Arquitetura de Software e Padrões de Projeto - apontes77/projetoApp_CMP1118 GitHub Wiki

Arquitetura de Software

A arquitetura de software representa a(s) estrutura(s) do sistema, que consiste nos componentes de software, nas propriedades externamente visíveis desses componentes e nos relacionamentos entre eles. Uma forma sem dúvida que contribui para a obtenção na qualidade de projetos de software são os padrões de projetos, em inglês "design patterns".

Introdução

Atualmente não se concebe um processo de desenvolvimento de software sério sem a utilização da orientação a objetos, pois esta permite agregar qualidades importantes aos sistemas desenvolvidos sob seus paradigmas, com a extensibilidade e a reusabilidade. Mas somente por estar utilizando-a, não é garantia de se obter essas qualidades. Para criar as melhores soluções, é preciso seguir um processo detalhado para obter uma análise dos requisitos, funcionais ou não funcionais, e desenvolver um projeto que os satisfaça e que possibilite submetê-los a teste, para constatar eventuais falhas, além do mais se deseja que o projeto tenha uma arquitetura flexível para acomodar futuros problemas e requisitos sem a necessidade da realização do re-projeto.

Uma coisa que os projetistas avançados sabem que não devem fazer é resolver cada problema a partir de princípios elementares ou do zero. Ao invés disso, eles reutilizam soluções que funcionaram no passado, e os utilizam repetidamente em seus projetos. É como resolver um problema matemático até então inédito, ou pelo, menos desconhecido a alguém. Primeiro utiliza-se todos os conhecimentos e princípios matemáticos que se tem conhecimento e que venha a ser útil na solução, depois de algumas tentativas e uso das teorias matemáticas, chega-se à solução e a partir daí tem-se um “algoritmo” (estrutura) montado que pode ser utilizado para resolver tantos problemas existirem e que sejam idênticos ao resolvido, e mesmo que não seja, é possível reaproveitar as idéias e conclusões do problema resolvido. É por isso que os padrões de projetos,design patterns, tem chamado a atenção e despertado o interesse dos projetistas de software, por proporcionar elementos que conduzem ao reaproveitamento de soluções para projetos, e não apenas a reutilização de código.

Os padrões de projetos tornam mais fácil reutilizar soluções e arquiteturas bem sucedidas para construir softwares orientados a objetos de forma flexível e fácil de manter. O uso de padrões de projeto pode reduzir a complexidade do processo de projetar software. Além disso, o software orientado a objetos bem projetado possibilita aos projetistas reutilizar e empregar componentes preexistentes em sistemas futuros.

Em software, os padrões de projeto não são classes nem objeto. Em vez disso, os projetistas usam esses padrões para construir conjuntos de classes e objetos. Para utilizá-los de maneira eficaz, os projetistas precisam se familiarizar com os padrões mais populares e eficazes utilizados pela engenharia de software e conhecer o seu contexto e escopo.

Definindo padrões de projeto

Definir o que é um padrão de projeto de maneira clara e objetiva, tem sido o objetivo da comunidade de software, desde a década de 80.O primeiro a apresentar uma definição do que seria um padrão, foi o arquiteto de professor Christopher Alexandre, no seu livro “A Times Way of Building” (Oxford University Press, 1979), que é: “Cada padrão é uma regra de três partes, que expressa uma relação entre um certo contexto, um problema e uma solução”. Sendo assim para entender a necessidade, existência, de um padrão é necessário estudar suas partes: o problema, a solução e o contexto sobre o qual ele é aplicável.

Entretanto, se tivermos uma solução para um problema em um certo contexto, ela não necessariamente pode constituir um padrão, pois é necessário que ela tenha como característica a regularidade, isto é, ela se constituirá como um padrão se puder ser utilizada repetidamente. Segundo Christopher Alexander, “cada padrão descreve um problema no nosso ambiente e o núcleo da sua solução, de tal forma que você possa usar esta solução mais de um milhão de vezes, sem nunca faze-lo da mesma maneira”.

Características de um padrão de projeto

Embora um padrão seja a descrição de um problema, de uma solução genérica e sua justificativa, isso não significa que qualquer solução conhecida para um problema possa constituir um padrão, pois existem características obrigatórias que devem ser atendidas pelos padrões:

1. Devem possuir um nome, que descreva o problema, as soluções e conseqüências. Um nome permiti definir o vocabulário a ser utilizado pelos projetistas e desenvolvedores em um nível mais alto de abstração.

2. Todo padrão deve relatar de maneira clara a qual (is)problema(s) ele deve ser aplicado, ou seja, quais são os problemas que quando inserido em um determinado contexto o padrão conseguirá resolve-lo.Alguns podendo exigir pré-condições.

3. Solução descreve os elementos que compõem o projeto, seus relacionamentos, responsabilidades e colaborações. Um padrão deve ser uma solução concreta, ele deve ser exprimido em forma de gabarito (algoritmo) que, no entanto pode ser aplicado de maneiras diferentes.

4. Todo padrão deve relatar quais são as suas conseqüências para que possa ser analisada a solução alternativa de projetos e para a compreensão dos benefícios da aplicação do projeto.

Quando os padrões não o ajudarão

Os padrões são um mapa, não uma estratégica. Os catálogos geralmente apresentarão algum código-fonte como uma estratégica de exemplo, portanto eles não devem ser considerados como definitivos. Os padrões não ajudarão a determinar qual aplicação você deve estar escrevendo apenas como implementar melhor a aplicação assim que o conjunto de recursos e outras exigências forem determinados. Os padrões ajudam com o que e como, mas não com por que ou quando.

O conceito de utilizar os padrões de forma indiscriminada é conhecida como antipadrões (anti patterns). De acordo com Andrew Koenig, se um padrão representa a “melhor prática”, então um antipadrão representa uma “lição aprendida”.

Existem duas noções de antipadrões:

1. Aqueles que descrevem uma solução ruim para um problema que resultou em uma situação ruim;
2. Aqueles que descrevem como se livrar de uma situação ruim e como proceder dessa situação para uma situação boa.

Como selecionar um padrão de projeto

Escolher dentre os padrões existentes aquele que melhor soluciona um problema do projeto, sem cometer o erro de escolher de forma errônea e torná-lo inviável, é uma das tarefas mais difíceis. Em suma, a escolha de um padrão de projeto a ser utilizado, pode ser baseada nos seguintes critérios:

Considerar como os padrões de projeto solucionam problemas de projeto.
Examinar qual a intenção do padrão, ou seja, o que faz de fato o padrão de projeto, quais seus princípios e que tópico ou problema particular de projeto ele trata (soluciona).
Estudar como os padrões se relacionam.
Estudar as semelhanças existentes entre os padrões.
Examinar uma causa de reformulação de projeto.
Considerar o que deveria ser variável no seu projeto, ou seja, ao invés de considerar o que pode forçar uma mudança em um projeto, considerar o que você quer ser capaz de mudar sem reprojetá-lo.

Referência: http://mds.cultura.gov.br/core.base_rup/guidances/concepts/software_architecture_4269A354.html