Processo Unificado de Desenvolvimento de Software

1. Processo Unificado de Processo Unificado de
Desenvolvimento de SoftwareDesenvolvimento de Software
G. Booch, Ivar Jacobson, James Rumbaugh
Rational Software Corporation
UNIVERSIDADE FEDERAL DA PARAÍBA
DEPARTAMENTO DE SISTEMAS E COMPUTAÇÃO
© Ulrich Schiel

2. PRECURSORES
Object Modeling Technique - OMT de J. Rumbaugh,
M. Blaha, W. Premerlani, F. Eddy e W. Lorensen
(TMO - Técnica de Modelagem de Objetos), 1991
Objectology - A Use-Case Driven Approach de I. Jacobson,
M. Ericsson e A. Jacobson, 1992
Object Oriented Analysis and Design - OOA & OOD
de G. Booch, 1994

3. CARACTERÍSTICAS
í baseado em componentes que realizam interfaces
í usa UML
í aspectos:
* dirigido por Use-Cases
* centrado em arquitetura
* iterativo e incremental
í os 4 Ps:pessoal, projeto, produto e processo

4. P4 = Pessoa, Projeto, Produto, Processo
PESSOASPESSOAS financiam, escolhem, desenvolvem, gerenciam,
testam, usam e são beneficiadas por produtos
PROJETOSPROJETOS sofrem alterações. Determinam os tipos de pessoas
que irão trabalhar no projeto e os artefatos que serão usados
Sistema-i Sistema-i+1
ciclo
fase
iteração

5. P4 = Pessoa, Projeto, Produto, Processo
PRODUTOPRODUTO código fonte, código de máquina, subsistemas, classes,
diagramas: interação, de estados e outros artefatos
ARTEFATO é qualquer tipo de informação criada por uma pessoa
(diagramas UML, textos, modelos de interfaces)
PROCESSOPROCESSO define quem faz o que, quando e como
PUPU é um processo. Considera fatores organizacionais,
do domínio, ciclo de vida e técnicos

6. Modelos
REQUISITOSREQUISITOS - funcionais e não-funcionais
descrevem o sistema a ser desenvolvido,
sob um certo ponto-de-vista, e
seu ambiente, ou seja, os atores
ANÁLISEANÁLISE classes e responsabilidades
PROJETOPROJETO classes de projeto, subsistemas, interfaces
IMPLEMENTAÇÃOIMPLEMENTAÇÃO código fonte (DLLs, JavaBeams, ActiveX)
TESTETESTE casos de teste (baseado nos use-cases)
DISTRIBUIÇÃODISTRIBUIÇÃO nós físicos e os componentes em cada nó

7. Dirigido a Use-Cases
Um ator é uma pessoa ou outro sistema
Cada use-case é um requisito funcional do sistema
Modelo Use-Case = U use-cases = funcionalidade do sistema
Os Use-Cases acompanham todo o processo de desenvolvimento:
Especificação de Requisitos, Análise, Projeto, Implementação e Testes
Cada use-case representa uma sequência de ações que produzem
um resultado de utilidade para um ator

8. Dirigido a Use-Cases
Porque USE-CASES??
êCapturar os requisitos: o Diagrama Use-Case
mostra quais atores usam quais use-cases
Use-Cases Arquitetura do sistema
dirige
influi
êDirigir o processo: para realizar os use-cases são
definidos classificadores (classes, subsistemas,
interfaces) e relacionamentos (colaborações) entre estes
êElaborar a arquitetura, determinar iterações,
determinação dos manuais de usuário

9. Dirigido a Use-Cases
Classe de
fronteira
Classe de
controle
Classe de
entidades
Modelo
USE-CASE
Modelo
ANÁLISE
Modelo
PROJETO
Classe
Modelo
IMPLEMENT
<executável>
<arquivo>
<arquivo>
relacionamento

10. Dirigido a Use-Cases
êDirigir o processo:
ANÁLISE: definir as CLASSES DE ANÁLISE para realizar um
use-case (classes limite, classes de controle e classes de entidades)
PROJETO: ENTRADA: modelo de análise, pacote de construção de
interfaces, SGBD, sistemas existentes.
SAIDA: classificadores (classes, subsistemas, interfaces),
relacionamentos e colaborações
IMPLEMENTAÇÃO :criação de programas executáveis e arquivos
que realizam os use-cases
TESTE: casos de teste e procedimentos de teste. Testar entradas, resultados
e condições

11. Centrado na arquitetura
DECISÕES SOBRE:
• a organização do sistema como um todo
• os elementos estruturais, interfaces e seu comportamento
• composição de elementos estruturais e comportamentais
em subsistemas
A ARQUITETURA descreve as partes essenciais do sistema,
importantes para todos desenvolvedores
Menos de 10% das classes são relevantes para a arquitetura
Descrição de REQUISITOS ADICIONAIS: segurança,
distribuição, concorrência, plataformas, etc.

12. Centrado na arquitetura
Use-Cases
Plataforma de software
Disponibilidade de blocos
reusáveis
Sistemas existentes
Hardware existente
Requisitos não-funcionais
(performance, segurança)
Arquitetura
influem

13. Centrado na arquitetura
PRODUTO
Use-Case
Arquitetura
Sequência para o arquiteto:
Criar uma visão preliminar da arquitetura
Analisar os use-cases chave (5-10%) e especificar um subsistema
para cada um
Pela especificação dos subsistemas aparecem mais detalhes da
arquitetura e novos use-cases
Repetir o passo acima, até terminar o sistema
função
forma

14. 4 FASES
CONCEPÇÃO
CONSTRUÇÃO
ELABORAÇÃO
TRANSIÇÃO

15. Iterativo e incremental
Projetos grandes são divididos em mini-projetos
Cada mini-projeto é uma iteração
•Um grupo de use-cases que estendem usabilidade
Fatores de risco mais importantes
MINI-
PROJETO
Cada iteração gera um incremento
PORQUE ITERATIVO E INCREMENTAL
• atenuar riscos
• obter arquitetura robusta
• facilitar alterações táticas ou contínuas
• conseguir aprendizado mais cedo

16. Iterativo e incremental
ConcepçãoElaboraçãoConstrução Transição
Requisitos
Análise
Projeto
Implemen
tação
Testes
Iter.
#1
Iter.
#2
_ _ _ _ _Iter.
#n-1
Iter.
#n
Fases

17. Iterativo e incremental
Cada fase termina com um MARCO (milestone):
INICIOINICIO: o que o sistema fará? Como poderia ser a arquitetura?
Prazos e custos?
Um CICLO é uma sequência das 4 fases.
Um projeto pode necessitar de vários ciclos.
• identificar os riscos
• fixar subconjunto chave -> arquitetura candidata
• estimativas iniciais (custos, esforços, alocações e qualidade
do produto)
• iniciar caso gerencial (business case)

18. Iterativo e incremental
ELABORAÇÃOELABORAÇÃO : use-cases especificados e esqueleto da arquitetura definido
CONSTRUÇÃOCONSTRUÇÃO : software feito
TRANSIÇÃOTRANSIÇÃO: beta-teste feito por poucos usuários. Treinamento, documentação
• identificar e reduzir riscos de construção
• especificar maioria dos use-cases
• fixar a arquitetura em proporções executáveis
• preparar o plano de projeto (para a próxima fase)
• estimar e justificar o orçamento
• finalizar o business case
• iterações garantindo viabilidade em forma executável -> incrementos
• eliminar problemas e erros não identificados previamente

19. O O
PPROCESSO ROCESSO
UUNIFICADONIFICADO

20. EXEMPLO
Desenvolver um sistema de controle de vendedores ambulantes de um empresa.
A empresa dividiu cada cidade em que atua em regiões. Cada região é controlada
por um supervisor ao qual está subordinado um certo número de vendedores.
A empresa possui diversos pontos distribuídos na cidade. Todo dia os vendedores
passam pela empresa, de manhã, e registram, em um
boletim de controle, a hora da partida, o roteiro de visitas planejado e o número de
contratos de vendas que levaram. Ao final da tarde, cada vendedor passa por um
pontos, e registra o resultado das atividades do dia, ou seja, os contratos de venda
fechados.
Até as 20 horas, todos vendedores devem ter registrados suas produções
do dia. Cada ponto da empresa, processa a esta hora, um resumo das atividades
registradas e o remete para a central da empresa.
No outro dia o supervisor analisa os boletins recebidos e passa-os, com alguns
comentários, ao controle geral de vendas da empresa.
O supervisor, além de controlar a produção dos vendedores, registra o
recebimento de novos vendedores e a liberação deles para o departamento pessoal
que, por sua vez, controla a contratação, alocação, relocação e demissão de
vendedores e supervisores.

21. Modelos
Requisitos
ARTEFATOS
Análise
Projeto
Implementação
Testes
ARTÍFICES
PASSOS e
ATIVIDADES
produz
produzido-por
composto-por

22. Obtenção dos Requisitos
ARTEFATOS
è Modelo Use-Case
è ator
è Use-Case
è descrição da arquitetura

23. Obtenção dos Requisitos
ARTÍFICES
è Analista de sistemas
è arquiteto
è Especificador de Use-Case
è projetista de interfaces

24. Obtenção dos Requisitos
PASSOS
è listar potenciais requisitos
è entender o contexto do sistema
è capturar requisitos funcionais
è capturar requisitos não-funcionais

25. Obtenção dos Requisitos - Passos
è listar potenciais requisitos
Desenvolver uma lista de características obtidas de clientes,
usuários, analistas e desenvolvedores
CARACTERÍSTICA:
• nome
• breve descrição ou definição
• conjunto de valores
• Estado (proposto, aprovado, incorporado, validado)
•estimativa de custos
•prioridade (crítica, importante ou secundária)
• riscos (crítico, significante, ordinário)

26. Obtenção dos Requisitos - Passos
è entender o contexto do sistema
• criar um modelo do domínio
• objetos de negócio (pedidos, contas, contratos,..)
• objetos do mundo real (veículos, máquinas, trajetos,..)
• eventos básicos (chegada de um pedido, partida de um
transporte, ..)

í usar diagramas UML, em particular diagramas de classe

27. Obtenção dos Requisitos - Passos
è capturar requisitos funcionais
ARTÍFICE
ARTEFATO
Analista de Sistemas
Especificador de Use-Cases
Projetista de Interfaces
Arquiteto
•Modelo use-case
•atores
•glossários
Protótipos de interfaces
Use-cases
Arquitetura
r
e
s
p
o
n
s
á
v
e
l

28. Obtenção dos Requisitos - Passos
è capturar requisitos funcionais
ATIVIDADES E SUBPASSOS
u A1) encontrar os atores e use-cases
v encontrar os atores
v encontrar e descrever cada use-case
v descrever o Modelo Use-Case como um todo
u A2) Priorizar Use-Cases (visão arquitetural)

29. Obtenção dos Requisitos - Passos
è capturar requisitos funcionais
ATIVIDADES E SUBPASSOS
u A3) Detalhar cada Use-Case
v estruturar a descrição do use-case
(construir um diagrama de estados e analisar cada caminho)
v formalizar a descrição do use-case
(usar diagramas de estado, diagramas de atividade ou diagramas
de interação)
v descrever o Modelo Use-Case como um todo

30. Obtenção dos Requisitos - Passos
è capturar requisitos funcionais
ATIVIDADES E SUBPASSOS
u A4) Prototipar as interfaces com o usuário
v projeto lógico da interface do usuário
v projeto físico da interface do usuário e
protótipo

31. Obtenção dos Requisitos
PROJETO LÓGICO : para cada ator, ver todos use-cases nos
quais está envolvido e especificar os elementos de interação
(ícones, listas, campos, figuras, etc.)
N.B. a mesma interface (formulário) pode aparecer em diversos
use-cases para diversos atores!
QUESTÕES para determinar os elementos de interação:
• quais informações o ator fornece ao sistema?
• quais informações o ator necessita do sistema?
• com quais elementos de interação o ator trabalha?
• quais ações o ator pode acionar e quais decisões tomar?
•Quais classes de domínio ou entidades de negócio estão envolvidos
com elementos de interação?

32. Obtenção dos Requisitos
PROJETO FÍSICO:
• combinar elementos de interação para formar interfaces que
atendam a atores

• determinar elementos adicionais (folders, janelas, controles, etc.)
• desenvolver um protótipo para cada interface

33. Obtenção dos Requisitos
è capturar requisitos funcionais
ATIVIDADES E SUBPASSOS
A5) Estruturar o modelo Use-Case
v identificar funcionalidades comuns
(generalizações, <<estende>>)
v identificar funcionalidades adicionais ou opcionais
v identificar outros relacionamentos entre use-cases
(<<inclui>>, inverso de <<estende>>)

34. Obtenção dos Requisitos
è capturar requisitos não-funcionais
ATIVIDADES
u usabilidade
vrequisitos de interfaces metáfora, frequência de uso, ..
v documentação
u confiabilidade
v tolerância a falhas.

35. Obtenção dos Requisitos
è capturar requisitos não-funcionais
ATIVIDADES
u performance
v tempos de resposta
v volumes de transações
u requisitos físicos
v equipamentos, material, espaços, configurações de rede,
v software

36. Análise

37. Análise
Deve ser preciso e inambíguoPode conter redundâncias,
inconsistências, etc.
Usado para o desenvolvedor
entender o sistema
Usado para o contrato com o
cliente
Descreve como realizar a
funcionalidade
Captura a funcionalidade do
sistema
Estruturado por classesEstruturado por use-cases
Visão interna do sistemaVisão externa do sistema
Linguagem do desenvolvedorlinguagem do usuário
MODELO DA ANÁLISEMODELO USE-CASE
Os requisitos externos são transformados em um modelo interno
preciso e completo para desenvolver o projeto do sistema

38. Análise - artefatos
2. CLASSE
DE ANÁLISE
Classe de
fronteira
Classe de
controle
Classe de
entidades
EXEMPLO
Interface de
registro
processar
resumo do dia
Boletim de
controle
1. MODELO DA
ANÁLISE

39. Análise - artefatos
3. REALIZAÇÃO DE UM USE-CASE
u Diagramas de classe
uDiagramas de colaboração
Resultado
do dia
Processar
resumo
boletim
de controle
VENDEDOR
partida
Resumo do dia
SUPERVISOR
mostra
resumos
1.registra partida
3. registra retorno
2. abre boletim
3. completa boletim
5. dados boletim
6. Registra resumo
8. analisa resumo
9. comentários
7. mostra resumo
10. resumo
comentado
RELOGIO
4. 8 horas

40. Análise - artefatos
3. REALIZAÇÃO DE UM USE-CASE (cont.)
u requisitos especiais
u fluxo de eventos
Descrição textual de requisitos não-funcionais
Descrição textual do diagrama de colaboração
4. PACOTES DE ANÁLISE
PACOTE DE SERVIÇOS
Devem ter coesão e fraco acoplamento
•Candidatos a subsistemas do projeto
é um conjunto de ações coerentes, indivisíveis para uso
em vários use-cases
5. DESCRIÇÃO DA ARQUITETURA

41. Análise
è arquiteto
è Especificador de Use-Case
è Especificador de componentes
ARTÍFICES
• responsável pela integridade global do modelo de análise
(corretude, consistência e legibilidade),
tanto pela sua funcionalidade quanto pela arquitetura
• responsável que a realização de um use-case corresponde
a sua especificação
• responsável pelas classe de análise e pelos pacotes

42. Análise
PASSOS
è Análise arquitetural
è Análise de cada Use-Case
è Análise de cada classe
è Análise de cada pacote

43. Análise - passos
è Análise arquitetural
Análise
arquitetural
MODELO
USE-CASE
REQUISITOS
ADICIONAIS
MODELO
DO DOMÍNIO
DESCRIÇÃO
ARQUITETURA
(mod. Requisitos)
ARQUITETO
DESCRIÇÃO
ARQUITETURA
(mod. Análise)
CLASSE
DE ANÁLISE
(esboço)
PACOTE
ANÁLISE
(esboço)

44. Análise - passos
è Análise arquitetural
ATIVIDADES E SUBPASSOS
u A1) Identificar pacotes de análise
v Encontrar pacotes coesos e fracamente acoplados
v Identificar funcionalidades comuns entre pacotes
(pacotes genéricos)
v Identificar pacotes de serviço
(serviços opcionais, classes relacionadas funcionalmente)
v Dependências entre pacotes

45. Análise - passos
è Análise arquitetural (cont.)
A2) Identificar classes de entidades óbvias
Obtidas a partir das classe do domínio
A3) Identificar requisitos especiais comuns
v Persistência
v Distribuição e concorrência
vaspectos de segurança
v tolerância a falhas
v gerência de transações

46. Análise - passos
è Análise de cada Use-Case
• encontrar as classe de análise para realizar o use-case
• distribuir o comportamento do use-case entre as classes
• identificar requisitos especiais
Análise de um
Use-Case
MODELO
USE-CASE
REQUISITOS
ADICIONAIS
MODELO
DO DOMÍNIO
DESCRIÇÃO
ARQUITETURA
(mod Análise)
ESPECIFICADOR
DE USE-CASES
CLASSE
DE ANÁLISE
(esboço)
REALIZAÇÃO
DE UM USE-CASE
(diagramas de classes
e de colaboração)

47. Análise - passos
è Análise de cada Use-Case
u A1) Identificar classes de análise
v encontrar classes de entidades para armazenar as informações
do use-case
v para cada ator humano, determinar uma classe de fronteira
central (representa a janela principal)
v determinar as classe de fronteira que interagem com as classes
de entidade
v determinar, pelo menos, uma classe de controle que coordena o
use-case
CONSTRUIR UM DIAGRAMA DE CLASSES

48. Análise - passos
è Análise de cada Use-Case (cont.)
u A2) Descrever interações entre objetos
v construir um diagrama de colaboração
v toda classe de análise deve participar de algum diagrama de
colaboração
v dar maior ênfase às conexões e condições do que à sequência
v às conexões de mensagens podem corresponder associações do
diagrama de objetos ou não
v considerar as relações entre use-cases no diagrama
u A3) Determinar requisitos especiais

49. Resultado
do dia
Processar
resumo
boletim
de controleVENDEDOR
partida
Resumo do dia
mostra
resumos
1.registra partida
3. registra retorno
2. abre boletim
4. completa boletim
6. dados boletim
7. Registra resumo
9. analisa resumo
10. comentários
8. mostra resumo
11. resumo
comentado
5. 8 horas
Análise - passos
RELÓGIO
SUPERVISOR
è Análise de cada Use-Case (cont.)

50. Análise - passos
è Análise de cada classe
• identificar as responsabilidades de cada classe, baseado em sua função
na realização de use-cases
• definir os atributos e relacionamentos
• capturar requisitos especiais para cada classe
Análise
de uma classeREALIZAÇÃO
DE UM USE-CASE
(diagramas de classes
e de colaboração)
ESPECIFICADOR
DE COMPONENTES
CLASSE
DE ANÁLISE
(completa)
CLASSE
DE ANÁLISE
(esboço)

51. Análise - passos
è Análise de cada classe
u A3) Identificar associações e agregações
u A2) Definir os atributos
v tipos de atributos são conceituais
v classes com muitos atributos podem ser divididas
v atributos de classes de fronteira são campos em interfaces
vclasses de controle geralmente não tem atributos
u A1) Identificar responsabilidades
v Determinar os papéis de cada classe nos diferentes use-cases
u A4) Identificar generalizações
u A5) Determinar requisitos especiais

52. Análise - passos
è Análise de cada pacote
v Rever as dependências entre pacotes de acordo com associações
estáticas ou dinâmicas entre as classes, criadas nos passos
anteriores
v Garantir que cada pacote preenche sua função
v Rever as questões de acoplamento fraco e coesão

53. Projeto
• adquirir uma compreensão de aspectos de requisitos
não funcionais e restrições sobre linguagens de programação,
sistemas operacionais, SGBDs, aspectos de distribuição, etc.
.
• Criar informações suficientes para a implementação, descre-
vendo subsistemas, interfaces e classes.
• Estar apto a dividir a tarefa de implementação em equipes
• Determinar mais cedo as interfaces entre os subsistemas
• Criar um modelo que possibilite uma implementação
que preencha as estruturas definidas sem altera-las
OBJETIVOS

54. Projeto
MODELO DE ANÁLISE MODELO DE PROJETO
conceitual físico
Genérico (c.r. projeto)específico
3 tipos de classes Depende da implementação
Menos formal Mais formal
Mais rápido (1/5 do projetoMais demorado (5 x análise)
Poucos níveis Muitos níveis
Menos dinamica Mais dinâmica, foco na
sequencia
Não se mantém no cicloSe manté em todo ciclo

55. Projeto - artefatos
1. MODELO DE PROJETO
É uma hierarquia de subsistemas contendo
classe de projeto, projetos de use-cases e interfaces
2. CLASSE DE PROJETO
• na linguagem de programação da implementação
• visibilidade dos atributos (ex. publico, protegido, privado)
• generalizações g herança;
• associações e agregações a atributos
• métodos em pseudo-código

56. Projeto - artefatos
3. REALIZAÇÃO DO USE-CASE
u Diagrama de classes
u Diagrama de interações (diagramas de sequência)
u Fluxo de eventos (textual)
u Requisitos de implementação

57. Projeto - artefatos
7. MODELO DE DISTRIBUIÇÃO
(Diagrama de nós e conexões)
5. INTERFACE (separa funcionalidade de implementação)
6. ARQUITETURA (VISÃO DO PROJETO)
(1. Subsistemas, interfaces e dependências
2. Classes chave, classes ativas
3. Realização de use-cases centrais ao sistema
4. SUBSISTEMA DE PROJETO
(pacotes de análise, componentes, produtos de software,
sistemas existentes) - SUBSISTEMAS DE SERVIÇO
8. ARQUITETURA (VISÃO DO MODELO DE DISTRIBUIÇÃO)

58. Projeto - artífices
è Arquiteto
è Especificador de use-cases
è Especificador de componentes
MODELO DO PROJETO
ARQUITETURA
MODELO DE DISTRIBUIÇÃO
REALIZAÇÃO DE USE CASE
CLASSE DE PROJETO
SUBSISTEMA
INTERFACE

59. Projeto - passos
Projeto de
um use-case
Projeto de
uma classe
Projeto de
um subsistema
Projeto da
arquitetura
ARQUITETO
ESPECIFICADOR
DE COMPONENTES
ESPECIFICADOR
DE USE-CASES

60. Projeto - passos
è Projeto da arquitetura
u A1) Identificar nós e configurações de rede
v determinar os nós envolvidos e suas características
v determinar os tipos de conexões entre os nós
v verificar necessidades de processamentos redundantes,
backups, etc.

61. Projeto - passos
è Projeto da arquitetura (cont.)
u A2) Identificar subsistemas e suas interfaces
v subsistemas da aplicação
v identificar middleware
(SO, SGBD, software de comunicação, pacotes GUI, distribuição, etc.)
v definir dependências entre os subsistemas
v identificar as interfaces entre os subsistemas
Pacote (análise)
Subsistema novo
Software existente
Não serve como subsistema
É integrado com sistemas existentes

62. Projeto - passos
è Projeto da arquitetura (cont.)
u A3) Identificar classes de projeto significativas
v a partir das classes de análise
v classes ativas
(requisitos de concorrência, performance, inicialização, distribuição,
prevenção de deadlocks)

u A4) outros requisitos de projeto
(persistência, transparência de distribuição, segurança, recuperação
de erros, gerência de transações)

63. Projeto - passos
è Projeto de um use-case
u A1) Identificar classes de projeto participantes
v estudar as classes de análise
v identificar classes que realizam os requisitos especiais da análise
v definir as classes de projeto e passar para o projetista de
componentes
OBJETIVO:
• identificar classes de projeto
• distribuir o comportamento entre os objetos
• definir requisitos das operações
• requisitos de implementação do use-case

64. Projeto - passos
è Projeto de um use-case (cont.)
u A2) Descrever a interação entre objetos
v o use-case é acionado por uma mensagem de um ator a um objeto
v traçar um ou vários diagramas de sequência
v utilize nomes e textos (fluxo de eventos) para descrever as
sequências
v considere as associações entre use-cases no diagrama de sequência

65. Projeto - passos
è Projeto de um use-case (cont.)
u A3) Identificar subsistemas e interfaces
v identificar os subsistemas obtidos a partir de pacotes deste use-case
v verifique se há classes de projeto especiais e seus subsistemas
u A4) Descrever a interação entre subsistemas
v a partir dos caminhos no diagrama se sequência determinar a
interação
v determinar qual interfaces é utilizada por qual mensagem

66. Projeto - passos
è Projeto de uma classe
A1) Definir uma classe de projeto
v a partir de classes de fronteira : depende da linguagem
v classes de entidades persistentes podem produzir tabelas relacionais
v classes de controle podem gerar várias classes de projeto
(distribuição) ou serem encapsuladas em classes de entidades
ASPECTOS:
• atributos
• operações e sua realização
• relacionamentos
• estados
• dependências
• interfaces
• requisitos de implementação

67. Projeto - passos
è Projeto de uma classe (cont.)
A2) Definir operações
v realizar as responsabilidades da classe
v requisitos especiais (e.g. acesso ao banco de dados)
v atender às necessidades das interfaces da classe
A3) Definir atributos
v considerar os atributos da análise
v os tipos dos atributos são determinados pela linguagem de
programação
v valores de atributos usados por vários objetos devem ser
transformados em objetos

68. Projeto - passos
è Projeto de uma classe (cont.)
A4) Identificar associações e agregações
v dependendo da linguagem, transformá-los em relacionamentos
v tentar transformar cardinalidades, papéis, etc. em atributos ou
em novas classes para realizar a associação
v analise a navegabilidade pelas associações
A5) Identificar generalizações
A6) Descrever métodos
v realização de operações por pseudo-código, diagramas de atividades,
linguagem natural,..
A7) Descrever estados
v diagrama de estados

69. Projeto - passos
è Projeto de um subsistema
A1) Rever as dependências entre subsistemas
v
A2) Rever as interfaces
v
A3) Rever o conteúdo

70. Implementação - artefatos
1. MODELO DA IMPLEMENTAÇÃO
2. COMPONENTE
3. SUBSISTEMA DE IMPLEMENTAÇÃO
4. INTERFACE
5. ARQUITETURA (visão da implementação)
6. PLANO DE INTEGRAÇÃO

71. Implementação - artefatos
1. MODELO DA IMPLEMENTAÇÃO
É uma hierarquia de subsistemas de implementação
contendo componentes e interfaces
2. COMPONENTE
• <<executable>> (programa executável)
• <<file>> (arquivo contendo código fonte ou dados)
• <<library>> (biblioteca estática ou dinâmica)
• <<table>> (tabela do banco de dados)
• <<document>> (um documento)
É UM PACOTE CONTENDO ELEMENTOS DO PROJETO
Estereótipos:

72. Implementação - artefatos
2. COMPONENTE - exemplos
<<executable>>
ProcessaBoletim.java
<<table>>
Resumo
BOLETIM
__________
__________
RESUMO
__________
__________
<<table>>
Contrato
realiza
realiza
gera
gera

73. Implementação - artefatos
3. SUBSISTEMAS DE IMPLEMENTAÇÃO
• um package em Java
•um project em Visual Basic
•um diretório de C++
CORRESPONDÊNCIA 1-1 COM SUBSISTEMAS DE PROJETO
4. INTERFACES
Implementam as interfaces do projeto

74. Implementação - artefatos
5. ARQUITETURA (visão da implementação)
6. PLANO DE INTEGRAÇÃO
•Decomposição em subsistemas, compostos de interfaces
e componentes
•Componentes chave
• Primeira versão executável
• testes localizados de integração para facilitar a detecção de
erros
• versão final

75. Implementação - artífices
è Arquiteto
è Integrador do sistema
è Engenheiro de componentes
MODELO DA IMPLEMENTAÇÃO
DESCRIÇÃO DA ARQUITETURA
MODELO DE DISTRIBUIÇÃO
PLANO DE INTEGRAÇÃO
COMPONENTE
SUBSISTEMA DE
IMPLEMENTAÇÃO
INTERFACE

76. Implementação - artífices

77. Implementação
PASSOS
è Implementação arquitetural
è Integrar sistemas
è Implementar subsistema
è Testar componentes
è Implementar uma classe

78. Projeto - passos
Integrar
sistemas
Implementar
uma classe
Implementar
um subsistemaImplementação
arquitetural
ARQUITETO
ENGENHEIRO DE
COMPONENTES
INTEGRADOR
DE SISTEMAS
Teste de
unidade

79. Implementação - passos
è Implementação arquitetural
u identificar componentes significativos
è Integrar sistemas
u determinar sequência de construção
u integrar construções
(compilar e linkar novos componentes)

80. Implementação - passos
è Implementar subsistema
u garantir conteúdo do subsistema
è Implementar uma classe
u implementar métodos
u determinar operações/métodos auxiliares

81. Teste
OBJETIVOS
J Planejar os testes em cada iteração, tanto os
testes de integração quanto os testes de sistema
J preparar casos de teste, criar procedimentos de teste e
procedimentos executáveis
J Realizar os testes e analisar os resultados

82. Teste - artefatos
1. MODELO DE TESTE
J Planejar os testes em cada iteração, tanto os
os testes de integração quanto os testes de sistema
J preparar casos de teste, criar procedimentos de teste e
procedimentos executáveis
J Realizar os testes e analisar os resultados
2. CASO DE TESTE

83. Fases X Etapas
ConcepçãoElaboraçãoConstrução Transição
Requisitos
Análise
Projeto
Implemen
tação
Testes
Iter.
#1
Iter.
#2
_ _ _ _ _Iter.
#n-1
Iter.
#n
Fases

84. As quatro Fases
è Fase de Concepção
u estabelece o business case (prioridade de negócio)
J Delimitar o escopo do sistema
J Determinar arquitetura candidata (elementos novos, arriscados)
J Identificar riscos críticos
J Identificar potenciais usuários ou clientes do sistema
Passos

85. As quatro Fases
è Fase de Elaboração
u determina uma arquitetura estável
J Determinar linha base da arquitetura cobrindo funcionalidades
significantes
J Identificar riscos críticos que podem derrubar planos, orçamentos,
e prazos
J Determinar níveis de qualidade (confiabilidade, tempos de resposta)
J Definir use-cases que cobrem ca. de 80% da funcionalidade do
sistema
J Determinar limites de pessoal, custos, prazos.
Passos

86. As quatro Fases
è Fase de Construção
u determina capacidades operacionais iniciais
J Estender o modelo de use-cases para toda a aplicação
J Finalizar a análise, projeto, implementação e testes
J Checar integridade da arquitetura (com possíveis alterações)
J Monitorar ricos críticos
Passos

87. As quatro Fases
è Fase de transição
u transforma versão beta em um sistema operacional
J Preparar atividades de transição
J Avisar clientes sobre mudanças no ambiente (hardware, software,
distribuição, ..)
J Preparar documentação final
J Carregar o novo sistema
J Corrigir possíveis defeitos detectados no beta-teste
Passos

88. Iterativo e incremental
u Uma ITERAÇÃO genérica é composta pelas 5 etapas:
Requisitos, Análise, Projeto, Implementação e Testes
Após cada iteração ou cada fase:
• planejar a próxima iteração à luz da experiência anterior
• modificar o processo, adaptar ferramentas, treinamento, etc.

89. Iterativo e incremental
requisitos análise projetoImplement. testes
planejamento consolidação
ITERAÇÃO

90. Iterativo e incremental
Planejando as
ITERAÇÕES
Planejando as FASES
• tempos por fase
• milestones
• iterações por fase
• plano do projeto
• cronograma
• conteúdo:
- quais use-cases serão realizados
- iterações anteriores e posteriores

91. Riscos
Possíveis riscos:
Gerenciar uma
lista de riscos:
• descrição
• prioridade (crítico, signifcante, rotineiro)
• impacto
• responsabilidades
• contingência (o que fazer?)
• relacionados a um produto
• não conseguir a arquitetura
• não realizar os requisitos