Documento de Arquitetura de Software- SGE

Transcrição

1 Documento de Arquitetura de Software- SGE IFG Autor: Marcelo Roldrin Barros Silva 1. Introdução 1.1 Finalidade Este documento oferece uma visão geral arquitetural abrangente do sistema SGE (Sistema de Gestão de Eventos), usando diversas visões arquiteturais para representar diferentes aspectos do sistema. O objetivo deste documento é capturar e comunicar as decisões arquiteturais significativas que foram tomadas em relação ao sistema. 1.2 Escopo Este documento ou artefato restringe-se a visão arquitetural dos Protótipos do Projeto SGE (Sistema de Gestão de Eventos), não abordando especificidades referentes às Tecnologias escolhidas para suportar sua implementação. 2. Definições, Acrônimos e Abreviações [1] RUP ( 3. Representação Arquitetural A Representação Arquitetural dos Protótipos do Projeto SGE baseia-se no Modelo 4+1 de Visualização de Arquitetura de Software (The 4+1 Model of View Architeture), de uso proposto pelo RUP [1]. Neste modelo, a arquitetura encontra-se representada por uma série de visões diferentes que, em sua essência, são fragmentos que ilustram os elementos significativos em termos de arquitetura dos modelos. A Figura 1 abaixo, apresenta as visões que compõem o Modelo 4+1 e, na sequência, as mesmas são descritas:

2 3.1 Metas e Restrições da Arquitetura Existem algumas restrições de requisito e de sistema principais que têm uma relação significativa com a arquitetura. São elas: Toda a programação do evento e os certificados devem ser disponibilizados online e ser acessadas pela internet; O sistema deve ser compatível com dispositivos moveis (Tablets e celulares); O sistema deve ser exibido e visualizado pelos principais navegadores disponíveis no mercado; O sistema deverá ser desenvolvido através de uma arquitetura flexível fácil de manter, de modo a acomodar novas funcionalidades e adaptações sem elevação de custo ou esforço adicional; A Linguagem de desenvolvimento utilizada para o sistema será o JAVA; O Servidor de Aplicação definido para o sistema foi o Glassfish; O Banco de Dados escolhido para suportar a aplicação será o PostgreSQL; Foram escolhidos os seguintes frameworks: o o o Hibernate (Persistência); JSF (View); Twitter Bootstrap (View).

3 4. Visões Arquiteturais 4.1 Visão Lógica O objetivo da visão lógica é representar a estrutura de relacionamento entre os elementos arquiteturais da aplicação, definindo seus padrões e conceitos gerais Definição das Camadas Nesta seção serão apresentadas as camadas da arquitetura proposta. Serão descritas as responsabilidades de cada camada quais tecnologias devem ser aplicadas a cada uma delas. No diagrama abaixo estão ilustradas cada uma das camadas que compõem a arquitetura básica proposta: Visão: A visão (view) é responsável por tudo que o usuário final visualiza, toda a interface, informação, não importando sua fonte de origem, é exibida graças a camada de visão. Controle: A Controle (controller), como o nome já sugere, é responsável por controlar todo o fluxo de informação que passa pelo site/sistema. É na controladora que se decide se, o que, quando e onde deve funcionar. Define quais informações devem ser geradas, quais regras devem ser acionadas e para onde as informações devem ir, é na controladora que essas operações devem ser executadas. Em resumo, é a controladora que executa uma regra de negócio (modelo) e repassa a informação para a visualização (visão). Modelo: O modelo (Model) é utilizado para manipular informações de forma mais detalhada, sendo recomendado que, sempre que possível, se utilize dos modelos para realizar consultas, cálculos e todas as regras de negócio do nosso site ou sistema. É o modelo que tem acesso a toda e qualquer informação sendo essa vinda de um banco de dados, arquivo XML.

4 4.2 Visão de Processos Não definido. [Esta seção descreve a decomposição do sistema em processos leves (threads simples de controle) e processos pesados (agrupamentos de processos leves). Organize a seção em grupos de processos que se comunicam ou interagem. Descreva os modos principais de comunicação entre processos, como transmissão de mensagens e interrupções.] 4.3 Visão de Implantação Visão Geral Esta visão define o ambiente de implantação onde a aplicação será publicada/instalada.

5 4.4 Visão da Implementação Visão Geral A proposta para Modelo de Implementação desse projeto baseou-se na sua divisão em camadas de responsabilidades, de forma a propiciar o reúso de componentes de software desenvolvidos entre eles Camadas

6 4.5 Visão de caso de uso Ainda não possuímos os casos de uso Realizações de Casos de Uso Esta seção ilustra o funcionamento do software, apresentando algumas realizações (ou cenários) de casos de uso selecionadas e explica como os diversos elementos do modelo de design contribuem para a respectiva funcionalidade.] 4.6 Visão de Dados(opcional) [Uma descrição da perspectiva de armazenamento de dados persistentes do sistema. Esta seção será opcional se os dados persistentes forem poucos ou inexistentes ou se a conversão entre o Modelo de Design e o Modelo de Dados for trivial.] 5. Tamanho e Desempenho [Uma descrição das principais características de dimensionamento do software que têm um impacto na arquitetura, bem como as restrições do desempenho desejado.] 6. Qualidade A arquitetura definida propicia o desenvolvimento dos protótipos do sistema, favorecendo a realização de teste, a verificação e a validação durante seu desenvolvimento. Além disso o aspecto de Camadas, propiciado pelos diferentes níveis de integração, permitem que se realize a substituição de camadas, sem causar grandes impactos no restante da aplicação.