© Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML.

© Nabor C. Mendonça 2001 1

Metodologia (R)UP + UML


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


I. A Motivação para o Modelo Iterativo e a Tecnologia de Objetos

Baseado em uma apresentação de Craig Larman


Software — Um Investimento de Risco

Resultado de projetos de software realizados nos EUA no início da década de 90

Inacabados30%

Concluídos70%

Fonte: Standish Report, 1994

•Todos baseados no modelo cascata

•53% custaram até 200% acima da estimativa inicial

•Estimou-se que $81 bilhões foram gastos em projetos fracassados só no ano de 1995


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


Imprecisão dos Requisitos

Estudo publicado por Capers Jones em 1987, baseado em 6.700 sistemas

0

10

20

30

40

50

60

10 100 1000 10000 100000

Tamanho do Sistema de Software em Pontos por Função

% d

e R

eq's

Pro

ble

mát

ico

s


Instabilidade dos Requisitos

O mercado muda — constantemente

As tecnologias mudam — inevitavelmente

A vontade e objetivos dos usuários mudam — imprevisivelmente


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


Esforço — O Perigo dos Passos Largos

1 20 267 4362

66690

01000020000300004000050000600007000080000

10 100

1000

1000

0

1000

00

Tamanho do Sistema em Pontos por Função

Pe

sso

as

/ Mê

s

Fonte: Applied Software Measurement, Capers Jones, 1997


Produtividade — O Perigo dos Passos Largos

0

500

1000

1500

2000

2500

3000

3500

4000

4500

1 10 100 1000

Tamanho do Sistema em KLOC

LO

C/P

ess

oa

po

r M

ês

Fonte: Measures For Excellence, Putnam, 1992. Baseado em 1.600 sistemas


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

– …


Portanto...


Usem o Modelo Iterativo!

Passos curtos, interação (feedback) e refinamento Iterativo, incremental, com intervalos de tempo

(ciclos) pré-estabelecidos

Iteração1

ProjetoCodificação, Teste,

IntegraçãoAnálise

...Iteração

2

ProjetoAnáliseCodificação, Teste,

Integração

2 a 4 semanas2 a 4 semanas


Um Processo Iterativo Popular — RUP

Atenção: as fases não são iterações!


Documentação

Projeto

Teste

Código

Outros

Revisão & Manutenção

Fonte: DP Budget, Vol. 7, No. 12, Dez. 1988

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


Entreguemas nunca

usadosatisfatoriamente

47%

Usado masbastante

alterado ouem seguidaabandonado

19%

Pago mas não entregue

29%

Usado depoisde alterações

3%

Usado tal comoentregue

2%

Fonte: US Government Accounting Office, Report FGMSD-80-4

O Custo da Mudança

Estudo com projetos de software do governo Americano


O Custo da Mudança

Um estudo da AT&T indicou que, na média,


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:


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 Notem a baixa prioridade

Notem a alta prioridade

Por Que a Tecnologia de Objeto? (2)


Ataca complexidade elegantemente e gera fácil adaptabilidade

. . . Produtividade Reuso

A produtividade se sobressai nas fases de manutenção ou modificação

do sistema — freqüentemente com mudanças profundamente mais

rápidas, se o sistema foi habilidosamente projetado.

“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

Por que a Tecnologia de Objeto? (3)


II. UML: uma Visão GeralGrady Booch


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


Modelos, Visões e Diagramas

Use CaseDiagramsUse Case

DiagramsUse CaseDiagrams

ScenarioDiagramsScenario

DiagramsCollaborationDiagrams

StateDiagramsState

DiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

StateDiagramsState

DiagramsObjectDiagrams

ScenarioDiagramsScenario

DiagramsStatechartDiagrams

Use CaseDiagramsUse Case

DiagramsSequenceDiagrams

StateDiagramsState

DiagramsClassDiagrams

ActivityDiagrams

A model is a completedescription of a systemfrom a particularperspective

Models


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


III. A Metodologia em Detalhes


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)


O Conceito de Iteração (2)

-- Desenvolvimento Iterativo e Incremental --



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



-- Risco Potencial Pequeno, no Final --



Feedback (interatividade) e adaptação iterativos conduzem ao sistema desejado

A instabilidade dos requisitos e do design diminuem com as últimas iterações


Características Gerais do Processo

Iterativo e incremental

– Grandes atividades (disciplines) de uma iteração

Análise

Projeto

Implementação

Validação: Teste & Integração

Todos os artefatos de análise e design são formalmente descritos usando a linguagem UML


Características Gerais do Processo (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


Características Gerais do Processo (3)


Fase de Planejamento

2. Criar Rel. Prel. de Investigação

3. Definir Requisitos

9. Det. das DemaisFases

7. 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

ElaboraçãoPlaneja-mento Construção


Fase de Planejamento (2)

1. Plano Inicial (Business Case)



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



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



Detalhamento das Fases

– Iterações (ou definição dos incrementos)

Requisitos: funções que o sistema deve oferecer

– Requisitos FuncionaisDiretamente relacionados com o negócio

– Requisitos Não-funcionais

Questões de desempenho

Emprego de certas tecnologias

. . .



Modelo do Negócio (ou do Domínio), ou Modelo Conceitual

– Principais Entidades ou Conceitos

– Relacionamentos entre as Entidades

– Um Diagrama de Classe Simplificado


Fase de Elaboração

Iteração 1

Sinc.Artefatos Análise Design Teste

Refin.Plano Impl.

Iteração 2 ...

ElaboraçãoPlaneja-mento Construção


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


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


Fase de Construção

Como a fase de Elaboração, mas cuidando apenas de requisitos não-funcionais

Obs: A fase de construção não é foco da disciplina


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


Artefatos (2)

i = inícior = refinamento

Atividades Artefato UMLIteração

Iníc. Elab.E1.E3

Análise Use Case------------------------Diagrama de Seqüência do Sistema (System Sequence Diagram)------------------------Modelo Conceitual------------------------Contrato

i

i

i

i

r

r

r

r

Design Diagrama de Interação entre Objetos (Object Sequence Diagram; Object Collaboration Diagram)------------------------Diagrama de Classe Detalhado

i-r

i-r


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 jogoo jogo inclui dois valores de face


Exemplo (2)

-- Modelo Conceitual (Versão #1) --


Exemplo (3)

-- Modelo Conceitual (Versão #2) --

JogoDeDados Dado21

Lança

Não estamos interessados na entidade JogadorJogador é apenas um usuário, ou ator


Exemplo (4)

-- Diagrama de Interação entre Objetos --

Jogador

Do jeito em que está, o jogador não sabe o resultado do jogo. Como sabê-lo?


Exemplo (5)

-- Diagrama de Classe --

Modifique o diagrama, para que o jogador saiba o resultado do jogo

© Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML.

Documents

Transcript of © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML.