Análise e Projeto OO com UML e Padrões

Análise e Projeto OO com UML e Padrões
Augusto Sampaio - acas Pedro Antonino – prga2 (Monitor) Agosto, 2013 Parte do material cedido pela Qualiti Software Processes Análise e Projetos OO com UML

Motivação

Essência de Análise e Projeto: construção de modelos
O que é um modelo? Por que construir modelos? Quantos modelos construir para: capturar os elementos do problema Representar diferentes níveis de abstração Em Engenharia de Software O que é Desenvolvimento Baseado em Modelos?

Um modelo é uma visão parcial (representação) da realidade
Modelos (visões parciais) Realidade Representa Chaque spécialité médicale utilise un certain vocabulaire et un certain langage pour parler du corps humain Sistema respiratório Outros modelos: Muscular, Nervoso, Circulatório, Digestivo, etc. Esqueleto

Multiplas visões: controle da complexidade
Plumber's view Architect's view Landlord's view Renter's view Mason's view Interior Designer's view De la même façon, les différentes corporations utilisent des langages spécifiques pour parler d'un bâtiment mais ces langages sont synchronisés. Carpenter's view Tax Collector's view Electrician's view Model repOf System

Desenvolvimento baseado em modelos
A principal motivação é aumentar a produtividade: Independência de tecnologia Reutilização Automação Aumentar o nível de abstração Foco no modelo, não no código “O modelo é o código ...” Processos são essenciais para sistematizar o desenvolvimento

O grande desafio ...

Vídeo: Modeling Through the Ages

Objetivos do curso Processo de Análise e Projeto no RUP
Aspectos de modelagem de paradigmas recentes: SOA (Software-Oriented Architecture) MDD (Model-Driven Development) Técnicas de modelagem OO em UML Ênfase em Padrões de Projeto e Arquiteturais Consolidação dos conceitos em um exemplo construído incrementalmente Uso de ferramentas de modelagem Geração de esqueleto de código Análise e Projetos OO com UML

Conteúdo do curso Análise/projeto no RUP Considerando SOA e MDD
Disciplina de A&P Análise de caso de uso Projetar arquitetura Projetar casos de uso Considerando SOA e MDD Modelo de negócio Analisar serviços Projetar serviços Padrões de projeto e arquiteturais Projetar subsistemas (componentes) Projetar classes Projetar concorrrência e distribuição Projetar base de dados Aulas conceituais e prática em laboratório Exemplo único para ilustrar conceitos Análise e Projetos OO com UML

Processos de software

Processo de software Para ser uma atividade sistematizada, Análise e Projeto deve ser parte de um processo Processo: O que é? Representação? Ciclo de vida? Execução? Modelos de processo Análise e Projetos OO com UML

Análise e Projeto no modelo Cascata
CIn-UFPE

Análise e Projeto no modelo Espiral

Análise e Projeto no modelo iterativo do RUP
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 CIn-UFPE

Análise e Projeto em SOA (Service Oriented Architecture)
Requisitos Especificação do modelo de negócios Modelagem do Negócio Analisar serviços Planejamento Projetar Serviços Planejamento Inicial Implementação Avaliação Teste

Análise versus Projeto

Foco no problema Comportamento (caixa preta, sem detalhes de implementação) Estrutura geral da arquitetura do sistema Requisitos funcionais Modelo simples Projeto Foco em uma solução Operações e atributos Representação próxima do código Requisitos não-funcionais (exemplo: desempenho), além dos funcionais Modelo complexo Fonte: Rational CIn-UFPE

Em MDD (Model Driven Development) da OMG (Object Management Group) ... Análise corresponde aos modelos independentes de plataforma (PIM – Platform Independent Model) No projeto, os modelos podem estar vinculados a uma tecnologia particular (PSM – Platform Specific Model) CIn-UFPE

Modelo de Análise e Projeto
Pode ser um só artefato evoluindo de uma visão abstrata (nas atividades de análise), para uma visão detalhada (nas atividades de projeto) Podem ser feitos dois artefatos um modelo de análise um modelo de projeto (inicia igual à última versão do modelo de análise e evolui independentemente) Documentação x esforço e disciplina de manutenção A decisão de quais documentos manter de A&P é inerentemente polêmica. A vantagem de manter os documentos de análise é que os aspectos de análise são usualmente abstratos e, a princípio, não sofrem grande modificação durante o processo de desenvolvimento e evolução. A desvantagem é não fornecer uma visão mais detalhada da estrutura real da aplicação. O modelo de projeto oferece uma visão mais detalhada da estrutura (arquitetura) da aplicação, servindo como entrada para o fluxo de implementação. CIn-UFPE

Estratégias de decomposição

Estratégias de Decomposição Funcional x Dados
Decomposição do sistema em componentes funcionais (exemplo: casos de uso) O estado do sistema é centralizado e compartilhado entre as funções Experiência mostrou inadequação para estruturação de modelos de análise e projeto (as regras de negócio mudam constantemente) Entretanto, útil para estruturar requisitos, planejar e gerenciar projetos, e realizar testes CIn-UFPE

Estratégias de Decomposição Funcional x Dados
Decomposição Baseada em Dados O sistema é visto como uma coleção de entidades que interagem (ou objetos, no paradigma OO) O estado do sistema é descentralizado Mostrou-se adequada como mecanismo de estruturação (estabilidade de dados com relação a funções) de modelos de análise projeto e implementação CIn-UFPE

Estratégias de decomposição Projeto Top-down x Bottom-up
CIn-UFPE

Projeto Top-down x Bottom-up
Na prática, o projeto de grandes sistemas nunca é inteiramente top-down Os projetistas reutilizam experiência (e componentes) No processo, ocorre brainstorm nos dois sentidos CIn-UFPE

Atributos de qualidade de modelos de análise e projeto

Atributos de Qualidade
A qualidade é uma propriedade relativa a prioridades específicas da organização Características de qualidade são igualmente aplicáveis a projetos orientados a objeto ou à função Dois atributos importantes são coesão e acoplamento CIn-UFPE

O Atributo Coesão Medida da proximidade das partes (elementos) de um componente do sistema Um componente deve implementar uma única entidade lógica ou função (abstração) Importância Quando uma mudança tiver que ser feita, ela será facilmente localizada Reuso ... Em Orientação a objetos, cada classe deve modelar uma única entidade CIn-UFPE

O Atributo Acoplamento
Medida da intensidade das interconexões entre componentes do sistema Importância Baixo acoplamento implica que mudanças em um componente tendem a não afetar outros componentes Reuso ... CIn-UFPE

Acoplamento Forte CIn-UFPE

Acoplamento Fraco CIn-UFPE

Acoplamento em Orientação a Objetos
Sistemas orientados a objeto são, potencialmente, fracamente acoplados Geralmente não compartilham estado A comunicação é feita através de passagem de mensagens Entretanto... uma classe está acoplada a sua superclasse (mudanças nos atributos ou operações se propagam a todas as subclasses) Relacionamentos cíclicos (em particular, bidirecionais) também geram forte acoplamento CIn-UFPE

Padrões, anti-padrões e frameworks

Padrões de Projeto e Arquiteturais
Projetistas experientes (re)utilizam soluções bem sucedidas no passado Padrões sistematizam soluções, incluindo Nome Problema Solução Conseqüência Exemplo, ... Durante as duas última décadas, surgiu uma “comunidade” voltada a padrões

Exemplo: Padrão Fachada

Anti-Padrões São uma maneira de documentar soluções recorrentes que não tiveram sucesso Podem também incluir soluções re-trabalhadas que sejam efetivas

Frameworks Usualmente baseado em padrões, mas já voltados para uma linguagem de programação Especialização/instanciação Hot spots Herança

Relacionamento com outras disciplinas do processo de software
abr-17 Planejamento e Gerenciamento – planeja e acompanha todo o desenvolvimento Requisitos – entrada para a análise e projeto do sistema Implementação – o modelo de análise e projeto é entrada a implementação Gerência de Configuração e Ambiente – oferece suporte aos artefatos gerados (incluindo modelos) Fluxo de análise e projeto

Módulos do curso 1. Visão geral e conceitos de OO com UML
2. Disciplina de Análise e Projeto 3. Analisar Caso de Uso 4. Projetar Arquitetura 5. Padrões de Projeto e arquiteturais 6. SOA 7. Projetar Caso de Uso 8. Projetar Subsistema 9. Projetar classe 10. Projetar Base de Dados 11. Visão Crítica e Referências Análise e Projetos OO com UML

Orientação a Objetos com UML
Visão Geral de OO com UML

Elementos básicos de OO em UML
Objeto Classe Atributo Operação Interface Componente Pacote Subsistema Relacionamentos Vários tipos de diagrama Os conceitos acima serão vistos durante o restante deste módulo. Visão Geral de OO com UML

Objeto em UML : Conta Apenas o nome da classe contaSaque
Apenas o nome do objeto contaSaque : Conta Os exemplos acima mostram as diferentes formas em que um objeto pode ser modelado em UML. Nome da classe e do objeto Visão Geral de OO com UML

Classe em UML O que deve ser modelado por uma classe?
Conta O que deve ser modelado por uma classe? O que é abstração e modularidade? Conta Nome da Classe numero saldo Atributos estrutura O exemplo acima mostra como modelar uma classe em UML, identificando o seu nome, atributos e operações. A representação dos atributos e operações é opcional. Operações credito() debito() getSaldo() getNumero() comportamento Visão Geral de OO com UML

Visibilidade Marcações de acesso podem ser usadas para especificar o tipo de acesso permitido aos atributos e operações + público # protegido privado Visão Geral de OO com UML

Interface Interfaces definem um tipo especificando apenas a assinatura de seus métodos Interfaces não possuem atributos e seus métodos não têm corpo Classes, subsistemas e componentes implementam interfaces provêem implementação para os métodos especificados em uma interface Uma interface define um tipo especificando apenas a assinatura (parâmetros de entrada e saída) dos métodos pertencentes a este tipo. São definidos então o nome, tipos de argumento e resultado dos métodos de uma classe mas não o código para a implementação destes métodos. Classes implementam interfaces, isto é, classes provêem implementação para os métodos especificados em uma interface. Ao implementar uma interface, uma classe deve prover implementação para todos os métodos definidos na interface, a não ser que esta classe seja abstrata. Quando uma classe implementa uma interface, provendo implementação para todos os métodos da interface, dizemos que esta classe é do tipo da interface. Pense assim: quando uma classe é do tipo de uma interface, esta classe pode ser usada em qualquer lugar que estiver sendo esperado um objeto do tipo desta interface. Dois elementos são polimórficos se eles implementam a mesma interface. Visão Geral de OO com UML

Exemplo: Independência do meio de armazenamento
Isolando 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 RepositorioContasOO Visão Geral de OO com UML

Interface em UML: notação alternativa
RepositorioContasBDR RepositorioContasOO RepositorioContas RepositorioContasXML Uma interface é uma coleção de operações, usadas para especificar um serviço de uma classe ou componente. Relacionamentos de realização Visão Geral de OO com UML

Classes, Interfaces e Classes Abstratas
Assinaturas dos métodos Classes Atributos Métodos Classes Abstratas Classes - possibilita herança de todo o código Classes abstratas - herança de parte do código Interfaces - implementação parte do zero; herança só de comportamento Atributos Métodos Assinatura de Métodos Visão Geral de OO com UML

Componente em UML <<EXE>> <<DLL>> Arquivo
executável <<DLL>> Componente Arquivo fonte Acima alguns exemplos de componentes são ilustrados em UML. Interface do Componente Visão Geral de OO com UML

Pacote Mecanismo para organizar elementos em grupos
Facilita entendimento do sistema Favorece modularidade e reuso em larga escala Essencial para estruturar sistemas complexos nome do pacote nome do pacote Um pacote representa um grupo de classes relacionadas, e possivelmente outros pacotes, de acordo com algum ponto de vista ou critério. O uso de pacotes para encapsular classes relacionadas favorece modularidade e consequentemente reuso em larga escala e manutenção, sendo assim essencial para estruturar sistemas orientados a objetos complexos. Quando o número de classes do seu sistema é muito alto, você deve organizá-las em pacotes para facilitar o seu entendimento Visão Geral de OO com UML

Subsistema em UML Realização Subsistema <<subsystem>>
Nome do subsistema Interface Subsistemas são representados em UML com um elemento de pacote com o estereótipo <<subsystem>>. Visão Geral de OO com UML

Subsistemas e Componentes
Ambos encapsulam um comportamento modelado por interfaces Subsistemas representam componentes no modelo de projeto Componentes são a realização física dos subsistemas Projeto <<subsystem>> Nome do subsistema Implementação Subsistemas e componentes: ambos encapsulam um conjunto de comportamentos modelado por interfaces. Um componente provê a realização física de um conjunto de interfaces. Componentes são elementos de implementação. Um componente é um subsistema implementado. Nome do componente Visão Geral de OO com UML

Relacionamentos Associação Dependência Generalização Realização
simples agregação composição Dependência Generalização Realização Existem vários tipo de relacionamentos, como mostra o slide acima. Veremos a seguir cada um destes tipos de relacionamento. Visão Geral de OO com UML

Associação Relação estrutural entre classes Pessoa Empresa Pessoa
Nome da associação Pessoa trabalha Empresa Associação Associações são relacionamentos estruturais entre classes porque implicam em mudanças na estrutura das classes participantes do relacionamento (com o acréscimo de um atributo) para serem implementadas. Papéis Classe Pessoa Empresa Empregado Empregador Visão Geral de OO com UML

Agregação Tipo especial de associação Relacionamento todo-parte
O todo possui um nível de abstração maior que a parte Todo Parte Empresa Departamento Toda agregação é uma associação. Agregação Visão Geral de OO com UML

Composição Tipo especial de agregação Relação de posse mais forte
O todo é responsável pela criação da parte A parte não vive sem o todo Não permite compartilhamento Todo Parte Toda composição é uma agregação e, consequentemente, uma associação. Empresa Departamento Composição Visão Geral de OO com UML

Dependência Relacionamento não estrutural (uso)
mais fraco que associação Uma dependência entre dois elementos indica que mudança em um elemento pode causar mudanças no outro LeitoraCartao Cartão Criar objetos, recebê-los como parâmetros ou retorná-los como resultado de algum método normalmente implica em uma dependência com a classe do objeto. lerCartao (cartao) Relacionamento de Dependência Visão Geral de OO com UML

Dependência Pode existir relacionamento de dependência entre vários elementos de UML Classe Cliente Fornecedor Componente Cliente Fornecedor Pacote PacoteCliente PacoteFornecedor Dependência Fonte: Rational Visão Geral de OO com UML

Multiplicidade Multiplicidade define quantos objetos participam do relacionamento O número de instâncias de uma classe relacionadas a uma instância de outra classe Especificado em cada uma das pontas da associação Multiplicidade indica, numa associação, quantos objetos de uma classe podem estar associados com uma instância da outra classe participante da associação. Visão Geral de OO com UML

Tipos de Multiplicidade
Não especificada Exatamente um Zero ou mais Muitos (mesmo que 0..*) Um ou mais Zero ou um Intervalo determinado Valores múltiplos 1 0..* * 1..* 0..1 O * pode ser substituído por um ‘n’ em algumas ferramentas CASE para indicar muitos. 2..4 2, 4..6 Visão Geral de OO com UML

Exemplo: Multiplicidade
Pessoa Empresa 1 1..* 1 instância da classe Empresa está associada a 1 ou mais instâncias de Pessoa (1 empresa possui 1 ou mais pessoas ligadas a ela). 1 instância da classe Pessoa está relacionada a apenas 1 instância da classe Empresa (1 pessoa está ligada a apenas 1 empresa). Visão Geral de OO com UML

Navegação Especifica a direção da associação
Associações e agregações são bidirecionais por default, mas é desejável que a navegação seja restringida a apenas uma direção Associações bidirecionais são mais difíceis de implementar e acoplam o modelo A navegabilidade indica que instâncias do relacionamento podem “enxergar” as outras instâncias. Visão Geral de OO com UML

Exemplo: Navegação Pessoa Empresa Navegação 1 1..*
As instâncias de Empresa conhecem as pessoas que fazem parte delas, mas, dada uma determinada pessoa (uma intância da classe Pessoa), ela não pode acessar, diretamente, a empresa da qual faz parte. Navegação Visão Geral de OO com UML

Generalização Relacionamento entre classes onde uma classe compartilha a estrutura (atributos e relacionamentos) e comportamento (operações) de outras classes Define uma hierarquia de abstrações Relacionamento “é um tipo de” (is-a-kind-of) Herança comportamental (behavioural inheritance) Referência clássica: A behavioral notion of subtyping (Liskov & Wing) Diferentes classes geralmente possuem características e comportamento (modelados através de atributos e métodos) em comum. Para evitarmos escrever o mesmo código diversas vezes, foi criado um mecanismo para reaproveitar essas similaridades. Herança é este mecanismo. O relacionamento de generalização ou especialização indica que objetos do tipo filho podem ser usados no lugar de objetos do tipo pai. Generalização é mais conhecido como relacionamento “é um tipo de” (is-a- kind-of). Uma subclasse (classe filha) herda a estrutura e o comportamento da sua superclasse (classe pai). Generalização é o nome do relacionamento e herança, o nome do mecanismo. Existem dois tipo de herança: simples e múltipla, apresentados a seguir. Visão Geral de OO com UML

Generalização Uma subclasse pode Tipos de herança: simples e múltipla
adicionar atributos, operações e relacionamentos redefinir operações herdadas Tipos de herança: simples e múltipla Além de herdar a estrutura e comportamento da sua classe pai, uma classe filha pode adicionar atributos, operações e relacionamentos em sua definição, e até redefinir operações herdadas. Visão Geral de OO com UML

Herança Simples Classes herdando de apenas uma outra classe Figura
cor largura da linha desenhar() girar(graus) selecionar() Superclasse (pai) Relacionamento de Generalização Retângulo vertices desenhar() diagonal() Círculo raio centro desenhar() Subclasses Quadrado Visão Geral de OO com UML

Herança Múltipla Classes herdando de mais de uma classe Herança
Mamífero AnimalVoador Herança múltipla Cachorro Morcego Passarinho Gaviao Gato Visão Geral de OO com UML

Herança Múltipla O que acontece quando as superclasses possuem o mesmo método (métodos com o mesmo nome? O que acontece quando se tenta executar um método que não está definido na subclasse? Em que hierarquia de superclasses deve-se procurar o método? São problemas como esses que desaconselham o uso de herança múltipla, pois essas indefinições tornam o código confuso, ambíguo e passível de erros. Visão Geral de OO com UML

Realização Indica que um elemento serve como contrato que o outro deve seguir Exemplos: Subsistema Componente Classe Realização Caso de uso Realização de Caso de uso Visão Geral de OO com UML

Exercício - Arquitetura
Defina uma arquitetura simplificada de uma aplicação bancária, com: Pelo menos 2 tipos de conta (corrente, poupança) e um cadastro de contas Cliente e um cadastro de clientes Operações para criar, remover, debitar, creditar, transferir, ... Adoção do padrão fachada Visão Geral de OO com UML

Mecanismos adicionais de UML
Estereótipos Notas Propriedades (Tagged values) Restrições OCL (Object Constraint Language) Por fim, veremos alguns dos mecanismos adicionais de UML: estereótipos, notas, rótulos e restrições. Visão Geral de OO com UML

Estereótipos Mecanismo utilizado para estender os elementos de UML
Define um novo modelo de elemento em termos de outro já existente Como criando um novo ícone utilizando a notação <<novo_elemento>> Visão Geral de OO com UML

Estereótipos - Exemplo
Classes de fronteira: <<boundary>> ClasseFronteira ClasseFronteira Veremos este e outros estereótipos padrão de UML no decorrer do curso. Visão Geral de OO com UML

Notas Anotação utilizada para adicionar informação a diagramas
Pode ser afixionada a qualquer elemento de UML Pode ser ligada a um elemento com uma linha tracejada Exemplo: Esta classe é uma abstração do dispositivo de hardware que será usado para ler efetivamente as informações do cartão magnético. LeitorCartao Visão Geral de OO com UML

Propriedades (Tagged Values)
Servem para estender elementos UML, adicionando informações sobre eles Exemplos já definidos em UML: Persistence Location (ex: no cliente, no servidor) Você pode criar suas próprias propriedades Cliente {persistence} LeitorCartao {location=server} Visão Geral de OO com UML

Restrições Usadas para criação de novas regras sobre elementos do modelo Ou modificação de regras existentes Pessoa funcionários Empresa 1..* 1 {subset} diretores 3 1 Visão Geral de OO com UML

OCL (Object Constraint Language)
É uma linguagem usada para definir restrições sobre elementos do modelo ou modificação de restrições existentes Invariantes de classe Pré e pós-condições de operações Empresa OCL pode ser usada para substituir restrições gráficas UML e também para definir restrições sobre as operações de uma classe. Invariantes podem ser definidos para classes com o objetivo de evitar instâncias com valor(es) inválido(s) em algum(ns) atributo(s). Pré- e pós-condições são usadas para definir, respectivamente, as restrições sobre a chamada de uma operação e qual o estado posterior do objeto após a execução da operação. context Empresa inv diretoresNecessarios: self.diretor->size() == 3 Visão Geral de OO com UML

Diagramas UML Diagramas de UML usados no curso (apresentados sob demanda) Casos de uso Classes Sequência Comunicação (Colaboração) Pacotes Componentes (usado em SOA) Visão Geral de OO com UML

Processos e Padrões Orientação a objetos e DBC são paradigmas promissores, mas Reuso Extensibilidade Escalabilidade ... exigem Processos Técnicas Disciplina Experiências anteriores de sucesso (padrões)!

abr-17 Atividades, Artefatos e Responsáveis da Disciplina de Análise e Projeto Fluxo de análise e projeto

Objetivos abr-17 Dar uma visão geral das atividades, responsáveis e artefatos desta disciplina no RUP Inserção de atividades e artefatos de SOA Fluxo de análise e projeto

Objetivos da disciplina de análise e projeto
abr-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

Relacionamento com os demais fluxos
abr-17 Planejamento e Gerenciamento – planeja o que será feito em cada iteração do sistema Requisitos – os casos de uso servem como entrada para o projeto da arquitetura do sistema Implementação – o modelo de análise e projeto é entrada para o fluxo de implementação Gerência de Configuração e Ambiente – oferece suporte aos artefatos gerados no fluxo de A&P Fluxo de análise e projeto

Arquitetura de software O modelo de “4+1 Visões”
abr-17 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 Arquiteto 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, na visão de distribuição e na visão de processos 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. 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. A visão de processos ilustra a organização dos processos do sistema. Esta visão ilustra a decomposição do sistema através de processos, incluindo o mapeamento de classes e subsistemas para processos e threads. Topologia, implantação, comunicação Arquiteto Escalabilidade Fluxo de análise e projeto

O Fluxo de Análise e Projeto
abr-17 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

Visão geral dos artefatos
abr-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 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. Projeto de Banco de Dados Fluxo de análise e projeto

Sobre os artefatos abr-17 A construção do modelo de análise e projeto é o principal objetivo deste fluxo de atividades O projeto de banco de dados geralmente contém o mapeamento do modelo OO para o relacional, ou seja, especifica tabelas, índices, triggers, procedures, etc. O documento da arquitetura é opcional. Ele é usado para descrever em detalhes uma determinada arquitetura Fluxo de análise e projeto

Sobre os artefatos abr-17 O mapeamento das classes de análise em classes de projeto é um artefato temporário do desenvolvimento O modelo de análise e projeto contém as realizações de casos de uso Na prática não há um documento de mapeamento entre classes de análise em classes de projeto. Este documento será usado por motivos didáticos; ao se adquirir mais experiência com o processo, ele se tornará desnecessário. Fluxo de análise e projeto

Artefato Realização de Caso de Uso
abr-17 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. Diagrama de Classes Diagrama de Colaboração Fluxo de análise e projeto

Realização de Caso de Uso
abr-17 Descreve como o caso de uso é realizado, associando o caso de uso com classes e outros elementos de projeto 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 Fluxo de análise e projeto

Artefato Modelo de Análise e Projeto
abr-17 Diagramas de Seqüência Diagramas de Colaboração Modelo de Análise e Projeto Diagrama de Componentes Diagramas de Classes Diagrama de Distribuição O modelo de análise e projeto é formado pela visão lógica, originada a partir da visão de casos de uso (que contém os diagramas de casos de uso). A visão lógica descreve os elementos significativos arquiteturalmente, isto é, as classes, cápsulas, subsistemas e pacotes que são relevantes na definição da arquitetura. Além disso, ela contém a realização de casos de uso, que detalha os elementos envolvidos na implementação de cada caso de uso. Assim, a visão lógica fornece uma descrição de como o sistema todo está organizado e estruturado, enquanto as realizações de casos de uso focam apenas nas classes e subsistemas necessários para se realizar cada caso de uso. A visão de distribuição descreve como o sistema será distribuido (nós físicos, infraestrutura de rede usada na comunicação, etc.). A visão de processos ilustra a organização dos processos do sistema. Esta visão ilustra a decomposição do sistema através de processos, incluindo o mapeamento de classes e subsistemas para processos e threads. O arquivo do modelo de análise e projeto geralmente é o mesmo 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). + Visão de Casos de Uso Visão Lógica Visão de Processos + Visão de Distribuição Fluxo de análise e projeto

Fluxo de atividades da disciplina de Análise e Projeto
abr-17 Fluxo de análise e projeto

Visão geral das atividades
abr-17 Projetar Serviços Analisar Serviços Fluxo de análise e projeto

<<subsystem>>
abr-17 Analisar Serviços Arquiteto de Software Projetar Serviços Projetar Arquitetura Revisor de projeto Prototipar Interface gráfica Arquiteto de Informação Check List  bla bla  bla  blabla Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas decisões do arquiteto <<subsystem>> Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados Fluxo de análise e projeto

Responsáveis e Artefatos
abr-17 Projetista de Banco de Dados Documento da Arquitetura Mapeamento das Classes de Análise em Elementos de Projeto Projeto de Banco de Dados Arquiteto Modelo de Análise e Projeto Realizações de casos de uso e projeto de subsistemas Analista de Sistemas Revisor Fluxo de análise e projeto

Responsáveis e Artefatos (SOA)
abr-17 Arquitetura de Serviços Projetista de Banco de Dados Modelo de Interação de Serviços Arquitetura de Componentes Arquiteto Projeto de Banco de Dados Arquitetura do Sistema Modelo de Projeto Projeto de componentes Analista de Sistemas Revisor Fluxo de análise e projeto

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

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

Projetista de Banco de Dados
abr-17 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 Fluxo de análise e projeto

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

abr-17 Analisar Caso de Uso Analisar caso de uso

Objetivos deste módulo
abr-17 Apresentar os passos necessários para realizar a atividade analisar casos de uso e discutir seus artefatos Apresentar os diagramas de seqüência, colaboração e classes de UML Analisar caso de uso

Fluxo de análise e projeto
abr-17 Analisar Serviços Arquiteto de Software Projetar Serviços Projetar Arquitetura Revisor de projeto Prototipar Interface gráfica Arquiteto de Informação Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas/ componentes Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados Fluxo de análise e projeto

abr-17 Analisar Serviços Arquiteto de Software Projetar Serviços Projetar Arquitetura Revisor de projeto Prototipar Interface gráfica Arquiteto de Informação Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas componentes Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados Fluxo de análise e projeto

Objetivos desta atividade
abr-17 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. Analisar caso de uso

abr-17 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 Analisar caso de uso

Passos para Analisar Casos de Uso
abr-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. Analisar caso de uso

Passo 1. Encontrar classes de análise
abr-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. Analisar caso de uso

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 Analisar caso de uso

QIB - Diagrama de Casos de Uso
abr-17 Usaremos o QIB como exemplo A descoberta de classes de análise será ilustrada com exemplos do Qualiti Internet Banking. Analisar caso de uso

Classes de Fronteira (boundary classes)
abr-17 Isolam o sistema de mudanças no ambiente externo Atores devem se comunicar apenas com classes de fronteira Exemplos de classes fronteira GUI Interface com outros sistemas Interface com dispositivos Notação em UML As classes de fronteira fazem a interface do sistema com qualquer entidade externa a ele, como os seus usuários, outras aplicações ou mesmo dispositivos com os quais o sistema precise interagir. Elas isolam o núcleo do sistema do mundo exterior, evitando que mudanças na interface com o mundo exterior afetem outras classes do sistema. As classes de fronteira são identificadas com o estereótipo <<boundary>>. Modelam a interação entre o sistema e seu ambiente <<boundary>> Analisar caso de uso

QIB – Efetuar Login abr-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. Analisar caso de uso

QIB – Efetuar Pagamento do Qualiti Card
abr-17 Descobrindo classes de fronteira Efetuar Pagamento do Qualiti Card ClienteAtor Operadora de Cartão de Crédito Analisar caso de uso

Descrevendo Classes de Fronteira
abr-17 GUI Concentre-se nas informações que serão apresentadas, não em um projeto gráfico Interface com outros sistemas ou dispositivos Concentre-se em quais protocolos devem ser definidos, não como serão implementados Concentre-se nas responsabilidades, não nos detalhes! Analisar caso de uso

Classes de Entidade (entity classes)
abr-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 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>>. Armazenam e controlam informação no sistema <<entity>> Analisar caso de uso

QIB – Efetuar Login Observe o fluxo de eventos do Efetuar Login
abr-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. Analisar caso de uso

Orientações para encontrar Classes de Entidade
abr-17 Usando a descrição do caso de uso, use a abordagem tradicional de filtrar substantivos identifique substantivos no fluxo de eventos remova candidatos redundantes e vagos remova atores que apenas interagem com o sistema mas não fazem parte da modelagem remova atributos (serão usados mais tarde) e operações Para encontrar classes de entidade observe o glossário e o fluxo de eventos do caso de uso. Os substantivos encontrados são candidatos naturais a classes de entidade. Se tiver sido realizada a modelagem do negócio, o modelo do negócio também é uma boa fonte para encontrar essas classes. Durante a realização deste passo é natural tentar identificar hierarquias de classes, porém, devem ser identificadas apenas hierarquias que sejam explícitas no caso de uso, isto é, que sejam inerentes a natureza da aplicação. A decisão de usar ou não herança deve ser postergada sempre que possível para as atividades de projeto. Analisar caso de uso

QIB – Efetuar Login Classes de entidade
abr-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. Analisar caso de uso

abr-17 Descrição inicial Este caso de uso é responsável por realizar o pagamento do Qualiti Card com a operadora de cartão de crédito. Cada cliente possui apenas um cartão como titular, estando vinculado a apenas uma operadora. Pré-condição: O cliente deve estar conectado ao sistema (ter efetuado o login). Pós-condição: O valor do pagamento é debitado da conta do cliente, o pagamento é enviado à operadora do cartão de crédito e a transação é registrada no sistema. Analisar caso de uso

abr-17 Fluxo de eventos principal 1. O cliente informa os dados necessários para efetuar o pagamento do cartão: - O código de barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar. 2. O sistema recupera a conta bancária do cliente logado. 3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar o pagamento. 4. O sistema debita da conta do cliente. 5. O sistema envia o pagamento à operadora de cartão de crédito. 6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento. Analisar caso de uso

abr-17 Fluxo de eventos secundários Fluxo Principal O cliente informa os dados necessários para efetuar o pagamento do cartão: - O código de barras da fatura que deseja efetuar o pagamento. - O valor que deseja pagar. O sistema recupera a conta bancária do cliente logado 3. O sistema verifica se o saldo da conta do cliente é suficiente para realizar o pagamento. 4. O sistema debita da conta do cliente. 5. O sistema envia o pagamento à operadora de cartão de crédito. 6. O sistema registra a transação de pagamento e emite um comprovante da mesma para o usuário. A transação registrada contém os dados da conta do cliente, o código de barras da fatura, data, hora e valor do pagamento. Fluxo secundário - No passo 3, se o saldo disponível na conta do cliente for menor que o valor do pagamento, o sistema informa que o saldo é insuficiente e retorna para o passo 1. - No passo 5, se a operadora de cartão de crédito estiver inativa, o sistema exibe uma mensagem e cancela a operação. - Em qualquer momento o usuário pode cancelar a operação. Analisar caso de uso

abr-17 Classes de entidade 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. Analisar caso de uso

Classes de Controle (control classes)
abr-17 Coordenam o comportamento (lógica de controle) do caso de uso Interface entre fronteira e entidade Dependente do caso de uso, independente do ambiente Permitem separação entre o uso da entidade (específico do sistema) do comportamento inerente à entidade Notação em UML Coordena o comportamento do caso de uso. Uma classe controle pode ter referência a vários objetos entidade. As classes de controle coordenam a realização do caso de uso, deixando as classes de entidade mais reusáveis, uma vez que elas ficam isoladas de comportamento específico do sistema. Alguns exemplos de classes de controle são classes fachada (que implementam o padrão de projeto Facade). As classes de controle são identificadas com o estereótipo <<control>>. <<control>> Analisar caso de uso

Orientações para encontrar Classes de Controle
abr-17 Usualmente, uma classe de controle por caso de uso Eventualmente mais de uma (comportamento complexo) ou nenhuma (manipulação simples de informações armazenadas) 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. Analisar caso de uso

QIB – Efetuar Login Encontrando classes de controle Efetuar Login
abr-17 Encontrando classes de controle Efetuar Login ClienteAtor Analisar caso de uso

abr-17 Encontrando classes de controle Efetuar Pagamento do Qualiti Card ClienteAtor Operadora de Cartão de Crédito Analisar caso de uso

QIB – Efetuar Login Classes de análise descobertas até o momento
abr-17 Classes de análise descobertas até o momento Analisar caso de uso

abr-17 Classes de análise descobertas até o momento Analisar caso de uso

Exercício – Qualiti Internet Banking
abr-17 Dado: Artefatos de requisitos do Qualiti Internet Banking, especialmente o fluxo de eventos do caso de uso RealizarDoc (ver próximos slides) Produzir: Identificação das classes de análise, com seus estereótipos e breve descrição Analisar caso de uso

QIB – Realizar Doc Descrição inicial
abr-17 Descrição inicial Este caso de uso é responsável por realizar a transferência de valores entre uma conta deste banco para uma conta de um outro banco. A transferência pode ocorrer entre contas com mesmo CPF ou CPFs distintos. Pré-condição: o cliente deve estar conectado ao sistema (ter efetuado o login). Pós-condição: o valor da transferência foi debitado da conta do cliente, o DOC foi enviado à operadora de DOC e a transação foi registrada. Analisar caso de uso

QIB – Realizar Doc Fluxo de eventos principal
abr-17 Fluxo de eventos principal 1. O cliente informa os dados necessários para a realização do DOC: - Banco, agência e conta destino; - CPF do favorecido; - Valor do DOC. 2. O sistema recupera a conta bancária do cliente logado. 3. O sistema verifica se o saldo da conta do cliente é suficiente para a realização do DOC. 4. O sistema envia o DOC à operadora. 5. Debita-se o valor da conta. 6. O QIB registra a ocorrência desta transação (um DOC). 7. Emite-se um comprovante da mesma para o usuário, contendo os dados da conta de origem e destino, assim como a data e valor do DOC. Analisar caso de uso

QIB – Realizar Doc Fluxo de eventos secundários Fluxo secundário
abr-17 Fluxo de eventos secundários Fluxo Principal 1. O cliente informa os dados necessários para a realização do DOC: - Banco, agência e conta destino; - CPF do favorecido; - Valor do DOC. 2. O sistema recupera a conta bancária do cliente logado. 3. O sistema verifica se o saldo da conta do cliente é suficiente para a realização do DOC. 4. O sistema envia o DOC à operadora. 5. Debita-se o valor da conta. 6. O QIB registra a ocorrência desta transação (um DOC). 7. Emite-se um comprovante da mesma para o usuário, contendo os dados da conta de origem e destino, assim como a data e valor do DOC. Fluxo secundário No passo 3, se o saldo disponível na conta do usuário for menor que o valor do DOC, o sistema informa que o saldo é insuficiente e retorna ao passo 1 do fluxo principal de eventos. No passo 4, se a operadora de DOC estiver inativa ou se ocorrer algum erro de comunicação que impeça a efetivação da transação, o sistema emite uma mensagem para o cliente e aborta a transação. Em qualquer momento o usuário pode cancelar a operação. Analisar caso de uso

Passo 2. Identificar persistência
abr-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). Analisar caso de uso

QIB – Efetuar Login abr-17 Classes persistentes Analisar caso de uso

abr-17 Classes persistentes Analisar caso de uso

abr-17 Dado Artefatos de requisitos do caso de uso realizar doc Classes de entidade Produzir Identificação das classes que deverão ser persistentes Analisar caso de uso

Contexto abr-17 Encontradas as classes de análise e identificadas as classes persistentes, vamos agora descrever o seu comportamento. Lembrando que estas atividades são realizadas para cada caso de uso Analisar caso de uso

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). Analisar caso de uso

Distribuindo comportamento entre as classes
abr-17 Diagrama de Seqüência Diagrama de Colaboração Classes de Análise Caso de Uso Classes de Análise (com responsabilidades) Analisar caso de uso

Alocando responsabilidades
abr-17 Use estereótipos de análise como guia Classes de fronteira comportamento que envolve comunicação com um ator Classes de entidade comportamento que envolve informação encapsulada na abstração Classes de controle comportamento específico ao caso de uso (lógica de controle do caso de uso) As responsabilidades de uma classe são os serviços que os objetos da classe devem prover para os outros objetos. Durante a etapa de projeto, cada responsabilidade evolui para um ou mais métodos da classe. Analisar caso de uso

Alocando responsabilidades
abr-17 Identificar que classe tem a informação necessária para realizar a responsabilidade isso pode envolver apenas uma classe, pode ser preciso criar nova classe ou relacionamento entre classes Analisar caso de uso

Modelando interações abr-17 Diagramas de interação (colaboração e seqüência) modelam interações do sistema com seus atores A interação é iniciada por um ator e envolve instâncias (objetos) das classes Diagramas de interação capturam a semântica do fluxo de eventos do caso de uso Auxiliam a identificar classes, responsabilidades e relacionamentos 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. Analisar caso de uso

Forma Geral dos Diagramas de Seqüência
abr-17 Objeto cliente Objeto fornecedor :Cliente :Fornecedor Mensagem reflexiva 1: Realize responsabilidade 1.1: Realize outra responsabilidade Mensagem Numeração hierárquica para as mensagens Foco de controle Analisar caso de uso

abr-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). Analisar caso de uso

Forma Geral de Diagramas de Colaboração
abr-17 Objeto cliente Mensagem reflexiva Link 1.1: Realize outra responsabilidade :Cliente :Fornecedor 1: Realize responsabilidade Mensagem Objeto fornecedor Analisar caso de uso

QIB - Efetuar Login abr-17 Analisar caso de uso

abr-17 QIB – Efetuar Pagamento do Qualiti Card Exercício: diagramas de seqüência e colaboração do caso de uso Efetuar Pagamento do Qualiti Card Analisar caso de uso

Quantos diagramas de interação fazer?
abr-17 Quantos forem necessários para modelar o comportamento do caso de uso! Pelo menos o fluxo principal deveria ser modelado Não é necessário modelar todos os fluxos Os fluxos secundários geralmente não acrescentam muito à modelagem do principal O importante é exemplificar o uso de todas as responsabilidades Normalmente, são feitos diagramas de interação apenas para o fluxo de eventos principal do caso de uso. Porém, se o caso de uso apresentar fluxos secundários complexos, deve-se elaborar diagramas de interação para eles também. Analisar caso de uso

Que diagramas de interação fazer?
abr-17 Diagramas de colaboração x diagramas de seqüência Colaboração Melhores para visualizar os relacionamentos e responsabilidades de um dado objeto Mais fáceis de desenhar - úteis em sessões de brainstorm Seqüência Melhores para visualizar a seqüência do fluxo no tempo Melhores para visualizar o fluxo completo Mais adequados para cenários complexos Normalmente, são feitos diagramas de interação apenas para o fluxo de eventos principal do caso de uso. Porém, se o caso de uso apresentar fluxos secundários complexos, deve-se elaborar diagramas de interação para eles também. Use o que gostar mais!! Analisar caso de uso

Contexto Para cada caso de uso encontramos as classes de análise
abr-17 Para cada caso de uso encontramos as classes de análise identificamos classes persistentes descrevemos o seu comportamento através de diagramas de interação Agora, para cada classe vamos descrever suas responsabilidades Analisar caso de uso

Passo 4. Descrever Responsabilidades
abr-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 Analisar caso de uso

QIB – Efetuar Login Classes com responsabilidades abr-17
Analisar caso de uso

abr-17 QIB – Efetuar Pagamento do Qualiti Card Classes com responsabilidades Analisar caso de uso

Analisando o Modelo abr-17 Classes com responsabilidades similares são candidatas a serem combinadas Uma classe com responsabilidades disjuntas é candidata a ser dividida Classes sem (ou com apenas uma responsabilidade) e classes que interagem com muitas classes são candidatas a serem reexaminadas Isso poderá resultar em uma alteração dos diagramas de interação 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. Analisar caso de uso

abr-17 Dado: Artefatos de requisitos do QIB, especialmente o fluxo de eventos do caso de uso Realizar DOC As classes de análise identificadas no exercício anterior Produzir: Diagrama de interação para o caso de uso VOPC com responsabilidades * VOPC: View of Participating Classes Analisar caso de uso

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. Analisar caso de uso

Encontrando Atributos
abr-17 Possíveis fontes: conhecimento do negócio, requisitos, glossário, modelo do negócio, etc. São propriedades/características das classes identificadas informação cujo valor é o aspecto crucial informação de propriedade exclusiva do objeto informação que pode ser lida ou escrita por operações, mas sem outro comportamento a não ser fornecer um valor Se a informação tem comportamento complexo ou é compartilhada, deve gerar uma classe Analisar caso de uso

Encontrando Relacionamentos
abr-17 Links entre objetos em diagramas de colaboração indicam a necessidade de relacionamento entre as respectivas classes Links reflexivos só geram relacionamentos reflexivos quando dois objetos da classe precisam se comunicar (mas não quando um objeto envia mensagens para si próprio) A navegabilidade do relacionamento deve estar de acordo com a direção da mensagem Inclua também o papel (role) e a multiplicidade dos relacionamentos 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. Analisar caso de uso

Encontrando Relacionamentos
abr-17 1: Realizar responsabilidade Diagrama de Colaboração :Cliente :Fornecedor Link Cliente Fornecedor Cliente Fornecedor Diagrama de classe Analise os diagramas de interação para encontrar os relacionamentos. Se uma classe se comunica com outra, então esta classe provavelmente recebe um objeto desta outra como parâmetro ou possui uma associação. Neste passo, mantenha o foco nas associações necessárias para realizar o caso de uso, não crie associação que você acha que pode ser necessária. Não esqueça de colocar nomes dos papéis (omita se for muito óbvio) e indicar multiplicidade. Realizar responsabilidade Associação Fonte: Rational Um relacionamento para cada link Analisar caso de uso

abr-17 QIB – Efetuar Login Diagrama de classes com relacionamentos e atributos Analisar caso de uso

abr-17 QIB – Efetuar Pagamento do Qualiti Card Diagrama de classes com relacionamentos e atributos Conta numero saldo getSaldo() debitar() <<entity>> Comprovante pagamentoCartao PagamentoCartao numeroFatura data hora valor contaBancaria TelaPagamentoQualitiCard efetuarPagamentoQualitiCard() <<boundary>> CadastroContas consultarConta() atualizar() <<entity collection>> 0..n CadastroPagamentos Cartao inserir() ComunicacaoOperadoraCartao enviar() ControladorPagamentoQualitiCard verificarSaldo() <<control>> 1 Analisar caso de uso

abr-17 Dado: Classes de análise do caso de uso Realizar DOC com estereótipos e responsabilidades Diagramas de interação do caso de uso VOPCs desenvolvidos no exercício anterior Produzir: VOPCs com relacionamentos e atributos. Incluir multiplicidade e navegabilidade dos relacionamentos Analisar caso de uso

Passo 6. Revisar Resultados
abr-17 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. Analisar caso de uso

Revisando: Passos realizados nesta atividade
abr-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 Analisar caso de uso

abr-17 Projetar Arquitetura Projetar caso de uso

Objetivos abr-17 Apresentar os passos necessários para realizar a atividade projetar arquitetura e discutir seus artefatos Apresentar o padrão de arquitetura em camadas Apresentar e exercitar o uso de padrões de projeto Apresentar o Padrão MVC Considerações sobre concorrência e distribuição Projetar caso de uso

abr-17 Analisar Serviços Arquiteto de Software Projetar Serviços Projetar Arquitetura Revisor de projeto Prototipar Interface gráfica Arquiteto de Informação Check List  bla bla  bla  blabla Analisar Casos de Uso Projetar Casos de Uso Projetar Subsistemas Analista de Sistemas Revisar Projeto Projetar classes Projetar Base de Dados Projetista de Banco de Dados Fluxo de análise e projeto

O que foi feito até agora
abr-17 Análise de caso de uso - para cada caso de uso: Identificação das classes de análise (fronteira, entidade e controle) Identificação das classes persistentes Distribuição do comportamento do caso de uso entre as classes Elaboração do diagrama de seqüência Geração do diagrama de colaboração Identificação das responsabilidades das classes Identificação dos atributos e relacionamentos 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. Projetar caso de uso

Objetivos desta atividade
abr-17 Avaliar o conjunto das classes de análise Definir elementos de projeto (classes de projeto, cápsulas e subsistemas) e organizá-los em pacotes Definir a estrutura da aplicação 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. Além disso, o arquiteto deve definir como será a distribuição do sistema. No final da atividade, a arquitetura do sistema estará definida, devendo ser revisada. A revisão da arquitetura antes de se passar ao projeto de casos de uso é importante, pois os projetistas irão usar a arquitetura definida aqui como base para a modelagem detalhada das classes envolvidas na realização de cada caso de uso. No final do projeto da arquitetura tudo deve estar pronto para que os projetistas possam detalhar as realizações dos casos de uso de maneira uniforme! Projetar caso de uso

abr-17 Visão geral dos artefatos Documento de Requisitos Modelo de Casos de Uso Modelo de Análise e Projeto (classes de análise) Arquiteto Projetar Arquitetura 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 Projetar caso de uso

Passos para Projetar Arquitetura
abr-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 Projetar caso de uso

Identificar classes de projeto Identificar subsistemas
Passo 1: Mapear classes de análise em elementos (classes, cápsulas e subsistemas) de projeto abr-17 Identificar classes de projeto Identificar subsistemas Especificar a interface dos subsistemas Fazer o mapeamento 1 classe de análise pode dar origem a 0 ou mais elementos 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 Projetar caso de uso

Identificando classes de projeto
abr-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. Projetar caso de uso

QIB – Identificando classes de projeto
abr-17 Classe Conta Tem duas responsabilidades distintas: controle de acesso e conta bancária Na realidade, modelam duas entidades diferentes A separação favorece o reuso Por exemplo, ContaCorrente é utilizado para clientes que não têm acesso à internet. A classe Conta tinha duas responsabilidades distintas e foi mapeada em ContaInternet e ContaCorrente. ContaInternet é uma conta de acesso à internet que contém o login e a senha do usuário (não é conta bancária). ContaCorrente é uma conta bancária que possui número e saldo. Esta decisão contribui para o posterior reuso de ambas as classes em outro contexto do QIB (por exemplo, contas bancárias sem acesso à internet). 1 1 Projetar caso de uso

Identificando subsistemas
abr-17 Antes, vamos revisar alguns conceitos... Qual a diferença entre subsistemas e pacotes? Como se descreve o comportamento de um subsistema? Qual a grande vantagem associada aos subsistemas? Projetar caso de uso

Subsistemas e interfaces: notação
abr-17 <<subsystem>> Nome subsistema <<interface>> Nome da interface Atributos Métodos Realização <<subsystem>> Nome subsistema Para denotar a dependência de um subsistema sobre sua interface pode-se usar tanto a notação canônica (primeira forma mostrada acima), quanto a notação com o ícone (estereótipo criado para interfaces). Nome da interface Atributos Métodos Projetar caso de uso

Por que usar subsistemas?
abr-17 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 Projetar caso de uso

abr-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. Projetar caso de uso

abr-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. Projetar caso de uso

A classe fachada abr-17 Além da interface, é destacada uma classe fachada de cada subsistema Interface <<subsystem>> nomeSubsistema FachadaSubsistema 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. ISubSistema Projetar caso de uso

abr-17 QIB – Efetuar Pagamento do Qualiti Card Identificando subsistemas Análise <<boundary>> ComunicacaoOperadoraCartao enviar() Projeto Classes de fronteira com outros sistemas normalmente evoluem para subsistemas, com suas respectivas fachadas. <<subsystem>> SubsistemaComunicacaoOperadoraCartao ISubsistemaComunicacaoOperadoraCartao enviar() Projetar caso de uso

abr-17 Contexto do subsistema ControladorPagamentoQualitiCard PagamentoCartao ISubsistemaComunicacao OperadoraCartao O diagrama de classes com o contexto do subsistema mostra as dependências do subsistema, assim como as classes que dependem de sua interface. enviar() FachadaComunicacaoOperadoraCartao Projetar caso de uso

Passo 2. Identificar oportunidades de reuso
abr-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. Projetar caso de uso

Identificando oportunidades de reuso
abr-17 A partir das interfaces de subsistemas ou componentes existentes analisar onde estes podem ser reutilizados Para um candidato a subsistema Procure interfaces similares (podendo requerer engenharia reversa de subsistemas existentes) Tente adaptar a interface nova às existentes, ou tornar as existentes mais gerais Substitua a interface nova por existentes Projetar caso de uso

Passo 3. Definir a estrutura da aplicação
abr-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. Projetar caso de uso

Definir as camadas da aplicação
abr-17 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 Projetar caso de uso

Estruturação em camadas
abr-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 Projetar caso de uso

Benefícios Modularidade:
abr-17 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 Projetar caso de uso

Benefícios abr-17 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 Projetar caso de uso

Camada de negócios Responsável por implementar a lógica do negócio
abr-17 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. Projetar caso de uso

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

Coleções de negócio abr-17 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 uma conta é responsabilidade da classe CadastroContas. Projetar caso de uso

Fachada do sistema Segue o padrão de projeto Facade
abr-17 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 Fachada Fachada efetuarPagamentoQualitiCard() ControladorPagamentoQualitiCard 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. CadastroContas CadastroPagamentosCartao CadastroContas CadastroPagamentosCartao Projetar caso de uso

Camada de dados abr-17 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. Projetar caso de uso

Coleções de dados abr-17 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 Projetar caso de uso

Coleções de dados Dependem do meio de armazenamento!
abr-17 Dependem do meio de armazenamento! RepositorioContasBDOO RepositorioContasBDR RepositorioContasArquivo Projetar caso de uso

Independência do meio de armazenamento
abr-17 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 Projetar caso de uso

Interface negócio-dados
abr-17 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. Projetar caso de uso

Juntando tudo - Visão geral da arquitetura
abr-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 Projetar caso de uso

QIB – Efetuar Login e Efetuar Pagamento do Qualiti Card
abr-17 Mapeamento entre análise e projeto Classes de Análise Elementos de Projeto Fachada TelaMenu Data Hora Conta ContaInternet ContaCorrente CadastroContasInternet IRepositorioContasInternet RepositorioContasInternetBDR CadastroContasCorrente IRepositorioContasCorrente RepositorioContasCorrenteBDR CadastroContas Após identificar os elementos de projeto (classes de projeto e subsistemas), o arquiteto faz uma tabela como a que está ilustrada acima, mostrando o mapeamento das classes de análise nos elementos de projeto correspondentes. O elemento SubsistemaComunicacaoOperadoraCartao é uma entidade conceitual, ao contrário dos demais elementos de projeto que são implementados em termos de classes ou interfaces. A classe Conta tinha duas responsabilidades distintas e foi mapeada em ContaInternet e ContaCorrente. ContaInternet é uma conta de acesso à internet que contém o login e a senha do usuário (não é conta bancária). ContaCorrente é uma conta bancária que possui número e saldo. Esta decisão contribui para o posterior reuso de ambas as classes em outro contexto (por exemplo, contas bancárias sem acesso à internet) ou outro sistema (por exemplo, sistemas que sejam acessados pela internet e precisem de uma classe de acesso como ContaInternet). CadastroPagamentosCartao CadastroTransacoes IRepositorioTransacoes RepositorioTransacoesBDR SubsistemaComunicacaoOperadoraCartao ISubsistemaComunicacaoOperadoraCartao FachadaComunicacaoOperadoraCartao ComunicacaoOperadoraCartao Projetar caso de uso

abr-17 Projeto da arquitetura TelaLogin TelaMenu TelaPagamentoQualitiCard FachadaComunicacaoOperadoraCartao 0..n 0..n 0..n 0..n 0..n 0..n 1 1 1 1 1 Fachada 1 1 ISubsistemaComunicacao 1 1 1 1 OperadoraCartao 1 1 1 1 1 1 ControladorLogin ControladorPagamentoQualitiCard Comprovante 1 1 1 1 1 1 1 1 Hora 1 1 1 1 1 1 1 1 PagamentoCartao CadastroContasInternet CadastroContasCorrente CadastroPagamentosCartao numeroFatura Este diagrama omite a maioria dos atributos, métodos e relacionamentos de dependência por legibilidade. Os cadastros não mantém um conjunto de objetos, mas apenas acessam os repositórios. Por isto, o relacionamento de agregação é substituído por dependência. Por causa do mapeamento de Conta em ContaInternet e ContaCorrente, o ControladorPagamentoQualitiCard tem relacionamentos com o CadastroContasInternet (porque precisa recuperar a conta bancária) e o CadastroContasCorrente (porque precisa atualizar a conta bancária na base). A classe ContaInternet também relaciona-se com ContaCorrente. contaBancaria valor 1 1 1 1 1 1 Data 1 1 1 1 1 1 ContaInternet IRepositorio IRepositorio ContasCorrente IRepositorio 1 1 PagamentosCartao ContaCorrente ContasInternet 1 1 RepositorioContas RepositorioContas RepositorioPagame InternetBDR CorrenteBDR ntosCartaoBDR Projetar caso de uso

abr-17 Dado: As classes de análise do caso de uso Realizar Doc A tabela de mapeamento e o projeto de arquitetura de Efetuar Login e Efetuar Pagamento do Qualiti Card Identificar para o Realizar Doc: subsistemas e suas interfaces elementos de projeto (classes e subsistemas) Produzir: Tabela mapeando as classes de análise nos elementos de projeto Diagrama de contexto dos subsistemas (opcional) Projeto da arquitetura com incluindo Realizar DOC Projetar caso de uso

Agrupar as classes em pacotes
abr-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. Projetar caso de uso

Critérios para definição dos pacotes
abr-17 Acoplamento e Coesão Agrupa as classes em bibliotecas Exemplo: cliente, conta, banco, util, etc. Distribuição – usuário Agrupa as classes por locais de implantação Exemplo: clienteRecife, clienteSaoPaulo, etc. Segurança Agrupa as classes por permissão de acesso Exemplo: gerência, programadores, etc. Evite dependências cíclicas Projetar caso de uso

Pacote Global Pode ser usado por todos os outros pacotes
abr-17 Pode ser usado por todos os outros pacotes classes utilitárias Não é necessário explicitar as dependências O pacote util agrupa classes auxiliares, que normalmente são usadas em vários projetos diferentes, como por exemplo classes para gerenciar conexões com um SGBD ou para implementar transações com o meio de armazenamento usado. Ele também pode conter sub-pacotes, se for adequado separar as classes utilitárias em grupos distintos. Projetar caso de uso

abr-17 Organização de pacotes 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. Projetar caso de uso

QIB – Pacote conta IRepositorioContas Corrente
abr-17 QIB – Pacote conta IRepositorioContas Corrente <<Interface>> CadastroContasCorrente <<entity collection>> 1 RepositorioContasCorrenteBDR ContaCorrente numero saldo getSaldo() debitar() <<entity>> ContaInternet login senha IRepositorioContasInternet CadastroContasInternet RepositorioContasInternetBDR As camadas guiam o modo como as classes de negócio e dados serão implementadas, porém, as classes destas duas camadas ficam em um mesmo pacote, uma vez que estão extremamente acopladas. Projetar caso de uso

QIB – Pacotes Dependência entre pacotes <<global>> util
abr-17 QIB – Pacotes Dependência entre pacotes <<global>> util controladores GUI conta <<subsystem>> subsistemaComunicacao OperadoraCartao transacao ISubsistemaComunicacao OperadoraCartao protocolos O pacote util possui classes que podem ser utilizadas por todos os outros pacotes, como Data e Hora. Isto justifica seu estereótipo <<global>> e também a omissão de relacionamentos de dependência para não sobrecarregar o diagrama. A interface do subsistema utiliza a classe PagamentoCartao do pacote transacao. Projetar caso de uso

abr-17 Dado: Os elementos de projeto A estrutura definida para a aplicação Definir os pacotes da aplicação e os elementos que devem estar presentes em cada pacote (incluir os elementos do caso de uso Realizar DOC) Elaborar um diagrama mostrando as dependências entre pacotes (opcional Projetar caso de uso

Análise e Projeto OO com UML e Padrões

Apresentações semelhantes

Apresentação em tema: "Análise e Projeto OO com UML e Padrões"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback

Login

Autorizar-se através da rede social:

Análise e Projeto OO com UML e Padrões

Apresentações semelhantes

Apresentação em tema: "Análise e Projeto OO com UML e Padrões"— Transcrição da apresentação:

Apresentações semelhantes

Sobre projeto

Feedback