1 fluxo de análise e projeto do rup para sistemas de tempo real robson godoi
TRANSCRIPT
1
Fluxo de Análise e Projetodo RUP para Sistemas de
Tempo Real
Robson Godoi
2
Transformar os requisitos em um projeto (inicialmente abstrato) do sistema
Desenvolver uma arquitetura robusta para o sistema
Adaptar o projeto levando em consideração requisitos da futura implementação
Objetivos do fluxo de análise e projeto
3
Arquitetura de softwareO modelo de “4+1 Visões”
Visão de Implementação
VisãoLógica
Visão de Distribuição
Visão de Processos
Visão de Casos de Uso
Analista de Sistemas
Arquiteto
Estrutura
Programadores
Arquiteto Escalabilidade Topologia, implantação, comunicação
Arquiteto
Estrutura, componentes
4
O Fluxo de Análise e Projeto
Planejamento e Gerenciamento.....
Fluxos de SuporteGerência de Configuração............
Requisitos...............................Análise e Projeto......................Implementação........................Testes...................................Implantação............................
Fluxos de Processo
Iterações
FasesConcepção Elaboração Construção Transição
Inicial
5
Visão geral dos artefatos
Análise e Projeto
Modelo de Casos de Uso
Projeto de Banco de
Dados
Documento de Requisitos
Glossário
Documento da
Arquitetura
Mapeamento das Classes de Análise em Elementos de
Projeto
Modelo de Análise e Projeto
6
Artefato Realização de Caso de Uso
Diagrama de Classes
Diagrama de Seqüência
Diagrama de Colaboração
Realização de Caso de Uso
Caso de Uso
Modelo de Casos de Uso Modelo de Análise e Projeto
7
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Arquiteto de Software
Revisor de Projeto
Projetar Casos de Uso
Projetar Subsistemas
Analista deSistemas
Fluxo de Análise e Projeto
Projetar Classes
Analisar Arquitetura
Revisar Arquitetura
Revisor da Arquitetura
Projetar Base de Dados
Projetista deBanco de Dados
Projetar Cápsula
Projetista de Cápsula
Refinar / Decompor Cápsula
8
Fluxo de Análise e Projeto
Analisar Casos de Uso
Projetar Arquitetura Arquiteto de
Software
Revisor de Projeto
Projetar Casos de Uso
Projetar Subsistemas
Analista deSistemas
Projetar Classes
Analisar Arquitetura
Revisar Arquitetura
Revisor da Arquitetura
Projetar Base de Dados
Projetista deBanco de Dados
Projetar Capsula
Projetista de Capsula
decisões doarquiteto
<<subsystem>>
CheckList bla bla bla blabla
Revisar Projeto
CheckList bla bla bla blabla
9
Analisar Caso de Uso
10
Analisar Casos de Uso
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Arquiteto de Software
Revisor de Projeto
Projetar Casos de Uso
Projetar Subsistemas
Analista deSistemas
Projetar Classes
Analisar Arquitetura
Revisar Arquitetura
Revisor da Arquitetura
Projetar Base de Dados
Projetista deBanco de Dados
Projetar Cápsula
Projetista de Cápsula
11
Objetivos desta atividade Encontrar as classes iniciais do sistema
(classes de análise) e distribuir comportamento dos casos de uso entre elas
Para cada classe, descrever as responsabilidades, atributos e associações
Esta atividade é realizada para cada caso de uso!
12
Visão geral dos artefatos
Analista de Sistemas
Analisar Caso de Uso
Glossário Modelo de Casos de Uso
Diagrama de Classes
Diagrama de Seqüência
Diagrama de Colaboração
Documento de Requisitos
Documento da
Arquitetura
Realização de Caso de Uso
13
Passos para Analisar Casos de UsoPara cada caso de uso:
1. Encontrar classes de análise2. Identificar persistência
Para cada classe:3. Distribuir comportamento entre as classes 4. Descrever responsabilidades5. Descrever atributos e associações
6. Revisar os Resultados
14
O comportamento do caso de uso é distribuído em classes de análise dos seguintes tipos (estereótipos)
Fronteira
Controle
Entidade
Estes estereótipos são uma conveniência de análise que desaparecem no projeto
Passo 1. Encontrar classes de análise
Notação em UML
15
Classes de análise: um primeiro passo em direção ao executável
Modelo de Casos de Uso
Códigos Fonte
Executável
Classes de Análise
Elementos de Projeto
16
Exemplo - Efetuar Login
TelaLogin<<boundary>>
ClienteAtor Efetuar Login
Usuario<<entity>>
Conta<<entity>>
ControladorLogin<<control>>
17
Efetuar Login – Fluxo de eventos
Este caso de uso é responsável por autenticar um usuário do sistema.
Pré-condição: nenhumaPós-condição: um usuário válido é logado e sua sessão é registrada no sistema.
Fluxo de eventos principal1. O cliente informa login e senha.2. O sistema verifica se o login e a senha são válidos (verifica-se se o login e senha pertencem a uma conta).3. O sistema registra o início de uma sessão de uso.
Fluxos secundários- No passo 2, se o login ou a senha forem inválidos, o sistema exibe uma mensagem e volta ao passo 1.
18
Passo 2. Identificar persistência
Identificar que classes de análise deverão ser persistentes
Criar, para cada classe persistente, uma classe de cadastro com estereótipo
<<entity collection>>
19
Passo 3. Distribuir comportamento entre as classes
Para cada fluxo de eventos alocar responsabilidades do caso de
uso às classes de análise modelar interações entre as classes
através dos diagramas de interação
20
Distribuir comportamento entre as classes
Classes de Análise Diagrama de
Colaboração
Caso de Uso
Diagrama de Seqüência
Classes de Análise(com responsabilidades)
21
: ClienteAtor : TelaLogin : ControladorLogin : CadastroContas
efetuarLogin(login, senha)
efetuarLogin(login, senha)
existeConta(login, senha)
registraSessao(login)
Efetuar Login
22
Passo 4. Descrever Responsabilidades Responsabilidades identificadas nos fluxos de
eventos são refletidas em diagramas de interação
Mensagens nestes diagramas resultam em responsabilidades nas classes receptoras
:Cliente :Fornecedor
// Realizar responsabilidade
Fornecedor
// Realizar responsabilidade
diagrama de classes
diagrama de interação
23
Efetuar LoginClasses com responsabilidades
TelaLogin
efetuarLogin()
<<boundary>>
ControladorLogin
efetuarLogin()
<<control>>
CadastroContas
existeConta()
<<entity collection>>
Conta<<entity >>
24
Passo 5. Descrever atributos e associações
Detalhando mais as classes definir atributos estabelecer associações necessárias
entre as classes
25
Efetuar LoginDiagrama de classes com relacionamentos e atributos
Contaloginsenha
<<entity>>
TelaLogin
efetuarLogin()
<<boundary>>
CadastroContas
existeConta()
<<entity collection>>
0..n0..n
ControladorLogin
efetuarLogin()
<<control>>
1
0..n
1
0..n
1
1
1
1
26
Passo 6. Revisar Resultados Verificar se as classes de análise
satisfazem os requisitos funcionais Unificar as classes de análise Verificar se todo o modelo está
consistente entre si e com os requisitos
27
Projetar Arquitetura
28
Projetar Arquitetura
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Arquiteto de Software
Revisor de Projeto
Projetar Casos de Uso
Projetar Subsistemas
Analista deSistemas
Projetar Classes
Analisar Arquitetura
Revisar Arquitetura
Revisor da Arquitetura
Projetar Base de Dados
Projetista deBanco de Dados
Projetar Cápsula
Projetista de Cápsula
29
Visão geral dos artefatos
Arquiteto Projetar Arquitetura
Documento da
Arquitetura
Documento de
Requisitos
Mapeamento das Classes de
Análise em Elementos de
Projeto
Modelo de Análise e Projeto
(classes de projeto, cápsulas e subsistemas)
Modelo de Análise e
Projeto (classes de análise)
Modelo de Casos de
Uso
30
Passos para Projetar Arquitetura1. Mapear classes de análise em elementos
(classes, cápsulas e subsistemas) de projeto
2. Identificar oportunidades de reuso3. Definir a estrutura da aplicação4. Descrever a concorrência5. Descrever a distribuição
31
Passo 1: Mapear classes de análise em elementos (classes, cápsulas e subsistemas) de projeto Identificar classes de projeto Identificar subsistemas Especificar a interface dos subsistemas Identificar cápsulas Identificar protocolos das cápsulas Fazer o mapeamento
1 classe de análise pode dar origem a 0 ou mais classes de projeto
Mapeamento m : n
32
Identificando classes de projeto
Uma classe de análise simples, que representa uma única abstração, é mapeada para uma única classe de projeto Exemplo: classes de entidade
Classes de análise muito simples podem até ser combinadas em uma única classe de projeto
Em geral, classes de análise complexas podem ser divididas em várias classes ou transformadas em um pacote ou subsistema
33
Identificando subsistemas Classes de análise
Classes de fronteira (interfaces com sistemas externos e com usuários)
Classes que fornecem serviços complexos Componentes reusáveis
Software de comunicação Suporte ao acesso a BD Estruturas de dados Bibliotecas de utilitários Produtos específicos da aplicação
34
<<subsystem>>Subsistema X
Identificando subsistemas
Classe A
Y()Z() Y()
Z()
<<interface>>
Interface A
Classe complexa
35
Interface <<subsystem>>nomeSubsistema
FachadaSubsistemaISubSistema
Além da interface, é destacada uma classe fachada de cada subsistema
A classe fachada
36
Identificando Cápsulas Cápsula
Representa um thread do sistema Fluxo de controle independente no sistema
Utilizadas para representar... unidades de concorrência objetos concorrentes externos representação interna de dispositivos físicos
externos controladores de objetos concorrentes
Em geral, uma cápsula representa uma classe ativa
37
Mapeamento das Classes de Análise em Cápsulas
Classes de fronteira e de controle são candidatas a transformarem-se em cápsulas
Atributos e operações de cápsulas são privados. Exceto o método que modela o comportamento.
38
Árvore de decisãoClasses de Fronteira e de Controle
Representa um componente
externo?
Reage a eventos externos?
Controla apenas acesso a dados?
Possui concorrência interna? Controla outras
cápsulas?
Transformar em
cápsula
Transformar
em várias cápsulas
Continuar como classe <<boundary>> ou <<control>>
S
S
S
S
S
N
N
N
N
N
39
Árvore de decisãoClasses de Fronteira e de Controle
Representa um componente
externo?
Reage a eventos externos?
Controla apenas acesso a dados?
Controla outras cápsulas?
Transformar em
cápsula
Continuar como classe <<boundary>> ou <<control>>
S
S
S
S
N
N
N
N
40
Cápsulas e Concorrência
Concorrência interna
Concorrência externa
41
Caso de uso – Atualizar Cotações
Relógio
(from atores)
Cliente
(from atores)
Consultar Cotações(from consultas)
Comprar Ações(from transacoes)
Vender Ações(from transacoes)
Atualizar Cotações(from transacoes)
Operadora Mercado de Ações
(from atores)
42
Fluxo de eventos – Atualizar cotações Fluxo de eventos
Este caso de uso se inicia quando o relógio dispara uma interrupção, a cada 5 minutos, indicando que as cotações devem ser atualizadas.
O sistema consulta as cotações das ações através da operadora do Mercado de Ações.
Em seguida o sistema atualiza o valor das ações, mantendo todo histórico dos valores das ações.
Fluxo secundário No passo 2, se a operadora demorar mais que 5
segundos para responder a solicitação de consulta, ocorrerá um timeout e o caso de uso será encerrado.
Em qualquer momento o usuário pode cancelar a operação.
43
Exemplo - Mercado de AçõesClasses de Análise
InterfaceRelogio<<boundary>>
ControladorAtualizacaoCotacoes<<control>>
ComunicacaoOperadoraMercadoAcoes<<boundary>>
Acao<<entity>>
Cotacao<<entity>>
OperadoraMercadoAcoes<<entity>>
CadastroAcoes<<entity collection>>
CadastroCotacoes<<entity collection>>
CadastroOperadorasMercadoAcoes<<entity collection>>
44
InterfaceRelogio<<capsule>>
ControladorAtualizacaoCotacoes<<capsule>>
ComunicacaoOperadoraMercadoAcoes<<capsule>>
ComunicacaoNasdaq<<capsule>>
ComunicacaoBovespa<<capsule>>
IComunicacaoOperadoraMercadoAcoes<<interface>>
Exemplo - Mercado de AçõesClasses de Análise
45
Identificando Protocolos das Cápsulas
Protocolos Identificam o ‘contrato’ entre cápsulas,
definindo um conjunto de sinais usados para comunicação entre diferentes threads, bem como a seqüência válida de troca de sinais entre as cápsulas.
46
Identificando Protocolos das Cápsulas
Passos Para cada cápsula, listar o conjunto de
sinais de entrada e de saída (in e out) Desenhar gráfico de interação entre
cápsulas Para cada interação par-a-par, criar um
protocolo Identificar similaridades entre protocolos
e promover reuso Associar protocolos a cápsulas
47
Identificando Protocolos Gráfico de interações entre cápsulas
InterfaceRelogio<<Capsule>>
ControladorAtualizacaoCotacoes<<Capsule>>
ComunicacaoOperadoraMercadoAcoes<<Capsule>>
interrupcao
consultarCotacoes
dadosCotacoes
ComunicacaoNasdaq<<Capsule>>
ComunicacaoBovespa<<Capsule>>
consultarCotacoesNasdaqconsultarCotacoesBovespa
dadosNasdaq dadosBovespa
48
Identificando ProtocolosCriar os protocolos
Toda interação entre cápsulas deve ser feita através de protocolos
Passo-a-passo: Para cada par de cápsulas que interagem
entre si, crie um protocolo Escolha uma das duas cápsulas como
referência para definir os sinais de entrada e os de saída
Insira os sinais de entrada e de saída da cápsula no protocolo criado
49
Identificando ProtocolosCriar os protocolos
InterfaceRelogio<<Capsule>>
ControladorAtualizacaoCotacoes<<Capsule>>
ComunicacaoOperadoraMercadoAcoes<<Capsule>>
interrupcao
consultarCotacoes
dadosCotacoes
AtivacaoPeriodica
interrupcao ()
<<Protocol>>
ComunicacaoNasdaq<<Capsule>>
ComunicacaoBovespa<<Capsule>>
consultarCotacoesNasdaqconsultarCotacoesBovespa
dadosNasdaq dadosBovespa
50
Identificando ProtocolosCriar os protocolos
InterfaceRelogio<<Capsule>>
ControladorAtualizacaoCotacoes<<Capsule>>interrupcao
consultarCotacoes
dadosCotacoes
AtivacaoPeriodica
interrupcao ()
<<Protocol>>
ComunicacaoOperadoraMercadoAcoes<<Capsule>>
ComunicacaoNasdaq<<Capsule>>
ComunicacaoBovespa<<Capsule>>
consultarCotacoesNasdaqconsultarCotacoesBovespa
ConsultaCotacoes
dadosCotacoes ()
consultarCotacoes ()
<<Protocol>>
InteracaoBovespa<<Protocol>>
consultarCotacoesBovespa (void)
dadosCotacoesBovespa (void)dadosNasdaq
ack
InteracaoNasdaq<<Protocol>>
consultarConexaoNasdaq (void)
dadosCotacoesNasdaq (void)
51
Identificando Protocolos Identificar similaridades entre protocolos
AtivacaoPeriodica
interrupcao ()
<<Protocol>>
ConsultaCotacoes
dadosCotacoes ()
consultarCotacoes ()
<<Protocol>>
InteracaoBovespa<<Protocol>>
consultarCotacoesBovespa (void)
dadosCotacoesBovespa (void)
InteracaoNasdaq<<Protocol>>
consultarConexaoNasdaq (void)
dadosCotacoesNasdaq (void)
52
Identificando Protocolos Protocolos identificados Finalmente...
AtivacaoPeriodica
interrupcao ()
<<Protocol>> ConsultaCotacoes
dadosCotacoes ()
consultarCotacoes ()
<<Protocol>>
53
Identificando Protocolos Associar protocolos a cápsulas Associações entre protocolos e
cápsulas
ControladorAtualizacaoCotacoes<<Capsule>>
AtivacaoPeriodica
interrupcao ()
<<Protocol>>
InterfaceRelogio<<Capsule>>
ConsultaCotacoes
consultarCotacoes ()
dadosCotacoes ()
<<Protocol>>
ComunicacaoOperadoraMercadoAcoes<<Capsule>>
ComuicacaoBOVESPA<<Capsule>>
ComuncacaoNASDAQ<<Capsule>>
54
Criando portas eassociando portas a protocolos
Criar o conjunto inicial de portas, considerando as responsabilidades da cápsula
Passo-a-passo: Criar uma porta para cada interação
cápsula-protocolo-cápsula Nomear a porta com o nome do protocolo
ou com o papel da cápsula na realização do protocolo
Se as direções dos sinais no protocolo estiverem invertidos (entrada está como saída e vice-versa), a porta deve ser definida como conjugada (conjugated)
O mesmo protocolo pode ser utilizado em diferentes portas
55
ExemploAtivacaoPeriodica
interrupcao (void)
<<Protocol>>
InterfaceRelogio
+ / interrupcao : AtivacaoPeriodica
# / timer : Timing
<<Capsule>>
+ / interrupcao<<Port>>
+ / interrupcao<<Port>>
ControladorAtualizacaoCotacoes
+ / interrupcao : AtivacaoPeriodica~
+ / consultaCotacoes : ConsultaCotacoes
<<Capsule>>
+ / interrupcao~
<<Port>>
+ / interrupcao~
<<Port>>
56
Passo 2. Identificar oportunidades de reuso
Internas ao sistema Similaridades entre pacotes e subsistemas
Externas ao sistema Componentes disponíveis no mercado Componentes de aplicações já desenvolvidas Componentes que podem se tornar reusáveis
para outros projetos
57
Passo 3. Definir a estrutura da aplicação
Definir as camadas da aplicação Determinar o meio de
armazenamento que será utilizado Agrupar as classes, cápsulas e
protocolos em pacotes e especificar a fachada da aplicação
58
Estruturação em camadas Separação do código:
interface com o usuário (GUI) comunicação regras de negócio acesso a dados Interface com o usuário
(GUI)
Comunicação
Negócio
Dados
59
Camada de negócios Responsável por implementar a lógica do
negócio Classes inerentes ao domínio da aplicação:
classes básicas do negócio coleções de negócio fachada do sistema
60
Classes básicas do negócio
Representam conceitos básicos do domínio da aplicação
PagamentoCartaonumeroFatura
Conta
numerosaldo
getSaldo()debitar()
61
Coleções de negócio Representam conjuntos de objetos das
classes básicas Responsáveis pela inclusão, remoção,
atualização e consultas a instâncias das classes básicas
Encapsulam as verificações e validações inerentes ao negócio
CadastroContasConta
62
Fachada do sistema Segue o padrão de projeto Facade Representa os serviços oferecidos pelo
sistema Centraliza as instâncias das coleções de
negócio e/ou controladores Gerencia as transações do sistema
63
Camada de dados Responsável pela manipulação da
estrutura física de armazenamento dos dados
Isolam o resto do sistema do meio físico usado
Classes coleções de dados
64
Coleções de dados Executam inclusões, remoções,
atualizações e consultas a instâncias das classes básicas no meio de armazenamento usado
Implementadas de acordo com o meio físico usado
CadastroContas
Conta
RepositorioContasBDR
Conta
65
Coleções de dados Dependem do meio de
armazenamento!
CadastroContas
Conta
RepositorioContasBDR
RepositorioContasBDOO
RepositorioContasArquivo
66
Independência do meio de armazenamento
Como isolar as coleções de negócio de mudanças na coleção de dados correspondente?
RepositorioContasBDR RepositorioContasArquivo
CadastroContas
<<interface>>RepositorioContas
67
Interface negócio-dados Sugestão de serviços
<<interface>>RepositorioContas
inserir(conta: Conta): voidatualizar(conta: Conta): voidremover(conta: Conta): voidconsultarConta(login: String): Conta
68
Incorporando cápsulas Classe de análise -> cápsula
GUI• Classe fronteira -> cápsula
Camada de negócio• Fachada -> cápsula• Controlador -> cápsula
Necessidade de protocolo de comunicação entre cápsulas Criação da camada de comunicação para
incorporar protocolos para realizar a comunicação da GUI com a camada de negócio.
69
Classes de análise - a origem de tudo
Classes de entidade -> classes básicas + coleções de negócio e coleções de dados
Classes de fronteira com usuários -> classes de GUI -> cápsulas com legados ->subsistemas
Classes de controle -> fachada do sistema ou subsistema -> cápsula
70
Agrupar as classes em pacotes
À medida que os elementos de projeto são identificados, a complexidade do modelo vai aumentando
Para organizá-lo, os elementos devem ser agrupados em pacotes
As camadas guiam essa organização
71
Passo 4. Descrever a concorrência
Objetivos Identificar o impacto dos requisitos de
concorrência para o projeto Definir quais os processos do sistema
Comunicação Criação / Destruição Mapear no ambiente de implementação
72
Visão geral dos artefatos
Documento da
Arquitetura
Modelo de Projeto
Documento da
Arquitetura
Cápsula
Descrever Concorrência
Requisitos Não
Funcionais
73
Como Descrever a Concorrência1. Analisar os requisitos de concorrência2. Identificar processos e threads3. Identificar o ciclo de vida dos processos4. Identificar os mecanismos de comunicação
entre processos (IPC).5. Coordenar a alocação de recursos entre
processos6. Mapear os processos para o ambiente de
implementação7.Distribuir os elementos do projeto dentro dos
processos
74
Passo 5. Descrever a distribuição
Objetivo Definir como a funcionalidade do
sistema será distribuída através dos nós físicos
75
Como Descrever a distribuição Definir a configuração da rede
Entender a configuração e a topologia da rede
Alocar processos e threads em nós Distribuir a carga de trabalho do
sistema
76
Projetar Cápsulas
77
Projetar Cápsulas
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Arquiteto de Software
Revisor de Projeto
Projetar Casos de Uso
Projetar Subsistemas
Analista deSistemas
Projetar Classes
Analisar Arquitetura
Revisar Arquitetura
Revisor da Arquitetura
Projetar Base de Dados
Projetista deBanco de Dados
Projetar Cápsula
Projetista de Cápsula
78
Objetivos desta atividade Detalhar a estrutura e o comportamento
das cápsulas identificadas no projeto Detalhar e especificar portas e protocolos Garantir que as cápsulas fornecem o
comportamento necessário à realização dos casos de uso
Realizada para cada cápsula da iteração correnteTodas as cápsulas devem estar
projetadas até o final da fase de elaboração
79
Visão geral dos artefatos
Projetista de Cápsula
Projetar Cápsulas
Projeto de Cápsulas
Modelo de Análise e Projeto
Requisitos Não
Funcionais
80
Passos para Projetar Cápsulas
Definir diagrama de estados Validar comportamento da cápsula
81
Passo 1. Definir diagrama de estados Definir o comportamento interno da
cápsula Quando utilizar?
Para representar o comportamento interno das cápsulas “folhas” (que não possuem sub-cápsulas)
Para especificar restrição de ordem nos sinais de um protocolo
82
Diagrama de estados x diagrama de interação
Diagrama de estados Comportamento interno de uma classe
(ou cápsula) Diagrama de interação
Comportamento do caso de uso como uma cooperação entre classes (cápsulas)
83
Diagramas de EstadosNotação
estado
transicão
estado
transicão final
transicão inicial
super-estado
transicão deorigem externa
auto-transicão
Principais elementos
sub-estado
sub-estado
HEstado história
84
Diagrama de Estados - InterfaceRelogio Cápsula: InterfaceRelogio
AguardandoInterrupcao
Initial
gerarInterrupcao
Initial
gerarInterrupcao
85
Diagrama de Estados – ComunicacaoBovespa sem ACK
Cápsula: ComunicacaoBovespa
AguardandoPeriodo
AguardandoD ados
InitialInitial
recebeuD adosrecebeuD ados
iniciarAtualizacaoiniciarAtualizacao
86
Diagrama de Estados – ComunicacaoBovespa com ACK
AguardandoPeriodo AguardandoACK
AguardandoD ados
Initial
iniciarAtualizacao
recebeuACKrecebeuD ados
Initial
iniciarAtualizacao
recebeuACKrecebeuD ados
Cápsula: ComunicacaoBovespa
87
Passo 2. Validar comportamento da cápsula Revisar o modelo simulando vários cenários Verificar:
Nomes apropriados para estados e transições Seqüência de execução das ações Disparo das transições
• É sempre possível continuar a execução?• Cada evento dispara apenas uma transição?
Operações nas cápsulas• As cápsulas possuem as operações necessárias para as
responsabilidades definidas no diagrama de estados?
88
Refinar / Decompor Cápsulas
89
Refinar / Decompor Cápsulas
Analisar Casos de Uso
Revisar Projeto
Projetar Arquitetura
Arquiteto de Software
Revisor de Projeto
Projetar Casos de Uso
Projetar Subsistemas
Analista deSistemas
Projetar Classes
Analisar Arquitetura
Revisar Arquitetura
Revisor da Arquitetura
Projetar Base de Dados
Projetista deBanco de Dados
Projetar Cápsula
Projetista de Cápsula
Refinar / Decompor Cápsula
90
Objetivos desta atividade Identificar a possibilidade de refinamento
ou decomposição das cápsulas Detalhar e especificar as cápsulas a partir
do refinamento / decomposição
91
Visão geral dos artefatos
Projetista de Cápsula
Refinar / Decompor Cápsulas
Modelo de Análise e Projeto
Requisitos Não
Funcionais
Projeto de Cápsulas
Projeto de Cápsulas
92
Passos para Refinar / Decompor Cápsulas Identificar oportunidades de
refinamento/decomposição Particionar atributos Particionar métodos Particionar portas Paralelizar máquinas de estado Refinar/Decompor Identificar oportunidades de herança
93
Fluxo de Análise e Projetodo RUP para Tempo Real
Robson Godoi