Cada elemento em UML tem um conjunto de propriedades. Por exemplo: as classes têm um nome, uma lista de atributos e uma lista de operações; as associações têm um nome e dois ou mais elementos participantes. Enquanto que os estereótipos permitem adicionar novos elementos ao UML, as marcas com valor permitem adicionar novas propriedades aos elementos, quer sejam elementos já existentes no UML, quer sejam elementos definidos por recurso a novos estereótipos. Uma marca com valor é um conceito que deve ser entendido como metadata (isto é, dados que descrevem dados) pois o seu valor aplica- se ao próprio elemento e não às suas instâncias. Por exemplo, confor- me ilustrado na Figura 4.12, pode-se especificar o número de proces- sadores instalados em cada tipo de nó, ou pode-se especificar se um determinado componente é para ser instalado/usado com perfil de clien- te, servidor, ou ambos.
Figura 4.12: Exemplo de marcas com valor.
Um par “marca” e “valor” é delimitado entre os caracteres ‘{’ e ‘}’. Exemplos de aplicações usuais:
§ Para geração de código: E.g.: {language=Java}, {linker=Blinker}. § Na produção automática de documentação.
Restrições
As restrições (constraints) permitem adicionar ou alterar a semântica assumida por omissão de qualquer elemento UML. Uma restrição consiste na especificação de uma condição delimitada pelos caracteres ‘{’ e ‘}’. A condição pode ser especificada numa linguagem formal (e.g., OCL) ou informal (e.g., texto em português).
Uma restrição permite especificar condições que têm de ser validadas para que o modelo esteja “bem definido”.
Figura 4.13: Exemplos de utilização de restrições.
A Figura 4.13 ilustra dois exemplos de especificação de restrições. No primeiro exemplo especifica-se em OCL que “uma pessoa pode estar
casada apenas com outra pessoa do sexo oposto” (Exemplo 1). No
segundo exemplo, especifica-se através da restrição {subset}, predefinida em UML, que os elementos da associação “gerir” tem de existir obrigatoriamente na associação “trabalhar”, ou seja especifica-se que “uma pessoa para ser gestor de um departamento tem também de
ser, necessariamente, membro desse departamento” (Exemplo 2).
4.7
Tipos de Dados
Um tipo de dado é uma abstracção utilizada de forma implícita no UML. Os tipos de dados não são elementos do modelo e por conseguinte não lhe são associados estereótipos, marcas com valor ou restrições. Um tipo primitivo é um tipo de dados que não tem uma subestrutura.
Exemplos de tipos de dados:
CAPÍTULO 4 - UML – VISÃO GERAL
1 3 5
§ Enumerados: Boolean, AggregationKind, VisibilityKind § Outros: Expression, Mapping, Name, Multiplicity
Note-se que os conceitos de nomes, expressões ou multiplicidade são tipos de dados UML, definidos informalmente à custa de outros tipos primitivos. Por exemplo, o tipo Multiplicity é definido como “o com- junto não vazio de inteiros (Integer) positivos, estendido com o carac- ter ‘*’”; o tipo Expression é definido como “uma sequência de carac- teres (String) cuja sintaxe não é definida, propositadamente, pelo UML”.
Para mais detalhes consulte-se a Secção 9.2.2.
4.8
Organização dos Artefactos – Pacotes
Um pacote (package) é em UML um elemento meramente organiza- cional. Permite agregar diferentes elementos de um sistema em grupos de forma que semântica ou estruturalmente faça sentido.
Um pacote pode conter outros elementos, incluindo: classes, interfaces, componentes, nós, casos de utilização, e mesmo outros pacotes. Por outro lado, um elemento encontra-se definido em apenas um único pacote.
A necessidade da existência de pacotes torna-se evidente na modelação de sistemas de média/grande dimensão, em que, por razões de ordem prática, se torna impossível modelizá-los de uma “só vez”. Os principais benefícios da sua utilização são: (1) facilita a gestão e procura de artefactos; (2) evita os conflitos de nomes (e.g., X::A é diferente de X::Y:A, e diferente de Z::A); e (3) providencia um mecanismo de contro- lo de acessos (visibilidade).
Elementos de diferentes tipos podem ter o mesmo nome dentro de um pacote. Por exemplo, pode existir num pacote uma classe e um compo- nente com o nome Entidade. Contudo, de modo a reduzir ou eliminar as possíveis confusões, sugere-se que tal prática não seja adoptada.
4.8.1 Representação Gráfica
Em UML os pacotes são representados graficamente por uma pasta (tabbed folder) com duas zonas complementares: um pequeno rectân- gulo (designado por tabulador ou tab), normalmente com o nome do pacote; e um rectângulo maior onde normalmente se especificam os elementos constituintes desse pacote ou, pelo menos, os seus elemen- tos públicos.
Figura 4.14: Exemplos de pacotes.
A Figura 4.14 ilustra alguns exemplos de representação de pacotes. No exemplo (1) o pacote tem o nome Utilizadores e descreve os seus elementos. Os símbolos “+”, “-“ e “#” representam informação de visibi- lidade, respectivamente visibilidade pública, privada e protegida (ver secção seguinte para mais detalhes).
O exemplo (2) ilustra uma forma alternativa de representar um pacote em que não são apresentados os seus elementos. O nome do pacote é Regras de Negócio e encontra-se colocado no meio do rectângulo maior.
Por fim, o exemplo (3) ilustra dois aspectos interessantes. Por um lado, a possibilidade de relações de hierarquia ou de inclusão entre pacotes: o pacote Docentes está contido no pacote DEI e pode ser identificado univocamente pela concatenação dos vários nomes separados pelo
CAPÍTULO 4 - UML – VISÃO GERAL
1 3 7
símbolo “::”. Outro aspecto interessante é a possibilidade de caracterizar o pacote através dos mecanismos comuns discutidos na Secção 4.6, tais como especificação de marcas (e.g., {version=1.4}), estereóti- pos ou restrições.
4.8.2 Relações entre Pacotes
Os pacotes apresentam entre si diferentes tipos de relações, em particular relações de importação, exportação e generalização.
Visibilidade
Os símbolos “+”, “-“ e “#” (ou similares, que as ferramentas CASE proponham), à semelhança do que acontece na especificação de atribu- tos e operações de classes, permitem indicar o tipo de visibilidade que os elementos constituintes de um pacote apresentam.
§ Um elemento com visibilidade pública (prefixado com o símbolo “+”) pode ser usado/referenciado por qualquer outro elemento inde- pendentemente do local onde é definido.
§ Um elemento com visibilidade privada (prefixado com o símbolo “- ”) pode ser usado/referenciado por elementos definidos no mesmo pacote.
§ Um elemento com visibilidade protegida (prefixado com o símbolo “#”) pode ser usado/referenciado por um elemento definido no mesmo pacote ou num outro pacote que seja uma especialização (através da relação de herança) do primeiro.
À semelhança do que acontece com algumas linguagens de programação (e.g., C++) relativamente à relação entre classes, é possível definir-se uma relação de friend entre dois pacotes (é uma relação de dependência entre pacotes, com estereótipo «friend»). Neste caso, um pacote que é friend de outro pode aceder/referenciar todos os seus elementos independentemente da sua visibilidade. Contudo este tipo de dependência deve ser evitado sempre que possível porque viola os princípios do encapsulamento e da minimização de dependências.