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

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

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

UML – Diagrama de 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

Classe: Representação Gráfica 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

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

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

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

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

UML – Diagrama de Classes 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. Contribuinte Nome Morada Factura Data Emissão Data Pagamento Valor Nú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 Pedro Ramos, José Farinha, DCTI/ISCTE

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

Associação “um para muitos” UML – Diagrama de Classes 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. Funcionário Num. Contribuinte Nome Morada Departamento Designação 0...1 0…* 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

Associação “um para muitos” UML – Diagrama de Classes 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. Funcionário Num. Contribuinte Nome Morada Departamento Designação 1 0 … * 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

Associação “muitos para muitos” UML – Diagrama de Classes 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. Aluno Número Nome Morada Disciplina Designação 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

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

Associação “um para um” UML – Diagrama de Classes Associação “um para um” Factura Recibo Data Emissão Data Pagamento Valor Número de Factura Nº Recibo 1 0 … 1 Nº Cheque Banco Nº Recibo É 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). Ilustrar também um caso com 3 classes e 2 relações: A – B – C. E em que se pretende saber a relação entre objectos de A e de C. Discutir alternativas: atributo com restrição ou relação de 1-para-N? – discutido à frente Pedro Ramos, José Farinha, DCTI/ISCTE

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

Classes Associativas (I) UML – Diagrama de Classes 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 Disciplina Designação Tipo Avaliação 0 … * Designação Tipo Avaliação 0 … * 1 … * Disciplinas da Licenciatura Tipo Avaliação Pedro Ramos, José Farinha, DCTI/ISCTE

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

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

Classe associativa vs. Classe com 2 associações Pedro Ramos, José Farinha, DCTI/ISCTE

0...* vs. 1...* Usar o 1...* quando a informação do lado muitos não faz sentido (não tem utilidade) sem a informação do lado 1. Pedro Ramos, José Farinha, DCTI/ISCTE