UML Diagrama de Classes Pedro Nogueira Ramos Pedro

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 n/1 -árias Associações (# / #) Associações singulares (uma classe) Classes Associativas Relações de Dependência Agregações Roles Composições Navegação Generalizações Especificação de Atributos Versus Classes Packages Pedro Ramos, José Farinha, DCTI/ISCTE

UML – Diagrama de Classes 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. Classe dos Clientes 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) 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

UML – Diagrama de Classes Classe: Representação Gráfica Classe dos 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 1 0…* Data Emissão Data Pagamento Valor Número de Factura 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

UML – Diagrama de Classes Multiplicidade das Associações 0. . . 1, zero ou um 0. . . *, de zero a n 0. . . 3, de zero a 3 1. . . 1, um e apenas um 1. . . *, de um a n 1. . . 3, de um a 3 . . . infinitas combinações que é vulgar agruparem-se em: 0 … 1 0 … * 1 … 1 0…* 0…* Pedro Ramos, José Farinha, DCTI/ISCTE “um para muitos” “um para um” “muitos para muitos”

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

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

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

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 0…* 0. . . * Designação frequência • As associações podem ter nomes, nomes esses que terão que ser distintos Pedro Ramos, José Farinha, DCTI/ISCTE

UML – Diagrama de Classes Associação “um para um” Factura 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). 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

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

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

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 Nome