View
110
Download
0
Category
Preview:
Citation preview
© Nabor C. Mendonça 2001 1
Análise e Projeto Orientados a Objetocom UML e Padrões
Parte I
Análise, Projeto, e Processo
© Nabor C. Mendonça 2001 2
Aplicando UML, Padrões e APOO
Objetivo – Desenvolver habilidades práticas na utilização da
TO para a criação de sistemas de software bem projetados, robustos, e modificáveis
Linguagens OO são um primeiro passo necessário mas insuficiente
Outros recursos importantes – processo de desenvolvimento– padrões– UML
Ilustrados na prática através de um estudo de caso detalhado
© Nabor C. Mendonça 2001 3
Atribuindo Responsabilidades
Saber a maneira adequada de atribuir responsabilidades a componentes de software é a habilidade mais importante na APOO– Mais difícil de dominar
– Afeta com mais profundidade a robustez, modificabilidade e reusabilidade do sistema
Padrões GRASP descrevem princípios fundamentais para auxiliar na atribuição de responsabilidades
Saber identificar objetos ou abstrações adequados é a segunda habilidade mais importante
© Nabor C. Mendonça 2001 4
O que é Análise e Projeto?
Análise — “o quê”
Investigação do problema e dos requisitos
Requisitos
Casos de uso
Restrições
Vocabulário
Projeto — “como”
Descrição de uma solução lógica
Objetos
Arquitetura
Instalação & Operação
Interface do usuário
© Nabor C. Mendonça 2001 5
Termos “Análise” e “Projeto” não são fixos, mas usados ao longo de um contínuo
Significados variam de metodologia para metodologia
Distinção é útil na prática, mas debater definições rígidas não é construtivo
Conflito de Terminologias
Mais orientadoa análise
Mais orientado a projeto
© Nabor C. Mendonça 2001 6
O que é APOO?
Na essência, considerar um problema e uma solução dentro da perspectiva de objetos, coisas ou conceitos
O que é AOO?– Investigação dos objetos de domínio e seus
relacionamentos
Descritos no Modelo de Objetos de Domínio
O que é POO?– Elaboração de uma solução lógica em termos de
componentes de software e suas colaborações e responsabilidades
Descritos em Diagramas de Classes e Diagramas de Interação
© Nabor C. Mendonça 2001 7
Representação de um Conceito na APOO
Conceitode domínio
public class Livro{public void imprimir();
private String titulo;}
Representaçãono código
Ex.: O conceito “Livro” em um sistema de biblioteca
Livro
título
Representaçãona análise
Livro
título
Representaçãono projeto
imprimir()
© Nabor C. Mendonça 2001 8
Uma Analogia — Organizando os Negócios de uma Empresa
DocumentosAssociados
APOOAnalogia
Casos de usoAnálise de requisitosQuais são os processos de negócio?
Modelo conceitualAnálise do domínioQuais são os papeis dos empregados?
Diagramas de classes de projeto, diagramas de colaboração
Atribuição de responsabilidades, projeto das interações
Quem é responsável por o quê? Como eles interagem?
© Nabor C. Mendonça 2001 9
Objetivo: ganha o jogo o jogador que rolar dois dados e tirar sete
Modelagem na APOO– Casos de uso
Descrições narrativas de processos do domínio no formato de prosa estruturada
Ex.:
Um Exemplo — Jogo de Dados
Caso de uso:Atores:Descrição:
JogarJogadorEste caso de uso começa quandoo jogador rola os dados. Se o totaldos dados for sete, o jogador ganha;do contrário, ele perde.
© Nabor C. Mendonça 2001 10
Modelagem na APOO (cont.)– Modelo conceitual
Conceitos, atributos, e associações que são considerados importantes no domínio da aplicação
Ex.:
– Um modelo conceitual descreve conceitos do mundo real, não componentes de software!
Um Exemplo — Jogo de Dados
Jogador
nome
JogoDeDados
Dado
valor
Rola
Joga
Inclui
2
2
1
1
1
1
© Nabor C. Mendonça 2001 11
Um Exemplo — Jogo de Dados
Modelagem na APOO (cont.) – Diagramas de colaboração
Alocação de responsabilidades para objetos ilustrando como eles interagem via mensagens
Mostram o fluxo de mensagens entre instâncias e a invocação de métodos
Ex.:
:Jogador d1 : Dado
d2 : Dado
joga() 1: r1 := rola()
2: r2 := rola()
© Nabor C. Mendonça 2001 12
Modelagem na APOO (cont.) – Diagramas de classes de projeto
Como os objetos (de software) se conectam?
Quais são os métodos de uma classe?
Ex.:
Rola
Joga
Inclui
2
2
Jogador
nome
joga()
Dado
valor
rola()
JogoDeDados
inicializa()
1
1
1
1
Um Exemplo — Jogo de Dados
© Nabor C. Mendonça 2001 13
APOO X APE
Sistema deBiblioteca
Sistema
A&P Orientados a ObjetoDecomposição por objetos ou conceitos
A&P EstruturadosDecomposição por funções ou processos
RegistraEmpréstimos
AdicionaRecursos
ReportaMultas
Catálogo
Livro
Bibliotecário
Biblioteca
Metodologias mais antigas, como Análise e Projeto Estruturados, baseiam-se em outras dimensões de decomposição
© Nabor C. Mendonça 2001 14
A UML é a linguagem padrão de diagramação para visualizar os resultados da análise e projeto
A notação (a própria UML) é relativamente trivial Muito mais importante: habilidade para modelar
com objetos– Só aprender a notação UML não ajuda
A UML não é– um processo ou metodologia
– APOO
– regras de projeto
A Linguagem de Modelagem Unificada — UML
© Nabor C. Mendonça 2001 15
Origem e Evolução da UML
Unified Method 0.8 Unificação I(Out’95)
Booch’93 OMT-2
Outros métodos Booch’91 OMT-1 OOSE Fragmentação
UML 1.0
Parceirosda UML
Padronização(Jan’97)
UML 1.1 Industrialização(Set’97)
UML 0.9 & 0.91 Unificação II(Out’96)
© Nabor C. Mendonça 2001 16
Processo de Desenvolvimento
Organização das atividades relacionas à produção e manutenção de sistemas de software
Útil, mas um fator de segunda ordem– O principal: equipe qualificada
Boa equipe + bom processo = menor risco
O processo racional unificado (RUP), baseado no modelo iterativo, é o processo padrão na indústria
© Nabor C. Mendonça 2001 17
Simplificação do processo iterativo unificado
Fácil extensão e customização
Não inclui atividades importantes como – Verificação & validação
– Divisão do trabalho
– Gerência de projeto
– Documentação
Um Processo Iterativo Simplificado
ConstruçãoPlan. &Elaboração Implantação
© Nabor C. Mendonça 2001 18
Fases
Planejamento e Elaboração– Concepção inicial, investigação de alternativas,
definição de requisitos, etc.
Construção– Construção do sistema através de múltiplos ciclos
de análise, projeto, implementação e teste
Implantação– Instalação e operação do sistema
© Nabor C. Mendonça 2001 19
Modelos e Artefatos
Um modelo descreve e abstrai aspectos essenciais de um sistema– Modelo estático (estrutura)
– Modelo dinâmico (comportamento)
Modelos são compostos por artefatos — diagramas e documentos que descrevem os elementos do modelo
Na APOO, a UML é usada para descrever e visualizar os modelos e artefatos produzidos em cada fase do processo de desenvolvimento
© Nabor C. Mendonça 2001 20
Fase de Planejamento e Elaboração
2. Criar Rel. Prel. de Investigação
3. Definir Requisitos
9. Refinar Plano7. Definir Mod. Conc. Inicial c
4. Reg. Termos no Glossário a
6. Definir Casos de Uso
1. Definir PlanoInicial
5. ImplementarProtótipo
b, d
a. contínuab. opcionalc. adiáveld. ordem variada
8. Definir Arquit.Inicial a, c, d
Notas
ConstruçãoPlan. &Elaboração Implantação
© Nabor C. Mendonça 2001 21
Fase de Planejamento e Elaboração
Atividades:
1. Definir plano inicial
Prazos, recursos, orçamento
2. Criar relatório preliminar de investigação
Motivação, alternativas, necessidades de negócio
3. Definir requisitos
Especificação declarativa dos requisitos
4. Registrar termos no glossário
Dicionário de termos, regras, restrições
5. Implementar protótipo
Protótipo do sistema para ajudar na definição dos requisitos
© Nabor C. Mendonça 2001 22
Fase de Planejamento e Elaboração
Atividades:
6. Definir casos de uso
Descrição em prosa estruturada dos processos de negócio
7. Definir modelo conceitual inicial
Objetos de domínio e seus relacionamentos
8. Definir arquitetura inicial
Principais subsistemas e suas dependências
9. Refinar plano
Atividades não lineares – Ex.: 7, 4, 6 em paralelo
© Nabor C. Mendonça 2001 23
Fase de Construção
Ciclo deDesenv. 1
Sinc.Artefatos Análise Projeto Teste
Refin.Plano Impl.
Ciclo deDesenv. 2
...
ConstruçãoPlan. &Elaboração Implantação
© Nabor C. Mendonça 2001 24
Fase de Construção
Repetição de ciclos de desenvolvimento– Construção progressiva do sistema até atingir uma
versão que satisfaça corretamente os requisitos
Atividades típicas de cada ciclo:
1. Refinar plano
2. Sincronizar artefatos
3. Análise
4. Projeto
5. Implementação
6. Teste
© Nabor C. Mendonça 2001 25
Ciclos de Desenvolvimento
Cada ciclo implementa um conjunto reduzido de requisitos, adicionando novas funções ao sistema – Crescimento incremental, através de expansões e
refinamentos sucessivos
Ciclos com tempo fixo de duas a oito semanas
Vantagens:– Evita complexidade excessiva
– Antecipa feedback dos usuários
© Nabor C. Mendonça 2001 26
Ciclos de Desenvolvimento e Casos de Uso
Um ciclo deve atacar um ou mais casos de uso, ou versões simplificadas de casos de uso
Casos de uso mais relevantes devem ser atacados nos primeiros ciclos– Prioridade para serviços com grande influência na
arquitetura do sistema ou de alto risco
Ciclo de Desenv. 1
Caso de uso AVersãoSimplificada
Ciclo de Desenv. 2
Caso de uso AVersãoCompleta
Ciclo de Desenv. 3
Caso de uso B
Caso de uso C
© Nabor C. Mendonça 2001 27
Análise
a. se ainda não feitob. contínuoc. opcional
2. Refinar Diag. Casos de Uso
3. Refinar ModeloConceitual
4. Refinar Glossário b
6. Definir Contrat.de Operação
1. Definir Casos de Uso Essenciais a
5. Definir Diag.Seq.
7. Definir Diag.Estado c
Notas
...Ciclo deDesenv. 1
Sinc.Artefatos Análise Projeto TesteRefin.
Plano Impl.
Ciclo deDesenv. 2
© Nabor C. Mendonça 2001 28
Análise
Subatividades:
1. Definir casos de uso essenciais
2. Refinar diagramas de casos de uso
3. Refinar modelo conceitual
4. Refinar glossário
5. Definir diagramas de seqüência do sistema
6. Definir contratos de operação
7. Definir diagramas de estado
© Nabor C. Mendonça 2001 29
Projeto
2. Definir Rel. & IU
4. Definir Diag.Interação
5. Definir Diag.Classes a
6. Definir Esquemado BD
1. Definir Casos deUso Reais
3. Refinar Arquitetura b
Notas
a. em paralelo com diag. interaçãob. ordem variada
...Ciclo deDesenv. 1
Sinc.Artefatos Análise Projeto TesteRefin.
Plano Impl.
Ciclo deDesenv. 2
© Nabor C. Mendonça 2001 30
Projeto
Subatividades:
1. Definir casos de uso reais
2. Definir relatórios e interfaces com o usuário
3. Refinar arquitetura do sistema
4. Definir diagramas de interação
5. Definir diagramas de classes de projeto
6. Definir esquema do banco de dados
Recommended