Visão de Módulo

Visão de módulo

A construção de sistemas de qualidade passa pela modelagem e arquitetura. É importante que todas as pessoas envolvidas direta ou indiretamente no projeto conheçam bem qual a arquitetura escolhida. Na fase de definição de arquitetura, os diagramas UML são bastantes úteis.

Acima temos uma visão genérica para definição de arquitetura de sistemas separado em módulos/camadas e como eles se interagem.Vamos definir e descrever essas camadas.

A camada de “Apresentação WEB” tem a finalidade de permitir o acesso do público ao sistema através do navegador WEB. Componentes GUI, HTML, AJAX, Javascript, etc. poderão ser usados. Esta camada utiliza o pacote de “Acesso as Regras” para fazer chamada a camada inferior de “Regras de Negócio” que, por sua vez, recebe chamada através do pacote “Exposição das Regras”. Estes pacotes de acesso e exposição às regras da liberdade na mudança dos conectores dessas camadas. Qualquer mudança na infra-estrutura de conexão será feita apenas nestes pacotes-conectores.

Como o nome já diz, a camada de “Regras de negócio” contém as classes de regras para processamento e funcionamento do sistema. Internamente há uma subdivisão em pacotes que se comunicam normalmente dentro da camada, seja por herança, agregação ou chamadas estáticas. Muitas regras dependem de salvamento e recuperação de dados no banco de dados. Esses acessos deverão utilizar a camada de “Acesso a dados”. Nela conterá classes ou objetos para fazer acesso ao banco de dados. Também, o acesso a camada de acesso a dados deverá ser feita através do pacote “Acesso aos DAO’s” e, por sua vez, a camada de dados receberá as requisições através do pacote “Exposição do Acesso a dados”. O motivo para utilização desses dois pacotes é o mesmo citado na comunicação entre a camada de apresentação e a camada de regras.

Na camada “Acesso a dados” também vão existir pacotes com classe para acesso a dados (inserir, alterar, listar, excluir). Todas as classes deverão utilizar uma outra camada de persistência de dados e essa utilização deverá ser através de herança. Uma classe abstrata “BaseDAO” deverá conter todas as funcionalidades de comunicação com o pacote de persistência que por sua vez, faz inter-comunicação com o banco de dados propriamente dito.

Dessa forma as camadas ficam bastante independente uma das outras. Utilizamos alguns conceitos de orientação a objetos como interface e classes abstratas para fazer chamadas entre as camadas e também classes DTO (Data Transfer Object) para troca de informações entre as camadas.

Este modelo de arquitetura pode ser utilizado em qualquer linguagem que utilize conceitos de orientação a objetos. A principal característica desse modelo é a possibilidade de desenvolvimento das camadas em tempos diferentes e por pesssoas diferentes. Para tanto é necessário apenas a definição das assinaturas (interfaces) das classes: os pacotes de exposição e acesso a cada camada.

Qualquer dúvida, estamos à disposição para quaisquer esclarecimento.