A funcionalidade externa de um sistema OO é fornecida através de colaborações entre objetos

(1)

Análise Orientada a Objetos

FIR – Faculdade Integrada do Recife

João Ferreira

joaoferreira@fir.br

Agenda da Aula

Introdução

Análise Orientada a Objetos

– Análise Arquitetural – Análise de Casos de Uso – Análise de Classes

Identificação Dirigida a

Responsabilidades

Padronizando a Nomenclatura

Introdução

O Modelo de Casos de Uso fornece uma perspectiva do sistema a partir de um ponto de vista externo

Os desenvolvedores precisam prosseguir no desenvolvimento do sistema

Introdução

A funcionalidade externa de um

sistema OO é fornecida através de

colaborações entre objetos

– Externamente

• Atores visualizam resultados de cálculos, relatórios produzidos, confirmações de requisições realizadas, etc.

– Internamente

• Objetos colaboram uns com os outros para produzir os resultados que são visíveis de fora

Introdução

Uma colaboração pode ser vista sob 2 aspectos

– Aspecto Dinâmico

• Descreve a troca de mensagens entre objetos e a sua reação a eventos que ocorrem no sistema

– Aspecto Estrutural Estático

• Permite compreender como o sistema está estruturado internamente

– Estrutural, pois seu foco encontra-se na representação da estrutura das classes e nas relações entre estas – Estático, pois não apresenta informações sobre as

interações dos objetos no decorrer do tempo

Análise Orientada a Objetos

Objetivo

– Entender mais precisamente os requisitos e definir o modelo de classes/objetos

(2)

Atividade: Análise Arquitetural

– Sumarizar o modelo de análise e arquitetura – Identificar

• Pacotes de análise • Pacotes de caso de uso • Classes de entidade óbvias

Atividade: Análise Arquitetural

Passo 1: Identificar pacotes de análise e agrupar casos de uso

– UCs necessários para realizar um dado processo de negócio

(ex: pacote de serviços de matrícula e histórico)

– UCs necessários e relacionados a um ator específico do sistema

– UCs relacionado a uma dada entidade

(ex: pacote de aluno que contém os caso de uso “Inserir Aluno”, “Alterar Aluno”, “Consultar Aluno” e “Remover Aluno”

Dentro de cada pacote de análise deve-se agrupar casos de uso do sistema de acordo com o(s) critério(s) escolhidos

Atividade: Análise Arquitetural

Passo 2: Identificar classes e entidades “óbvias”

– Representam alguma informação do domínio do sistema e que é usualmente persistente

– Conceitos/objetos/eventos/indivíduos pertencentes ao mundo real e relacionado ao domínio modelado – Exemplos: classes Aluno, Professor Funcionário,

Matrícula, Histórico para um Sistema de Matrícula – Este passo consiste em identificar as principais

classes de entidade do sistema partindo

principalmente da especificação dos UCs definidos no fluxo de requisitos

Atividade: Análise Arquitetural

Passo 2: Identificar classes e entidades “óbvias” (continuação)

– Não é necessário se preocupar em identificar todas as classes de entidade existentes, mas apenas as mais óbvias.

– A próxima atividade “Analisar Casos de Uso” identificará todas as classes de entidade necessárias para os casos de uso

Atividade: Analisar Casos de Uso

Objetivos

– Identificar as classes de análise das quais serão criados objetos para atender os fluxos de eventos de cada caso de uso

– Distribuir o

comportamento do caso de uso para objetos de análise que interagem entre si

Atividade: Analisar Casos de Uso

Passo 1: Identificar classes de análise

– Neste passo, são identificados os diferentes tipos de classes de análise necessárias para realizar os casos de uso

– A principal fonte de informação é a especificação detalhada de UC (doc. de requisitos)

• e, quando houver, o modelo de domínio

(3)

Atividade: Analisar Casos de Uso

Tipos de Classes de Análise

– Classe Fronteira <<boundary>>

– Classe de Controle <<control>>

– Classe de Entidade <<entity>>

Atividade: Analisar Casos de Uso

Classe Fronteira <<boundary>>

– Modela interações entre os atores e o sistema.

• Receber, enviar ou apresentar alguma informação

– Para cada ator existirá no mínimo uma classe fronteira para permitir a interação com o sistema.

• Uma classe de fronteira pode ser usada para interação entre mais de um tipo de ator e o sistema

Atividade: Analisar Casos de Uso

Exemplo de classe Fronteira para o caso

de uso “Inserir Aluno”

Atividade: Analisar Casos de Uso

Classe de Controle <<control>>

– Responsáveis pela coordenação e gerenciamento do UC.

– Modelam cálculos, processamentos, verificações que devem ser realizadas para caracterizar a lógica de negócio do sistema

Dois tipos

– Controlador: intermediar a comunicação de objetos de classes fronteira com objetos de controle “cadastro”;

– Cadastro: manipular(inserir, remover, consultar e alterar) objetos de alguma classe entidade (Aluno, Professor, Disciplina)

Atividade: Analisar Casos de Uso

Classe de Entidade <<entity>>

– Representa a abstração da informação que é manipulada/ processada pelo caso de uso – Normalmente derivada do próprio domínio

(mundo real) onde o sistema se insere – É importante não confundir um atributo de

classe entidade com a própria classe entidade

• Exemplo: nomeAluno, cpf não é uma classe entidade, e sim um atributo da classe entidade Aluno

Atividade: Analisar Casos de Uso

(4)

Atividade: Analisar Casos de Uso

Passo 1: Identificar classes de análise (cont.) Guia Geral para identificação de classes de análise:

– Identificar classes que representam a informação processada pelo UC

– Identificar classes fronteira relacionadas a interface gráfica do sistema, uma para cada Ator interagindo com o UC. Esta classe de fronteira representa a tela principal com a qual o ator interagirá com o sistema

– Identificar uma classe de controle geral responsável pela coordenação e gerenciamento global do UC

Atividade: Analisar Casos de Uso

Guia Geral para identificação de classes de análise:

– Identificar uma classe de fronteira central para cada que representa um sistema externo que interaja com o sistema.

• A idéia central desta classe é encapsular mecanismos/ meios de comunicação entre o sistema sendo desenvolvido e o sistema externo

– Identificar uma classe de controle geral responsável pela manipulação de um conjunto de entidades da mesma classe.

• Está classe será denominada CadastroX, onde X é a entidade que a classe de controle manipula (ex: CadastroAluno, CadastroProfessor)

Atividade: Analisar Casos de Uso

Passo 2: Descrever interações entre

objetos de análise

– Construir diagramas de seqüência que descrevam as interações necessárias entre objetos de análise para realizar o caso de uso

– Para cada caso de uso, construir um diagrama de seqüência que reflita o seu fluxo principal e, se necessário, construir diagramas de seqüência para cada um dos fluxos alternativos.

Atividade: Analisar Casos de Uso

Passo 2: Descrever interações entre

objetos de análise (cont.)

– Fluxos de exceções podem ser representados como notas UML nos próprios diagramas de seqüência dos fluxos principal e alternativos

– Cada diagrama deve ser criado a partir de passos iniciais de cada fluxo e seguido por cada um dos passos. Para o atendimento de cada passo do caso de uso deve-se decidir que objetos de análise precisam interagir para sua realização

Atividade: Analisar Casos de Uso

Dicas para a construção de diagramas de seqüência

– O passo inicial do diagrama é normalmente uma instância de um ator solicitando algo para um objeto de uma classe fronteira

– Cada classe de análise identificada para o UC deve ter no mínimo um método sendo chamado durante a execução de um dos fluxos do UC. Caso contrário, ela se torna desnecessária

– Os links no diagrama de colaboração normalmente caracterizam relações de associação ente classes de análise

Atividade: Analisar Casos de Uso

(5)

Atividade: Analisar Classes

Objetivos:

– Identificar as

responsabilidades (serviços/métodos) – Identificar os atributos

e relações de cada classe de análise

Atividade: Analisar Classes

Passo 1: Identificar Métodos

– Os métodos de cada classe de análise podem ser obtidos através da investigação dos diagramas de interação obtidos na atividade “Analisar Casos de Uso”. Cada mensagem recebida por um objeto de análise caracteriza um método de uma classe

– Identifique apenas os métodos das classes do tipo <<controle>> e <<entidade>>, não necessitando realizar tal passo para as classes de análise do tipo <<fronteira>>

Atividade: Analisar Classes

Passo 2: Identificar Atributos

– Neste passo, serão identificados atributos principalmente para as classes do tipo <<entidade>>

– Atributos de uma classe que tenham uma relação bastante forte entre si e

representem algum conceito podem (e deve) ser representados como uma nova classe

• Ex: classe “Endereço” de um “Aluno”

Atividade: Analisar Classes

Passo 2: Identificar Atributos (cont.)

– Não é necessário especificar

detalhadamente os tipos de cada atributo nesta etapa de Análise

– Classes <<fronteira>> para outros sistemas externos podem ter como atributos algum mecanismo de comunicação

Atividade: Analisar Classes

Passo 3: Identificar Associações e Agregações

– As associações e agregações entre classes podem ser obtidas a partir do diagrama de colaboração (obtido a partir do diagrama de seqüência construído em “Analisar Casos de Uso”)

– Nem toda ligação entre objetos de análise em um diagrama de colaboração, ocasionam uma associação ou agregação, algumas delas podem ser apenas relação de dependência

– Idealmente o número de relações entre classes deve ser minimizado para evitar um forte acoplamento do sistema

Atividade: Analisar Classes

Passo 3: Identificar Associações e Agregações (cont.)

– Recomenda-se definir os nomes e multiplicidade nas relações

– Relações de agregação podem ser criadas nos seguintes casos

• Conceito que fisicamente contém um ao outro (ex: carro que contém um motorista e passageiros)

• Conceito composto de um conjunto de outros (carro que consiste de um motor e pneus)

(6)

Agregação X Composição

(Agregação)

(Composição)

Atividade: Analisar Classes

Passo 4: Identificar Generalizações

– Relações de generalização podem ser definidas entre classes de análise para expressar comportamento comum e compartilhado entre classes de análise, principalmente entre classes do tipo <<entidade>>

– Expressam reuso e extensão entre classes – Visam facilitar o entendimento do modelo de

análise

Classes de Análise

Identificando Classes de Análise

...

– Um SW OO é composto de objetos que colaboram entre si

– Por outro lado, todo objeto pertence a uma classe

– Portanto, quando se fala na identificação das classes, o objetivo na verdade é saber as características e comportamentos dos objetos que irão compor as classes do SW

Identificando Classes de Análise

2 métodos para identificação de classes

– Método dirigido a dados

– Método dirigido a responsabilidades

Identificando Classes de Análise

Método dirigido a dados

– Identificação da estrutura dos conceitos relevantes para um domínio de negócio – Tem-se como resultado um modelo

(7)

Identificando Classes de Análise

Método dirigido a responsabilidades

– Identificação de classes a partir de seus comportamentos externos relevantes para o sistema

– Enfatiza o encapsulamento da estrutura e o comportamento dos objetos

– Os detalhes internos (“como”) devem ser abstraídos

– O esforço recai sobre a identificação das responsabilidades que cada classe deve ter

Identificação dirigida a responsabilidades

Responsabilidades e colaboradores

– O comportamento de um objeto é definido de tal forma que ele possa cumprir com suas responsabilidades

– Uma responsabilidade é uma obrigação que um objeto tem para com o SW no qual ele está inserido

• Através delas, um objeto colabora com outros para que os objetivos do SW sejam alcançados

Responsabilidades e colaboradores

– Na prática, uma responsabilidade é alguma coisa que um objeto conhece ou faz (sozinho ou não)

• Um objeto Cliente conhece seu nome, seu endereço, seu telefone

• Um objeto Pedido conhece sua data de realização e sabe fazer o cálculo do seu total

Responsabilidades e colaboradores

– Se um objeto tem uma responsabilidade com a qual não pode cumprir sozinho, ele deve requisitar colaborações de outros objetos

• É a troca de mensagens que os objetos colaboram entre si

Exemplo:

– A impressão de uma fatura é requisitada em um sistema de vendas, vários objetos precisam colaborar:

• Um objeto Pedido pode ter a responsabilidade de fornecer o seu valor total

• Um objeto Cliente fornece seu nome. • Cada ItemPedido informa a quantidade

correspondente e o valor de seu subtotal • Os objetos Produto também colaboraram

fornecendo seu nome e preço unitário.

Categorias de Responsabilidades

(8)

Categorias de Responsabilidades

Divisão de responsabilidades

– Cada objeto é especialista em realizar de um entre os 3 tipos de tarefas

• Se comunicar com atores (fronteira) • Manter as informações do sistema (entidade) • Coordenar a realização de um caso de uso

(controle)

Divisão de responsabilidades

– A importância dessa categorização está

relacionada à capacidade de adaptação do sistema a eventuais mudanças

– Se cada objeto possui funções específicas dentro do sistema, eventuais mudanças no sistema tendem a ser

• Menos complexas • Mais localizadas

– Uma eventual modificação em uma parte do sistema tem menos possibilidades de resultar em mudanças em outras partes

Divisão de responsabilidades

Classes de Controle Mudanças em funcionalidades

complexas (lógica do negócio)

Classes de Entidade Informações manipuladas pelo

sistema

Classes de Fronteira Interface gráfica, comunicação

com outros sistemas

Onde Alterar Tipo de Mudança

Divisão de responsabilidades

– Exemplo: vantagem de separação de responsabilidades em um sistema para uma loja de aluguel de carros.

• Se o sistema tiver que ser atualizado para que seus usuários possam utilizá-lo pela Internet, a lógica da aplicação não precisaria de modificações.

• Se o sistema tiver que atualizar a lógica para calcular o bônus acumulado pelas locações mensais feitas por um cliente, então, se esta lógica estiver encapsulada em uma classe de controle, somente esta classe precisaria de modificação.

Atenção:

– A separação das responsabilidades além de ajudar no desacoplamento entre elementos do SW, facilita também o reuso dos objetos no desenvolvimento de SW semelhantes.

Fronteira

(9)

Modelo de Classes

O diagrama da UML utilizado para

representar o aspecto estático é o

diagrama de classes.

– O modelo de classes é composto desse diagrama e de alguma descrição textual associada.

Assim como outros modelos, o modelo

de classes evolui durante o

desenvolvimento do sistema.

– À medida que o sistema é desenvolvido, o modelo de classes é incrementado com novos detalhes.

Padronizando a Nomenclatura

É fortemente recomendado que se

padronize a nomenclatura a ser utilizada

para os elementos do modelo de classes

Sugestão de padronização

– Para nomes de identificadores (regra geral)

• Remover qualquer espaço em branco, preposição, artigo, acento ou caracter especial • Ex: OrdemPedido, obterTotal(), precoUnitario, ...

Padronizando a Nomenclatura

– Para nomes de classes e de relacionamentos

• Iniciar as palavras com letra maiúscula • Ex: Cliente, ItemPedido, Pedido, OrdemPedido

– Para nomes de propriedades (Atributos) e operações (Métodos)

• A primeira palavra inicia com letra minúscula, as demais com letras maiúsculas