Arquitetura de Software

Outro elemento cognitivo evidenciado durante a pesquisa documental relaciona-se às orientações disponibilizadas ao fornecedor sobre a maneira que os SI devem ser construídos e mantidos, definindo então a arquitetura de software em uso no ambiente da organização pública.

O conhecimento da arquitetura de um sistema permite a identificação de suas propriedades mais importantes (BASS; CLEMENTS; KAZMAN, 2003), auxiliando cliente e fornecedor no estabelecimento do esforço necessário para a manutenção evolutiva de softwares (ROSES, 2007), bem como na construção de novos projetos. A arquitetura pode ser considerada a representação que permite à engenharia de software analisar a efetividade do projeto em satisfazer os seus requisitos. Considerar alternativas arquiteturais em uma fase em

que fazer modificações de projeto ainda é relativamente fácil potencializa a redução dos riscos associados à construção do software (PRESSMAN, 2006).

Para Pressman (2006), padrões arquiteturais definem uma estrutura global do software, indicam o relacionamento entre subsistemas e componentes do software e definem as regras para especificar o relacionamento entre os elementos (classes, pacotes, componentes, subsistemas) da arquitetura. Esses elementos definem estilos arquiteturais que descrevem categorias de sistemas que possuem: 1) um conjunto de componentes (banco de dados, módulos computacionais); 2) um conjunto de conectores que viabiliza a comunicação entre os componentes; 3) regras que determinam como os componentes são integrados para compor o sistema; e 4) modelos semânticos, que descrevem as propriedades gerais do sistema (BASS; CLEMENTS; KAZMAN, 2003).

Sommerville (2007) comenta que a essência de um projeto de software é a tomada de decisões sobre a organização lógica do software. Nesse sentido, o projeto de arquitetura é o primeiro estágio no processo de projeto e representa a ligação entre os processos de engenharia de projeto e de requisitos. Bass et al. (2003) apresenta a arquitetura de sistemas como o resultado de um conjunto de decisões técnicas e de negócios, sendo seu desenho elaborado de acordo com o ambiente requerido para a arquitetura. Os autores discorrem sobre a importância da arquitetura, tendo em vista que durante o esforço no desenvolvimento de software, os requisitos explicitam apenas parte das propriedades desejadas, e esperadas, pelo aplicativo. Isso se deve ao fato de que nem todos os requisitos preocupam-se diretamente com essas propriedades – que normalmente são atendidas pelo PS – e o não atendimento adequado dessas propriedades poderá resultar em um aplicativo com desempenho insatisfatório.

As vantagens de se projetar e documentar uma arquitetura de software são apresentadas por Bass et al. (2003):

• Base de comunicação entre stakeholders: a arquitetura de software representa uma abstração de um sistema baseado em computador que permite o seu uso como base de entendimento e comunicação entre todos os envolvidos no projeto;

• Fonte de visualização do projeto: a arquitetura de software destaca as primeiras informações e decisões sobre o desenho do sistema, o que favorece a tomada de decisão a respeito do projeto, influenciando no ciclo de desenvolvimento, entrega e manutenção do software;

• Modelo de abstração reutilizável: a arquitetura de software se constitui em um modelo compreensível sobre como o sistema está estruturado e como seus

elementos trabalham conjuntamente, sendo esse modelo transferível entre sistemas;

São cinco as arquiteturas de sistemas mais utilizadas (PRESSMAN, 2006), a saber: 1) arquitetura centrada nos dados; 2) arquitetura de fluxo de dados; 3) arquitetura de chamada e retorno; 4) arquitetura orientada a objetos; e 5) arquitetura em camadas.

A arquitetura centrada nos dados baseia-se na existência de um banco de dados (arquivo, repositório ou SGBD51) como componente principal, a partir do qual os demais componentes irão orbitar, extraindo desse banco os dados necessários para o funcionamento do sistema. A Figura 15 apresenta um exemplo da arquitetura centrada nos dados.

Figura 15 - Arquitetura centrada nos dados

Fonte: Pressman (2006), adaptado pelo Autor.

A arquitetura de fluxo de dados tem sua estrutura baseada em filtros e tubos, onde os filtros são os componentes de software, que se comunicam (transmissão de dados) com outros componentes por meio de tubos. Cada componente trabalha de forma independente dos demais e é projetado para receber dados de uma forma e produzir dados de saída (para o componente seguinte) de uma forma específica. Essa arquitetura é utilizada quando há a necessidade de transformação, ou manipulação, dos dados de entrada em uma série de componentes computacionais. A Figura 16 apresenta um modelo da arquitetura de fluxo de dados.

Figura 16 - Arquitetura de fluxo de dados

Fonte: Pressman (2006), adaptado pelo Autor.

A arquitetura de chamada e retorno tem como principal característica a facilidade de modificação – ampliação – do sistema. Ela pode ser elaborada sob o preceito “programa principal/subprograma”, onde um programa principal aciona certo número de componentes de programas, que também podem acionar outros componentes; e sob o preceito “chamada de procedimentos remotos”, onde os componentes do programa principal/subprograma são distribuídos entre vários computadores em uma rede. A Figura 17 apresenta a arquitetura de chamada e retorno na configuração ‘programa principal/subprograma’.

Figura 17 - Arquitetura na configuração ‘programa principal/subprograma’

Fonte: Pressman (2006), adaptado pelo Autor.

Na arquitetura orientada a objetos, os componentes de um sistema encapsulam os dados e as operações que devem ser aplicadas para manipular os dados, sendo a comunicação e a coordenação entre os componentes obtida por meio de passagem de mensagens. Os processos de projetos orientados a objetos envolvem o projeto de classes de objeto e os relacionamentos entre essas classes, que definem os objetos do sistema e suas interações (SOMMERVILLE, 2007). A Figura 18 ilustra uma arquitetura orientada a objetos.

Figura 18 - Arquitetura orientada a objetos

Fonte: Sommerville (2007), adaptado pelo Autor.

A arquitetura em camadas, ilustrada na Figura 19, tem como estrutura básica a definição de um número predeterminado de camadas, onde na camada mais interior, os componentes realizam a interface com o sistema operacional. A camada mais exterior possui os componentes que realizarão a interface com o usuário. As camadas intermediárias fornecem os demais serviços que viabilizam o funcionamento da aplicação.

Figura 19 - Arquitetura em camadas

Fonte: Pressman (2006), adaptado pelo Autor.

O excerto extraído do edital INEP-011/2010 evidencia o estabelecimento da arquitetura de software a ser seguida pelo fornecedor, destacando-se em negrito as expressões de maior relevância:

1. Introdução 1.1. Finalidade

Este documento pretende apresentar uma visão geral das arquiteturas de sistemas

Java e PHP utilizadas no Inep. Ele deve ser usado como uma referência para construção de novos sistemas e fonte de consultas em relação ao padrão de

arquitetura utilizada no Inep. O mesmo também deve servir como insumo para a elaboração do documento de arquitetura do projeto, artefato descrito na MGDS (Metodologia de Gestão e Desenvolvimento de Sistemas).

1.2. Escopo

O documento aplica-se aos sistemas do Inep (desenvolvidos internamente ou externamente), em que as linguagens de programação sejam Java e PHP.

1.3. Evolução deste guia Este guia foi construído baseado nas experiências dos projetos anteriores do Inep e assim sendo pode e deve ser continuamente adequado / adaptado conforme as lições aprendidas e as evoluções tecnológicas que surgirem no mercado.

2. Representação da Arquitetura

A arquitetura de um sistema é o alicerce onde se funda o software. A partir dos modelos, camadas, abstrações e frameworks apresentados e sugeridos, o projetista e o desenvolvedor do sistema têm uma visão geral, técnica e conceitual da aplicação que será construída. A arquitetura define, entre outras coisas, onde implementar regras de negócios, onde e como persistir informações e as tecnologias que devem ser utilizadas. Cabe aos projetistas e desenvolvedores adaptar os requisitos funcionais do sistema às definições da arquitetura.

Não faremos referência a projetos específicos, já que seu objetivo é definir uma arquitetura geral de desenvolvimento Java e PHP.

Não é raro ainda, que alguns projetos venham a necessitar de mais camadas do que as aqui descritas, mas essa decisão deve ser feita juntamente com a equipe técnica do Inep, preferencialmente no início do projeto.

O Guia de Arquitetura será divido em duas partes, sendo elas: Parte I – Arquitetura Java Web;

Parte II – Arquitetura PHP.

3. Metas e Restrições da Arquitetura

A arquitetura aqui definida, prima pela simplicidade e produtividade, fazendo uso de tecnologias que permitam a criação de softwares robustos, confiáveis e de fácil manutenção.

Apesar das camadas descritas no documento, serem possíveis de serem implementadas em vários frameworks, o framework recomendado para o desenvolvimento das aplicações PHP é o Zend Framework (versão homologada pelo Inep), tendo em vista a maturidade desse framework no meio empresarial.

Para aplicações Java acessadas via browser (aplicações WEB) deve ser utilizado o MECSeam, framework do Inep para aplicações WEB, baseado no Framework Seam (versão homologada pelo Inep). Ainda não possuímos um Framework para desenvolvimento de aplicações Desktop, caso exista alguma demanda para este tipo de aplicação, entre em contato com a equipe técnica do Inep.

Por padrão, o Inep utiliza a versão 1.6 do Java (JEE).

No desenvolvimento de WebServices, o padrão e-Ping deve ser respeitado, segue link de referência deste padrão: http://www.governoeletronico.gov.br/acoes-e- projetos/e-ping-padroes-deinteroperabilidade.

Assim, o estabelecimento de um projeto arquitetural tem o potencial de padronizar a maneira como os softwares serão construídos, contribuindo positivamente para a melhoria da qualidade dos produtos desenvolvidos.