Design Pattern e a Reusabilidade de Software

Apresentação em tema: "Design Pattern e a Reusabilidade de Software"— Transcrição da apresentação:

1 Design Pattern e a Reusabilidade de Software
Klevison Matias

2 Introdução Tema O presente trabalho visa abordar os principais conceitos relativos aos Padrões de Projeto de Software, os quais descrevem possíveis soluções de problemas comuns encontrados em projetos orientados a objetos (Meyer, 1997).

3 Introdução Com a crescente necessidade de se obter excelência nos serviços e produtos, em toda ou qualquer empresa, surge a necessidade das mesmas obterem uma boa estrutura para se adaptarem às crescentes exigências do mercado. Esse cenário visa encorajar cada vez mais assuntos como produtividade e qualidade. Para a área de software não é diferente. Reutilização é um ponto chave para produtividade, sendo também um dos atributos considerados na avaliação de qualidade de software.~\citep{Pree1995a}.

4 Introdução 1977 Cristopher Alexander - A Pattern Language: Towns, Buildings, Constructions 1995 Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides - Design Patterns: Elements of Reusable Object-Oriented Software

5 Introdução • Padrões resolvem problemas reais, sendo soluções já comprovadas e testadas em diversos casos de um ou vários domínios; • Capturam o conhecimento dos modeladores mais experientes, aumentando o reuso de idéias; • Ajudam modeladores iniciantes a compreender e resolver problemas complexos; • Podem ser utilizados para registrar e encorajar o reuso das melhores práticas; • Capturam partes essenciais do projeto de forma compacta; • Aumentam o nível de abstração para o desenvolvimento de soluções para os problemas; • Formam um vocabulário comum para discussão e resolução de problemas; • Servem para melhorar a comunicação entre membros de uma equipe; • Indicam, além da solução, as condições necessárias para aplicá-la, o raciocínio lógico utilizado para concebê-la, as restrições e custos associados.

6 Introdução Padrões de projeto são metodologias de construção de software comprovadamente funcionais que garantem legibilidade, manutenbilidade e reutilização de código-fonte no desenvolvimento de alguma aplicação computacional (Daniel Welfer, 2005). Um pattern descreve um problema que ocorre com frequência em nosso ambiente, e então explica a essência da solução para este problema, de forma que tal solução possa ser utilizada milhões de outras vezes, sem ao menos repeti-la uma única vez. Um dos aspectos relevantes na pesquisa em questão é a demonstração de que construir um sistema de software reutilizável não é o modo mais rápido e tampouco mais cômodo de se desenvolver software (Gamma et al., 1995).

7 Conceitos Preliminares Orientação a Objetos
Segundo Agostini2007 a modelagem orientada a objetos é um modelo de software e um paradigma de implementação em que o foco principal é sobre as estruturas de dados. Essas estruturas de dados estão divididas basicamente em classes e objetos. Entender sistemas orientado a objetos é a arte de combinar o concreto (objetos e suas interações) com o abstrato (classes e seus relacionamentos) Lange1995. Durante o tempo de execução, essas classes são instanciadas por objetos que trocam mensagens e realizam as tarefas associadas ao software. Conceitos como herança, composição, polimorfismo, encapsulamento e abstração (que serão vistos mais adiante) dão suporte ao desenvolvimento de estruturas de classe eficientes.

8 Conceitos Preliminares Orientação a Objetos
Encapsulamento • Public São sempre acessíveis em todos os métodos de todas as classes. Este é o nível menos rígido de encapsulamento, que equivale a não encapsular. • Protected São acessíveis no pacote, nos métodos da própria classe e suas subclasses(o que será visto em Herança). • Private São acessíveis somente nos métodos (todos) da própria classe. Este é o nível mais rígido de encapsulamento.

9 Conceitos Preliminares Orientação a Objetos
Herança Segundo Lavin2006 em um sentido biológico, um filho herda genes do seus pais, e esse material genético condiciona a aparência e o comportamento do filho. Na programação orientação a objetos o significado de herança é análogo. Programar orientado a objeto nos permite criar uma hierarquia de classes de modo que se tenha uma estrutura na qual classes derivadas (filhas) herdem propriedades (atributos) e comportamentos (métodos) de uma determinada classe (mãe). Esse é um dos principais conceitos da orientação a objetos, a Herança. Ao utilizar esse conceito evita-se reescrever códigos semelhantes para classes semelhantes, assim podendo reutilizar código e padronizar o projeto de software.

10 Conceitos Preliminares Orientação a Objetos
Abstração A programação orientada a objetos nos permite separar, em um dado momento, a implementação em algumas partes, para que se possa focar no que o objetivo daquele modelo (Classe) é ou faz antes de se decidir como ele será implementado. Essa “separação” é conhecida no paradigma de orientação a objetos como abstração.

11 Conceitos Preliminares Orientação a Objetos
Interface Uma interface tem características parecidas com uma classe abstrata, ela isola do mundo exterior os detalhes de implementação, porem em uma interface não contém nenhum código de implementação, apenas assinaturas de métodos e/ou atributos que devem ter seu código implementado nas classes que implementarem essa interface. Ela serve como uma espécie de contrato para classes que irão implementá-la.

12 Conceitos Preliminares Orientação a Objetos
Polimorfismo O termo polimorfismo tem sua origem do grego e significa “várias formas” (poli = várias, morphos = formas). Esse conceito permite que diferentes objetos tenham um mesmo método como uma particularidade, ou seja, certo método responde de maneiras diferentes para determinados objetos. Por conta dessa flexibilidade muitos patterns utilizam esse conceito.

13 Conceitos Preliminares Orientação a Objetos
Propriedades e Métodos Estáticos O que difere métodos e atributos não estáticos de métodos e atributos estáticos é o fato de se poder acessar um membro estático sem precisar instanciar a classe a que ele pertence. Um método pode fazer uso apenas dos recursos de uma classe (e não das informações associadas a cada objeto individualmente).

14 Conceitos Preliminares Orientação a Objetos
Coesão e Acoplamento Para a engenharia de software a qualidade de um software aumenta-se com baixo acoplamento e alta coesão. Coesão A coesão é definida, em termos acadêmicos, como a medida de proximidade no relacionamento entre todas as responsabilidades, os dados e os métodos de uma classe. Ou seja, significa o quão uma classe é específica para desempenhar um papel em um contexto. Quanto menor a diversidade de “assuntos” abordados por uma entidade, maior a sua coesão e quando esta entidade está bem focada em um determinado aspecto do sistema, é uma entidade bem coesa. Acoplamento Significa a medida do quão uma determinada classe conhece o ambiente ao seu redor. Ou seja, o quão “presa” (possui conhecimento ou depende) uma parte do sistema é às outras partes. O alto acoplamento significa que as classes relacionadas precisam conhecer detalhes internos umas das outras. O baixo acoplamento visa minimizar dependências e maximizar o reuso.

15 Conceitos Preliminares Reusabilidade de Software
Todo o conceito de orientação a objetos visto acima tange uma das principais propostas do design patterns, a reusabilidade. A orientação a objetos oferece uma gama de soluções para se projetar de maneira reutilizável. A reusabilidade não é obtida pelo simples fato de desenvolvermos softwares orientados a objetos. O software deve ser planejado para ser reusável. O uso de design patterns é um “acordo”' com o reuso de código, um dos principais princípios da orientação a objetos, que assegura modularidade e extensibilidade para o projeto Agostini2007. Conceitos como herança e interfaces devem ser encorajados a fim de se obter o máximo de reuso do código, pois como visto anteriormente esses conceitos ajudam a generalizar problemas em um projeto de software. Segundo GAMMA1995 projetar software orientados a objeto é difícil, mas projetar software reutilizável orientado a objetos é ainda mais complicado. Pois para a utilização de patterns requer experiência do projetista em orientação a objetos, para que o mesmo possa identificar no seu projeto em particular onde os patterns podem ser aplicados.

16 Conceitos Preliminares Reusabilidade de Software - História
O conceito de reusabilidade teve força a partir do advento da orientação a objetos e tornou-se mais fortalecida com a evolução dos mesmos e a criação de conceitos como \textit{design patterns}. Os softwares de outras gerações costumavam ser acoplados e pouco coesos, tornando a manutenção e a evolução uma tarefa penosa. Com a evolução desses conceitos os projetistas mais experientes perceberam que determinadas soluções de projeto poderiam ser aplicadas em diferentes casos, logo, eles reusaram essas soluções. Com a ajuda dessas experiências de sucesso, o reuso de software tornou-se algo mais comum entre os projetistas de software.

17 Conceitos Preliminares Reusabilidade de Software - Objetivo
A reusabilidade pode ser considerada algo que irá prover ``informações ou serviços'' de programas que podem ser usados em múltiplas aplicações, tornando-se resposta importante aos problemas de produtividade de software.\begin{quote} Um dos principais objetivos do desenvolvimento de software orientado a objeto é o de melhorar a reusabilidade de componentes de software. Padrões de projeto devem ajudar a melhorar a reusabilidade. Aumentar a reusabilidade de software é considerada como precondição técnica crucial para melhorar o qualidade geral do software e reduzir os custos de manutenção e produção.~\citep{Pree1995}. \end{quote}

18 Conceitos Preliminares Reusabilidade de Software - Motivação
A reutilização de software se torna uma barreira para muitos programadores, pois em muitos casos os benefícios são percebidos a longo prazo fazendo com que a equipe fique desmotivada em desenvolver soluções reutilizáveis quando, em geral, a linha de tempo para o desenvolvimento de um software é curta. Existe também a barreira técnica, pois muitos programadores podem não entender o que reusar ou como reusar. Para se criar um projeto de software (padronizado) onde se justifique o uso das melhores práticas faz-se necessário um conhecimento acurado de orientação a objetos e \textit{design patterns} como também motivação e visão , a longo prazo, da equipe. No que se diz respeito à reutilização e flexibilidade, não existe meio termo. Ou se projeta de uma maneira concisa para que esse software seja adaptável e reutilizável ou não se projeta.

19 Design Patterns Após uma abordagem sucinta no que se refere a reusabilidade e orientação a objetos, estamos aptos a desenvolver uma boa abordagem sobre \textit{design patterns}.

20 Design Patterns Introdução
Design patterns vem ganhando grande aceitação como uma ferramenta para modelagem orientada a objetos Agostini2007, pois existem problemas de software que, embora estejam situados em contextos diferentes, podem ser solucionados de maneiras semelhantes. Fazendo com que problemas antigos, que foram já foram vivenciados pelos programadores mais experientes, serão catalogados e padronizados para evitar futuros problemas. Para Agostini2007 os patterns são estruturas classe que foram usadas por muitos anos e foram estabelecidos como soluções eficientes para muitos problemas.

21 Design Patterns Origem
\textit{Design Patterns}, também conhecidos como padrões de projeto, tiveram origem no conceito de reuso de software. Como já havia sido abordado anteriormente, o conceito de padrões de projeto foi criado no final da década de 70 pelo engenheiro civil Cristopher Alexander. Percebendo que todas as construções de edifícios possuíam algumas características em comum resolveu catalogar estas soluções em seu livro \textit{The Timeless Way of Building}. Na área de engenharia de software essas práticas foram adaptadas para a construção de sistemas de informação. Liderada por Erich Gamma a \textit{GoF} (\textit{Gang of Four}) - Erich Gamma, Richard Helm, Ralph Johnson a John Vlissides publicaram o livro \textit{Design Patterns: Elements of Reusable Object-Oriented Software}. O livro continha a descrição de 23 padrões para problemas que eram comumente encontrados durante o desenvolvimento de software.

22 Design Patterns Conceito
Um padrão pode ser definido como sendo um esboço, em vez da implementação específica, ou seja, um modelo a ser seguido durante a construção do software (Coad, 1995). As melhores práticas, de projetos antigos, são executadas visando que o esforço para evitar retrabalho seja mínimo. A principal proposta não está no fator tecnológico, mas sim em criar uma cultura na qual a catalogação de experiências e soluções para apoiar toda uma equipe de desenvolvimento de software seja algo importante e motivador. Com essas experiências já testadas e comprovadamente ideais, tem-se um vocabulário comum que permitirá uma melhor comunicação entre a equipe. Design Patterns são metodologias de construção de software comprovadamente funcionais que garantem legibilidade, manutenabilidade e reutilização de código-fonte no desenvolvimento de alguma aplicação computacional WELFER2005. Para fazer uma analogia sucinta pode-se usar o exemplo dado por Pree1995 “Motoristas aplicam um certo pattern para definir a transmissão manual do veículo em movimento. Este equilíbrio de embreagem e de combustível é aplicado não importando se o veículo for um Fusca ou um Porsche 959”. Fazendo um pequeno resumo do que foi digo anteriormente sobre design patterns, poderíamos dizer, de forma sucinta, que um design pattern “é uma solução para um problema em um determinado contexto” GAMMA1995, onde: Contexto se refere ao conjunto de situações, que se repetem, nas quais o design pattern pode ser aplicado; Problema se refere ao conjunto de “forças” (objetivos e limitações) que ocorrem dentro do contexto; Solução é uma estrutura formal para ser aplicada na resolução do problema. Segundo GAMMA1995 um padrão tem quatro elementos essenciais: O nome do padrão é uma referência que podemos usar para descrever um problema de projeto, suas soluções e consequências em uma ou duas palavras. O problema descreve em que situação aplicar o padrão; A solução descreve os elementos que compõem o padrão de projeto, seus relacionamentos, suas responsabilidades e colaborações; As consequências são os resultados e análises das vantagens e desvantagens da aplicação do padrão;

23 Design Patterns Classificação
Pode se classificar os padrões de projeto de várias maneiras, porém o mais comum é classificá-los de acordo com os tipos de problemas que eles resolvem. De acordo com esse critério, os padrões podem ser: Criação resolvem os problemas da criação de objetos; Comportamentais que lidam com os problemas de atribuição de responsabilidades aos objetos; Estruturais que lidam com os problemas de relacionamentos entre objetos;

24 Design Patterns Motivação
Design patterns têm vários usos no processo de desenvolvimento de software orientado a objetos (Schneide, 1999): Formam um vocabulário comum que permite uma melhor comunicação entre os desenvolvedores, uma documentação mais completa e uma melhor exploração das alternativas de projeto. Reduz a complexidade do sistema através da definição de abstrações que estão acima das classes e instâncias. Um bom conjunto de padrões aumenta muito a qualidade do programa; Constituem uma base de experiências reutilizáveis para a construção de software. Funcionam como peças na construção de projetos de software mais complexos; podem ser considerados como micro-arquiteturas que contribuem para arquitetura geral do sistema; Reduzem o tempo de aprendizado de uma determinada biblioteca de classes. Isto é fundamental para o aprendizado dos desenvolvedores novatos; Quanto mais cedo são usados, menor será o retrabalho em etapas mais avançadas do projeto.

25 Aplicação Prática Singleton
O pattern Singleton está entre um dos mais simples patterns a ser implementado, pois seu objetivo é apenas garantir que seja mantida somente instância de um determinado objeto. Ou seja, a própria classe garante que nenhuma outra instância seja criada, bem como oferece uma maneira de acessar sua própria instância. Uma das finalidades mais utilizadas pelo padrão Singleton é o acesso ao banco de dados de uma determinada aplicação, haja vista que pretendível evitar ao máximo o número conexões abertas em tempo de execução. A classe que utilizará o padrão Singleton para esta finalidade garantirá que somente uma conexão será usada e persistida durante o tempo de execução.

26 Aplicação Prática Factory
Existem certas situações em aplicações que, seja por uma intervenção humana ou por uma implementação mais complexa, o programador não saberá como o programa irá se comportar diante de uma determinada situação. Com isso, o programador pode não saber que classe deverá ser instanciada em determinado momento de uma aplicação. Para facilitar esse tipo de situação foi criado o pattern Factory. Segundo GAMMA1995 o pattern Factory pode ser usado nas seguintes situações: Uma classe não pode antecipar a classe de objetos que deve ser criada; Uma classe quer que suas subclasses especifiquem os objetos que ela cria; Classes delegam responsabilidades para uma dentre várias subclasses auxiliares, e se deseja localizar o conhecimento de qual subclasse auxiliar implementa a delegação.

27 Aplicação Prática Façade
O objetivo deste pattern é fornecer uma interface unificada para um conjunto de interfaces em um subsistema (Gamma et al., 1995). Ou seja, o pattern Façade é o isolamento entre camadas de um sistema, permitindo uma interface mais simples de comunicação entre essas camadas, como também um acoplamento baixo. A figura 2.2, abaixo , demonstra como a interface unificada minimiza a comunicação e as dependências entre os subsistemas que compõem a aplicação.

28 Referências