Padrões Projeto de Softwares Categorias de Padrões Processo de Tradução de modelos de análise (isentos de tecnologia, lógicos) para modelos de projeto (development-ready, físicos) Qual a Tecnologia Alvo ideal ou disponível? Como acomodar restrições e requisitos não funcionais na Infra-estrutura real que estará disponível? Quais serão os procedimentos da produção (back-ups, espelhamento, segurança, etc...) Que padrões definir, estabelecer e como garantir e controlar o cumprimento destes padrões 1
Processo de Tradução de modelos de análise (isentos de tecnologia, lógicos) para modelos de projeto (development-ready, físicos) Como fazer valer os SLAs e padrões (ITIL, COBiT), acordados c/ cliente? Como manter a coerência e a rastreabilidade com os modelos de análise? Como fazer tudo isso com qualidade, manutenibilidade, extensiblilidade, flexibilidade e reusabilidade (usando coisas prontas)??? Palavra de ordem: trade-off (tomar decisões...) Reusabilidade Característica desejável de bons projetos Partes de um projeto em andamento devem ser projetada para reaproveitamento futuro Re-uso de partes projetadas no projeto anterior Design Patterns: Reusabilidade Conceitual, geralmente requerer adaptação ao contexto FrameWorks: Reusabilidade de Código (classes, componentes e sub-sistemas) prontos (Ready-to-use) 2
Flexibilidade Característica desejável de um projeto de software, reflete a capacidade de um pattern ou framework alterar suas funcionalidades em função das necessidades de uma aplicação específica que pretende usá-lo. Extensibilidade Característica desejável de um projeto de software, reflete a possibilidade de alteração (manutenibilidade) e de evolução de um framework ou pattern. 3
Encapsulamento Característica de bons projeto, no qual agrupa-se e blinda-se um conjunto de elementos de código/design, fornecendo aos demais elementos um meio de acesso (interface) bem clara para ser acessado. os elementos com bom encapsulamento devem ser projetados para possuir uma forte relação interna (alta coesão) e uma interface clara que facilite seu uso pelos demais (fraco acoplamento) Encapsulamento Projeto OO Projeto Clássico Nível 1 Métodos Linhas de código Nível 2 Classe / Objeto Funções/Subprogramas Nível 3 Componente Biblioteca Nível 4 Sub-Sistema Sub-Sistema Nível 5 Serviço (SOA) Serviço (SOA) 4
Acoplamento Medida de projetos de software Mede a dependência entre partes (elementos) do projeto de uma aplicação Quanto mais baixo for o grau de acoplamento entre seus elementos (módulos, bibliotecas, componentes, sub-sistemas), mais qualidade tem o projeto do software Coesão Medida de projetos de software Mede a associação funcional entres os elementos internos de um elemento do software (módulos, bibliotecas, componentes, sub-sistemas) Quanto mais alto o grau de coesão, mais qualidade tem o projeto do software. 5
Categorias Padrões Arquiteturais Expressam um esquema estrutural fundamental para sistemas de software Provêem um conjunto de subsistemas fundamentais, especificam suas responsabilidades e incluem regras e guias para a organização dos relacionamentos entre eles Categorias Padrões de Projeto Provêem um esquema para refinamento dos subsistemas ou componentes de um sistema de software ou dos relacionamentos entre eles. Descrevem uma estrutura recorrente comum de componentes de comunicação que solucionam um problema de projeto geral dentro de um contexto particular 6
Categorias Idiomas São um padrão de nível baixo específico de uma linguagem de programação Descrevem como implementar aspectos particulares de componentes ou de relacionamentos entre eles usando as características de uma dada linguagem Categorias de Patterns Categorias de patterns definidos por GoF (grupo de 4 Gamma e colegas) Creational (de Criação) Structural (Estruturais) Behavioral (Comportamentais) Outros autores desenvolveram outros patterns Basic (boas práticas para programação OO) Collectional (manutenção de coleções de objetos) Concurrency (lidam c/ concorrência, race conditions) Persistência (ex: DAO) 7
Categorias de Patterns Creational (de Criação) Mecanismos para Criação de Objetos Structural (Estruturais) Delegação de responsabilidades para outros objetos. Facilita desenvolvimento em camadas Behavioral (Comportamentais) Atribuição de responsabilidade entre diferentes objetos, a maioria em tempo de execução Collectional (Coleções) Coleções de objetos Concurrency Mecanismos p/ evitar concorrência, race-conditions, deadlocks 8