Você está na página 1de 85

O Processo de Desenvolvimento

(UP/RUP)

Mestrado em Ciência da Computação


Disciplina: Engenharia de Software
Profa. Dra. Elisa H. M. Huzita

ES-rup-análise-2003
Processo de Desenvolvimento de Software

O processo de desenvolvimento de software é um


conjunto de atividades e resultados associados que
tem por objetivo produzir software eficiente, de alta
qualidade, com baixa taxa de erros e que atenda às
necessidades e expectativas do usuário de forma
geral, JACOBSON (1999).

ES-rup-análise-2003
Processo de Desenvolvimento de
Software
O processo define quem irá fazer o que e como será
atingido o objetivo. Entende-se por objetivo a
construção de um software ou a melhoria de um
existente.

ES-rup-análise-2003
Boas Práticas

desenvolver o software iterativamente :


z waterfall x iterativo e incremental ( possíveis
soluções que seriam derivadas para os problemas de
desenvolvimento?)

gerenciar requisitos :
z o desafio: os requisitos são dinâmicos
(possíveis soluções que seriam derivadas para os
problemas de desenvolimento?)
z Requisito = condição ou capacidade que um
sistema deve satisfazer.
ES-rup-análise-2003
Boas Práticas
z o gerenciamento de requisitos envolve:
z elicitar, organizar e documentar as funcionalidades
e restrições do sistema;
z avaliar as modificações e seus impactos e
z documentar compromissos e decisões.

ES-rup-análise-2003
Boas Práticas
usar arquiteturas baseada em componentes: possibilita o
reuso ou customização de componentes.
z iteração + CBD : a cada iteração pode-se medir, testar e
avaliar em relação aos requisitos.

modelar visualmente o software: ajuda a melhorar a


habilidde da equipe para gerenciar a complexidade do
software. (possíveis soluções que seriam derivadas para os
problemas de desenvolvimento?)
z Um modelo é uma simplificação da realidde que descreve
completamente um sistema de uma perspectiva em
particular.
ES-rup-análise-2003
Boas Práticas

verificar continuamente a qualidade do


software: em relação à sua funcionalidade,
confiabilidade, desempenho - testar cenários
controlar modificações do software: grandes
equipes e sistemas complexos um controle
coordenado de modificações para manter a
consistência.

ES-rup-análise-2003
O que é a RUP
é um processo de engenharia de software: provê uma
abordagem disciplinada - por todo o ciclo de vida
para assinalar tarefas e responsabilidades dentro de
uma organização;
é um process product: existe toda uma família de
produtos / ferramentas para dar o suporte;
é um process framework: pode ser adaptado e
extendido para satisfazer as necessidades da
organização que está adotando;
é dirigido a use case;
segue as boas práticas de desenvolvimento.
é uma especialização do UP
ES-rup-análise-2003
Caracterísitcas do UP

Dirigido a use-case - os use-cases estão presentes desde a


captura dos requisitos até a realização dos testes do
sistema.
Centrado na arquitetura - significa que um sistema de
arquitetura é usado como um artefato primário para
conceituação, construção, gerenciamento e evolução do
sistema no processo de desenvolvimento

ES-rup-análise-2003
Caracterísitcas do UP

Desenvolvimento iterativo e incremental - cada


parte do projeto , passa por todas as fases de
desenvolvimento (inicio, elaboração, construção e
transição). Cada workflow pode ser repetido (iteração)
até que se atinja as necessidades do projeto. Em cada
nova iteração os riscos são identificados e analisados.

ES-rup-análise-2003
Elementos da Modelagem
Processo: descreve quem está fazendo o que,
como e quando.

No UP:
z Worker: “quem” - descreve o comportamento
do indivíduo no negócio e as
responsabilidades.
z Exs: analista de sistema;
projetista,
gerente de projeto,
projetista de interface,
gerente de configuração
ES-rup-análise-2003
Elementos da Modelagem

z Atividades: como - unidade de trabalho que o


indivíduo com um determinado papel deve
executar e produzir um resultado no contexto do
projeto.
z Ex: planejar uma iteração - gerente de projeto;
encontrar atores e use case - analista de
sistema;
z Artefatos: o que - pedaço de informação que é
produzido, modificado ou usado por um processo.
z Ex: um modelo de projeto

z Workflow: quando - sequência de atividades que


produzem um resultado de valor.
ES-rup-análise-2003
Workflow do RUP

de engenharia de suporte
* modelagem do negócio * gerenciamento de projeto
* requisitos * gerenciamento de
* análise e projeto configuração e de
* implementação modificação
* teste * ambiente
* entrega

ES-rup-análise-2003
Arquitetura do UP

ES-rup-análise-2003
Ciclo de Vida UP

como vencer pontos fracos do modelo


cascata?
z Iterações
como garantir que o projeto está
convergindo?
z Fases e Milestones

ES-rup-análise-2003
Vantagens da Iteração

riscos são amenizados antecipadamente;


as modificações são melhor gerenciáveis;
existe um maior grau de reuso;
a equipe de projeto pode aprender ao longo do
processo;

o produto é de melhor qualidade.

ES-rup-análise-2003
Ciclo de Vida UP
O ciclo de vida está organizado em:
z fases: inicio, elaboração, construção e transição
z workflows: requisitos, análise, projeto, implementação e
teste

Cada fase pode ser dividida em um ou mais


iterações e termina com um maior ou menor
milestone respectivamente.
Cada ciclo resulta em uma nova release do sistema,
e cada release é um produto pronto para entrega.
ES-rup-análise-2003
Inicial Elaboração Construção Transição

Milestone Milestone Milestone Milestone


objetivo Arquitetura Capaciadade release
ciclo vida ciclo vida operacional produto

ES-rup-análise-2003
As Fases...
a)Inicial:
entender os requisitos e determinar o escopo do
projeto
Concentra-se em:
z delimitar o escopo do sistema proposto,
z descrever ou delinear a arquitetura do sistema (principalmente
as partes do sistemas que são novas, de risco ou apresentam
dificuldades),
z identificar os riscos críticos,
z construir um protótipo do sistema proposto comas idéias
básicas do novo sistema
Pode-se decidir por continuar ou abandonar.
ES-rup-análise-2003
As Fases...

b) elaboração:
Concentra-se em:
z Elaborar a arquitetura básica do sistema proposto,
z identificar e detalhar os use-cases,
z desenvolver um plano de projeto e eliminar os
elementos de maior risco para o projeto.

ES-rup-análise-2003
As Fases...

Construção: é o desenvolvimento do produto


propriamente dito
Concentra-se em:
z Implementar, testar e integrar os mini-projetos
para compor o sistema como um todo
z Completar o desenvolvimento dos use-case
z Disponibilizar a versão beta

ES-rup-análise-2003
As Fases...

Transição: é considerada uma espécie de


período de análise pelos usuários do produto
desenvolvido
Concetra-se em:
z implantar o produto no ambiente ,
z adequar às características desse ambiente,
z proporcionar treinamento aos usuários,
z oferecer assistência técnica.

ES-rup-análise-2003
Workflow do UP

* requisitos
* análise
* projeto
* implementação
* teste

ES-rup-análise-2003
Workflow Requisitos

1) Objetivos:
estabelecer e manter um acordo com os clientes
e outros stakeholders sobre o que o sistema faria
e porque;
prover os desenvolvedores do sistema com um
melhor entendimento dos requisitos do sistema;
definir os limites do sistema;
prover uma base para planejamento do conteúdo
técncio das iterações;

ES-rup-análise-2003
Workflow Requisitos

prover uma base para estimar custo e tempo


para desenvolver o sistema;
definir uma interface do usuário

ES-rup-análise-2003
Domínio x negócio

Modelo do Domínio X Modelo do Negócio

parte todo
Às vezes parte coincide com o todo
Modelo do domínio modelo de software

ES-rup-análise-2003
Artefatos
1) Artefatos
a) Modelo De Use Case
z desenvolvedores de software e clientes entram
em acordo sobre os requisitos.
z modelo contendo os atores e use case e suas
relações.

ES-rup-análise-2003
ES-rup-análise-2003
Artefatos

b) Ator:
z Usuário;
z Worker;
z o papel desempenhado;
z sistema externo que o sistema interage;
z partes fora do sistema que colaboram com o
sistema.
z identificados os atores de um sistema
identificou o ambiente externo do sistema.

ES-rup-análise-2003
Artefatos

C) Use Case
especifica uma sequência de ações incluindo
alternativas de sequencia que o sistema pode
executar, interagindo com os atores do sistema.
c1) fluxo de eventos:
z capturado como uma descrição textual da sequencia
de ações do use case.
z especifica como o sistema interage com atores quando
o use case é executado.
c2) requisitos especiais: requisitos não funcionais sobre
um use case.

ES-rup-análise-2003
Artefatos

d) Descrição Da Arquitetura
z visão arquitetural do modelo de use case
inclui use case com funcionalidade crítica ou
importante, envolve requisito importante que deve
ser desenvolvido.
e) Glossário
z definir os conceitos, notações e termos
importantes e comuns usados pelos analistas ( e
outros desenvolvedores).
z é útil para alcançar um consenso entre os
desenvolvedores.

ES-rup-análise-2003
Artefatos

f) Protótipo Da Interface Do Usuário


z ajudam a capturar e entender as interações
específicas entre os atores humanos e o sistema
e também entender melhor os use case.

ES-rup-análise-2003
Worker

3) workers:
analista de sistema é o responsável por:
z delimitar o sistema,
z encontrar os atores e os use case
z garantir que o modelo de use case está completo e
consistente.
z liderar a modelagem e coordenar a captura de
requisitos
especificador de use case: é o responsável por:
z detalhar as descrições de use case e dar suporte ao
analista.
ES-rup-análise-2003
workers

projetista de interface do usuário


arquiteto:
z descrever a visão arquitetural do modelo use
case

ES-rup-análise-2003
Workflow (requisitos com workers e
artefatos)

ES-rup-análise-2003
Workflow

a) encontrar atores e use case


z por que use case e atores?
z (i) delimitar o sistema;
z (ii) esboçar quem/o que (atores) irá interagir
com o sistema e a funcionalidade (use case)
esperado do sistema;
z (iii) capturar e definir um glossário de termos
comuns descrever funcionalidade do
sistema.

ES-rup-análise-2003
As entradas e saídas de identificar atores e use case

ES-rup-análise-2003
Workflow

Etapas:
z a1) encontrar atores:
z se existe um modelo de negócio : é direto.
z um ator para cada worker no negócio
z e um ator para cada ator de negócio (isto é cada
cliente do negócio) que irá usar o sistema de
informação.
z se não, identificar com o cliente os usuários e
tentar organizá-los em categorias:
z os atores relevantes e
z sem sobreposição de papéis

ES-rup-análise-2003
Workflow

- a2) encontrar use case:


z um para todo papel de cada worker que participa na
realização do use case do negócio
z para se chegar a um use case podem ser necessárias
várias interações com o usuário.
z use case deve ser fácil de modificar, rever, testar e
gerenciar como unidade.
z definir escopo do use case : alguns são completos por
si só, outros pertencem a uma “cadeia”.
z use case executado com sucesso valor para o
ator alcançar algum objetivo.
ES-rup-análise-2003
Workflow

-a3) descrever brevemente cada use case


-a4) descrever o modelo de use case :
z Esta etapa inclui :
z preparar glossário de termos usados,
z se necessário, organizar o modelo de use case como
pacotes de use case
z preparar uma descrição survey - revisão para:
z requisitos funcionais foram capturados como use
case?
z a sequencia de ações está correta, completa e
entendivel para cada use case
z algum use case prove pouco ou nenhum valor?

ES-rup-análise-2003
Workflow

Resultados:
uma versão do modelo use case com
atores e use case novos ou
modificados.

ES-rup-análise-2003
Workflow

b) estabelecer prioridade entre os use case:


determinar/planejar use case a serem
implementados em iterações iniciais os que
serão postergados.

ES-rup-análise-2003
Workflow
c) detalhar use case:
z descrever para cada use case o fluxo de eventos em
detalhe, como o use case inicia, termina e a interface
com os atores.
z deve-se definir:
z todos os caminhos alternativos do use case:
z estado inicial (pré-condição) e final (pós-condição)
z a ordem - sequencia numerada - em que as ações devem
ser executadas,
z caminhos não permitidos (ex. pagar uma conta 2 vezes)
z a interação do sistema com os atores (mensagens e
resultados)
z descrever as ações do sistema e dos atores

ES-rup-análise-2003
Workflow

z quando encerrar as descrições ?


z os requisitos podem ser entendidos em profundidade,
z de forma correta ,
z completo,
z consistentes.

z como formalizar a descrição ?


z statechart,
z diagramas de atividades,
z diagramas de interação.

ES-rup-análise-2003
Workflow

resultado:
z descrição detalhada de um particular use
case: em texto e diagramas.

ES-rup-análise-2003
Workflow

d) construir protótipo da interface do usuário: {protótipos


e esboços de interfaces que especificarão o look and feel
das interfaces para os atores mais importantes }.
z Na construção do protótipo verificar (por ex.):
z como os use case se relacionam;
z dados que seriam manipulados;
z elementos da interface que o ator usa?
z ações/decisões que o ator toma?
z informações/diretrizes necessárias antes que o ator chame
cada ação no use case?
z informações necessárias ao sistema?

ES-rup-análise-2003
Workflow

e) estruturar o modelo de use case: pode ser


necessário explicitar relações include/extend.

ES-rup-análise-2003
Participante

Coordenador de Participante
Controlar Crachá

Controlar Certificado
Co orden ador do Com itê Científi co

Controlar Participante

Cadas trar Atividade

Coord enador do

Gerenciar Evento

Coordenador de Program ação

Geren cia r Progr am ação

ES-rup-análise-2003
SUMÁRIO DO WORKFLOW REQUISITOS:

z um modelo de negócio ou de dominio;


z um modelo use case: requisitos funcionais/ não
funcionais específicos a cada use case;
z protótipos/projeto de interfaces;
z especificação de requisitos suplementares para
os requisitos genéricos.

ES-rup-análise-2003
Workflow Análise

ES-rup-análise-2003
Análise

OBJETIVOS DA ANÁLISE:
z manter uma especificação precisa dos requisitos
através do modelo de análise;
z descrever o modelo de análise usando a
linguagem dos desenvolvedores
z um modelo de análise estrutura os requisitos em
uma forma que facilita o entendimento deles,
preparando-os, modificando-os e em geral
mantendo-os
z um modelo de análise é o primeiro passo para o
modelo de projeto.

ES-rup-análise-2003
modelo use case modelo análise
descrito usando a linguagem do cliente descrito usando a linguagem do
desenvolvedor
visão externa do sistema visão interna do sistema
estruturado por use case: da a estrutura da estruturado por classes estereótipos e
visão externa pacotes; dá a visão da estrutura interna
usado principalmente como um contrato usado principalmente pelos
entre o cliente os desenvolvedores sobre o desenvolvedores para entender como o
que o sistema seria e não faria sistema seria projetado e implementado
pode conter redundâncias, inconsistências não conteria redundâncias, inconsistências
entre os requisitos entre os requisitos
captura a funcionalidade do sistema esboça como realizar a funcionalidade
incluindo funcionalidade significativa dentro do sistema, incluindo a
arquiteturalmente funcionalidade significativa
arquiteturalmente, trabalha como um
primeiro passo para o projeto
define os use case que são depois analisados define as realizações de use case, cada um
no modelo de análise representando a análise de um use case do
modelo de use case
ES-rup-análise-2003
Artefatos

a) modelo de análise:
constituído da análise de sistema que é o
pacote do nível de topo, constituído de
pacotes de análise, classes de análise e use
case-realization - análise

Figura do modelo de análise

ES-rup-análise-2003
ES-rup-análise-2003
Artefatos

b) classe de análise: representa uma abstração


de um ou várias classes e/ou subsistemas no
projeto do sistema.
características:
z enfoca sobre a manipulação dos requisitos funcionais
mais óbvia no contexto do domínio do problema, mais
conceitual e de granularidade maior do que o seu
correspondente projeto e implementação.

ES-rup-análise-2003
Artefatos

z raramente provê ou define interface em


termos de operações e suas assinaturas -
define responsabilidades
z define atributos, em um nível mais alto
conceituais e reconhecíveis do domínio do
problema. Podem se tornar classes no projeto
e implementação.
z envolvida em relações conceituais obedecem
aos 3 estereótipos: de limite, de controle ou
entidade.

ES-rup-análise-2003
Artefatos

use-case realization - análise:


z descreve como um use case específico é
compreendido e executado em termos de
classes de análise interagindo. Provê um
rastreamento para um use case específico no
modelo de use case.

ES-rup-análise-2003
Artefatos

é constituído de:
z uma descrição textual do fluxo de eventos,
z diagrama de classes com as classes de análise
participantes
z os diagramas de interação (colaboração) que
desenham a compreensão de um particular fluxo ou
cenário de use case em termos das interações de
objetos de análise. ( figuras: diagrama de classe para
realization do use case pagto fatura e do diagrama de
colaboração correspondente).

ES-rup-análise-2003
ES-rup-análise-2003
ES-rup-análise-2003
Artefatos

z Um texto escrito em termos de objetos, contem o fluxo


de eventos da análise e facilitaria a
leitura/compreensão do diagrama de colaboração.

z requisitos especiais: descrições textuais que coletam


todos os requisitos não funcionais sobre um use case
realization
z Ex: quando um comprador solicitar a visualização das
faturas recebidas, não levaria mais do que 0,5 segundos.
As faturas seriam pagas usando um padrão X.

ES-rup-análise-2003
Artefatos

c) pacote de análise:
z organizar os artefatos do modelo de análise em
pedaços gerenciáveis.
z pode consistir de classes de análise,
z use case realization e
z outros pacotes de análise recursivamente
z Um pacote de análise seria coeso e fracamente
acoplado.

ES-rup-análise-2003
Artefatos

z características:
z pode representar uma separação de interesses
: alguns pacotes de análise podem ser
analisados separadamente, por diferentes
desenvolvedores com diferentes conhecimentos
do domínio.
z seriam criados com base nos requisitos
funcionais e no domínio do problema e seriam
reconhecidos pelas pessoas com conhecimento
do domínio.

ES-rup-análise-2003
Artefatos

z pode-se ter também pacote de serviços (serviços


providos pelo sistema ao cliente) Ex. verificar
ortografia
z a funcionalidade de um pacote de serviço pode
ser gerenciada como uma unidade.
z o pacote de serviço constitui uma entrada
essencial para as atividades de projeto e
implementação subsequentes.

ES-rup-análise-2003
Artefatos

d) descrição arquitetural ( visão do modelo de


análise):
z é constituído:
z a decomposição do modelo de análise em pacotes
de análise e suas dependências.
z as classes de análise ( entidade, limite e controle).
z use case realization de uma funcionalidade crítica/
importante e envolve vários pacotes de análise, ou
foco sobre algum use case importante que
necessita ser desenvolvido anteriormente no ciclo
de vida de software
ES-rup-análise-2003
Worker

a)arquiteto: responsável pela integridade (correto,


consistente e legível ) do modelo de análise,
b) engenheiro de use case: responsável por um ou
mais use case realization
c) engenheiro de componente:
z define e mantém as responsabilidades, atributos,
relações e requisitos especiais das classes de análise,
de acordo com os requisitos do use case realization
que participa.
z mantém a integridade de pacotes de análise,
garantindo a corretude e que a dependência em
relação a outros pacotes está correta e mínima.
ES-rup-análise-2003
Workflow

os passos para a criação do modelo de


análise:
z engenheiros de use case definem os use case
realization em termos das classes de análise que
participam;
z arquitetos identificam os maiores pacotes de análise,
as classes entidade e os requisitos;
z engenheiro de componentes especifica os requisitos e
integra-os em cada classe(responsabilidades, atributos
e relações consistentes).

ES-rup-análise-2003
Workflow

Principais atividades:
a) análise arquitetural: esboçar o modelo de análise
e a arquitetura identificando os pacotes de análise,
as classes de análise e os requisitos especiais.
a1) identificando os pacotes de análise:
z organizar o modelo de análise dividindo o trabalho de
análise, podem ser encontrados no modelo de análise
à medida que ele evolui e necessita ser decomposto.

ES-rup-análise-2003
Workflow
Critérios para identificar os pacotes de
análise:
z os requisitos funcionais = use case
identificar pacotes de análise é alocar a
porção principal de um número de use case
para um pacote em específico e então
compreender a funcionalidade correspondente.
z estratégias:
z os use case requeridos para suportar um processo
de negócio específico
z os use case requeridos para suportar um ator
específico do sistema;
ES-rup-análise-2003
Workflow

z os use case que são relacionados (figura


abaixo)

ES-rup-análise-2003
Workflow

z dois ou mais pacotes que compartilham as


mesmas classes extrair as classes
compartilhadas, colocá-los em seu pacote
próprio ou outro pacote e definir as
dependências onde for o caso.

ES-rup-análise-2003
Workflow

z as classes de análise dentro do mesmo pacote


de serviço contribuirão para o mesmo serviço.
z Pacote serviço

ES-rup-análise-2003
Workflow

z A direção de dependência = direção de


navegabilidade.
z Os pacotes são fracamente acoplados e
fortemente coesos

ES-rup-análise-2003
Workflow

identificar classes:
z algumas com base nas classes do domínio ou
entidades do negócio são identificadas durante a
captura dos requisitos.
z muitas serão identificadas quando o use case
realization for executada.
z as agregações e associações entre as classes de
domínio no modelo de domínio pode ser usado para
identificar um conjunto de associações entre as
classes entidades.

ES-rup-análise-2003
Workflow

a3) identificar os requisitos especiais:


capturar para que sejam adequadamente manipulados
nas fases subsequentes. Exs: persistência, distribuição e
concorrência; características de segurança, tolerância a
falhas, gerenciamento de transações.
z Ex: as características chave de um requisito especial:
z Um requisito persistência tem as seguintes
caracterísitcas:
z Intervalo de valores válidos para um atributo; o volume; o
período de persitêcia; a frequência de atualização;
confiabilidae (objetos sobreviveriam a um crash)

ES-rup-análise-2003
Workflow

b) analisar um use case:

ES-rup-análise-2003
Workflow

b1) identificar as classes de análise cujos objetos são


necessários para executar o fluxo de eventos do use
case:
z Esboçar nome, responsabilidade, atributos e relações,
z descrever as interações dos objetos de análise usando o
diagrama de colaboração para cada fluxo ou subfluxo,
b2) Cada use case é refinado como uma colaboração de
classes de análise
b3) capturar os requisitos especiais - não funcionais.
Exemplos:
A fatura deve ser persistente
A classe Manipular Pedido sdeve ser capaz de manipular 10000
transações por hora.ES-rup-análise-2003
Workflow

c) analisar uma classe:


z objetivos:
c1) identificar e manter as responsabilidades de
uma classe de análise com base no seu papel
no use case realization.
z onde encontrar?
z combinando os papéis desempenhados nos
diferentes use case realization;
z estudando os diagramas de classe, de interação e a
descrição textual

ES-rup-análise-2003
Workflow

Exemplo de descrição textual:


“ Os objetos Fatura são criados durante o use case Fatura do
Comprador. O vendedor executa este use case para cobrar
pelo pagamento de uma compra ( um pedido que foi criado
durante o use case Solicite Produtos e Serviços). Durante a
execução do use case, a Fatura é passada para o comprador
que pode mais tarde decidir por pagá-la.
O pagamento é efetuado no use case Pagar Fatura onde o
objeto EscalonaPagto escalona um objeto Fatura para
pagamento. Mais tarde a fatura é paga e o objeto Fatura é
liquidado.
Note no entanto que a mesma instância Fatura participa tanto
do use cse Fatura Comprador como do use case Pagar Fatura”.

ES-rup-análise-2003
Workflow

z c2) identificar e manter os atributos e relações


das classes de análise
z como identificar os atributos?
z o nome deve ser um substantivo;
z os atributos seriam conceituais;
z tentar reusar um que já exista;
z um único atributo não pode ser compartilhado por
vários objetos de análise
z complexidade para compreensão de uma classe
por causa dos atributos, estes devem ser separados
z identifcar as relações de associação,
generalização e agregação
ES-rup-análise-2003
Workflow

z c3) capturar os requisitos especiais da classe


no use case realization-análise.

ES-rup-análise-2003
Workflow

d) analisar um pacote.
z objetivo:
z (i) garantir que os pacotes são independentes um
do outro;
z (ii) garantir que o pacote colabora em um use case
realization;
z (iii) descrever dependências de modo que o efeito
de próximas modificações possam ser estimadas.

ES-rup-análise-2003
Workflow

z principais diretrizes: (figura a seguir):


z definir e manter as dependências entre
pacotes;
z certificar que contém as classes corretas
z limitar as dependências a outros pacotes.

ES-rup-análise-2003
ES-rup-análise-2003
SUMÁRIO DO WORKFLOW ANÁLISE

os resultados:
z Pacotes de análise e pacotes de serviço e suas
dependências e conteúdos.
z Classes de análise e suas responsabilidades,
atributos, relações e requisitos especiais
z use case realization - análise
z Visão arquitetural

ES-rup-análise-2003

Você também pode gostar