© Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV Projeto (1B)

Apresentação em tema: "© Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV Projeto (1B)"— Transcrição da apresentação:

1 © Nabor C. Mendonça 2001 1 Análise e Projeto Orientados a Objeto com UML e Padrões Parte IV Projeto (1B)

2 © Nabor C. Mendonça 2001 2 Diagramas de Interação para o Sistema POST n Eventos de interesse : – Caso de uso Comprar Itens: entrarItem, encerrarVenda, fazerPagamento – Caso de uso Inicializar: inicializar :POST enterItem() :POST endSale() :POST makePayment() 1: ???() :POST startUp()1: ???()

3 © Nabor C. Mendonça 2001 3 n Criando uma nova Venda – Pelo Criador, POST cria Venda, e Venda cria uma coleção (vazia) para registrar objetos Item-de-Venda Diagrama de Interação entrarItem 1: [new sale] create() enterItem(upc, qty) :POST:Sale :SalesLineItem 1.1: create() by Controllerby Creator An empty collection that will eventually hold SalesLineItem instances.

4 © Nabor C. Mendonça 2001 4 n Criando um novo Item-de-Venda – Pelo Criador, Venda cria objetos Item-de-Venda – POST passa parâmetro quantidade para Venda, que o repassa para Item-de-Venda como parâmetro da mensagem create – Pelo criador, POST envia mensagem fazerItem-de- Venda para Venda, que então cria um novo Item-de- Venda e o adiciona à sua coleção de objetos Item- de-Venda n Encontrando uma Especificação-Produto – Pelo Especialista, Catálogo-Produto faz a busca pela Especificação-Produto baseado em casamento de UPCs Diagrama de Interação entrarItem

5 © Nabor C. Mendonça 2001 5 n Visibilidade para Catálogo-Produto – Catálogo-Produto é visível para POST pois ambas 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 Catálogo-Produto n Buscando Especificação-Produto no BD – Persistência ignorada nesse estágio (pressupõe todos em memória) n 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 Separação Modelo-Visão) Diagrama de Interação entrarItem

6 © Nabor C. Mendonça 2001 6 n Diagrama de colaboração parcial Diagrama de Interação entrarItem

7 © Nabor C. Mendonça 2001 7 n Definindo atributo Venda.completada Diagrama de Interação encerrarVenda

8 © Nabor C. Mendonça 2001 8 n Calculando total da venda Diagrama de Interação encerrarVenda

9 © Nabor C. Mendonça 2001 9 n Criando Pagamento – Pelo Especialista, POST e Venda podem criar um Pagamento – Considerando também Alta Coesão e Baixo Acoplamento, Venda é a melhor escolha Diagrama de Interação fazerPagamento

10 © Nabor C. Mendonça 2001 10 n Registrando a Venda – Pelo Especialista, Loja adiciona a Venda à coleção (log) de vendas completadas Diagrama de Interação fazerPagamento

11 © Nabor C. Mendonça 2001 11 n Calculando troco – Pelo Especialista, Venda e Pagamento podem calcular troco – Considerando Baixo Acoplamento, Venda é a melhor escolha Diagrama de Interação fazerPagamento :Salepmt: Payment 1: amt := amount()bal := balance() Sale--balance() { return pmt.amount() - total() } 2: t := total()

12 © Nabor C. Mendonça 2001 12 Diagrama de Interação inicializar n Criar por último, após todas as outras operações terem sido consideradas n Instancia objeto de domínio inicial, enviando-lhe uma mensagem create n Objeto inicial pode ou não tomar conta da execução – Em aplicações interativas, controle da execução normalmente fica com a camada de Apresentação – Se objeto inicial toma conta da execução, uma mensagem run (ou equivalente) pode ser enviada num segundo diagrama de colaboração

13 © Nabor C. Mendonça 2001 13 Diagrama de Interação inicializar n Candidatos para objeto de domínio inicial: – Uma classe representando o sistema como um todo Ex.: POST – Uma classe representado o negócio ou organização como um todo Ex.: Loja (melhor uma Loja pode conter vários POSTs) n Instâncias de objetos persistentes – Se poucas, criar de uma vez, durante inicialização – Se muitas, criar sob demanda, conforme são requisitadas

14 © Nabor C. Mendonça 2001 14 Diagrama de Interação inicializar n Diagrama de colaboração parcial

15 © Nabor C. Mendonça 2001 15 Conectando as Camadas de Apresentação e Lógica da Aplicação store :Store 1: create() 2: p := getPOST() : POST :POSTApplet create()

16 © Nabor C. Mendonça 2001 16 Visibilidade entre Objetos n Capacidade de um objeto ver ou ter uma referência para outro objeto – Necessária para comunicação (envio de mensagens) entre objetos n Quatro maneiras de B ser visível para 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 objeto local de um método de A – Visibilidade global B é de algum modo visível globalmente

17 © Nabor C. Mendonça 2001 17 Visibilidade de Atributo n Existe de A para B quando B é um atributo de A – Permanente persiste enquanto A e B existirem

18 © Nabor C. Mendonça 2001 18 Visibilidade de Parâmetro n 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 de A (permanente se B é atribuído a um atributo de A) 1: [new sale] create() 3: makeLineItem(spec, qty) enterItem(upc, qty) 2: spec := specification(upc) 3.1: create(spec, qty) :POST:Sale :Product Catalog sl : SalesLineItem Sale--makeLineItem(ProductSpecification spec, int qty) {... sl = new SalesLineItem(spec, qty);... } SalesLineItem--SalesLineItem(ProductSpecification spec, int qty) {... productSpec = spec; // parameter to attribute visibility... }

19 © Nabor C. Mendonça 2001 19 Visibilidade Declarada Localmente n 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 de A (permanente se B é atribuído a um atributo de A) – Duas maneiras comuns de alcançar: 1. Criar nova instância e atribuir para variável local 2. Atribuir objeto de retorno de um método para variável local 1: [new sale] create() 3: makeLineItem(spec, qty) enterItem(upc, qty) 2: spec := specification(upc) :POST:Sale :Product Catalog POST--enterItem(upc, qty) {... // local visibility via assignment of returning object ProductSpecification spec = prodCatalog.specification(upc);... }

20 © Nabor C. Mendonça 2001 20 Visibilidade Global n Existe de A para B quando B é global para A – Permanente persiste enquanto A e B existirem n Forma menos comum de visibilidade em sistemas desenvolvidos utilizando OO – Maneira mais comum (mas não recomendada) de atingir é atribuir nova instância a uma variável global n Alternativa recomenda: – Padrão Singleton (GoF)

21 © Nabor C. Mendonça 2001 21 Notação de Visibilidade na UML n Uso opcional de estereótipos específicos :A:B 1: msg() :C 2: msg() :D 3: msg() «association» «parameter» «local» :E 4: msg() «global» «association» is used for attribute visibility

22 © Nabor C. Mendonça 2001 22 Definindo Diagramas de Classe 2. Definir Rel. & IU 4. Definir Diag. Interação 5. Definir Diag. Classe a 6. Definir Esquema do BD 1. Definir Casos de Uso Reais 3. Refinar Arquitetura b Notas a. em paralelo com diag. interação b. ordem variada Sinc. Artefatos AnáliseProjetoTeste Refin. Plano Impl. Um Ciclo de Desenvolvimento

23 © Nabor C. Mendonça 2001 23 Diagramas de Classe n Um diagrama de classe ilustra as especificações de software para as classes e interfaces do sistema n Inclui: – Classes, associações e atributos – Interfaces (com operações e constantes) – Métodos – Informação sobre o tipo dos atributos – Navegabilidade – Dependências n UML não diferencia modelo conceitual de diagrama de classe (o termo classe de implementação é usado para distinguir o segundo do primeiro)

24 © Nabor C. Mendonça 2001 24 Diagramas de Classe n Diagrama parcial para as classes POST e Venda no sistema POST:

25 © Nabor C. Mendonça 2001 25 Como Fazer um Diagrama de Classe n Regras úteis: 1. Identificar todas as classes participando na solução proposta pelos diagramas de interação. 2. Desenhe as classes num diagrama de classe. 3. Inclua os atributos identificados no modelo conceitual. 4. Adicione métodos tal como identificados nos diagramas de interação. 5. Adicione informação sobre o tipo dos atributos e métodos. 6. Adicione as associações necessária para permitir a visibilidade de atributos requisitada.

26 © Nabor C. Mendonça 2001 26 Como Fazer um Diagrama de Classe n Regras úteis (cont.): 7. Adicione setas de navegabilidade para indicar a direção da visibilidade de atributos. 8. Adicione relacionamentos de dependência para indicar outros tipos de visibilidade.

27 © Nabor C. Mendonça 2001 27 Modelo de Conceitual X Diagrama de Classe n Modelo conceitual: abstração de conceitos do mundo real n Diagrama de classe: especificação de componentes de software

28 © Nabor C. Mendonça 2001 28 Criando Diagramas de Classe para o Sistema POST n Identificando classes e atributos POST Sale date isComplete time SalesLineItem quantity ProductCatalog quantity ProductSpecification description price UPC Store address name Payment amount

29 © Nabor C. Mendonça 2001 29 Criando Diagramas de Classe para o Sistema POST n Adicionando nomes de métodos SalesLineItem quantity subtotal() ProductCatalog specification() ProductSpecification description price upc Store address name addSale() Payment amount POST endSale() enterItem() makePayment() Sale date isComplete time becomeComplete() makeLineItem() makePayment() total()

30 © Nabor C. Mendonça 2001 30 Criando Diagramas de Classe para o Sistema POST n Métodos create – Métodos de instanciação (construtores) específicos para cada linguagem de programação – Normalmente omitidos no diagrama de classe n Métodos de acesso – get e set de atributos – Omitidos no diagrama para reduzir ruído (2N métodos desinteressantes para cada N atributos) n Métodos de coleção (multiobjects) – Parte da definição da coleção (classes de biblioteca do tipo container: Vetor, Hashtable, etc.) – Omitidos no diagrama para reduzir ruído

31 © Nabor C. Mendonça 2001 31 Criando Diagramas de Classe para o Sistema POST n Adicionando informação sobre o tipo dos atributos – Opcional – Grau de detalhe dependente da audiência

32 © Nabor C. Mendonça 2001 32 Criando Diagramas de Classe para o Sistema POST n Adicionando associações, navegabilidade e dependências

33 © Nabor C. Mendonça 2001 33 n UML oferece notação rica para descrever características como visibilidade, valores iniciais, etc. n No sistema POST: todos os atributos são privados e todos os métodos são públicos Especificação Detalhada de Membros Class Name attribute attribute : type attribute : type = initial value classAttribute /derivedAttribute... method1() method2(parameter list) : return type abstractMethod() +publicMethod() -privateMethod() #protectedMethod() classMethod()...

34 © Nabor C. Mendonça 2001 34 Projetando a Arquitetura do Sistema 2. Definir Rel. & IU 4. Definir Diag. Interação 5. Definir Diag. Classe a 6. Definir Esquema do BD 1. Definir Casos de Uso Reais 3. Refinar Arquitetura b Notas a. em paralelo com diag. interação b. ordem variada Sinc. Artefatos AnáliseProjetoTeste Refin. Plano Impl. Um Ciclo de Desenvolvimento

35 © Nabor C. Mendonça 2001 35 Arquitetura Clássica em Três Camadas Record sales Presentation Application Logic Authorize payments Storage Database Object Store Enter ItemEnd Sale UPC Make Payment Total Quantity TenderedBalance

36 © Nabor C. Mendonça 2001 36 Arquitetura Multi-camadas n Decomposição da camada de Lógica da Aplicação: – Objetos de domínio (conceitos) – Objetos de serviço (persistência, comunicação, segurança, etc.) Payment Presentation Application Logic Sale Storage Database POSTApplet Database Interface ReportGenerator domain concepts services

37 © Nabor C. Mendonça 2001 37 Vantagens da Arquitetura Multi-camadas n Implantação em várias configurações n Isolamento da lógica da aplicação em componentes separados n Distribuição através de diferentes computadores e/ou processos n Alocação de desenvolvedores para camadas específicas

38 © Nabor C. Mendonça 2001 38 Representando Arquiteturas com Pacotes n Um pacote é um conjunto de elementos de modelo de qualquer tipo (casos de uso, classes, diagramas de interação), incluindo outros pacotes n O sistema inteiro pode ser considerado dentro do escopo de um único pacote o pacote Sistema n Notação para pacotes na UML: Domain Concepts Core Elements Sales

39 © Nabor C. Mendonça 2001 39 Pacotes na Arquitetura de um Sistema de Informação

40 © Nabor C. Mendonça 2001 40 Identificando Pacotes n 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.

41 © Nabor C. Mendonça 2001 41 Camadas e Partições n Uma arquitetura multi-camadas pode ser composta por divisões verticais (camadas) e horizontais (partições) – Partições decompõem uma camada em subsistemas relativamente independentes Relational Database Interface CommunicationReporting Object Database Interface Services Core ElementsSalesProducts Domain Vertical Layers Horizontal Partitions

42 © Nabor C. Mendonça 2001 42 Visibilidade entre Pacotes n Visibilidade típica: – Acesso a pacotes de domínio Outros pacotes (normalmente pacotes de apresentação) têm visibilidade para várias das 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 das classes representando um serviço particular. – 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.

43 © Nabor C. Mendonça 2001 43 Interface para Pacotes de Serviço O Padrão Fachada n Uma Fachada é uma classe que oferece uma interface comum para um grupo de outros componentes ou um conjunto de interfaces originalmente separadas n Usada para oferecer um interface pública comum para um pacote de serviço n Classes de outros pacotes comunicam-se apenas com a fachada, a qual colabora com as outras classes internas (privadas) para oferecer o serviço n Suporta baixo acoplamento

44 © Nabor C. Mendonça 2001 44 Sem Visibilidade para Janelas O Padrão Separação Modelo-Visão n Objetos do modelo (domínio) não devem ter conhecimento sobre ou estar diretamente acoplados a objetos da visão (apresentação) n Classes de domínio encapsulam qualquer informação e comportamento relacionados à lógica da aplicação n Classes de apresentação responsáveis apenas por operações de entrada/saída

45 © Nabor C. Mendonça 2001 45 Sem Visibilidade para Janelas O Padrão Separação Modelo-Visão :POST Presentation (View) Layer (e.g., POSTApplet) Domain (Model) Layer Worse. Messaging or coupling from the Model layer to the View layer is not desirable. Better. Messages from View to Model layer. Supports model-view separation. :POST 1: enterItem(upc, qty) 1: displayMessage(msg) Object Store Enter ItemEnd Sale UPC Make Payment Total Quantity TenderedBalance

46 © Nabor C. Mendonça 2001 46 Vantagens do Padrão Separação Modelo- Visão n Foco em processos do domínio, em vez de em mecanismo de interação e apresentação n Desenvolvimento separado das camadas de lógica da aplicação e apresentação n Redução do impacto de mudanças na camada de apresentação nos objetos de domínio n Capacidade de incluir novos mecanismos de interação, sem afetar a lógica da aplicação n Suporte para múltiplas visões do mesmo objeto de domínio n Execução e teste da lógica da aplicação independentemente da camada de apresentação

47 © Nabor C. Mendonça 2001 47 Comunicação Indireta n Evita acoplamento entre objetos remetentes (senders) e e seus destinatários (receivers) – Suporte para difusão (broadcast) de mensagens n Mecanismo mais comuns: – Padrão Editor-Assinante (ou Observador) – Callbacks – Notificação de eventos

48 © Nabor C. Mendonça 2001 48 Coordenadores de Aplicação n Um coordenador de aplicação é uma classe responsável pela mediação entre as camadas de apresentação e lógica da aplicação n 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

49 © Nabor C. Mendonça 2001 49 Armazenamento e Persistência n 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 Domain Relational Database Interface Object Database Interface Relational Database Object Database