Engenharia de Software Orientada a Objetos

Apresentação em tema: "Engenharia de Software Orientada a Objetos"— Transcrição da apresentação:

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

2 Agenda Modelagem Os 3 modelos de Rumbaugh e Blaha
Conceitos de Objetos e Classes Diagrama de Classe Conceitos de Ligação e Associação

3 Modelagem Modelo: é uma abstração de algo com finalidade de entender antes de implementar. Sistemas complexos necessitam de modelos para serem melhor compreendidos. O objeto da modelagem é transformar o modelo em uma implementação correta para resolver o problema.

4 Modelagem O mundo real está cercado de vários modelos, tais como: modelos para testes em túnel de vento, desenho de peças, planta de imóveis, etc. Os modelos tem várias finalidades: Testar uma entidade física antes de implementá-la Comunicação com os clientes Visualização prévia da solução final Redução da complexidade

5 Os 3 modelos Para modelar um sistema O.O., Rumbaugh e Blaha propõem 3 pontos de vista distintos: Modelo de Classes: representa os aspectos estáticos da aplicação (estrutura de dados) e seus relacionamentos Modelo de Estados: representa os comportamentos de controle em função do tempo Modelo de Interações: representa a colaboração entre os objetos

6 Modelos de Classes Descreve a estrutura dos objetos em um sistema, ou seja: Sua Identidade Seus atributos Suas operações Seus relacionamentos com outros objetos (herança, associação) O modelo de Classes fornece a base necessária para os diagramas de Estados e Interações

7 Modelos de Estados Descreve o comportamento dos objetos em função do tempo, ou seja, a sequencia de como o objeto se interage na aplicação. O objetivo deste tipo de modelo é descrever a sequencia de estados e eventos. Ações e eventos em um modelo de estados tornam-se operações sobre os objetos do modelo de classes.

8 Modelos de Interações Descreve as interações entre os objetos individuais para atender aos requerimentos do sistema. O objetivo deste tipo de modelo é descrever a sequencia temporal dos objetos em comum. Aqui serão aplicados diagramas de sequência, diagramas de atividades.

9 Modelagem de Classes

10 Modelagem de Classes Captura a estrutura estática do sistema (objetos), o relacionamento entre esses objetos, assim como atributos e operações pertinentes ao processo informado pelo usuário do sistema. Este é o modelo mais importante dos 3 modelos citados. Os modelos de classes fornecem uma representação gráfica intuitiva que facilita a compreensão do escopo do sistema.

11 Conceitos de Objetos Um objeto é conceito, abstração ou coisa que possui uma identidade e possui um significado dentro do sistema Geralmente os objetos são identificados por nomes próprios (substântivos) ou referências específicas nas descrições de problemas ou reuniões com os usuários. Basicamente um objeto pode ser introduzido em um modelo por 3 razões: Correspondem ao cenário que o sistema está tentando mapear (ex: Clientes, Fornecedores, Produtos) São entidades conceituais necessárias (ex: objeto para resolver uma equação de segundo grau, objeto para resolver um cálculo matemático complexo) São introduzidos por razões de implementação ( ex: objeto para imprimir uma nota fiscal num formulário pré-impresso)

12 Conceitos de Objetos A escolha dos objetos depende do julgamento e da natureza de um problema Podem existir várias representações corretas, ou seja, para um mesmo sistema podem existir diversas maneiras corretas para se representar os objetos A principal característica de um objeto é a sua identidade, ou seja, a capacidade de se distinguir de outros objetos. Ex: Duas maças com mesma cor, forma, textura. Uma pessoa pode comer uma das maçãs e deixar a outra para comer depois. Desta forma, as maças apesar de possuirem características semelhantes são consideradas objetos distintos.

13 Conceitos de Classes Uma classe descreve objetos com atributos ,operações e tipos de relacionamentos semelhantes. Ex: Pessoa, Empresa, Processo (Veja abaixo o destaque destas 3 possíveis classes) Cada Pessoa possui um nome, data de nascimento e pode trabalhar em um Cargo de uma Empresa. Cada Processo tem um proprietário (que é uma Pessoa), uma prioridade, uma lista de recursos exigidos. Conforme exemplo acima, é possível enxergar que as classes são originadas a partir de frases e conversas realizadas com os usuários do sistema. A escolha das classes depende da natureza da aplicação e também do critério do projetista. Desta forma, poderão existir diversas representações de classes para um mesmo problema.

14 Conceitos de Classes Em uma linguagem de programação podemos determinar que um objeto é uma representação de uma determinada classe A classe é uma propriedade implicíta de um objeto. Quando um objeto é criado no sistema, é possível saber a qual classe o mesmo se refere. E para tratar isso, cada linguagem de programação tem sua própria maneira de tratamento. Se os objetos são o foco da modelagem, porque então se preocupar com as classes? Porque agrupando os objetos em classes estaremos abstraindo o problema e a abstração dá a modelagem o poder de generalizar, ou seja, o poder de compartilhar atributos e operações.

15 Diagrama de Classes Para que possamos modelar um sistema precisamos de uma representação gráfica. Para padronizar nossa representação gráfica precisamos de um padrão. Um padrão muito divulgado no meio científico são os diagramas UML. Existe um diagrama UML específico para o tratamento de classes: o diagrama de classes. Os diagramas de classes oferecem uma notação gráfica para modelar classes e seus relacionamentos, descrevendo assim os possíveis objetos. A principal vantagem é que eles são fáceis de entender, possibilitando que o próprio usuário do sistema opine sobre o modelo.

16 Diagrama de Objetos Em algumas situações também poderemos utilizar o diagrama de objetos. Este diagrama mostra os objetos individuais instanciados e seus relacionamentos. Estes tipos de diagramas são mais utilizados para documentar casos de testes de sistema. No entanto, podemos citar que estes diagramas são pouco utilizados em um projeto de um sistema.

17 Notação Gráfica - UML Abaixo a notação gráfica sugerida para um diagrama de classes. Abaixo a notação gráfica sugerida para um diagrama de objetos. Pessoa JoãoDaSilva:Pessoa

18 Valores e Atributos Valor é um elemento dos dados
Atributo é uma propriedade nomeada de uma classe Exemplos: Nome, data de nascimento são atributos da classe Pessoa “João da Silva” é o valor do atributo nome para um objeto da classe Pessoa “30/12/1988” – é o valor do atributo data de nascimento para um objeto da classe Pessoa

19 Notação Gráfica - UML Abaixo a notação gráfica sugerida para um atributo no diagrama de classes. Abaixo a notação gráfica sugerida para um atributo no diagrama de objetos. Pessoa nome: string dataNascimento: Date JoãoDaSilva:Pessoa Nome=“João da Silva” dataNascimento=“30/12/88”

20 Identificação de um objeto
Em alguns casos de implementação é necessário que o objeto tenha um ID para sua identificação. Ex: “João da Silva = ID 12029”, “Maria = ID 12030”, etc. O importante aqui é que em um modelo de classes, o ID do objeto é implicíto e desta forma, não precisa ser indicado.

21 Notação Gráfica - UML Sempre lembrar que não devemos indicar os identificadores dos objetos no modelo de classes, conforme pode ser observado abaixo: Pessoa IDPessoa: ID nome: string dataNascimento: Date Pessoa nome: string dataNascimento: Date Certo Errado

22 Visibilidade de um atributo
Indica que um atributo pode ou não ser visível em determinadas situações. Neste contexto um atributo pode ter os seguintes níveis de visibilidade: Público: o atributo é sempre visível Privado: o atributo somente poderá ser visualizado dentro de métodos da própria classe Protegido: o atributo somente poderá ser visualizado dentro de metódos da própria classe e também das classes descendentes

23 Notação Gráfica - UML Abaixo a notação gráfica UML destacando a visibilidade dos atributos. Símbolos utilizados: “+” Público “-” Privado “#” Protegido Neste exemplo, o atributo nome é publico, o atributo dataNasc é privado e o atributo endereco é protegido. Pessoa + nome: string dataNasc: Date # endereco: string

24 Operações Operação é uma função ou procedimento que pode ser aplicada a classe: Ex: Contratar, Demitir, PagarConta, etc. Um método é uma implementação de uma operação: void Contratar(Empregado emp) Assinatura de um método é a maneira pela qual o método é implementado: void Contratar(Empregado emp) >> [Assinatura 1] void Contratar(Empregado emp, bool cond) >> [Assinatura 2]

25 Notação Gráfica - UML Abaixo a notação gráfica UML destacando a inserção de métodos nos modelos. Pessoa nome: string dataNasc: Date endereco: string mudarCargo(): void mudarEndereço():void Atributos Métodos

26 Visibilidade de um método
Assim como um atributo, é possível definir a visibilidade de um método (público, privado, protegido) Abaixo a notação UML para visibilidade: Pessoa + nome: string - dataNasc: Date # endereco: string + mudarCargo():void - mudarEndereço():void

27 Dúvidas ?