Análise e Projeto Orientados a Objeto com UML e Padrões

1. Análise e Projeto Orientados a Objetocom UML e Padrões Parte IV Projeto (1B) Prof. Msc. Emerson Silas Dória

2. Operação:EntrarItem Pós-Condições: 1. Se tSe for uma nova venda, uma Venda foi criada (criação de instância); :Sistema Operador EntrarItem(UPC, quantidade) EntrarItem(UPC,quantidade) TerminarVenda() Operação: TerminarVenda Pós-Condições: 1. Venda.Completada recebe o valor... :POST Sistema EntrarItem(UPC, quantidade) TerminarVenda() RegistrarPagamento(quantia) RegistrarPagamento(quantia) Diagrama de Colaboração ou Seqüência DSS Operações do Sistema Contratos Projetando uma solução com Objetos e Padrões A partir dos Casos de Usos levanta-se os Eventos de Sistema para o DSS Prof. Msc. Emerson Silas Dória

3. EntrarItem 1:???( ) :POST TerminarVenda 1:???( ) :POST RegistrarPagamento 1:???( ) :POST Inicializar 1:???( ) :POST Projetando uma solução com Objetos e Padrões • 1º Passo: Criar os DI: • Crie um DI separado para operação do sistema: • Para cada evento do sistema, crie um DI com o evento como a mensagem inicial. A classe POST servirá de controladora do eventos Prof. Msc. Emerson Silas Dória

4. Projetando uma solução com Objetos e Padrões • 2º Passo: Utilizar os Contratos • Caso os contratos não tenham sido construídos, deve-se voltar aos casos de uso e pensar sobre o que deve ser conseguido. Prof. Msc. Emerson Silas Dória

5. registra-venda-de descrito-por 1 Especificação de Produto Catálogo de Produtos contém 1..* 1 1 0..1 usado-por * descreve * * Item Venda Loja Item estoca 1 * 1 1 1..* 1 log-vendas realizadas contido-em possui 1..* 1 6 * Venda POST Gerente iniciado-por capturada-por 1 1 1 1 1 1 1 1 registra-venda-no paga-por iniciada-por 3 1 1 1 iniciada-por Pagamento Cliente Operador 1 Projetando uma solução com Objetos e Padrões • 3º Passo: Considerar o Modelo Conceitual Prof. Msc. Emerson Silas Dória

6. Iniciando a Construção • Criando uma nova Venda • Pelo Criador, POST cria Venda, e Venda cria uma coleção (vazia) para registrar objetos ItemVenda • Observações: • A exibição da descrição e do preço serão tratados posteriormente; • Considere os contratos e modelo conceitual; Prof. Msc. Emerson Silas Dória

7. Iniciando a Construção • Criando um novo ItemVenda • Pelo Criador, Venda cria objetos ItemVenda • POST passa o parâmetro quantidade para Venda, que o repassa para ItemVenda como parâmetro da mensagem criar_iv • Pelo Criador, POST envia mensagem criar_iv para Venda, que então cria um novo ItemVenda e o adiciona à sua coleção de objetos ItemVenda • Encontrando uma Especificação de Produto • Pelo Especialista, CatalogoDeProdutos faz a busca pela EspecificaçãoDeProduto baseado em uma correspondência de UPCs. Prof. Msc. Emerson Silas Dória

8. Iniciando a Construção • Visibilidade para CatalogoDeProdutos • CatalogoDeProdutos é visível para POST pois ambos instâncias são criadas e associadas durante o caso de uso Inicialização • Assim, é POST quem envia mensagem de busca de especificação para CatalogoDeProdutos • Buscando EspecificaçãoDeProduto no Banco de Dados • Persistência será tratada posteriormente (pressupõe todos em memória) • Mostrando Descrição e Preço • Interação com IU ignorada nesse estágio; objetos de negócio não devem se comunicar com objetos da IU (Padrão MVC(MVS)) Prof. Msc. Emerson Silas Dória

9. 1:[novavenda] criar( ) EntrarItem(UPC,QTD) 3:criar_iv(ESPEC, QTD) :Venda :POST 2:ESPEC:=especificação(UPC) 3.1:criar_iv(ESPEC, QTD ) :CatalogoDe Produtos 1.1:criar( ) iv:ItemVenda 3.2:adicionar(iv) 2.1:ESPEC:=encontrar(UPC) :ItemVenda :Especificação DeProduto DI [Colaboração]EntrarItem Prof. Msc. Emerson Silas Dória

10. TerminarVenda( ) 1:completar( ) v:Venda :POST completar() { completada:=true } DI [Colaboração]TerminarVenda • Definindo atributo Venda.completada Prof. Msc. Emerson Silas Dória

11. tot:obter_total( ) 1:[para cada] iv:next( ) :Venda :ItemVenda 2:st:=obter_subtotal( ) iv:ItemVenda 2.1:pr:=obter_preço( ) obter_total( ) { total:=0 para cada itemvenda, iv tot:=tot+iv.obter_subtotal( ) return( ) } classe Venda obter_subtotal( ) { quantidade*pd.preço } classe ItemVenda pd:Especificação DeProduto DI [Colaboração]TerminarVenda Durante a criação dos DI’s não se preocupe com a exibição de informações, exceto quando a informação requerida não é conhecida no momento. • Calculando o Total da Venda Um DI pode não ser iniciado por um evento de sistema. Prof. Msc. Emerson Silas Dória

12. registrarPagamento(df) 1:registrarPagamento(df) :POST :Venda 1.1:criar(df) Pagamento DI [Colaboração]RegistrarPagamento • Criando Pagamento • Pelo Especialista, POST e Venda podem criar um Pagamento • Considerando também Alta Coesão e Baixo Acoplamento, Vendaé a melhor escolha. Prof. Msc. Emerson Silas Dória

13. criar( ) 2:criar(cp) :Loja :POST 1:criar( ) 1.1:criar( ) 1.2.2*:adicionar(ep) cp:CatalogoDe Produtos :ItemVenda :EspecificaçãoDe Produto 1.2:carregaEspeProd( ) ep:Especificação DeProduto 1.2.1*:criar(UPC,PRECO,DESCRICAO) DI [Colaboração]Inicializar Visibilidade permanente de Loja para POST. Objeto inicial, mas não responsável por assumir o controle da aplicação. É criado pela camada de apresentação. Prof. Msc. Emerson Silas Dória

14. Object Store UPC Quantity Total create() :POSTApplet Tendered Balance presses button Enter Item End Sale Make Payment 1: create() Cashier 2: p := getPOST() : POST onEnterItem() Presentation 3: t := total() : Float store :Store :POSTApplet Layer 1: enterItem(upc, qty) 2: [no sale] sale := getSale() : Sale Domain post : POST sale : Sale Layer Aplicações Multicamadas • Conectando as camadas de apresentação e lógica da aplicação Prof. Msc. Emerson Silas Dória

15. Visibilidade entre Objetos • Capacidade de um objeto “ver” ou ter uma referência para outro objeto. • Necessária para comunicação (envio de mensagens) entre objetos. • Quatro maneiras de B ser visível por A: • Visibilidade de atributo: B é um atributo de A • Visibilidade de parâmetro: B é um parâmetro de um método de A • Visibilidade declarada localmente: B é declarado como um objeto local em um método de A • Visibilidade global : B é de algum modo visível globalmente Prof. Msc. Emerson Silas Dória

16. Class POST { private CatalagoDeProdutos cp; } EntraItem(UPC, QTD) { ESPEC = cp.especificacao(UPC) } classe POST VisibilidadeAtributo • Existe de A para B quando B é um atributo de A • Permanente, persiste enquanto A e B existirem EntrarItem(UPC,QTD) :POST 2:ESPEC:=especificação(UPC) cp:CatalogoDe Produtos Prof. Msc. Emerson Silas Dória

17. 1:[novavenda] criar( ) EntrarItem(UPC,QTD) 3:criar_iv(ESPEC, QTD) :Venda :POST 2:ESPEC:=especificação(UPC) criar_iv(EspecificacaoDeProduto ESPEC, int QTD) { ... } classe Venda 3.1:criar_iv(ESPEC, QTD ) :CatalogoDe Produtos iv:ItemVenda VisibilidadeParâmetro • Existe de A para B quando B é passado como um parâmetro para um método de A • Temporária, persiste apenas dentro do escopo do método Prof. Msc. Emerson Silas Dória

18. 1:[novavenda] criar( ) EntrarItem(UPC,QTD) 3:criar_iv(ESPEC, QTD) :Venda :POST EntrarItem(UPC, QTD) { EspecificacaoDeProduto ESPEC = cp.especializacao (UPC); } classe POST 2:ESPEC:=especificação(UPC) :CatalogoDe Produtos VisibilidadeDeclarada Localmente • Existe de A para B quando B é declarado como um objeto local dentro de um método de A • Temporária, persiste apenas dentro do escopo do método • Duas maneiras comuns de alcançar: 1. Criar uma nova instância local e atribuir a uma variável local 2. Atribuir objeto de retorno de um método para uma variável local Prof. Msc. Emerson Silas Dória

19. VisibilidadeGlobal • Existe de A para B quando B é global para A • Permanente, persiste enquanto A e B existirem • Forma menos comum de visibilidade em sistemas desenvolvidos utilizando OO • Maneira mais comum (mas menos desejável) de atingir é atribuir nova instância a uma variável global • Alternativa recomenda: • Padrão Singleton (GoF) Prof. Msc. Emerson Silas Dória

20. Notação de Visibilidade na UML • Uso opcional de “estereótipos” específicos :B 1:msg( ) :A <<atributo>> 2:msg( ) :C <<parâmetro>> :D 3:msg( ) <<local>> 4:msg( ) :E <<global>> Prof. Msc. Emerson Silas Dória

21. Refin. Plano Impl. Teste 1. Definir Casos de Uso Reais 2. Definir Rel. & IU 3. Refinar Arquitetura b 4. Definir Diag. Interação 5. Definir Diag. Classe 6. Definir Esquema do BD a Notas a. em paralelo com diagrama de interação b. ordem variada Sinc. Artefatos Análise Projeto Definindo Diagramas de Classe Prof. Msc. Emerson Silas Dória

22. Diagramas de Classe • Um diagrama de classe ilustra as especificações de software para as classes e interfaces do sistema • Inclui: • Classes, associações e atributos • Interfaces (com operações e constantes) • Métodos • Informação sobre o tipo dos atributos • Navegabilidade • Dependências • UML não diferencia modelo conceitual de diagrama de classe (o termo “classe de implementação” é usado para distinguir o segundo do primeiro) Prof. Msc. Emerson Silas Dória

23. informações sobre tipos Venda POST data, hora status:boolean captura 1 1 obter_total( ) entrarItem( ) métodos navegabilidade Diagramas de Classe • Diagrama parcial para as classes POST e Venda no sistema POST: Prof. Msc. Emerson Silas Dória

24. Como Fazer umDiagrama de Classe • Regras úteis: • Identificar todas as classes participantes da solução, proposta pelos diagramas de interação; • Desenhar as classes num diagrama de classe; • Incluir os atributos identificados no modelo conceitual; • Adicionar métodos tal como identificados nos diagramas de interação; • Adicionar informação sobre tipos aos atributos e métodos; • Adicionar as associações necessária para permitir a visibilidade de atributos. Prof. Msc. Emerson Silas Dória

25. Como Fazer umDiagrama de Classe • Regras úteis (continuação): • Adicionar setas de navegabilidade para indicar a direção da visibilidade de atributos; • Adicionar relacionamentos de dependência para indicar outros tipos de visibilidade. Prof. Msc. Emerson Silas Dória

26. Modelo de Conceitual X Diagrama de Classe • Modelo Conceitual: abstração de conceitos do mundo real • Diagrama de Classe: especificação de componentes de software Venda POST Modelo Conceitual data, hora status:boolean captura 1 1 Venda POST Diagrama de Classe data, hora status:boolean captura 1 1 obter_total( ) entrarItem( ) Prof. Msc. Emerson Silas Dória

27. CataladoDeProdutos EspecificacaoDeProduto POST quantidade descricao preco UPC Pagamento ItemVenda Venda Loja quantia quantidade data hora status nome endereco POSTCriando Diagramas de Classe • Identificando classes e atributos • Observar os DI e Modelo Conceitual Prof. Msc. Emerson Silas Dória

28. CataladoDeProdutos EspecificacaoDeProduto POST quantidade descricao preco UPC TerminarVenda() EntrarItem() RegistrarPagamento() Especificação() Pagamento ItemVenda Venda Loja quantia quantidade data hora status nome endereco Obter_Subtotal() Completar() Criar_iv() RealizarPagamento() Obter_Total() Criando Diagramas de Classe para o Sistema POST • Adicionando nomes aos métodos • Observe as mensagens dos DI Prof. Msc. Emerson Silas Dória

29. Venda data hora status Completar() Criar_iv(ESPEC: EspecificacaoDeProduto; QTD:integer) RealizarPagamento() Obter_Total() Criando Diagramas de Classe para o Sistema POST • Adicionando informação sobre o tipo dos atributos • Opcional • Grau de detalhe dependente do público-alvo. Prof. Msc. Emerson Silas Dória

30. usa CataladoDeProdutos EspecificacaoDeProduto POST 1 1 contém quantidade descricao preco UPC 1 1..* 1 TerminarVenda() EntrarItem() RegistrarPagamento() 1 descreve Especificação() * 1 busca_em possui 1 Pagamento contém ItemVenda Venda Loja 1 1 1..* quantia quantidade data hora status nome endereco captura 1 1 Obter_Subtotal() Completar() Criar_iv() RealizarPagamento() Obter_Total() pago_por 1 1 Criando Diagramas de Classe para o Sistema POST Navegabilidade implica visibilidade, geralmente visibilidade de atributo. • Adicionando associações e navegabilidade • Investigar os DI As conexões envolvidas nos DI estarão representadas como associações no Diagrama de Classes Prof. Msc. Emerson Silas Dória

31. Class Name attribute attribute : type attribute : type = initial value classAttribute /derivedAttribute ... method1() method2(parameter list) : return type abstractMethod() +publicMethod() -privateMethod() #protectedMethod() classMethod() ... Características dos Elementos de Classe • UML oferece notação rica para descrever características como visibilidade, valores iniciais, etc. • No sistema POST: todos os atributos são privados e todos os métodos são públicos Prof. Msc. Emerson Silas Dória

32. Refin. Plano Impl. Teste 1. Definir Casos de Uso Reais 2. Definir Rel. & IU 3. Refinar Arquitetura b 4. Definir Diag. Interação 5. Definir Diag. Classe 6. Definir Esquema do BD a Notas a. em paralelo com diagrama de interação b. ordem variada Sinc. Artefatos Análise Projeto Arquitetura do Sistema Prof. Msc. Emerson Silas Dória

33. Object Store UPC Quantity Total Tendered Balance Enter Item End Sale Make Payment BD Segurança SGBD Arquitetura Multicamadas GartnerGroup, 95 Apresentação Lógica da Aplicação Venda Pagamento -> objetos de domínio -> objetos de serviço Armazenamento Prof. Msc. Emerson Silas Dória

34. Vantagens da Arquitetura Multicamadas • Implantação em várias configurações • Isolamento da lógica da aplicação em componentes separados, possibilitando reutilização • Distribuição através de diferentes computadores e/ou processos • Alocação de desenvolvedores para construção de camadas específicas Prof. Msc. Emerson Silas Dória

35. Conceitos do Dominio Elementos Centrais Venda Representando Arquiteturas com Pacotes • Um pacote é um conjunto de elementos de modelo de qualquer tipo (casos de uso, classes, diagramas de interação), incluindo outros pacotes; • O sistema inteiro pode ser considerado dentro do escopo de um único pacote, o pacote Sistema • Notação para pacotes na UML: Prof. Msc. Emerson Silas Dória

36. 1 Presentation Domain High-level Relational Database Object Database Communication Reporting Object- Interface Interface oriented Services Layer Examples: 1. Java Applets, Application Frameworks & MFC Documents and Views, 2 Support Libraries VisualAge Visual Parts 2. JDK, MFC, STL Low-level Services Layer (object and non-object oriented) Relational Object Database Database PacotesArquitetura de um Sistema de Informação Prof. Msc. Emerson Silas Dória

37. Identificando Pacotes • Regras úteis: • Agrupar em um pacote elementos que oferecem um serviço comum (ou uma família de serviços relacionados), com acoplamento e colaboração relativamente altos. • Em níveis mais altos de abstração, o pacote deve ser visto como um elemento altamente coeso, com responsabilidades fortemente relacionadas. • Por outro lado, o acoplamento e colaboração entre elementos agrupados em diferentes pacotes devem ser relativamente baixos. Prof. Msc. Emerson Silas Dória

38. Visibilidade entre Pacotes • Visibilidade típica: • Acesso a pacotes de domínio • Outros pacotes (normalmente pacotes de apresentação) têm visibilidade para váriasdas classes que representam conceitos de domínio. • Acesso a pacotes de serviço • Outros pacotes (normalmente pacotes de domínio e apresentação) têm visibilidade para apenas uma ou poucas classes em cada particular pacote de serviço. • Padrão Façade (Fachada) - GoF • Acesso a pacotes de apresentação • Nenhum outro pacote tem visibilidade direta para as classes da camada de apresentação; comunicação, quando há, é de forma indireta. Prof. Msc. Emerson Silas Dória

39. Interface dos Pacotes de ServiçoPatterns: Façade - GoF (Fachada) • Uma Fachada é uma classe que oferece uma interface comum para um grupo de outros componentes ou um conjunto de interfaces originalmente separadas; • Usada para oferecer um interface pública comum para um pacote de serviço; • Classes de outros pacotes comunicam-se apenas com a fachada, a qual colabora com as outras classes internas (privadas) para oferecer o serviço; • Suporta baixo acoplamento Prof. Msc. Emerson Silas Dória

40. Sem Visibilidade para JanelasPatterns: Separação Modelo-Visão • Objetos domodelo(domínio) não deveriam ter conhecimento direto dos objetos devisão (apresentação), ou estar diretamente acoplados a estes. • Classes de domínio encapsulam a informação e o comportamento relacionados à lógica da aplicação • Classes de apresentação responsáveis apenas por operações de entrada/saída Prof. Msc. Emerson Silas Dória

41. Object Store UPC Quantity Total Presentation (View) Layer Tendered Balance (e.g., POSTApplet) Enter Item End Sale Make Payment 1: displayMessage(msg) 1: enterItem(upc, qty) Domain (Model) Layer :POST :POST Better. Worse. Messages from View to Messaging or coupling from Model layer. Supports the Model layer to the View model-view separation. layer is not desirable. Sem Visibilidade para JanelasPatterns: Separação Modelo-Visão Prof. Msc. Emerson Silas Dória

42. Vantagens do Padrão Separação Modelo-Visão • Foco em processos do domínio, em vez de em mecanismo de interação e apresentação; • Desenvolvimento separado das camadas de lógica da aplicação e apresentação; • Redução do impacto de mudanças na camada de apresentação nos objetos de domínio; • Capacidade de incluir novos mecanismos de interação, sem afetar a lógica da aplicação; • Suporte para múltiplas visões do mesmo objeto de domínio; • Execução e teste da lógica da aplicação independentemente da camada de apresentação. Prof. Msc. Emerson Silas Dória

43. Comunicação Indireta • Evita acoplamento entre objetos remetentes (senders) e e seus destinatários (receivers) • Suporte para difusão (broadcast) de mensagens • Mecanismo mais comuns: • Padrão Editor-Assinante(ou Observador) • Callbacks • Notificação de eventos Prof. Msc. Emerson Silas Dória

44. Coordenadores de Aplicação • Um coordenador de aplicação é uma classe responsável pela mediação entre as camadas de apresentação e lógica da aplicação • Responsabilidades básicas: • Mapear informação entre objetos de domínio e IU • Responder a eventos capturados pela IU • Abrir janelas para mostrar informação produzida pelos objetos de domínio • Atualizar janelas quando informação à mostra muda na camada de lógica da aplicação- caso haja múltiplas visões para o mesmo objeto de domínio • Gerenciar transações Prof. Msc. Emerson Silas Dória

45. Domain Relational Database Object Database Interface Interface Relational Object Database Database Armazenamento e Persistência • Requer um subsistema específico para mapear entre objetos de domínio e objetos do BD • Implementado de forma semi-transparente através de frameworks de persistência Prof. Msc. Emerson Silas Dória