1 fluxo de análise e projeto do rup para sistemas de tempo real robson godoi

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


Projetar Arquitetura Arquiteto de

Software

Revisor de Projeto



Analista deSistemas

Projetar Classes


Revisar Arquitetura




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



Revisar Projeto



Revisor de Projeto



Analista deSistemas

Projetar Classes


Revisar Arquitetura




Projetar 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


Analista de Sistemas

Analisar Caso de Uso

Glossário Modelo de Casos de Uso

Diagrama de Classes


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


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()


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()


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


28



Revisar Projeto



Revisor de Projeto



Analista deSistemas

Projetar Classes


Revisar Arquitetura




Projetar Cápsula


29


Arquiteto Projetar Arquitetura

Documento da

Arquitetura

Documento de

Requisitos

Mapeamento das Classes de

Análise em Elementos de

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





interrupcao

consultarCotacoes

dadosCotacoes

AtivacaoPeriodica

interrupcao ()

<<Protocol>>




dadosNasdaq dadosBovespa

50



ControladorAtualizacaoCotacoes<<Capsule>>interrupcao

consultarCotacoes

dadosCotacoes

AtivacaoPeriodica

interrupcao ()

<<Protocol>>





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 ()


<<Protocol>>

InteracaoBovespa<<Protocol>>

consultarCotacoesBovespa (void)

dadosCotacoesBovespa (void)

InteracaoNasdaq<<Protocol>>

consultarConexaoNasdaq (void)

dadosCotacoesNasdaq (void)

52

Identificando Protocolos Protocolos identificados Finalmente...

AtivacaoPeriodica

interrupcao ()

<<Protocol>> ConsultaCotacoes

dadosCotacoes ()


<<Protocol>>

53

Identificando Protocolos Associar protocolos a cápsulas Associações entre protocolos e

cápsulas


AtivacaoPeriodica

interrupcao ()

<<Protocol>>


ConsultaCotacoes


dadosCotacoes ()

<<Protocol>>


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


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


Revisar Projeto



Revisor de Projeto



Analista deSistemas

Projetar Classes


Revisar Arquitetura




Projetar 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



Projetar Cápsulas

Projeto de Cápsulas


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



Revisar Projeto



Revisor de Projeto



Analista deSistemas

Projetar Classes


Revisar Arquitetura




Projetar 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





Requisitos Não

Funcionais



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

1 fluxo de análise e projeto do rup para sistemas de tempo real robson godoi

Documents