Architecture Document
We write the management artifacts in brazilian portuguese language. If you want a feedback about this artifact, feel free to ask! We'll take an effort to bring an abstract to you ;)
Este documento apresenta uma visão geral da arquitetura do EqLibra e utiliza uma série de visões arquiteturais diferentes para ilustrar os diversos aspectos do sistema. Sua intenção é capturar e transmitir as decisões significativas do ponto de vista da arquitetura que foram tomadas em relação ao sistema.
O documento de arquitetura da aplicação especifica e constitui as metodologias e visões para a construção do produto em forma de Web Site. Tal arquitetura, aqui idealizada, fundamenta a base para a construção do produto, expressando como o sistema deverá se comportar em suas interações e qual o nível de abrangência da aplicação em questão de limitação e qualidade.
Este documento está organizado pelas seguintes seções:
-
Introdução: Fornece uma visão geral do conteúdo do documento.
-
Representação da Arquitetura: Descreve qual é a arquitetura de software do sistema e como ela é representada.
-
Visão Lógica: Ilustra o funcionamento do software descrevendo a decomposição do modelo de design em termos de camadas e de hierarquia de pacotes.
-
Visão de Implementação: Descreve a estrutura geral do modelo de implementação definindo as regras que determinam a inclusão em uma camada específica.
Basicamente, para o desenvolvimento do EqLibra, foi considerado a arquitetura sugerida pelo framework Django e aplicações de padrões de projeto, mais especificamente, os padrões GRASP (Padrões de Software para Atribuição de Responsabilidade Geral).
A arquitetura Django é vagamente baseada no padrão MVC (Model-View-Controller), pois realiza a separação da lógica da aplicação, a interface com o usuário e as camadas de acesso aos dados. Contudo, é importante ressaltar que o Django implementa, de fato, um padrão semelhante de arquitetura: o MTV (Model-Template-View). Em síntese:
-
Model: pode ser vista como a camada de acesso aos dados, onde a aplicação interage com quaisquer banco de dados e fontes de informações.
-
Template: é a camada que define como os dados devem ser apresentados ao usuário, enquanto que essa é considerada a camada view em um padrão MVC.
É importante ressaltar que a camada Controller de MVC possui uma interpretação distinta no framework Django. Nesse caso, o framework vê como a própria estrutura, determinando a visualização apropriada para a qual enviar requisições, conforme definido na configuração de URL's.
Contudo, mediante ao paradigma de organização do framework, visões foram abstraídas, aplicando os padrões de projeto GRASP. Dessa maneira, foi possível obter uma representação MVC e, em adicional, garantir boas práticas de projeto.
A visão de caso de uso é documentada no Documento de Caso de Uso.
O EqLibra, tratando-se de uma aplicação web, contará com um servidor HTTP (web), convencionalmente obedecendo à arquitetura cliente/servidor. Neste servidor está implantada a aplicação (código-fonte) em sua versão final e, para estabelecer comunicação com as máquinas requisitantes, utiliza-se principalmente do protocolo TCP/IP. Além disso, o servidor ainda estabelecerá comunicação com uma base de dados Apache. Esta comunicação é firmada através da linguagem PostgreSQL, pré estabelecida pelos padrões adotados durante as fases de análise e definição de arquitetura.
A imagem a seguir ilustra os componentes envolvidos na arquitetura.
A visão de dados proporciona uma visão abstrata quanto aos dados. Isto é, o sistema acaba por ocultar determinados detalhes sobre a forma de armazenamento e manutenção desses dados.
O diagrama utilizado para está visão é o MER no qual descreve os objetos (entidades) envolvidos em um domínio de negócios, com suas características (atributos) e como elas se relacionam entre si (relacionamentos). Este modelo representa a estrutura que possuirá o banco de dados da aplicação. Mas, para o contexto do EqLibra, algumas dificuldades são encontradas para documentar este modelo e consequentemente esta visão.
A principal dificuldade em documentar esta visão está no princípio de utilização do framework do Django, o qual possui um padrão de estruturação de banco de dados interno muito sólida, o que acaba atrapalhando sua documentação uma vez que é difícil enxergar o MER no framework. No entanto, é uma arquitetura interna bem estável e útil.
A imagem a seguir ilustra o MER, Modelo Entidade Relacionamento, obtido a partir da abstração dos diagramas de classe e domínio.
Como já mencionado, a aplicação desenvolvida baseia-se em uma arquitetura dividida em camadas. Com a utilização da linguagem Python, segundo critérios do framework Django, é possível a organização dessas camadas baseadas em pacotes (packages). A figura a seguir ilustra a arquitetura do sistema e as setas indicam as dependências entre os pacotes.
Diagrama de Pacotes
Os pacotes "Atribuidor" e "Direcionador" foram pensados a partir da aplicação do padrão GRASP da Indireção, que evita o acoplamento direto. No caso do pacote "Atribuidor", foi pensado um novo arquivo, o "displays.py", responsável pela estruturação e exibição de informações. Os demais arquivos, "forms.py", "urls.py" e "admin.py" são implementações do framework Django. Como retratado anteriormente, uma abstração foi realizada para aplicação dos padrões GRASP, bem como adequação à um MVC mais formal.
A visão de implementação prevê como os componentes do aplicativo serão distribuídos em suas respectivas camadas. Essas camadas (View, Model e Controller) foram adotadas pelo fato de trazerem uma organização estrutural dos componentes do sistema como um todo, aumentando a coesão e diminuindo o acoplamento, além de prover facilidade na divisão de atividades e manutenibilidade, pois cria padrões bem definidos de implementação.
A seguir, será possível contemplar imagens acerca da visão de implementação para modelos e para as controladoras.
Diagrama de Classes - Modelos
Diagrama de Classes - Controladoras
A partir da visualização das imagens é possível contemplar a aplicação de outros padrões GRASP, como Criador, Especialista, Alta Coesão e Controlador. A seguir, será possível contemplar um diagrama de sequência elaborado para a operação de efetuação do login, compreendendo a visão de implementação das classes dos pacotes "Atribuidor" e "Direcionador".
Diagrama de Sequência - Login
É possível contemplar o Diagrama de Colaboração, que exemplifica o posicionamento dos módulos da aplicação com relação às requisições por parte do usuário.
Diagrama de Colaboração
Contudo, mesmo havendo a aplicação dos padrões GRASP, procurou-se encontrar maneiras de otimizar as operações com os objetos, visto que o EqLibra é um sistema orientado a objetos. Assim, foram considerados alguns padrões GoF (Gang of Four).
Em síntese, os padrões de projeto GoF caracterizam-se como uma solução consolidada para problemas recorrentes no desenvolvimento e manutenção de software orientado a objetos.
A seguir, é possível visualizar o diagrama de classes obtido até o momento para o EqLibra, considerando a permanência dos padrões GRASP bem como a adição de padrões GoF.
Diagrama de Classes com a aplicação dos padrões GoF
Dessa forma, observando a modelagem de classes, é possível perceber três padrões GoF: o Memento, o Template Method e o Strategy. Esses padrões se apresentam como soluções extremamente elegantes e necessárias para o contexto da simulação de investimentos, visto que existem cálculos de simulação que variam em alguns detalhes e, adicionalmente, pertencem à módulos distintos pela perspectiva da engenharia econômica.