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

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

1 Fluxo de Análise e Projeto do RUP para Sistemas de Tempo Real
abr-17 Fluxo de Análise e Projeto do RUP para Sistemas de Tempo Real Robson Godoi Fluxo de análise e projeto

2 Objetivos do fluxo de análise e projeto
abr-17 Objetivos do fluxo de análise e projeto 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 Arquitetura de software O modelo de “4+1 Visões”
abr-17 Arquitetura de software O modelo de “4+1 Visões” Estrutura, componentes Estrutura Visão Lógica Visão de Implementação Analista de Sistemas Programadores Visão de Casos de Uso Arquiteto Visão de Processos Visão de Distribuição A definição da arquitetura consiste de um conjunto de visões do sistema, que são usadas mais ou menos como as diversas plantas arquitetônicas de uma construção. Para construir algo, o arquiteto fornece o desenho da fachada, a planta baixa, a planta que descreve as instalações elétrica e hidráulica etc. As diversas plantas são usadas pelo mestre de obras, pedreiros, encanadores, eletricistas, de acordo com a atividade que deve ser realizada por cada um. Da mesma maneira, o arquiteto do projeto fornece as diversas visões da arquitetura do sistema (que são, na verdade, modelos do sistema descritos através de diagramas de UML), que serão usadas pelos desenvolvedores de acordo com suas atividades. Nesta parte do curso estaremos nos concentrando na visão lógica e na visão de distribuição. A visão lógica apresenta a estrutura e a organização do projeto do sistema, ilustrando os subsistemas, pacotes e classes que são arquiteturalmente relevantes, bem como os mecanismos de arquitetura e design a serem utilizados (persistência, comunicação, controle de falha, concorrência, etc). A visão implementação descreve a organização dos elementos “estáticos” do software (código, dados e outros artefatos) em um ambiente de desenvolvimento em termos de pacotes, camadas e gerenciamento de configuração. A visão de processos descreve a estrutura de processos planejada para o sistema. Isto engloba os componentes dinâmicos, decomposições em tempo de execução e alguns aspectos não funcionais como: performance, disponibilidade, etc. O sistema é decomposto em conjuntos independentes de task/threads, processos e grupos de processos. A visão de distribuição mostra a configuração dos nós de processamento em tempo de execução, os componentes que são armazenados em cada nó e objetos que são armazenados nos componentes e nós. Arquiteto Topologia, implantação, comunicação Arquiteto Escalabilidade Fluxo de análise e projeto

4 O Fluxo de Análise e Projeto
abr-17 O Fluxo de Análise e Projeto Planejamento e Gerenciamento..... Fluxos de Suporte Gerência de Configuração Requisitos Análise e Projeto Implementação Testes Implantação Fluxos de Processo Iterações Fases Concepção Elaboração Construção Transição Inicial Fluxo de análise e projeto

5 Visão geral dos artefatos
abr-17 Visão geral dos artefatos 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 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, porém é uma maneira eficiente de utilizar padrões de projeto. Glossário Documento de Requisitos Projeto de Banco de Dados Fluxo de análise e projeto

6 Artefato Realização de Caso de Uso
abr-17 Artefato Realização de Caso de Uso Modelo de Casos de Uso Modelo de Análise e Projeto Caso de Uso Realização de Caso de Uso Diagrama de Seqüência A realização do caso de uso é o conjunto de elementos (classes, associações, diagramas etc.) que descreve como o caso de uso será realizado. Para que os elementos envolvidos na realização de cada caso de uso sejam facilmente identificados, eles devem ser agrupados em uma área comum, relacionada ao respectivo caso de uso. Em UML, uma realização de caso de uso pode ser representada através de um conjunto de diagramas: diagrama de classe diagrama de seqüência diagrama de colaboração Diagrama de Classes Diagrama de Colaboração Fluxo de análise e projeto

7 Fluxo de Análise e Projeto
abr-17 Fluxo de Análise e Projeto Revisor da Arquitetura Analisar Arquitetura Projetar Arquitetura Projetista de Cápsula Arquiteto de Software Projetar Cápsula Refinar / Decompor Cápsula Revisar Arquitetura Projetar Casos de Uso Analista de Sistemas Analisar Casos de Uso Projetista de Banco de Dados Revisor de Projeto Projetar Subsistemas Projetar Classes Projetar Base de Dados Revisar Projeto Fluxo de análise e projeto

8 Fluxo de Análise e Projeto
abr-17 Fluxo de Análise e Projeto Revisor da Arquitetura Projetista de Capsula Analisar Arquitetura Projetar Arquitetura Arquiteto de Software Check List  bla bla  bla  blabla Projetar Capsula decisões do arquiteto Revisar Arquitetura Analisar Casos de Uso Projetar Casos de Uso Analista de Sistemas Arquiteto Lidera e coordena as atividades técnicas e a construção dos artefatos do projeto. Estabelece a estrutura das visões arquiteturais : Decompõe o sistema em visões; Agrupa os elementos de projeto em subsistemas, pacotes, módulos e define suas interfaces; Identifica unidades de concorrência Tem uma visão larga e superficial do sistema Analista Faz a realização dos casos de uso de forma consistente com a arquitetura Deve conhecer: A tecnologia a ser usada no desenvolvimento do sistema; As técnicas de modelagem de casos de uso; Os requisitos do sistema; As técnicas de análise e projeto orientado a objetos; A linguagem UML BD Define a estrutura de dados da aplicação, como tabelas, índices, visões, triggers, etc. Deve possuir um conhecimento sólido em análise e projeto orientado a objetos e banco de dados Revisor Planeja e conduz revisões formais do modelo de análise e projeto Deve ser experiente e ter como objetivo a descoberta de problemas no modelo Deve ter um conhecimento equivalente ao de um arquiteto Projetista de Banco de Dados Revisor de Projeto Check List  bla bla  bla  blabla Projetar Base de Dados <<subsystem>> Revisar Projeto Projetar Subsistemas Projetar Classes Fluxo de análise e projeto

9 abr-17 Analisar Caso de Uso Fluxo de análise e projeto

10 Analisar Casos de Uso abr-17 Fluxo de análise e projeto Revisor da
Arquitetura Analisar Arquitetura Projetar Arquitetura Projetista de Cápsula Arquiteto de Software Projetar Cápsula Revisar Arquitetura Analisar Casos de Uso Projetar Casos de Uso Analista de Sistemas Projetista de Banco de Dados Revisor de Projeto Projetar Subsistemas Projetar Classes Projetar Base de Dados Revisar Projeto Fluxo de análise e projeto

11 Objetivos desta atividade
abr-17 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! Esta atividade é realizada uma vez para cada caso de uso a ser desenvolvido na iteração, isto é, o foco da atividade é em um caso de uso específico. Fluxo de análise e projeto

12 Visão geral dos artefatos
abr-17 Visão geral dos artefatos Modelo de Casos de Uso Documento de Requisitos Glossário Documento da Arquitetura Realização de Caso de Uso Analisar Caso de Uso Analista de Sistemas Os elementos chave desenvolvidos nesta atividade são as classes de análise e as primeiras versões das realizações dos casos de uso, que fazem parte do Modelo de Análise e Projeto. Diagrama de Colaboração Diagrama de Classes Diagrama de Seqüência Fluxo de análise e projeto

13 Passos para Analisar Casos de Uso
abr-17 Passos para Analisar Casos de Uso 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

14 Passo 1. Encontrar classes de análise
abr-17 Passo 1. Encontrar classes de análise 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. Classes de fronteira (entre os atores e os casos de uso), isolam o sistema de mudanças no ambiente externo (Gui, Interface com out. sistemas ou dispositivos); Classes de entidade (armazenam e controlam a informação que o sistema utiliza), . 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. Classes de controle (controlam a lógica do caso de uso), interface entre fronteira e entidade, independe do ambiente; Geralmente, é definida uma classe controle para cada caso de uso. Porém, casos de uso com fluxos simples podem ser realizados sem classes de controle, com as classes de fronteira trocando informação diretamente com as classes de entidade. Já casos de uso com fluxos mais complexos geralmente precisam de uma ou mais classes de controle para coordenar a ação de outros objetos do sistema. Alguns exemplos de classes de controle são classes fachada (que implementam o padrão de projeto Facade). 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. Notação em UML Fluxo de análise e projeto

15 Classes de análise: um primeiro passo em direção ao executável
abr-17 Classes de análise: um primeiro passo em direção ao executável Classes de Análise Modelo de Casos de Uso Elementos de Projeto Códigos Fonte 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, durante as atividades de projeto. Executável Fluxo de análise e projeto

16 Exemplo - Efetuar Login
abr-17 Exemplo - Efetuar Login Efetuar Login ClienteAtor Fluxo de análise e projeto

17 Efetuar Login – Fluxo de eventos
abr-17 Efetuar Login – Fluxo de eventos 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

18 Passo 2. Identificar persistência
abr-17 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>> 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

19 Passo 3. Distribuir comportamento entre as classes
abr-17 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 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

20 Distribuir comportamento entre as classes
Diagrama de Seqüência Diagrama de Colaboração Classes de Análise Caso de Uso Classes de Análise (com responsabilidades)

21 abr-17 Efetuar Login Diagramas de interação são usados para descrever a interação entre as classes (troca de mensagens) necessárias para realizar o fluxo de eventos do caso de uso. Eles são úteis na hora de identificar as responsabilidades de cada classe (operações que são implementadas pela classe). As classes de análise encontradas no passo anterior são o ponto de partida para a elaboração dos diagramas de interação. 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 Usuário e Mensagem (identificadas inicialmente como classes de análise) não são usadas aqui, pois Usuário é 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

22 Passo 4. Descrever Responsabilidades
abr-17 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 diagrama de interação :Cliente :Fornecedor 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. // Realizar responsabilidade diagrama de classes Fornecedor // Realizar responsabilidade Fluxo de análise e projeto

23 Efetuar Login Classes com responsabilidades
abr-17 Efetuar Login Classes com responsabilidades Você deve analisar as classes identificadas levando em consideração os itens listados acima. Este processo pode resultar em uma alteração dos diagramas de interação para uma melhor distribuição de comportamento. Deve ser realizado também no final da análise de cada caso de uso. Fluxo de análise e projeto

24 Passo 5. Descrever atributos e associações
abr-17 Passo 5. Descrever atributos e associações 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. Associações são relacionamentos estruturais entre classes, representando ligações que devem ser mantidas entre os objetos das classes associadas. Os diagramas de interação são, novamente, boas fontes para se identificar associações entre classes, pois a comunicação (troca de mensagens) entre objetos significa que pelo menos um deles deve conhecer o outro, podendo representar a necessidade de uma associação entre os objetos. Identifique as associações existentes entre as classes do caso de uso e documente-as no diagrama de classes elaborado anteriormente. Caso você identifique dependências, agregações e composições, pode documentá-las também. Todavia, se estiver em dúvida sobre a natureza de uma determinada associação (associação simples, agregação ou composição), represente-a como uma associação simples – você poderá substituí-la depois, se desejar. Fluxo de análise e projeto

25 Efetuar Login Diagrama de classes com relacionamentos e atributos

26 Passo 6. Revisar Resultados
abr-17 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 Ao terminar a análise, é importante verificar se todo o comportamento do caso de uso pode realmente ser realizado com as classes e responsabilidades que foram encontradas. Além disso, as classes envolvidas na realização do caso de uso devem estar definidas de forma consistente e coesa. Em particular, deve-se considerar os pontos listados a seguir. Todos os fluxos de eventos, inclusive os fluxos secundários do caso de uso, podem ser realizados com as classes que foram encontradas? As classes representam abstrações simples e bem definidas? Observe as responsabilidades de cada classe – uma classe com muitas responsabilidades talvez deva ser dividida em classes menores e mais coesas. Existe alguma classe sem responsabilidades ou com apenas uma responsabilidade? A falta de responsabilidades pode ser um indício de que a classe é supérflua. Existem classes diferentes que apresentam comportamento semelhante ou que representam o mesmo conceito no sistema? Em caso positivo, elas devem ser unificadas em uma única classe. Fluxo de análise e projeto

27 abr-17 Projetar Arquitetura Fluxo de análise e projeto

28 abr-17 Projetar Arquitetura Analisar Arquitetura Projetar Arquitetura Projetista de Cápsula Revisor da Arquitetura Arquiteto de Software Projetar Cápsula Revisar Arquitetura Analista de Sistemas Analisar Casos de Uso Projetar Casos de Uso As classes de análise, identificadas durante a atividade Analisar caso de uso, modelam os objetos do universo no qual o sistema está inserido, isto é, modelam o que o sistema irá tratar. Agora é hora de considerar os requisitos não funcionais – assim como quaisquer restrições do ambiente de implementação e execução – e mapear as classes de análise em elementos que modelem a solução do problema, isto é, elementos que apresentem como o sistema irá realizar suas funções. Agora é hora de definir a estrutura da aplicação como um todo, identificando que mecanismos serão necessários para implementar as classes encontradas na análise de caso de uso, e definindo os pacotes da aplicação. Durante esta atividade, o arquiteto deve verificar se é possível reusar algum subsistema já pronto, ou se algum subsistema deve ser projetado de forma a ser reusado em outras aplicações. É verificado também a possibilidade de uso de padrões de projeto. Projetista de Banco de Dados Revisor de Projeto Projetar Subsistemas Projetar Classes Projetar Base de Dados Revisar Projeto Fluxo de análise e projeto

29 Visão geral dos artefatos
abr-17 Visão geral dos artefatos Modelo de Análise e Projeto (classes de análise) Documento de Requisitos Modelo de Casos de Uso Projetar Arquitetura Arquiteto Modelo de Análise e Projeto (classes de projeto, cápsulas e subsistemas) Mapeamento das Classes de Análise em Elementos de Projeto Documento da Arquitetura Fluxo de análise e projeto

30 Passos para Projetar Arquitetura
abr-17 Passos para Projetar Arquitetura 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 4. Descrever a concorrência 5. Descrever a distribuição Fluxo de análise e projeto

31 Identificar classes de projeto Identificar subsistemas
abr-17 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 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

32 Identificando classes de projeto
abr-17 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 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

33 Identificando subsistemas
abr-17 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 Subsistemas permitem dividir o sistema em partes independentes (que se tornarão componentes) Cada subsistema pode ser desenvolvido, testado e possivelmente implantado independentemente dos demais Um subsistema pode representar uma abstração (no projeto) de produtos ou sistemas externos que serão incorporados na implementaçã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

34 Identificando subsistemas
abr-17 Identificando subsistemas <<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

35 <<subsystem>>
abr-17 A classe fachada Além da interface, é destacada uma classe fachada de cada subsistema Interface <<subsystem>> nomeSubsistema 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. FachadaSubsistema ISubSistema Fluxo de análise e projeto

36 Identificando Cápsulas
abr-17 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 Fluxo de análise e projeto

37 Mapeamento das Classes de Análise em Cápsulas
abr-17 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. Fluxo de análise e projeto

38 Árvore de decisão Classes de Fronteira e de Controle
abr-17 Árvore de decisão Classes de Fronteira e de Controle Representa um componente externo? S Transformar em cápsula N S N 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>> Fluxo de análise e projeto

39 Árvore de decisão Classes de Fronteira e de Controle
abr-17 Árvore de decisão Classes de Fronteira e de Controle Representa um componente externo? S N S Reage a eventos externos? Transformar em cápsula N Controla outras cápsulas? S N Controla apenas acesso a dados? N S Continuar como classe <<boundary>> ou <<control>> Fluxo de análise e projeto

40 Cápsulas e Concorrência
abr-17 Cápsulas e Concorrência Concorrência externa Concorrência interna Fluxo de análise e projeto

41 Caso de uso – Atualizar Cotações
abr-17 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 Fluxo de análise e projeto

42 Fluxo de eventos – Atualizar cotações
abr-17 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. Fluxo de análise e projeto

43 Exemplo - Mercado de Ações Classes de Análise
abr-17 Exemplo - 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>> Fluxo de análise e projeto

44 Exemplo - Mercado de Ações Classes de Análise
abr-17 Exemplo - Mercado de Ações Classes de Análise InterfaceRelogio <<capsule>> ControladorAtualizacaoCotacoes <<capsule>> ComunicacaoOperadoraMercadoAcoes <<capsule>> ComunicacaoNasdaq <<capsule>> ComunicacaoBovespa <<capsule>> Falar sobre a possibilidade de concorrência no sistema legado. IComunicacaoOperadoraMercadoAcoes – seria um protocolo, se houvesse uma cápsula para o legado. RUP não fala nada sobre o assunto. Propor cápsulas, e abstrair o legado como um Mecanismo Padrão de Arquitetura Concorrente (Web Server) IComunicacaoOperadoraMercadoAcoes <<interface>> Fluxo de análise e projeto

45 Identificando Protocolos das Cápsulas
abr-17 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. Fluxo de análise e projeto

46 Identificando Protocolos das Cápsulas
abr-17 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 Fluxo de análise e projeto

47 Identificando Protocolos Gráfico de interações entre cápsulas
abr-17 Identificando Protocolos Gráfico de interações entre cápsulas InterfaceRelogio <<Capsule>> ControladorAtualizacaoCotacoes <<Capsule>> interrupcao dadosCotacoes consultarCotacoes ComunicacaoOperadoraMercadoAcoes <<Capsule>> 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 consultarCotacoesNasdaq consultarCotacoesBovespa ComunicacaoNasdaq <<Capsule>> ComunicacaoBovespa <<Capsule>> dadosNasdaq dadosBovespa Fluxo de análise e projeto

48 Identificando Protocolos Criar os protocolos
abr-17 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 Fluxo de análise e projeto

49 Identificando Protocolos Criar os protocolos
abr-17 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 Fluxo de análise e projeto

50 Identificando Protocolos Criar os protocolos
abr-17 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>> Fluxo de análise e projeto

51 Identificando Protocolos Identificar similaridades entre protocolos
abr-17 AtivacaoPeriodica interrupcao () <<Protocol>> InteracaoNasdaq <<Protocol>> consultarConexaoNasdaq (void) dadosCotacoesNasdaq (void) ConsultaCotacoes dadosCotacoes () consultarCotacoes () <<Protocol>> InteracaoBovespa <<Protocol>> consultarCotacoesBovespa (void) dadosCotacoesBovespa (void) Fluxo de análise e projeto

52 Identificando Protocolos Protocolos identificados
abr-17 Identificando Protocolos Protocolos identificados Finalmente... ConsultaCotacoes dadosCotacoes () consultarCotacoes () <<Protocol>> AtivacaoPeriodica interrupcao () <<Protocol>> Fluxo de análise e projeto

53 Identificando Protocolos Associar protocolos a cápsulas
abr-17 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>> Fluxo de análise e projeto

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

55 Exemplo abr-17 Fluxo de análise e projeto AtivacaoPeriodica
interrupcao (void) <<Protocol>> InterfaceRelogio + / interrupcao : AtivacaoPeriodica # / timer : Timing <<Capsule>> + / interrupcao <<Port>> ControladorAtualizacaoCotacoes + / interrupcao : AtivacaoPeriodica~ + / consultaCotacoes : ConsultaCotacoes + / interrupcao~ Fluxo de análise e projeto

56 Passo 2. Identificar oportunidades de reuso
abr-17 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 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

57 Passo 3. Definir a estrutura da aplicação
abr-17 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 O arquiteto pode seguir um padrão já existente para estruturar a aplicação Se o arquiteto adotar uma estrutura diferente do padrão, deve descrevê-la no Documento da Arquitetura O arquiteto também pode definir novos padrões ou atualizar orientações já existentes Fluxo de análise e projeto

58 Estruturação em camadas
abr-17 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) 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. Modularidade: Dividir para conquistar; Separação de conceitos; Reusabilidade; Extensibilidade Mudanças em uma camada não afetam as outras, desde que as interfaces sejam preservadas - plug-and-play Uma mesma versão de uma camada trabalhando com diferentes versões de outra camada : várias GUIs para a mesma aplicação; vários mecanismos de persistência suportados pela mesma aplicação; várias plataformas de distribuição para acesso a uma mesma aplicação Comunicação Negócio Dados Fluxo de análise e projeto

59 Camada de negócios Responsável por implementar a lógica do negócio
abr-17 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 Esta camada é o núcleo do sistema, responsável por implementar a lógica do negócio. Nela estão todas as classes inerentes ao domínio da aplicação, como as classes básicas do negócio, as coleções de negócio e a classe fachada do sistema. Fluxo de análise e projeto

60 Classes básicas do negócio
abr-17 Classes básicas do negócio Representam conceitos básicos do domínio da aplicação As classes básicas representam objetos básicos manipulados pelo sistema. O Amazon, por exemplo, possui as classes básicas mostradas acima, necessárias para representar conceitos centrais ao domínio da aplicação.      Fluxo de análise e projeto

61 abr-17 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 As coleções de negócio representam conjuntos de classes básicas e são responsáveis pela manutenção das instâncias destas classes. Por exemplo, a inclusão, remoção ou atualização de um cliente é responsabilidade da classe CadastroClientes. Fluxo de análise e projeto

62 Fachada do sistema Segue o padrão de projeto Facade
abr-17 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 A fachada representa os serviços que são oferecidos pelo sistema, podendo implementar uma ou mais interfaces públicas para oferecer diferentes visões dos serviços disponíveis. Esta classe centraliza todas as instâncias das coleções de negócio da aplicação e pode ser o único ponto de acesso ao sistema (quando construída segundo o padrão de projeto Singleton). A fachada pode encapsular verificações e validações inerentes ao negócio como, por exemplo, verificar se uma determinada instância possui relacionamentos com outras instâncias antes de removê-la. Fluxo de análise e projeto

63 abr-17 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 As classes desta camada são responsáveis pela manipulação da estrutura física de armazenamento dos dados. São elas que isolam o resto do sistema do meio de armazenamento usado (memória, arquivos simples, SGBD relacional, etc.), de maneira que se o meio de armazenamento for trocado, apenas as classes desta camada terão que ser modificadas ou substituídas. A camada de negócio utiliza os serviços desta camada – mais especificamente, os serviços de classes referenciadas como coleções de dados – para inserir, atualizar, remover e consultar instâncias das classes básicas. Fluxo de análise e projeto

64 abr-17 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 RepositorioContasBDR Fluxo de análise e projeto

65 Coleções de dados Dependem do meio de armazenamento!
abr-17 Coleções de dados Dependem do meio de armazenamento! RepositorioContasBDOO RepositorioContasBDR RepositorioContasArquivo Fluxo de análise e projeto

66 Independência do meio de armazenamento
abr-17 Independência do meio de armazenamento Como isolar as coleções de negócio de mudanças na coleção de dados correspondente? CadastroContas <<interface>> RepositorioContas As coleções de dados dependem do meio de armazenamento utilizado. Porém, seus serviços são implementados de acordo com uma interface comum, chamada interface negócio-dados. As coleções de negócio na verdade referenciam objetos do tipo dessa interface, assim, as coleções de dados podem ser alteradas ou substituídas sem afetar as coleções de negócio que usam seus serviços. RepositorioContasBDR RepositorioContasArquivo Fluxo de análise e projeto

67 Interface negócio-dados
abr-17 Interface negócio-dados Sugestão de serviços <<interface>> RepositorioContas inserir(conta: Conta): void atualizar(conta: Conta): void remover(conta: Conta): void consultarConta(login: String): Conta As consultas realizadas nas coleções de dados podem retornar vários objetos que precisem ser manipulados pela camada de negócios. Fluxo de análise e projeto

68 Incorporando cápsulas
abr-17 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. Fluxo de análise e projeto

69 Classes de análise - a origem de tudo
abr-17 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 Existe certa relação das classes de análise (entidade, fronteira e controle), encontradas durante a atividade Analisar Caso de Uso, com as classes e pacotes discutidos anteriormente. Classes de entidade, na maioria das vezes, transformam-se em classes básicas do negócio e levam a criação das respectivas coleções de negócio e coleções de dados. Classes de fronteira com usuários do sistema representam elementos da interface gráfica e tornam‑se parte do pacote gui. Entretanto, classes fronteira com outros sistemas normalmente evoluem para subsistemas, com suas respectivas fachadas. Classes de controle são usadas para coordenar a execução de casos de uso, assim, o conjunto delas forma a base a partir da qual é criada a fachada do sistema como um todo. Fluxo de análise e projeto

70 Agrupar as classes em pacotes
abr-17 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 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

71 Passo 4. Descrever a concorrência
abr-17 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 Fluxo de análise e projeto

72 Visão geral dos artefatos
abr-17 Visão geral dos artefatos Cápsula Modelo de Projeto Descrever Concorrência Documento da Arquitetura Documento da Arquitetura Requisitos Não Funcionais Fluxo de análise e projeto

73 Como Descrever a Concorrência
abr-17 Como Descrever a Concorrência 1. Analisar os requisitos de concorrência 2. Identificar processos e threads 3. Identificar o ciclo de vida dos processos 4. Identificar os mecanismos de comunicação entre processos (IPC). 5. Coordenar a alocação de recursos entre processos 6. Mapear os processos para o ambiente de implementação 7.Distribuir os elementos do projeto dentro dos processos 1) Definir a extensão que tarefas de execução paralela são requeridas pelo sistema (Ajuda a definir a forma da arquitetura); Requisitos não funcionais : Grau de distribuição que o sistema necessita; Capacidade computacional requerida; Grau de paralelismo suportado pelo ambiente; Necessidade de tolerância a falha; Direcionamento a eventos do sistema 3) Identificar quando Threads e Processos são criados. 4) Meio de comunicação (Memória compartilhada; Semáforos, RPC, Broadcast, etc) 5)Alocar recursos escassos; Antecipar e gerencias potenciais gargalos de performance Fluxo de análise e projeto

74 Passo 5. Descrever a distribuição
abr-17 Passo 5. Descrever a distribuição Objetivo Definir como a funcionalidade do sistema será distribuída através dos nós físicos Fluxo de análise e projeto

75 Como Descrever a distribuição
abr-17 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 Fluxo de análise e projeto

76 abr-17 Projetar Cápsulas Fluxo de análise e projeto

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

78 Objetivos desta atividade
abr-17 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 corrente Todas as cápsulas devem estar projetadas até o final da fase de elaboração Fluxo de análise e projeto

79 Visão geral dos artefatos
abr-17 Visão geral dos artefatos Modelo de Análise e Projeto Requisitos Não Funcionais Projetar Cápsulas Projetista de Cápsula Projeto de Cápsulas Fluxo de análise e projeto

80 Passos para Projetar Cápsulas
abr-17 Passos para Projetar Cápsulas Definir diagrama de estados Validar comportamento da cápsula Fluxo de análise e projeto

81 Passo 1. Definir diagrama de estados
abr-17 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 Fluxo de análise e projeto

82 Diagrama de estados x diagrama de interação
abr-17 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) Fluxo de análise e projeto

83 Diagramas de Estados Notação
abr-17 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 Estado é uma condição de um objeto no qual este realiza alguma atividade ou espera por determinado evento. É composto de: Nome – Identifica unicamente o estado Entry action – Ação executada a cada entrada no estado Exit action – Ação executada a cada saída do estado Máquina de estados interna – Máquina de estados filha, no caso de super-estados Transição é um relacionamento direcionado entre dois estados (origem e destino) e indica que um objeto no estado origem executará determinada ação e entrará no estado destino, quando ocorrer determinado evento e se certas condições forem satisfeitas É composta de: Nome - Identifica unicamente a transição Estado origem – estado de saída da transição Evento de disparo – evento que ativa a transição Condição de guarda – condição que deve ser satisfeita para a transição ser efetivada Ação – ação executada na transição Estado destino – estado de chegada da transição Fluxo de análise e projeto

84 Diagrama de Estados - InterfaceRelogio
abr-17 Diagrama de Estados - InterfaceRelogio Cápsula: InterfaceRelogio Fluxo de análise e projeto

85 Diagrama de Estados – ComunicacaoBovespa sem ACK
abr-17 Diagrama de Estados – ComunicacaoBovespa sem ACK Cápsula: ComunicacaoBovespa Fluxo de análise e projeto

86 Diagrama de Estados – ComunicacaoBovespa com ACK
abr-17 Diagrama de Estados – ComunicacaoBovespa com ACK Cápsula: ComunicacaoBovespa Fluxo de análise e projeto

87 Passo 2. Validar comportamento da cápsula
abr-17 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? Fluxo de análise e projeto

88 Refinar / Decompor Cápsulas
abr-17 Refinar / Decompor Cápsulas Fluxo de análise e projeto

89 Refinar / Decompor Cápsulas
Analisar Arquitetura Projetar Arquitetura Projetista de Cápsula Revisor da Arquitetura Arquiteto de Software Projetar Cápsula Refinar / Decompor Cápsula Revisar Arquitetura Projetar Casos de Uso Analista de Sistemas Analisar Casos de Uso Projetista de Banco de Dados Revisor de Projeto Projetar Subsistemas Projetar Classes Projetar Base de Dados Revisar Projeto

90 Objetivos desta atividade
abr-17 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 Fluxo de análise e projeto

91 Visão geral dos artefatos
abr-17 Visão geral dos artefatos Modelo de Análise e Projeto Projeto de Cápsulas Requisitos Não Funcionais Refinar / Decompor Cápsulas Projetista de Cápsula Projeto de Cápsulas Fluxo de análise e projeto

92 Passos para Refinar / Decompor Cápsulas
abr-17 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 Fluxo de análise e projeto

93 Fluxo de Análise e Projeto do RUP para Tempo Real
abr-17 Fluxo de Análise e Projeto do RUP para Tempo Real Robson Godoi Fluxo de análise e projeto