Coloque em foco a representação de arquitetura que irão orientar todos os demais aspectos do projeto. Procure investir o tempo neces-
sário para revisar cuidadosamente as documentações de arquitetura. Nesta fase, um erro poderá gerar um grande impacto negativo nas próximas fases do desenvolvimento do sistema.
Quando descrevemos a arquitetura de um sof- tware precisamos apresentar as características desejadas pelo cliente . Com isso, os desenvolve- dores querem uma orientação clara e precisa sobre
o projeto, e os clientes querem garantias de que esta arquitetura atenderá suas necessidades de negócios.
Para Sommerville (2011, p. 108) cada sistema é único, quando o domínio da aplicação é o mesmo, frequentemente possuem arquiteturas semelhantes, pois refletem os conceitos principais. Assim, é interessante ao projetar uma arquite- tura de sistema, decidir se o seu sistema vai ser uma aplicação com classes mais gerais e verificar o que tem em comum, e quais dessas você pode reusar.
Mas você deve estar se perguntando: porque seria interessante reusar? A reutilização é um aspecto fundamental para o desenvolvimento de um sistema, principalmente na fase de projeto. Muitos sistemas que já foram desenvolvidos e estão em uso, são similares a sistema que estão sendo desenvolvidos e muita das informações já usadas podem ser reutilizadas para solucionar problemas recorrentes no projeto.
“A arquitetura de software deve modelar a estrutura de um sistema, bem como a maneira por meio da qual dados e componentes procedurais cola- boram entre si.”
Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
A arquitetura de um software pode se basear em padrões ou estilos de arquite- tura. Conforme Sommerville, (2011, p. 108) “os padrões de arquitetura capturam a essência de uma arquitetura que tem sido usada em diferentes sistemas de sof- tware”. Assim, ao definir uma arquitetura de um sistema, você deve analisar os padrões mais comuns, quais os seus pontos fortes e fracos e como eles podem ser usados, pois um padrão é uma solução que já foi testada e aprovada para um problema em comum.
Pressman (2011, p. 235) define que o padrão de arquitetura ou estilo impõe muita transformação a um projeto de arquitetura de um sistema. Por sua vez, Sommerville (2011, p. 108) afirma que “a ideia de padrões como uma forma de apresentar, compartilhar e reusar o conhecimento sobre sistemas de software é hoje amplamente usada”. Contudo vamos pensar em um padrão de arquitetura somente em sistemas bem-sucedidos de sistemas desenvolvidos anteriormente. Afinal o que é um padrão? Um padrão é usado para descrever um problema que ocorreram repetidas vezes, e é usada uma solução para esse problema de forma que possamos reutilizar esta solução encontrada. Em outras palavras, eles são soluções para problemas que alguém algum dia teve, achou a solução aplicando um modelo que foi documentado e que agora você pode usar inte- gralmente ou de acordo com a sua necessidade.
O padrão mostra uma solução de arquitetura que ajuda a servir como base para o projeto da arquitetura. Conforme Sommerville (2011, p. 108) devemos pensar em padrão de arquitetura como uma descrição abstrata, que seja estili- zada, com boas práticas experimentadas e que tenham sido testadas em diferentes sistemas e ambientes e, com isso, incluir informações de uso desse padrão, para saber se ele é adequado e quais os seus pontos fortes e fracos.
A escolha do padrão arquitetural a ser usado deve estar associado ao tipo de sistema e seus requisitos não funcionais. Para ajudar na escolha podemos pensar em algumas perguntas: O sistema a ser desenvolvido é interativo? Ele vai possui muitas variações? Quais os requisitos não funcionais que podemos considerar importantes? E quanto a sua confiabilidade? E a sua adaptabilidade? Quando respondemos a estas perguntas, podemos perceber que na composi- ção de padrões, temos padrões diferentes que levam o projeto a consequências diferentes, mesmo quando os padrões abordam problemas semelhantes que são
Projeto da Arquitetura do Software Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
encontrados e em alguns padrões de projeto, sistemas complexos podem vir a possuir mais de um padrão arquitetural.
Nos próximos tópicos, vamos conhecer brevemente alguns padrões comu- mente que são usados em diferentes tipos de sistemas. Entre os padrões de arquitetura comumente usados estão: modelo-visão-controlador, arquitetura em camadas, repositório, cliente-servidor e duto e filtro.
Vamos aos padrões de arquitetura mais conhecidos:
MVC (Modelo-Visão-Controlador): esse padrão é considerado a base do gerenciamento de interações para muitos dos sistemas que são baseados em Web. Na descrição deste padrão você pode incluir o nome do padrão, uma descrição breve, podendo ser um modelo gráfico associado, exemplos de tipos de sistema em que este padrão pode ser usado novamente, suas vantagens e desvantagens.
Arquitetura em Camadas: este padrão de arquitetura é organizado em camadas separadas e em cada camada só depende dos recursos e serviços ofere- cidos pela camada que se encontra imediatamente abaixo dela. Esta arquitetura é considerada mutável e portável, pois enquanto ela não for alterada, a camada pode ser substituída por outra equivalente. Mas quando ela muda ou tem novos recursos adicionados, apenas a camada adjacente é afetada.
Arquitetura de Repositório: esse padrão de arquitetura descreve como um conjunto de componentes que estão interagindo podem compartilhar seus dados. Normalmente, os sistemas organizam os seus dados em torno de um banco de dados ou repositório compartilhado. Assim, este padrão é adequado para as aplicações nas quais os dados são gerados por um componente e usa- dos por outro. Um exemplo, um ambiente controlado por versões, que mantém o controle de todas as alterações do sistema e permite que seja feita a reversão para versões anteriores.
Arquitetura Cliente-Servidor: esse padrão de arquitetura é organizado em um conjunto de serviços e servidores associados e clientes que acessam e usam os serviços. Normalmente este padrão é utilizado em arquiteturas de sistemas distribuídos.
Arquitetura de Duto e filtro: esse padrão de arquitetura é um modelo de organização em tempo de execução de um sistema, com entradas e saídas de informações. Conforme Sommerville (2011, p. 114) “os dados fluem de um para
Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
o outro e transformam-se enquanto se movem por meio da sequência”. Assim, cada etapa desta transformação, é implementada como uma transformação.
Caro(a)Aluno(a) foram apresentados alguns dos padrões de arquitetura e descritos brevemente alguns que são comumente usados, mas existem outros. Para obterem mais informações sobre os padrões de arquitetura recomendo que leiam o Saiba Mais. Boa leitura!
Depois do aprofundamento no Saiba Mais, vamos para o próximo tópico onde vamos conhecer o Projeto de componentes e seus conceitos. Bons estudos!
Um padrão de arquitetura, assim como um estilo arquitetural, impõe trans- formação no projeto de arquitetura. Entretanto, padrão difere de estilo em alguns modos fundamentais: (1) o escopo de um padrão é menos abran- gente, concentrando-se em um aspecto da arquitetura e não na arquitetu- ra em sua totalidade; (2) um padrão impõe uma regra sobre a arquitetura, descrevendo como o software irá tratar algum aspecto de sua funcionali- dade em termos de infraestrutura os padrões de arquitetura tendem a tra- tar questões comportamentais específicas no contexto da arquitetura (por exemplo, como as aplicações em tempo real tratam a sincronização ou as interrupções). Os padrões podem ser usados com um estilo de arquitetura para dar forma à estrutura global de um sistema. Um estilo arquitetural é uma transformação imposta no projeto do sistema inteiro. O objetivo é es- tabelecer uma estrutura para todos os componentes do sistema.
Fonte: Pressman (2011).
Como projetista, trabalhe arduamente para derivar tanto as abstrações pro- cedurais quanto a de dados que atendam ao problema em questão. Se elas puderem atender um domínio inteiro dos problemas, tanto melhor.
©shutterstock Projeto de Componentes Repr odução pr oibida. A rt . 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
PROJETO DE COMPONENTES
Conforme Pressman (2011, p. 257) “o projeto de componentes ocorre depois da primeira iteração do projeto de arquitetura tiver sido completa”. Para ele, o conjunto completo de componentes de software é definido durante o projeto de arquitetura. O projeto de componentes procura detalhar as estruturas de dados, definir os algoritmos, as características da interface que serão usadas, os meca- nismos de comunicação que serão alocados para cada um dos componentes do software.
Quem realiza as atividades do projeto de componentes é o Engenheiro de Software. Você deve estar se perguntando: Qual a importância do projeto de componentes no desenvolvimento do software? Bem, nesta fase, ao analisar o projeto até aqui você já deve ser capaz de determinar se o software irá funcionar ou não, antes que ele seja implementado. Certo? Pois o projeto de componen- tes é usado para representar o software de uma forma que possamos “revisar” os detalhes, como as estruturas de dados definidas, as interfaces e se os algorit- mos irão funcionar.
A base do projeto de componentes é formada pelas representações de projeto de dados, de arquitetura e de interface. Uma dica interessante, é que normal- mente é possível fazer uso de componentes de software reutilizáveis, ao invés
Repr odução pr oibida. A rt. 184 do C ódigo P enal e L ei 9.610 de 19 de f ev er eir o de 1998.
de implementar novos. O principal artefato utilizado durante o projeto de com- ponentes são que cada componente, pode ser representado em notação gráfica, tabular ou baseado em texto.
Para Pressman (2011, p. 258) não importa o tipo de mecanismo que será utilizado para representar o projeto de componentes, as estruturas de dados, as interfaces e os algoritmos definidos, pois eles devem atender a uma série de metas de projeto bem fundamentadas que vão auxiliam a evitar erros à medida que o projeto evolui.
Mas o que é um componente de software? Conforme Gimenes e Huzita (2005) é uma unidade de software independente que encapsula, seu projeto e a imple- mentação, oferecendo serviços, por meio de interfaces definidas, que serão usadas para o meio externo. Pressman (2011) define que um componente é um bloco construtivo modular para ser usado em software de computador e com relação à orientação a objetos, um componente é um conjunto de classes colaborativas. Um componente é considerado uma unidade independente que pode ser utilizado junto com outros componentes, formando um sistema mais complexo. No entanto o significado de componente vai depender do ponto de vista do res- ponsável pelo projeto de componentes, o engenheiro de software. Mas qual seria este ponto de vista? Conforme Pressman (2011) temos três pontos de vistas que são utilizados. São eles:
Visão Orientada a objetos: um componente é um conjunto de classes cola- borativas ou podem ter um componente com uma única classe.
Visão Tradicional: para essa visão, um componente é o elemento funcio- nal de um programa que incorpora a lógica de processamento, as estruturas de dados e uma interface que habilita o componente para que os dados sejam for- necidos a ele.
Visão relacionada com processos: um componente é utilizado a partir da reusabilidade, ou seja, que façamos o uso de componentes de software ou de padrões de projeto já existentes.