A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Pedro Ramos, José Farinha, DCTI/ISCTE UML – Diagrama de Classes Pedro Nogueira Ramos José Farinha

Apresentações semelhantes


Apresentação em tema: "Pedro Ramos, José Farinha, DCTI/ISCTE UML – Diagrama de Classes Pedro Nogueira Ramos José Farinha"— Transcrição da apresentação:

1 Pedro Ramos, José Farinha, DCTI/ISCTE UML – Diagrama de Classes Pedro Nogueira Ramos José Farinha DCTI / ISCTE

2 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

3 Pedro Ramos, José Farinha, DCTI/ISCTE 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 empresa Atributos: nome, morada, nº contribuinte,... Operações: emitir facturas, alterar morada,... UML – Diagrama de Classes

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

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

6 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

7 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

8 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

9 Pedro Ramos, José Farinha, DCTI/ISCTE 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 UML – Diagrama de Classes

10 Pedro Ramos, José Farinha, DCTI/ISCTE 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 UML – Diagrama de Classes

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

12 Pedro Ramos, José Farinha, DCTI/ISCTE Associação um para muitos Funcionário Num. Contribuinte Nome Morada Departamento Designação …* 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. UML – Diagrama de Classes

13 Pedro Ramos, José Farinha, DCTI/ISCTE Associação um para muitos Funcionário Num. Contribuinte Nome Morada 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. UML – Diagrama de Classes 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.

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

15 Pedro Ramos, José Farinha, DCTI/ISCTE 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 UML – Diagrama de Classes As associações podem ter nomes, nomes esses que terão que ser distintos

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

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

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

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

20 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 Sistema de saúde Nome 0 … *0 …1 Beneficiário Núm. de beneficiário Pessoa Nome Morada Núm. de beneficiário Sistema de saúde Nome 0 … *0 …1

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

22 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.


Carregar ppt "Pedro Ramos, José Farinha, DCTI/ISCTE UML – Diagrama de Classes Pedro Nogueira Ramos José Farinha"

Apresentações semelhantes


Anúncios Google