Upload
rogerio-pc-do-nascimento
View
1.701
Download
0
Embed Size (px)
DESCRIPTION
Aula4 TEES UFS: Orientação a Objetos
Citation preview
Orientação por Objectos
> Modelo de Processo OO > Identificação de Classe e Objectos
Aula 4
2
Sumário
Actividades Básicas Independentes do Modelo Conceitos e Princípios OO
– relevantes para o processo de desenvolvimento de SW Modelo de Processo OO
– Exemplo de Processos dentro de uma Empresa– Modelo Recursivo / Paralelo
Identificação de Classes e Objectos– Análise Sintáctica Gramatical– Formas de Manifestação– Considerações que um Analista deve ter em mente
Boas Práticas para o desenvolvimento de SW OO
3
Actividades Básicas Independentesdo Modelo de Processos
adaptáveis a qualquer modelo de processo Exemplo que veremos na aula prática..
– actividades do Modelo Espiral Comunicação com o cliente Planeamento Análise do risco Actividades de Engenharia Construção e Entrega Avaliação do Cliente
Convém estabelecer um conjunto de actividades básicas para desenvolverem durante toda a semana
Nas aulas práticas, faremos o ponto da situação.
4
Espiral de BoehmComunicação com o cliente
Planeamento
Engenharia
Análise de riscos
Construçãoe adaptação
Avaliação do cliente
5
Exemplo:Comunicação com o Cliente
Projecto pequeno1. Desenvolver lista de aspectos a
esclarecer
2. Reunião com o cliente
3. Determinar conjuntamente âmbito do projecto
4. Revisão do âmbito com todos os envolvidos
5. Modificar o âmbito quando requerido
Projecto complexo1. Revisar pedido do cliente2. Planear e programar reunião formal3. Definir soluções propostas e
enfoques existentes4. Preparar documentos de trabalho e
agenda reunião5. Realizar reunião6. Desenvolver conjuntamente mini-
especificações que reflectem as características do software
7. Revisar mini-especificações8. Integrar mini-especificações num
documento de alcance do projecto9. Revisar o documento de alcance10. Modificar o documento de alcance
quando requerido
6
Selecção do modelo
Deve haver flexibilidade na escolha Projectos pequenos: ciclo clássico Limites severos de tempo: DRA Data entrega muito próxima: modelo
incremental
Os modelos vistos até agora não são, por si só, suficientes para o sucesso de projectos
baseados no Paradigma Orientado a Objectos
7
Conceitos e Princípios OO
Quem define os objectos?– o Engenheiro de Software
O que implica a definição de objectos?– a descrição de:
Propriedades (atributos) Comportamentos (Operações, Serviços ou Métodos) Mensagens
Por que é importante?– porque os componentes de SW derivados do paradigma OO
mostram características associadas com SW de alta qualidade
Independência Funcional, Ocultação de Informação, etc.
8
Conceitos e Princípios OO
Quais são os passos?– AOO, DOO, Implementação e Testes
Qual é o produto obtido?– produz-se um conjunto de Modelos Orientados por Objectos
ou Diagramas, ou bonecos ;)
Estes diagramas descrevem o(s):– Requisitos (Documento de Especificação)– Desenho– Código– Processos de Testes
… para o desenvolvimento de um Sistema ou Produto OO
9
Conceitos e Princípios OO
Análise Orientada por Objectos– Especificação, Casos de Utilização, Diagrama de Classes e de Objectos
Identificam-se as Classes e Objectos relevantes no Domínio do Problema
Desenho OO– Diagramas de Interacção, de Actividades e de Estados
aqui descrevem-se detalhes sobre a arquitectura, as interfaces e os componentes
– a implementação “transforma” o Desenho em Código Testes OO
– os testes corroboram a arquitectura, as interfaces e os componentes
O software OO é mais fácil de manter porque sua estrutura é pouco acoplada
– o que implica menos efeitos colaterais quando se fazem mudanças
10
Casos de Desenvolvimento de SW
11
Modelo de Processo OO(ou Modelo Recursivo-Paralelo)
O melhor paradigma deve ser um modelo evolutivo de processo acoplado com um enfoque que
fomenta a reutilização
Nenhum dos outros modelos vistos pôde ser utilizado isoladamente com sucesso para a OO
Identificar classes candidatas
recursivo(modelo evolutivo)
paralelo(reutilização de componentes)
buscar classes na biblioteca
extrair classes, se existem
desenvolver novas classes, se não existem
adicionar novas classes à biblioteca
construir n-ésima iteração do sistema
Análise de Riscos
Engenhariae Construção
12
Modelo Recursivo-Paralelo
Realizar a análise suficiente para isolar as classes do problema e as conexões mais importantes
Realizar um pequeno desenho para determinar se as classes e as conexões podem ser implementadas de maneira prática
Extrair objectos reutilizáveis de uma biblioteca para construir um protótipo prévio
Conduzir alguns testes para descobrir erros no protótipo
Obter retro-alimentação do cliente sobre o protótipo Modificar o modelo de análise baseando-se na Análise,
no Desenho e no Cliente
13
Modelo Recursivo-Paralelo
Refinar o Desenho para acomodar as mudanças Construir objectos especiais (não disponíveis na biblioteca)
Montar um novo protótipo usando– Objectos da biblioteca– Novos objectos
Realizar provas para descobrir erros Obter retro-alimentação do cliente sobre o protótipo
- Este enfoque continua até o protótipo evoluir para uma aplicação em produção!
14
Sequencia típica de um Processo OO em termos de actividades para o Plano de Projecto OO
planificação
testesextrair
classes reutilizáveis
análise desenho
protótipo
análise desenho
planificação análise desenhoanálises
docliente
(…)
testesclasses
reutilizáveisprotótipoplanificação análise desenho
entregaao
cliente
Revisão e Refinamento:
revisões, avaliações do cliente e testes a cada incremento
(…)
15
Identificação de Classes e Objectos
Análise Sintáctica Gramática– Sublinhar os substantivos do texto
da narrativa do processo ou da Descrição do Âmbito do Sistema
– Descartar os sinónimos
Um objecto nunca deve ser uma forma verbal!
16
Identificação: Formas de Manifestação
Entidades externas (outros sistemas, pessoas)– que produzem ou consomem informação a ser usada pelo
sistema
Coisas (cartas, apresentações, etc.)– que são parte do domínio de informação do problema
Ocorrências (acções que se repetem – ex. instalação)– que ocorrem dentro do contexto de uma operação do sistema
Papéis (director, engenheiro, vendedor, etc.)– desempenhados por pessoas que interagem com o sistema
17
Identificação: Formas de Manifestação
Unidades Organizacionais (divisão, grupo, equipa)– Relevantes numa organização
Estruturas (sensores, veículos de 4 rodas, etc.)– que definem uma classe de objectos
ou classes relacionadas de objectos
Lugares (planta de produção, armazém de carga, etc.)– que estabelecem o contexto do problema e a função geral do
sistema
18
Identificação: Considerações para os Analistas
Como saber se um objecto deve ser incluído (ou não) no Modelo de Análise OO? – Perguntem-se:
– A informação acerca dele deve ser lembra? ou seja, é um objecto persistente?
– Possui operações identificáveis que podem mudar o valor dos seus atributos?– Possui atributos múltiplos?
ou somente um atributo?
– Possui atributos comuns? que são aplicáveis a todas as ocorrências do objecto
– Possui operações comuns? que são aplicáveis a todas as ocorrências do objecto
– São entidades externas? que produzem ou consomem informação do sistema?
Se qualquer uma das respostas for SIM, o objecto deve ser incluído no modelo
19
Finalizando a identificação
Alguns objectos descartados serão atributos dos objectos seleccionados
Durante as iterações do Modelo de Processo OO (Modelo Recursivo-Paralelo) podem ser adicionados outros novos objectos
20
Boas Práticas de Desenvolvimento OO
Alta Coesão– Os métodos tendem a manipular um número limitado de atributos
Baixo Acoplamento– A classe tem pouca comunicação com outros elementos do sistema
porque a comunicação ocorre (internamente) somente através de métodos declarados
Polimorfismo– Permite que operações diferentes tenham o mesmo nome
Por exemplo: o método desenhar() para classes gráficas..– Reduz o acoplamento entre objectos tornando-os mais independentes
evitar Herança Múltipla– Pode dificultar a manutenção!
Em geral, complica a hierarquia da classe e cria problemas potenciais no controle da Configuração (veremos no projecto)
– É mais coerente especializar (gerar) uma nova classe “filha”