No Slide Title - Computação UFCG

Metodologia (R)UP +
UML
© Nabor C. Mendonça 2001
1
Roteiro
I. A Motivação para o Modelo Iterativo e a Tecnologia
de Objetos
II. UML: Visão Geral
III. (R)UP + UML em Detalhes
© Nabor C. Mendonça 2001
2
I. A Motivação para o Modelo
Iterativo e a Tecnologia de
Objetos
Baseado em uma apresentação de Craig Larman
© Nabor C. Mendonça 2001
3
Software — Um Investimento de Risco

Resultado de projetos de software realizados nos
EUA no início da década de 90
•Todos baseados no
modelo cascata
Inacabados
30%
•53% custaram até
200% acima da
estimativa inicial
•Estimou-se que
$81 bilhões foram
Concluídos gastos em projetos
70%
fracassados só no
ano de 1995
Fonte: Standish Report, 1994
© Nabor C. Mendonça 2001
4
O Que Deu Errado?


O modelo cascata é fortemente baseado em
suposições oriundas dos processos de engenharia
convencionais
Algumas dessas suposições não foram
confirmadas na prática
–
Todos os requisitos podem ser precisamente
identificados antes do desenvolvimento
–
Os requisitos são estáveis
–
O design pode ser feito totalmente antes da
implementação
© Nabor C. Mendonça 2001
5
Imprecisão dos Requisitos
Estudo publicado por Capers Jones em 1987,
baseado em 6.700 sistemas
% de Req's Problemáticos

60
50
40
30
20
10
0
10
100
1000
10000
100000
Tamanho do Sistema de Software em Pontos por Função
© Nabor C. Mendonça 2001
6
Instabilidade dos Requisitos

O mercado muda — constantemente

As tecnologias mudam — inevitavelmente

A vontade e objetivos dos usuários mudam —
imprevisivelmente
© Nabor C. Mendonça 2001
7
Análise + Design Completos antes da
Implementação?

Pergunte a qualquer programador

Requisitos são incompletos e instáveis


Uma especificação completa tem que ser tão
detalhada quanto o próprio código
Desenvolver software é uma atividade
intrinsecamente “difícil”
–
Discover Magazine, 1999: Software caracterizado
como a mais complexa “máquina” que a
humanidade já construiu
© Nabor C. Mendonça 2001
8
Pessoas / Mês
Esforço — O Perigo dos Passos Largos
80000
70000
60000
50000
40000
30000
20000
10000
0
66690
1
20
267
4362
Tamanho do Sistema em Pontos por Função
Fonte: Applied Software Measurement, Capers Jones, 1997
© Nabor C. Mendonça 2001
9
LOC/Pessoa por Mês
Produtividade — O Perigo dos Passos Largos
4500
4000
3500
3000
2500
2000
1500
1000
500
0
1
10
100
1000
Tamanho do Sistema em KLOC
Fonte: Measures For Excellence, Putnam, 1992. Baseado em 1.600 sistemas
© Nabor C. Mendonça 2001
10
A Voz da Experiência e da Pesquisa

Em 1994, o DoD (EUA) parou de contratar projetos baseado
no modelo cascata, por causa de fracassos abismais
–

Eles agora incentivam um modelo iterativo
Virtualmente todos os trabalhos na área publicados nos
últimos 5 anos defendem a substituição do modelo cascata
por um modelo iterativo
–
The Unified Software Development Process
–
Applying UML and Patterns
–
Software Project Management
–
Succeeding with Objects
–
Object Solutions
–
Surviving Object-oriented Projects
–
…
© Nabor C. Mendonça 2001
11
Portanto...
© Nabor C. Mendonça 2001
12
Usem o Modelo Iterativo!


Passos curtos, interação (feedback) e refinamento
Iterativo, incremental, com intervalos de tempo
(ciclos) pré-estabelecidos
Iteração
1
Análise
Projeto
Codificação, Teste,
Integração
2 a 4 semanas
© Nabor C. Mendonça 2001
Iteração
2
Análise
...
Projeto
Codificação, Teste,
Integração
2 a 4 semanas
13
Um Processo Iterativo Popular — RUP

Atenção: as fases não são iterações!
© Nabor C. Mendonça 2001
14
O Custo da Mudança

Planos estratégicos e racionais de desenvolvimento
baseiam-se no custo total do sistema, não apenas nos
custos de desenvolvimento
Outros
Código
Teste
Projeto
Revisão &
Manutenção
Documentação
Fonte: DP Budget, Vol. 7, No. 12, Dez. 1988
© Nabor C. Mendonça 2001
15
O Custo da Mudança

Estudo com projetos de software do governo Americano
Usado depois
de alterações
3%
Usado mas
bastante
alterado ou
em seguida
abandonado
19%
Usado tal como
entregue
2%
Entregue
mas nunca
usado
satisfatoriamente
47%
Pago mas
não entregue
29%
Fonte: US Government Accounting Office, Report FGMSD-80-4
© Nabor C. Mendonça 2001
16
O Custo da Mudança

Um estudo da AT&T indicou que, na média,
© Nabor C. Mendonça 2001
17
Por que a Tecnologia de Objeto?



Os principais problemas do software hoje são
–
Diminuir o custo e o tempo da mudança
–
Aumentar a capacidade e facilidade de adaptação
Fato: Objetos são especialmente bons para
–
Reduzir o tempo necessário para adaptar um
sistema existente (reação mais rápida à mudanças
no seu ambiente de negócio)
–
Reduzir o esforço, a complexidade e os custos
associados à mudança
Em suma:
© Nabor C. Mendonça 2001
18
Por Que a Tecnologia de Objeto? (2)

Segundo um estudo corporativo de 1997, as razões
prioritárias para se adotar a tecnologia de objeto (TO) são:
–
1. Capacidade de aproveitar novas plataformas e ferramentas
–
2. Facilidade de manutenção
–
3. Economia de custos
–
4. Desenvolvimento de aplicações lucrativas
–
5. Encapsulamento das aplicações existentes
–
6. Melhores interfaces
–
7. Maior produtividade
–
8. Participação no "futuro da computação"
–
9. Prova da capacidade de usar a tecnologia
–
10. Rápido desenvolvimento de aplicações estratégicas
–
11. Reuso de software
© Nabor C. Mendonça 2001
Notem a alta prioridade
Notem a baixa prioridade
19
Por que a Tecnologia de Objeto? (3)
“O valor da TO (APOO, POO) está fundamentalmente na sua
capacidade de lidar com problemas complexos e criar
sistemas compreensíveis e gerenciáveis, que podem
acompanhar uma complexidade crescente e ser facilmente
adaptáveis—se habilidosamente projetados.”
Craig Larman

Ataca complexidade elegantemente e gera fácil
adaptabilidade
A produtividade se sobressai nas

...

Produtividade

Reuso
© Nabor C. Mendonça 2001
fases de manutenção ou modificação
do sistema — freqüentemente com
mudanças profundamente mais
rápidas, se o sistema foi
habilidosamente projetado.
20
II. UML
Grady Booch
© Nabor C. Mendonça 2001
21
A Importância da UML




É um padrão, de fato
Cobre as atividades de análise e design de um
processo de desenvolvimento orientado a objeto
de software
É baseada na experiência e necessidades dos
usuários de todos os tipos
Implementada em muitas ferramentas
© Nabor C. Mendonça 2001
22
Diagramas UML
A model is a complete
description of a system
from a particular
perspective
Use Case
Use Case
Diagrams
Sequence
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Collaboration
Diagrams
Diagrams
Scenario
Scenario
Diagrams
Statechart
Diagrams
Diagrams
© Nabor C. Mendonça 2001
Use Case
Use Case
Diagrams
Use Case
Diagrams
Diagrams
State
State
Diagrams
Class
Diagrams
Diagrams
State
State
Diagrams
Object
Diagrams
Diagrams
State
State
Diagrams
Component
Diagrams
Diagrams
Models
Component
Component
Diagrams
Deployment
Diagrams
Activity
Diagrams
Diagrams
23
Diagramas


Um diagrama é uma visão segundo um modelo
–
Apresentado de modo conveniente a um tipo de
usuário (“stakeholder”)
–
Dá uma visão parcial do sistema
–
É semanticamente consistente com outras visões
Na UML, existem 9 diagramas
–
Visões estáticas: use case, classe, objeto,
componente, deployment
–
Visões dinâmicas: seqüência, colaboração,
diagrama de estado, diagrama de atividade
© Nabor C. Mendonça 2001
24
III. A Metodologia em
Detalhes
© Nabor C. Mendonça 2001
25
O Conceito de Iteração



Um mini projeto com duração pequena (por
exemplo, 1 mês), com resultados testados e
integrados
Cada iteração inclui seus próprios requisitos de
análise, design, implementação e teste
O final de uma iteração é uma peça correta 
release  de software (passou por análise, design,
implementação e testes)
© Nabor C. Mendonça 2001
26
O Conceito de Iteração (2)
-- Desenvolvimento Iterativo e Incremental -© Nabor C. Mendonça 2001
27
O Conceito de Iteração (3)


As iterações de maior risco são atacadas primeiro
–
Diretamente relacionadas com o negócio
–
Riscos potencialmente altos no início do
desenvolvimento
As iterações de menor risco são deixadas para o
final
–
Iterações não diretamente relacionadas com o
negócio
–
Riscos baixos à medida que se aproxima do final
© Nabor C. Mendonça 2001
28
O Conceito de Iteração (4)
-- Risco Potencial Pequeno, no Final --
© Nabor C. Mendonça 2001
29
O Conceito de Iteração (5)


Feedback (interatividade) e adaptação iterativos
conduzem ao sistema desejado
A instabilidade dos requisitos e do design
diminuem com as últimas iterações
© Nabor C. Mendonça 2001
30
O Conceito de Iteração (6)
© Nabor C. Mendonça 2001
31
Características Gerais da Metodologia

Iterativo e incremental
–
Grandes atividades (disciplines) de uma iteração
Análise
Projeto
Implementação
Validação: Teste & Integração  Testes de Regressão

Todos os artefatos de análise e design são
formalmente descritos usando a linguagem UML
© Nabor C. Mendonça 2001
32
Características Gerais da Metodologia (2)


Fases do processo
–
Início ou Planejamento (Inception)
–
Elaboração
–
Construção
–
Transição
Uma fase (exceto a primeira) é composta de
diversas iterações
© Nabor C. Mendonça 2001
33
Características Gerais da Metodologia (3)
© Nabor C. Mendonça 2001
34
Fase Início
Planejamento
Elaboração
2. Criar Rel. Prel.
de Investigação
1. Definir Plano
Inicial
© Nabor C. Mendonça 2001
Construção
4. Reg. Termos
no Glossário a
5. Implementar
Protótipo
7. Definir Mod.
Conc. Inicial
8. Definir Arquit.
Inicial
a, c, d
c
b, d
3. Definir Requisitos
6. Definir Casos
de Uso
Notas
9. Det. das Demais
Fases
a. contínua
b. opcional
c. adiável
d. ordem variada
35
Fase Início (2)
1. Plano Inicial (Business Case)
© Nabor C. Mendonça 2001
36
Fase Início (3)
2. Criar relatório preliminar de investigação
Motivação, alternativas, necessidades de negócio
3. Definir requisitos iniciais
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
37
Fase Início (4)
6. Definir use cases iniciais
Descrição em prosa estruturada dos processos de negócio
7. Definir modelo conceitual inicial
Objetos do domínio e seus relacionamentos
8. Definir arquitetura inicial
Principais subsistemas e suas dependências
9. Detalhamento das Demais Fases
Obs.: Atividades não seqüenciais
© Nabor C. Mendonça 2001
38
Fase Início (5)

Detalhamento das Fases
–

Iterações (ou definição dos incrementos)
Requisitos: funções que o sistema deve oferecer
–
Requisitos Funcionais
Diretamente relacionados com o negócio
–
Requisitos Não-funcionais
Questões de desempenho
Emprego de certas tecnologias
...
© Nabor C. Mendonça 2001
39
Fase Início (6)

Modelo do Negócio (ou do Domínio), ou Modelo
Conceitual
–
Principais Entidades ou Conceitos
–
Relacionamentos entre as Entidades
Um Diagrama de Classe Simplificado
© Nabor C. Mendonça 2001
40
Fase de Elaboração
Planejamento
Iteração 1
Iteração 2
Refin.
Plano
© Nabor C. Mendonça 2001
Elaboração
Construção
...
Sinc.
Artefatos
Análise
Design
Impl.
Teste
41
Fase de Elaboração (2)

Iterações
–

Construção progressiva do sistema até atingir uma
versão que satisfaça corretamente os requisitos
funcionais
Atividades típicas de cada iteração:
1. Refinar plano das fases
2. Sincronizar artefatos
3. Análise
4. Projeto
5. Implementação
6. Teste
© Nabor C. Mendonça 2001
42
Fase de Elaboração (3)

Cada ciclo de desenvolvimento 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
43
Fase de Construção

Como a fase de Elaboração, mas cuidando apenas
de requisitos não-funcionais
–
O « tournant »: todos os requisitos funcionais
implementados
Obs: A fase de construção não é foco da disciplina
© Nabor C. Mendonça 2001
44
Artefatos

Toda iteração deve produzir artefatos
–
Artefato é uma peça de informação que é produzida,
modificada ou utilizada por um processo
–
Artefato UML: um artefato formalmente definido
segundo a sintaxe UML
© Nabor C. Mendonça 2001
45
Artefatos (2)
Atividades
Artefato UML
Iníc.
Elab.
E1.E3
Iteração
Análise
Design
Use Case
-----------------------Diagrama de Seqüência do Sistema
(System Sequence Diagram)
-----------------------Modelo Conceitual
-----------------------Contrato
Diagrama de Colaboração entre
Objetos (Object Sequence Diagram;
Object Collaboration Diagram)
-----------------------Diagrama de Classe Detalhado
i
r
i
r
i
r
i
r
i-r
i-r
i = início
r = refinamento
© Nabor C. Mendonça 2001
46
Um Pequeno Exemplo Ilustrativo (Parcial)

Use Case (extremamente simples, e apresentado de
maneira informal)
–
Jogo de Dados : no jogo de dados, um jogador lança
dois dados; se a soma dos valores de face for 7, ele
ganha; caso contrário, ele perde.
Está implícito que:
um jogador joga jogo
o jogo inclui dois valores de face
© Nabor C. Mendonça 2001
47
Exemplo (2)
-- Modelo Conceitual (Versão #1) --
© Nabor C. Mendonça 2001
48
Exemplo (3)
JogoDeDados
Lança
1
2
Dado
Não estamos interessados na entidade Jogador
Jogador é apenas um usuário, ou ator
-- Modelo Conceitual (Versão #2) -© Nabor C. Mendonça 2001
49
Exemplo (4)
Jogador
Do jeito em que está, o jogador não sabe o resultado do jogo. Como sabê-lo?
-- Diagrama de Colaboração entre Objetos -© Nabor C. Mendonça 2001
50
Exemplo (5)
Modifique o diagrama, para que o jogador saiba o resultado do jogo
-- Diagrama de Classe -© Nabor C. Mendonça 2001
51