4.2. UML Diagramas de classes

Transcrição

1 Engenharia de Software 4.2. UML Diagramas de classes Nuno Miguel Gil Fonseca

2 Um diagrama de classes serve para modelar o vocabulário de um sistema Construído e refinado ao longo das várias fases do desenvolvimento do software, por analistas, projectistas (designers) e implementadores Também servem para: Especificar colaborações (no âmbito de um caso de uso ou mecanismo) Especificar esquemas lógicos de bases de dados Especificar vistas (estrutura de dados de formulários, relatórios, etc.) (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 2

3 Objectos Um objecto é algo com fronteiras bem definidas, relevante para o problema em causa que tem: Um estado modelado por valores de atributos (tamanho, forma, peso, etc.) e por ligações que num dado momento tem com outros objectos Um comportamento um objecto exibe comportamentos invocáveis (por resposta a chamadas de operações) ou reactivos (por resposta a eventos) Uma identidade no espaço: é possível distinguir dois objectos mesmo que tenham o mesmo estado exemplo: podemos distinguir duas folhas de papel A4, mesmo que tenham os mesmos valores dos atributos no tempo: é possível saber que se trata do mesmo objecto mesmo que o seu estado mude exemplo: se pintarmos um folha de papel A4 de amarelo, continua a ser a mesma folha de papel (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 3

4 Objectos do mundo real e objectos computacionais No desenvolvimento de software orientado por objectos, procura-se imitar no computador o mundo real visto como um conjunto de objectos que interagem entre si Muitos objectos computacionais são imagens de objectos do mundo real Dependendo do contexto (análise ou projecto) podemos estar a falar em objectos do mundo real, em objectos computacionais ou nas duas coisas em simultâneo Exemplos de objectos do mundo real: o Sr. João Exemplos de objectos computacionais: o registo que descreve o Sr. João (imagem de objecto do mundo real) uma árvore de pesquisa binária (objecto puramente computacional) (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 4

5 No desenvolvimento de software OO, não nos interessam tanto os objectos individuais mas sim as classes de objectos Uma classe é um descritor de um conjunto de objectos que partilham as mesmas propriedades (semântica, atributos, operações e relações) Um objecto de uma classe é uma instância da classe A extensão de uma classe é o conjunto de instâncias da classe (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 5

6 podem representar: Coisas concretas: Pessoa, Turma, Carro, Imóvel, Factura, Livro Papéis que coisas concretas assumem: Aluno, Professor, Piloto Eventos: Curso, Aula, Acidente Tipos de dados: Data, Intervalo de Tempo, Número Complexo, Vector Decomposição orientada por objectos : começa por identificar os tipos de objectos (classes) presentes num sistema tipos de objectos são mais estáveis do que as funções, logo a decomposição orientada por objectos leva a arquitecturas mais estáveis (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 6

7 Em UML, uma classe é representada por um rectângulo com o nome da classe Habitualmente escreve-se o nome da classe no singular (nome de uma instância), com a 1ª letra em maiúscula Para se precisar o significado pretendido para uma classe, deve-se explicar o que é (e não é...) uma instância da classe Exemplo: Um aluno é uma pessoa que está inscrita num curso ministrado numa escola. Uma pessoa que esteve no passado inscrita num curso, mas não está presentemente inscrita em nenhum curso, não é um aluno. (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 7

8 As classes, são caracterizadas por: nome (ou identificador) atributos operações restrições (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 8

9 Atributos O estado de um objecto é dados por valores de atributos (e por ligações que tem com outros objectos) Todos os objectos de uma classe são caracterizados pelos mesmos atributos (ou variáveis de instância) o mesmo atributo pode ter valores diferentes de objecto para objecto Atributos são definidos ao nível da classe, enquanto que os valores dos atributos são definidos ao nível do objecto Exemplos: uma pessoa (classe) tem os atributos nome, data de nascimento e peso ZeCarlos (objecto) é uma pessoa com nome José Carlos, data de nascimento 29/01/1965 e peso 80kg (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 9

10 Atributos Os atributos são listados num compartimento de atributos (opcional) a seguir ao compartimento com o nome da classe Uma classe não deve ter dois atributos com o mesmo nome Os tipos de dados não estão pré-definidos em UML, podendo-se usar os da linguagem de implementação alvo (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 10

11 Operações Comportamento invocável de objectos é modelado por operações uma operação é algo que se pode pedir para fazer a um objecto de uma classe Objectos da mesma classe têm as mesmas operações Operações são definidos ao nível da classe, enquanto que a invocação de uma operação é definida ao nível do objecto Princípio do encapsulamento: acesso e alteração do estado interno do objecto (valores de atributos e ligações) controlado por operações Nas classes que representam objectos do mundo real é mais comum definir responsabilidades em vez de operações (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 11

12 Operações (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 12

13 Atributos e operações estáticas Atributo estático: tem um único valor para todas as instâncias (objectos) da classe valor está definido ao nível da classe e não ao nível das instâncias Operação estática: não é invocada para um objecto específico da classe Notação: nome sublinhado Correspondem a membros estáticos (static) em C++, C# e Java (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 13

14 Atributos e operações estáticas (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 14

15 Visibilidade de atributos e operações Visibilidade: + (public) : visível por todos - (private) : visível só por operações da própria classe # (protected) : visível por operações da própria classe e descendentes (subclasses) (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 15

16 Visibilidade de atributos e operações Princípio do encapsulamento esconder todos os detalhes de implementação que não interessam aos clientes (utilizadores) da classe permite alterar representação do estado sem afectar clientes permite validar alterações de estado (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 16

17 Relação entre classes Associações binárias Uma associação é uma relação entre objectos das classes participantes Assim como um objecto é uma instância duma classe, uma ligação é uma instância duma associação Pode haver mais do que uma associação (com nomes diferentes) entre o mesmo par de classes Papéis nos extremos da associação podem ter indicação de visibilidade (pública, privada, etc.) (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 17

18 Relação entre classes Notação para a multiplicidade (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 18

19 Relação entre classes Multiplicidade de associações binárias (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 19

20 Relação entre classes Nome da associação A indicação do nome é opcional O nome é indicado no meio da linha que une as classes participantes Pode-se indicar o sentido em que se lê o nome da associação (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 20

21 Relação entre classes Associação reflexiva Pode-se associar uma classe com ela própria (em papéis diferentes) (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 21

22 Relação entre classes Associações unidireccionais As associações são classificadas quanto à navegabilidade em: Bidireccionais (normais) Unidireccionais Significado das associações unidireccionais: um objecto da classe 1 tem a responsabilidade de dar o(s) objecto(s) correspondente(s) da classe 2 (nível de especificação), ou um objecto da classe 1 tem apontador(es) para o(s) objecto(s) correspondente(s) da classe 2 (nível de implementação) (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 22

23 Relação entre classes Classe-associação reúne as propriedades de associação e classe o nome pode ser colocado num sítio ou noutro, conforme interessa realçar a natureza de associação ou de classe, mas a semântica é a mesma o nome também pode ser colocado nos dois sítios não é possível repetir combinações de objectos das classes participantes na associação (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 23

24 Relação entre classes Atributos vs associações Uma propriedade que designa um objecto de uma classe presente no modelo, deve ser modelada como uma associação e não como um atributo (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 24

25 Relação entre classes Agregação Associação com o significado contém (é constituído por) / faz parte de (part of) Relação de inclusão nas instâncias das classes Hierarquias de objectos (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 25

26 Relação entre classes Agregação Os valores dos atributos de uma classe propagam-se para os valores dos atributos de outra classe Uma acção sobre uma classe implica uma acção sobre outra classe Os objectos de uma classe estão subordinados aos objectos de outra classe (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 26

27 Relação entre classes Composição Forma mais forte de agregação aplicável quando: existe um forte grau de pertença das partes ao todo cada parte só pode fazer parte de um todo (i.e., a multiplicidade do lado do todo não excede 1) Espera-se que as partes só vivam enquanto viver o todo: qualquer apagamento ou destruição do todo leva ao apagamento ou destruição das partes o objecto parte só pode pertencer a um (único) todo (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 27

28 Relação entre classes Generalização Relação semântica is a ( é um / é uma ) : um aluno é uma pessoa Relação de inclusão nas extensões das classes: A sub-classe herda as propriedades (atributos, operações e relações) da super-classe, podendo acrescentar outras (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 28

29 Relação entre classes Generalização Notações alternativas (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 29

30 Relação entre classes Generalização Em geral, pode-se ter uma hierarquia de classes relacionadas por herança / generalização em cada classe da hierarquia colocam-se as propriedades que são comuns a todas as suas subclasses evita-se redundância, promove-se reutilização! (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 30

31 Relação entre classes Generalização Herança múltipla ocorre numa subclasse com múltiplas super-classes suportada por algumas linguagens de programação OO (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 31

32 Relação entre classes e operações abstractas Classe abstracta: classe que não pode ter instâncias directas pode ter instâncias indirectas pelas subclasses concretas Operação abstracta: operação com implementação a definir nas subclasses uma classe com operações abstractas tem de ser abstracta Notação : nome em itálico ou propriedade {abstract} (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 32

33 Relação entre classes e operações abstractas (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 33

34 Relação entre classes Dependência Relação de uso entre dois elementos (classes, componentes, etc.), em que uma mudança na especificação do elemento usado pode afectar o elemento utilizador Exemplo típico: classe-1 que depende de outra classe-2 porque usa operações ou definições da classe-2 (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 34

35 Relação entre classes Concretização (realization) Relação entre elementos a diferentes níveis de abstracção, isto é, entre um elemento mais abstracto (que especifica uma interface ou um "contracto", entre clientes e implementadores) e um elemento correspondente mais concreto (que implementa esse contracto) Difere da generalização porque há apenas herança de interface e não herança de implementação (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 35

36 Relação entre classes Dependência e concretização Aparecem frequentemente combinados Exemplo: Cliente usa o servidor sem dele depender directamente (depende apenas da interface ou contracto que o servidor implementa) (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 36

37 Interfaces Uma interface especifica um conjunto de operações (com sintaxe e semântica) externamente visíveis de uma classe de (ou componente, subsistema, etc.) semelhante a classe abstracta só com operações abstractas e sem atributos nem associações separação mais explícita entre interface e (classes de) implementação interfaces são mais importantes em linguagens como Java, C# e VB.NET que têm herança simples de implementação e herança múltipla de interface (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 37

38 Interfaces Relação de concretização de muitos para muitos entre interfaces e classes de implementação Vantagem em separar interface de implementação: os clientes de uma classe podem ficar a depender apenas da interface em vez da classe de implementação Notação: classe com estereótipo «interface» (ligada por relação de concretização à classe de implementação) ou círculo (ligado por linha simples à classe de implementação) (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 38

39 Interfaces (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 39

40 Os diagramas de classes podem ser sob três perspectivas: Conceptual De especificação De implementação (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 40

41 Perspectiva conceptual A classe exprime um conceito abstracto no domínio em estudo As associações representam relacionamentos conceptuais Cada associação tem dois papéis, que correspondem a cada um dos dois sentidos do relacionamento S é um sub-tipo de T se todas as instâncias de S forem também, por definição, instâncias de T A ideia chave é que tudo o que estabelecermos para T (associações, atributos, operações) é também válido para S (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 41

42 Perspectiva de especificação Já se pensa a classe em termos de software, mas em termos de função e não de implementação (i.e., interfaces) (ex.: pedais de um carro) As associações representam responsabilidades Estas responsabilidades não implicam, no entanto, estruturas de dados Generalização significa que a interface do sub-tipo tem que incluir todos os elementos da interface do super-tipo Diz-se que a interface do sub-tipo está conforme com a interface do super-tipo (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 42

43 Perspectiva de implementação A classe é descrita em termos da sua implementação As associações exprimem agora a existência de ponteiros nos dois sentidos, entre as classes ligadas pela associação A generalização está associada com o fenómeno da herança nas linguagens de programação orientadas para objectos Fala-se aqui de sub-classes, e não de sub-tipos, e considera-se que a sub-classe herda todos os métodos e todos os atributos da super-classe, podendo os métodos da sub-classe sobrepor-se aos métodos herdados (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 43

44 É fundamental reconhecer sempre em que perspectiva se está a desenhar, ou a ler, um diagrama de classes Para que queremos o diagrama que estamos a desenhar? Vamos usá-lo para comunicar com quem? Programadores? Analistas? (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 44

45 Adequar a perspectiva que se está a usar à fase em que o projecto se encontra: fazer diagramas conceptuais se se está a fazer a análise de especificação se começa a pensar em software de implementação apenas quando se quer ilustrar uma solução de implementação mais particular No nosso caso, interessa-nos mais a perspectiva conceptual! (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 45

46 Quando usar? Evitar a todo o custo começar a pensar nos pormenores de implementação demasiado cedo. Para o conseguir, procurar concentrar a atenção nas perspectivas de concepção e de especificação (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 46

47 Quando usar? Os diagramas de classes são a espinha dorsal de praticamente todos os métodos orientados para objectos, sendo, por isso, os mais usados São, no entanto, muito ricos e complexos, pelo que se recomenda o seu uso com alguns cuidados Não tentar usar todas as notações disponíves. Usar as mais complexas apenas quando for indispensável Estes slides não são exaustivos na explicação destes diagramas! (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 47

48 Não desenhar modelos para tudo!! É melhor ter poucos diagramas que se vão actualizando quando necessário do que ter muitos diagramas que se vão tornando obsoletos por falta de actualização Isto vale para TODOS os tipos de diagramas UML! (c) Nuno Miguel Gil Fonseca - Escola Superior de Tecnologia e Gestão de Oliveira do Hospital - Engenharia de Software 48