Etapas principais do desenvolvimento de software Padrões arquiteturais Padrões de projeto

Transcrição

1 Etapas principais do desenvolvimento de software Padrões arquiteturais Padrões de projeto 1

2 Criar aplicações não é apenas escrever código (code and fix) Atualmente as aplicações exigem arquiteturas e código cada vez mais sofisticados Um dos maiores desafios é saber o que codificar 2

3 Aprender conceitos úteis para o planejamento e construção de aplicações Flexíveis, eficientes, reutilizáveis e de fácil manutenção Uso de padrões de projeto como soluções para problemas recorrentes dentro da programação 3

4 C++ é uma linguagem usada como ferramenta de aprendizado pois Possui um enorme material disponível através de livros, sites, tutoriais, etc. Possui IDEs, depuradores, bibliotecas, etc. É multiplataforma: Linux, Windows, Mac OS, etc 4

5 No entanto, o principal desafio não é a linguagem C++ ou qualquer outra linguagem O desafio é como estruturar sua aplicação: Decidir quando e quais classes utilizar 5

6 Existem vários metodologias, fases, mas em geral as etapas são: Análise Projeto Implementação Testes Não é linear 6

7 Se cada fase for bem trabalhada minimiza o risco de alterações na aplicação Mudanças essas que poderiam impactar severamente no cronograma e também no sucesso do projeto 7

8 O que a aplicação deve fazer: Análise ruim resulta frustração 8

9 Uma boa análise deve fornecer uma ESPECIFICAÇÃO CLARA que esboça as necessidades do cliente. Diferente das outras fases, a análise não necessita ter uma aspecto técnico. 9

10 O produto gerado pela fase de análise é geralmente um documento que pode ser: Uma simples lista de tudo que a aplicação deve ser capaz de fazer Casos de uso que apresentam os requisitos da aplicação demonstrando as possíveis interações que os usuários terão com a aplicação 10

11 Define como será a aplicação O produto da fase de projeto é um documento que ajuda a dividir o desenvolvimento da aplicação em etapas menores 11

12 Determinação das classes Responsabilidades de cada classe Os relacionamentos que cada classe tem com seus colaboradores Definição das interfaces fornecidas pela aplicação (os métodos públicos das classes) 12

13 Responsabilidade é essencialmente o que uma classe (ou instância de uma classe) deve ser capaz de realizar É geralmente algo que pode ser escrito em uma linguagem de programação, por exemplo: Criar um formulário de dados, validação estes dados Tratar requisições e respostas para e de um serviço de um servidor Desenhar uma figura de um modelo de dados À medida que se definem as responsabilidades das classes, são feitas: alterações, mudanças, adições de novas classes e outras são descartadas. 13

14 Codificar o que foi definido nas fases anteriores 14

15 Boas práticas de codificação são um grande benefício para o desenvolvimento de aplicações Melhoram a legibilidade da aplicação tornando-a mais fácil de compreender por outros desenvolvedores de sua equipe int ano; Mapa cidade; void obtenhadadosmapaparaendereco(dadosendereco endereco); 15

16 Exemplo de boa prática de programação 16

17 Acoplamento forte ou Acoplamento fraco Acoplamento fraco cria aplicações flexíveis e adaptáveis. Se objetos são fortemente acoplados, a aplicação torna-se rígida, ou seja, uma mudança em um objeto pode atingir outros objetos e prejudicar todo o sistema. 17

18 Executar testes podem ajudar a determinar se a aplicação roda como esperado e permite detectar possíveis erros. Quem faz os testes? Testadores Os próprios desenvolvedores De que forma? Testes manuais Testes automatizados 18

19 Padrões de software que oferecem soluções bem-definidas para problemas arquiteturais em um software Expressam uma forma de organização estrutural para um software, que consiste de subsistemas, suas responsabilidades e interrelações Em comparação com padrões de projeto, padrões arquiteturais são maiores em escala 19

20 Cada camada (tier) é desenvolvida e mantida como um módulo independente Conceitualmente a arquitetura em 3 camadas é linear. O padrão MVC é triangular. 20

21 Frequentemente mais utilizados em aplicações Web View: página HTML Controller: código que reúne dados dinâmicos e gera o conteúdo dentro do HTML Model: conteúdo atual, geralmente armazenado em um banco de dados 21

22 Peer-to-Peer (P2P) Invocação implícita Arquitetura orientada a serviços E outros mais. 22

23 Um padrão é uma descrição do problema e a essência da sua solução Documenta boas soluções para problemas recorrentes Permite o reuso de conhecimento anterior documentados em boas práticas Deve ser suficientemente abstrato para ser reusado em aplicações diferentes 23

24 Algo comprovado que captura e comunica os conhecimentos das melhores práticas Descoberto, não inventado Soluções Sucintas e de Fácil Aplicação Capturam, de forma sucinta e facilmente aplicável, soluções de projeto de programas de computador que foram desenvolvidas e evoluíram com o passar do tempo 24

25 Soluções Exaustivamente Refinadas Resultados de um longo processo de projeto, re-projeto, teste e reflexão sobre o que torna um sistema mais flexível, reusável, modular e compreensível Soluções Compartilhadas Construídas em grupo Através do uso de um vocabulário comum 25

26 Os 23 padrões de projeto mais conhecidos foram popularizados pelo livro de E. Gamma, R. Helm, R. Johnson e J. Vlissides Conhecido como Gang-of- Four (GoF) 26

27 Segundo o seu propósito De Criação: tratam da criação de objetos Estruturais: tratam da composição de classes e objetos Comportamentais: tratam das interações e responsabilidades entre classes e objetos Segundo seu escopo Classes: lidam com os relacionamentos entre classes e subclasses Objetos: lidam com os relacionamentos entre objetos 27

28 Nome Um identificador significativo para o padrão Descrição do problema Descrição da solução Um template de solução que pode ser instanciado em maneiras diferentes Consequências Os resultados e compromissos de aplicação do padrão B 28

29 Tornam um sistema independente de como seus objetos são criados, compostos e representados Estes tipos de padrões ajudam a tornar a aplicação mais flexível, não necessariamente menor Padrões criacionais geralmente delegam a criação de objetos para subclasses 29

30 Abstract Factory Builder Factory Method Prototype Singleton 30

31 Permite a criação de objetos a partir de classes abstratas através do uso de subclasses Pode associar duas ou mais hierarquias de classe diferentes mas relacionadas entre si Muito utilizado na criação de frameworks para definir e manter relacionamentos entre objetos 31

32 Uma classe não é capaz de definir os tipos de objetos que deve criar Uma classe deseja que suas subclasses especifiquem os objetos que estão criando Classes delegam tarefas para uma de várias classses auxiliares, e deseja-se saber qual delas recebeu alguma tarefa para realizar 32

33 33

34 Creator : declara o factory method (método de fabricação) que retorna o objeto da classe Product (produto). Este elemento também pode definir uma implementação básica que retorna um objeto de uma classe ConcreteProduct (produto concreto) básica; ConcreteCreator sobrescreve o factory method e retorna um objeto da classe ConcreteProduct; 34

35 Product define uma interface para os objectos criados pelo factory method; ConcreteProduct uma implementação para a interface Product. 35

36 Factory method elimina a necessidade de associar classes específicas de aplicação no código. O código lida apenas com a interface Product portanto a mesma pode funcionar com qualquer classes ConcreteProduct definidas pelo usuário Exemplo: suponha uma aplicação lida com diversos tipos de documentos A mesma sabe quando os documentos devem ser criados, mas não sabem que documentos criar 36

37 Factory method elimina a necessidade de associar classes específicas de aplicação no código. O código lida apenas com a interface Product portanto a mesma pode funcionar com qualquer classes ConcreteProduct definidas pelo usuário Exemplo: suponha uma aplicação lida com diversos tipos de documentos A mesma sabe quando os documentos devem ser criados, mas não sabem que documentos criar 37

38 A aplicação construída através de um framework baseado no padrão Factory Method, suporta a criação de documentos do tipo MeuDocumento. 38

39 classaplicacao{ protected: Documento doc; public: virtual Documento criadocumento() = 0; voidnovodocumento() { this.doc = this->criadocumento(); } }; voidabrirdocumento() { this->doc.abrir(); } classdocumento { }; virtual void abrir() = 0; virtual voidfechar() = 0; virtual void gravar() = 0; 39

40 class MinhaAplicacao: public Aplicacao{ public: virtual Documento criadocumento() { returnnew MeuDocumento(); } }; class MeuDocumento: public Documento { public: virtual void abrir() { cout << "Documento: Abrir documento! << endl; } }; virtual voidfechar() { cout<< "Documento: Fechar documento! << endl; } virtual void gravar() { cout << "Documento: Salvar documento! << endl; } 40

41 O framework é constituído pelas classes abstratas Aplicacao e Documento. A aplicação disponibiliza as classes concretas MinhaAplicacao e MeuDocumento. A classe MinhaAplicacao é uma implementação da abstração definida pela classe Aplicacao 41

42 A chave deste padrão está na declaração do método abstrato criadocumento, da classe Aplicacao, e na sua utilização pelo método novodocumento. Isso permite que o método novodocumento crie documentos sem conhecer os detalhes de implementação Desta forma, a implementação do método criadocumento (neste caso situada na classe MinhaAplicacao) varie livremente, para atender os diversos formatos possivelmente suportados. Sem que seja necessário modificar o código das classes abstratas. 42

43 Nome Singleton Descrição do problema Uma classe precisa ter uma única instância Descrição da solução Próximo slide Consequências Fácil acesso e gerência de recursos compartilhados, como variáveis globais 43

44 O construtor é privado O método getinstance() é público e estático Retorna a única instância que é guardada em uma variável de classe 44

45 classsingleton{ private: staticsingleton*instance; Singleton() { // construtor privado } public: staticsingleton* getinstance(); voidmetodo(); }; Singleton* Singleton::instance= NULL; 45

46 Singleton* Singleton::getInstance() { if(!instance) { instance= new Singleton(); returninstance; } else{ returninstance; } } voidsingleton::metodo() { cout<< "Metododa classe Singleton" << endl; } 46

47 Possui um atributo que armazena a única instância da classe Construtor da classe é privado para evitar criação acidental de outras instancias. Única instancia só pode ser obtida pela chamada ao método getinstance() da classe. 47

48 intmain() { } Singleton*sc1,*sc2; // Singleton objeto; //erro de compilação sc1 = Singleton::getInstance(); sc1->metodo(); sc2 = Singleton::getInstance(); sc2->metodo(); 48

49 Padrões de projeto estruturais são padrões que lidam com as estruturas do projeto, facilitando a comunicação entre suas entidades. Estes padrões, em outras palavras cuidam da estrutura de seu projeto. Fazendo analogia com a engenharia civil, estes seriam responsáveis por definir o alicerce da construção bem como a estrutura para sustentá-la 49

50 Adapter Bridge Composite Decorator Façade Flyweight Proxy 50

51 Uma biblioteca é projetada para ser reusada Entretanto, a interface da biblioteca (assinatura dos métodos) pode não ser exatamente a esperada pela aplicação Não é desejável alterar o código da aplicação Não é desejável alterar a interface da biblioteca 51

52 Nome Adapter Descrição do problema Permitir que classes com interfaces incompatíveis trabalhem juntos Descrição da solução Próximo slide Consequências Reuso de funcionalidades de uma classe sem alterar sua interface 52

53 53

54 O cliente (Client) precisa de uma funcionalidade A funcionalidade já está implementada no Adaptee. Entretanto, os métodos tem assinaturas diferentes. A classe Target tem a assinatura do método que o cliente precisa. A classe Adapter converte a assinatura do método em Adaptee para aquela que o cliente precisa. 54

55 classtomadadedoispinos{ }; public: voidligarnatomadadedoispinos() { cout<< Ligado na Tomada de Dois Pinos << endl; } class TomadaDeTresPinos{ public: voidligarnatomadadetrespinos() { cout<< Ligado na Tomada de TresPinos << endl; } } 55

56 classadaptertomada: publictomadadedoispinos { private: TomadaDeTresPinostomadaDeTresPinos; public: AdapterTomada(TomadaDeTresPinos tomadadetrespinos) { this->tomadadetrespinos = tomadadetrespinos; } }; voidligarnatomadadedoispinos() { tomadadetrespinos.ligarnatomadadetrespinos(); } 56

57 Tem-se uma classe TomadaDeDoisPinos que deve ser conectada a uma classe TomadaDeTresPinos que possui outros métodos e uma outra interface diferente. Usamos um Adapter para poder acessá-la. O Adapter herda da TomadaDeDoisPinos (o seu Target como mostrado no diagrama de classes). Dentro do Adapter tem-se o que o cliente precisa que é a TomadaDeTresPinos que será chamado posteriormente no método ligarnatomadadedoispinos que na verdade está chamando o método ligarnatomadadetrespinos. 57

58 int main() { TomadaDeTresPinos *t3 = new TomadaDeTresPinos(); AdapterTomada *a = new AdapterTomada(t3); a->ligarnatomadadedoispinos(); } 58

59 O cliente faz uma chamada usando a tomada de dois pinos Mas na realidade esta chamada está sendo adaptada para uma tomada de três pinos. Assim temos duas interfaces que não eram compatíveis entre si conversando normalmente. 59

60 Nome Decorator Descrição do problema Agregar dinamicamente novas responsabilidades a um objeto Descrição da solução (Próximo slide) Consequências Maior flexibilidade que herança Evita sobrecarregar hierarquia de classes 60

61 61

62 A classe abstrata Component é implementada pela classe concreta ConcreteComponent, que é o objeto no qual será adicionado dinamicamente um novo comportamento. As classes Decorator implementam a mesma interface abstrata que o componente que irão decorar. Os ConcreteDecorator também podem adicionar mais comportamentos (método addedbehavior() no diagrama ConcreteDecoratorB) ou mais atributos (addedstate no diagrama ConcreteDecoratorA). Portanto a ideia basicamente é que através dos Decorators possamos adicionar comportamentos aos componentes bases (ConcreteComponent). 62

63 class Janela { // Component public: virtual voiddraw() = 0; } ; class JanelaSimples: public Janela { // ConcreteComponent public: virtual voiddraw() { cout<< desenha uma janela << endl; } }; class JanelaDecorator: public Janela { // Decorator protected: Janela janeladecorada; public: JanelaDecorator(Janela janeladecorada) { this->janeladecorada= janeladecorada; } }; 63

64 Acima tem-se a implementação da primeira parte do padrão Decorator. Nesse exemplo criou-se uma janela simples onde queremos adicionar mais coisas como barras de rolagem, caixas de texto, labels, etc. Assim, criou-se também a classe JanelaDecorador que será estendida pelos decoradores que irão inserir propriedades na nossa janela. 64

65 class DecoradorBarraVertical: public JanelaDecorator{ //ConcreteDecorator }; private: voiddrawbarravertical() { cout << desenha uma barra vertical na janela ; } public: DecoradorBarraVertical(Janela janeladecorada) : JanelaDecorator(janelaDecorada) { } virtual voiddraw() { drawbarravertical(); janeladecorada.draw(); } 65

66 No código acima um decorador anexa uma barra vertical ao nosso componente principal (JanelaSimples). Portanto, anexamos responsabilidades ao nosso componente base. Se quiséssemos criar uma barra horizontal, menus, botões, faríamos outros decoradores para anexar mais responsabilidades. Uma situação importante a se observar são as duas chamadas ao método draw(). A chamada a drawbarravertical() chama ele próprio para pintar na tela a sua própria barra vertical e a outra chamada que veio da superclasse é a responsável por chamar outros decoradores que podem ser anexados na classe. 66

67 intmain() { Janela *janeladecorada = new DecoradorBarraVertical( new JanelaSimples()); } janeladecorada->draw(); Note que a execução do janeladecorada.draw() irá chamar o método draw da janela simples combinado com o draw() do nosso decorator. 67

68 Perguntas? 68

69 FIM 69