Padrões de Projeto e Qualidade de Software

Projetar e desenvolver software de baixo consumo de recursos e custo, que atenda os requisitos pré estabelecidos, que seja reutilizável e manutenível é uma tarefa complexa. É fundamental entender as técnicas de sucesso a fim de solucionar os problemas inerentes ao processo de desenvolvimento de software. O objetivo desse trabalho é demonstrar os impactos dos Padrões de Projetos sob a qualidade de software.

Transcript

1. MINISTÉRIO DA EDUCAÇÃO UNIVERSIDADE TECNOLÓGICA FEDERAL DO PARANÁ – UTFPR CAMPUS MEDIANEIRA HOUSSAN ALI HIJAZI PADRÕES DE PROJETO E QUALIDADE DE SOFTWARE MEDIANEIRA – PR 2007
2. HOUSSAN ALI HIJAZI PADRÕES DE PROJETO E QUALIDADE DE SOFTWARE Monografia apresentada como requisito parcial ao Curso de Pós-Graduação Lato-Senso em Projeto e Desenvolvimento de Sistemas Baseados em Objetos para Ambiente Internet, UTFPR – Universidade Tecnológica Federal do Paraná, Campus Medianeira. Orientador: Jefferson Gustavo Martins, MSc. MEDIANEIRA – PR 2007
3. DEDICATÓRIA Antes de tudo, gostaria de agradecer a toda a minha família pelo apoio nos momentos difíceis, aos professores da especialização pelos ensinamentos ao longo do curso e a todos os meus amigos e companheiros que participaram direta ou indiretamente para conclusão desse projeto.
4. AGRADECIMENTOS Aos Mestres que ajudaram na minha formação profissional. Aos Companheiros da UTFPR, pelos ótimos momentos vividos na faculdade. Ao professor e orientador Jefferson, que me ajudou a tornar este trabalho realidade, estando sempre disposto quando possível a ajudar nos momentos em que precisei. Ao professor Everton, que me ajudou na bibliografia
5. RESUMO Projetar e desenvolver software de baixo consumo de recursos e custo, que atenda os requisitos pré estabelecidos, que seja reutilizável e manutenível é uma tarefa complexa. É fundamental entender as técnicas de sucesso a fim de solucionar os problemas inerentes ao processo de desenvolvimento de software. O objetivo desse trabalho é demonstrar os impactos dos Padrões de Projetos sob a qualidade de software. Palavras-Chave: Padrões de Projeto, Qualidade de Software, Desenvolvimento de software
6. ABSTRACT Project and develop software of low resource, reusable and manutenible has been to be proven as a hard task. Its a major goal understand the techniques inherents a software development, and this thesis demonstrates the benefits of using design patterns aiming quality during software development process. Key words: Design patterns; Software quality; Software Development.
7. LISTA DE FIGURAS FIGURA 3.1 – ARQUITETURA CENTRADA EM DADOS ............................................................... 19 FIGURA 3.2 – ARQUITETURA EM FLUXO DE DADOS................................................................. 20 FIGURA 4.1 - CATÁLOGO DE PADRÕES SEGUNDO A GOF. ....................................................... 26 FIGURA 5.1 - ESTRUTURA DO PADRÃO DE PROJETO SINGLETON ............................................... 27 FIGURA 5.2 - CÓGIDO EM JAVA DO PADRÃO DE PROJETO SINGLETON ....................................... 27 FIGURA 5.3 - CÓGIDO EM JAVA DE UM VALUE OBJECT ............................................................ 29 FIGURA 5.4 - PADRÃO DE PROJETO DAO............................................................................... 30 FIGURA 5.5 - APLICAÇÃO 2 CAMADAS ................................................................................... 31 FIGURA 5.6 - VÁRIAS INTERFACES (VIEWS) ............................................................................ 31 FIGURA 5.7 - CAMADAS DO PADRÃO DE PROJETO MVC.......................................................... 32
8. LISTA DE SIGLAS ABNT - Associação Brasileira de Normas Técnicas IEC - International Eletrotechnical Commission ISO - International Standardization Organization SQA Software Quality Assurance MVC Model, View, Controller DAO Data Access Object VO Value Object
9. SUMÁRIO 1 INTRODUÇÃO............................................................................................................... 11 1.1 OBJETIVOS................................................................................................... 12 1.1.1 Objetivo Geral ......................................................................................... 12 1.1.2 Objetivos Específicos ............................................................................... 12 1.2 ESTRUTURA DO TRABALHO..................................................................... 12 2 QUALIDADE DE SOFTWARE..................................................................................... 13 2.1 QUALIDADE DO PRODUTO DE SOFTWARE ........................................................... 14 2.2 QUALIDADE DO PROCESSO DE SOFTWARE ................................................ 14 2.3 UMA NOVA VISÃO ...................................................................................... 15 2.4 GARANTIA DE QUALIDADE E PADRÕES............................................................... 15 2.5 CONTROLE DE QUALIDADE...................................................................... 16 2.6 REVISÕES ........................................................................................................ 16 2.6.1 Revisões Técnicas Formais ...................................................................... 17 3 ARQUITETURA DE SOFTWARE ............................................................................... 18 3.1 TIPOS DE ARQUITETURAS ................................................................................. 18 3.1.1 Arquitetura centradas nos dados.............................................................. 19 3.1.2 Arquitetura em fluxo de dados.................................................................. 20 3.1.3 Arquitetura de chamada e retorno............................................................ 20 3.1.4 Arquitetura orientada a objeto ................................................................. 20 3.1.5 Arquitetura em camadas........................................................................... 21 3.2 MODULARIDADE.............................................................................................. 21 3.3 COESÃO........................................................................................................... 21 3.4 ACOPLAMENTO................................................................................................ 22 3.5 INDEPEDÊNCIA FUNCIONAL............................................................................... 22 4 PADRÕES DE PROJETOS ........................................................................................... 22
10. x 4.1 ELEMENTOS DE UM PADRÃO DE PROJETO.......................................................... 23 4.2 CLASSIFICAÇÃO DOS PADRÕES ......................................................................... 24 4.2.1 Padrões de criação .................................................................................. 24 4.2.2 Padrões estruturais.................................................................................. 25 4.2.3 Padrões comportamentais........................................................................ 25 5 APLICAÇÃO E ANÁLISE DE ALGUNS PADRÕES DE PROJETO ........................ 26 5.1 SINGLETON ...................................................................................................... 26 5.2 VALUE OBJECT ................................................................................................ 28 5.3 DATA ACCESS OBJECT (DAO).......................................................................... 29 5.4 MVC (MODEL/VIEW/CONTROLLER ................................................................... 30 6 CONSIDERAÇÕES FINAIS.......................................................................................... 33 7 REFERÊNCIAS.............................................................................................................. 34
11. 1 INTRODUÇÃO Desenvolver software com qualidade tem sido o grande desafio do mercado atualmente. Cumprir prazos, atender aos requisitos funcionais do software, avaliar sua complexidade, atender os aspectos funcionais, estimar custos e recursos, não são tarefas simples. É necessário um controle muito grande dos processos que envolvem a fabricação do software, desde a sua criação, a sua completa instalação no cliente e manutenção. A qualidade é uma característica com múltiplas faces de um produto. A relevância de cada face pode variar com o contexto e ao longo do tempo, pois as pessoas podem mudar seus posicionamentos e atualizar suas referências com relação a um objeto de uma questão. Portanto, a qualidade não é absoluta, mas depende da perspectiva do avaliador. Por isso, qualidade é um conceito complexo, porque possui significados diversos para diferentes pessoas. Segundo Pressman-2002:193, a qualidade de software consiste na “conformidade com requisitos funcionais e de desempenho explicitamente declarados, padrões de desenvolvimento explicitamente documentados e características implícitas, que são esperadas em todo o software desenvolvido profissionalmente”. Inseridos nesse ambiente de desenvolvimento orientado a objeto, os desenvolvedores e engenheiros de software criaram, de forma implícita, padrões universais, com o intuito de melhorar a abstração, dividir o problema em porções menores e criar soluções facilmente implementáveis, documentados pela comunidade ajudando assim a criar uma linguagem universal entre os desenvolvedores. O uso de Padrões de Projeto ajuda a nivelar a equipe de desenvolvimento, pois cria uma linguagem compreendida por todos, criam soluções coesas e ajudam a reduzir o tempo de desenvolvimento (reuso de código) e o tempo de manutenção. Segundo Pressman-2002:786, 60% de esforços despendidos por uma empresa de desenvolvimento de sistemas são causados pela manutenção de software.
12. 12 1.1 OBJETIVOS 1.1.1 Objetivo Geral Este projeto tem como objetivo mostrar que aplicar as práticas de Padrões de Projetos podem impactar no processo de desenvolvimento de sistemas e se podem ou não afetar a qualidade de software. Se a sua aplicação pode ajudar no desenvolvimento de sistemas melhorando ou não o processo de software trazendo benefícios e aumentando a qualidade. 1.1.2 Objetivos Específicos  Demonstrar e analisar alguns Padrões de Projeto.  Demonstrar e analisar as visões (produto e processo) da qualidade de software.  Demonstrar através de exemplos práticos como o uso de Design Patterns podem impactar na qualidade de software.  Demonstrar como o uso de Padrões de Projetos pode influenciar uma equipe de desenvolvimento. 1.2 ESTRUTURA DO TRABALHO Esse projeto contém 5 capítulos divididos da seguinte forma: O capítulo inicial apresenta a introdução, os objetivos e a estrutura do trabalho. O capítulo 2 trata da definição da qualidade de software enfatizando mais as visões baseadas no processo ou no produto. O capítulo 3 apresenta um histórico sobre padrões de projeto, abordando os principais padrões e sua classificação. O capítulo 4 mostra através de exemplos o uso de padrões de projetos. O capítulo 5 ressalta as considerações finais sobre os exemplos abordados e os trabalhos futuros.
13. 2 QUALIDADE DE SOFTWARE A qualidade é um termo muito relativo, porém esta totalmente ligada à satisfação do cliente, isto é, fazer o que o cliente espera que ele faça. A ISO8402 define qualidade como “a totalidade de características de uma entidade que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas”. Necessidades explícitas são as funcionalidades e objetivos propriamente ditos pelo cliente e necessidades implícitas apesar de não serem declaradas pelo cliente, são necessárias para o funcionamento do software (ex.: o processador de texto escreve textos). Segundo a SWEBOK (documento criado sob o patrocínio da IEEE com a finalidade de servir de referência sobre que assuntos são considerados, de forma generalizada pela comunidade, como pertinentes a área de Engenharia de Software): é uma área de conhecimento da Engenharia de Software que divide e subdivide a área de conhecimento de Qualidade do software nos seguintes tópicos:  Fundamentos de Qualidade de Software: Cultura e Ética de Engenharia de Software, Valores e Custos de Qualidade, Modelos e Características de Qualidade, Melhoria da Qualidade  Gerência do Processo de Qualidade de Software: Garantia de Qualidade de Software, Verificação e Validação, Revisões e Auditorias  Considerações Práticas: Requisitos de Qualidade para Aplicações, Caracterização de Defeitos, Técnicas de Gerência de Qualidade de Software, Medidas de Qualidade de Software Qualidade de software é uma área da Engenharia de Software que tem como meta produzir um software com qualidade e que atenda os requisitos funcionais, definição do escopo, com o custo e tempos estipulados. A qualidade de software é a conformidade a requerimentos e a características implícitas que são esperadas de software profissionalmente desenvolvido (PRESSMAN 2002).
14. 14 2.1 QUALIDADE DO PRODUTO DE SOFTWARE Por muito tempo a engenharia de software concentrava sua atenção na qualidade do produto em si, isto é, chegar a um resultado planejado sem se preocupar com o caminho a ser seguindo. Essa visão fazia com que os desenvolvedores de software tivessem a idéia que a medição da qualidade do produto apenas seria efetiva quando o mesmo estivesse pronto. Os testes só seriam efetuados após o software estivesse totalmente pronto e, dessa forma, uma parte do esforço gasto no desenvolvimento do produto seria despendida após o termino do mesmo. Dessa forma, de 60% do esforço gasto em um programa eram despendidos depois que ele já havia sido entregue pela primeira vez ao cliente (PRESSMAN – 2002). Com o tempo, percebeu-se que a qualidade de software baseada no produto é resultado das atividades aplicadas no processo de desenvolvimento do software. Medir a qualidade de um software é verificar se o mesmo atende aos requisitos pedidos pelo cliente, se está dentro do cronograma e se não estourou os custos pré-definidos (PRESSMAN - 2002). Essa visão é tratada nas séries de Normas ISO/IEC 9126, 14598 E 12119. 2.2 QUALIDADE DO PROCESSO DE SOFTWARE A qualidade de software é ligada à qualidade do processo de desenvolvimento como um todo. Assim, a melhoria da qualidade de software é obtida melhorando diretamente os processos envolvidos na construção de software, definindo assim a qualidade de produto gerado, ou seja, um software entregue nos prazos e custos pré-estabelecidos e que atenda aos anseios do cliente. Basicamente, melhorando o processo, é possível melhorar o produto final, pois quando focamos no processo, podemos garantir a qualidade desde o início do projeto, controlando a sua fabricação e medindo sua qualidade antes de sair do processo de produção. Avaliações são realizadas ao final de cada fase de processo, reduzindo a propagação de erros para as fases seguintes. Essa nova visão sobre qualidade de software foi impulsionada pela evolução da Engenharia de Software, e serviu como base para a criação de modelos de definição, avaliação e melhoria dos processos de desenvolvimento.
15. 15 Essa visão orientada ao processo é tratada pelo modelo de referência na Norma ISO/IEC 12207 e série de Normas ISO 9000. 2.3 UMA NOVA VISÃO As duas vertentes - qualidade de produto e qualidade de processo - são complementares e inter-dependentes. Espera-se que a qualidade do processo de fabricação tenha um impacto positivo sobre o software obtido. Entretanto, tal objetivo será atingido se houver uma compreensão clara de que os processos devem fornecer todos os mecanismos necessários para especificar o produto e controlar a fabricação desde o inicio até a entrega ao cliente final. Inspeção pós-produção Avalia o produto final, depois de pronto 1900 Controle estatístico da produção Avalia os subprodutos das etapas de produção 1940 Procedimento de produção Avalia todo o procedimento de produção 1950 Educação das pessoas Avalia as pessoas envolvidas no processo 1960 Otimização dos processos Avalia e aperfeiçoa cada processo 1970 Projeto robusto Avalia o projeto de produção 1980 Engenharia simultânea Avalia a própria concepção do produto 1990 2.4 GARANTIA DE QUALIDADE E PADRÕES A garantia de qualidade de software (SQA) é uma atividade que define a estrutura para atingir a qualidade de software, audita e relata ajuda selecionar os padrões a serem usados durante o processo de desenvolvimento de software ou o produto de software em si. (SOMMERVILLE-2003). A garantia da qualidade tem um conjunto de tarefas que envolvem duas partes: engenheiro de software e o grupo SQA. Uma vez que os engenheiros de software almejam a qualidade, através do uso de métodos e medidas técnicas, e efetuando revisões técnicas formais e testes de software. O grupo SQA tem como missão ajudar a atingir a qualidade de
16. 16 software final através de planejamento, supervisão, registro, análise e relato da garantia de qualidade. (PRESSMAN-2002). 2.5 CONTROLE DE QUALIDADE É a atividade que visa supervisionar o processo de desenvolvimento de um produto, através de revisões, testes e inspeções com o objetivo de garantir os procedimentos e padrões estabelecidos na garantia de qualidade e os requisitos especificados pelo cliente sejam contemplados. Há um ciclo de realimentação no processo quando o resultado não atende as especificações esperadas pelo mesmo. Segundo Pressman-2002, o ciclo de realimentação é essencial para minimizar os defeitos produzidos. O processo de controle de qualidade possui um conjunto de procedimentos e relatórios que devem ser compreendidos pela equipe de software. Tais procedimentos devem ser de fácil compreensão. Há duas abordagens no controle da qualidade: 1. Um grupo de pessoas é responsável pelo controle de qualidade, verificando se os padrões de projeto usados para gerar o software e a documentação estão conforme o padrão adotado. 2. Avaliação automática, onde o software gerado e os documentos são processados em algum programa e comparados aos padrões adotados. 2.6 REVISÕES Revisões são atividades amplamente utilizadas para validar a qualidade de um produto ou um processo. Um grupo de pessoas examina a documentação, uma parte ou todo o processo de desenvolvimento de software com a finalidade de encontrar possíveis erros e inconsistências. O que foi revisado? Quem fez a revisão e os possíveis erros são anotados e repassados a pessoa responsável através de um relatório. Documentos como modelos de processo, planos de testes, procedimentos de gerenciamento de configuração, padrões de processo e manuais do usuário também podem ser revisados. (SOMMERVILLE-2003). As revisões se subdividem em:
17. 17  Inspeções de projeto ou programa que usa uma checklist com o objetivo de detectar erros nos requisitos, projeto ou código.  Revisões de progresso fornecem informações à gerência sobre o progresso geral do projeto. O foco dessa abordagem são os custos, planos e prazos.  Revisões de qualidade que realiza uma análise técnica dos componentes ou da documentação do produto, com o objetivo de encontrar inconsistências entre a especificação, projeto e código ou documentação e garantir os padrões de qualidade definidos foram seguidos. (SOMMERVILLE-2003). 2.6.1 Revisões Técnicas Formais As revisões técnicas formais têm como objetivo descobrir erros na função, lógica e implementação de um produto de software, verificar se o software atende aos requisitos pré- definidos, se o sistema atende aos padrões pré-estabelecidos e tornar os projetos facilmente administráveis. Tais erros descobertos numa fase do processo de desenvolvimento de software são benéficos, pois não se propagam para a fase seguinte ou não se transformem em defeitos no produto final de software. Além desses objetivos específicos de software, as revisões técnicas formais permitem que engenheiros de software inexperientes conheçam e se familiarizem abordagens novas para análise, projeto e implementação final de software. Estudos mostram que as revisões técnicas formais são 75% efetivas na descoberta de defeitos de projetos. Tais descobertas detectadas e removidas reduzem substancialmente o curso dos passos sequentes nas fases de desenvolvimento e manutenção. Algumas diretrizes devem ser levadas em consideração quando se faz revisões técnicas formais:  Revisar o produto e não o produtor.  Fazer uma agenda e segui-la  Limitação do debate e replica quando algum ponto não aceito por toda equipe  Relatar problemas, mas não resolve-los  Anotar tudo que possível  Limitar o número de participantes
18. 18  Use uma checklist  Aloque recursos e tempo para as revisões  Treinamento dos revisores  Reveja as suas revisões 3 ARQUITETURA DE SOFTWARE A arquitetura de software é a estrutura hierárquica dos componentes de programas (módulos), a maneira que esses módulos interagem entre si e a estrutura de dados. É organização de um sistema assim como as relações entre os seus componentes. Sendo assim todos os sistemas de software tem uma arquitetura, pois ele é composto por componentes e suas relações. A arquitetura independe de tecnologia, e ajuda na abstração de informações internas do sistema e provê informações que servem de análise para a tomada de decisão e redução de riscos. As necessidades atuais de desenvolvimento de software tendem a se adequar a uma arquitetura que:  Aumente a produtividade no desenvolvimento (desde a abstração até a implantação)  Facilite e agilize a manutenção  Integre com sistemas legados e sistemas externos futuros  Seja escalável  Reduza custos de produção, treinamento e suporte ao usuário  Segurança 3.1 TIPOS DE ARQUITETURAS A maioria das arquiteturas se encaixam nos seguintes tipos:
19. 19 3.1.1 Arquitetura centrada nos dados Como o próprio nome já diz, essa arquitetura tem como característica um repositório de dados (arquivo de dados) no seu centro e os componentes a ela ligados ficam atualizando, modificando e adicionando através de um software cliente. Esse tipo de arquitetura provê integrabilidade (PRESSMAN-2002), isto é, novos clientes podem ser adicionados ou retirados sem que isso impacte nos clientes atuais, pois os mesmos operam independentemente. Figura 3.1 – Arquitetura centrada em dados
20. 20 3.1.2 Arquitetura em fluxo de dados Essa arquitetura é aplicada quando os dados de entrada precisam passar por operações computacionais para geram uma saída de dados. Há um padrão de fluxos que servem para transmitir os dados de um componente para o outro. Figura 3.2 – Arquitetura em fluxo de dados 3.1.3 Arquitetura de chamada e retorno Esse estilo de arquitetura visa ajudar o projetista de software a conseguir uma estrutura de programa que seja relativamente fácil de modificar e ampliar. (PRESSMAN-2002). Existem dois subestilos: A arquitetura de programa principal/subprograma tem como característica uma parte principal que chama outros componentes que por sua vez chama outros componentes. A arquitetura de camada de procedimentos remotos acontece quando os componentes de um sistema são distribuídos em rede. 3.1.4 Arquitetura orientada a objeto Os dados e as operações são encapsulados pelos componentes do sistema e a comunicação entre os componentes é feita através de passagem de mensagem.
21. 21 3.1.5 Arquitetura em camadas  Na medida em que os sistemas crescem os desenvolvedores de softwares começaram a dividir o mesmo a fim de obter maior manutenção. ( Essa arquitetura tem como característica separar o sistema em camadas com o intuito de deixa-las independentes. A camada mais externa é a interface com o usuário e nas camadas mais internas interagem com o sistema operacional. Essa arquitetura permite um crescimento da abstração do sistema, isto é, fácil reutilização e evolução do sistema. 3.2 MODULARIDADE A modularidade começou a ser usada amplamente usada na indústria de automóveis da década de 60. Modularidade é dividir o software em pedaços menores com um determinado contexto que em conjunto atendem aos requisitos do usuário. A modularidade ajuda a separar o sistema em subsistemas menores, e com essa estrutura os engenheiros de software podem trabalhar em partes disitintas do sistema sem dependência de outras etapas de software. Um módulo tem que ser projetado de tal forma que a informação (procedimentos e dados) contida neles seja inacessíveis a outros módulos que não precisem dessa informação. Como a maior parte das informações estão ocultas para as outras partes do software, erros gerados durante a modificação são menos prováveis de serem propagados para outros locais de software. (PRESSMAN -2002). 3.3 COESÃO Um módulo coeso executa uma tarefa dentro de uma estrutura de software, não precisando muita integração com outras partes do software. É a medida de força relacional a um módulo, isto é, o quão consistentes são os pedaços de projeto de software. Existem 4 tipos de coesão: Coesão Funcional: módulo contém elementos que contribuem para execução de uma única tarefa. Coesão Seqüencial: dados de saída de uma atividade são à entrada da próxima.
22. 22 Coesão Comunicacional: elementos de um módulo operam sobre mesmos dados. Coesão Procedural: elementos de um módulo estão envolvidos em atividades diferentes e possivelmente não relacionadas, nas quais o controle flui de uma atividade para outra. 3.4 ACOPLAMENTO Acoplamento é a medida de interligação entre os módulos numa estrutura de software. É a medida de interdepedência entre as partes do projeto, em um projeto de software, buscamos o baixo acoplamento. Uma conectividade simples entre os módulos resulta em software bem mais fácil de entender e menos propenso a “efeito de propagação”. (PRESSMAN-2002) 3.5 INDEPEDÊNCIA FUNCIONAL A independência funcional é conseguida desenvolvendo módulos com uma finalidade única e pouca interação com os outros módulos. O intuito é projetar um software com módulos que “cuidem” de uma subfunção específica dos requisitos gerais e que tenha uma interface simples com o quando “visto” por outras partes do programa. (PRESSMAN -2002). Módulos independentes são mais fáceis de manter, pois efeitos causados por uma modificação são menos propensos a propagação de erros e a reutilização é possível. 4 PADRÕES DE PROJETOS O tema padrões de projeto menciona-se através da história primeira mente pelo arquiteto Christopher Alexander durante a década de 1970 com o “A Pattern Language”, e ele os define: “Cada pattern descreve um problema que ocorre várias vezes em nosso ambiente e uma solução para esse problema, de forma que se possa reutilizá-la diversas vezes.
23. 23 Cada padrão é um a regra de três partes, que expressa uma relação entre um certo contexto, um problema e uma solução.” Em outras palavras, design patterns implementam soluções conhecidas e testadas que visam solucionar problemas recorrentes no desenvolvimento de sistemas. A popularização dos padrões de software foi obtida graças ao Gang Of Four (GOF), com o livro Design Patterns: Elements of Reusable Object-Oriented Software. O GOF coloca o termo design pattern em discussão no meio dos desenvolvedores de software, catalogando e documentando os padrões de projeto existentes e recorrentes aos projetos de software. Segundo Gamma-2004, padrões de projeto são descrições de objetos e classes comunicantes que são customizados para resolver um problema geral de projeto num contexto particular. Existem muitas definições de design pattern e os termos focais usados são o problema e a solução. Algumas características comuns dos padrões são:  Padrões são observados através da experiência.  Existem padrões em diferentes níveis de abstração.  Os padrões são artefatos reutilizáveis.  Os padrões comunicam designs e melhores práticas.  Os padrões podem ser utilizados em conjunto para selecionar problemas maiores. 4.1 ELEMENTOS DE UM PADRÃO DE PROJETO Um padrão de projeto basicamente é composto por quatro elementos essenciais: 1 - Nome do Padrão: Um nome identifica um padrão com um ou duas palavras que descreve o problema, suas soluções e consequências. Dar nome ao padrão de projeto cria um vocabulário de ajuda no nível de abstração mais alto. Um nome pode ser usado para como um vocabulário comum entre os projetistas. 2 - Problema: Descreve quando o padrão deve ser usado e explica e descreve o contexto do mesmo. Algumas vezes, poderá conter uma lista de condições a ser satisfeita para que o padrão seja aplicado.
24. 24 3 - Solução: Apresenta os elementos, relacionamentos, responsabilidades e colaborações. Descreve a forma que o padrão soluciona o problema no seu determinado contexto. A solução mostra uma descrição abstrata de um problema de projeto e como a disposição dos elementos resolve o mesmo. 4 - Conseqüências: são análises e resultados das desvantagens e vantagens da aplicação do padrão de projeto. Frequentemente envolvem compromissos de espaço e tempo, ajudando o projetista na relação custo/benefício. Visto que o reuso de código é um fator do projeto orientado a objetos, as consequências apresentam os impactos sobre a flexibilidade, extensibilidade e portabilidade. 4.2 CLASSIFICAÇÃO DOS PADRÕES Segundo Gamma (2004), os padrões de projeto são classificados por dois critérios:  O primeiro critério chamado finalidade e mostra o que o padrão faz. A finalidade é subdividida em padrões de criação, estrutural e comportamental.  O segundo critério denominado escopo, especifica se o padrão se aplica a classes ou objetos. Padrões para classes demonstram os relacionamentos de classes e subclasses através de herança fixada em tempo de compilação, enquanto os padrões de objetos lidam com relacionamentos entre objetos podendo se modificados em tempo de execução. 4.2.1 Padrões de criação Os padrões de criação abstraem o processo de instanciação, ajudando a tornar independente como o objeto é criado, composto e representado (GAMMA-2004). O padrão de criação para classes usa herança para variar a classe que é instanciada, enquanto padrão de criação para objetos delegam a instanciação para outro objeto, isto é, postergam esse processo para outro objeto. Os padrões de criação possuem duas situações: 1. Todos encapsulam conhecimento sobre quais classes concretas o sistema usará 2. Ocultam a maneira de como essas classes são criadas e juntadas
25. 25 Com isso esses tipos de padrões dão flexibilidade no que é criado, quem cria, como e quando é criado. 4.2.2 Padrões estruturais Esse tipo de padrão se preocupa com a forma de como as classes e objetos são compostos para formar uma estrutura maior (GAMMA – 2004). Padrões estruturais para classes usam herança para compor interfaces e implementações e os padrões estruturais para objetos descrevem maneiras de compor objetos para obter novas funcionalidades, e essa flexibilidade obtida com a composição de objetos provê a capacidade de mudar a composição em tempo de execução, o que é impossível com a composição estática de classes. 4.2.3 Padrões comportamentais Os padrões comportamentais se preocupam com algoritmos e a atribuição de responsabilidades entre objetos (GAMMA – 2004). Não descrevem apenas padrões de classes e objetos, mas também a comunicação entre eles. Caracterizam fluxos de controle difíceis de seguir em tempo de execução, assim eles afastam o foco do fluxo de controle permitindo se concentrar somente na maneira que os objetos são interconectados. Padrões comportamentais de classes utilizam herança para distribuir o comportamento entre classes, enquanto os padrões comportamentais de objetos utilizam composição em vez de herança.
26. 26 Figura 4.1 - Catálogo de Padrões Segundo a GoF. 5 APLICAÇÃO E ANÁLISE DE ALGUNS PADRÕES DE PROJETO Neste capítulo são apresentados alguns problemas inerentes ao processo de desenvolvimento de software, mostrando o cenário no qual ele se encaixa e aplicando padrões de projetos para solucioná-lo. A partir da aplicação dos padrões de projetos, um comparativo é feito do processo de desenvolvimento do ponto de vista, da modularidade, escalabilidade, manutenibilidade, reusabilidade, acoplamento e coesão. 5.1 SINGLETON O padrão de projeto Singleton é um padrão do catalogo do Gang of Four , está entre os padrões de projeto de software mais conhecidos, e ele resolve o problema de um de quando precisamos que uma classe tenha apenas uma instância e essa classe seja extendida
27. 27 pelas suas subclasses fornecendo um ponto global de acesso. Garante que apenas um objeto existe independente do número de requisições que receber para criá-lo (ROCHA – 2003). Segundo o Gang of Four, garantir que uma classe só tenha uma única instância, e prover um ponto de acesso global a ela. O classe que implementa o Singleton possui uma variável privada já instanciada, método construtor com acessos privados e um método do tipo público e estático que tem a função de retornar a instância pré-instanciada. Figura 5.1 - Estrutura do padrão de projeto Singleton Figura 5.2 - Código em Java do padrão de projeto Singleton
28. 28 Segundo (GAMMA-2004), recomenda-se usar esse padrão quando:  deve haver uma instância de uma classe, e essa instância deve dar acesso através de um ponto central.  quando a única instância tiver de ser extensível através de subclasses, possibilitando os clientes de usarem a instância estendida sem alterar seu código. 5.2 VALUE OBJECT Também conhecido como bean, tem como função transportar um objeto com suas características através das camadas de um produto de software. Em aplicações remotas, variáveis são passadas de um lado a outro sem encapsulamento em objeto, aumentando o uso de banda de rede e gerando uma baixa performance no sistema. Os Value Objects resolvem esse problema encapsulando os atributos em um objeto com características definidas. Uma classe que representa esse padrão tem os atributos privados e dois métodos para cada variável, um chamado de get<nome variável> que serve para pegar o valor do atributo do objeto e o outro chamado de set<nome variável> que serve para setar o valor de um atributo do objeto. Quando o objeto é instanciado os métodos set do objeto são chamados para setar as características do objeto, então o objeto é transportado pela rede ou entre as camadas de um produto de software.
29. 29 Figura 5.3 - Código em Java de um Value Object 5.3 DATA ACCESS OBJECT (DAO) Numa aplicação onde o acesso ao banco de dados é feito para uma fonte de dados específica, a mudança da base de dados se torna trabalhosa, pois seria necessário a recriação do acesso à base de dados. O acesso aos dados varia dependendo do banco de dados (dados relacionais ou dados orientados a objeto) ou da implementação. O uso do DAO ajuda para abstrair e encapsular todos os acessos ao banco de dados. O uso desse padrão ajuda a gerenciar o acesso a base e manipulação dos dados, ele `esconde` completamente detalhes de implementação do banco de dados do cliente. A lógica da aplicação que depende de um DAO usa uma interface provida pelo mesmo. Essa interface exposta pelo DAO não muda quando a base de dados for mudada, esse modelo permite ao DAO adaptar-se a diferentes sistemas de armazenamento. Esse pattern funciona como um adaptador entre o componente e a base de dados. (MICROSYSTEMS – 2002)
30. 30 Figura 5.4 - Padrão de projeto DAO 5.4 MVC (MODEL-VIEW-CONTROLLER) Nos primeiros tempos da computação, na época dos mainframes e do início do computador pessoal, os aplicativos eram desenvolvidos para serem usados em uma única máquina. Esses aplicativos continham todas as funcionalidades em um único módulo contendo muitas linhas de código e de manutenção difícil. A lógica de negócio, acesso ao banco de dados e a entrada do usuário estavam todos presentes no mesmo lugar. Com a necessidade de trabalhar dados compartilhados com outras máquinas fez surgir as aplicações em duas camadas. Nessa abordagem as máquinas centrais continham a lógica de acesso ao banco de dados que eram acessadas por outras máquinas que executavam a aplicação.
31. 31 Figura 5.5 - Aplicação 2 camadas O padrão de arquitetural MVC (Model View Controller) provê uma maneira de dividir a funcionalidade de um sistema de software em 3 camadas com o intuito de deixar cada camada menos acoplada a outra camada. Essa independência de camadas permite a utilização de várias interfaces com o usuário, isto é, uma mudança de um sistema de desktop para WEB, basta mudar a interface (View). Figura 5.6 - Várias Interfaces (Views)
32. 32 O padrão MVC é um representante da arquitetura em camadas e é separado em 3 camadas:  Model(modelo) - responsável pela lógica de negócios  View(visualizador) - responsável pela interface com o usuário  Controller(controlador) - responsável por atender as requisições e interação com o modelo. Figura 5.7 - Camadas do padrão de projeto MVC Essa separação permite múltiplas visões que compartilha a mesma regra de negócio, o que torna mais fácil de implementar, testar e manter. (MICROSYSTEMS – 2000)
33. 33 6 CONSIDERAÇÕES FINAIS Aliado a um processo de desenvolvimento de software bem definido, a adoção de uma arquitetura sólida e o uso de patterns mostram-se extremamente importantes para a qualidade final de um projeto de software. Uma arquitetura permite organizar melhor o software para atender diferentes cenários (interfaces gráficas, banco de dados, linguagens de programação, etc). O uso de patterns, por sua vez, ajuda na integração da equipe de desenvolvimento em torno de uma solução padronizada de um problema recorrente. O projeto como um todo torna- se mais claro, o código mais limpo, simplificando sobremaneira a manutenção e futuras implementações. O uso de padrões de projetos abstrai o processo de criação, trata da forma como os objetos e classes são criados e as responsabilidades eles. Sem dúvida que há um ganho de produtividade quando uma aplicação utiliza padrões de projeto é muito grande, alem de deixar o sistema modular, facilita a manutenção, ajuda na escalabilidade, construindo um sistema robusto e de qualidade. O uso de padrões ajuda na qualidade do processo e com isso o produto final torna-se com mais qualidade. Para trabalho futuros podem ser realizados estudos dentro do âmbito da produtividade do desenvolvimento de um produto de software usando o framework web Ruby On Rails.
34. 34 7 REFERÊNCIAS ALEXANDER, C. A Pattern Language: Towns, Buildings, Constructions. Oxford University Press, 1977 GAMMA, E. / HELM, R. / JOHNSON, R. / VLISSIDES, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1994 FREEMAN, E. / FREEMAN, E. Use a cabeça! Padrões de Projeto (Design Patterns) - Alta Books – 2005 GAMMA, E. / HELM, R. / JOHNSON, R. / VLISSIDES, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 2003 PRESSMAN, R. Engenharia de Software – Mcgraw-Hill - 2002 ALUR, D. / CRUPI, J. / MALI, D. Core J2EE Patterns – Campus – 2004 SOMMERVILLE, I. Engenharia de Software – Addison Wesley – 2003 METSKER, S. J. Padrões de Projeto em JAVA – Bookman – 2004 GAMMA, E. ; HELM, R. ; JOHNSON, R. ; VLISSIDES, J. - Padrões de Projetos – Soluções Reutilizáveis de Software Orientado a Objetos - Bookman – 2004 GAMMA, E. - Padrões de Projeto. - Addison Wesley - 2000. LARMAN, G. – Utilizando UML e Padrões – Bookman - 2004
35. 35 ARGONAVIS – Padrões de projeto – Padrões de Responsabilidade – link: http://www.argonavis.com.br/cursos/java/j930/J930_03.pdf acessado em 20/01/2008 MICROSYSTEMS, S. – Java BluePrints Model-View-Controller – (2000-2002) link : http://java.sun.com/blueprints/patterns/MVC-detailed.html acessado em 20/01/2008 MICROSYSTEMS, S. – Core J2EE Pattern – Data Access Object – (2001-2002) Link : http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html acessado em 26/01/2008 MICROSYSTEMS, S. – Design Pattern – Data Access Object – (2002) Link : http://java.sun.com/blueprints/patterns/DAO.html acessado em 25/01/2008