Introdução
Devido a ineficiência no processo de desenvolvimento de software, a idéia inicialmente apresentada pelo arquiteto Christopher Alexander, na década de 70, ganhou força dentre os os projetistas. Christopher notou temas recorrentes na arquitetura e o agrupou em descrições e instruções chamadas Padrões.
Padrões
Pode-se entender como Padrão soluções para problemas específicos que ocorrem de forma recorrente em um determinado contexto que foram acumulados por projetistas no desenvolvimento de software. Um Padrão é uma regra que pode ser divida em:
Contexto: descreve a situação de uma problema no desenvolvimento.
Problema: fato recorrente que atua sobre um contexto.
Solução: descreve uma configuração ou estrutura de componentes e suas interconexões, obedecendo as forças(requisitos, restrições e propriedades) presentes no problema.
Forças: são requisitos, restrições e propriedades associadas ao problema. De uma maneira geral, segundo Alexander, a força consiste em requisitos que descrevem o problema proposto a qual a solução deve atender, as restrições devem ser aplicadas às soluções e propriedades desejáveis que a solução deve alcançar.
Atualmente, os padrões tem sido amplamente utilizados em todo o processo de desenvolvimento de software, desde a análise até a implementação do sistema
Vantagens
Existem várias vantagens na utilização de Padrões no processo de desenvolvimento de software, tais como:
Descreve abstração de software.
Formação de um vocabulário comum para comunicações entre projetistas em todas as fases de um projeto.
Reduz o término de aprendizado de uma tecnologia, visto que, quando um projetista aprende uma tecnologia pode utilizar-se dela como facilitar para aprender uma nova tecnologia.
Possibilita vasta reutilização.
Classificação de Padrões
Padrões de software podem ser classificados sobre domínios. Um Padrão pode ser genérico onde tem sua aplicabilidade em domínios diferentes ou específico quando fica associado a um único domínio.
Segundo Bushmann[1996], os padrões podem ser agrupados em três categorias:
Padrões de arquitetura.
Idiomas.
Padrões de análise e projeto.
Padrões de Arquiterura
Os Padrões de Arquitetura expressam o esquema de organização da estrutura de um sistema. Eles agrupam um conjunto de subsistemas, especificando os relacionamentos entre eles e as regras de comunicação entre os relacionamentos. Um exemplo deste padrão é o MVC(Model-View-Controller).
Idiomas
Os Idiomas são padrões de baixo nível, específicos para uma linguagem de programação que descrevem como implementar aspectos particulares de componentes, bem como, os relacionamentos entre eles. Além disso, agem como diretrizes de projetos, pois acabam ditando como será feito o modo de atribuição de nomes.
Padrões de Análise e Projeto
Os Padrões de Análise e Projeto fornecem um esquema para refinar os subsistemas ou componentes de um sistema de software. Estes padrões possuem um grau de granularidade considerado médio e são independentes de linguagem de programação. Em geral os Padrões de Projeto podem ser classificados em três diferentes tipos:
Padrões de criação: abstraem o processo de criação de objetos a partir da instanciação de classes.
Padrões estruturais: tratam da forma como a classe e o objeto estão organizados para formação de estruturas maiores.
Padrões comportamentais: preocupam-se com algoritmos e a atribuição de responsabilidade entre objetos.
Cada um desses padrões podem ser subdivididos em:
Padrões de classes: em geral estáticos, definidos em tempo de execução.
Padrões de objetos: em geral dinâmicos, definidos em tempo de execução.
O catálogo Gamma é o exemplo mais famoso para padronização de projetos baseando-se em experiências de diversos projetistas. Abaixo será apresentada uma tabela com a estrutura proposta por este catálogo.
Tabela 1. Estrutura proposta pelo catálogo
| | Finalidade | |||
| Criação | Estrutural | Comportamental | ||
| Escopo | Classe | Factory Method | Adapter | Interpreter |
| Objeto | Abstract Factory | Adapter | Chain of Responsability | |
| Builder | Bridge | Command | ||
| Prototype | Composite | Iterator | ||
| Singleton | Decorator | Mediator | ||
| | Facade | Memento | ||
| | Flyweigth | Observer | ||
| | Proxy | State | ||
| | | Strategy | ||
| | | Vistor | ||
Umas séries de características podem ser realizados a cada item contido na tabela. Por critério de visualização será apresentado uma relação de tipos de padrões e sua referida funcionalidade.
Tabela 2. Especificação do catálogo Gamma
| | Descrição | Uso | |
| Padrões de Criação | Abstract Factory | Fornece uma interface para criação de famílias de objetos relacionados ou dependentes sem especificar duas classes concretas. | Transportabilidade entre diferentes bibliotecas de interfaces gráficas. |
| Builder | Separa a construção de um objeto complexo da sua representação, de modo que o mesmo processo de construção possa criar diferentes representações. | Conversão de formatos de texto em editores. | |
| Factory Method | Define uma interface para criar um objeto, mas deixa as subclasses decidirem qual a classe que será instanciada. Permite a uma classe postergar a instanciação de subclasses. | Bastante usado em toolkits e frameworks para a instanciação de objetos. | |
| Prototype | Especifica os tipos de objetos a serem criados usando uma instância prototípica e cria novos objetos copiando este protótipo. | Depurador Etgdb. | |
| Singleton | Garante que uma classe tenha somente uma instância e fornece um ponto global de acesso para ela. | Programas que só podem ter uma instância sendo executada em um dado momento. | |
| Padrões Estruturais | Adapter | Converte a interface de uma classe em uma outra interface esperada pelo clientes. Permite que certas classes trabalhem em conjunto, pois de outra forma seria impossível por causa de suas interfaces incompatíveis. | Popularmente conhecido como wrapper, usado para adaptar a interface de classes. |
| Bridge | Separa uma abstração de sua implementação, de modo que as duas possam varias independentemente. | Para evitar o vínculo entre abstração e implementação quando de mudanças na implementação em tempo de execução. | |
| Composite | Compõe objetos em estrutura de árvores para representar hierarquias do tipo partes-todo. Permite que os clientes da estrutura tratem objetos individuais e composições de objetos de maneira uniforme. | Para representar hierarquias parte-todo. | |
| Decorator | Atribui responsabilidades adicionais a um objeto dinamicamente. Fornece uma alternativa flexível à utilização de subclasses para a extensão de funcionalidades. | Para a atribuição de enfeitos gráficos e outras funcionalidades acessórias a widgets. | |
| Façade | Fornece uma interface unificada para um conjunto de interfaces em um subsistema. Define uma interface de nível mais alto que torna o subsistema mais fácil de usar. | Interface única em sistema complexos. | |
| Flyweigth | Usa compartilhamento para suportar grandes quantidades de objetos, de granularidade fina, de maneira eficiente. | Sistemas com grandes números de objetos. | |
| Proxy | Fornece um objeto representante ou um marcador de outro objeto para controlar acesso ao mesmo. | Algumas implementações corbas. | |
| Padrões Comportamentais | Chain of Responsibility | Evita o acoplamento entre o remetente de uma solicitação e o destinatário da solicitação, dando a mais de um objeto a chance de tratar a solução. Encadeia os objetos receptores e passa a solicitação ao longo da cadeia até que um objeto trate. | Tratamento de eventos do usuário. |
| Command | Encapsula uma solicitação como um objeto, permitindo a parametrização de clientes com diferentes solicitações, o enfileiramento e o registro de solicitações e o suporte a operações que possam ser, por exemplo, desfeitas. | Suporte a desfazer. | |
| Interpreter | Dada uma linguagem, define uma representação para uma gramática juntamente com um interpretador que usa a representação para interpretar sentenças nessa linguagem. | Interpretar uma linguagem com uma árvore sintática abstrata, como em compiladores de linguagens orientadas à objetos. | |
| Iterator | Fornece uma maneira de acessar sequencialmente os elementos de um objeto agregado sem expor sua representação subjacente. | C++ Standard Template Library | |
| Mediador | Define um objeto que encapsula a interação entre um conjunto de objetos. Promove o acoplamento fraco ao evitar que os objetos se refiram explicitamente uns aos outros, permitindo a variação das interações independentemente. | Arquitetura de aplicações Smalltalk. | |
| Memento | Sem violar a encapsulação, captura e externaliza um estado interno de um objeto, de modo que o mesmo possa posteriormente ser restaurado para esse estado. | Armazenar um instantâneo do estado do objeto sem romper o encapsulamento. | |
| Observer | Define uma dependência um-para-muitos entre objetos, de modo que, quando um objeto muda de estado, todos os seus dependentes são automaticamente notificados e atualizados. | Propagação de mudanças e atualizações com acoplamento fraco entre objetos. | |
| State | Permite que um objeto altere seu comportamento quando seu estado interno muda. O objeto parecerá ter mudado sua classe. | Em algumas implementações da pilha TCP/IP. | |
| Template Method | Define o esqueleto de um algoritmo em uma operação, postergando a definição em alguns passos para a subclasses. Permite que as subclasses redefinam certos passos de um algoritmo sem mudar sua estrutura. | Arquiteturas Application/Document/View. | |
| Visitor | Representa uma operação a ser executada sobre os elementos de uma estrutura de objetos. Permite a definição de uma nova operação sem mudar as classes dos elementos sobre os quais opera. | Para executar uma série de operações sobre os objetos que possuem interfaces diferentes, sem poluir a interface dos mesmos. | |
Linguagens de Padrões
Linguagens Padrões consiste em uma coleção estruturada de padrões que são construídos a partir de outros padrões para transformar necessidades e restrições em uma arquitetura[Coplien].
Conclusão
Os Padrões e Linguagens Padrões têm como objetivo profissionalizar o processo de desenvolvimento de software, ainda que, os Padrões não apresentem uma solução exata.
José Mauro da Silva Sandy
Referências
- Buschmann et al. Pattern-Oriented Software Architecture, Wiley, 1996.
- J. Coplin, The Colunm Whitout a Name, C++ Report, 94+.
- UFSC. Padrões de Projeto. Disponível em<http://s2i.das.ufsc.br/tikiwiki/apresentacoes/padroes_de_projeto.pdf>. Acesso em 14 ago. 2009.
- Entendo como é formada a linha digitável nos boletos bancários - Apresentação de como é realizada a formação dos boletos bancários.
- Limites Inferiores e NP-Completude - Análise de algoritmo NP e limites
0 comentários:
Postar um comentário