UML – Diagrama de Classes

1. UML – Diagrama de Classes Pedro Nogueira Ramos (Pedro.Ramos@iscte.pt) José Farinha (Jose.Farinha@iscte.pt) DCTI / ISCTE Pedro Ramos, José Farinha, DCTI/ISCTE

2. 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 Pedro Ramos, José Farinha, DCTI/ISCTE

3. UML – Diagrama de Classes 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) • É distinto de outros clientes da empresa • Atributos: nome, morada, nº contribuinte, ... • Operações: emitir facturas, alterar morada, ... Cliente ‘João Silva’ Pedro Ramos, José Farinha, DCTI/ISCTE

4. UML – Diagrama de Classes Classes Classe: conjunto de objectos que partilham o mesmo Mecanismo de Identificação, Estado, Comportamento, Relações e Semântica. • Todos distintos uns dos outros • Partilham atributos e operações • Relacionam-se com as mesmas classes (e.g., produtos que adquirem) • Representam a mesma realidade (semântica) Classe dos Clientes 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). Pedro Ramos, José Farinha, DCTI/ISCTE

5. UML – Diagrama de Classes Classe: Representação Gráfica Classe dos Clientes Cliente Designação (distinta) Num. Contribuinte Nome Morada Atributos (relevantes) Atribuir Factura() Operações (relevantes) Pedro Ramos, José Farinha, DCTI/ISCTE

6. 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 Pedro Ramos, José Farinha, DCTI/ISCTE

7. 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 Pedro Ramos, José Farinha, DCTI/ISCTE

8. 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 Pedro Ramos, José Farinha, DCTI/ISCTE

9. UML – Diagrama de Classes 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 Casos especiais: Composição Agregação 2) Generalizações Pedro Ramos, José Farinha, DCTI/ISCTE

10. UML – Diagrama de Classes Cliente Factura Num. Contribuinte Nome Morada Data Emissão Data Pagamento Valor Número de Factura 1 0 … * Associações Uma associação é uma relação que permite especificar que objectos de uma dada classe se relacionam com objectos de outra classe. 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 Pedro Ramos, José Farinha, DCTI/ISCTE

11. UML – Diagrama de Classes 0 …1 0 … * 0 … 1 1 …1 0 … * 0 … * Multiplicidade das Associações 0 ... 1, zero ou um 1 ... 1, um e apenas um 0 ... *, 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: “um para muitos” “um para um” “muitos para muitos” Pedro Ramos, José Farinha, DCTI/ISCTE

12. UML – Diagrama de Classes 0…* 0...1 Funcionário Departamento Num. Contribuinte Nome Morada Designação Associação “um para muitos” • 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. Produção João Ana Comercial Funcional Dado um funcionário é possível determinar em que departamento ele trabalha, e, dado um departamento é possível identificar os seus funcionários. Luís Financeiro Joana Informática Pedro Ramos, José Farinha, DCTI/ISCTE

13. UML – Diagrama de Classes 0 … * 1 Funcionário Departamento Num. Contribuinte Nome Morada Designação Associação “um para muitos” • 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. Produção João Ana Comercial Funcional Dado um funcionário é possível determinar em que departamento ele trabalha, e, dado um departamento é possível identificar os seus funcionários. Luís Financeiro Joana Informática Pedro Ramos, José Farinha, DCTI/ISCTE

14. UML – Diagrama de Classes Aluno Disciplina Número Nome Morada Designação Associação “muitos para muitos” 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. 0 … * 0 ... * frequenta João Matemática Ana Direito Luís Joana Marketing As associações podem ter nomes, nomes esses que terão que ser distintos Informática A mesma associação (domínio e co-domínio idênticos) Pedro Ramos, José Farinha, DCTI/ISCTE

15. UML – Diagrama de Classes Aluno Disciplina Número Nome Morada Designação Nomes de Associações • As associações podem ter nomes, nomes esses que terão que ser distintos 0 … * 0 ... * frequência • As associações podem ter nomes, nomes esses que terão que ser distintos Pedro Ramos, José Farinha, DCTI/ISCTE

16. UML – Diagrama de Classes Associação “um para um” Factura Recibo Data Emissão Data Pagamento Valor Número de Factura Nº Recibo Nº Cheque Banco Nº Recibo 1 0 … 1 É 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). Pedro Ramos, José Farinha, DCTI/ISCTE

17. Atributos enumerados • Que apenas podem assumir valores incluídos num conjunto finito e bem delimitado Pedro Ramos, José Farinha, DCTI/ISCTE

18. UML – Diagrama de Classes Disciplina Designação Tipo Avaliação Classes Associativas (I) • As Classes Associativas são associações que se “transformam” em classes quando é necessário: • Colocar atributos na associação ou/e; Licenciatura 0 … * Designação Tipo Avaliação 0 … * 1 … * Disciplinas da Licenciatura Tipo Avaliação Pedro Ramos, José Farinha, DCTI/ISCTE

19. UML – Diagrama de Classes 0 … * 0 … * 0 … * 0 … * Disciplina Docente Num. Contribuinte Nome Morada Designação Tipo Avaliação Classes Associativas (II) b) Associar uma classe a uma associação. Licenciatura Designação Tipo Avaliação 0 … * 1 … * Disciplinas da Licenciatura Tipo Avaliação Pedro Ramos, José Farinha, DCTI/ISCTE

20. 0 … * 0 …1 0 … * 0 …1 Sistema de saúde Pessoa Pessoa Sistema de saúde Beneficiário Nome Morada Nome Núm. de beneficiário Nome Morada Núm. de beneficiário Nome 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. Pedro Ramos, José Farinha, DCTI/ISCTE