Skip to content

Documento de arquitetura

italopaiva edited this page Nov 23, 2015 · 48 revisions

Documento de Arquitetura de Software

SiMCTA

Versão 2.0

Histórico da Revisão

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

1. Introdução

Esse documento apresenta uma visão acerca da arquitetura de software utilizada para o desenvolvimento do SiMCTA.

1.1 Finalidade

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.

1.2 Escopo

Esse documento trata de elementos arquiteturais e leva em consideração as especificações do casos de uso e o diagrama de classes.

1.3 Referências

Casos de Uso

Diagrama de Classes

1.4 Visão Geral

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.

2. Representação da Arquitetura

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.

arquitetura

3. Metas, Restrições e Decisões Arquiteturais

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.

4. Visão de Casos de Uso

Os casos de uso relevantes para a arquitetura são:

UC01-Cadastrar curso

UC05-Cadastrar pacote

UC09-Matricular aluno

UC18-Abrir turma

UC21-Matricular aluno na turma

diagrama-caso-uso-arquitetura

4.1 Realizações de Casos de Uso

Os diagramas de sequência dos casos de uso permitem a visualização do comportamento da comunicação entre as camadas.

5. Visão Lógica

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.

5.1 Responsabilidades por camada

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.

5.2 Visão Geral

A imagem abaixo exemplifica as comunicações entre as camadas elucidadas acima.

diagrama-pacotes

6. Visão de Implementação

A visão de implementação está dividida em pacotes de acordo com as camadas estabelecidas.

6.1 Model

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.

Pacote Model - Geral

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.

Diagrama-model-geral-4-iteracao

Pacote Model - Específico

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.

Diagrama-de-Model-Iteração-6

6.2 DAO

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.

classes-dao

6.3 View

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.

Diagrama-de-View-Iteração-4

6.4 Controller

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.

Diagrama-controller-4-iteracao

7. Visão de dados

Na visão de dados são apresentados os dois modelos que representam as entidades e relacionamentos no banco de dados.

Modelo conceitual

No modelo conceitual é apresentado o Diagrama Entidade-Relacionamento.

der-6

Modelo lógico

No modelo lógico é apresentado o diagrama de esquema do banco de dados. de-6

8. Visão de Implantação

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:

implantacao

Clone this wiki locally