Documento de arquitetura
| Data | Versão | Descrição | Autor |
|---|---|---|---|
| 06/09/2015 | 1.0 | Criação do documento | Emilie Morais |
| 26/09/2015 | 1.5 | Atualização da definição da arquitetura e diagramas de classes | Ítalo Paiva |
| 21/11/2015 | 2.0 | Atualização do documento | Ítalo Paiva |
| 21/11/2015 | 2.0 | Ajustes no textos do documento e na seção de casos de uso | Emilie Morais |
| 21/11/2015 | 2.0 | Atualização da seção da Visão Lógica | Ítalo Paiva |
| 21/11/2015 | 2.0 | Atualização da seção da Visão de Implantação | Ítalo Paiva |
Esse documento apresenta uma visão acerca da arquitetura de software utilizada para o desenvolvimento do SiMCTA.
A finalidade do documento de arquitetura é apresentar uma visão acerca da arquitetura a ser utilizada de modo a estabelecer um padrão de projeto e possibilitar uma melhor modularização e manutenabilidade para o SiMCTA.
Esse documento trata de elementos arquiteturais e leva em consideração as especificações do casos de uso e o diagrama de classes.
Nesse documento é apresentada a representação da arquitetura, suas metas e restrições, as diferentes visões, como: caso de uso, lógica, de implantação, de implementação e de dados.
Para o SiMCTA é proposta uma arquitetura de quatro camadas, sendo elas: Model, View, Controller e DAO.
A camada Model é responsável por estabelecer o domínio da aplicação na solução proposta, contendo as regras de negócio inerentes ao contexto. Ela se comunica diretamente apenas com as camadas Controller e DAO.
A camada Controller é responsável por processar as informações provenientes da View, ou seja, informações solicitadas pelo usuário, controlando o fluxo da aplicação e utilizando ou alterando dados da Model. Essa camada também estabelece comunicação com o banco de dados por intermédio da camada DAO.
Dessa forma, a camada DAO (Data Access Object) é responsável por realizar a persistência no banco de dados.
Na imagem abaixo pode ser vista a estrutura de comunicação estabelecida entre as camadas.
A arquitetura escolhida permite ao sistema uma maior modularização, facilitando a manutenção do software e a integração com futuros módulos previstos.
O sistema deve ser implementado utilizando a linguagem Java e o banco de dados MySQL.
As decisões arquiteturais críticas foram documentas como Memórias Técnicas.
Os casos de uso relevantes para a arquitetura são:
UC21-Matricular aluno na turma
Os diagramas de sequência dos casos de uso permitem a visualização do comportamento da comunicação entre as camadas.
O usuário estabelece comunicação com a View, a qual requisita algum tipo de ação do sistema, assim a View solicita para a Controller a ação requerida. A Controller processa as informações através da comunicação com a Model e com a DAO, esta que se comunica com o banco de dados, e retorna o resultado para a View apresentando para o usuário.
A camada View deve conter apenas as classes responsáveis pelos componentes gráficos e visuais de interação com o usuário. As classes desta camada só se comunicam com as classes da camada Controller, enviando requisições, e com as classes do pacote Datatype para a criação de tipos de dados simples.
A camada Controller contém as classes responsáveis por receber as requisições das classes da View e para se comunicar com as classes das camadas Model e DAO. Esta camada pode se comunicar com todas as classes das outras camadas, de modo estabelecer o fluxo da aplicação.
A camada Model contém as classes que representam o domínio da aplicação, contendo as regras de negócio implementadas. As classes desta camada podem se comunicar com as classes da camada Controller e com as classes do pacote Datatype para a criação de tipos de dados que serão incorporados nos modelos.
A camada de DAO contém as classes de comunicação com o banco de dados para a persistência e recuperação dos dados. As classes desta camada podem se comunicar com as classes da camada Controller, devolvendo status de operações ou resultados de consultas, e com as classes da camada Model para criar os objetos que serão retornados em consultas.
O pacote Datatype contém classes que representam tipos de dados genéricos que são utilizados pelas outras classes, principalmente na camada Model. Pode ser considerado uma camada inferior à Model, com classes reutilizáveis. As classes deste pacote foram criadas pela utilização do padrão Expert, criando classes coesas com a responsabilidade de fazer e conhecer os respectivos tipos de dados que representam.
A imagem abaixo exemplifica as comunicações entre as camadas elucidadas acima.
A visão de implementação está dividida em pacotes de acordo com as camadas estabelecidas.
Na camada de Model foram diagramadas duas visões, uma visão geral apresentando apenas os nomes das classes que compõem a camada e uma visão específica sendo representada pelo diagrama de classes.
Na visão geral do pacote está representada uma classe genérica criada para o pacote, onde todas as classes pertencentes a essa camada são subclasse dessa classe.
Na visão específica do pacote está representado o diagrama de classes do sistema. Nesta camada foi utilizada uma Indireção com a Invenção Pura das classes Service e ServiceItem, que não faziam parte do domínio mas foram criadas para aliviar outras classes e facilitar a implementação. Foram utilizados os padrões Composite para representar a relação Todo-Parte entre Pacote e cursos.
Na visão do pacote de DAO podem ser vistas as classes pertencentes ao pacote responsáveis pela persistência no banco e as classes responsáveis por realizar a conexão com o banco.
Nesta camada foi utilizada Invenção Pura da classe abstrata DAO para definir métodos comuns às classes de persistência de cada entidade, uma Indireção junto com o padrão criacional Singleton com a criação da classe FactoryConnection para intermediar a conexão com o banco de dados.
A modelagem das classes da camada de View destacam o uso dos Padrões de Projeto Decorator para decorar os formulários de CRUD das diversas classes com as respectivas operações e Template Method para definir a ordem de criação dos elementos na tela.
A modelagem seguinte apresenta uma solução utilizando uma indireção aplicada com o padrão Template Method em uma herança incompleta para as classes responsáveis pela matrícula do aluno em curso.
Na visão de dados são apresentados os dois modelos que representam as entidades e relacionamentos no banco de dados.
No modelo conceitual é apresentado o Diagrama Entidade-Relacionamento.
No modelo lógico é apresentado o diagrama de esquema do banco de dados.
A aplicação será executada em um computador pessoal operando o Sistema Operacional Windows XP Service Pack 3. Como aplicação Java, será utilizado a Java Virtual Machine (JVM) 1.7 como ambiente de execução da aplicação, onde será gerado um arquivo .jar contendo a aplicação.
Para executar o arquivo .jar no Windows, deve ser criado um arquivo .bat contendo o código que iniciará a aplicação Java. Para o acesso do usuário à aplicação, um atalho do Windows para o arquivo .bat deve ser criado contendo o ícone da logomarca da empresa.
Para a utilização do banco de dados pela aplicação, deve ser instalado no Windows o Banco de Dados MySQL 5.5.44 e executado o script para a criação do banco de dados utilizado pela aplicação.
A Figura abaixo mostra a visão de implantação descrita:
