© nabor c. mendonça 2001 1 metodologia (r)up + uml
TRANSCRIPT
![Page 1: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/1.jpg)
© Nabor C. Mendonça 2001 1
Metodologia (R)UP + UML
![Page 2: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/2.jpg)
© Nabor C. Mendonça 2001 2
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
![Page 3: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/3.jpg)
© Nabor C. Mendonça 2001 3
I. A Motivação para o Modelo Iterativo e a Tecnologia de Objetos
Baseado em uma apresentação de Craig Larman
![Page 4: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/4.jpg)
© Nabor C. Mendonça 2001 4
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
![Page 5: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/5.jpg)
© Nabor C. Mendonça 2001 5
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
![Page 6: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/6.jpg)
© Nabor C. Mendonça 2001 6
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
![Page 7: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/7.jpg)
© Nabor C. Mendonça 2001 7
Instabilidade dos Requisitos
O mercado muda — constantemente
As tecnologias mudam — inevitavelmente
A vontade e objetivos dos usuários mudam — imprevisivelmente
![Page 8: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/8.jpg)
© Nabor C. Mendonça 2001 8
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
![Page 9: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/9.jpg)
© Nabor C. Mendonça 2001 9
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
![Page 10: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/10.jpg)
© Nabor C. Mendonça 2001 10
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
![Page 11: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/11.jpg)
© Nabor C. Mendonça 2001 11
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
– …
![Page 12: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/12.jpg)
© Nabor C. Mendonça 2001 12
Portanto...
![Page 13: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/13.jpg)
© Nabor C. Mendonça 2001 13
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
![Page 14: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/14.jpg)
© Nabor C. Mendonça 2001 14
Um Processo Iterativo Popular — RUP
Atenção: as fases não são iterações!
![Page 15: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/15.jpg)
© Nabor C. Mendonça 2001 15
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
![Page 16: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/16.jpg)
© Nabor C. Mendonça 2001 16
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
![Page 17: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/17.jpg)
© Nabor C. Mendonça 2001 17
O Custo da Mudança
Um estudo da AT&T indicou que, na média,
![Page 18: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/18.jpg)
© Nabor C. Mendonça 2001 18
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:
![Page 19: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/19.jpg)
© Nabor C. Mendonça 2001 19
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)
![Page 20: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/20.jpg)
© Nabor C. Mendonça 2001 20
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)
![Page 21: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/21.jpg)
© Nabor C. Mendonça 2001 21
II. UML: uma Visão GeralGrady Booch
![Page 22: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/22.jpg)
© Nabor C. Mendonça 2001 22
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
![Page 23: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/23.jpg)
© Nabor C. Mendonça 2001 23
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
![Page 24: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/24.jpg)
© Nabor C. Mendonça 2001 24
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
![Page 25: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/25.jpg)
© Nabor C. Mendonça 2001 25
III. A Metodologia em Detalhes
![Page 26: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/26.jpg)
© Nabor C. Mendonça 2001 26
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)
![Page 27: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/27.jpg)
© Nabor C. Mendonça 2001 27
O Conceito de Iteração (2)
-- Desenvolvimento Iterativo e Incremental --
![Page 28: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/28.jpg)
© Nabor C. Mendonça 2001 28
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
![Page 29: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/29.jpg)
© Nabor C. Mendonça 2001 29
O Conceito de Iteração (4)
-- Risco Potencial Pequeno, no Final --
![Page 30: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/30.jpg)
© Nabor C. Mendonça 2001 30
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
![Page 31: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/31.jpg)
© Nabor C. Mendonça 2001 31
O Conceito de Iteração (6)
![Page 32: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/32.jpg)
© Nabor C. Mendonça 2001 32
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
![Page 33: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/33.jpg)
© Nabor C. Mendonça 2001 33
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
![Page 34: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/34.jpg)
© Nabor C. Mendonça 2001 34
Características Gerais do Processo (3)
![Page 35: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/35.jpg)
© Nabor C. Mendonça 2001 35
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
![Page 36: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/36.jpg)
© Nabor C. Mendonça 2001 36
Fase de Planejamento (2)
1. Plano Inicial (Business Case)
![Page 37: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/37.jpg)
© Nabor C. Mendonça 2001 37
Fase de Planejamento (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
![Page 38: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/38.jpg)
© Nabor C. Mendonça 2001 38
Fase de Planejamento (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
![Page 39: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/39.jpg)
© Nabor C. Mendonça 2001 39
Fase de Planejamento (5)
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
. . .
![Page 40: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/40.jpg)
© Nabor C. Mendonça 2001 40
Fase de Planejamento (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
![Page 41: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/41.jpg)
© Nabor C. Mendonça 2001 41
Fase de Elaboração
Iteração 1
Sinc.Artefatos Análise Design Teste
Refin.Plano Impl.
Iteração 2 ...
ElaboraçãoPlaneja-mento Construção
![Page 42: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/42.jpg)
© Nabor C. Mendonça 2001 42
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
![Page 43: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/43.jpg)
© Nabor C. Mendonça 2001 43
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
![Page 44: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/44.jpg)
© Nabor C. Mendonça 2001 44
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
![Page 45: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/45.jpg)
© Nabor C. Mendonça 2001 45
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
![Page 46: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/46.jpg)
© Nabor C. Mendonça 2001 46
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
![Page 47: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/47.jpg)
© Nabor C. Mendonça 2001 47
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
![Page 48: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/48.jpg)
© Nabor C. Mendonça 2001 48
Exemplo (2)
-- Modelo Conceitual (Versão #1) --
![Page 49: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/49.jpg)
© Nabor C. Mendonça 2001 49
Exemplo (3)
-- Modelo Conceitual (Versão #2) --
JogoDeDados Dado21
Lança
Não estamos interessados na entidade JogadorJogador é apenas um usuário, ou ator
![Page 50: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/50.jpg)
© Nabor C. Mendonça 2001 50
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?
![Page 51: © Nabor C. Mendonça 2001 1 Metodologia (R)UP + UML](https://reader035.vdocuments.mx/reader035/viewer/2022081602/552fc0f8497959413d8b4d99/html5/thumbnails/51.jpg)
© Nabor C. Mendonça 2001 51
Exemplo (5)
-- Diagrama de Classe --
Modifique o diagrama, para que o jogador saiba o resultado do jogo