Engenharia de Software Orientada a Objetos Professor: Guilherme Timóteo Aula 3: – Modelagem de Classes (parte 2)

Apresentação em tema: "Engenharia de Software Orientada a Objetos Professor: Guilherme Timóteo Aula 3: – Modelagem de Classes (parte 2)"— Transcrição da apresentação:

1 Engenharia de Software Orientada a Objetos Professor: Guilherme Timóteo Aula 3: – Modelagem de Classes (parte 2)

2 Agenda Conceitos de Ligação e Associação Generalização Herança Dicas Práticas para Modelagem de Classes

3 Conceitos de Ligação e Associação Ligação é uma conexão física ou conceitual entre objetos – Ex: João da Silva trabalha para a Empresa X A maioria das ligações se relaciona com dois objetos, embora existam ligações relacionando mais de dois objetos Associação é a descrição de um grupo de ligações com estrutura semelhantes – Ex: Uma Pessoa trabalha para uma empresa

4 Exemplo de Associação Na bolsa de valores, uma pessoa pode ter uma ou mais ações de uma determinada empresa. Por outro lado, as ações de uma empresa podem pertencer a diversas pessoas. Abaixo a modelagem do caso acima citado: O relaciomento acima citado correspondente a um relacionamento muitos para muitos. Nota que existe um “*” ao lado de cada classe envolvida no exemplo Pessoa nome: string Empresa nome: string PossuiAcao ** Diagrama de Classe

5 Implementação de uma associação A implementação é muito simples. Normalmente os desenvolvedores implementam associações como referências de um objeto para outro. Um referência é um atributo de um objeto que se refere a outro. Veja o exemplo abaixo: Pessoa nome: string Cargo nome: string Possui 1* Diagrama de Classe Pessoa nome: string cargo: Cargo Note que a classe Pessoa agora tem um atributo representando a associação com a classe Cargo.

6 Multiplicidade Especifica o número de instâncias de uma classe que se podem relacionar com outra. A notação UML prevê a multiplicidade como um intervalo: – 1 = Exatamente 1 instância – 1..* = 1 ou mais instâncias – 3..5 = de 3 a 5 instâncias – * = 0 ou muitas instâncias

7 Multiplicidade Abaixo um relacionamento exemplo “um para muitos”: Abaixo um relacionamento exemplo “muitos para muitos”: Pessoa nome: string Cargo nome: string Possui 1* Pessoa nome: string Empresa nome: string PossuiAcao **

8 Multiplicidade Abaixo um relacionamento exemplo “um para um”: Abaixo um relacionamento exemplo “um para um intervalo especificado”: Pais nome: string Capital nome: string Possui 11 Pessoa nome: string Dependente nome: string Possui 11..3

9 Multiplicidade Primeiramente devemos nos preocupar em identificar as classes e seus relacionamentos. Os detalhes sobre a multiplicidade deverão ser investigados quando o trabalho de identificação dos objetos estiver concluído. O tipo de multiplicidade mais comum é o “um para muitos”. A determinação da multiplicidade vai depender da análise do contexto da aplicação. Em alguns casos, uma pessoa poderá trabalhar em vários cargos nas empresas e desta forma, a multiplicidade será de muitos para muitos. Em outros casos, a pessoa poderá trabalhar somente em um cargo. Neste caso, a multiplicidade será de um para muitos.

10 Nome das extremidades Para tornar o modelo mais claro é importante indicar os nomes das extremidades. O nomes das extremidades normalmente aparecem como substântivos que irão descrever de alguma forma a função daquele extremidade no relacionamento entre as classes. Pessoa nome: string Empresa nome: string TrabalhaPara*0..1 EmpregadoEmpregador

11 Nome das extremidades Ao colocar os nomes nas extremidades você poderá ter uma noção dos possíveis erros de modelagem. Vamos abaixo a um exemplo: Pai 2 pai filho Filho * Errado Pessoa * 2 Certo

12 Classes de associação Classe de associação é um classe que representa uma associação entre outras classes. As classes de associação são utilizadas quando o relacionamento entre as classes é composto por mais de um atributo. Abaixo um exemplo: Pessoa nome: string Empresa nome: string ** EmpregadoEmpregador TrabalhaPara cargo: string salario: float Salario e cargo são os atributos que relacionam uma Pessoa com uma Empresa

13 Generalização e Herança É o relacionamento entre a superclasse e suas respectivas subclasses. A generalização organiza as classes de acordo com suas semelhanças e diferenças, estruturando a descrição dos objetos. O relacionamento entre superclasses e subclasses pode ser definido da seguinte forma: – Uma subclasse herda as características de uma superclasse – Um superclasse generaliza as características comuns às subclasses

14 Notação UML - Herança Abaixo um exemplo da notação UML para a característica de herança: Equipamento nome: string Fabricante: string Peso: float Bomba pressaoSucao: float pressaoDescarga:float Tanque volume: float TanqueEsferico diametro: float TanqueTeto altura: float

15 Termos utilizados Ancestral é o termo que se refere a classe pai na hierarquia de classes Descendente é o termo que se refere a classe herdeira na hierarquia de classes Cada classe descendente herda os atributos e operações das classes ancestrais Geralmente não se recomenda um modelo de classes com muitas classes descendentes aninhadas, porque isto torna o modelo difícil de ser entendido.

16 Uso da Generalização A generalização tem 3 objetivos principais: – Dar suporte a operação de polimorfismo para aumentar a flexibilidade do software – Gerar uma estrutura de objetos que se encaixe nos requerimentos de sistema indicados pelo usuário – Permitir a reutilização de códigos, ou seja, você pode herdar uma funcionalidade que já foi desenvolvida anteriormente.

17 Enumerações Uma enumeração é um conjunto de dados que possui um conjunto finito de valores – Ex: tipo de linha: Sólida Tracejada Pontilhada Ao se projetar um sistema é necessário visualizar as possíveis enumerações, já que elas são importantes durante a fase de implementação (pois assim é possível criar uma lista representando o conjunto enumerado)

18 Enumerações – Notação UML A notação UML é descrita abaixo: Note que é necessário indicar todos os valores possíveis para o enumeration em questão. > TipoDeLinha solida tracejada pontilhada

19 Erros de modelagem Abaixo um erro muito frequente na modelagem de classes: Criar classes descedentes para cada valor possível de um conjunto finito dificulta a implementação e manuntenção do sistema > TipoDeLinha solida tracejada pontilhada Linha Solida Tracejada Pontilhada Errado Certo

20 Classe Abstrata Classe abstrata é uma classe que não pode ser instanciada por um objeto. Isto quer dizer que você não pode criar um objeto que referencie uma classe abstrata Classe concreta é uma classe que pode ser instanciada por um objeto A classe abstrata pode ser utilizada para definir métodos que precisam ser herdados pelas classes descendentes É possível se definir uma operação abstrata, ou seja, uma operação que precisa ser implementada pela classe descendente Criar classes descedentes para cada valor possível de um conjunto finito dificulta a implementação e manuntenção do sistema

21 Classe Abstrata – Notação UML A classe Trabalhador está em itálico e por isso é definida como uma classe abstrata A operação calcularCusto também está em itálico e é considerada uma operação abstrata Não se pode criar objetos a partir da classe Trabalhador, já que ela é uma classe abstrata É possível se criar objetos a partir das classes Pedreiro e Serralheiro As classes Pedreiro e Serralheiro são obrigadas a implementar a operação abstrata calcularCusto. A operação verificarSituacao não é uma operação abstrata e por isso, as classes Pedreiro e Serralheiro não a precisa implementar Trabalhador calcularCusto verificarSituacao PedreiroSerralheiro

22 Pacotes Quando o sistema a ser modelado possui um grande número de classes é interessante agrupar as classes com finalidades semelhantes. Para agrupar as classes podemos criar um pacote. O pacote nada mais é do que um artificio para organizar as classes de maneira que facilite o entendimento do modelo. A notação UML para pacotes é descrita abaixo: Pacote 2Pacote1 Neste pacote poderão estar disponíveis as classes responsáveis pelos cadastros básicos do sistema Neste pacote poderão estar disponíveis as classes responsáveis pelos cálculos financeiros do sistema

23 Dicas práticas Para facilitar a modelagem de classes é interessante mencionar algumas dicas práticas: – Escopo: Primeiro procure entender o problema do usuário antes de tentar modelar as classes – Simplicidade: O simples é belo. Tente simplificar o modelo, pois assim ele será melhor entendido e de mais fácil manutenção no futuro – Referências: Não coloque atributos referenciando objetos. Ao invés disso, modele as associações assim como descrevemos nesta aula – Layout do diagrama: Tente centralizar as principais classes no centro do diagrama de classes e evite o cruzamento de linhas, pois isto dificulta o entendimento do modelo – Generalização: Tente evitar generalizações aninhadas profundamente – Revisões: Solicite que outro projetista valide o seu modelo de classes e principalmente verifique se ele entendeu o modelo que você projetou – Enumerações: Identifique cuidadosamente as possíveis enumerações do sistema – Pacotes: Tente organizar as classes em pacotes. Isto facilitará o entendimento do modelo – Documentação: Documente o seu modelo de classes. Acredite!! Você mesmo precisará desta documentação

24 Dúvidas ?