Upload
buicong
View
214
Download
0
Embed Size (px)
Citation preview
Análise Orientada
a Objetos
Análise e Projeto
Análise versus Projeto
• Foco no entendimento do
problema
• Projeto idealizado
• Comportamento
• Estrutura do sistema
• Requisitos funcionais
• Modelos simples
• Foco no entendimento da
solução
• Operações e atributos
• Performance
• Pensamento no código
• Ciclo de vida de objetos
• Requisitos não-funcionais
• Modelo complexo
2010Análise e Projeto I 2
Análise e Projeto OO
• Durante a Análise
OO, a ênfase está
em achar e
descrever objetos
(ou conceitos) no
domínio do
problema
• Durante o projeto
OO, a ênfase está
em achar objetos
lógicos de software
que poderão ser
eventualmente
implementados
usando uma
linguagem OO
Análise e Projeto OO
Conceito
de domínio
public class Livro
{
public void imprimir();
private String titulo;
}
Representação
no código
• Exemplo: O conceito “Livro” em um sistema de biblioteca.
Livro
título
Representação
na análise
Livro
título
Representação
no projeto
imprimir()
Modelo de Analise e
Projeto
• A construção do modelo de análise e projeto é o principal objetivo desta disciplina
• O modelo de análise e projeto contém as realizações de casos de uso
• Pode ser particionado em dois modelos
– Modelo de Analise
– Modelo de Projeto
2010Análise e Projeto I 5
Realização de Caso de
Uso
2010Análise e Projeto I 6
Realização de Caso
de Uso
Caso de Uso
Diagramas de ColaboraçãoDiagramas de ColaboraçãoDiagramas de Classe Diagramas de Classe
Diagramas de SequênciaDiagramas de Sequência
Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto
Requisitos Analise e projeto
Análise Projeto Casos de Uso
Diag. Seq. de Eventos do Sistema
Modelo conceitual
Diagrama de Classes
Diag. Colaboração
Diag. sequências
ATIVIDADES DA ANÁLISE E
PROJETO
2010Análise e Projeto I 8
Analisar Arquitetura
• Construir e avaliar uma prova de conceito arquitetural
– Mostrar que existe uma solução possível de satisfazer os requisitos do sistema relevantes à arquitetura
2010Análise e Projeto I 9
Definir uma arquitetura
candidata
• Criar o esqueleto inicial da arquitetura do sistema
• Identificar classes de análise dos casos de uso arquiteturalmente relevantes
• Atualizar a realização de caso de uso com as interações entre classes de análise
2010Análise e Projeto I 10
Analisar o comportamento
• Transformar as descrições sobre o comportamento providas pelos caso de uso em um conjunto de elementos nos quais o modelo de projeto vai se basear
2010Análise e Projeto I 11
Projetar Componentes
• Refinar as definições dos elementos acrescentado detalhes sobre como estes elementos implementam o comportamento requerido
• Refinar e atualizar as realizações de casos de uso com os novos elementos identificados
2010Análise e Projeto I 12
Projetar Banco de Dados
• Identificar classes persistentes no modelo de projeto
• Projetar as estruturas de banco de dados (Modelo de dados)
• Definir mecanismos e estratégias para armazenar e recuperar dados
2010Análise e Projeto I 13
Refinar Arquitetura
• Permitir uma transição entre os elementos e mecanismos de análise para os de projeto
• Manter a consistência e integração da arquitetura
• Descrever a arquitetura de execução e produção da aplicação
2010Análise e Projeto I 14
ANÁLISE DE CASOS DE USO
16
Passos da Atividade de
Análise
• Identificar as classes
– Identificar persistência
• Identificar responsabilidades das classes
• Identificar relacionamentos
• Identificar atributos
17
Identificando as classes
• No primeiro passo de análise, identificaremos três tipos de classes:
– Fronteira
– Entidade
– Controle
• Tais classes são identificadas separadamente para cada de uso
18
Classes de Fronteira
• Utilizada para modelar a interação entre um ator e o sistema
• Para cada interação entre um ator e caso de uso, é criada uma classe de fronteira
• Possuem o estereótipo <<boundary>>
19
Classes de Entidade
• Utilizadas para modelar a informação manipulada pelo sistema
• Podem ser persistentes ou não
• Conceito análogo às entidades dos diagramas ER
• São identificadas a partir do fluxo de eventos do caso de uso
• Possuem o estereótipo <<entity>>
20
Classes de Controle
• Classes responsáveis por controlar o fluxo de execução do caso de uso
• Normalmente é criada uma classe de controle para cada caso de uso
• Possuem o estereótipo <<control>>
Exemplo
2010Análise e Projeto I 21
registrar faltas
registrar súmulas
das aulas
Professor
consultar freqüência
Aluno
editar alunos remover alunos
adicionar turma
remover turma
editar turma
Servidor de e-mailadicionar alunos
Secretária
Usuarioefetuar login
15/03/2005 21/28
2010Análise e Projeto I 22
Exemplo
2010Análise e Projeto I 23
Especificação de Casos de
Uso
• Efetuar Login
• Fluxo de eventos:
1. Usuário informa login e senha
2. Sistema checa se o login e senha conferem
3. Sistema registra a sessão do aluno e a tela principal do sistema é exibida
15/03/2005 23/28
login e senha
24
Exemplo
• Que classes preciso criar?
– uma classe de fronteira para lidar com a interação dos atores com o sistema
– uma classe de entidade para representar as informações relevantes do aluno
– uma classe de controle para gerenciar o fluxo de execução do caso de uso
25
Exemplo
ControladorLogin UsuarioTelaLogin
ControladorLogin
<<control>>
Usuario
<<entity>>
TelaLogin
<<boundary>>
• Há diferentes opções de visualização dos estereótipos. • A opção padrão é mostrada acima - os estereótipos são
visualizados através da mudança dos ícones das classes. • Há também a opção de se visualizar os estereótipos do modo
convencional (<<estereótipo>>).
26
Persistência
• Mas caso alguma classe de entidade precise ser persistente?
• Que classe será responsável por realizar as tarefas de persistência?
• Para cada classe de entidade que precise ser persistente, é criada uma nova classe com o estereótipo <<entity collection>>
27
Exemplo
TelaLogin
<<boundary>>
CadastroUsuarios
<<entity collection>>
ControladorLogin
<<control>>
Usuario
<<entity>>
28
Diagramas de interação
• Após a identificação das classes, é necessário descobrir quais são as responsabilidades de cada classe, o que cada uma precisa fazer.
• Os diagramas de interação (seqüência e colaboração) são muito úteis nesta tarefa
29
Exemplo
: usuário : TelaLogin : ControladorLogin : CadastroAlunos
efetuarLogin(login, senha)
efetuarLogin(login, senha)
checar(login, senha)
registrarSessao()
30
Alocando
responsabilidades
• Após identificarmos as responsabilidades (métodos) pelos diagramas de interação, devemos acrescentar os métodos nas classes previamente identificadas (1º passo)
31
Classes com métodos
32
Identificando
relacionamentos
• As classes identificadas não funcionam isoladamente, elas se relacionam com as demais classes
• Os diagramas de interação são muito úteis nesta tarefa
• Para cada ligação presente nos diagramas de interação, é necessário um relacionamento no diagrama de classes
33
Classes com
relacionamentos
34
Identificando Atributos
• Também é necessário identificar quais os atributos das classes
• Um bom conhecimento do domínio do problema é bastante importante para esta tarefa, principalmente na identificação de atributos das classes de entidade
• Nesta etapa ainda não precisamos indicar quais os tipos dos atributos
35
Diagrama final
36
Exemplo 2
Fluxo de eventos: 1. Secretária informa dados do aluno 2. Secretária seleciona a opção “confirmar cadastro” 3. Sistema checa se os dados são válidos 4. Sistema adiciona o aluno à base de dados 5. Sistema envia um e-mail para o aluno, informando-o seu login e senha 6. Sistema exibe uma mensagem de confirmação de cadastro Identificar as classes do caso de uso “adicionar aluno”
Secretária Servidor de e-mailadicionar alunos
FLUXO DE ANÁLISE E
PROJETO SIMPLIFICADO
Simplificando/Instanciando o processo para um contexto específico
Fluxo de atividades
simplificado
1. Analisar Arquitetura
2. Analisar Caso de Uso
3. Projetar Classes
4. Projetar Banco de Dados
2010Análise e Projeto I 38
ANALISAR ARQUITETURA
Analisar Arquitetura
• Esforço inicial em definir as partes do sistema e seus relacionamentos (Arquitetura Inicial)
• Definir as convenções de modelagem
• Identificar os mecanismos de análise
• Identificação das abstrações-chave
2010Análise e Projeto I 40
• A estrutura de um sistema de software, que engloba
– componentes de software;
– suas propriedades visíveis externamente;
– e os relacionamentos e interações entre eles
• As primeiras decisões tomadas no projeto de um sistema
– As mais importantes!
• Uma arquitetura de software é composta por componentes e conectores
Arquitetura de Software
Estilos
42
Padrões de Distribuição
• Ponto a ponto
• Cliente-servidor
– Cliente “gordo” (Fat Client)
– Servidor “gordo” (Fat Server)
– 3 camadas
– Cliente-servidor Distribuído
43
Ponto a ponto
44
Apresentação
Negócio
Dados
Apresentação
Negócio
Dados
Cliente-servidor 3 camadas
45
Apresentação
Negócio
Dados
Cliente “gordo”
46
Apresentação Negócio
Dados
Arquitetura Web Tradicional
47
Navegador Web
Apresentação Negócio
Dados
Clientes web (Mozilla, IE, etc.)
Servidor WEB Rede Local
Banco de Dados Relacional
Internet
Uma Arquitetura Web
Componente Componente Componente
Clientes web (Mozilla, IE, etc.)
Servidor WEB Internet Rede
Local
Banco de Dados Relacional
Uma Arquitetura Web
Banco de Dados Relacional
Conector (Ponte SQL)
Conector (HTTP, RMI)
Clientes web (Mozilla, IE, etc.)
Servidor WEB Rede Local
Internet
Uma Arquitetura Web
Arquitetura Inicial
• Quais as principais partes do sistema?
• Como elas interagem entre si?
• Que padrões arquiteturais utilizar (no todo ou internamente nas partes) ?
– MVC
– Baseado em camadas
– Canais e filtros
– Centrado em repositório
2010Análise e Projeto I 51
Exemplo de arquitetura
inicial
2010Análise e Projeto I 52
Interface Gráfica
Negócio
Dados
Módulo de Vendas
Módulo de Estoque
Socket
Convenções de
modelagem
• O que são? – Que diagramas e elementos de modelagem utilizar
– Definir as regras para utilização desses componentes
– Convenções de nome
• Exemplos – Casos de uso devem ser nomeados como ações
(Cadastrar usuário)
– Cada realização de caso de uso deve conter: • Um diagrama de classes
• No mínimo um diagrama de seqüência representando o fluxo principal de ações
2010Análise e Projeto I 53
Mecanismos de análise
• O que são? – Focam nos requisitos não-funcionais do
sistema
– Decisão estratégica sobre padrões, politicas e práticas a serem utilizadas no projeto
• Exemplos – Persistência
– Comunicação
– Gerenciamento de transações
– Segurança 2010Análise e Projeto I 54
Identificar Abstrações-
chave
• Definir classes de análise preliminares
– Conhecimento do domínio
– Requisitos
– Outros artefatos (Glossário e modelo de negócio)
2010Análise e Projeto I 55
ANALISAR CASO DE USO
Objetivos
• Identificar as classes que executam o fluxo de eventos do caso de uso
• Distribuir o comportamento do caso de uso nestas classes
• Identificar atributos, responsabilidades e associações das classes
2010Análise e Projeto I 57
Passo 1: Encontrar
classes de análise
• O comportamento do caso de uso é distribuído em classes de análise
2010Análise e Projeto I 58
Passo 2: Distribuir
comportamento
• Para cada fluxo de eventos
– Identificar classes de análise participantes
– Alocar responsabilidades do caso de uso às classes de análise
– Modelar interações entre as classes através dos diagramas de interação
2010Análise e Projeto I 59
Distribuindo
comportamento entre as
classes
2010Análise e Projeto I 60
Caso de uso
Diagrama de seqüência Diagrama de colaboração
Classes de análise
Classes de análise com
responsabilidades
Alocando
responsabilidades
• Use estereótipos de análise como guia – Classes de fronteira
• Comportamento que envolve comunicação com um ator
– Classes de entidade • Comportamento que envolve informação
encapsulada na abstração
– Classes de controle • Comportamento específico ao (lógica de controle
do) caso de uso
2010Análise e Projeto I 61
Guia: Alocando
responsabilidades
• Quem tem a informação necessária para realizar a responsabilidade
– isso pode envolver apenas uma classe, mas pode ser preciso criar novas classes ou relacionamentos entre classes
2010Análise e Projeto I 62
Modelando interações
• Diagramas de interação (colaboração e seqüência) modelam interações do sistema com seus atores
• A interação é iniciada por um ator e envolve instâncias (objetos) das classes
• Diagramas de interação capturam a semântica do fluxo de eventos do caso de uso – Auxiliam a identificar classes, responsabilidades e
relacionamentos
– Mecanismo de validação da arquitetura
2010Análise e Projeto I 63
Vários diagramas podem ser
necessários
2010Análise e Projeto I 64
Colaboração X Sequência
• Colaboração
– Mostra os
relacionamentos, além
das interações
– Melhor para visualizar a
colaboração
– Melhor de ser usado em
reuniões
• Sequência
– Mostra a sequência
explicíta de mensagens
– Melhor para visualizar o
fluxo
– Melhor para cenários
complexos
2010Análise e Projeto I 65
Passo 3: Descrever
Responsabilidades
• Atualizar os diagramas de classes com as responsabilidades identificadas no de iteração
• Mensagens nestes diagramas resultam em responsabilidades nas classes receptoras
2010Análise e Projeto I 66
Como fazer?
2010Análise e Projeto I 67
:Cliente :Fornecedor
// Executar responsabilidade
Fornecedor
// Executar responsabilidade
diagrama de
classe
diagrama de
interação
Gerenciando a
consistência
• Classes com responsabilidades similares são candidatas a serem combinadas
• Uma classe com responsabilidades disjuntas é candidata a ser dividida
• Classes sem (ou com apenas uma responsabilidade) e classes que interagem com muitas classes são candidatas a serem reexaminadas
2010Análise e Projeto I 68
Passo 4: Descrever
atributos e associações
• Definir atributos
• Estabelecer agregações e associações
2010Análise e Projeto I 69
Encontrando Atributos
• Possíveis fontes: conhecimento do negócio, requisitos, glossário, modelo do negócio, etc.
• São propriedades/características das classes identificadas – informação de propriedade exclusiva do objeto
– informação que pode ser lida ou escrita por operações, mas sem outro comportamento a não ser fornecer um valor
• Se a informação tem comportamento complexo ou é compartilhada, deve gerar uma classe
2010Análise e Projeto I 70
Encontrando
Relacionamentos
• Interações entre objetos nos diagrama de interação pode indicar a necessidade de definir um relacionamento entre as classes
• Adicionar os elementos de um relacionamento – Tipo e nome
– Navegabilidade
– Multiplicidade
– Papéis
2010Análise e Projeto I 71
Encontrando Relacionamentos
2010Análise e Projeto I 72
:Client :Supplier
Link
Supplier
PerformResponsibility()
Diagrama
de classe
Diagrama de
Colaboração
Association
Client Supplier
Client
1: PerformResponsibility
Prime suppliers
0..* 0..*
Passo 5: Qualificar
mecanismos de análise
• Mapear classes de análise em mecanismos de análise
2010Análise e Projeto I 73
Classes de análise Mecanismos de análise
Estudante Persistente
ControladorMatricula Distribuição, Segurança
Curso Persistente, Interface Legado
Passo 6: Unificar classes
de análise
2010Análise e Projeto I 74
Realização de Caso
de Uso
Diagramas de Classe Diagramas de Classe
…
Realização de Caso
de Uso
Diagramas de Classe Diagramas de Classe
…
Realização de Caso
de Uso
Diagramas de Classe Diagramas de Classe
…
Diagramas de Classe Diagramas de Classe
PROJETAR CLASSES
Objetivo
• Detalhar as partes do sistema
• Concretização dos conceitos definidos até o momento – Detalhes de implementação e ambiente de
produção • Produtos utilizados
• Linguagem de programação
• Distribuição
• Performance
• Restrições físicas
2010Análise e Projeto I 76
Passos do projeto de
classes
1. Criar classes de projeto
2. Identificar classes persistentes
3. Definir métodos
4. Definir atributos
5. Definir estados
6. Definir relacionamentos
7. Contemplar os requisitos não-funcionais
2010Análise e Projeto I 77
Para cada classe:
Passo 1: Criar classes de
projeto
• Converter classes de análise (Fronteira, Controle e Entidade) em classes de projeto
• Padrões de projeto podem ser incorporados
• As classes são refinadas para incorporar os mecanismos arquiteturais
2010Análise e Projeto I 78
Projetando classes de
fronteira
• GUI (Graphical User Interface) – Que ferramenta de desenvolvimento de
interface gráfica será utilizada?
– Quant pode ser criada pela ferramenta?
– Que padrões serão utilizados?
• Sistemas Externos – Que tecnologias/mecanismos de integração?
– Que padrões?
– Projetar como um subsistema…
2010Análise e Projeto I 79
Projetando classes de
entidade
• Classes de Entidade são
– Transitórias
– Persistentes
• São detalhadas no passo “Identificar classes persistentes”
2010Análise e Projeto I 80
Projetando classes de
controle
• Decisões que deve ser tomadas:
– Elas são realmente necessárias?
– Elas podem/devem ser agrupadas?
• Como decidir?
– Complexidade
– Operações relacionadas
– Probabilidade de mudar
– Performance e distribuição
2010Análise e Projeto I 81
Passo 2: Identificando
classes persistentes
• Instancias da classe precisam preservar o seu estado
• Estratégia de persistencia é definida para cada classe persistente
2010Análise e Projeto I 82
Curso BD Relacional
Candidato Arquivo
JDBC
Serialização
Passo 3: Definir Métodos
• Tem como propósito mapear responsabilidades identificada na análise para métodos na classe
• Deve-se considerar
– Nome, assinatura e visibilidade dos métodos
2010Análise e Projeto I 83
Mapeando operações
2010Análise e Projeto I 84
:Fornecedor :Cliente
// Realizar alguma operação
:Fornecedor :Cliente
fazerAlgo()
Projeto
Análise
+ concreto
- concreto
Passo 4: Definir Atributos
• Tem como propósito formalizar a definição dos atributos
• Deve-se considerar
– Persistência
– Visibidade, nome, tipo e valor inicial
2010Análise e Projeto I 85
Passo 5: Definir estado
• Tem como objetivo definir como o objeto se comporta
• Relevante apenas para objetos com ciclo de vida complexo
• Pode ser especificado em UML
– Diagrama de estados
– Diagrama de atividades
2010Análise e Projeto I 86
Diagrama de Estados
• Um diagrama de estados mostra o ciclo de vida de um objeto
2010Análise e Projeto I 87
Nome do estado Variavel: Tipo = valor
Ação de entrada Ação de saída Atividade
Evento(args)
[condição]
/ Operacao(args)
^obj.enviarMensagem(args) Estado
Ações
Atividades Transição
Exemplo de diagrama de
estado
2010Análise e Projeto I 88
Inicializado Aberto
Fechado
Cancelado
do: Incializa Curso
do: Finaliza curso
do: Notifica Alunos
Adiciona Aluno / contador = 0
Adiciona Aluno[ contador < 10 ]
[ contador = 10 ]
Cancela
Cancela
Cancela
Passo 6: Definir
Relacionamentos
• Dependências
• Associações
– Simples
– Agregação
– Composição
• Generalização
2010Análise e Projeto I 89
Passo 7: Contemplar os
requisitos não-funcionais
• Concretização dos mecanismos de análise – Incorporar responsabilidades em algumas classes
– Criar novas classes
• Exemplos: – Segurança Como armazenar as senhas? Que
algoritmo usar para criptografar uma mensagem?
– Distribuição Que tecnologia utilizar? Qual o impacto da tecnologia nos objetos já definidos?
– Tratamento de logs Que tipo de operações deve ter log (Acesso a dados, execução de negócio, …)
2010Análise e Projeto I 90
Projetar Banco de Dados
• Mapear as classes persistentes em conceitos do Banco de Dados
• Definir os tipos de dados mais adequados para o BD
• Normalizar se necessário
2010Análise e Projeto I 91
EXEMPLOS DE
ARQUITETURAS
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113