Utilizando Padrões De Design No Desenvolvimento Rápido De Aplicações De Software Zalkind Lincoln Dantas Rocha Jair Cavalcanti Leite

Objetivo wMostrar o impacto do uso de padrão de design na arquitetura deste software bem como as dificuldades de implementá-lo utilizando uma linguagem em ambiente de desenvolvimento rápido de aplicações (RAD - Rapid Application Development)

Conteúdo wPatho Control - Descrição wProblemas enfrentados wPadrões de design wSoluções encontradas

Etapas do Laudo

Modelo de navegação wIr diretamente para as etapas de recepção, macroscopia, conclusão e entrega; wNavegar por estas etapas voltando ou avançando pelas telas que já percorreu; wMovimentar-se através de botões, opções de menu ou teclas de atalho.

Configuração de Ambiente wAdequar comandos de acordo com a etapa. wExemplo: l Enviar um exame para entrega somente após ter sido concluído; l Excluir exame apenas na recepção e na entrega; l Comandos de voltar e avançar desabilitados quando na primeira e última etapa visitada.

Problema: wConstruir uma arquitetura que: l i) suporte o modelo de navegação projetado; l ii) permita implementar o recurso de avançar e voltar; l iii) facilite a configuração de ambiente de acordo com a etapa.

Padrões de design wUm padrão de design é uma solução para um problema num determinado contexto. wSurgiu originalmente na arquitetura através dos trabalhos de Christopher Alexander.

Padrões de design wO objetivo é capturar a experiência acumulada de projetistas que perceberam padrões de solução para determinados problemas, catalogando e nomeando estas soluções testadas para serem reutilizadas mais facilmente.

Padrões de design wAlguns autores, como o grupo dos quatro, adaptaram este conceito, originalmente aplicado à arquitetura, para descrever soluções simples e elegantes para problemas específicos no design de softwares orientados a objetos.

Padrão Command wParametrizar objetos por uma ação executa de modo a ser implementada em outro local; wSuportar a funcionalidade de desfazer comandos.

Padrão Command

Padrão Command (Aplicado) wMudanças de etapas podem ser comandos; wAvançar e voltar podem ser desfazer e refazer; wPortanto o padrão COMMAND resolveria os problemas i e ii.

Padrão Command (Aplicado)

Padrão Observer wAlterar um objeto requer mudanças em outros e não se sabe quantos objetos precisam ser mudados.

Padrão Observer

Padrão Observer (Aplicado) wOs controles podem ser observadores e é possível criar assuntos cujos estados indiquem quando estes controles devem ser habilitados ou desabilitados. wO padrão OBSERVER seria adequado para resolver o problema iii.

Padrão Observer (Aplicado)

Considerações Finais wOs padrões realmente apresentaram soluções para problemas de design. wAdequações precisaram ser efetuadas: l O padrão Subject perdeu o acoplamento abstrato. Acoplar as modificações nos observadores concretos dentro do método Notify gerou altíssimo acoplamento.

Considerações Finais wOutras nem tanto: l O padrão Command foi implementado quase sem modificações em relação ao padrão proposto. wNovos assuntos e novos comandos foram acrescentados, inclusive fora do contexto de interface, sem implicação às classes já existentes.

Considerações Finais wEssas adaptações aos padrões originais para a solução dos problemas na linguagem utilizada podem contribuir na descrição de padrões mais específicos, chamados idiomas, podendo ser reutilizados em novos projetos

Contatos: Zalkind Lincoln Jair Cavalcanti Leite