S IMULATION NUMERIQUE D ’ UN ESSAI DE MIGRATION

Um dos artefatos mais relevantes no processo de construção de software consiste na AS. A referência a este termo, imediatamente remete à analogia existente com a arquitetura tradicional, responsável pelo projeto e construção de edificações. No en- tanto, quando melhor analisadas, é possível perceber que estas duas áreas possuem princípios distintos. A Tabela 1 evidencia estas diferenças.

Tabela 1 – Comparação entre Arquitetura e AS.

Arquitetura Tradicional Arquitetura de Software

Decisões são tomadas antes do início da cons-

trução. As tomadas de decisões ocorrem em qualquermomento.

Resultado final obtido é sólido e estático (edifi-

cação). O resultado final é maleável (software).

Projeto que não acolhe mudanças estruturais

após finalizado. O projeto acolhe mudanças, uma vez que é pos-sível modificar o produto final, tanto por ques- tões de performance quanto tecnológicas. Fonte: Adaptado de HUNT; THOMAS (1999).

Sob esta perspectiva, HUNT; THOMAS (1999) relacionam o desenvolvimento de arquitetura à jardinagem. Ou seja, assim como as plantas em um jardim, o software (e sua arquitetura) está sempre em evolução, já que, além de ser difícil planejá-lo, ele é dependente de manutenção contínua. Deixando essas constatações à parte, exis- tem várias conceituações utilizadas para definir o termo AS. FOWLER (2003) destaca uma ponderação feita por Ralph Johnson1 _{na qual ele declara que na maioria dos}

projetos de software bem-sucedidos, os seus desenvolvedores têm uma compreen- são compartilhada do design do sistema. Esta percepção é chamada de arquitetura. Este entendimento compartilhado inclui como o sistema é dividido em componentes e como estes interagem entre si.

Outra definição que corrobora e compartilha elementos deste conceito é apresen- tada por BASS; CLEMENTS; KAZMAN (2012):

"A arquitetura de software de um programa, ou sistema computacional, é a estrutura (ou estruturas) de um sistema, que inclui os elementos de software, as propriedades externamente visíveis destes elementos, e os relacionamentos entre eles".

1_{Um dos autores de Design Patterns: Elements of Reusable Object-Oriented Software (GAMMA}

Uma AS se caracteriza por seguir um estilo ou tipo arquitetural, ou seja, uma cole- ção de princípios utilizados para atingir um objetivo. Este estilo descreve um conceito geral que busca prover uma estrutura abstrata de funcionamento para uma aplicação ou um conjunto delas (PATTERNS, 2009).

Cada tipo possui especificações que determinam componentes, relacionamentos, restrições e suposições de como estas partes são interconectadas. Assim, um tipo de arquitetura promove a reutilização do design, fornecendo soluções para problemas recorrentes. A Tabela 2 destaca os principais estilos arquiteturais de software.

Tabela 2 – Tipos de arquiteturas de software mais comuns.

Tipo Descrição

Cliente-Servidor. Sistema dividido em duas camadas, onde o cliente faz

requisições ao servidor.

Baseada em Componentes. Aplicação é decomposta em componentes, os quais

expõe interfaces de comunicação bem definidas.

Em camadas. Separa as responsabilidades da aplicação em cama-

das.

N-tier. Também separa funcionalidades em camadas, no en-

tanto elas estão fisicamente distribuídas.

Service-Oriented Architecture (SOA). Aplicações que expõem e consomem funcionalidades

como um serviço.

Orientada a Objetos. Divide uma aplicação em objetos individuais reutilizá-

veis, com dados e comportamentos próprios. Fonte: Adaptado de PRESSMAN; MAXIM (2016).

Existe uma série de fatores que podem influenciar o tipo de arquitetura escolhido para um determinado projeto. Dentre eles podem ser destacados: a capacidade e experiência do time de desenvolvimento; os recursos tecnológicos disponíveis; e as restrições de ambiente e infraestrutura.

É possível combinar diversos estilos arquiteturais para compor uma solução mais completa e robusta. É factível, por exemplo, a estruturação de uma arquitetura em camadas, as quais possuem internamente diversos componentes, os quais por sua vez, são desenvolvidos como serviços ou de forma orientada a objetos.

Assim, dependendo do tamanho, quantidade de componentes e atores envolvidos em um projeto, uma AS pode ficar bastante complexa. Para facilitar sua compre- ensão, a AS pode ser representada em vários níveis, conforme a necessidade de apresentar (ou esconder) detalhes do projeto às pessoas que desempenham diferen- tes papéis ou que possuem expertises heterogêneas em uma organização. Pensando nisso, BROWN (2013) propõe a utilização do modelo C4 (Contexto, Contêineres, Com- ponentes e Classes/Código), um conjunto de diagramas que possuem diferentes pro- pósitos e níveis de abstração.

A Figura 4 destaca um exemplo de diagrama de Contexto. Como o seu próprio nome revela, ele apresenta a contextualização da solução, destacando a aplicação ao centro, cercada por possíveis usuários, módulos ou sistemas que interagem de alguma forma com o software proposto. É um diagrama de alto nível que pode ser utilizado como ponto de partida para discussões, permitindo identificar com quem é preciso conversar até a compreensão da solução.

Figura 4 – Exemplo de diagrama de Contexto, segundo o modelo C4.

Fonte: BROWN (2013).

Já o diagrama de Contêineres, destaca as escolhas tecnológicas feitas no projeto, evidenciando onde cada componente da aplicação será executado. Utilizado como elo entre os diagramas de contexto e de componentes. A Figura 5 apresenta um exemplo deste tipo de diagrama.

As outras duas representações propostas pelo modelo C4 são os diagramas de Componentes e Classes. Estes diagramas são mais voltados às equipes de desenvol-

Figura 5 – Exemplo de diagrama de Contêineres, segundo o modelo C4.

vimento, já que apresentam especificidades do projeto de software. A Figura 6 destaca um exemplo de diagrama de Componentes, representação pela qual uma aplicação é dividida em elementos com responsabilidades e dependências específicas.

Figura 6 – Exemplo de diagrama de Componentes, segundo o modelo C4.

Fonte: BROWN (2013).

Por fim, o diagrama de Classes é o último proposto pelo modelo C4. Seu objetivo é apresentar detalhes de implementação, focando nas estruturas internas dos compo- nentes de software. A Figura 7 apresenta um exemplo desta forma de representação. A ideia do C4 é que a utilização de um número maior de diagramas simplificados facilite o entendimento das aplicações desenvolvidas e suas interações. Além disso,

Figura 7 – Exemplo de diagrama de Classes, segundo o modelo C4.

Fonte: BROWN (2013).

permite que pessoas com diferentes expertises consigam compreender como a solu- ção funciona, compartilhando uma visão geral da arquitetura proposta.

Para avaliar e compreender os requisitos e funcionalidades de soluções de soft- ware, ou validar uma AS, uma abordagem bastante utilizada é a prototipação.