UML – Diagrama de Classes

Pedro Ramos, José Farinha, DCTI/ISCTE

UML – Diagrama de Classes

Pedro Nogueira Ramos([email protected])

José Farinha([email protected])

DCTI / ISCTE


Diagrama de Classes - Índice

Conceitos Básicos

Associações (# / #)

Classes Associativas

Agregações

Composições

Generalizações

Atributos Versus Classes

Associações n/1-árias

Associações singulares (uma classe)

Relações de Dependência

Roles

Navegação

Especificação de Atributos

Packages


Objectos

Objecto: qualquer coisa relevante do domínio que pretendemos modelar e que têm:

. Identidade (forma de o identificar)

. Estado (conjunto de atributos)

. Comportamento (operações que sobre ele podem ser efectuadas)

Cliente ‘João Silva’

É distinto de outros clientes da empresaAtributos: nome, morada, nº contribuinte, ...Operações: emitir facturas, alterar morada, ...



Classes


Classe: conjunto de objectos que partilham o mesmo Mecanismo de Identificação, Estado, Comportamento, Relações e Semântica.

Classe dos Clientes

Todos distintos uns dos outrosPartilham atributos e operações Relacionam-se com as mesmas classes (e.g., produtos que adquirem)Representam a mesma realidade (semântica)

Os objectos não têm necessariamente que corresponder a entidades humanas ou, mais genericamente, a entidades com representação física (e.g., uma factura). Um conceito abstracto, por exemplo um departamento, pode ser um objecto (caso seja relevante para o domínio em causa).


Classe: Representação Gráfica

Classe dos Clientes

ClienteNum. ContribuinteNomeMorada

Atribuir Factura()

Designação (distinta)

Atributos (relevantes)

Operações (relevantes)



Atributos• Um atributo numa classe representa uma característica típica dos objectos dessa classe e

pode assumir qualquer valor• Pode especificar-se um tipo de dados para um atributo

Neste caso, os valores que podem ser atribuídos ao atributo estão condicionados à compatibilidade com o tipo

Informação: No âmbito da cadeira e para efeitos de resolução de exercícios práticos, não se considera necessário indicar o tipo de dados no diagrama de classes UML. Na realização do trabalho, sim.

• Em UML, um atributo definido numa classe é de preenchimento opcional:– Em cada novo objecto que seja criado, o dito atributo poderá ser ou não preenchido.– Não há em UML forma de especificar obrigatoriedade de preenchimento– Em desenho de base de dados é importante identificar a obrigatoriedade de preenchimento – mas

tal será feito apenas quando for gerado o modelo relacional da base de dados• Se for considerado muito relevante colocar essa informação no diagrama de classes UML, indicar os

atributos de preenchimento obrigatório numa caixa de comentário UML

• Em UML pode especificar-se um valor por omissão (default value) para um atributo– Novos objectos serão preenchidos no dito atributo com o valor indicado caso não haja instrução

explícita para que o valor de preenchimento seja outro– Não usar para modelar o conceito de valor mais frequente

José Farinha

..., a não ser que o valor mais frequente seja tão frequente que garantidamente todos os objectos possuem esse valor no dito atributo quando não há outra indicação


Atributos de identificação

• Ao definir os atributos de uma classe, deverá incluir-se sempre um atributo (ou mais) que possa(m) funcionar como mecanismo de identificação dos objectos dessa classe. Isto é, um (ou mais) atributo(s) para o(s) qual(is):

– todos os objectos têm valor

– o valor nesse(s) atributo(s) garantidamente não se repete entre diferentes objectos.

• Em certos casos, não se conseguem apurar atributos para este efeito. Neste tipo de classes, especificamos um atributo adicional que permita distinguir os objectos, atributo esse cujos valores são artificialmente atribuídos a cada objecto, sem causar repetições.

– Este atributo diz-se um Identificador Interno, Identificador Único ou Identificador de Objecto (OI, Object Identifier) e é frequente receber nomes do género:

“Número [de ...]”“Código [de ...]”“Id”

– Por razões de performance, em termos de implementação (i.é, no modelo lógico e/ou físico) poderá introduzir-se um atributo destes mesmo que exista uma forma de identificação natural na classe

– No modelo de dados conceptual um atributo deste género apenas deverá ser indicado se não existir uma forma de identificação natural na classe


Desusos de UML para desenho de bases de dados relacionais

Para efeitos de desenho de base de dados relacional: – Não se especificam operações (métodos) das classes;– Não se especificam as visibilidades –

público/protegido/privado – dos atributos: todos se assumem públicos;

Se pretendêssemos desenhar uma base de dados orientada por objectos, tal já assim não seria;

– Relativamente a um atributo, não se faz especificação de multiplicidades superiores a 1, pois:

• Tal não é habitualmente suportado pelas ferramentas de desenho e construção de base de dados

• Não se pretende obter um modelo puramente orientado por objectos


Relações

Em qualquer sistema existem objectos que se relacionam entre si. Por exemplo, se considerarmos a classe das facturas da empresa, o cliente ‘João Silva’ relaciona-se com as facturas a ele emitidas.

A relação entre objectos é representada através das relações entre as classes, que podem ser de dois tipos:

1) Associações

2) Generalizações

Casos especiais:

Composição

Agregação



Associações

Uma associação é uma relação que permite especificar que objectos de uma dada classe se relacionam com objectos de outra classe.

Cliente

Num. ContribuinteNomeMorada

Factura

Data EmissãoData PagamentoValorNúmero de Factura

0 … *1

Um cliente pode estar associado a n facturas, ou a nenhuma ([0,*]), e

Uma factura está obrigatoriamente associada a um e apenas a um cliente ([1,1]).

Nota: 1 é equivalente a 1 ... 1



Multiplicidade das Associações0 ... 1, zero ou um 1 ... 1, um e apenas um0 ... *, de zero a n 1 ... *, de um a n 0 ... 3, de zero a 3 1 ... 3, de um a 3 ... infinitas combinações que é vulgar agruparem-se em:

0 … *0 …1

0 … 11 …1

0 … *0 … *

“um para muitos”

“um para um”

“muitos para muitos”



Associação “um para muitos”

Funcionário


Departamento

Designação 0...1 0…*

Semântica

• Um funcionário pode estar associado a um e apenas um departamento

• a um departamento podem-se associar vários ou nenhum funcionários.

João

Ana

Joana

Luís

Produção

Comercial

Financeiro

Informática

Funcional

Dado um funcionário é possível determinar em que departamento ele trabalha, e, dado um departamento é possível identificar os seus funcionários.



Associação “um para muitos”

Funcionário


Departamento

Designação 1 0 … *

João

Ana

Joana

Luís

Produção

Comercial

Financeiro

Informática

Funcional

Dado um funcionário é possível determinar em que departamento ele trabalha, e, dado um departamento é possível identificar os seus funcionários.


Semântica

• Um funcionário tem necessariamente que estar associado a um departamento

• a um departamento podem-se associar vários ou nenhum funcionários.


Associação “muitos para muitos”

Aluno

NúmeroNomeMorada

Disciplina

Designação0 ... *0 … *

João

Ana

Joana

Luís

Matemática

Direito

Marketing

Um objecto não pode estar duplamente associado a outro objecto (Joana / Marketing). À semelhança das classes (em que os objectos são distintos), as associações também têm que ser distintas.

InformáticaAs associações podem ter nomes, nomes esses que terão que ser distintos

frequenta


A mesma associação (domínio e co-domínio idênticos)


Nomes de Associações

• As associações podem ter nomes, nomes esses que terão que ser distintos

Aluno

NúmeroNomeMorada

Disciplina

Designação0 ... *0 … *

frequência


• As associações podem ter nomes, nomes esses que terão que ser distintos


Associação “um para um”

Factura

Data EmissãoData PagamentoValorNúmero de FacturaNº Recibo

Recibo

Nº ChequeBancoNº Recibo

0 … 11

É a associação que atribui um número de recibo à factura. Caso contrário, uma factura estaria associada a dois recibos (o recibo indicado no atributo da factura e o recibo resultante da associação).



Atributos enumerados

• Que apenas podem assumir valores incluídos num conjunto finito e bem delimitado


Classes Associativas (I)

As Classes Associativas são associações que se “transformam” em classes quando é necessário:

a) Colocar atributos na associação ou/e;

Licenciatura

DesignaçãoTipo Avaliação

Disciplina

DesignaçãoTipo Avaliação1 … *0 … *

Disciplinas da Licenciatura

Tipo Avaliação

0 … *



Classes Associativas (II)

b) Associar uma classe a uma associação.

Licenciatura

DesignaçãoTipo Avaliação

Disciplina

DesignaçãoTipo Avaliação1 … *0 … *

Disciplinas da Licenciatura

Tipo Avaliação

Docente


0 … *0 … *

0 … *

0 … *



Classes associativas

• As classes associativas são mais frequentemente necessárias nas associações muitos para muitos. Mas, em casos mais raros, fazem também sentido em associações de outras cardinalidades.

Pessoa

NomeMorada

Sistema de saúde

Nome0 … * 0 …1

Beneficiário

Núm. de beneficiário

Pessoa

NomeMoradaNúm. de beneficiário

Sistema de saúde

Nome0 … * 0 …1

UML – Diagrama de Classes

Documents

Transcript of UML – Diagrama de Classes