Esse artigo faz parte da revista SQL Magazine edição 57. Clique aqui para ler todos os artigos desta edição
T-SIZE: 10pt; FONT-FAMILY: Verdana">
A Unified Modeling Language (UML) é uma linguagem de modelagem (ler Nota DevMan 1). É importante deixar claro que ela não se trata de uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.
Ou seja, ela nos diz o que podemos modelar, mas não como. Modelos servem para possibilitar o entendimento do ambiente no qual o sistema irá operar, a comunicação entre as pessoas envolvidas em um projeto, promover a melhor compreensão dos requisitos do projeto, promover a difusão deste conhecimento entre os envolvidos e, avaliar diferentes soluções através da modelagem da solução.
Nota DevMan 1. A história da UML
A UML tem origem na compilação das "melhores práticas de engenharia" que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMT (Rumbaugh) e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comum e largamente utilizada. A UML pretende ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos.
Os esforços para a criação da UML tiveram início em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8 do Unified Process - Processo Unificado (
A UML possui dois grandes conjuntos de diagramas:
· Estrutural: modelam aspectos estáticos do software focando nas entidades participantes e seus relacionamentos. Os diagramas deste conjunto são: diagrama de classes, objetos, componentes, instalação, pacotes e estrutura.
· Comportamental: modelam aspectos dinâmicos do software focando, na maioria das vezes, como as entidades interagem para prover uma determinada funcionalidade para o usuário. Os diagramas deste conjunto são: diagrama de casos de uso, transição de estados, atividades, interação, seqüência, colaboração e de tempo.
Neste contexto, o diagrama de classes não é somente amplamente usado, mas também pode ser considerado o elemento central nas metodologias orientadas a objetos. Ele descreve os tipos de objetos no sistema e os vários tipos de relacionamento estático que existem entre eles.
Existem dois tipos básicos de relacionamentos:
· Associações: por exemplo, um cliente pode alugar vários vídeos;
· Subtipos: uma enfermeira é um tipo de pessoa;
Veremos rapidamente agora algumas das formas em que podemos utilizar cada um desses tipos de relacionamentos:
· Associação - Representa uma ligação entre dois elementos. Ainda podem expressar a cardinalidade (ou multiplicidade) e a navegação (sentido) da associação. Na Figura 1 temos uma associação simples entre duas entidades, cliente e conta corrente indicando que um cliente está associado a uma conta corrente.
Figura 1. Associação Simples
· Associação Recursiva – Acontece quando um elemento se conecta a ele mesmo, e a associação tem alguma semântica no modelo. Na Figura 2 mostramos como é possível conectar uma entidade a ela mesma através de uma associação recursiva e que ainda representa semanticamente a conexão entre dois objetos (neste caso, uma relação conjugal entre pessoas).
Figura 2. Associação Recursiva
· Associação Exclusiva – Quando algumas combinações de associações não são compatíveis no domínio do problema. É uma restrição entre duas ou mais associações. Na Figura 3 podemos notar que objetos de uma entidade podem participar de no máximo uma das associações em um dado momento. Uma associação exclusiva é representada por uma linha tracejada entre as associações que são partes da associação exclusiva, com a especificação "{ou}" sobre a linha tracejada.