Analise e Projeto
Orientado a Objetos –
APS II
Prof. Isledna
Objetivos
• Apresentar um método para análise e
projeto de sistemas orientado a
objetos, baseado na abordagem do
Processo Unificado (PU).
O que vamos fazer ?
• Usaremos a linguagem UML (Unified
Modeling Language) para criar modelos (de
análise e de projeto)
– Um modelo é uma representação abstrata dos
aspectos essenciais de um sistema
– O que é "essencial" depende do momento da
modelagem
– A UML usa uma representação principalmente
gráfica para representar os modelos
– UML é muito popular hoje em dia para modelar
sistemas
O que vamos fazer ?
• Usaremos Design Patterns (padrões de
projeto) para mostrar soluções abstratas
para problemas que surgem
frequentemente durante o projeto de
sistemas OO
– Os patterns tratarão principalmente de:
• Como atribuir responsabilidades a objetos (uma das
atividades mais difícil no desenvolvimento de
sistemas OO)
• Como separar o que muda do que é constante numa
determinada situação, com o objetivo de ganhar
flexibilidade
– Para evitar "o efeito gelatina"
O que vamos fazer ?
• Explicaremos e seguiremos um
processo de desenvolvimento que
mostra claramente quais são as
etapas a seguir para produzir
software de qualidade
– Veremos também quais artefatos devem
ser produzidos na várias fases e etapas
do processo
O que é Análise e
Projeto ?
• Diferenças entre análise e projeto: tem
mais do que uma definição empregada
– Primeira alternativa:
• A análise modela o problema e consiste das atividades
necessárias para entender o domínio do problema (o
que deve ser feito). É uma atividade de investigação.
• O projeto modela a solução e consiste das atividades
de criação (como pode ser feito)
O que é Análise e
Projeto ?
• Segunda alternativa:
– A análise consiste de todas as atividades feitas
com ou para o conhecimento do cliente. A
informação produzida é aquela que o cliente
deve discutir e aprovar
– O projeto inclui as atividades que resultam em
informação que interessa apenas ao
programador
– Com essa definição, a análise invade um pouco o
"lado da solução", pois o cliente deve discutir
alguns tipos de interações que ocorrerão na
interface do usuário, etc.
O que é Análise e
Projeto ?
• Nesta disciplina, adotaremos a segunda
alternativa
– associar as palavras "análise" e "projeto" aos
artefatos (deliverables) entregues nos final de
cada fase
– Um modelo de análise deve ser aprovado pelo
cliente e pode incluir alguma (pequena)
discussão da solução, principalmente no que diz
respeito à interface com usuário, etc.
Outros pontos a serem
abordados:
• As fases de requisitos
• Implementação e
• Testes
O que é Análise e Projeto
Orientados a Objeto ?
• A perspectiva empregada é de objetos
(coisas, conceitos ou entidades)
• Durante a Análise OO, a ênfase está em
achar e descrever objetos (ou conceitos)
no domínio do problema
– Por exemplo, num sistema de informação para
uma biblioteca, alguns dos conceitos são Livro,
Biblioteca, Usuário.
– Tais objetos podem ter atributos e
responsabilidades
• Durante o projeto orientado a objeto, a
ênfase está em achar objetos lógicos de
software que poderão ser eventualmente
implementados usando uma linguagem de
programação OO
– Tais objetos pode ter atributos e métodos
• Durante a construção (programação OO),
os objetos do projeto são implementados e
testados
APOO versus AP
Estruturada
• Com ambas as técnicas, usa-se
decomposição
• A decomposição é por função ou
processo
Introdução a Análise e
projeto
• Motivação
– Sociedade dependente de sistemas
• Anos atrás: bancos, empresas de
grande porte
• Hoje: celulares, aplicações
distribuídas, Internet
• Pressão sobre desenvolvedores:
rapidez, confiabilidade, preço, etc.
Cenário atual do
desenvolvimento
• Dificuldade de entendimento dos
requisitos
• Dificuldade de manutenção
• Proliferação de tecnologias
• Baixa qualidade
Melhores soluções
existentes
• Utilizar modelos mais baratos para
visualizar soluções
• Utilizar soluções que já foram
utilizadas com sucesso
• Melhorar a comunicação na equipe
• Orientação a objetos
– Representa o mundo real em termos de
objetos
Processo de
Desenvolvimento
• Uma linguagem de modelagem não é
suficiente
• Precisamos também de um processo de
desenvolvimento
• O que é um processo de desenvolvimento?
– Define quem faz o que, quando e como, para
atingir um certo alvo
Exemplos
•
•
•
•
•
•
•
Modelo em Cascata
Modelo de Prototipagem
Modelo Evolucionário
Desenvolvimento Baseado em Componentes
Modelo de Métodos formais
Programação Extrema
Processo Unificado
Processo unificado (PU)
• Linguagem de modelagem + processo
de desenvolvimento = método (ou
metodologia) de desenvolvimento
• Linguagem de Modelagem = UML
Princípios Básicos do PU
• Desenvolvimento iterativo
• Baseado em casos de uso
• Centrado na arquitetura
Desenvolvimento
Iterativo
• O desenvolvimento de um software é
dividido em vários ciclos de iteração, cada
qual produzindo um sistema testado,
integrado e executável.
• Em cada ciclo ocorrem as atividades de
análise de requisitos, projeto,
implementação e teste, bem como a
integração dos artefatos produzidos com
os artefatos já existentes.
Desenvolvimento
Iterativo
• Planejar quantos ciclos de desenvolvimento
serão necessários para alcançar os
objetivos do sistema.
• As partes mais importantes devem ser
priorizadas e alocadas nos primeiros ciclos.
– A primeira iteração estabelece os principais
riscos e o escopo inicial do projeto, de acordo
com a funcionalidade principal do sistema.
– Partes mais complexas do sistema devem ser
atacadas já no primeiro ciclo, pois são elas que
apresentam maior risco de inviabilizar o
projeto.
Desenvolvimento
Iterativo
• O tamanho de cada ciclo pode variar de
uma empresa para outra e conforme o
tamanho do sistema.
• Por exemplo, uma empresa pode desejar
ciclos de 4 semanas, outra pode preferir 3
meses.
• Produtos entregues em um ciclo podem ser
colocados imediatamente em operação, mas
podem vir a ser substituídos por outros
produtos mais complexos em ciclos
posteriores.
Baseado em Casos de Uso
• Um caso de uso é uma seqüência de ações,
executadas por um ou mais atores e pelo
próprio sistema, que produz um ou mais
resultados de valor para um ou mais atores.
• O PU é dirigido por casos de uso, pois
utiliza-os para dirigir todo o trabalho de
desenvolvimento, desde a captação inicial e
negociação dos requisitos até a aceitação
do código (testes).
Baseado em Casos de Uso
• Os casos de uso são centrais ao PU e
a outros métodos iterativos, pois:
– Os requisitos funcionais são registrados
preferencialmente por meio deles
– Eles ajudam a planejar as iterações
– Eles podem conduzir o projeto
– O teste é baseado neles.
Centrado na Arquitetura
• Arquitetura é a organização fundamental
do sistema como um todo. Inclui elementos
estáticos, dinâmicos, o modo como
trabalham juntos e o estilo arquitetônico
total que guia a organização do sistema.
• •A arquitetura também se refere a
questões como desempenho, escalabilidade,
reuso e restrições econômicas e
tecnológicas.
Centrado na Arquitetura
• No PU, a arquitetura do sistema em
construção é o alicerce fundamental sobre
o qual ele se erguerá
• •Deve ser uma das preocupações da equipe
de projeto.
• •A arquitetura, juntamente com os casos
de uso, deve orientar a exploração de
todos os aspectos do sistema
Centrado na arquitetura
• A arquitetura é importante porque:
• –Ajuda a entender a visão global
• –Ajuda a organizar o esforço de
desenvolvimento
• –Facilita as possibilidades de reuso
• –Facilita a evolução do sistema
• –Guia a seleção e exploração dos casos de
uso.
Processo de
Desenvolvimento
• As grandes fases de qualquer
processo de desenvolvimento
– Concepção
• Visão e viabilidade do sistema
– Elaboração
• Arquitetura e requisitos definidos
• Implementação dos requisitos mais
complicados
• As grandes fases de qualquer
processo de desenvolvimento (cont.)
– Construção
• Versão beta do software
– Transição
• Implantação do sistema no ambiente de
produção
Fase de Concepção
•
•
•
•
•
Estabelece-se as viabilidade de
implantação do sistema
Definição do escopo do sistema.
Estimativas de custos e cronograma
Identificação dos potenciais riscos que
devem ser gerenciados ao longo do
projeto
Esboço da arquitetura do sistema, que
servirá como alicerce para a sua
construção.
Fase de Elaboração
• Visão refinada do sistema:
– com a definição dos requisitos
funcionais;
– detalhamento da arquitetura criada na
fase anterior;
– gerenciamento contínuo dos riscos
envolvidos.
Fase de Construção
• O sistema é efetivamente
desenvolvido e, em geral, tem
condições de ser operado, mesmo que
em ambiente de teste, pelos clientes.
• É nesta fase que o desenvolvimento
iterativo e incremental é realizado
Fase de transição
• O sistema é entregue ao cliente para
uso em produção.
• Testes são realizados e um ou mais
incrementos do sistema são
implantados.
• Defeitos são corrigidos, se
necessário.
Resumo
• Um processo de desenvolvimento deve ser:
– Iterativo (ter várias iterações no tempo)
– Incremental (gerar novas versões
incrementadas a cada release)
• Motivos:
– Sempre tem algo para entregar para o cliente
apressado (a última iteração)
– Os requisitos mudam com tempo e um processo
iterativo mantém freqüentes contatos com o
cliente o que ajuda a manter os requisitos
sincronizados
– Altamente motivador para a equipe de
desenvolvimento (e o cliente) ver o software
funcionando cedo