Aplicando UML, Padrões e APOO

Objetivo
Análise e Projeto „

– Desenvolver habilidades práticas na utilização da

Orientados a Objeto TO para a criação de sistemas de software bem
com UML e Padrões projetados, robustos, e modificáveis
„ Linguagens OO são um primeiro passo necessário
Parte I mas insuficiente
„ Outros recursos importantes
Análise, Projeto, e Processo – processo de desenvolvimento
– padrões
– UML
„ Ilustrados na prática através de um estudo de caso
detalhado
© Nabor C. Mendonça 2001 1 © Nabor C. Mendonça 2001 2

Atribuindo Responsabilidades O que é Análise e Projeto?

„ Saber a maneira adequada de atribuir
responsabilidades a componentes de software Análise — “o quê” Projeto — “como”
é a habilidade mais importante na APOO
Investigação do problema Descrição de uma solução
– Mais difícil de dominar e dos requisitos lógica
– Afeta com mais profundidade a robustez,
modificabilidade e reusabilidade do sistema Requisitos Objetos

Casos de uso Arquitetura

„ Padrões GRASP descrevem princípios
fundamentais para auxiliar na atribuição de
Restrições Instalação & Operação
responsabilidades
Vocabulário Interface do usuário
„ Saber identificar objetos ou abstrações adequados
é a segunda habilidade mais importante
© Nabor C. Mendonça 2001 3 © Nabor C. Mendonça 2001 4

Conflito de Terminologias O que é APOO?

„ Termos “Análise” e “Projeto” não são fixos, mas „ Na essência, considerar um problema e uma
usados ao longo de um contínuo solução dentro da perspectiva de objetos, coisas
ou conceitos
Mais orientado Mais orientado „ O que é AOO?
a análise a projeto
– Investigação dos objetos de domínio e seus
relacionamentos
Descritos no Modelo de Objetos de Domínio
„ Significados variam de metodologia para „ O que é POO?
metodologia
– Elaboração de uma solução lógica em termos de
componentes de software e suas colaborações e
responsabilidades
„ Distinção é útil na prática, mas debater definições
rígidas não é construtivo Descritos em Diagramas de Classes e Diagramas de Interação

© Nabor C. Mendonça 2001 5 © Nabor C. Mendonça 2001 6

1
 Representação de um Conceito na APOO Uma Analogia — Organizando os Negócios de
uma Empresa
„ Ex.: O conceito “Livro” em um sistema de biblioteca
Documentos
Analogia APOO
Conceito Representação Representação Associados
de domínio na análise no projeto
Quais são os Análise de requisitos Casos de uso
processos de negócio?
Livro Livro
título título
Quais são os papeis Análise do domínio Modelo conceitual
imprimir() dos empregados?

Quem é responsável Atribuição de Diagramas de classes

public class Livro por o quê? Como eles responsabilidades, de projeto, diagramas
{ interagem? projeto das interações de colaboração
Representação public void imprimir();
no código
private String titulo;
}
© Nabor C. Mendonça 2001 7 © Nabor C. Mendonça 2001 8

Um Exemplo — Jogo de Dados Um Exemplo — Jogo de Dados

„ Objetivo: ganha o jogo o jogador que rolar dois „ Modelagem na APOO (cont.)
dados e tirar sete – Modelo conceitual
Conceitos, atributos, e associações que são considerados
importantes no domínio da aplicação
„ Modelagem na APOO
Ex.:
– Casos de uso Jogador 1 Rola 2 Dado

Descrições narrativas de processos do domínio no formato nome valor

de prosa estruturada 1 2
Joga
Ex.:
Caso de uso: Jogar 1
Atores: Jogador JogoDeDados 1 Inclui
Descrição: Este caso de uso começa quando
o jogador rola os dados. Se o total
dos dados for sete, o jogador ganha; – Um modelo conceitual descreve conceitos do
do contrário, ele perde. mundo real, não componentes de software!
© Nabor C. Mendonça 2001 9 © Nabor C. Mendonça 2001 10

Um Exemplo — Jogo de Dados Um Exemplo — Jogo de Dados

„ Modelagem na APOO (cont.) „ Modelagem na APOO (cont.)
– Diagramas de colaboração – Diagramas de classes de projeto
Alocação de responsabilidades para objetos ilustrando Como os objetos (de software) se conectam?
como eles interagem via mensagens
Quais são os métodos de uma classe?
Mostram o fluxo de mensagens entre instâncias e a
invocação de métodos Ex.:
Jogador Dado
Ex.: Rola
nome valor
joga() 1: r1 := rola() 1 2
:Jogador d1 : Dado joga() rola()
1 2
Joga
2: r2 := rola()
d2 : Dado 1
JogoDeDados
1 Inclui

inicializa()

© Nabor C. Mendonça 2001 11 © Nabor C. Mendonça 2001 12

2
 APOO X APE A Linguagem de Modelagem Unificada — UML
„ Metodologias mais antigas, como Análise e Projeto „ A UML é a linguagem padrão de diagramação
Estruturados, baseiam-se em outras dimensões de para visualizar os resultados da análise e projeto
decomposição
„ A notação (a própria UML) é relativamente trivial
Sistema de „ Muito mais importante: habilidade para modelar
Biblioteca com objetos
– Só aprender a notação UML não ajuda
A&P Orientados a Objeto A&P Estruturados „ A UML não é
Decomposição por objetos ou conceitos
Decomposição por funções ou processos
– um processo ou metodologia
Sistema
Catálogo Bibliotecário – APOO

Livro Biblioteca Registra Adiciona Reporta

– regras de projeto
Empréstimos Recursos Multas

© Nabor C. Mendonça 2001 13 © Nabor C. Mendonça 2001 14

Origem e Evolução da UML Processo de Desenvolvimento

„ Organização das atividades relacionas à produção
UML 1.1 Industrialização e manutenção de sistemas de software
(Set’97)

UML 1.0 Padronização

(Jan’97)
„ Útil, mas um fator de segunda ordem
Parceiros
da UML – O principal: equipe qualificada
UML 0.9 & 0.91 Unificação II
(Out’96)

Unified Method 0.8 Unificação I „ Boa equipe + bom processo = menor risco
(Out’95)

Booch’93 OMT-2
„ O processo racional unificado (RUP), baseado no
Outros modelo iterativo, é o processo padrão na indústria
métodos Booch’91 OMT-1 OOSE Fragmentação

© Nabor C. Mendonça 2001 15 © Nabor C. Mendonça 2001 16

Um Processo Iterativo Simplificado Fases

„ Simplificação do processo iterativo unificado „ Planejamento e Elaboração
– Concepção inicial, investigação de alternativas,
Plan. & Construção Implantação
definição de requisitos, etc.
Elaboração

„ Construção
„ Fácil extensão e customização
– Construção do sistema através de múltiplos ciclos
de análise, projeto, implementação e teste
„ Não inclui atividades importantes como
– Verificação & validação „ Implantação
– Divisão do trabalho – Instalação e operação do sistema
– Gerência de projeto
– Documentação
© Nabor C. Mendonça 2001 17 © Nabor C. Mendonça 2001 18

3
 Modelos e Artefatos Fase de Planejamento e Elaboração
„ Um modelo descreve e abstrai aspectos essenciais
de um sistema Plan. & Construção Implantação
Elaboração
– Modelo estático (estrutura)
– Modelo dinâmico (comportamento)

„ Modelos são compostos por artefatos —

diagramas e documentos que descrevem os 1. Definir Plano
Inicial
2. Criar Rel. Prel.
de Investigação
3. Definir Requisitos

elementos do modelo 5. Implementar 6. Definir Casos

4. Reg. Termos
no Glossário a Protótipo de Uso
b, d Notas

a. contínua
„ Na APOO, a UML é usada para descrever e 7. Definir Mod.
Conc. Inicial c
8. Definir Arquit.
Inicial a, c, d
9. Refinar Plano b. opcional
c. adiável
visualizar os modelos e artefatos produzidos em d. ordem variada

cada fase do processo de desenvolvimento

© Nabor C. Mendonça 2001 19 © Nabor C. Mendonça 2001 20

Fase de Planejamento e Elaboração Fase de Planejamento e Elaboração

„ Atividades: „ Atividades:
1. Definir plano inicial 6. Definir casos de uso
Prazos, recursos, orçamento Descrição em prosa estruturada dos processos de negócio
2. Criar relatório preliminar de investigação 7. Definir modelo conceitual inicial
Motivação, alternativas, necessidades de negócio Objetos de domínio e seus relacionamentos
3. Definir requisitos 8. Definir arquitetura inicial
Especificação declarativa dos requisitos Principais subsistemas e suas dependências
4. Registrar termos no glossário 9. Refinar plano
Dicionário de termos, regras, restrições
5. Implementar protótipo „ Atividades não lineares
Protótipo do sistema para ajudar na definição dos requisitos
– Ex.: 7, 4, 6 em paralelo
© Nabor C. Mendonça 2001 21 © Nabor C. Mendonça 2001 22

Fase de Construção Fase de Construção

„ Repetição de ciclos de desenvolvimento
Plan. &
Elaboração
Construção Implantação – Construção progressiva do sistema até atingir uma
versão que satisfaça corretamente os requisitos

„ Atividades típicas de cada ciclo:

Ciclo de
Desenv. 1
Ciclo de
Desenv. 2
... 1. Refinar plano
2. Sincronizar artefatos
3. Análise
4. Projeto
Refin.
Plano
Sinc. Análise Projeto Impl. Teste
5. Implementação
Artefatos

6. Teste
© Nabor C. Mendonça 2001 23 © Nabor C. Mendonça 2001 24

4
 Ciclos de Desenvolvimento Ciclos de Desenvolvimento e Casos de Uso
„ Cada ciclo implementa um conjunto reduzido de „ Um ciclo deve atacar um ou mais casos de uso, ou
requisitos, adicionando novas funções ao versões simplificadas de casos de uso
sistema „ Casos de uso mais relevantes devem ser atacados
– Crescimento incremental, através de expansões e nos primeiros ciclos
refinamentos sucessivos
– Prioridade para serviços com grande influência na
arquitetura do sistema ou de alto risco
„ Ciclos com tempo fixo de duas a oito semanas
Ciclo de Ciclo de Ciclo de
Desenv. 1 Desenv. 2 Desenv. 3
„ Vantagens:
Caso de uso A Caso de uso A Caso de uso B
– Evita complexidade excessiva Versão Versão
Simplificada Completa
– Antecipa feedback dos usuários Caso de uso C

© Nabor C. Mendonça 2001 25 © Nabor C. Mendonça 2001 26

Análise Análise
Notas
„ Subatividades:
Ciclo de Ciclo de a. se ainda não feito
Desenv. 1 Desenv. 2 ... b. contínuo
c. opcional
1. Definir casos de uso essenciais
2. Refinar diagramas de casos de uso
3. Refinar modelo conceitual
Refin. Sinc.
Plano Artefatos Análise Projeto Impl. Teste 4. Refinar glossário
5. Definir diagramas de seqüência do sistema
6. Definir contratos de operação
7. Definir diagramas de estado
1. Definir Casos de 2. Refinar Diag. 3. Refinar Modelo 4. Refinar
Uso Essenciais a Casos de Uso Conceitual Glossário b

5. Definir Diag. 6. Definir Contrat. 7. Definir Diag.

Seq. de Operação Estado c

© Nabor C. Mendonça 2001 27 © Nabor C. Mendonça 2001 28

Projeto Projeto
Notas „ Subatividades:
Ciclo de Ciclo de a. em paralelo com
...
Desenv. 1 Desenv. 2 diag. interação
b. ordem variada 1. Definir casos de uso reais
2. Definir relatórios e interfaces com o usuário
3. Refinar arquitetura do sistema
Refin.
Plano
Sinc.
Artefatos Análise Projeto Impl. Teste 4. Definir diagramas de interação
5. Definir diagramas de classes de projeto
6. Definir esquema do banco de dados

1. Definir Casos de 2. Definir Rel. & IU 3. Refinar

Uso Reais Arquitetura b

4. Definir Diag. 5. Definir Diag. 6. Definir Esquema

Interação Classes a do BD

© Nabor C. Mendonça 2001 29 © Nabor C. Mendonça 2001 30