Orientação por Objectos
> Modelo de Processo OO
> Identificação de Classe e Objectos
Aula 12
Sumário

Conceitos e Princípios OO
–

Modelo de Processo OO
–
–

–
–
2
Exemplo de Processos dentro de uma Empresa
Modelo Recursivo / Paralelo
Identificação de Classes e Objectos
–

relevantes para o processo de desenvolvimento de SW
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
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:




Por que é importante?
–
3
Propriedades (atributos)
Comportamentos (Operações, Serviços ou Métodos)
Mensagens
porque os componentes de SW derivados do paradgma OO
mostram características associadas com SW de alta qualidade

Independência Funcional, Ocultação de Informação, etc.
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
4
Conceitos e Princípios OO

Análise Orientada por Objectos
–
Especificação, Casos de Utilização, Diagrama de Classes e de Objectos


Desenho OO
–
Diagramas de Interacção, de Actividades e de Estados

–

Identificam-se as Classes e Objectos relevantes no Domínio do Problema
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
5
– o que implica menos efeitos colaterais quando se fazem mudanças
Casos de Desenvolvimento de SW
6
Nenhum
dos outros modelos vistos pôde ser
utilizado isoladamente com sucesso para a OO
Modelo de Processo OO
(ou Modelo Recursivo-Paralelo)
Análise de Riscos
Identificar classes candidatas
Engenharia
e Construção
recursivo
(modelo evolutivo)
O
7
melhor paradigma deve ser um
modelo evolutivo de processo
acoplado com um enfoque que
fomenta a reutilização
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
paralelo
(reutilização de componentes)
Modelo Recursivo-Paralelo






8
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
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
–
–


9
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!
Sequencia típica de um Processo OO em
termos de actividades para o Plano de Projecto OO
planificação
análise
Revisão e
Refinamento:
desenho
análise
desenho
revisões, avaliações
do cliente e testes a
cada incremento
(…)
planificação análise
extrair
desenho classes
protótipo testes
reutilizáveis
análises
do
cliente
(…)
planificação análise
10
classes
desenho
protótipo testes
reutilizáveis
entrega
ao
cliente
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!
11
Identificação:
Formas de Manifestação

Entidades externas (outros sistemas, pessoas)
–

Coisas (cartas, apresentações, etc.)
–

que ocorrem dentro do contexto de uma operação do sistema
Papéis (director, engenheiro, vendedor, etc.)
–
12
que são parte do domínio de informação do problema
Ocorrências (acções que se repetem – ex. instalação)
–

que produzem ou consomem informação a ser usada pelo
sistema
desempenhados por pessoas que interagem com o sistema
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


Lugares (planta de produção, armazém de carga, etc.)
–
13
ou classes relacionadas de objectos
que estabelecem o contexto do problema e a função geral do
sistema
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?

–
–
Possui operações identificáveis que podem mudar o valor dos seus atributos?
Possui atributos múltiplos?

–
que são aplicáveis a todas as ocorrências do objecto
São entidades externas?

14
que são aplicáveis a todas as ocorrências do objecto
Possui operações comuns?

–
ou somente um atributo?
Possui atributos comuns?

–
ou seja, é um objecto persistente?
que produzem ou consomem informação do sistema?
Se qualquer uma das respostas for SIM, o objecto deve ser incluído no modelo
Finalizando a identificação


15
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
Boas Práticas de Desenvolvimento OO

Alta Coesão
–

Baixo Acoplamento
–

Os métodos tendem a manipular um número limitado de atributos
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

–

Reduz o acoplamento entre objectos tornando-os mais independentes
evitar Herança Múltipla
–
Pode dificultar a manutenção!

16
Por exemplo: o método desenhar() para classes gráficas..
–
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”
para a próxima semana…
Plano de Projecto de SW

Documento MS Word
–

Project Map
–

tutorial do MS Project
V.I.C.T.O.R.
–
18
modelo proposto para a Lacertae SW
assistente automatizado para “Gerenciamento de Projetos” elaborado
por uma empresa incubada na UFPE – Universidade Federal de
Pernambuco