Olá, estudante! Pronto(a) para dar mais um passo em nossa jornada pelo universo da programação? Agora que você já possui uma boa compreensão sobre o ciclo de vida de um software, é hora de retomar o conceito de arquitetura e se aprofundar em um tema essencial para sua carreira profissional.

Nesta lição, damos continuidade ao que foi abordado nas lições anteriores e nosso objetivo é que você entenda os principais conceitos relacionados à arquitetura de software. Você irá perceber a importância do projeto de arquitetura de software, compreender as decisões estratégicas necessárias durante a construção de um projeto de arquitetura e descobrir que existem diferentes padrões de arquitetura, que variam de acordo com o tipo de sistema ou aplicação.

Com esse conhecimento, você estará ainda mais preparado(a) para sua futura carreira profissional! Vamos lá?

Nas lições anteriores, você compreendeu que a elicitação e análise de requisitos exigem um processo cuidadoso para definir os serviços que o sistema deve ter, como também identificar as restrições relativas à operação e ao desenvolvimento do sistema. Nesse processo, a compreensão da "dor do cliente" e de suas necessidades devem ser traduzidas para requisitos funcionais e não funcionais. 

Ao final desse processo, deve-se produzir um documento conforme discussões realizadas entre o cliente e a equipe de desenvolvimento. Esse documento deve especificar um sistema que satisfaça os requisitos dos stakeholders (interessados no projeto). Além disso, a especificação dos requisitos deve possuir uma declaração de requisitos em alto nível para usuários finais, atendendo as necessidades dos clientes, e uma especificação mais detalhada do sistema para desenvolvedores do sistema. 

Essa especificação detalhada é muito importante para garantir a continuação do processo de desenvolvimento de software, pois contém informações mais técnicas, tais como: definição de como deve ser gerado o banco de dados, como será a comunicação com outros sistemas e, assim, por diante.  Nesta lição, você compreenderá a importância dessa especificação e como isso deve ser feito.

Antônia se formou como Técnica de Desenvolvimento de Sistemas e é analista júnior de sistemas, em uma empresa de informática. No início, ela realizou atividades referentes à "Elicitação e Análise de requisitos", mas, com o passar do tempo, ela começou a se questionar sobre a etapa seguinte do projeto, mais especificamente a que era denominada por "Projeto de arquitetura". 

Antônia procurou compreender como uma arquitetura de sistema deve ser modelada. Ela descobriu que é por meio de diagramas composto por blocos. Nos diagramas, cada caixa representa um componente; toda seta indica que os dados ou sinais de controle são enviados de um componente para outro, conforme direção das setas; caixas dentro de caixas representam um componente que foi decomposto em subcomponentes.

Curiosa, Antônia procurou entender o modelo de um sistema de controle robotizado de empacotamento. Ela compreendeu que era um modelo abstrato da arquitetura e que apresentava tanto os componentes que precisam ser desenvolvidos quanto os relacionamentos existentes entre esses, conforme apresentado na Figura 1.

Analisando o modelo com mais cuidado, a Antônia percebeu que o sistema possui um componente "visão" (que seleciona os objetos em uma esteira) ligado a outro componente "identificação de objetos" (que identifica o tipo de objeto) para, posteriormente, selecionar o tipo correto de empacotamento através de um componente composto por "seleção de empacotamento" e "empacotamento". Existe um componente para retirar objetos da esteira de entrega para serem empacotados; ou para colocar os objetos empacotados em outra esteira. Finalmente, os objetos são retirados e colocados por um componente composto por "controlador de braço" e "controlador de garra".

Antônia conclui que a arquitetura de software é importante! Se os componentes e a relação entre eles não forem bem planejados, o modelo pode afetar o desempenho, a robustez, a capacidade de distribuição e de manutenção do sistema.

Independente do modelo do processo de desenvolvimento de software, o projeto de arquitetura é o primeiro estágio na construção do projeto de software, conforme apresentado na Figura 2.  É considerado o elo da fase "Elicitação e Análise de Requisitos" com a fase "Projeto", pois esse identifica os principais componentes estruturais de um sistema e seus relacionamentos.

É muito complicado este conceito? Vamos, pouco a pouco, compreender melhor.

Pressman (2011) diz que a construção de um projeto exige decisões importantes sobre a natureza estrutural do sistema, onde deve-se abstrair a representação de informação e as sequências de processamento. Este mesmo autor diz que o projeto de arquitetura permite que a construção de programas ocorra com maior qualidade e, por consequência, a codificação pode refinar os detalhes de alto nível apresentados no projeto.

Você já está refletindo como a fase de "Elicitação e Análise de requisitos" influencia a construção do projeto? Espero que sim!

Sommerville (2011) indica que todo componente individual implementa algum requisito funcional do sistema, e que todo requisito não funcional depende da forma como os componentes estão organizados e se comunicam (ou seja, a arquitetura do sistema). Este mesmo autor salienta que todo requisito não funcional é influenciado pelos componentes individuais; contudo o que influencia é a arquitetura do sistema.  Além disso, este mesmo autor salienta que:

Finalmente, Sommerville (2011) salienta que, devido à estreita relação entre a arquitetura do software e os requisitos não funcionais, a estrutura da arquitetura e o estilo que serão escolhidos para um sistema depende dos requisitos não funcionais do sistema, conforme os exemplos abaixo apresentados:

1. Desempenho: o projeto de arquitetura deve localizar as operações críticas em um número pequeno de componentes, cuidando para que esses componentes sejam implantados em um mesmo computador, ao invés de serem distribuídos pela rede. Isso significa que alguns componentes podem ficar consideravelmente grandes, ao invés de terem baixa granularidade; mas há redução do número de comunicações entre eles. Uma solução é organizar um sistema de runtime para permitir que o sistema seja executado em processadores diferentes.

2. Proteção: deve projetar uma arquitetura em camadas, em que os ativos mais críticos ficam protegidos nas camadas internas via validação de proteção aplicada nestas camadas.

3. Segurança: operações relacionadas com segurança devem estar em um componente ou um pequeno número de componentes. Isso reduz os problemas de validação de segurança e os custos, tornando possível o fornecimento de sistemas de proteção que, em caso de falha, podem desligar o sistema de maneira segura.

4. Disponibilidade: o projeto deve incluir componentes redundantes para que se possa substituir e atualizar os componentes, sem haver necessidade de parar o sistema.

5. Manutenção: um projeto com componentes autocontidos e com baixa granularidade podem ser rapidamente alterados. Deve-se ter o cuidado de separar os produtores de dados dos consumidores, e evitar estruturas de dados compartilhadas.

Chegamos ao fim da nossa lição, conto que você tenha compreendido a importância de definir a arquitetura do software e quais são as decisões necessárias sobre a arquitetura de sistema, durante a construção do projeto de arquitetura. Não esqueça que existem padrões de arquitetura que são usados em diferentes tipos de sistemas de aplicações. 

Dando continuidade aos nossos estudos, iniciaremos agora a parte prática, em que veremos, por meio de um exemplo do mundo real, a aplicação dos conceitos abordados até aqui. Para isso, farei uso de um “spoiler”: vou introduzir brevemente dois temas que serão aprofundados mais adiante — Elicitação e Análise de Requisitos. Não se preocupe em memorizar esses conceitos agora. Por ora, é importante apenas saber que eles são etapas fundamentais no desenvolvimento de software. Envolvem o processo de coleta de informações sobre os requisitos do sistema, além da identificação das necessidades e expectativas dos usuários, clientes ou demais pessoas que utilizarão as soluções desenvolvidas. Quando examinamos e refinamos os requisitos levantados na etapa de elicitação e os transformamos em requisitos funcionais e não funcionais, estamos realizando a análise de requisitos.

Para esta atividade, o desafio consiste em reaproveitar o exemplo da Seção 3, referente ao estudo de caso, e utilizá-lo como base. No entanto, em vez de um sistema robótico de visão computacional, consideraremos um sistema de controle de iluminação.

Imagine um sistema de controle de iluminação para um ambiente, como uma sala de estar ou um quarto. Por ser um sistema simples, ele é composto por apenas dois componentes principais:

Se representarmos esse sistema em um diagrama, teremos a seguinte configuração: 

Observe que o projeto de arquitetura está sendo representado por um diagrama de blocos simples. Em diagramas como esse, cada caixa representa um componente. No nosso exemplo do Saiba Aplicar, usamos um modelo simplificado. No entanto, em sistemas mais complexos, podemos encontrar representações com caixas dentro de caixas, o que indica a decomposição de um componente em subcomponentes. As setas, por sua vez, indicam a transmissão de dados e/ou sinais de controle entre os componentes, na direção apontada.

Ao final desta lição, espero que você seja capaz de desenvolver uma visão abstrata de sistemas, conseguindo compreender de forma ampla e integrada os módulos e componentes considerados na concepção de um projeto. Recomendo observar outros projetos de software e trocar ideias com seus colegas, a fim de ter contato com diferentes pontos de vista e verificar se suas percepções e entendimentos estão alinhados com o conteúdo abordado nesta lição.