Os padrões de projeto possibilitam a reutilização de técnicas comprovadas com o objetivo de atender requisitos técnicos relacionados ao projeto de um sistema. Para este trabalho, foram analisados alguns padrões de projeto e selecionados aqueles que poderiam ser satisfatoriamente aplicados.
Facade
Padrão de projeto que oferece um ponto centralizado e unificado para um conjunto de interfaces em um subsistema ou do sistema como um todo, que representa o conjunto de serviços oferecidos. Neste projeto a camada de interface de negócios é implementada com um ponto de acesso único para as funcionalidades, isolando os diversos componentes do sistema (Helm,2005).
MVC
O MVC tem como principal objetivo separar dados físicos ou lógicos de negócio da interface do usuário e o fluxo da aplicação. A ideia é permitir que uma mensagem da lógica de negócios possa ser acessada e visualizada através de várias interfaces. Na arquitetura MVC, a lógica do negócio não sabe quantas e nem quais são as interfaces que o usuário está exibindo seu estado. A interface do usuário não se importa de onde está recebendo os dados mas ela tem que garantir que sua aparência reflita o estado do modelo (Helm,2005).
DAO
É um padrão para persistência dos dados que permite separar regras de negócio das regras de acesso ao banco de dados (Helm,2005).
Singleton
Assegura que a classe terá uma única instância e provê um ponto único de acesso a ela. O padrão singleton é usado, portanto, dentro de uma interface de negócio, para limitar sua instância, acessível a partir de um único ponto específico. Isto é importante por que serve de único ponto de acesso a todos os serviços oferecidos e dispõe do conjunto de dados que será compartilhado entre os usuários (Helm, 2005).
4.4. Documentos de Requisitos
O propósito deste documento é apresentar a descrição dos serviços e funções que o sistema a ser desenvolvido deve prover, bem como as suas restrições de operação e propriedades gerais.
4.4.1 Visão geral do documento de requisitos
Esta secção fornece as informações necessárias para fazer um bom uso do referido documento, explicitando seus objetivos e as convenções que foram adotadas no texto. As seções 4.4.2 e 4.4.3 apresentam a especificação do formulário, ou seja, a especificação dos requisitos que deverão ser levados em consideração no desenvolvimento do protótipo e os mesmos estarão organizadas como descrito abaixo:
Seção 4.4.2 – Requisitos funcionais – Lista os requisitos funcionais do sistema, especificando seus objetivos e prioridades; e
Seção 4.4.3 – Requisitos não funcionais – Lista os requisitos não funcionais do sistema, especificando seus objetivos e prioridades.
Esta seção explica o conceito de alguns termos importantes que serão mencionados no decorrer deste documento. Estes termos são descritos no Quadro 4.1.
Quadro 4.1 - Requisitos Funcionais e Não Funcionais
Termo Descrição
Requisitos Funcionais Requisitos técnicos de software que compõe o sistema, que descrevem ações que o sistema deve estar apto a executar, ou seja, o que o sistema deve fazer.
Requisitos Não Funcionais Requisitos técnicos do software que compõe o sistema, que descrevem atributos que o sistema deve possuir ou restrições sob as quais ele deve operar.
Requisitos Não Técnicos Requisitos não relacionados ao software. Requisitos não técnicos estão fora do escopo deste documento.
Fonte: Borges et. al., 2005
Para estabelecer a prioridade dos requisitos, foram adotadas as denominações “essencial”, “importante” e “desejável”. A prioridade dos requisitos é
utilizada no gerenciamento do escopo das etapas do projeto e no estabelecimento delas durante o desenvolvimento do sistema:
Essencial – Requisito sem o qual o sistema não entra em funcionamento; Importante – Requisito sem o qual o sistema entra em funcionamento, mas
de forma não satisfatória. Requisitos importantes devem ser implantados o mais rápido possível, mas se não forem, parte do sistema poderá ser implantada mesmo assim; e
Desejável – Requisito que não compromete as funcionalidades básicas do sistema, isto é, o sistema pode funcionar de forma satisfatória sem ele. Requisitos desejáveis são requisitos que podem ser desenvolvidos por último, sem comprometer o funcionamento do sistema.
4.4.2 Requisitos Funcionais
Os requisitos funcionais estão descritos e enumerados conforme as referências a seguir:
A referência “RF” significa Requisito Funcional e o número que se encontra após está referência significa a sequencia (ordenação) adotada.
[RF001] – Manter Cadastro de Arquivos XML
Este requisito tem como finalidade o cadastro dos arquivos XML.
Prioridade: [ x ] Essencial [ ] Importante [ ] Desejável
[RF002] – Listagem dos Arquivos XML
Este requisito tem como finalidade listar os arquivos XML que foram dados carga e exibir a situação das notas fiscais (Recebida, Classificada, Vinculada, Pendente, Sem Registro, Cancelada)
Prioridade: [ ] Essencial [ x ] Importante [ ] Desejável
[RF003] – Exibir detalhes dos Arquivos XML
Este requisito tem como finalidade exibir o conteúdo do arquivo XML selecionado pelo usuário.
Prioridade: [ ] Essencial [ x ] Importante [ ] Desejável
[RF004] – Exibir a apuração das notas fiscais
Este requisito tem como finalidade exibir a quantidade e valor total de notas fiscais para o período solicitado.
Prioridade: [ ] Essencial [ x ] Importante [ ] Desejável
[RF005] – Exibir a quantidade de produtos vendidos
Este requisito tem como finalidade exibir a quantidade de produtos vendidos no período solicitado.
Prioridade: [ ] Essencial [ x ] Importante [ ] Desejável
[RF006] – Exibir o montante de impostos pagos
Este requisito tem como finalidade exibir o valor que foi pago em impostos nas mercadorias no período solicitado.
Prioridade: [ ] Essencial [ x ] Importante [ ] Desejável
[RF007] – Exibir o preço de custo dos produtos
Este requisito tem como finalidade exibir o valor do preço de custo do produto, ou seja, o preço do produto com os impostos.
Prioridade: [ ] Essencial [ x ] Importante [ ] Desejável
[RF008] – Exibir a quantidade mínima por produto
Este requisito tem como finalidade exibir a quantidade mínima de cada produto, fazendo uma verificação semanal de entrada e saída.
Prioridade: [ ] Essencial [ x ] Importante [ ] Desejável
4.4.3 Requisitos Não Funcionais
Os requisitos não funcionais estão descritos e enumerados conforme as referências a seguir:
A referência “RNF” significa Requisito Não Funcional e o número que se encontra após está referência significa a sequencia (ordenação) adotada.
[RNF001] – Sistema Web
O sistema deve ser Web seguindo os padrões de desenvolvimento e ser compatível com o navegador Chrome (Google, 2013).
Prioridade: [ x ] Essencial [ ] Importante [ ] Desejável
[RNF002] – Linguagem de Programação deve ser Java 6.0
Esta linguagem Java (Oracle, 2013) foi escolhida na versão 6.0 devido a uma limitação do servidor Online, que só possui recursos de utilização até esta versão.
Prioridade: [ x ] Essencial [ ] Importante [ ] Desejável
[RNF003] – O Servidor de Aplicação deve ser Apache Tomcat 6.0
O servidor de aplicação instalado no ambiente proposto para executar o protótipo é o Apache Tomcat (Wiggers, 2003) 6, fincando inviável atualizar o mesmo devido a outras aplicações que utilizam o mesmo servidor.
Prioridade: [ x ] Essencial [ ] Importante [ ] Desejável
[RNF004] – O software de relatórios deve ser o iReport 5.0.1 ou superior
O iReport (JasperSoft, 2013) é uma ferramenta bem consolidada no mercado e é de fácil manuseio para a criação de relatórios.
Prioridade: [ x ] Essencial [ ] Importante [ ] Desejável
[RNF005] – A API de desenvolvimento deve ser a SpringFaces 3.0.0 Release ou superior
A API de desenvolvimento da aplicação Web associada ao Java é a SpringFaces (SpringSource, 2013), que garante uma alta performance no desenvolvimento da solução e integrada ao Eclipse (Eclipse, 2013), que é uma ferramenta bastante utilizada em ambientes corporativos que trabalham com a linguagem Java.
Prioridade: [ x ] Essencial [ ] Importante [ ] Desejável
[RNF006] – O SGBD deve ser o Oracle 11g Release 11.2.0.2.0
O servidor Online Oracle é o 11g, sendo isso um fator importante devido ao tratamento dos dados em XML, que foi melhorado nesta versão para o uso do campo “sys.XMLType”, que será usado para armazenar os dados em XML (Oracle, 2013).
Com essa melhora as consultas a campos deste tipo respondem de maneira mais rápida (Oracle, 2007).
Prioridade: [ x ] Essencial [ ] Importante [ ] Desejável
[RNF007] – O sistema deve funcionar nos sistemas operacionais Windows, GNU/Linux, Mac OS, Android e iOS.
O sistema deve funcionar nos sistemas operacionais GNU/Linux, Windows e Mac OS, pois como a aplicação será web, basta que o sistema operacional possua um browser que será possível fazer uso da aplicação.
Prioridade: [ x ] Essencial [ ] Importante [ ] Desejável
[RNF008] – O sistema deve suportar o acesso de 1.000 usuários simultâneos
Como a aplicação será disponibilizada Online, várias pessoas poderão fazer uso dessa funcionalidade e com isso deixando uma margem de 1.000 usuários
simultâneos para o acesso a aplicação.
Prioridade: [ x ] Essencial [ ] Importante [ ] Desejável
[RNF009] – A arquitetura deve seguir o padrão MVC
O padrão MVC é o padrão utilizado atualmente pelo local onde o protótipo será desenvolvido.
Prioridade: [ x ] Essencial [ ] Importante [ ] Desejável