Abr-17 Projetar Arquitetura Projetar caso de uso.

Apresentação em tema: "Abr-17 Projetar Arquitetura Projetar caso de uso."— Transcrição da apresentação:

1 abr-17 Projetar Arquitetura Projetar caso de uso

2 abr-17 Objetivos 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

3 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 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

4 O que foi feito até agora
abr-17 O que foi feito até agora 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

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

6 Visão geral dos artefatos
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

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

8 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

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

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

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

12 Subsistemas e interfaces: notação
abr-17 Subsistemas e interfaces: notação <<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

13 Por que usar subsistemas?
abr-17 Por que usar subsistemas? 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

14 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 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

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

16 <<subsystem>>
abr-17 A classe fachada Além da interface, é destacada uma classe fachada de cada subsistema Interface <<subsystem>> nomeSubsistema FachadaSubsistema ISubSistema Todo subsistema deve apresentar uma classe fachada, com visibilidade pública, que implementa a interface do subsistema. É através da fachada que os clientes do subsistema acessam os seus serviços. Projetar caso de uso

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

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

19 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

20 Identificando oportunidades de reuso
abr-17 Identificando oportunidades de reuso 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

21 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

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

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

24 Benefícios Modularidade:
abr-17 Benefícios 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

25 abr-17 Benefícios 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

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

27 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 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

28 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 uma conta é responsabilidade da classe CadastroContas. Projetar caso de uso

29 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 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

30 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 (repositórios) 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

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

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

33 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

34 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

35 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

36 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 CadastroPagamentosCartao CadastroTransacoes IRepositorioTransacoes RepositorioTransacoesBDR 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). SubsistemaComunicacaoOperadoraCartao ISubsistemaComunicacaoOperadoraCartao FachadaComunicacaoOperadoraCartao ComunicacaoOperadoraCartao Projetar caso de uso

37 QIB – Efetuar Login e Efetuar Pagamento do Qualiti Card
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 contaBancaria valor 1 1 1 1 1 1 Data 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. 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

38 Exercício – Qualiti Internet Banking
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 incluindo Realizar DOC Projetar caso de uso

39 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

40 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

41 Pacote Global Pode ser usado por todos os outros pacotes
abr-17 Pacote Global 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

42 QIB – Efetuar Login e Efetuar Pagamento do Qualiti Card
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

43 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

44 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

45 Exercício – Qualiti Internet Banking
abr-17 Exercício – Qualiti Internet Banking 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