Fluxo de Análise e Projeto do RUP para Tempo Real

Apresentação em tema: "Fluxo de Análise e Projeto do RUP para Tempo Real"— Transcrição da apresentação:

1 Fluxo de Análise e Projeto do RUP para Tempo Real
mar-17 Fluxo de Análise e Projeto do RUP para Tempo Real Augusto Sampaio Fluxo de análise e projeto

2 Objetivos do fluxo de análise e projeto
mar-17 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 O principal objetivo do fluxo de análise e projeto é traduzir os requisitos do sistema (o quê o sistema deve fazer) em uma especificação de como implementá-lo. UML é a linguagem de modelagem usada para descrever essa especificação. É durante a análise e projeto que se trabalha na definição de uma arquitetura estável e robusta para o sistema, levando em consideração restrições de desempenho e do ambiente de implementação e execução. Em termos de fases, a ênfase em A&P ocorre durante a Elaboração. Fluxo de análise e projeto

3 Visão geral dos artefatos
mar-17 Modelo de Análise e Projeto Documento da Arquitetura Modelo de Casos de Uso Análise e Projeto Mapeamento das Classes de Análise em Elementos de Projeto Glossário Documento de Requisitos Projeto de Banco de Dados As entradas para as atividades de análise e projeto são oriundas do fluxo de requisitos. O modelo de casos de uso contém os requisitos funcionais do sistema e o Documento de Requisitos contém a descrição dos requisitos funcionais e não-funcionais. O glossário é usado para esclarecer a definição de termos usados nesses documentos. As atividades de análise e projeto geram toda a modelagem do sistema. Seus artefatos principais são: o modelo de análise e projeto - descreve as classes, subsistemas e pacotes da aplicação, podendo usar diversos diagramas para isso. Geralmente, usa-se o mesmo arquivo do modelo durante todo o desenvolvimento. Isso significa que o modelo evolui de uma descrição bastante abstrata (feita durante as atividades de análise), para uma descrição detalhada das classes e subsistemas identificados (nas atividades de projeto). O modelo de Análise e Projeto contém as realizações dos casos de uso; o documento da arquitetura - fornece uma descrição detalhada da arquitetura do sistema. o modelo de dados - descreve a representação lógica e física dos dados persistentes do sistema. Em outras palavras, ele apresenta como os elementos persistentes devem ser mapeados para estruturas do meio de armazenamento, como as tabelas de um banco de dados, por exemplo. Mapeamento das classes de análise em elementos do projeto - é um artefato temporário. Fluxo de análise e projeto

4 Fluxo de Análise e Projeto
mar-17 Projetar Arquitetura Arquiteto de Software Revisor de projeto Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas Projetar Cápsulas Analista de Sistemas Projetar Base de Dados Revisar Projeto Projetista de Banco de Dados Fluxo de análise e projeto

5 Fluxo de Análise e Projeto
mar-17 Revisor de projeto Arquiteto de Software Projetar Arquitetura Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas Projetar Cápsulas decisões do arquiteto <<subsystem>> Analista de Sistemas Check List  bla bla  bla  blabla Projetar Base de Dados Revisar Projeto Projetista de Banco de Dados Fluxo de análise e projeto

6 Analisar Casos de Uso mar-17 Fluxo de análise e projeto Revisor de
Arquiteto de Software Projetar Arquitetura Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas Projetar Cápsulas Analista de Sistemas Projetar Base de Dados Revisar Projeto Projetista de Banco de Dados Fluxo de análise e projeto

7 Passos para Analisar Casos de Uso
mar-17 Para cada caso de uso: 1. Encontrar classes de análise 2. Identificar persistência Para cada classe: 3. Distribuir comportamento entre as classes 4. Descrever responsabilidades 5. Descrever atributos e associações 6. Revisar os Resultados Durante a realização dos passos, usa-se bastante a descrição do caso de uso, particularmente de seu fluxo de eventos. Às vezes, a descrição do fluxo é feita em um nível de abstração elevado e, eventualmente, pode ser preciso detalhar mais alguma parte específica do fluxo de eventos. Neste caso, é preciso entrar em contato com o especificador de requisitos para esclarecer quaisquer dúvidas e/ou propor alguma mudança no Documento de Requisitos. Aspectos não-funcionais a nível de análise já devem ser identificados nesta atividade. Aqui, o foco é em persistência, mas deve-se atentar para outros aspectos como segurança. Fluxo de análise e projeto

8 Passo 1. Encontrar classes de análise
mar-17 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 As classes de análise constituem a primeira tentativa de modelar como o sistema irá realizar o caso de uso. Elas são ainda bastante abstratas, e, durante a etapa de projeto, poderão ser divididas em outras classes ou até mesmo transformadas em subsistemas. A idéia é que elas aglutinem os conceitos e responsabilidades necessários para a realização dos casos de uso; os detalhes e pormenores das classes são tratados posteriormente. As classes de análise podem ser de três tipos: fronteira, entidade e controle. Veremos neste passo como identificar as classes usando três diferentes perspectivas do sistema: classes de fronteira (entre os atores e os casos de uso), classes de controle (controlam a lógica do caso de uso) e classes de entidade (armazenam a informação que o sistema utiliza). Identificar as classes por tipo facilita a análise do sistema porque cada estereótipo direciona algumas características das classes. Por exemplo, classes de fronteira são mais propensas a mudanças e classes de entidade são, na sua maioria, persistentes. Fluxo de análise e projeto

9 QIB - Diagrama de Casos de Uso
mar-17 Usaremos o QIB como exemplo A descoberta de classes de análise será ilustrada com exemplos do Qualiti Internet Banking. Fluxo de análise e projeto

10 QIB – Efetuar Login mar-17 Regra geral para encontrar classes de fronteira: uma classe por cada par ator/caso de uso Efetuar Login ClienteAtor Para encontrar classes de fronteira, basta olhar o modelo de casos de uso – em geral existe uma classe de fronteira para cada par ator-caso de uso. Fluxo de análise e projeto

11 QIB – Efetuar Login Encontrando classes de controle Efetuar Login
mar-17 Encontrando classes de controle Efetuar Login ClienteAtor Fluxo de análise e projeto

12 Classes de Entidade (entity classes)
mar-17 Abstrações e conceitos chaves dos casos de uso Fontes: Conhecimento do negócio Glossário Modelo de negócios Documento de requisitos Especificação do Caso de uso Notação em UML Armazenam e controlam informação no sistema As classes de entidade representam os conceitos principais do sistema, as fontes de informação que o sistema manipula. Elas geralmente são persistentes e sua principal função é armazenar e gerenciar informação. As classes de entidade são identificadas com o estereótipo <<entity>>. <<entity>> Fluxo de análise e projeto

13 QIB – Efetuar Login Observe o fluxo de eventos do Efetuar Login
mar-17 Observe o fluxo de eventos do Efetuar Login Este caso de uso é responsável por autenticar um usuário do sistema. Pré-condição: nenhuma Pós-condição: um usuário válido é logado e sua sessão é registrada no sistema. Fluxo de eventos principal 1. 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. Fluxo de análise e projeto

14 QIB – Efetuar Login Classes de entidade
mar-17 Classes de entidade A classe Conta é uma classe que armazena o login e senha de um cliente. Algumas classes levantadas podem ser eliminadas e novas serão adicionadas Este primeiro levantamento de classes de entidade pode revelar classes que não serão realmente utilizadas no caso de uso e serão eliminadas. As atividades seguintes indicarão mais claramente que classes realmente são utilizadas. Fluxo de análise e projeto

15 QIB – Efetuar Login Classes de análise descobertas até o momento

16 Passo 2. Identificar persistência
mar-17 Identificar que classes de análise deverão ser persistentes Criar, para cada classe persistente, uma classe de cadastro com estereótipo <<entity collection>> As classes persistentes são classes cujos atributos devem ser armazenados pelo sistema de forma não volátil (em um SGBD, por exemplo). Elas devem ser identificadas porque serão tratadas de maneira especial durante a etapa de projeto, para que se possa implementar sua persistência. Atributos complexos de classes persistentes, que não sejam considerados persistentes individualmente, não devem ser marcados como tal. Por exemplo, considere as classes Cliente e Endereço, com Endereço sendo um dos atributos de Cliente. A classe Cliente deve ser identificada como persistente, mas Endereço não, uma vez que os dados relativos ao endereço do cliente só são armazenados juntamente com os dados do respectivo cliente. As classes de cadastro são responsáveis por manter uma coleção de objetos. Por exemplo, um objeto da classe de entidade Conta representa uma única conta de do sistema. Um objeto da classe CadastroContas é responsável por todas as contas do sistema e oferece métodos típicos de acesso a base de dados (inserir, remover, atualizar, consultar, etc). Fluxo de análise e projeto

17 QIB – Efetuar Login Classes persistentes

18 Passo 3. Distribuir comportamento entre as classes
mar-17 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 Neste passo, deve-se modelar os casos de uso (fluxo de eventos) usando os diagramas de interação (seqüência ou colaboração). Fluxo de análise e projeto

19 mar-17 QIB – Efetuar Login O método existeConta() procura no cadastro de contas a existência de uma Conta que armazene o login e senha digitados. Este cenário assume que a procura é bem sucedida (cliente válido, com o método retornando true). Apesar de o cadastro ser consultado, o objeto Conta não é recuperado por este caso de uso. Note que as classes Usuario e Mensagem (identificadas inicialmente como classes de análise) não são usadas aqui, pois Usuario é o ClienteAtor e Mensagem não é utilizada neste cenário (fluxo principal). Ao final de um login bem sucedido, a TelaLogin armazena o identificador do cliente (login) enquanto o mesmo estiver usando o sistema (controla esta sessão de uso). Fluxo de análise e projeto

20 QIB - Efetuar Login

21 Passo 4. Descrever Responsabilidades
mar-17 Responsabilidades identificadas nos fluxos de eventos são refletidas em diagramas de interação Mensagens nestes diagramas resultam em responsabilidades nas classes receptoras diagrama de interação :Cliente :Fornecedor // Realizar responsabilidade As mensagens enviadas para objetos de uma determinada classe representam requisições de serviços que devem ser realizados pelos objetos. Assim, os diagramas de interação são uma boa fonte para encontrar responsabilidades. Para cada mensagem presente no diagrama, examine a classe do objeto para o qual a mensagem foi enviada. Se na classe ainda não existir uma responsabilidade capaz de atender ao que foi requisitado na mensagem, crie a responsabilidade correspondente. Se não houver diagramas disponíveis, examine o fluxo de eventos do caso de uso para identificar as responsabilidades de cada classe. diagrama de classes Fornecedor // Realizar responsabilidade Fluxo de análise e projeto

22 QIB – Efetuar Login Classes com responsabilidades mar-17
Fluxo de análise e projeto

23 Passo 5. Descrever atributos e associações
mar-17 Detalhando mais as classes definir atributos estabelecer associações necessárias entre as classes O propósito deste passo é identificar outras classes que sejam necessárias, definir que informações as classes de análise são responsáveis por manter e identificar os relacionamentos entre essas classes. Fluxo de análise e projeto

24 QIB – Efetuar Login Diagrama de classes com relacionamentos e atributos

25 Projetar Arquitetura mar-17 Fluxo de análise e projeto Revisor de
Arquiteto de Software Projetar Arquitetura Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas Projetar Cápsulas Analista de Sistemas Projetar Base de Dados Revisar Projeto Projetista de Banco de Dados Fluxo de análise e projeto

26 Passos para Projetar Arquitetura
mar-17 1. Mapear classes de análise em elementos (classes, cápsulas e subsistemas) de projeto 2. Identificar oportunidades de reuso 3. Definir a estrutura da aplicação Fluxo de análise e projeto

27 Identificar classes de projeto Identificar cápsulas
Passo 1: Mapear classes de análise em elementos (classes, cápsulas e subsistemas) de projeto mar-17 Identificar classes de projeto Identificar cápsulas Identificar protocolos das cápsulas Identificar subsistemas Especificar a interface dos subsistemas Fazer o mapeamento 1 classe de análise pode dar origem a 0 ou mais classes de projeto Como o foco da atividade Analisar caso de uso é em um caso de uso específico, se a análise for feita por mais de uma pessoa, é possível que existam algumas inconsistências na definição de classes que participem da realização de mais de um caso de uso. Por exemplo, podem ter sido definidas duas classes diferentes para representar o mesmo conceito, ou uma mesma classe pode apresentar comportamentos completamente diferentes em dois casos de uso distintos. Como a atividade corrente lida com o conjunto dos casos de uso, ao identificar os elementos de projeto, o arquiteto tem a oportunidade de perceber e corrigir quaisquer inconsistências oriundas da análise. Uma classe de análise pode ser dividida em mais de uma classe de projeto ou transformada em um subsistema; por outro lado, várias classes de análise muito acopladas podem ser unificadas em uma única classe de projeto ou agrupadas em um subsistema. O objetivo deste passo é avaliar as classes de análise e mapeá-las para os elementos de projeto (classes ou subsistemas) adequados. Mapeamento m : n Fluxo de análise e projeto

28 Identificando classes de projeto
mar-17 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 Uma classe de análise pode ser dividida em mais de uma classe de projeto ou transformada em um subsistema; por outro lado, várias classes de análise muito acopladas podem ser unificadas em uma única classe de projeto ou agrupadas em um subsistema. O objetivo deste passo é avaliar as classes de análise e mapeá-las para os elementos de projeto (classes ou subsistemas) adequados. De uma forma geral, uma classe de análise é mapeada diretamente para uma classe de projeto se ela for simples e representar uma única abstração dentro do sistema (normalmente as classes entidade seguem essa regra e transformam-se diretamente em classes de projeto). Classes de análise mais complexas geralmente são quebradas em outras classes mais simples ou transformadas em subsistemas. Fluxo de análise e projeto

29 Identificando Cápsulas
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

30 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.

31 Árvore de decisão Classes de Fronteira e de Controle
Representa um componente externo? S Transformar em cápsula N N S Reage a eventos externos? Possui concorrência interna? N Controla outras cápsulas? S S Transformar em várias cápsulas N Controla apenas acesso a dados? N S Continuar como classe <<boundary>> ou <<control>>

32 Cápsulas e Concorrência
Concorrência externa Concorrência interna

33 Caso de uso – Atualizar Cotações
Relógio (from atores) Cliente Consultar Cotações (from consultas) Comprar Ações (from transacoes) Vender Ações Atualizar Cotações Operadora Mercado de Ações

34 Fluxo de eventos – Atualizar cotações
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.

35 Exemplo - QIB Mercado de Ações Classes de Análise
InterfaceRelogio <<boundary>> ControladorAtualizacaoCotacoes <<control>> ComunicacaoOperadoraMercadoAcoes <<boundary>> Acao <<entity>> CadastroAcoes <<entity collection>> Cotacao <<entity>> CadastroCotacoes <<entity collection>> OperadoraMercadoAcoes <<entity>> CadastroOperadorasMercadoAcoes <<entity collection>>

36 Exemplo - QIB Mercado de Ações Classes de projeto
InterfaceRelogio <<capsule>> ControladorAtualizacaoCotacoes <<capsule>> ComunicacaoOperadoraMercadoAcoes <<subsystem>> IComunicacaoOperadoraMercadoAcoes <<interface>> ComunicacaoNasdaq <<capsule>> ComunicacaoBovespa <<capsule>> Acao <<entity>> CadastroAcoes <<entity collection>> IRepositorioAcoes <<interface>> RepositorioAcoesBDR IRepositorioCotacoes <<interface>> RepositorioCotacoesBDR Cotacao <<entity>> CadastroCotacoes <<entity collection>> OperadoraMercadoAcoes <<entity>> CadastroOperadorasMercadoAcoes <<entity collection>> IRepositorioMercadoAcoes <<interface>> RepositorioMercadoAcoes

37 Identificando Protocolos das Cápsulas
Identificam o ‘contrato’ entre cápsulas, definindo um conjunto de sinais usados para comunicação entre diferentes threads, bem como a sequência válida de troca de sinais entre as 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

38 Identificando Protocolos Identificar conjunto de sinais das cápsulas
InterfaceRelogio Entradas: Saídas: interrupcao ControladorAtualizacaoCotacoes Entradas: interrupcao, dadosCotacoes Saídas: consultarCotacoes ComunicacaoOperadoraMercadoAcoes Entradas: consultarCotacoes, dadosCotacoesNasdaq, dadosCotacoesBovespa, Saídas: dadosCotacoes, consultarCotacoesNasdaq, dadosCotacoesBovespa, ComunicacaoNasdaq Entradas: consultarCotacoesNasdaq Saídas: dadosCotacoesNasdaq ComunicacaoBovespa Entradas: consultarCotacoesBovespa Saídas: dadosCotacoesBovespa

39 Identificando Protocolos Gráfico de interações entre cápsulas
InterfaceRelogio <<Capsule>> ControladorAtualizacaoCotacoes <<Capsule>> interrupcao dadosCotacoes consultarCotacoes ComunicacaoOperadoraMercadoAcoes <<Capsule>> consultarCotacoesNasdaq consultarCotacoesBovespa ComunicacaoNasdaq <<Capsule>> ComunicacaoBovespa <<Capsule>> dadosNasdaq dadosBovespa

40 Identificando Protocolos Criar 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

41 Identificando Protocolos Criar os protocolos
InterfaceRelogio <<Capsule>> ControladorAtualizacaoCotacoes <<Capsule>> interrupcao dadosCotacoes consultarCotacoes AtivacaoPeriodica interrupcao () <<Protocol>> ComunicacaoOperadoraMercadoAcoes <<Capsule>> consultarCotacoesNasdaq consultarCotacoesBovespa ComunicacaoNasdaq <<Capsule>> ComunicacaoBovespa <<Capsule>> dadosNasdaq dadosBovespa

42 Identificando Protocolos Criar os protocolos
InterfaceRelogio <<Capsule>> ControladorAtualizacaoCotacoes <<Capsule>> interrupcao dadosCotacoes ConsultaCotacoes dadosCotacoes () consultarCotacoes () <<Protocol>> consultarCotacoes AtivacaoPeriodica interrupcao () <<Protocol>> ComunicacaoOperadoraMercadoAcoes <<Capsule>> consultarCotacoesNasdaq consultarCotacoesBovespa ComunicacaoNasdaq <<Capsule>> ComunicacaoBovespa <<Capsule>> dadosNasdaq dadosBovespa

43 Identificando Protocolos Criar os protocolos
InterfaceRelogio <<Capsule>> ControladorAtualizacaoCotacoes <<Capsule>> interrupcao dadosCotacoes ConsultaCotacoes dadosCotacoes () consultarCotacoes () <<Protocol>> consultarCotacoes AtivacaoPeriodica interrupcao () <<Protocol>> ComunicacaoOperadoraMercadoAcoes <<Capsule>> InteracaoBovespa <<Protocol>> consultarCotacoesBovespa (void) dadosCotacoesBovespa (void) consultarCotacoesNasdaq consultarCotacoesBovespa ComunicacaoNasdaq <<Capsule>> ComunicacaoBovespa <<Capsule>> dadosNasdaq

44 Identificando Protocolos Criar os protocolos
InterfaceRelogio <<Capsule>> ControladorAtualizacaoCotacoes <<Capsule>> interrupcao dadosCotacoes ConsultaCotacoes dadosCotacoes () consultarCotacoes () <<Protocol>> consultarCotacoes AtivacaoPeriodica interrupcao () <<Protocol>> ComunicacaoOperadoraMercadoAcoes <<Capsule>> InteracaoBovespa <<Protocol>> consultarCotacoesBovespa (void) dadosCotacoesBovespa (void) dadosNasdaq ack InteracaoNasdaq <<Protocol>> consultarConexaoNasdaq (void) dadosCotacoesNasdaq (void) consultarCotacoesNasdaq consultarCotacoesBovespa ComunicacaoNasdaq <<Capsule>> ComunicacaoBovespa <<Capsule>>

45 Identificando Protocolos Identificar similaridades entre protocolos
AtivacaoPeriodica interrupcao () <<Protocol>> InteracaoNasdaq <<Protocol>> consultarConexaoNasdaq (void) dadosCotacoesNasdaq (void) ConsultaCotacoes dadosCotacoes () consultarCotacoes () <<Protocol>> InteracaoBovespa <<Protocol>> consultarCotacoesBovespa (void) dadosCotacoesBovespa (void)

46 Identificando Protocolos Protocolos identificados
Finalmente... ConsultaCotacoes dadosCotacoes () consultarCotacoes () <<Protocol>> AtivacaoPeriodica interrupcao () <<Protocol>>

47 Identificando Protocolos Associar protocolos a cápsulas
Associações entre protocolos e cápsulas InterfaceRelogio <<Capsule>> ControladorAtualizacaoCotacoes <<Capsule>> ComunicacaoOperadoraMercadoAcoes <<Capsule>> ConsultaCotacoes consultarCotacoes () dadosCotacoes () <<Protocol>> AtivacaoPeriodica interrupcao () <<Protocol>> ComuicacaoBOVESPA <<Capsule>> ComuncacaoNASDAQ <<Capsule>>

48 Criando portas e associando portas a protocolos
mar-17 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 O tipo da porta é definido pelo papel do protocolo representado para a respectiva porta. Fluxo de análise e projeto

49 Exemplo AtivacaoPeriodica interrupcao (void) <<Protocol>>
ConsultaCotacoes consultarCotacoes (void) dadosCotacoes (void) InterfaceRelogio + / interrupcao : AtivacaoPeriodica # / timer : Timing <<Capsule>> + / interrupcao <<Port>> ComunicacaoOperadoraMercadoAcoes + / consultaCotacoes : ConsultaCotacoes~ # / consultaBovespa : ConsultaCotacoes # / consulataNasdaq : ConsultaCotacoes + / consultaCotacoes~ ComunicacaoBovespa consultarCotacaoBovespa() + / consultaCotacaoBovespa : ConsultaCotacoes~ / comunicacaoBovespaR1 ComunicacaoNasdaq consultaCotacaoNasdaq() + / consultaCotacaoNasdaq : ConsultaCotacoes~ (from controladores) / comunicacaoNasdaqR1 ControladorAtualizacaoCotacoes + / interrupcao : AtivacaoPeriodica~ + / consultaCotacoes : ConsultaCotacoes + / interrupcao~ + / consultaCotacoes ISubsistemaComunicacaoOperadoraMercadoAcoes iniciarConexao() consultarCotacoes() 1 FachadaComunicacaoOperadoraMercadoAcoes (from subsistemaComunicacaoMercadoAcoes)

50 Identificando subsistemas
mar-17 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 Classes de análise que provêem serviços complexos, como as classes de fronteira (especialmente as que possuem interface com outros sistemas), são candidatas naturais a subsistemas. Classes de controle auto-contidas e com serviços bem específicos também podem resultar em subsistemas. Fluxo de análise e projeto

51 Identificando subsistemas
mar-17 <<subsystem>> Subsistema X Classe A Y() Z() Y() Z() <<interface>> Interface A Classe complexa A decisão de transformar uma classe com serviços complexos em um subsistema é baseada na experiência do arquiteto e a definição da interface do subsistema pode levar algum tempo para estabilizar. Os detalhes de como os serviços (que eram da classe complexa) especificados na interface do subsistema devem ser implementados, são postergados para a atividade Projetar Subsistema. Fluxo de análise e projeto

52 <<subsystem>>
A classe fachada mar-17 Além da interface, é destacada uma classe fachada de cada subsistema Interface <<subsystem>> nomeSubsistema FachadaSubsistema ISubSistema Todo subsistema deve apresentar uma classe fachada, com visibilidade pública, que implementa a interface do subsistema. É através da fachada que os clientes do subsistema acessam os seus serviços. Fluxo de análise e projeto

53 Passo 2. Identificar oportunidades de reuso
mar-17 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 Verifique se algum subsistema pode ser comprado ou reutilizado, ao invés de desenvolvido completamente pela equipe. Às vezes, algumas modificações na interface do subsistema podem ser necessárias para que se possa reutilizar um componente já pronto. Nestes casos, avalie a relação custo-benefício e, se for o caso, altere a interface correspondente. Avalie também se algum subsistema pode ser modificado de forma a se tornar mais facilmente reutilizável por outras aplicações da instituição. Em caso positivo, avalie o custo da modificação necessária e, sempre que possível, modifique a interface do respectivo subsistema de forma a aumentar a sua reusabilidade. Fluxo de análise e projeto

54 Passo 3. Definir a estrutura da aplicação
mar-17 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 Vamos adotar a estrutura em camadas recomendada pela Qualiti-CESAR. Fluxo de análise e projeto

55 Estruturação em camadas
mar-17 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 A separação do código em camadas independentes permite que se troque a interface gráfica ou o meio de armazenamento dos dados (arquivos por um SGBD, por exemplo) sem afetar as regras de negócio do sistema. Isso facilita a reusabilidade das classes básicas do negócio em outros projetos e permite maior flexibilidade na escolha de tecnologias para implementar a aplicação. Negócio Dados Fluxo de análise e projeto

56 Juntando tudo - Visão geral da arquitetura
mar-17 GUI / Comunicação NEGÓCIO Interfaces negócio-dados DADOS Fachada TelaLogin TelaPagamentoQualitiCard ControladorLogin ControladorPagamentoQualitiCard CadastroPagamentosCartao ... ContaInternet PagamentoCartao IRepositorioContasInternet IRepositorioPagamentosCartao RepositorioPagamentosCartaoBDR RepositorioPagamentosCartaoBDOO RepositorioContasInternetBDR RepositorioContasInternetArquivo CadastroContasInternet Esta figura mostra as classes do QIB organizadas nas camadas GUI, Comunicação, Negócio e Dados. As classes TelaLogin e TelaPagamentoQualitiCard ainda estão encapsulando funcionalidades de GUI e Comunicação. Fluxo de análise e projeto

57 Arquitetura – incorporando cápsulas
Negócio Interfaces negócio-dados Dados TelaConsultarCotacoes - Capsula ControladorAtualizacaoCotacoes - Capsula IRepositorioCotacoes RepositorioCotacoesBDR RepositorioCotacoesArquivo CadastroCotacoes Comunicação ConsultaCotacoes – Protocolo ComunicacaoOperadora - Capsula ISubsistemaComunicacaoOperadaoraMercadoAcoes CadastroOperadoraMercadoAcoes IRepositorioOperadoraMercadoAcoes RepositorioMercadoAcoesBDR RepositorioMercadoAcoesArquivo InterfaceRelogio – Capsula AtivacaoPeriodica - Protocolo GUI GUI

58 Arquitetura completa GUI Negócio Interfaces negócio-dados
Fachada - Capsula TelaConsultarCotacoes - Capsula ControladorAtualizadorCotacoes - Capsula IRepositorioCotacoes Repositorio CotacoesBDR Cotacoes Arquivo CadastroCotacoes Comunicação ConsultaCotacoes – Protocolo CadastroOperadora MercadoAcoes IRepositorioOperadoraMercadoAcoes MercadoAcoesBDR MercadoAcoesArquivo TelaLogin - Capsula TelaPagamentoQualitiCard - Capsula PagamentoQualitiCard – Protocolo PagamentoLogin – Protocolo ControladorPagamentoQualitiCard CadastroPagamentoCartao PagamentoCartao IRepositorioPagamentoCartao ControladorLogin CadastroContas Internet ContaInternet IRepositorioContas ContasInternetBDR ContasInternetArquivo PagamentosCartaoBDR PagamentosCartaoBDOO InterfaceRelogio - Capsula AtivacaoPeriodica – Protocolo ComunicacaoControlador – Protocolo Dados

59 Agrupar as classes em pacotes
mar-17 À 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 A definição das camadas vista acima não está diretamente relacionada a organização dos pacotes da aplicação, isto é, as camadas não correspondem diretamente aos pacotes do sistema, elas apenas guiam a escolha das classes que serão usadas no sistema. Fluxo de análise e projeto

60 QIB – Efetuar Login e Efetuar Pagamento do Qualiti Card
mar-17 Organização de pacotes Inclui cápsulas conta protocolos No pacote GUI estão todas as classes relacionadas a interface da aplicação, como TelaLogin, TelaMenu e TelaPagamentoQualitiCard. Em controladores estão a Fachada, o ControladorLogin e o ControladorPagamentoQualitiCard. No pacote util estão classes utilitárias que serão utilizadas por qualquer outro pacote, como Data e Hora. No pacote conta estão as classes ContaCorrente, CadastroContasCorrente, IRepositorioContasCorrente, RepositorioContasCorrenteBDR, ContaInternet, CadastroContasInternet, IRepositorioContasInternet e RepositorioContasInternetBDR. O pacote subsistemaComunicacaoOperadoraCartao contém todas as classes relacionadas à implementação deste subsistema (por enquanto, a interface ISubsistemaComunicacaoOperadoraCartao e FachadaComunicacaoOperadoraCartao). O pacote transacao armazena as classes Transacao, PagamentoCartao, CadastroTransacao, IRepositorioTransacoes e RepositorioTransacoesBDR. Fluxo de análise e projeto

61 Projetar Cápsulas <<subsystem>> Revisor de projeto
Arquiteto de Software Projetar Arquitetura Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas Projetar Cápsulas decisões do arquiteto <<subsystem>> Analista de Sistemas Projetar Base de Dados Revisar Projeto Projetista de Banco de Dados

62 Passos para Projetar Cápsulas
Definir diagrama de estados Validar comportamento da cápsula

63 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

64 Diagrama de estados x diagrama de interação
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)

65 Diagramas de Estados Notação
Principais elementos estado transicão transicão final transicão inicial super-estado transicão de origem externa auto-transicão sub-estado H Estado história

66 Diagrama de Estados - InterfaceRelogio
Cápusla: InterfaceRelogio

67 Diagrama de Estados – ComunicacaoBovespa sem ACK
Cápsula: ComunicacaoBovespa

68 Diagrama de Estados – ComunicacaoBovespa com ACK
Cápsula: ComunicacaoBovespa

69 Exemplo – QIB Mercado de Ações Diagrama de estados
Cápsula: ComunicacaoOperadoraMercadoAcoes / comunicacaoBovespaR1 : ComunicacaoBovespa / comunicacaoNasdaqR1 : ComunicacaoNasdaq + / consultaCotacoes~ + / consultaCotacaoBovespa~ + / consultaCotacaoNasdaq~ # / consultaCotacaoBovespa~ # / consulataCotacaoNasdaq~ + / dadosCotacoesNasdaq~ + / dadosCotacoesBovespa~ + / dadosCotacoes~ Sub-cápsulas

70 Fluxo de Análise e Projeto
mar-17 Projetar Arquitetura Arquiteto de Software Revisor de projeto Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas Projetar Cápsulas Analista de Sistemas Projetar Base de Dados Revisar Projeto Projetista de Banco de Dados Fluxo de análise e projeto