2011
Criação de Componente de parâmetro de
Relatório e Pesquisa
Framework de Aplicação:
Amanda Barbosa Silva
UNIVERSIDADE ESTADUAL DE GOIÁS
UNIDADE UNIVERSITÁRIA DE CIÊNCIAS EXATAS E TECNOLÓGICAS
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
AMANDA BARBOSA SILVA
Framework de Aplicação:
Criação de Componente de Parâmetro de Relatório e Pesquisa
Anápolis
Novembro, 2011
UNIVERSIDADE ESTADUAL DE GOIÁS
UNIDADE UNIVERSITÁRIA DE CIÊNCIAS EXATAS E TECNOLÓGICAS
BACHARELADO EM SISTEMAS DE INFORMAÇÃO
AMANDA BARBOSA SILVA
Framework de Aplicação:
Criação de Componente de Parâmetro de Relatório e Pesquisa
Projeto apresentado ao Departamento de Sistemas de Informação da Unidade Universitária de
Ciências Exatas e Tecnológicas da Universidade Estadual de Goiás, como requisito parcial
para obtenção do grau de Bacharel em Sistemas de Informação.
Orientador: Prof. Esp. Leandro Doutor Branquinho
Anápolis
Novembro, 2011
FICHA CATALOGRÁFICA
SILVA, Amanda Barbosa. Framework de Aplicação: Criação de Componente de
Parâmetro de Relatório e Pesquisa. Anápolis 2011.
(UEG / UnUCET, Bacharelado em Sistemas de Informação, 2011).
Trabalho de Conclusão de Curso (Projeto). Universidade Estadual de Goiás, Unidade
Universitária de Ciências Exatas e Tecnológicas. Departamento de Sistemas de Informação.
1. Framework
2. Pesquisa
3. Parâmetros de Relatório
4. Banco de Dados
5. Padrões
6. Orientação a Objetos
REFERÊNCIA BIBLIOGRÁFICA
SILVA, Amanda Barbosa. Framework de Aplicação: Criação de Componente de
Parâmetro de Relatório e Pesquisa. Anápolis, 2011. 151 p. Trabalho de Conclusão de Curso
(Projeto) – Curso de Sistemas de Informação, UnUCET, Universidade Estadual de Goiás.
CESSÃO DE DIREITOS
NOME DO AUTOR: Amanda Barbosa Silva
TÍTULO DO TRABALHO: Framework de Aplicação: Criação de Componente de Parâmetro
de Relatório e Pesquisa.
GRAU/ANO: Graduação / 2011.
É concedida à Universidade Estadual de Goiás permissão para reproduzir cópias deste
trabalho, emprestar ou vender tais cópias para propósitos acadêmicos e científicos. O autor
reserva outros direitos de publicação e nenhuma parte deste trabalho pode ser reproduzida
sem a autorização por escrito do autor.
Amanda Barbosa Silva
Avenida Contorno nº 314, Qd. 104 A Lt. 59 - Centro
CEP 74055-140 – Goiânia – GO – Brasil
Dedico esse trabalho a minha mãe, por ter sempre me ajudado e incentivado em meus estudos,
estando sempre ao meu lado. Dedico também ao meu namorado, Vinicius, por sempre me
ajudar em minhas dificuldades e sempre acreditar em mim e em minha capacidade. Dedico
também ao meu professor e orientador, Leandro, por propor esse projeto.
AGRADECIMENTOS
Ao meu professor e orientador Leandro, pelo apoio, incentivo, e por acreditar no
desenvolvimento deste projeto e em minha capacidade.
A todos os meus professores pelo constante apoio ao longo dos anos do curso.
Agradeço a empresa em que a trabalho atualmente, a DataEasy, por ter acreditado
em meu potencial, investido em minha carreira profissional e proporcionado a minha
mudança para a área de programação e minha contratação.
Aos meus familiares pelo apoio a seguir um curso em outra cidade e por outras
dificuldades encontradas durante os quatro anos de curso. Agradeço especialmente a minha
mãe, por sempre me apoiar em minhas escolhas e pelos incentivos em continuar o curso.
Ao meu namorado, Vinicius, pelo constante apoio em minhas dificuldades e ao
incentivo à carreira de programador que proporcionou a iniciativa e o desenvolvimento deste
projeto.
A todos, os meus sinceros agradecimentos.
LISTA DE ABREVIATURAS E SIGLAS
Siglas
Descrição
OO
Orientação a Objetos
DMS
Documento de Modelagem de Sistema
UEG
Universidade Estadual de Goiás
UnUCET
Unidade Universitária de Ciências Exatas e Tecnológicas
SQL
Structured Query Language
MSSQL
Banco de Dados Microsoft SQL Server
RESUMO
O desenvolvimento de um framework possui vantagens e desvantagens, mas é possível que os
benefícios sejam capazes de sobressair se for bem estruturado e se o domínio for conhecido
detalhadamente.
Framework é o conceito de orientação a objetos na prática. A maturidade em seus conceitos
permite que o desenvolvedor seja capaz de abstrair problemas comuns em certo domínio
criando uma solução genérica através de um conjunto de classes e interfaces encapsuladas,
que pode ser utilizada em aplicações semelhantes (do mesmo domínio), mas não
necessariamente iguais. O uso de padrões de projeto proporciona um dos principais desafios
dos desenvolvedores, o reuso de código.
Este projeto tem como objetivo o desenvolvimento de um componente para um framework de
aplicação (vertical): com as funções de pesquisa e parâmetro de relatórios. O objetivo do
framework é permitir a mudança das interfaces de pesquisa e das consultas de relatórios
através do banco de dados da aplicação, possibilitando a mudança em tempo de execução do
sistema e sem a necessidade de compilação, ou seja, um framework gerenciado pelo banco de
dados.
Palavras-chave: Framework, Banco de dados, Padrões de Projeto, reutilização, regras de
negócio.
ABSTRACT
The development of a framework has advantages and disadvantages, but it is possible that the
benefits are able to exceed if properly structured and if the domain is known in detail.
Framework is the concept of object orientation in practice. The maturity in their concepts
allows the developer to be able to abstract common problems in one domain by creating a
generic solution through a set of classes and interfaces encapsulated, which can be used in
similar applications (same domain), but not necessarily equal. The use of design patterns
provides
a
major
challenge
for
developers,
code
reuse.
This project aims to develop a component to an application framework (vertical) with search
functions and parameter reports. The aim of the framework is to allow the change of search
interfaces and reporting queries through the database application, allowing the change in the
runtime system and without the need to build, that is, a framework managed by the database.
Keywords: Framework, Database, Design Patterns, reuse, business rules.
PREFÁCIO
O propósito deste documento é apresentar a especificação de uma solução em software
genérica, mas que seja capaz de ser especificada para as diversas aplicações que serão criadas
a partir do framework. Especificadamente a criação de um componente de pesquisa e
parâmetros de relatório capaz de gerar interfaces e consultas dinamicamente a partir de
configurações realizadas em banco de dados. Objetiva também ser uma base de dados dos
requisitos do software, dos casos de uso e definição da arquitetura que serão utilizados para o
desenvolvimento.
O Documento de Modelagem do Sistema está organizado em lista de Elementos Gráficos do
Projeto, Dicionário do Projeto, Gerência de Projeto, Modelagem do Negócio, Requisitos,
Modelagem dos Casos de Uso, Modelagem de Dados, Especificação da Arquitetura,
Realização dos Casos de Uso, itens relacionados aos testes e a conclusão do projeto e
complementos.
TABELA DE REVISÕES
Versão
Principais Autores
Descrição da Versão
Data de Término
V[1.0]
Amanda Barbosa Silva
Elaboração do pré-projeto.
07/04/2011
V[2.0]
Amanda Barbosa Silva
Definição do processo de
desenvolvimento do software.
07/05/2011
V[3.0]
Amanda Barbosa Silva
Elaboração do processo para
28/05/2011
definição da estrutura do banco
de dados para os componentes.
Definição da estrutura do banco
de dados.
V[4.0]
Amanda Barbosa Silva
Definição do processo de
especificação de requisitos.
03/09/2011
V[5.0]
Amanda Barbosa Silva
Especificação dos requisitos.
05/09/2011
V[6.0]
Amanda Barbosa Silva
Preenchimento da ata de
reunião realizada no dia
02/09/2011. Definição dos
casos de uso e criação do
diagrama de caso de uso.
24/09/2011
V[7.0]
Amanda Barbosa Silva
Alteração da modelagem do
banco de dados. Inserção de
exemplos na especificação de
requisitos. Início do
detalhamento dos casos de uso.
26/09/2011
Versão
Principais Autores
Descrição da Versão
V[8.0]
Amanda Barbosa Silva
Foi
decidido
que
seria 08/10/2011
desenvolvido
um
único
componente
com
as
funcionalidades de pesquisa e
parâmetro
de
relatório.
Continuação do detalhamento dos
casos de uso. Criação do ER do
banco de dados e do script.
Elaboração do apêndice A que
apresenta
ao
usuário
a
configuração do caminho dos
arquivos de conexão com o banco
de dados.
V[9.0]
Amanda Barbosa Silva
Finalização da modelagem de 15/10/2011
dados.
Finalização
do
detalhamento dos casos de uso.
Criação dos diagramas de
atividade,
componentes,
implantação e pacotes.
V[10.0] Amanda Barbosa Silva
Casos de uso alterados para a nova 22/10/2011
programação.
Alteração
dos
diagramas de acordo com a
necessidade da nova programação.
Preenchimento das atas de reunião
conforme solicitado (reuniões
online). Inicio da definição do
dicionário do projeto.
V[11.0] Amanda Barbosa Silva
Conclusão do dicionário do 29/10/2011
projeto. Criação dos casos de
teste. Criação do apêndice B que
será usando da realização do caso
de teste. Criação da conclusão.
V final
Correção dos diagramas de acordo 11/12/2011
com
a
implementação.
Preenchimento do relatório de
testes. Imagem da interface
gráfica.
Amanda Barbosa Silva
Tabela 1 – Tabela de Revisões
Data de Término
SUMÁRIO
1
2
3
4
Lista de Elementos Gráficos ............................................................................................. 19
1.1
Lista de Tabelas..................................................................................................................... 19
1.2
Lista de Figuras ..................................................................................................................... 21
Dicionário do Projeto ........................................................................................................ 23
2.1
Lista de Abreviaturas nos Artefatos do Documento ............................................................. 23
2.2
Elementos de Dados.............................................................................................................. 23
2.3
Elementos de Comportamento ............................................................................................. 27
Gerência do Projeto ........................................................................................................... 36
3.1
Cronograma de Atividades .................................................................................................... 36
3.2
Processos de Desenvolvimento do Software ........................................................................ 37
3.3
Relatório Semanal de Progresso ........................................................................................... 40
3.3.1
Relatório Semanal de Progresso n.º 01 ......................................................................... 40
3.3.2
Relatório Semanal de Progresso n.º 02 ......................................................................... 41
3.3.3
Relatório Semanal de Progresso n.º 03 ......................................................................... 42
3.3.4
Relatório Semanal de Progresso n.º 04 ......................................................................... 43
3.3.5
Relatório Semanal de Progresso n.º 05 ......................................................................... 44
3.3.6
Relatório Semanal de Progresso n.º 06 ......................................................................... 45
3.3.7
Relatório Semanal de Progresso n.º 07 ......................................................................... 46
3.3.8
Relatório Semanal de Progresso n.º 08 ......................................................................... 47
3.3.9
Relatório Semanal de Progresso n.º 09 ......................................................................... 48
3.3.10
Relatório Semanal de Progresso n.º 10 ......................................................................... 49
3.3.11
Relatório Semanal de Progresso n.º 11 ......................................................................... 50
3.3.12
Relatório Semanal de Progresso n.º 12 ......................................................................... 51
3.3.13
Relatório Semanal de Progresso n.º 13 ......................................................................... 52
3.3.14
Relatório Semanal de Progresso n.º 14 ......................................................................... 53
3.3.15
Relatório Semanal de Progresso n.º 15 ......................................................................... 54
3.3.16
Relatório Semanal de Progresso n.º 16 ......................................................................... 55
3.3.17
Relatório Semanal de Progresso n.º 17 ......................................................................... 56
3.3.18
Relatório Semanal de Progresso n.º 18 ......................................................................... 57
3.3.19
Relatório Semanal de Progresso n.º 19 ......................................................................... 58
Modelagem do Negócio .................................................................................................... 59
15
4.1
5
4.1.1
Ata n.º 01....................................................................................................................... 59
4.1.2
Ata n.º 02....................................................................................................................... 60
4.1.3
Ata n.º 03....................................................................................................................... 62
4.1.4
Ata n.º 04....................................................................................................................... 64
4.1.5
Ata n.º 05....................................................................................................................... 65
4.1.6
Ata n.º 06....................................................................................................................... 66
4.1.7
Ata n.º 07....................................................................................................................... 67
4.1.8
Ata n.º 08....................................................................................................................... 67
4.1.9
Ata n.º 09....................................................................................................................... 69
4.2
Descrição do Negócio ............................................................................................................ 70
4.3
Lista de Requisitos ................................................................................................................. 72
4.4
Lista de Regras de Negócio ................................................................................................... 73
4.5
Dificuldades encontradas no Negócio ................................................................................... 75
4.6
Definição do Problema .......................................................................................................... 76
4.7
Objetivo do Software ............................................................................................................ 76
4.8
Escopo do Software ............................................................................................................... 76
4.9
Clientes Alvo .......................................................................................................................... 77
4.10
Glossário do Negócio............................................................................................................. 77
Requisitos .......................................................................................................................... 78
5.1
6
Ata de Reunião ...................................................................................................................... 59
Especificação dos Requisitos ................................................................................................. 78
5.1.1
ERaF1.1 .......................................................................................................................... 78
5.1.2
ERaF2.1 .......................................................................................................................... 78
5.1.3
ERaF3.1 .......................................................................................................................... 79
5.1.4
ERaF4.1 .......................................................................................................................... 80
5.1.5
ERaF5.1 .......................................................................................................................... 80
5.1.6
ERaF6.1 .......................................................................................................................... 81
5.1.7
ERaF7.1 .......................................................................................................................... 81
5.1.8
ERaF8.1 .......................................................................................................................... 82
5.1.9
ERaF9.1 .......................................................................................................................... 83
5.1.10
ERaF10.1 ........................................................................................................................ 83
Modelagem de Casos de Uso ............................................................................................ 84
6.1
Relação de Casos de Uso ....................................................................................................... 84
16
6.2
Relação dos Atores ................................................................................................................ 84
6.2.1
Desenvolvedor............................................................................................................... 85
6.2.2
Componente .................................................................................................................. 85
6.3
Diagrama Geral de Casos de Uso .......................................................................................... 85
6.4
Detalhamento dos Casos de Uso........................................................................................... 85
6.4.1
[Caso de Uso] Criar conexões com os bancos de dados das aplicações ....................... 86
6.4.2
[Caso de Uso] Realizar conexão com o banco de dados do componente .................... 91
6.4.3
[Caso de Uso] Realizar conexão com o banco de dados da aplicação .......................... 93
6.4.4
[Caso de Uso] Configurar Framework ........................................................................... 96
6.4.5
[Caso de Uso] Configuração da execução do componente ........................................... 98
6.4.6
[Caso de Uso] Configurar interface gráfica ................................................................. 100
6.4.7
[Caso de Uso] Checar se existe entidade/view no banco de dados ............................ 103
6.4.8
[Caso de Uso] Validar se o tipo do campo no banco de dados é compatível com o tipo
do campo na interface ................................................................................................................ 106
7
6.4.9
[Caso de Uso] Criar SQL de consulta com base nos parâmetros informados ............. 108
6.4.10
[Caso de Uso] Realizar consulta .................................................................................. 111
6.4.11
[Caso de Uso] Retornar resultado de acordo com a função ....................................... 113
6.4.12
[Caso de Uso] Realizar consulta extra ......................................................................... 116
Modelagem de Dados ...................................................................................................... 120
7.1
Projeto Conceitual de Dados ............................................................................................... 120
7.2
Projeto Lógico de Dados...................................................................................................... 120
7.3
Script de Criação de Banco de Dados .................................................................................. 121
8
Especificação da Arquitetura .......................................................................................... 123
8.1
Diagrama de Componentes ................................................................................................. 123
8.2
Diagrama de Implantação ................................................................................................... 124
8.3
Diagrama de Pacotes ........................................................................................................... 125
9
Realização de Casos de Uso ............................................................................................ 126
9.1
Diagrama de Classe Conceitual ........................................................................................... 126
9.2
Diagrama de Classes do Projeto .......................................................................................... 126
9.3
Diagrama de Sequência ....................................................................................................... 130
9.4
Layout da Interface ............................................................................................................. 134
9.5
Diagrama Geral de Classes do Projeto ................................................................................ 135
10
Testes ........................................................................................................................... 136
17
10.1
Plano de Testes ................................................................................................................... 136
10.2
Casos de Testes ................................................................................................................... 136
10.3
Relatório de Testes .............................................................................................................. 140
11
Conclusão .................................................................................................................... 141
12
Referências .................................................................................................................. 142
13
Apêndices .................................................................................................................... 143
13.1
Apêndice A – Cronograma de Atividades do Trabalho de Conclusão de Curso .................. 143
13.2 Apêndice A – PÔSTER APRESENTADO NO III SIMPÓSIO DE TECNOLOGIA DA INFORMAÇÃO E
III SEMANA DE INICIAÇÃO CIENTÍFICA DO CURSO DE SISTEMAS DE INFORMAÇÃO UNUCETUEG/2011 ........................................................................................................................................ 144
13.3
Apêndice C – Configuração dos arquivos dataSource ......................................................... 145
13.4
Apêndice D – Configurando o banco de dados ................................................................... 146
13.5
Apêndice E – Exemplo de Uso ............................................................................................. 149
18
1
Lista de Elementos Gráficos
1.1 Lista de Tabelas
Tabela 1 – Tabela de Revisões ................................................................................................. 14
Tabela 2 – Lista de Abreviaturas nos Artefatos do Documento ............................................... 23
Tabela 3 – Elementos de Dados – Entidades ............................................................................ 24
Tabela 4 – Elementos de Dados - Campos ............................................................................... 25
Tabela 5 – Elementos de Dados – Filtro .................................................................................. 25
Tabela 6 – Elementos de Dados – Filtro_has_campos ............................................................. 25
Tabela 7 – Elementos de Dados - Pesquisa .............................................................................. 26
Tabela 8 – Elementos de Dados – Pesquisa_has_filtro ............................................................ 26
Tabela 9 – Elementos de Comportamento Entidades ............................................................... 27
Tabela 10 – Elementos de Comportamento Campos................................................................ 28
Tabela 11 – Elementos de Comportamento Filtro .................................................................... 28
Tabela 12 – Elementos de Comportamento Pesquisa ............................................................... 29
Tabela 13 – Elementos de Comportamento TipoCampo.......................................................... 30
Tabela 14 – Elementos de Comportamento TipoOperador ...................................................... 31
Tabela 15 – Elementos de Comportamento EntidadesDAO .................................................... 31
Tabela 16 – Elementos de Comportamento CamposDAO ....................................................... 32
Tabela 17 – Elementos de Comportamento FiltroDAO ........................................................... 32
Tabela 18 – Elementos de Comportamento PesquisaDAO ...................................................... 33
Tabela 19 – Elementos de Comportamento Select ................................................................... 33
Tabela 20 – Elementos de Comportamento ParametersSQL ................................................... 35
Tabela 21 – Elementos de Comportamento WhereClauses...................................................... 35
Tabela 22 - Relatório Semanal de Progresso n.º 01 ................................................................. 40
Tabela 23 - Relatório Semanal de Progresso n.º 02 ................................................................. 41
Tabela 24 - Relatório Semanal de Progresso n.º 03 ................................................................. 42
Tabela 25 - Relatório Semanal de Progresso n.º 04 ................................................................. 43
Tabela 26 - Relatório Semanal de Progresso n.º 05 ................................................................. 44
Tabela 27 - Relatório Semanal de Progresso n.º 06 ................................................................. 45
Tabela 28 - Relatório Semanal de Progresso n.º 07 ................................................................. 46
Tabela 29 - Relatório Semanal de Progresso n.º 08 ................................................................. 47
Tabela 30 - Relatório Semanal de Progresso n.º 09 ................................................................. 48
Tabela 31 - Relatório Semanal de Progresso n.º 10 ................................................................. 49
Tabela 32 - Relatório Semanal de Progresso n.º 11 ................................................................. 50
Tabela 33 - Relatório Semanal de Progresso n.º 12 ................................................................. 51
Tabela 34 - Relatório Semanal de Progresso n.º 13 ................................................................. 52
Tabela 35 - Relatório Semanal de Progresso n.º 14 ................................................................. 53
Tabela 36 - Relatório Semanal de Progresso n.º 15 ................................................................. 54
Tabela 37 - Relatório Semanal de Progresso n.º 16 ................................................................. 55
Tabela 38 - Relatório Semanal de Progresso n.º 17 ................................................................. 56
Tabela 39 - Relatório Semanal de Progresso n.º 18 ................................................................. 57
Tabela 40 - Relatório Semanal de Progresso n.º 19 ................................................................. 58
19
Tabela 41 – Ata de Reunião n.º 01 ........................................................................................... 59
Tabela 42 – Ata de Reunião n.º 02 ........................................................................................... 61
Tabela 43 – Ata de Reunião n.º 03 ........................................................................................... 63
Tabela 44 – Ata de Reunião n.º 04 ........................................................................................... 64
Tabela 45 – Ata de Reunião n.º 05 ........................................................................................... 65
Tabela 46 – Ata de Reunião n.º 06 ........................................................................................... 66
Tabela 47 – Ata de Reunião n.º 07 ........................................................................................... 67
Tabela 48 – Ata de Reunião n.º 08 ........................................................................................... 69
Tabela 49 – Ata de Reunião n.º 09 ........................................................................................... 69
Tabela 50 – Lista de Requisitos................................................................................................ 72
Tabela 51 – Lista de Regras de Negócio .................................................................................. 74
Tabela 52 – Dificuldades encontradas no negócio ................................................................... 75
Tabela 53 – Clientes Alvo ........................................................................................................ 77
Tabela 54 – Glossário do Negócio ........................................................................................... 78
Tabela 55 – Especificação do Requisito definir entidade a ser consultada .............................. 78
Tabela 56 – Especificação do Requisito definir os filtros de pesquisa .................................... 79
Tabela 57 – Especificação do Requisito definir os campos das entidades ............................... 80
Tabela 58 – Especificação do Requisito definir quais campos pertence a cada filtro .............. 80
Tabela 59 – Especificação do Requisito validar se o tipo do campo no banco de dados é
compatível com o tipo do campo na interface ................................................................... 81
Tabela 60 – Especificação do Requisito criar SQL de consulta com base nos parâmetros
informados ......................................................................................................................... 81
Tabela 61 – Especificação do Requisito Definir se o campo deverá realizar uma consulta extra
........................................................................................................................................... 82
Tabela 62 – Especificação do Requisito Checar se existe entidade/view no banco de dados .. 82
Tabela 63 – Especificação do Requisito Definir a consulta que o campo deverá executar para
apresentar os dados ............................................................................................................ 83
Tabela 64 – Especificação do Requisito Permitir a montagem de uma interface
dinamicamente para pesquisas e parâmetros de relatório .................................................. 84
Tabela 65 – Lista de Casos de Uso ........................................................................................... 84
Tabela 66 – Detalhamento Caso de Uso UC01 ........................................................................ 88
Tabela 67 – Detalhamento Caso de Uso UC02 ........................................................................ 92
Tabela 68 – Detalhamento Caso de Uso UC03 ........................................................................ 95
Tabela 69 – Detalhamento Caso de Uso UC04 ........................................................................ 97
Tabela 70 – Detalhamento Caso de Uso UC05 ...................................................................... 100
Tabela 71 – Detalhamento Caso de Uso UC06 ...................................................................... 102
Tabela 72 – Detalhamento Caso de Uso UC07 ...................................................................... 105
Tabela 73 – Detalhamento Caso de Uso UC08 ...................................................................... 107
Tabela 74 – Detalhamento Caso de Uso UC09 ...................................................................... 110
Tabela 75 – Detalhamento Caso de Uso UC10 ...................................................................... 112
Tabela 76 – Detalhamento Caso de Uso UC11 ...................................................................... 115
Tabela 77 – Detalhamento Caso de Uso UC12 ...................................................................... 118
Tabela 78 – Caso de Teste – Configurar framework .............................................................. 137
Tabela 79 – Caso de Teste – Preencher campo do tipo texto ................................................. 137
Tabela 80 – Caso de Teste – Preencher campo do tipo data .................................................. 138
Tabela 81 – Caso de Teste – Preencher campo do tipo combobox ........................................ 138
Tabela 82 – Caso de Teste – Preencher campo do tipo checkbox .......................................... 139
Tabela 83 – Caso de Teste – Preencher campo do tipo radio button ..................................... 139
20
Tabela 84 – Caso de Teste – Preencher campo do tipo lista de adição .................................. 140
Tabela 85 – Caso de Teste – Preencher campo do tipo lista de adição .................................. 140
1.2 Lista de Figuras
Figura 1 – Diagrama Geral de Caso de Uso ............................................................................. 85
Figura 2 – Diagrama de Atividade – UC01 Configurar ........................................................... 89
Figura 3 – Diagrama de Atividade – UC01 Alterar.................................................................. 90
Figura 4 – Diagrama de Atividade – UC02 Conectar .............................................................. 93
Figura 5 – Diagrama de Atividade – UC03 Conectar .............................................................. 96
Figura 6 – Diagrama de Atividade – UC04 Instanciar ............................................................. 98
Figura 7 – Diagrama de Atividade – UC05 Configurar ......................................................... 100
Figura 8 – Diagrama de Atividade – UC06 Configurar ......................................................... 103
Figura 9 – Diagrama de Atividade – UC07 Checar entidade/view ........................................ 105
Figura 10 – Diagrama de Atividade – UC08 Validar tipo campo .......................................... 108
Figura 11 – Diagrama de Atividade – UC09 Criar SQL ........................................................ 110
Figura 12 – Diagrama de Atividade – UC10 Consultar ......................................................... 113
Figura 13 – Diagrama de Atividade – UC11 Retornar resultado – Busca ............................. 115
Figura 14 – Diagrama de Atividade – UC11 Retornar resultado – Relatório ........................ 116
Figura 15 – Diagrama de Atividade – UC12 Realizar consulta extra – Buscar Textfield ..... 118
Figura 16 – Diagrama de Atividade – UC12 Realizar consulta extra – Buscar Lista de Adição
......................................................................................................................................... 119
Figura 17 – Diagrama de Atividade – UC12 Realizar consulta extra – Remover Lista de
Adição .............................................................................................................................. 119
Figura 18 – Projeto Conceitual ............................................................................................... 120
Figura 19 – Projeto Lógico ..................................................................................................... 120
Figura 20 – Diagrama de Componentes ................................................................................. 123
Figura 21 – Diagrama de Implantação ................................................................................... 124
Figura 22 – Diagrama de Pacotes Arquitetural ...................................................................... 125
Figura 23 – Diagrama de Classe Conceitual .......................................................................... 126
Figura 24 – DC de Projeto - Realizar Conexões .................................................................... 126
Figura 25 – DC de Projeto - Execução do Componente......................................................... 127
Figura 26 – DC de Projeto – Retorno do Resultado ............................................................... 128
Figura 27 – DC de Projeto – Realizar consulta extra ............................................................. 129
Figura 28 – Execução do Componente ................................................................................... 130
Figura 29 – Realizar consulta extra ........................................................................................ 130
Figura 30 – Escolha consulta extra ......................................................................................... 131
Figura 31 – Retorno do Resultado – BUSCA......................................................................... 132
Figura 32 – Retorno do Resultado – RELATÓRIO ............................................................... 133
Figura 33 – Interface de pesquisa ........................................................................................... 134
Figura 34 – Diagrama de Classes ........................................................................................... 135
Figura 35 – Cronograma de atividades proposto no projeto do Trabalho de Conclusão de
Curso ................................................................................................................................ 143
Figura 36 – Pôster – Framework de Aplicação ...................................................................... 144
Figura 37 – Configuração Tomcat .......................................................................................... 145
Figura 38 – Tabela de Pesquisa .............................................................................................. 146
21
Figura 39 – Tabela de Entidades ............................................................................................ 147
Figura 40 – Tabela de Campos ............................................................................................... 147
Figura 41 – Tabela de Filtro ................................................................................................... 148
Figura 42 – Tabela de vinculo entre Campos e Filtro ............................................................ 148
Figura 43 – Tabela de vinculo entre Filtro e Pesquisa ........................................................... 149
Figura 44 – Configuração do uso do componente no web.xml da aplicação web ................. 150
Figura 45 – Chamada ao componente da interface................................................................. 151
22
2
Dicionário do Projeto
2.1 Lista de Abreviaturas nos Artefatos do Documento
Artefato
Termo
ou Sigla
Significado
Elementos de Dados
D.C.C
Características
Conceitual
no
Diagrama
de
Classes
Elementos
de
Dados
e
Elementos de Comportamento
D.C.P
Características no Diagrama de Classes de
Projeto
Elementos de Dados
L.T
Características no Layout de Tabela
Elementos
de
Dados
e
Elementos de Comportamento
Item
Identificador único no artefato do diagrama
Elementos
de
Dados
e Artefato Elemento do diagrama
Elementos de Comportamento
Elementos de Comportamento Assinatura Assinatura do método
Cronograma
Atividade Atividade que precisa ser realizada.
Cronograma
Previsão Data planejada
concluída.
Cronograma
Entrega Data em que a atividade foi realmente entregue.
para
entrega
da
atividade
Tabela 2 – Lista de Abreviaturas nos Artefatos do Documento
2.2 Elementos de Dados
Artefato
Item
id
Entidades
Características
Identificador da
entidade da
aplicação para o
D.C.C
Numérico
D.C.P
Integer
L.T
Int
auto_increment
23
framework.
nome
Nome da entidade
na aplicação que
utilizará o
framework.
Texto
String
Varchar
isView
Define se a entidade
é uma view no
banco original da
aplicação.
Numérico
Byte
Tinyint
Tabela 3 – Elementos de Dados – Entidades
Artefato
Item
id
Campos
Características
D.C.C
D.C.P
Integer
L.T
Identificador do
campo da aplicação
para o framework.
Numérico
Int
nome
Nome do campo na
aplicação que
utilizará o
framework.
Texto
String
Varchar
consulta
SQL para trazer
dados e preencher o
campo na tela ou
realizar a consulta
extra.
Texto
String
Varchar
tipoCamp
oBanco
Tipo do campo no
banco de dados que
utiliza o framework.
Numérico
Enum
int
tipoCamp
oInterface
Tipo do campo que
deseja na interface.
Numérico
Enum
int
tipoOpera
dor
Tipo do operador
que será utilizado na
consulta para
comparação do
valor.
Numérico
Enum
int
auto_increment
24
idEntidad
e
Id da entidade a qual
pertence.
Numérico
Integer
int
Tabela 4 – Elementos de Dados - Campos
Artefato
Filtro
Item
id
Características
Identificador do
filtro.
D.C.C
Numérico
D.C.P
Integer
L.T
Int
auto_increment
label
Nome do filtro que
será apresentado na
interface gráfica.
Texto
String
Varchar
negar
Possibilidade de
inverter o operador
no momento da
consulta.
Numérico
Byte
Tinyint
campos
Lista de campos que
pertencem ao filtro.
Lista
List
Entidade
Tabela 5 – Elementos de Dados – Filtro
Artefato
filtro_has_campos
Item
Características
D.C.C
D.C.P
L.T
campos
Lista de campos que
pertencem ao filtro.
-
-
filtro_idFiltro
-
-
-
-
campos_idCampo
Tabela 6 – Elementos de Dados – Filtro_has_campos
25
Artefato
Pesquisa
Item
id
Características
Identificador da
pesquisa.
D.C.C
Numérico
D.C.P
Integer
L.T
Int
auto_increment
descricao
Descrição da
pesquisa que será
apresentado na
interface gráfica.
Texto
String
Varchar
ordemPes
quisa
Como o resultado da
pesquisa deverá ser
ordenado.(SQL)
Texto
String
Varchar
filtros
Lista de filtros que
pertencem à
pesquisa.
Lista
List
Entidade
Tabela 7 – Elementos de Dados - Pesquisa
Artefato
pesquisa_has_filtro
Item
Características
D.C.C
D.C.P
L.T
filtros
Lista de filtros que
pertencem à
pesquisa.
-
-
pesquisa_idPesquisa
-
-
-
-
filtro_idFiltro
Tabela 8 – Elementos de Dados – Pesquisa_has_filtro
26
2.3 Elementos de Comportamento
Artefato
Item
id
Entidades
Características
Get and Set do atributo.
Assinatura
getId()
setId(Integer id)
nome
Get and Set do atributo.
getNome()
setNome(String nome)
isView
Get and Set do atributo.
getIsView()
setIsView(Byte isView)
Tabela 9 – Elementos de Comportamento Entidades
Artefato
Item
id
Campos
Características
Get and Set do atributo.
Assinatura
getId()
setId(Integer id)
nome
Get and Set do atributo.
getNome()
setNome(String nome)
consulta
Get and Set do atributo.
getConsulta()
setConsulta(String consulta)
tipoCamp
oBanco
Get and Set do atributo.
getTipoCampoOperador()
setTipoCampoOperador(TipoCampo
tipoCampoBanco)
27
tipoCamp
oInterface
Get and Set do atributo.
getTipoCampoInterface()
setTipoCampoInterface(TipoCampo
tipoCampoInterface)
tipoOpera
dor
Get and Set do atributo.
getTipoOperador()
setTipoOperador(TipoOperador
tipoOperador)
idEntidad
e
Get and Set do atributo.
getIdEntidade()
setIdEntidade(Integer idEntidade)
Tabela 10 – Elementos de Comportamento Campos
Artefato
Item
id
Filtro
Características
Get and Set do atributo.
Assinatura
getId()
setId(Integer id)
label
Get and Set do atributo.
getLabel()
setLabel(String label)
negar
Get and Set do atributo.
getNegar()
setNegar(Byte negar)
campos
Get and Set do atributo.
getCampos()
setCampos(List<Campos> campos)
Tabela 11 – Elementos de Comportamento Filtro
Artefato
Item
id
Pesquisa
Características
Get and Set do atributo.
Assinatura
getId()
28
setId(Integer id)
descrição
Get and Set do atributo.
getDescricao()
setDescricao(String descricao)
ordemPes
quisa
Get and Set do atributo.
getOrdemPesquisa()
setOrdemPesquisa(String ordemPesquisa)
filtros
Get and Set do atributo.
getFiltros()
setFiltros(List<Filtros> filtros)
Tabela 12 – Elementos de Comportamento Pesquisa
Artefato
Item
id
TipoCampo
Características
Assinatura
Get and Set do atributo.
getId()
Representa o valor do banco de dados.
setId(Integer id)
Get and Set do atributo.
getTipo()
Representa o valor utilizado no html, para
os utilizados na interface gráfica (tela).
setTipo(String tipo)
TEXTFIE
LD
Atributo que representa o tipo do campo
na tela.
TEXTFIELD
COMBO
BOX
Atributo que representa o tipo do campo
na tela.
COMBOBOX
CHECKB
OX
Atributo que representa o tipo do campo
na tela.
CHECKBOX
RADIO_
BUTTON
Atributo que representa o tipo do campo
na tela.
RADIO_BUTTON
tipo
29
LISTA_A
DD
Atributo que representa o tipo do campo
na tela.
LISTA_ADD
TEXTUA
IS
Atributo que representa o tipo do campo
no banco.
TEXTUAIS
NUMERI
COS
Atributo que representa o tipo do campo
no banco.
NUMERICOS
DATA
Atributo que representa o tipo do campo
na tela e no banco.
DATA
Tabela 13 – Elementos de Comportamento TipoCampo
Artefato
Item
id
TipoOperador
Características
Assinatura
Get and Set do atributo.
getId()
Representa o valor do banco de dados.
setId(Integer id)
Get and Set do atributo.
getOperador()
Representa o valor utilizado no SQL.
setOperador(String operador)
IGUAL
Atributo que representa o operador
utilizado na montagem do SQL para o
campo.
TEXTFIELD
LIKE
Atributo que representa o operador
utilizado na montagem do SQL para o
campo.
LIKE
DIFERE
NTE
Atributo que representa o operador
utilizado na montagem do SQL para o
campo.
DIFERENTE
MAIOR
Atributo que representa o operador
utilizado na montagem do SQL para o
campo.
MAIOR
operador
30
MENOR
Atributo que representa o operador
utilizado na montagem do SQL para o
campo.
MENOR
BETWEE
N
Atributo que representa o operador
utilizado na montagem do SQL para o
campo.
BETWEEN
NOT
Atributo que representa o operador
utilizado na montagem do SQL para o
campo.
NOT
Tabela 14 – Elementos de Comportamento TipoOperador
Artefato
Item
EntidadesDAO
Características
Assinatura
buscaEnti
dadeById
Retorna o objeto de acordo com o id
passado por parâmetro.
buscaEntidadeById(Integer idEntidade) :
Entidades
doGetJD
BCViews
Verifica se o schema passado como
parâmetro é uma view.
doGetJDBCViews(String schemaName) :
Boolean
Tabela 15 – Elementos de Comportamento EntidadesDAO
Artefato
Item
CamposDAO
Características
Assinatura
getCampo
sByFiltro
Retorna a lista de campos do filtro
passado como parâmetro.
getCamposByFiltro(Integer idFiltro) :
List<Campos>
getCampo
ById
Retorna o objeto de acordo com o id
passado por parâmetro.
getCampoById(Integer idCampo) :
Campos
31
executarC
onsultaCa
mpo
Executa a consulta no banco de dados
cliente do campo e retorna a lista de
dados.
executarConsultaCampo(String consulta) :
List<Object>
setTipoCa
mpo
Seta o tipo do campo nos atributos
tipoCampo e tipoInterface.
setTipoCampo(Integer tipoCampo) :
TipoCampo
setTipoO
perador
Seta o tipo do campo no atributo
tipoOperador.
setTipoOperador(Integer tipoOperador) :
TipoOperador
Tabela 16 – Elementos de Comportamento CamposDAO
Artefato
Item
FiltroDAO
Características
Assinatura
camposD
AO
Representa uma instancia de
CamposDAO.
camposDAO
getFiltros
byPesquis
a
Retorna a lista de filtros da pesquisa
passada como parâmetro.
getFiltrosbyPesquisa(Integer idPesquisa) :
List<Filtros>
getFiltroB
yId
Retorna o objeto de acordo com o id
passado por parâmetro.
getFiltroById(Integer idFiltro) : Filtros
getCampo
sFiltro
Retorna a lista de campos do filtro
passado como parâmetro.
getCamposFiltro(Integer idFiltro) :
List<Campos>
Tabela 17 – Elementos de Comportamento FiltroDAO
Artefato
Item
PesquisaDAO
Características
Assinatura
32
filtrosDA
O
Representa uma instancia de FiltrosDAO.
filtrosDAO
getPesqui
saById
Retorna o objeto de acordo com o id
passado por parâmetro.
getPesquisaById(Integer idPesquisa) :
Pesquisa
getPesqui
saByDesc
ricao
Retorna o objeto de acordo com a
descrição passada por parâmetro.
getPesquisaByDescricao(String
nomePesquisa) : Pesquisa
getFiltros
Pesquisa
Retorna a lista de filtros da pesquisa
passada como parâmetro.
getFiltrosPesquisa(Integer idPesquisa) :
List<Filtros>
Tabela 18 – Elementos de Comportamento PesquisaDAO
Artefato
Item
select
Select
Características
Get and Set do atributo.
Assinatura
getSelect()
setSelect(String select)
parameter
Get and Set do atributo.
getParameters()
setParameters(List<Object>)
Tabela 19 – Elementos de Comportamento Select
Artefato
Item
value
ParametersSQL
Características
Assinatura
Get and Set do atributo.
getValue()
Representa o valor do campo para
montagem do SQL.
setValue(String id)
33
SELECT
Atributo que representa a constante
utilizada na montagem do SQL.
SELECT
FROM
Atributo que representa a constante
utilizada na montagem do SQL.
FROM
WHERE
Atributo que representa a constante
utilizada na montagem do SQL.
WHERE
ORDER_
BY
Atributo que representa a constante
utilizada na montagem do SQL.
ORDER_BY
SPACE
Atributo que representa um espaço para a
montagem do SQL.
SPACE
COMMA
Atributo que representa uma vírgula para
a montagem do SQL.
COMMA
OR
Atributo que representa a constante
utilizada na montagem do SQL.
OR
AND
Atributo que representa a constante
utilizada na montagem do SQL.
AND
PARENT Atributo que representa a abertura de um
HESES_L parêntese para a montagem do SQL.
EFT
PARENTHESES_LEFT
PARENT
HESES_
RIGHT
Atributo que representa o fechamento de
um parêntese para a montagem do SQL.
PARENTHESES_RIGHT
QUERY
Atributo que representa os parâmetros da
consulta com ? para substituição pelo
valor a ser pesquisado na montagem do
SQL.
QUERY
ASTERIS
K
Atributo que representa um asterisco (*)
para a montagem do SQL.
ASTERISK
34
QUOTE
Atributo que representa uma aspa simples
para a montagem do SQL.
QUOTE
Tabela 20 – Elementos de Comportamento ParametersSQL
Artefato
Item
rightPara
meter
WhereClauses
Características
Get and Set do atributo.
Assinatura
getRightParameter()
setRightParameter(String rightParameter)
secondRi
ghtParam
eter
Get and Set do atributo.
operand
Get and Set do atributo.
getSecondRightParameter()
setSecondRightParameter(String
secondRightParameter)
getOperand()
setOperand(String operand)
leftParam
eter
Get and Set do atributo.
getLeftParameter()
setLeftParameter(String leftParameter)
nextOpera Get and Set do atributo.
nd
getNextOperand()
setNextOperand(String nextOperand)
Tipo
Get and Set do atributo.
getTipo()
setTipo(TipoCampo tipo)
Tabela 21 – Elementos de Comportamento WhereClauses
35
3
Gerência do Projeto
3.1 Cronograma de Atividades
Incremento
1ª Iteração
o
Definição do projeto a ser desenvolvido
o
Elaboração do pré-projeto
o
Conclusão e entrega do pré-projeto
2ª Iteração
o
Adequação da documentação antiga e especificação
dos novos requisitos definidos
o
Validação dos requisitos
o
Detalhamento dos casos de uso e validação.
3ª Iteração
o
Correções necessárias e finalização do projeto.
o
Entrega do projeto para realização da banca.
4ª Iteração
o
Implementação dos casos de uso definidos.
o
Realização de testes
Previsão
Entrega
08/04/2011
02/06/2011
08/11/2011
13/11/2011
36
3.2 Processos de Desenvolvimento do Software
1. Etapa 1 – Conhecimento do negócio e do domínio da aplicação
1.1. Estudo sobre o projeto proposto através de DMSs anteriores e pesquisas de um modo geral
sobre frameworks.
1.2. Objetivo: Não focar no desenvolvimento. Procurar entender os conceitos e o objetivo da
solução proposta.
1.3. Problemas encontrados:
1.3.1. Aplicação de domínio genérico.
1.3.2. Aplicação dos conceitos de Orientação a Objetos.
1.3.3. Complexidade do desenvolvimento de um framework.
1.3.4. Criação de interfaces e relatórios gerenciados pelo banco de dados. (regras definidas no
banco)
2. Etapa 2 – Definição das funcionalidades do componente do projeto
2.1. Partir do pressuposto que as funcionalidades do componente já foram identificadas.
2.2. Escolher a funcionalidade a ser trabalhada.
2.3. Identificar os atributos da funcionalidade. (repetição)
2.3.1. Identificar o tipo de dado/objeto e tamanho se necessário.
2.4. Identificar os métodos.
2.4.1. Identificar as assinaturas do método.
2.5. Definição da interface da funcionalidade.
2.6. Saídas: interface da funcionalidade definida.
3. Etapa 3 – Levantamento e Análise de Requisitos
3.1. Reunir com o orientador para definir o que o framework deverá fazer.
3.1.1. A partir das necessidades do cliente definir os requisitos do sistema.
3.1.2. Saídas: Atas de reunião, definição dos requisitos e regras de negócio.
3.2. Produção da especificação dos requisitos definidos e adaptação de requisitos anteriores de
acordo com a necessidade do projeto.
37
3.2.1. Especificar os requisitos definidos nas reuniões de acordo com a tabela definida.
Informar: definição, especificação, regras de negócio associadas, risco e descrição do
risco e a interação que será entregue.
3.2.2. Entradas: Atas de reunião, definição dos requisitos e regras de negócio.
3.2.3. Saídas: Especificação dos requisitos, incluindo requisitos não funcionais. Validação dos
requisitos e aprovação.
4. Etapa 4 – Definição e Detalhamento dos Casos de Uso
4.1. Definição de casos de uso de acordo com os requisitos aprovados e casos de uso que surjam a
partir de outros casos de uso.
4.2. Entradas: Especificação de requisitos e casos de usos anteriores.
4.3. Saídas: Detalhamento dos casos de usos encontrados e definidos, diagramas de atividade por
caso de uso, diagrama de caso de uso, diagrama de sequencia e de classe. Validação do
detalhamento.
5. Projeto arquitetural
5.1. Entradas: definição das funcionalidades do componente.
5.2. Escolher a funcionalidade a ser trabalhada. (repetição)
5.2.1. Identificar as tabelas necessárias para o funcionamento da funcionalidade.
5.2.2. Identificar os atributos que deverão ser guardados e os seus tipos. O que o usuário
deverá informar para que o componente funcione.
5.2.3. Definir os relacionamentos necessários entre as tabelas e as transposições de chaves.
5.3. Saídas: diagrama de componentes e definição de camadas, elaboração do diagrama de classe,
diagrama de pacotes, projeto lógico do banco de dados, script.
6. Etapa 5 – Implementação
6.1. Codificação dos casos de uso definidos, detalhados e aprovados.
6.2. Entradas: Análise completa do sistema.
6.3. Saídas: Funcionalidades implementadas e classes de teste elaboradas. Realização dos casos de
uso.
7. Testes
7.1. Execução dos testes elaborados.
7.1.1. Entradas: classes de testes elaboradas.
7.1.2. Saídas: execução dos testes e elaboração dos relatórios.
38
8. Treinamento do uso do framework
8.1. Elaboração de um manual para uso do framework.
8.2. Entradas: Framework concluído, ambiente necessário configurado.
8.3. Saídas: Manual com ensinamentos do uso do framework.
9. Manutenção e Evolução
9.1. Correções ou implementação de novos casos de uso.
9.2. Entradas: Framework em uso pelo cliente.
9.3. Saídas: correção de uma funcionalidade já existente ou implementação de novos casos de uso
para
o
framework.
39
3.3 Relatório Semanal de Progresso
3.3.1 Relatório Semanal de Progresso n.º 01
Relatório Semanal de Progresso
Período
N.º 01
21/02/2011 á 26/02/2011
Atividade
Planejada
Entrar em contato com o orientador para discutir sobre o projeto a ser
desenvolvido.
Atividade
Realizada
Email encaminhado ao orientador informando ausência no período e intenção
de marcar reunião. Aguardando contato.
Próximo Período
28/02/2011 á 05/03/2011
Planejado para o
próximo período
Reunião com o orientador para definição do projeto.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 22 - Relatório Semanal de Progresso n.º 01
40
3.3.2 Relatório Semanal de Progresso n.º 02
Relatório Semanal de Progresso
Período
N.º 02
28/02/2011 á 05/03/2011
Atividade
Planejada
Reunir-se para definição do projeto.
Atividade
Realizada
Não houve atividade.
Próximo Período
07/02/2011 á 12/03/2011
Planejado para o
próximo período
Entregar termo de aceite ao orientador. Definir o projeto a ser desenvolvido.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 23 - Relatório Semanal de Progresso n.º 02
41
3.3.3 Relatório Semanal de Progresso n.º 03
Relatório Semanal de Progresso
Período
Atividade
Planejada
Atividade
Realizada
N.º 03
07/02/2011 á 12/03/2011
Entregar termo de aceite ao orientador. Definir o projeto a ser desenvolvido.
Foi feita a entrega do termo de aceite. Conversamos e definimos que o projeto a
ser desenvolvido seria a criação de dois componentes para um framework de
aplicação que já vem sendo desenvolvido. Os componentes definidos foram o
de pesquisa e parâmetro de relatório.
Próximo Período
14/03/2011 á 19/03/2011
Planejado para o
próximo período
Reunião com o orientador para melhor discutir sobre o projeto proposto.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 24 - Relatório Semanal de Progresso n.º 03
42
3.3.4 Relatório Semanal de Progresso n.º 04
Relatório Semanal de Progresso
Período
Atividade
Planejada
Atividade
Realizada
N.º 04
14/03/2011 á 19/03/2011
Reunir-se com o orientador para discutir sobre o projeto proposto.
Foi marcada uma reunião para o dia 14/03, mas por motivos pessoais o
orientador não pode comparecer. A reunião foi remarcada para o dia 18/03 onde
o orientador apresentou dois componentes a serem desenvolvidos e solicitou
que estudasse os DMSs anteriores de formandos que já haviam iniciado o
desenvolvimento do framework. No mesmo dia solicitei os DMSs na biblioteca.
Consegui os do ano de 2008, dos formandos Joseph e Sandoval.
Próximo Período
21/03/2011 á 26/03/2011
Planejado para o
próximo período
Estudar os DMSs anteriores sobre o projeto e solicitar ao orientador a
possibilidade de conseguir os DMSs dos anos mais recentes (2009 e 2010).
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 25 - Relatório Semanal de Progresso n.º 04
43
3.3.5 Relatório Semanal de Progresso n.º 05
Relatório Semanal de Progresso
Período
N.º 05
21/03/2011 á 26/03/2011
Atividade
Planejada
Estudar os DMSs anteriores sobre o projeto e solicitar ao orientador a
possibilidade de conseguir os DMSs dos anos mais recentes (2009 e 2010).
Atividade
Realizada
Após ler os DMSs, entrei em contato com o orientador para apresentar o que já
havia lido. O orientador informou que procuraria conseguir os DMSs mais
recentes. Foi acordado que o desenvolvimento dois componentes seria,
inicialmente, possível e que seria iniciada a elaboração do pré-projeto.
Próximo Período
28/03/2011 á 02/04/2011
Planejado para o
próximo período
Avançar na preparação do pré-projeto visando compensar os atrasos.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 26 - Relatório Semanal de Progresso n.º 05
44
3.3.6 Relatório Semanal de Progresso n.º 06
Relatório Semanal de Progresso
Período
N.º 06
28/03/2011 á 02/04/2011
Atividade
Planejada
Avançar na preparação do pré-projeto visando compensar os atrasos.
Atividade
Realizada
Inicio da elaboração do pré-projeto
Próximo Período
04/04/2011 á 09/04/2011
Planejado para o
próximo período
Reunir-se com o orientador para apresentar uma prévia do pré-projeto e definir
algo que esteja faltando. Entregar o pré-projeto.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 27 - Relatório Semanal de Progresso n.º 06
45
3.3.7 Relatório Semanal de Progresso n.º 07
Relatório Semanal de Progresso
Período
N.º 07
04/04/2011 á 09/04/2011
Atividade
Planejada
Reunir-se com o orientador para apresentar uma prévia do pré-projeto e definir
os requisitos. Entregar o pré-projeto.
Atividade
Realizada
Reunião realizada com o orientador. Discussão sobre o que deveria ser
corrigido. Discussão sobre os requisitos a serem definidos.
Próximo Período
11/04/2011 á 16/04/2011
Planejado para o
próximo período
Definição do processo de desenvolvimento do projeto.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 28 - Relatório Semanal de Progresso n.º 07
46
3.3.8 Relatório Semanal de Progresso n.º 08
Relatório Semanal de Progresso
N.º 08
Períodos
02/05/2011 á 07/05/2011
Atividade
Planejada
Definição do processo de desenvolvimento do projeto.
Atividade
Realizada
Processo de definição dos componentes do projeto. Definição dos artefatos do
componente de pesquisa.
Próximo Período
09/05/2011 á 14/05/2011
Planejado para o
próximo período
Continuar a definição do processo de desenvolvimento.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 29 - Relatório Semanal de Progresso n.º 08
47
3.3.9 Relatório Semanal de Progresso n.º 09
Relatório Semanal de Progresso
N.º 09
Períodos
09/05/2011 á 14/05/2011
Atividade
Planejada
Continuar a definição do processo de desenvolvimento. Tirar dúvidas sobre o
componente de relatórios.
Atividade
Realizada
Não houve atividades.
Próximo Período
16/05/2011 á 21/05/2011
Planejado para o
próximo período
Continuar a definição do processo de desenvolvimento. Tirar dúvidas sobre o
componente de relatórios.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 30 - Relatório Semanal de Progresso n.º 09
48
3.3.10 Relatório Semanal de Progresso n.º 10
Relatório Semanal de Progresso
N.º 10
Períodos
16/05/2011 á 21/05/2011
Atividade
Planejada
Continuar a definição do processo de desenvolvimento. Tirar dúvidas sobre o
componente de relatórios.
Atividade
Realizada
Reunião com o orientador, dúvidas sobre o componente de relatório sanadas.
Próximo Período
23/05/2011 á 28/05/2011
Planejado para o
próximo período
Elaboração do processo para definição da estrutura do banco de dados para os
componentes. Definição da estrutura do banco para o componente de relatório.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 31 - Relatório Semanal de Progresso n.º 10
49
3.3.11 Relatório Semanal de Progresso n.º 11
Relatório Semanal de Progresso
N.º 11
Períodos
23/05/2011 á 28/05/2011
Atividade
Planejada
Elaboração do processo para definição da estrutura do banco de dados para os
componentes. Definição da estrutura do banco para o componente de relatório.
Atividade
Realizada
Elaboração do processo para definição da estrutura do banco de dados para os
componentes. Definição da estrutura do banco para o componente de relatório.
Próximo Período
-
Planejado para o
próximo período
Definir o processo de especificação de requisitos e inicia-lo.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 32 - Relatório Semanal de Progresso n.º 11
50
3.3.12 Relatório Semanal de Progresso n.º 12
Relatório Semanal de Progresso
N.º 12
Períodos
29/08/2011 á 03/09/2011
Atividade
Planejada
Definir o processo de especificação de requisitos e inicia-lo.
Definição do processo de especificação de requisitos.
Atividade
Realizada
Reunião com o orientador e definição de que os componentes suportariam um
novo tipo, lista de adição, a possibilidade de negar o valor preenchido em um
campo da tela e os retornos de cada componente.
Próximo Período
-
Planejado para o
próximo período
Realizar a especificação de requisitos.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 33 - Relatório Semanal de Progresso n.º 12
51
3.3.13 Relatório Semanal de Progresso n.º 13
Relatório Semanal de Progresso
Períodos
05/09/2011 á 10/09/2011
Atividade
Planejada
Realizar a especificação de requisitos.
Atividade
Realizada
Especificação dos requisitos. Criação de um projeto no Google Code para
manter o repositório dos arquivos do projeto de graduação e os logs das
atividades.
Próximo Período
-
Planejado para o
próximo período
Definição dos casos de uso e especificação.
Avaliação do
Período de
Trabalho pelo
orientador
N.º 13
Ótimo
Bom
Regular
Ruim
Tabela 34 - Relatório Semanal de Progresso n.º 13
52
3.3.14 Relatório Semanal de Progresso n.º 14
Relatório Semanal de Progresso
N.º 14
Períodos
19/09/2011 á 24/09/2011
Atividade
Planejada
Definição dos casos de uso e especificação.
Atividade
Realizada
Preenchimento da ata de reunião realizada no dia 02/09/2011. Definição dos
casos de uso e criação do diagrama de caso de uso.
Próximo Período
26/09/2011 á 01/10/2011
Planejado para o
próximo período
Detalhamento dos casos de uso.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 35 - Relatório Semanal de Progresso n.º 14
53
3.3.15 Relatório Semanal de Progresso n.º 15
Relatório Semanal de Progresso
Períodos
26/09/2011 á 01/10/2011
Atividade
Planejada
Detalhamento dos casos de uso.
N.º 15
Alteração da modelagem do banco de dados. Início do detalhamento dos casos
de uso.
Atividade
Realizada
Reunião com orientador em que foi definido que colocaríamos exemplos nas
especificações dos requisitos. Exemplos inseridos. Orientador sugeriu que
começasse o diagrama de classes, os modelos de dados e testes, deixando
somente a realização de casos de uso para fazermos.
Dúvidas quanto ao preenchimento do dicionário do projeto, contratos de
operação dos casos de uso e se pode existir algum caso de uso que não foi
definido. Orientador irá enviar exemplos para o preenchimento e verificar a
existência de mais algum caso de uso. Dúvida quanto às exceções definidas
para o caso de uso. São realmente exceções e não fluxos alternativos.
Definido que a aplicação será realmente web.
Próximo Período
03/10/2011 á 08/10/2011
Planejado para o
próximo período
Finalização do detalhamento dos casos de uso. Diagrama de classes, modelos
de dados e testes.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 36 - Relatório Semanal de Progresso n.º 15
54
3.3.16 Relatório Semanal de Progresso n.º 16
Relatório Semanal de Progresso
N.º 16
Períodos
03/10/2011 á 08/10/2011
Atividade
Planejada
Finalização do detalhamento dos casos de uso. Diagrama de classes, modelos de
dados e testes.
Continuação do detalhamento dos casos de uso. Criação do ER do banco de
dados e do script.
Atividade
Realizada
Início da programação com a realização dos casos de uso 1 e 2. Elaboração do
apêndice A que apresenta ao usuário a configuração do caminho dos arquivos
de conexão com o banco de dados.
Reunião com orientador, dúvidas quanto ao preenchimento do dicionário do
projeto, contratos de operação dos casos de uso e se pode existir algum caso de
uso que não foi definido, ainda não sanadas. Orientador irá enviar exemplos
para o preenchimento.
Próximo Período
10/10/2011 á 15/10/2011
Planejado para o
próximo período
Finalização do detalhamento dos casos de uso. Diagrama de classes, modelos de
dados e testes.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 37 - Relatório Semanal de Progresso n.º 16
55
3.3.17 Relatório Semanal de Progresso n.º 17
Relatório Semanal de Progresso
N.º 17
Períodos
10/10/2011 á 15/10/2011
Atividade
Planejada
Finalização do detalhamento dos casos de uso. Diagrama de classes, modelos de
dados e testes.
Finalização da modelagem de dados.
Finalização do detalhamento dos casos de uso. Criação dos diagramas de
atividade, componentes, implantação e pacotes.
Atividade
Realizada
Realização dos casos de uso faltando apenas a interface gráfica.
Programação para montagem da tela de pesquisa. Não será possível realizar as
realizações dos casos de uso como planejado. Nova definição de programação.
Foram feitos testes em uma nova maneira de implementação que irei adotar.
Próximo Período
Planejado para o
próximo período
Avaliação do
Período de
Trabalho pelo
orientador
10/10/2011 á 15/10/2011
Alterar os casos de uso, os diagramas e a realização dos casos de uso.
Reiniciar a programação dos casos de uso.
Ótimo
Bom
Regular
Ruim
Tabela 38 - Relatório Semanal de Progresso n.º 17
56
3.3.18 Relatório Semanal de Progresso n.º 18
Relatório Semanal de Progresso
Períodos
Atividade
Planejada
N.º 18
17/10/2011 á 22/10/2011
Alterar os casos de uso, os diagramas e a realização dos casos de uso.
Reiniciar a programação dos casos de uso.
Casos de uso alterados para a nova programação. Alteração dos diagramas de
acordo com a necessidade da nova programação.
Atividade
Realizada
Reunião com orientador. As dúvidas quanto ao dicionário do projeto foram
sanadas. Foi definido que não seria feita a definição dos valores padrões para os
campos. Quanto à implementação seria apresentado à montagem da tela até a
próxima sexta, dia 28/10.
Preenchimento das atas de reunião conforme solicitado.
Inicio da definição do dicionário do projeto.
Próximo Período
24/10/2011 á 29/10/2011
Planejado para o
próximo período
Implementação dos casos de uso. Criação dos casos de teste. Criação do
apêndice B que será usando da realização do caso de teste. Criação da
conclusão. Conclusão do dicionário do projeto.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 39 - Relatório Semanal de Progresso n.º 18
57
3.3.19 Relatório Semanal de Progresso n.º 19
Relatório Semanal de Progresso
N.º 19
Períodos
24/10/2011 á 29/10/2011
Atividade
Planejada
Implementação dos casos de uso. Criação dos casos de teste. Criação do
apêndice B que será usando da realização do caso de teste. Criação da
conclusão. Conclusão do dicionário do projeto.
Atividade
Realizada
Inicio da implementação e conclusão do dicionário do projeto. Criação dos
casos de teste. Criação do apêndice B que será usando da realização do caso de
teste. Criação da conclusão.
Próximo Período
-
Planejado para o
próximo período
Continuação da implementação dos casos de uso.
Avaliação do
Período de
Trabalho pelo
orientador
Ótimo
Bom
Regular
Ruim
Tabela 40 - Relatório Semanal de Progresso n.º 19
58
4
Modelagem do Negócio
4.1 Ata de Reunião
4.1.1 Ata n.º 01
ATA da Reunião n.º 01
Data
Horário
Local
18/03/2011
Das 20h00m às 20h30m
Sala de aula do 4º ano de Sistemas de Informação
na UEG-UnUCET
Equipe técnica
Amanda Barbosa Silva
Equipe usuária
Leandro Doutor Branquinho
Teor desta reunião
A reunião foi realizada no local e no horário agendado.
Ao iniciar a reunião o senhor Leandro propôs o desenvolvimento de dois componentes para o
framework de aplicação. A criação de um componente de pesquisa e de um componente de parâmetro
de relatório que fosse gerenciado pelo banco de dados. Isso facilitaria para o desenvolvedor de
software que utilizasse o framework nas mudanças das interfaces e views de relatórios sem a
necessidade de recompilar as classes do sistema.
O orientador Leandro solicitou que fossem estudados os DMSs anteriores relativos a esse mesmo
projeto dos alunos formandos dos anos de 2008, 2009 e 2010. A preocupação inicial é o entendimento
do projeto e dos conceitos relacionados e o esclarecimento de dúvidas.
Observação Importante
O objetivo da reunião foi apresentar o que o projeto a ser desenvolvido envolveria e busca de
conhecimento sobre o projeto e seu domínio.
Requisitos Registrados
Os componentes deverão ser gerenciados pelo banco de dados.
Tabela 41 – Ata de Reunião n.º 01
59
4.1.2 Ata n.º 02
ATA da Reunião n.º 02
Data
Horário
Local
07/04/2011
Das 20h30m às 21h00m
Ateliê de Arquitetura na UEG-UnUCET
Equipe técnica
Amanda Barbosa Silva
Equipe usuária
Leandro Doutor Branquinho
Teor desta reunião
A reunião foi realizada no local combinado. O horário da reunião foi das 21h30m às 22h10m.
Ao iniciar a reunião o senhor Leandro verificou o que já havia sido desenvolvido para o pré-projeto a
ser entregue.
Foram realizadas algumas correções. Foi definido que não utilizaríamos o termo “reutilização de
código”, devido ao fato de estarmos desenvolvendo um framework que reutilizará tanto código
quanto interface, ou seja, reutilizará o projeto. A reutilização de um framework possui maior
abrangência do que apenas o reuso de código.
Acordamos que o framework seria capaz de trabalhar com views no banco de dados, e que existiria
uma entidade que guardaria o SQL da tabela ou a view, no caso componente de relatório. Poderíamos
também utilizar o próprio componente de pesquisa no componente de parâmetro de relatório. Quanto
a isso, o senhor Leandro informou que possui um framework desenvolvido por ele que reutiliza os
componentes, como sugeriu, só que as regras ainda estão no código-fonte, e não gerenciadas pelo
banco de dados.
Resolvemos que ainda não iriamos definir a linguagem a ser utilizada no desenvolvimento, assim
como o banco de dados a ser utilizado.
Observação Importante
O objetivo da reunião foi verificar o andamento do pré-projeto e iniciar a definição de requisitos e
regras de negócio do sistema.
Requisitos Registrados
60
Definir entidade a ser consultada
Definir campos da entidade pelo qual deseja consultar
Definir o tipo do campo na interface
Definir a quais campos da entidade o campo da interface deve consultar
Definir o tipo da consulta a ser executada para os campos da interface
Criar SQL de consulta com base nos parâmetros informados
Criar view no banco de dados
Checar se existe entidade/view no banco de dados
Tabela 42 – Ata de Reunião n.º 02
61
4.1.3 Ata n.º 03
ATA da Reunião n.º 03
Data
Horário
Local
02/05/2011
Das 21h00m às 22h30m
Sala de aula do 4º ano de Sistemas de Informação
na UEG-UnUCET
Equipe técnica
Amanda Barbosa Silva
Equipe usuária
Leandro Doutor Branquinho
Teor desta reunião
A reunião foi realizada no horário e no local combinado.
Ao iniciar a reunião acordamos que seguiríamos um processo de software bem definido. Para isso,
iriamos definir os processos.
Um processo já havia sido definido. Como a parte de conhecimento do negócio já havia sido realizada,
iniciamos com a definição dos componentes do projeto.
Foi definido no processo:
Definição dos componentes do projeto
1.1. Partir do pressuposto que os componentes já foram identificados.
1.2. Escolher o componente a ser trabalhado.
1.3. Identificar os atributos do componente. (repetição)
1.3.1. Identificar o tipo de dado/objeto e tamanho se necessário.
1.4. Identificar os métodos.
1.4.1. Identificar as assinaturas do método.
1.5. Definição da interface do componente.
1.6. Saídas: interface do componente definida.
Após definir o processo realizamos a definição do componente de pesquisa.

Componente de Pesquisa
o Conexão com Banco de Dados
o Entidade do banco
62

Nome da entidade
o Lista de campos

Titulo do campo (label)

Tipo de controle de interface

Tipo do campo no banco

Critério pesquisa (na consulta)

Critério exibição (tela)

Ordem de pesquisa

Ordem de exibição
o Métodos do componente

Conectar (Connection conexao): boolean

Executar (nome componente)

configurarInterface() - campos do componente

exibirJanela()

realizarConsulta() – resultado da consulta

getResultado
o Interface do componente

Executar

getResultado
Talvez continuaríamos a definição do processo no outro dia.
Observação Importante
O objetivo da reunião foi definir o processo de desenvolvimento de software.
Requisitos Registrados
Nenhum requisito registrado.
Tabela 43 – Ata de Reunião n.º 03
63
4.1.4 Ata n.º 04
ATA da Reunião n.º 04
Data
Horário
Local
17/05/2011
Das 21h30m às 22h30m
Sala de aula do 4º ano de Sistemas de Informação
na UEG-UnUCET
Equipe técnica
Amanda Barbosa Silva
Equipe usuária
Leandro Doutor Branquinho
Teor desta reunião
A reunião foi realizada no local combinado. O horário da reunião foi das 21h30m às 22h10m.
Ao iniciar a reunião apresentei ao professor que ainda tinha dúvidas no componente de relatórios do
framework. O professor fez alguns desenhos, primeiro exemplificando como seria a visão do usuário
final, com os campos de pesquisa disponíveis. Ao clicar no botão seria executado um select ou uma
view e seria apresentado o relatório para o usuário, com a utilização de uma ferramenta de relatórios
que montasse o resultado da consulta.
Depois fomos para a visão do programador, o usuário. Em que ele teria que definir, via banco de
dados, um relatório com cada campo com um label e um tipo. E via programação chamar a execução
do componente para renderização.
Por último, a visão do framework, o componente em si. O componente teria que montar o SQL,
associar o dataset ao relatório e exibir a janela montada na página.
Com essas as discussões sobre o componente de parâmetro de relatório surgiram mais algumas
dúvidas sobre as views. Foi acordado que o sistema trabalharia com as views como se fossem
entidades, sendo possível pesquisar os dados dentro de uma view.
Para melhores esclarecimentos, o senhor Leandro sugeriu que eu definisse o processo de
desenvolvimento de software para a arquitetura do banco de dados de cada componente e montasse a
arquitetura para o componente de relatório.
Observação Importante
O objetivo da reunião foi esclarecer dúvidas sobre o componente de relatório.
Requisitos Registrados
Nenhum requisito registrado.
Tabela 44 – Ata de Reunião n.º 04
64
4.1.5 Ata n.º 05
ATA da Reunião n.º 05
Data
Horário
Local
02/09/2011
Das 20h00m às 21h00m
Sala dos professores na UEG-UnUCET
Equipe técnica
Amanda Barbosa Silva
Equipe usuária
Leandro Doutor Branquinho
Teor desta reunião
A reunião ocorreu conforme combinado.
Durante a reunião foi decidido que a interface gráfica suportaria mais um tipo de campo além de text,
checkbox, radio button e combobox, que seria a lista de adição. O usuário poderia digitar um texto
livre em um campo do tipo text e incluir na listagem ou selecionar um texto já inserido na listagem e
remover.
Também foi acordado que o usuário poderia negar a condição colocada na tela. Ao invés de pesquisar
pelo que está colocando no campo, seria pesquisar o que não foi preenchido.
Decidimos que o componente de pesquisa (formulário) retornaria uma chave primária (que representa
o registro pesquisado) e que o relatório retornaria uma string que representa o select gerado
dinamicamente pelo componente. Nesse último caso, o desenvolvedor poderia executar o SQL e
manipular os dados retornados montando um relatório em pdf (por exemplo).
Observação Importante
Cada campo da tela será pesquisado no select por „and‟. Os dados inseridos na caixa de seleção serão
pesquisados por „or‟.
Requisitos Registrados
Nenhum requisito registrado.
Tabela 45 – Ata de Reunião n.º 05
65
4.1.6 Ata n.º 06
ATA da Reunião n.º 06
Data
Horário
Local
01/10/2011
Das 10h00m às 11h00m
Online – mensagens instantâneas
Equipe técnica
Amanda Barbosa Silva
Equipe usuária
Leandro Doutor Branquinho
Teor desta reunião
A reunião ocorreu conforme combinado.
Na reunião, o DMS preenchido até o momento foi enviado para o professor. O orientador realizou uma
rápida avaliação e sugeriu que colocasse exemplos de preenchimento nas especificações dos requisitos
devido à complexidade de entendimento do detalhamento.
Sugeriu também que começasse o diagrama de classes, os modelos de dados e testes, deixando
somente a realização de casos de uso para fazermos posteriormente.
Informei que possuía dúvidas quanto ao preenchimento do dicionário do projeto, contratos de
operação dos casos de uso e se poderia existir algum caso de uso que não foi definido. Orientador
informou que irá enviar exemplos para o preenchimento e avaliar o DMS enviando um feedback até o
início da próxima semana.
No detalhamento dos casos de uso coloquei algumas exceções, mas estava com dúvida quanto a serem
realmente exceções ou fluxos alternativos. Orientador verificou e informou que são realmente
exceções.
Estava com dúvidas quanto a fazer uma aplicação desktop ou web devido as tecnologias que poderia
utilizar. Possuo mais facilidade em utilizar html e servlet do que o swing. Definido, então, que a
aplicação será realmente web.
Foi decidido que seria desenvolvido um único componente com as funcionalidades de pesquisa e
parâmetro de relatório.
Observação Importante
A aplicação será web.
O objetivo da reunião foi sanar as dúvidas quanto ao preenchimento do DMS.
Requisitos Registrados
Nenhum requisito registrado.
Tabela 46 – Ata de Reunião n.º 06
66
4.1.7 Ata n.º 07
ATA da Reunião n.º 07
Data
Horário
Local
08/10/2011
Das 10h00m às 11h00m
Online – mensagens instantâneas
Equipe técnica
Amanda Barbosa Silva
Equipe usuária
Leandro Doutor Branquinho
Teor desta reunião
A reunião ocorreu conforme combinado.
O DMS foi enviado anteriormente para que o orientador pudesse avaliar.
Informei novamente sobre as dúvidas quanto ao preenchimento do dicionário do projeto, contratos de
operação dos casos de uso e se poderia existir algum caso de uso que não foi definido, pois ainda não
havia recebido o feedback. Orientador informou que irá enviar exemplos para o preenchimento e
avaliar o DMS enviando o feedback.
Observação Importante
O objetivo da reunião foi sanar as dúvidas quanto ao preenchimento do DMS.
Requisitos Registrados
Nenhum requisito registrado.
Tabela 47 – Ata de Reunião n.º 07
4.1.8 Ata n.º 08
ATA da Reunião n.º 08
Data
Horário
Local
22/10/2011
Das 21h30m às 22h10m
Sala de Estágio UEG-UnUCET
Equipe técnica
Amanda Barbosa Silva
67
Equipe usuária
Leandro Doutor Branquinho
Teor desta reunião
A reunião ocorreu conforme combinado.
Na reunião o orientador perguntou como estava o andamento do projeto. Informei que o DMS estava
praticamente concluído faltando apenas o dicionário do projeto que não havia preenchido. O caso de
teste e o apêndice para sua realização e a conclusão.
O orientador fez alguns exemplos do dicionário do projeto. Por exemplo, se a classe SearchServlet
possuir uma instancia de CamposDAO. Em que CamposDAO é responsável pela persistência da
entidade campos e qual seria o seu tipo no diagrama de classe conceitual, de forma mais genérica e o
seu tipo do diagrama de classe do projeto, que é o seu tipo verdadeiro. Nesse caso, seria uma classe
nos dois tipos. Informou que eu deveria listar os conceitos definidos no projeto.
Surgiu a dúvida quanto ao desenho do diagrama de classe conceitual ou não, pois o diagrama não
existia no modelo do DMS disponibilizado. O orientador também informou que provavelmente não
seria necessário devido ao fato desse diagrama ser desenvolvido para se ter um melhor entendimento
do projeto, sem ser no nível tão técnico. Como o projeto já é técnico não haveria a necessidade. O
orientador iria verificar essa necessidade e informar.
Informei que havia preenchido os relatórios de acompanhamento por não achar que o cronograma
estava completo o bastante. Repassei para o orientador.
O orientador solicitou que fossem preenchidas as atas de reunião das orientações online devido as
decisões tomadas durante essas reuniões serem importantes.
O orientador perguntou sobre a programação, informei que havia iniciado a programação, mas tive
problemas para implementar da forma como havia detalhado. Então fiz uns testes de uma maneira que
deu certo e resolvi usar essa maneira. Então realizei as alterações no DMS conforme necessário. Ele
solicitou que fosse feita uma implementação para apresentar a ele, sem a necessidade de estar
funcionando tudo corretamente. Informei que gostaria de terminar o DMS nessa semana para a entrega
e depois me preocupar somente com a programação, mas que daria para iniciar a programação essa
semana ainda. Combinamos então uma apresentação na sexta, dia 28, com a tela montada para a
realização da pesquisa.
Informei ao orientador a necessidade de não fazer o requisito quanto ao preenchimento dos valores
padrões para um campo, devido à necessidade de o desenvolvedor preencher esses valores com dados
que existam no banco original da aplicação onde o framework irá buscar os dados, senão nada seria
encontrado. Ficou definido então que não será feito. Estava com dúvidas também quanto a
implementação da lista de adição, devido ao modo como queria implementar a primeira vez e que não
seria viável. Mas na nova forma de implementação será possível implementar.
Informei também quanto a possibilidade de um campo poder se relacionar com outro e um filtro poder
se relacionar com outro e resolvemos colocar esse requisito como futuro ou sugestão de
implementação. Pois, o modo como foi especificado, um filtro já possui vários campos permitindo
colocar um campo período, por exemplo, com dois campos.
Estava preocupada quanto à necessidade de alterações no DMS antes da apresentação da banca. O
orientador informou que eu poderia realizar as modificações que desejasse e apresentar a retifica para
a banca no dia da apresentação.
Observação Importante
O objetivo da reunião foi sanar as dúvidas quanto ao preenchimento do DMS.
68
Requisitos Registrados
Nenhum requisito registrado.
Tabela 48 – Ata de Reunião n.º 08
4.1.9 Ata n.º 09
ATA da Reunião n.º 09
Data
Horário
Local
18/11/2011
Das 21h00m às 21h30m
Sala de Estágio UEG-UnUCET
Equipe técnica
Amanda Barbosa Silva
Equipe usuária
Leandro Doutor Branquinho
Teor desta reunião
A reunião ocorreu conforme combinado.
Foi apresentado ao orientador o dicionário do projeto preenchido. O orientador informou que estava de
acordo.
O sistema foi apresentado ao orientador. Houve um mal entendido no retorno da funcionalidade do
relatório. O retorno da chave primária seria o registro selecionado na listagem retornada após a busca
do usuário final. Ficou acordado que seria um requisito futuro e que a funcionalidade retornaria um
Map com o nome da coluna e o valor respectivo a cada coluna.
Observação Importante
O objetivo da reunião foi apresentar o preenchimento do dicionário do projeto e apresentar o sistema
ao orientador antes da apresentação final.
Requisitos Registrados
Nenhum requisito registrado.
Tabela 49 – Ata de Reunião n.º 09
69
4.2 Descrição do Negócio
O projeto visa desenvolver um framework do tipo vertical, também conhecido como framework de
aplicação, de domínio genérico para o desenvolvimento de sistemas de informação.
De acordo com Rocha (2009), a idéia pregada por esse tipo de software não é nova, e surgiu
junto com a orientação a objetos. Um framework é a estrutura de uma aplicação, ou seja, um conjunto
de classes e interfaces projetado para encapsular o código comum de certo domínio fornecendo uma
solução pronta e genérica para os problemas relacionados a esse domínio.
O uso dessa solução, chamada pré-fabricada por Rocha (2009), facilita a tarefa do
desenvolvedor devido ao fato de parte do sistema já estar implementada e testada, bastando apenas
tratar os pontos específicos da aplicação. Além disso, aplicações criadas a partir de um framework são
desenvolvidas com maior rapidez e qualidade.
Grande parte do trabalho no desenvolvimento de um framework consiste em identificar suas
partes fixas (frozen spots) e variáves (hot spots). As partes fixas são responsáveis por definir a
arquitetura e o comportamento básico da aplicação, além dos relacionamentos entres os seus
componentes. Essas partes são constantes para qualquer aplicação instanciada a partir do framework.
Já as partes variáveis, podem ser customizadas e estão abertas a extensão, permitindo que o
comportamento do framework seja especificado para cada tipo de aplicação. Normalmente, os
frameworks são a generalização de um domínio, por isso possui as partes variáveis, para que o
desenvolvedor possa, durante a instanciação, customizar as especificidades da aplicação. Para realizar
essa customização normalmente o desenvolvedor implementa interfaces, estende classes ou configura
arquivos.
As partes fixas e variáveis do framework definem uma de suas maiores vantagens, o reuso
tanto de código quanto de interface. Além disso, utiliza técnicas de padrões de projeto, “soluções
comprovadas para problemas recorrentes”. Sem esquecer da extensibilidade, que, segundo Rocha
(2009) é uma característica importante para esse tipo de aplicação, pois permite que o desenvolvedor
utiliza a mesma estrutura para solucionar problemas semelhantes, mas não necessariamente iguais.
Mas é claro que o uso de um framework possui, também, desvantagens. Uma delas é a
complexidade, pois é necessário conhecer não apenas o problema que se pretende resolver como o
domínio das aplicações e os conceitos de OO e design patterns. Depois disso é necessário desenvolver
uma solução flexível, robusta e extensível, o que também não é uma solução fácil. Além disso, existe
o alto custo no desenvolvimento, o que normalmente só é justificável quando há certeza que ele será
utilizado na criação de várias aplicações.
Temos também a questão da evolução, pois qualquer mudança no framework irá afetar as
aplicações desenvolvidas a partir dele. Portanto, é possível ter diversas aplicações com diferentes
versões do framework. Tal fato aumenta sistematicamente a complexidade da manutenção tanto da
aplicação quanto do framework.
De acordo com Rocha (2009) os frameworks são classificados basicamente em caixa-branca e
caixa-preta. O primeiro, é configurado principalmente através de herança e implementação de métodos
abstratos, o que significa que o desenvolvedor deve possuir conhecimento sobre a estrutura do
framework para utilizá-lo. Essa abordagem é considerada simples, por não ser necessário o
conhecimento de todas as extensões que o framework suporta antes que seja necessário. Por outro
lado, ela é mais difícil por ser necessário que o desenvolvedor conheça a estrutura interna do
framework.
70
O segundo, a instanciação é feita a partir de classes já existentes e não é necessário que o
desenvolvedor conheça a estrutura do framework. Ele é considerado mais simples de ser utilizado, mas
seu projeto possui uma complexidade maior devido a necessidade de todas as combinações de
extensões possíveis.
Além desses, existe frameworks que são uma combinação dos dois anteriores, eles são
chamado de caixa-cinza.
Como foi dito, o framework que será desenvolvido, é de aplicação. Os frameworks de
aplicações, também conhecidos com verticais, são frameworks voltados para áreas de domínios
específicos, proveem altíssimo grau de reutilização, pois o foco não é solucionar problemas sistêmicos
e sim problemas de negócio, embora, comumente incorporam alguns requisitos sistêmicos. Capturam
as funcionalidades comuns a várias aplicações, portanto, sempre que aplicações distintas em um
mesmo domínio possuírem funcionalidades em comum é possível criar um framework.
Porém, o objeto no momento é o desenvolvimento de uma solução genérica, que
posteriormente poderá ser específico a um domínio.
O objetivo é o desenvolvimento de dois componentes para o framework: pesquisa e parâmetro
de relatório. Os componentes serão gerenciados pelo banco de dados. Com isso, quando houver
necessidade de alterações nas interfaces ou consultas pode-se simplesmente alterar determinados
valores no banco de dados e o framework consegue realizar as alterações dos objetos persistentes de
acordo com essas novas regras, sem que seja necessária uma nova compilação.
71
4.3 Lista de Requisitos
Identificação
Requisito
R01
Definir entidade a ser consultada
R02
Definir os filtros de pesquisa
R03
Definir os campos das entidades
R04
Definir quais campos pertencem a cada filtro
R05
Validar se o tipo do campo no banco de dados é compatível com o tipo do
campo na interface
R06
Criar SQL de consulta com base nos parâmetros informados
R07
Definir se o campo deverá realizar uma consulta extra
R08
Checar se existe entidade/view no banco de dados
R09
Definir a consulta que o campo deverá executar para apresentar os dados
R10
Permitir a montagem de uma interface dinamicamente para pesquisas e
parâmetros de relatório
Tabela 50 – Lista de Requisitos
72
4.4 Lista de Regras de Negócio
Requisito
Associado
Identificação
Regras de Negócio
RN01
Entidade a ser consultada, filtros da interface e parâmetros R01,
R02,
da consulta SQL devem ser definidos no banco de dados. R03,
R04,
R05, R06
RN02
É necessário escolher uma entidade/view para cada campo R01
definido para a consulta.
RN03
O nome da entidade deve ser o mesmo nome da tabela no R01
banco de dados a ser consultado.
RN04
Todos os operadores devem
independentemente do tipo de dados.
RN05
Os parâmetros da consulta SQL são os campos definidos R06
pelo qual deseja pesquisar, combinados com os valores
preenchidos pelo usuário final na interface gráfica.
RN06
Os parâmetros para consulta deverão estar vinculados a R03, R08
uma entidade ou a uma view. Não poderá existir campo
sem entidade ou sem view.
RN07
Os tipos dos campos na interface gráfica devem ser: R03
textfield, combobox, checkbox, radio button ou lista de
adição.
RN08
A consulta para trazer opções preenchidas será realizada R09
apenas para os campos do tipo combobox, checkbox e
radio button. Para que esses campos sejam preenchidos é
necessário existir a consulta.
RN09
Caso o campo consulta seja preenchido para campos do R07
tipo textfield ou lista de adição, significa que a consulta
extra está habilitada.
RN10
A consulta extra poderá ser habilitada apenas para campos R07
do tipo textfield ou lista de adição.
RN11
O desenvolvedor poderá definir uma consulta para R09
qualquer tipo de campo com base nas regras RN08 e
RN09.
estar
disponíveis R03
73
RN12
Os tipos dos campos no banco de dados devem ser R05
compatíveis com os tipos dos campos na interface de
pesquisa.

Varchar, char, text: textuais

Int, decimal, bigInt, double, float, tinyint, smallint:
numéricos

Date, Datetime: data
RN13
Um filtro de pesquisa poderá ter vários campos.
R04
RN15
Para a funcionalidade de busca (pesquisa, formulário), R06
retornar uma chave (chave primária do registro
pesquisado). Para o parâmetro de relatório retornar a SQL
configurada pelo componente.
RN16
Cada campo da tela será pesquisado no select por „and‟. R06
Os dados inseridos na caixa de seleção e as opções
selecionadas do checkbox serão pesquisados por „or‟.
RN17
É necessário preencher pelo menos um campo da interface R06
para realizar a pesquisa.
Tabela 51 – Lista de Regras de Negócio
74
4.5 Dificuldades encontradas no Negócio
Dificuldades
Propostas de Soluções
1. A criação de framework é uma atividade muito Analisar os projetos já realizados na área
complexa por envolver o entendimento de muitos de framework e projetos antigos
conceitos como: orientação a objetos e design patterns.
relacionados a esse projeto, e priorizar o
estudo de designer patterns e das
metodologias
usadas
para
o
desenvolvimento de framework.
2. O framework inicialmente será genérico sem a Abstrair ao máximo os componentes que
definição de um domínio. Quando se define um domínio serão desenvolvidos.
é necessário o estudo do seu negócio, mas um framework
genérico é necessário uma abrangência maior.
3. A inserção das regras de validação dos objetos do Descrever de forma minuciosa todos os
domínio do negócio no banco de dados sem o auxílio de procedimentos a serem seguidos pelo
uma interface gráfica para disciplinar o uso do usuário do framework e desenvolver
framework.
funcionalidades no framework que o
permita emitir mensagem mais intuitivas
e claras.
4. Como o projeto é uma evolução, é necessário conhecer Analisar
os
DMSs
anteriores
o que já foi feito anteriormente e adaptações.
relacionados ao mesmo projeto.
Tabela 52 – Dificuldades encontradas no negócio
75
4.6 Definição do Problema
Atualmente as ferramentas convencionais de desenvolvimento de software não têm facilitado: a
manutenção de software; reutilização de código-fonte, de análise e de projeto. Atualmente quando se
deseja desenvolver uma nova aplicação, mesmo que pertença a domínios semelhantes ou até mesmo
iguais aos de outras aplicações já desenvolvidas, o código é iniciado do zero ou até mesmo realizando
cópias das aplicações similares.
O mesmo acontece para as interfaces e consultas ao banco de dados dos sistemas quando se
necessita de alterações, sejam elas evolutivas, adaptativas, ou corretivas. Dependendo da
complexidade dessa mudança e de como está estruturado, alguns desenvolvedores optam por
refazerem todo o projeto.
Quando se opta pela alteração, ela pode abalar a estrutura do software, dificultar manutenções
futuras e chegar até mesmo ao ponto de reconstruir o software.
Com a utilização do framework o desenvolvedor poderá guardar sua regra de negócio no
banco de dados. Isso permite que as interfaces gráficas e as consultas ao banco de dados sejam criadas
dinamicamente e que futuras alterações sejam rápidas e realizadas com facilidade, sem a necessidade
de parar a aplicação ou a nova compilação de classes para visualização das alterações. Garantindo
assim as principais vantagens de um framework: reuso e extensibilidade.
No momento, o importante não é o domínio da aplicação, e sim o desenvolvimento de um
componente com duas funcionalidades: pesquisa e parâmetro de relatório. Capaz de estruturar a
interface gráfica e a montagem do SQL de retorno dinamicamente, com resultados visuais rápidos e
funcionais.
4.7 Objetivo do Software
Modelagem de um framework de aplicação, genérico, orientado a objetos, com foco na implementação
de um componente com duas funcionalidades: pesquisa e parâmetro de relatório.
A funcionalidade de pesquisa permitirá a criação de interfaces gráficas dinamicamente e a
obtenção de um resultado de acordo com a pesquisa preenchida e as configurações realizadas no banco
de dados ao usuário final.
A funcionalidade de parâmetro de relatório utilizará a funcionalidade de pesquisa retornando,
nesse caso, ao desenvolvedor uma consulta e permitindo que o mesmo realize o que desejar com o
resultado pronto. Como por exemplo, a execução da consulta e a montagem de um relatório em pdf.
Como os dados serão obtidos do banco de dados do framework, poderá facilitar as
manutenções que venham a ser necessárias ou satisfazer mudanças nas regras de negócios da aplicação
sem comprometer o código.
4.8 Escopo do Software
76
O framework utilizará linguagem Java e banco de dados Microsoft SQL Server com suporte à criação
de interfaces dinamicamente, a partir de uma entidade, restrita ao componente: text field, combo box,
checkbox, radio button ou lista de adição.
O componente deverá:

Montar a interface gráfica a partir dos dados inseridos no banco de dados.
 Gerar uma consulta SQL a partir de dados do banco (tipo do operador do campo) e a partir dos
dados informados na tela para consulta pelo usuário final.

Pesquisa (busca): deverá executar a consulta SQL e retornar o registro pesquisado.
 Parâmetro de Relatório: deverá retornar a String que representa a consulta no banco para os
dados informados para que o desenvolvedor a utilize para a montagem de um relatório.
Para os casos citados os parâmetros são configurados no Banco de Dados.
Utilizará também o MiniTemplator que é uma ferramenta compacta de template para arquivos HTML.
4.9 Clientes Alvo
Nome
Definição
Desenvolvedor de Software
Responsável por instanciar e preencher o banco de dados
do framework.
Tabela 53 – Clientes Alvo
4.10 Glossário do Negócio
Termo
Definição
Sinônimo
Instanciação
Criação de uma aplicação a
partir de um framework
Frozen spots
Arquitetura
e Partes fixas
comportamentos básicos da
aplicação
Hot spots
Partes da aplicação abertas à Partes variáveis
customização e extensão
que permitem que o
comportamento
do
framework seja adaptado as
características específicas
da aplicação.
77
View
Representa uma tabela do Visões do banco de dados
banco de dados ou o
resultado de uma consulta
SQL.
Tabela 54 – Glossário do Negócio
5
Requisitos
5.1 Especificação dos Requisitos
5.1.1 ERaF1.1
ERaF1
Definir entidade a ser consultada
Definição
Para a montagem da tela é necessário definir qual ou quais as entidades
serão consultadas.
As entidades deverão ser cadastradas manualmente.
O nome da entidade deve ser o mesmo nome da tabela no banco de dados
a ser consultado.
Especificação
Por exemplo, caso deseje que a entidade Paciente da sua aplicação seja
consultável, deverá preencher no banco de dados o campo nome_entidade
com o nome da tabela no seu banco de dados. (o campo id é auto
incremento)
Regras de Negócio Associadas
RN01, RN02 e RN03
Descrição do Risco
Risco
Iteração
Não existem riscos de desenvolvimento.
-
Única
Tabela 55 – Especificação do Requisito definir entidade a ser consultada
5.1.2 ERaF2.1
ERaF2
Definir os filtros de pesquisa
78
Para a montagem da tela é necessário definir qual ou quais os filtros
deverão ser apresentados na interface para o usuário final.
Definição
A label do filtro será definida com o nome que o usuário deseja que seja
apresentado na interface para o usuário final.
Especificação
A negação significa se será apresentado ao usuário final um checkbox com
a opção de negar os dados preenchidos no filtro. Buscando tudo menos o
que ele preencheu.
Por exemplo, um filtro Nome Usuário, esse seria sua label ou apenas
Nome, e caso desejasse que o usuário possa negar essa condição seria
apenas preencher no banco de dados o negar com 1, se não for pra negar a
condição, preencher com 0.
Regras de Negócio Associadas
RN01, RN06
Descrição do Risco
Risco
Iteração
Não existem riscos de desenvolvimento.
-
Única
Tabela 56 – Especificação do Requisito definir os filtros de pesquisa
5.1.3 ERaF3.1
ERaF3
Definir os campos das entidades
Definição
Para a montagem da tela é necessário definir os campos que serão
consultados e qual entidade ele pertence.
O nome do campo deverá ser preenchido com o nome do campo no banco
a ser consultado.
Definir a qual entidade ou a qual view o campo pertence.
Preencher o tipo do campo no banco de dados de origem e o tipo do campo
na interface de busca. Os tipos dos campos na interface gráfica podem ser:
textfield = 1, combobox = 2, checkbox = 3, radio button 4 ou lista de
adição = 5.
Especificação
Por exemplo, para o filtro Nome provavelmente teremos um campo do tipo
textfield ou lista de adição. Nesse caso, poderíamos pesquisar por like,
pois existem nomes compostos. Preenchemos então o banco de dados com:

nome = nome do campo no banco de dados da aplicação (nome,
por exemplo);

tipo_campo_banco, nesse caso provavelmente um varchar, então
preencheríamos com 1. Se fosse do tipo numério seria 2 se fosse
data seria 3;
79

tipo_campo_interface seria 1 ou 5;

tipo_operador seria 1 ou 2;

id auto incremento.
Regras de Negócio Associadas
RN01, RN04, R06 e RN07
Descrição do Risco
Risco
Iteração
Não existem riscos de desenvolvimento.
-
Única
Tabela 57 – Especificação do Requisito definir os campos das entidades
5.1.4 ERaF4.1
ERaF4
Definir quais campos pertencem a cada filtro
Definição
Um filtro será apresentado na interface gráfica pode ter vários campos de
pesquisa.
Após o cadastro dos filtros e dos campos é necessário vincular os campos
aos seus respectivos filtros.
Especificação
Por exemplo, em um filtro chamado Período, provavelmente teríamos que
preencher duas datas, consequentemente teríamos dois campos. Então na
tabela preencheríamos com o id do campo e o id do filtro que cadastramos.
Teríamos nesse caso duas entradas, uma para cada campo do filtro.
Regras de Negócio Associadas
RN13
Descrição do Risco
Risco
Iteração
Não existem riscos de desenvolvimento.
-
Única
Tabela 58 – Especificação do Requisito definir quais campos pertence a cada filtro
5.1.5 ERaF5.1
ERaF5
Validar se o tipo do campo no banco de dados é compatível com o tipo do
campo na interface
Definição
O tipo da consulta deve ser compatível como tipo do campo do banco de
dados.
Especificação
O framework deverá consultar o campo no banco de dados e comparar os
dados do tipo da consulta e do tipo do campo no banco de dados:
80

Varchar: textuais = 1

Int, decimal, bigInt, double, float: numéricos = 2

Date: data = 3
Regras de Negócio Associadas
RN01 e RN12
Descrição do Risco
Risco
Iteração
Não existem riscos de desenvolvimento.
-
Única
Tabela 59 – Especificação do Requisito validar se o tipo do campo no banco de dados é
compatível com o tipo do campo na interface
5.1.6 ERaF6.1
ERaF6
Criar SQL de consulta com base nos parâmetros informados
Definição
A partir dos dados informados na interface gráfica e dos dados
configurados em banco de dados, o framework deverá montar um SQL.
Especificação
Para a busca (pesquisa) o framework montará o SQL e executará no banco
do cliente, retornando uma chave primária que representa o registro
pesquisado.
Para o parâmetro de relatório o framework montará o SQL e retornará uma
string, em que o usuário poderá usá-la como desejar.
Regras de Negócio Associadas
RN01, RN05, RN15 e RN17
Descrição do Risco
Risco
Montar o SQL de consulta com os dados do banco de 3
dados.
Iteração
Única
Tabela 60 – Especificação do Requisito criar SQL de consulta com base nos parâmetros
informados
5.1.7 ERaF7.1
ERaF7
Definir se o campo deverá realizar uma consulta extra
Definição
Na montagem da tela o desenvolvedor poderá definir uma consulta extra
para o campo textfield ou lista de adição, assim, o framework habilitará
um botão para pesquisa com base da consulta cadastrada e no dado
81
informado, preenchendo campo na interface gráfica.
Caso deseje que o usuário final possa realizar uma consulta extra, o
desenvolvedor deverá preencher o campo consulta. Nesse caso a interface
terá o botão para a consulta e preenchimento do campo. O framework
usará consulta definida para o campo. Se um campo textfield ou lista de
adição tiver o campo consulta preenchido, significa que a consulta extra
está habilitada.
Especificação
Por exemplo, para o campo Nome caso o campo consulta esteja
preenchido, o usuário final poderia preencher o campo com o que deseja
encontrar e selecionar o botão de pesquisa, o sistema iria realizar uma
pesquisa, com base na consulta informada e retornar uma combobox com
os dados encontrados. O usuário seleciona o desejado e o campo na
interface é preenchido, no caso de textfield; ou é adicionado a lista, se for
lista de adição.
Regras de Negócio Associadas
RN09 e RN10
Descrição do Risco
Risco
Iteração
Não existem riscos de desenvolvimento.
-
Única
Tabela 61 – Especificação do Requisito Definir se o campo deverá realizar uma consulta
extra
5.1.8 ERaF8.1
ERaF8
Checar se existe entidade/view no banco de dados
Definição
O usuário poderá definir que um campo será buscado em uma view. Para
buscar, o framework deverá verificar se a view existe.
Especificação
Antes de executar a consulta para o campo, o framework deverá verificar
se a view existe no banco do cliente.
Regras de Negócio Associadas
RN06
Descrição do Risco
Risco
Iteração
Não existem riscos de desenvolvimento.
-
Única
Tabela 62 – Especificação do Requisito Checar se existe entidade/view no banco de
dados
82
5.1.9 ERaF9.1
ERaF9
Definir a consulta que o campo deverá executar para apresentar os dados
Definição
Na montagem da tela o desenvolvedor poderá definir uma consulta para o
campo, assim, o framework apresentará o resultado da consulta como
valores para que o usuário selecione.
Caso o campo deva realizar uma consulta para apresentar na tela, o
desenvolvedor deverá definir a consulta a ser executada.
Especificação
Por exemplo, para um filtro Usuário caso deseje que traga todos os
usuários do banco de dados, basta preencher o campo consulta com o
select específico para trazer os dados desejados. (select nome from usuário
where ativo = 1)
Regras de Negócio Associadas
RN08 e RN11
Descrição do Risco
Risco
Iteração
Não existem riscos de desenvolvimento.
-
Única
Tabela 63 – Especificação do Requisito Definir a consulta que o campo deverá executar
para apresentar os dados
5.1.10 ERaF10.1
ERaF10
Permitir a montagem de uma interface dinamicamente para pesquisas e
parâmetros de relatório
Definição
O componente deverá montar uma interface dinamicamente para a
pesquisa configurada no banco de dados.
Especificação
Quando chamada a execução do componente, tanto para a busca como
para o parâmetro de relatório, o sistema deverá configurar a interface
dinamicamente de acordo com os filtros e campos definidos para a
pesquisa solicitada.
Regras de Negócio Associadas
-
Descrição do Risco
Risco
Iteração
Não existem riscos de desenvolvimento.
-
Única
83
Tabela 64 – Especificação do Requisito Permitir a montagem de uma interface
dinamicamente para pesquisas e parâmetros de relatório
6
Modelagem de Casos de Uso
6.1 Relação de Casos de Uso
Casos de Uso
UC01 - Criar conexões com os bancos de dados das aplicações
UC02 - Realizar conexão com o banco de dados do componente
UC03 - Realizar conexão com o banco de dados da aplicação
UC04 – Configurar framework
UC05 – Configuração da execução do componente
UC06 – Configurar interface gráfica
UC07 - Checar se existe entidade/view no banco de dados
UC08 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
UC09 - Criar SQL de consulta com base nos parâmetros informados
UC10 - Realizar consulta
UC11 - Retornar resultado de acordo com a função
UC12 – Realizar consulta extra
Tabela 65 – Lista de Casos de Uso
6.2 Relação dos Atores
84
6.2.1 Desenvolvedor
Este ator é responsável por configurar a conexão e o banco de dados da aplicação e realizar a
instanciação do framework para a execução do componente.
O desenvolvedor deverá seguir as orientações definidas no manual de instanciação conforme
apêndice C deste documento para obtenção dos recursos do componente.
6.2.2 Componente
Este ator é responsável por utilizar as configurações definidas pelo desenvolvedor, montar a interface
gráfica, realizar a consulta e retornar os dados de acordo com a função executada.
6.3 Diagrama Geral de Casos de Uso
Figura 1 – Diagrama Geral de Caso de Uso
6.4 Detalhamento dos Casos de Uso
85
6.4.1 [Caso de Uso] Criar conexões com os bancos de dados das aplicações
UC.01
Criar conexões com os bancos de dados das aplicações
Descrição:
Este caso de uso descreve como deverá ser realizada a configuração para a criação da
conexão com o banco de dados da aplicação e do framework.
Cenário 1 - Configurar
PréCondição:
Nenhuma.
PósCondição:
Arquivos dataSourceComponents.properties e dataSourceApplication.properties
configurados e caminhos dos arquivos especificados.
Atores:
Desenvolvedor
Ativação:
Fluxo Principal
Nº.
Ação
1
O desenvolvedor deverá criar dois arquivos para a configuração da conexão. Um
arquivo com o nome dataSourceComponents.properties, onde serão configurados os
dados de conexão do banco do componente. E outro arquivo
dataSourceApplication.properties, onde serão configurados os dados de conexão do
banco de dados da aplicação do desenvolvedor.
2
Nos arquivos deverá conter:
conn.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
conn.url= url=jdbc:sqlserver://[HOST]:[PORTA];databaseName=[DATABASE
NAME]
conn.pwd=[SENHA]
conn.user=[USER]
O desenvolvedor deverá preencher os dados que estão em vermelho.
3
Os arquivos deverão ficar no mesmo diretório e o desenvolvedor deverá configurar o
caminho dos arquivos nos dados de inicialização da JVM da seguinte forma: Dcomponent.config.path="C:/dataSource (por exemplo)" (verificar apêndice A).
86
Cenário 2 - Alterar
PréCondição:
Arquivos de configurações dataSourceComponents.properties e / ou
dataSourceApplication.properties já existirem.
PósCondição:
Arquivos dataSourceComponents.properties, arquivo dataSourceApplication.properties
e caminho dos arquivos alterados.
Atores:
Desenvolvedor
Ativação:
Fluxo Principal
Nº.
Ação
1
O desenvolvedor deverá acessar o diretório onde os arquivos
dataSourceComponents.properties e dataSourceApplication.properties estão
configurados.
2
Nos arquivos poderá alterar as configurações de acordo com o desejado seguindo o
padrão abaixo:
conn.driver=com.microsoft.sqlserver.jdbc.SQLServerDriver
conn.url= url=jdbc:sqlserver://[HOST]:[PORTA];databaseName=[DATABASE
NAME]
conn.pwd=[SENHA]
conn.user=[USER]
O desenvolvedor deverá preencher os dados que estão em vermelho.
3
Caso tenha alterado o caminho dos arquivos, o desenvolvedor deverá reconfigurar o
caminho nos dados de inicialização da JVM: Dcomponent.config.path="C:/dataSource (por exemplo)". (verificar apêndice A)
Fluxo de Exceção
E1
Desenvolvedor não configurou o caminho nos dados de inicialização.
E2
Caminho informado dos arquivos de configuração do banco de dados não existe.
E3
Desenvolvedor alterou diretório dos arquivos e não configurou o novo caminho nos
dados de inicialização.
Requisitos
87
R05 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
R06 - Criar SQL de consulta com base nos parâmetros informados
R08 - Checar se existe entidade/view no banco de dados
Referências
UC01 - Criar conexão com o banco de dados da aplicação
UC02 - Realizar conexão com o banco de dados da aplicação
UC04 – Configurar framework
UC05 - Configuração da execução do componente
UC06 - Configurar interface gráfica
UC08 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
UC09 - Criar SQL de consulta com base nos parâmetros informados
UC10 - Realizar consulta
UC12 – Realizar consulta extra
Observações
Não há.
Tabela 66 – Detalhamento Caso de Uso UC01
88
Figura 2 – Diagrama de Atividade – UC01 Configurar
89
Figura 3 – Diagrama de Atividade – UC01 Alterar
90
6.4.2 [Caso de Uso] Realizar conexão com o banco de dados do componente
UC.02
Realizar conexão com o banco de dados do componente
Descrição:
Este caso de uso descreve como deverá ser realizada a conexão com o banco de dados
do componente.
Cenário 1 – Conectar
PréCondição:
Configuração do arquivo dataSourceComponents.properties e do caminho do arquivo.
PósCondição:
Conexão com o banco de dados realizada com sucesso.
Atores:
Desenvolvedor e Componente
Ativação:
Fluxo Principal
Nº.
Ação
1
Desenvolvedor faz chamada ao componente.
2
Componente tenta realizar conexão com o banco de dados.
3
O sistema deverá buscar o caminho do arquivo configurado com o nome : Dcomponent.config.path nos dados de inicialização.
4
Com o arquivo encontrado deverá buscar os dados de conexão: conn.driver, conn.url,
conn.pwd, conn.user.
5
Realizar a conexão com o banco de dados configurado.
Fluxo de Exceção
E1
Desenvolvedor não configurou o caminho nos dados de inicialização.
91
E2
Caminho informado do arquivo de configuração do banco de dados não existe.
E3
Desenvolvedor alterou diretório do arquivo e não configurou o novo caminho nos
dados de inicialização.
Requisitos
R05 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
R06 - Criar SQL de consulta com base nos parâmetros informados
R08 - Checar se existe entidade/view no banco de dados
Referências
UC01 - Criar conexão com o banco de dados da aplicação
UC02 - Realizar conexão com o banco de dados da aplicação
UC05 – Configuração da execução do componente
UC06 - Configurar interface gráfica
UC07 - Checar se existe entidade/view no banco de dados
UC08 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
Observações
Não há.
Tabela 67 – Detalhamento Caso de Uso UC02
92
Figura 4 – Diagrama de Atividade – UC02 Conectar
6.4.3 [Caso de Uso] Realizar conexão com o banco de dados da aplicação
UC.03
Realizar conexão com o banco de dados da aplicação
93
Descrição:
Este caso de uso descreve como deverá ser realizada a conexão com o banco de dados
da aplicação.
Cenário 1 – Conectar
PréCondição:
Configuração do arquivo dataSourceApplication.properties e do caminho do arquivo.
PósCondição:
Conexão com o banco de dados realizada com sucesso.
Atores:
Usuário final e Componente
Ativação:
Usuário final seleciona o botão para realizar a pesquisa.
Fluxo Principal
Nº.
Ação
1
Usuário final preenche os dados desejados para realizar a pesquisa na interface gráfica
e seleciona o botão de pesquisar.
2
Componente tenta realizar conexão com o banco de dados.
3
O sistema deverá buscar o caminho do arquivo configurado com o nome : Dcomponent.config.path nos dados de inicialização.
4
Com o arquivo encontrado deverá buscar os dados de conexão: conn.driver, conn.url,
conn.pwd, conn.user.
5
Realizar a conexão com o banco de dados configurado.
Fluxo de Exceção
E1
Desenvolvedor não configurou o caminho nos dados de inicialização.
E2
Caminho informado do arquivo de configuração do banco de dados não existe.
E3
Desenvolvedor alterou diretório do arquivo e não configurou o novo caminho nos
dados de inicialização.
Requisitos
R05 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
R06 - Criar SQL de consulta com base nos parâmetros informados
94
R08 - Checar se existe entidade/view no banco de dados
Referências
UC01 - Criar conexão com o banco de dados da aplicação
UC03 - Realizar conexão com o banco de dados da aplicação
UC09 - Criar SQL de consulta com base nos parâmetros informados
UC10 - Realizar consulta
UC12 – Realizar consulta extra
Observações
Não há.
Tabela 68 – Detalhamento Caso de Uso UC03
95
Figura 5 – Diagrama de Atividade – UC03 Conectar
6.4.4 [Caso de Uso] Configurar Framework
UC.04
Configurar framework
Descrição:
Este caso de uso descreve como o desenvolvedor deverá configurar o framework para
a sua utilização.
96
Cenário 1 – Configurar
PréCondição:
-
PósCondição:
Configuração do framework, com local do servlet definido no web.xml e cópia dos jars
de dependência.
Atores:
Desenvolvedor.
Ativação:
Fluxo Principal
Nº.
Ação
1
Desenvolvedor configura o mapeamento do servlet no web.xml.
2
Desenvolvedor copia search.jar (que representa o framework) e sua dependências para
o diretório lib do seu projeto dentro de WEB-INF.
Referências
UC04 – Configurar framework
UC05 – Configuração da execução do componente
Observações
Não há.
Tabela 69 – Detalhamento Caso de Uso UC04
97
Figura 6 – Diagrama de Atividade – UC04 Instanciar
6.4.5 [Caso de Uso] Configuração da execução do componente
UC.05
Configuração da execução do componente
Descrição:
Este caso de uso descreve como o desenvolvedor deverá configurar a execução do
componente.
Cenário 1 – Configurar
PréCondição:
Configuração dos arquivos de conexão, conexão com o banco de dados do
componente, configuração do framework e configurações da regras de negócio.
PósCondição:
Configuração do componente para a renderização da interface gráfica de acordo com
as regras de negócio definidas no banco de dados.
Atores:
Desenvolvedor e Componente
98
Ativação:
Fluxo Principal
Nº.
Ação
1
Após a configuração do framework, no local onde deseja fazer a chamada ao
framework para configuração da tela, o desenvolvedor poderá colocar como link ou
como form do botão a chamada ao framework (de acordo com o caminho definido no
web.xml).
2
Além da chamada ao caminho, o desenvolvedor deverá passar como parâmetro o id da
pesquisa que deseja executar (com o nome „pesquisa‟), o modo como deseja executar
(r (relatório) ou b (busca), com o nome „modo‟) e o caminho do servlet para qual
deseja que seja redirecionado após a execução da pesquisa pelo usuário final (onde o
desenvolvedor poderá manipular os dados do resultado retornado, com o nome
„resultado‟).
Fluxo de Exceção
E1
Sistema não consegue conectar com o banco de dados do componente.
E2
Desenvolvedor não seta os parâmetros necessários.
E3
Desenvolvedor não configurou o banco de dados.
Requisitos
R01 - Definir entidade a ser consultada
R02 - Definir os filtros de pesquisa
R03 - Definir os campos das entidades
R04 - Definir quais campos pertence a cada filtro
R05 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
R07 - Definir se o campo deverá realizar uma consulta extra
R08 - Checar se existe entidade/view no banco de dados
Referências
UC01 - Criar conexões com os bancos de dados das aplicações
UC02 - Realizar conexão com o banco de dados do componente
UC04 – Configurar framework
UC05 – Configuração da execução do componente
UC06 – Configurar interface gráfica
99
UC07 - Checar se existe entidade/view no banco de dados
UC08 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
Observações
O nome dos parâmetros a serem repassados para o servlet do framework são: pesquisa, modo e
resultado.
Tabela 70 – Detalhamento Caso de Uso UC05
Figura 7 – Diagrama de Atividade – UC05 Configurar
6.4.6
UC.06
[Caso de Uso] Configurar interface gráfica
Configurar interface gráfica
100
Descrição:
Este caso de uso descreve a configuração da interface gráfica após a chamada da
execução.
Cenário 1 – Configurar
PréCondição:
Configuração da chamada a execução do componente.
PósCondição:
Renderização da interface gráfica de acordo com as regras de negócio definidas no
banco de dados.
Atores:
Usuário final e Componente
Ativação:
Usuário final clica no botão ou link configurado.
Fluxo Principal
Nº.
Ação
1
Usuário final clica no botão ou link configurado pelo desenvolvedor.
2
Componente busca os parâmetros passados pelo desenvolvedor.
3
Componente realiza a configuração da interface a partir das regras de negócio
4
Componente realiza validações das regras de negócio em banco de dados.
5
Componente apresenta interface configurada.
Fluxo de Exceção
E1
Sistema não consegue conectar com o banco de dados do componente.
E2
Desenvolvedor não seta os parâmetros necessários.
E3
Desenvolvedor não configurou o banco de dados.
Requisitos
101
R01 - Definir entidade a ser consultada
R02 - Definir os filtros de pesquisa
R03 - Definir os campos das entidades
R04 - Definir quais campos pertence a cada filtro
R05 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
R07 - Definir se o campo deverá realizar uma consulta extra
R08 - Checar se existe entidade/view no banco de dados
Referências
UC01 - Criar conexões com os bancos de dados das aplicações
UC02 - Realizar conexão com o banco de dados do componente
UC04 – Configurar framework
UC05 – Configuração da execução do componente
UC06 – Configurar interface gráfica
UC07 - Checar se existe entidade/view no banco de dados
UC08 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
Observações
Não há.
Tabela 71 – Detalhamento Caso de Uso UC06
102
Figura 8 – Diagrama de Atividade – UC06 Configurar
6.4.7 [Caso de Uso] Checar se existe entidade/view no banco de dados
UC.07
Checar se existe entidade/view no banco de dados
Descrição:
Este caso de uso descreve a checagem da existência da entidade/view no banco de
dados.
103
Cenário 1 – Checar entidade/view
PréCondição:
Chamada à execução do componente e configuração da interface gráfica. Antes da
renderização realizar validação.
PósCondição:
Execução do componente e renderização da interface gráfica de acordo com as regras
de negócio definidas no banco de dados.
Atores:
Desenvolvedor e Componente
Ativação:
Fluxo Principal
Nº.
Ação
1
Componente verifica se a entidade/view existe no banco de dados.
2
Existindo, retorna a validação „verdadeiro‟ e permite a próxima validação.
Fluxos alternativos
Entidade/View não existe
1
Componente verifica se a entidade/view existe no banco de dados.
2
Caso a entidade/view não exista, retorna mensagem ao usuário e cancela validação.
Fluxo de Exceção
E1
Sistema não consegue conectar com o banco de dados do componente.
E2
Desenvolvedor não seta os parâmetros necessários.
E3
Desenvolvedor não configurou o banco de dados.
Requisitos
R01 - Definir entidade a ser consultada
R02 - Definir os filtros de pesquisa
R03 - Definir os campos das entidades
R04 - Definir quais campos pertence a cada filtro
R05 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
104
R07 - Definir se o campo deverá realizar uma consulta extra
R08 - Checar se existe entidade/view no banco de dados
Referências
UC01 - Criar conexões com os bancos de dados das aplicações
UC02 - Realizar conexão com o banco de dados do componente
UC04 – Configurar framework
UC05 – Configuração da execução do componente
UC06 – Configurar interface gráfica
UC07 - Checar se existe entidade/view no banco de dados
UC08 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
Observações
Não há.
Tabela 72 – Detalhamento Caso de Uso UC07
Figura 9 – Diagrama de Atividade – UC07 Checar entidade/view
105
6.4.8 [Caso de Uso] Validar se o tipo do campo no banco de dados é
compatível com o tipo do campo na interface
UC.08
Descrição:
Validar se o tipo do campo no banco de dados é compatível com o tipo do campo
na interface
Este caso de uso descreve a checagem da compatibilidade do tipo do campo no banco
com o tipo do campo na interface.
Cenário 1 – Validar tipo campo
PréCondição:
Chamada à execução do componente e configuração da interface gráfica. Antes da
renderização realizar validação.
PósCondição:
Execução do componente e renderização da interface gráfica de acordo com as regras
de negócio definidas no banco de dados.
Atores:
Desenvolvedor e Componente
Ativação:
Fluxo Principal
Nº.
Ação
1
Caso a checagem da entidade/view seja validada o componente deve verificar se o tipo
do campo no banco é compatível com o tipo do campo na interface.
2
Caso os tipos sejam compatíveis permite a renderização da página.
Fluxos alternativos
Tipos não são compatíveis
1
Verifica se os tipos são compatíveis.
3
Tipos não são compatíveis, retorna mensagem ao usuário e cancela validação.
Fluxo de Exceção
106
E1
Sistema não consegue conectar com o banco de dados do componente.
E2
Desenvolvedor não seta os parâmetros necessários.
E3
Desenvolvedor não configurou o banco de dados.
Requisitos
R01 - Definir entidade a ser consultada
R02 - Definir os filtros de pesquisa
R03 - Definir os campos das entidades
R04 - Definir quais campos pertence a cada filtro
R05 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
R07 - Definir se o campo deverá realizar uma consulta extra
R08 - Checar se existe entidade/view no banco de dados
Referências
UC01 - Criar conexões com os bancos de dados das aplicações
UC02 - Realizar conexão com o banco de dados do componente
UC04 – Configurar framework
UC05 – Configuração da execução do componente
UC06 – Configurar interface gráfica
UC07 - Checar se existe entidade/view no banco de dados
UC08 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
Observações
Não há.
Tabela 73 – Detalhamento Caso de Uso UC08
107
Figura 10 – Diagrama de Atividade – UC08 Validar tipo campo
6.4.9 [Caso de Uso] Criar SQL de consulta com base nos parâmetros
informados
UC.09
Criar SQL de consulta com base nos parâmetros informados
Descrição:
Este caso de uso descreve a criação do SQL de consulta pelo componente com base
nas regras de negócio definidos em banco de dados para a pesquisa selecionada pelo
desenvolvedor.
Cenário 1 – Criar SQL
PréCondição:
Configuração dos arquivos de conexão, conexão com o banco de dados do
componente, execução do componente, chamada a configuração da interface,
validações e configurações das regras de negócio.
Pós-
SQL criada permitindo o retorno desejado ao desenvolvedor.
108
Condição:
Atores:
Usuário final e Componente
Ativação:
Usuário final preenche os dados para pesquisa e clica no botão.
Fluxo Principal
Nº.
Ação
1
Usuário final preenche os dados desejados para realizar a pesquisa na interface gráfica
e seleciona o botão de pesquisar.
2
Componente busca dados dos campos da interface gráfica e cria o SQL de consulta
dinamicamente para aquela pesquisa.
Fluxo de Exceção
E1
Sistema não consegue conectar com o banco de dados do componente.
E2
Desenvolvedor não seta os parâmetros necessários.
E3
Desenvolvedor não configurou o banco de dados.
Requisitos
R01 - Definir entidade a ser consultada
R02 - Definir os filtros de pesquisa
R03 - Definir os campos das entidades
R04 - Definir quais campos pertence a cada filtro
R05 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
R06 - Criar SQL de consulta com base nos parâmetros informados
R07 - Definir se o campo deverá realizar uma consulta extra
R08 - Checar se existe entidade/view no banco de dados
Referências
UC01 - Criar conexões com os bancos de dados das aplicações
UC02 - Realizar conexão com o banco de dados do componente
UC04 - Instanciar hot-spot
UC04 – Configurar framework
UC05 – Configuração da execução do componente
109
UC07 - Checar se existe entidade/view no banco de dados
UC08 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
UC09 - Criar SQL de consulta com base nos parâmetros informados
UC10 - Realizar consulta
UC11 - Retornar resultado de acordo com a função
Observações
Não há.
Tabela 74 – Detalhamento Caso de Uso UC09
Figura 11 – Diagrama de Atividade – UC09 Criar SQL
110
6.4.10 [Caso de Uso] Realizar consulta
UC.10
Realizar consulta
Descrição:
Este caso de uso descreve a realização da consulta após a criação do SQL caso o a
funcionalidade executada seja a de busca.
Cenário 1 – Consultar
PréCondição:
Configuração dos arquivos de conexão, conexão com o banco de dados do componente
e da aplicação, execução do componente, chamada a configuração da interface,
validações, criação da consulta e configurações das regras de negócio.
PósCondição:
Consulta realizada permitindo o retorno desejado ao desenvolvedor.
Atores:
Componente
Ativação:
Fluxo Principal
Nº.
Ação
1
Componente verifica se é o modo de busca.
2
Se o modo da chamada for o de busca executa o SQL criado.
Fluxos Alternativos
Não é o modo de busca
1
Componente verifica se é o modo de busca.
2
Não é o modo de busca, não executa o SQL
Fluxo de Exceção
E1
Sistema não consegue conectar com o banco de dados do componente.
111
E2
Sistema não consegue conectar com o banco de dados da aplicação.
E3
Desenvolvedor não seta os parâmetros necessários.
E4
Desenvolvedor não configurou o banco de dados.
Requisitos
R01 - Definir entidade a ser consultada
R02 - Definir os filtros de pesquisa
R03 - Definir os campos das entidades
R04 - Definir quais campos pertence a cada filtro
R05 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
R06 - Criar SQL de consulta com base nos parâmetros informados
R07 - Definir se o campo deverá realizar uma consulta extra
R08 - Checar se existe entidade/view no banco de dados
Referências
UC01 - Criar conexões com os bancos de dados das aplicações
UC02 - Realizar conexão com o banco de dados do componente
UC04 – Configurar framework
UC05 – Configuração da execução do componente
UC06 – Configurar interface gráfica
UC07 - Checar se existe entidade/view no banco de dados
UC08 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
UC09 - Criar SQL de consulta com base nos parâmetros informados
UC10 - Realizar consulta
UC11 - Retornar resultado de acordo com a função
Observações
Não há.
Tabela 75 – Detalhamento Caso de Uso UC10
112
Figura 12 – Diagrama de Atividade – UC10 Consultar
6.4.11 [Caso de Uso] Retornar resultado de acordo com a função
UC.11
Retornar resultado de acordo com a função
Descrição:
Este caso de uso descreve como deverá ser o retorno do resultado para as funções do
componente.
Cenário 1 – Retornar resultado
PréCondição:
Criação e execução da consulta SQL.
PósCondição:
Retorno desejado ao desenvolvedor a partir da funcionalidade executada.
Atores:
Componente
Ativação:
113
Fluxo Principal
Nº.
Ação
1
Componente verifica qual o modo executado.
2
Se o modo da chamada for o de busca seta o atributo „result-search‟ com o resultado da
execução do SQL (Map<String, Object>: nome da coluna no banco de dados e
resultado encontrado). Se o modo da chamada for o de relatório setar o atributo „resultsearch‟ com a String que representa o SQL.
Fluxo de Exceção
E1
Sistema não consegue conectar com o banco de dados do componente.
E2
Sistema não consegue conectar com o banco de dados da aplicação.
E3
Desenvolvedor não seta os parâmetros necessários.
E4
Desenvolvedor não configurou o banco de dados.
Requisitos
R01 - Definir entidade a ser consultada
R02 - Definir os filtros de pesquisa
R03 - Definir os campos das entidades
R04 - Definir quais campos pertence a cada filtro
R05 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
R06 - Criar SQL de consulta com base nos parâmetros informados
R07 - Definir se o campo deverá realizar uma consulta extra
R08 - Checar se existe entidade/view no banco de dados
Referências
UC01 - Criar conexões com os bancos de dados das aplicações
UC02 - Realizar conexão com o banco de dados do componente
UC04 – Configurar framework
UC05 – Configuração da execução do componente
UC06 – Configurar interface gráfica
UC07 - Checar se existe entidade/view no banco de dados
UC08 - Validar se o tipo do campo no banco de dados é compatível com o tipo do campo na interface
UC09 - Criar SQL de consulta com base nos parâmetros informados
114
UC10 - Realizar consulta
UC11 - Retornar resultado de acordo com a função
Observações
Não há.
Tabela 76 – Detalhamento Caso de Uso UC11
Figura 13 – Diagrama de Atividade – UC11 Retornar resultado – Busca
115
Figura 14 – Diagrama de Atividade – UC11 Retornar resultado – Relatório
6.4.12 [Caso de Uso] Realizar consulta extra
UC.12
Realizar consulta extra
Descrição:
Este caso de uso descreve como o usuário final poderá realizar uma consulta extra para
um campo textfield ou lista de adição.
Cenário 1 – Buscar Textfield
PréCondição:
Execução do componente.
PósCondição:
Opção escolhida preenchida no respectivo campo.
Atores:
Usuário final e Componente
Ativação:
Usuário final clica no botão de consulta extra do respectivo campo.
Fluxo Principal
Nº.
Ação
1
Usuário final clica no botão de consulta extra.
2
Componente busca o campo e abre uma nova tela com uma combobox preenchida com
os dados retornados da consulta definida para o campo.
3
Usuário final seleciona a opção desejada e clica no botão selecionar.
4
Componente preenche o campo na tela de pesquisa com a opção selecionada pelo
usuário final.
Cenário 2 – Buscar Lista de adição
PréCondição:
Execução do componente.
116
PósCondição:
Opção escolhida adicionada na lista do respectivo campo.
Atores:
Usuário final e Componente
Ativação:
Usuário final clica no botão de consulta extra do respectivo campo.
Fluxo Principal
Nº.
Ação
1
Usuário final clica no botão de consulta extra.
2
Componente busca o campo e abre uma nova tela com uma combobox preenchida com
os dados retornados da consulta definida para o campo.
3
Usuário final seleciona a opção desejada e clica no botão selecionar.
4
Componente adiciona a opção selecionada pelo usuário final na lista de adição do
campo na tela de pesquisa.
Cenário 2 – Remover Lista de adição
PréCondição:
Existir pelo menos um item da lista de adição do campo.
PósCondição:
Opção escolhida removida da lista do respectivo campo.
Atores:
Usuário final e Componente
Ativação:
Usuário final clica no botão de remover da opção desejada do respectivo campo.
Fluxo Principal
Nº.
Ação
1
Usuário final clica no botão remover do item desejado na lista do respectivo campo.
2
Componente remove a opção desejada da lista do campo.
Fluxo de Exceção
E1
Usuário final fecha a tela sem clicar no botão selecionar.
117
E2
Sistema não consegue conectar com o banco de dados da aplicação.
Requisitos
R07 - Definir se o campo deverá realizar uma consulta extra
Referências
UC01 - Criar conexões com os bancos de dados das aplicações
UC03 - Realizar conexão com o banco de dados da aplicação
UC12 – Realizar consulta extra
Observações
Não há.
Tabela 77 – Detalhamento Caso de Uso UC12
Figura 15 – Diagrama de Atividade – UC12 Realizar consulta extra – Buscar Textfield
118
Figura 16 – Diagrama de Atividade – UC12 Realizar consulta extra – Buscar Lista de
Adição
Figura 17 – Diagrama de Atividade – UC12 Realizar consulta extra – Remover Lista de
Adição
119
7
Modelagem de Dados
7.1 Projeto Conceitual de Dados
Figura 18 – Projeto Conceitual
7.2 Projeto Lógico de Dados
Figura 19 – Projeto Lógico
120
7.3 Script de Criação de Banco de Dados
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[campos]') AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[campos](
[idcampo] [int] IDENTITY(1,1) NOT NULL,
[nome] [varchar](45) NULL,
[consulta] [varchar](1500) NULL,
[tipo_campo_banco] [int] NOT NULL,
[tipo_campo_interface] [int] NOT NULL,
[tipo_operador] [int] NOT NULL,
[entidades_identidade] [int] NOT NULL,
CONSTRAINT [PK_campos] PRIMARY KEY CLUSTERED
(
[idcampo] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
END
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[entidades]') AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[entidades](
[identidade] [int] IDENTITY(1,1) NOT NULL,
[nome_entidade] [varchar](45) NOT NULL,
CONSTRAINT [PK_entidades] PRIMARY KEY CLUSTERED
(
[identidade] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
END
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[filtro]') AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[filtro](
[idfiltro] [int] IDENTITY(1,1) NOT NULL,
[label] [varchar](45) NOT NULL,
[negar] [smallint] NOT NULL,
CONSTRAINT [PK_filtro] PRIMARY KEY CLUSTERED
(
121
[idfiltro] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
END
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[filtro_has_campos]') AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[filtro_has_campos](
[filtro_idfiltro] [int] NOT NULL,
[campos_idcampo] [int] NOT NULL,
CONSTRAINT [PK_filtro_has_campos] PRIMARY KEY CLUSTERED
(
[filtro_idfiltro] ASC,
[campos_idcampo] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
END
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[pesquisa]') AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[pesquisa](
[idpesquisa] [int] IDENTITY(1,1) NOT NULL,
[descricao] [varchar](45) NULL,
[ordem_pesquisa] [varchar](45) NULL,
CONSTRAINT [PK_pesquisa] PRIMARY KEY CLUSTERED
(
[idpesquisa] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
END
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
IF NOT EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[pesquisa_has_filtro]') AND type in (N'U'))
BEGIN
CREATE TABLE [dbo].[pesquisa_has_filtro](
[pesquisa_idpesquisa] [int] NOT NULL,
[filtro_idfiltro] [int] NOT NULL,
CONSTRAINT [PK_pesquisa_has_filtro] PRIMARY KEY CLUSTERED
(
[pesquisa_idpesquisa] ASC,
[filtro_idfiltro] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
END
122
8
Especificação da Arquitetura
8.1 Diagrama de Componentes
Figura 20 – Diagrama de Componentes
123
8.2 Diagrama de Implantação
Figura 21 – Diagrama de Implantação
124
8.3 Diagrama de Pacotes
Figura 22 – Diagrama de Pacotes Arquitetural
125
9
Realização de Casos de Uso
9.1 Diagrama de Classe Conceitual
Figura 23 – Diagrama de Classe Conceitual
9.2 Diagrama de Classes do Projeto
Figura 24 – DC de Projeto - Realizar Conexões
126
Figura 25 – DC de Projeto - Execução do Componente
127
Figura 26 – DC de Projeto – Retorno do Resultado
128
Figura 27 – DC de Projeto – Realizar consulta extra
129
9.3 Diagrama de Sequência
Figura 28 – Execução do Componente
Figura 29 – Realizar consulta extra
130
Figura 30 – Escolha consulta extra
131
Figura 31 – Retorno do Resultado – BUSCA
132
Figura 32 – Retorno do Resultado – RELATÓRIO
133
9.4 Layout da Interface
Figura 33 – Interface de pesquisa
134
9.5 Diagrama Geral de Classes do Projeto
Figura 34 – Diagrama de Classes
135
10 Testes
10.1 Plano de Testes
O teste a ser executado será de usabilidade seguindo todos os procedimentos necessários para a
utilização do framework:

Configuração dos arquivos datasource.properties.

Configuração do banco de dados.

Configuração das libs e da chamada ao componente.

Manipulação do retorno.

Um teste para cada tipo de campo na interface preenchendo somente o campo.

Um teste que preenche todos os campos da tela, um de cada tipo.
Os requisitos necessários para a execução do teste são:

Uma aplicação web que possa fazer chamada ao componente

SQL Server 2005

Tomcat 6.0.20

Windows XP/Vista/Sete ou Ubuntu

Navegador Firefox, Internet Explorer, por exemplo
10.2 Casos de Testes
Caso de Teste
Configurar framework
Tipo de Teste
Usabilidade
Procedimentos
1. Configuração dos arquivos dataSource.properties de acordo com o detalhamento do caso de
uso 01 e seguindo o procedimento descrito no apêndice C.
2. Seguir os procedimentos descritos no Apêndice D e E.
3. Disponibilizar a aplicação para o usuário final utilizar.
4. Verificar se o retorno dos dados está conforme manipulado.
136
Resultado Esperado
Framework configurado pelo desenvolvedor e pronto para
uso pelo usuário final.
Resultado do Teste
Satisfatório
Tabela 78 – Caso de Teste – Configurar framework
Caso de Teste
Preencher campo do tipo texto
Tipo de Teste
Verificação
Procedimentos
1. Preencher campo com o que deseja pesquisar.
2. Efetuar buscar e verificar se os dados retornados estão de acordo como o preenchido e o
configurado.
1. Campo possui consulta extra. Seleciona botão de consulta extra, escolhe uma opção na
combobox e clica no botão selecionar.
2. Verifica se o valor selecionado foi preenchido na tela de pesquisa, no local do campo.
3. Efetuar a busca e verificar se os dados retornados estão de acordo com o preenchido e
configurado.
Resultado Esperado
Campo preenchido e retorno de acordo com o que foi
pesquisado.
Resultado do Teste
Satisfatório
Tabela 79 – Caso de Teste – Preencher campo do tipo texto
Caso de Teste
Preencher campo do tipo data
Tipo de Teste
Verificação
Procedimentos
1. Preenche o campo com a data desejada.
2. Verifica se o componente configurou corretamente a máscara.
3. Efetuar a busca e verificar se os dados retornados estão de acordo com o preenchido e
configurado.
137
Resultado Esperado
Campo preenchido e retorno de acordo com o que foi
pesquisado.
Resultado do Teste
Satisfatório
Tabela 80 – Caso de Teste – Preencher campo do tipo data
Caso de Teste
Preencher campo do tipo combobox
Tipo de Teste
Verificação
Procedimentos
1. Verifica se os valores apresentados na combobox estão de acordo com a consulta definida
para o campo.
2. Seleciona o valor desejado.
3. Efetuar a busca e verificar se os dados retornados estão de acordo com o preenchido e
configurado.
Resultado Esperado
Campo preenchido e retorno de acordo com o que foi
pesquisado.
Resultado do Teste
Satisfatório
Tabela 81 – Caso de Teste – Preencher campo do tipo combobox
Caso de Teste
Preencher campo do tipo checkbox
Tipo de Teste
Verificação
Procedimentos
1. Verifica se os valores apresentados nas checkboxes estão de acordo com a consulta definida
para o campo.
2. Seleciona o(s) valor(es) desejado(s).
3. Efetuar a busca e verificar se os dados retornados estão de acordo com o preenchido e
configurado.
Resultado Esperado
Campo preenchido e retorno de acordo com o que foi
pesquisado.
Resultado do Teste
Satisfatório
138
Tabela 82 – Caso de Teste – Preencher campo do tipo checkbox
Caso de Teste
Preencher campo do tipo radio button
Tipo de Teste
Verificação
Procedimentos
1. Verifica se os valores apresentados nos radio buttons estão de acordo com a consulta
definida para o campo.
2. Seleciona o valor desejado.
3. Efetuar a busca e verificar se os dados retornados estão de acordo com o preenchido e
configurado.
Resultado Esperado
Campo preenchido e retorno de acordo com o que foi
pesquisado.
Resultado do Teste
Satisfatório
Tabela 83 – Caso de Teste – Preencher campo do tipo radio button
Caso de Teste
Preencher campo do tipo lista de adição
Tipo de Teste
Verificação
Procedimentos
1. Preencher campo texto com o que deseja pesquisar.
2. Clica no botão adicionar. Verifica se o valor foi adicionado na listagem.
3. Efetuar buscar e verificar se os dados retornados estão de acordo como o preenchido e o
configurado.
1. Campo possui consulta extra. Seleciona botão de consulta extra, escolhe uma opção na
combobox e clica no botão selecionar.
2. Verifica se o valor foi adicionado na listagem.
3. Efetuar a busca e verificar se os dados retornados estão de acordo com o preenchido e
configurado.
Resultado Esperado
Campo preenchido e retorno de acordo com o que foi
139
pesquisado.
Resultado do Teste
Satisfatório
Tabela 84 – Caso de Teste – Preencher campo do tipo lista de adição
Caso de Teste
Preencher pesquisa
Tipo de Teste
Verificação
Procedimentos
1. Preencher todos os campos apresentados na tela.
2. Efetuar a busca e verificar se os dados retornados estão de acordo com o preenchido e
configurado.
Resultado Esperado
Campos preenchidos e retorno de acordo com o que foi
pesquisado.
Resultado do Teste
Satisfatório
Tabela 85 – Caso de Teste – Preencher campo do tipo lista de adição
10.3 Relatório de Testes
Os procedimentos definidos nos casos de teste foram seguidos.
A configuração do banco de dados foi simples. Uma dificuldade é o vínculo de campos com filtro e o
vinculo de filtro com pesquisa por ter que saber o id (identificador) corretor dos dois.
A configuração do framework na aplicação foi simples e sem dificuldades.
Foi configurada uma interface para usuário final com cada tipo de campo, habilitando a consulta extra
e a consulta que traz opções nos campos combobox, checkbox e radio button. Não houve dificuldades
no preenchimento dos dados. A tela teve uma resposta rápida, montando rapidamente a interface
configurada no banco de dados. Para cada teste do campo somente o campo foi preenchido.
Foi efetuada uma pesquisa preenchendo todos os campos da interface. Os dados foram retornados
conforme desejado.
O componente foi executado nos dois modos: busca e relatório. O retorno do componente com relação
à funcionalidade solicitada (busca ou relatório) foi como especificado e foi possível a fácil
manipulação do retorno para apresentação dos dados para o usuário final.
140
11 Conclusão
Pensando nas vantagens do uso de um framework esse projeto teve como objetivo o desenvolvimento
de um componente com duas funcionalidades: pesquisa e parâmetro de relatório. Foi desenvolvida
uma configuração simples para o seu uso e sem a necessidade de compilação de código objetivando a
praticidade e rapidez nas mudanças.
Houveram dificuldades no desenvolvimento do projeto devido a criação em tempo de execução da
interface visual do componente e também do SQL de consulta. Foram estudos empíricos da melhor
forma de implementação resultando em uma solução prática e simples.
O objetivo não foi definir um domínio para a aplicação. Afinal, praticamente todos os programas
precisam de uma pesquisa.
O componente tem grandes chances de ser bem aceito pelos desenvolvedores. Na minha opinião, um
dos aspectos que mais contribui para isso, é a facilidade de integração com a aplicação web já
existente. O desenvolvedor precisa apenas configurar no web.xml de sua aplicação, copias os .jars
necessários e fazer a chamada no local desejado além, é claro, da configuração no banco de dados.
Outro aspecto é a configuração realizada no banco de dados. Consequentemente, não é necessário
retirar a aplicação do ar para manutenções nem recompilações de código. A cada demanda, basta
apenas adicionar o novo parâmetro de pesquisa via banco de dados e as alterações estarão disponíveis
para o usuário final em tempo de execução.
Usuários finais de aplicações solicitam muito pesquisas com determinados campos e relatórios. O
componente nesse aspecto facilita bastante. A demanda do cliente pode ser atendida rapidamente
quanto aos campos de busca e os parâmetros de relatório. Assim, o desenvolvedor não precisa se
preocupar com a interface e sim com o seu retorno.
Como um requisito futuro, para quem desejar continuar o projeto, sugiro permitir o relacionamento de
um campo com outro e de um filtro com outro, sendo que esse relacionamento seria apenas visual
(apenas na interface). Com isso, na utilização do componente poderia ser configurado o
relacionamento de dois filtros de data, por exemplo, sendo cada um com um período.
Outro requisito futuro seria uma opção que selecionasse todas as opções do checkbox, para que o
usuário não precisasse selecionar um por um na listagem.
E, por último, no caso da funcionalidade de busca, seria listar todas as opções encontradas de acordo
com a pesquisa preenchida. O usuário final poderia selecionar uma opção na listagem e o componente
retornaria o identificador do registro selecionado. Assim, o desenvolvedor que está manipulando o
componente poderia buscar esse registro e apresentá-lo em um modo de consulta ou em modo de
edição para o usuário final.
141
12 Referências
Isbir Filho, Joseph Antônio. Framework de Aplicação: Modelagem e Implementação de
Interfaces. Anápolis, 2008. 138 p. Trabalho de Conclusão de Curso (Projeto) – Curso de
Sistemas de Informação, UnUCET, Universidade Estadual de Goiás.
MENDONÇA, Sandoval César de Oliveira. Framework de Aplicação para o Desenvolvimento de
Sistemas de Informação: Frameworks de Aplicações. Anápolis, 2008. 187 p. Projeto – Curso de
Sistemas de Informação, UnUCET, Universidade Estadual de Goiás.
PONTIFÍCIA UNIVERSIDADE CATÓLICA DO RIO DE JANEIRO. Frameworks: Conceitos
Gerais. Rio de Janeiro, 14p.
ROCHA, André Dantas. Construindo frameworks em Java. Java Magazine, Rio de Janeiro, ano VII,
edição 66, p. 76-82, fevereiro 2009.
UNIVERSIDADE FEDERAL DE CAMPINA GRANDE. Tipos de frameworks. Disponível em:
<http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/frame/tipos.htm>. Acesso em 02 de abril de
2011.
142
13 Apêndices
13.1 Apêndice A – Cronograma de Atividades do Trabalho de
Conclusão de Curso
Figura 35 – Cronograma de atividades proposto no projeto do Trabalho de Conclusão
de Curso
143
13.2 Apêndice A – PÔSTER APRESENTADO NO III SIMPÓSIO DE
TECNOLOGIA DA INFORMAÇÃO E III SEMANA DE INICIAÇÃO
CIENTÍFICA DO CURSO DE SISTEMAS DE INFORMAÇÃO
UNUCET-UEG/2011
Figura 36 – Pôster – Framework de Aplicação
144
13.3 Apêndice C – Configuração dos arquivos dataSource
Configuração do caminho dos arquivos properties de conexão com o banco de dados no Windows.
Após a instalação do Apache Tomcat, acessar a pasta /tomcat/bin. Executar o arquivo tomcat6w.exe,
é necessário que o serviço tenha sido instalado.
Acessar a aba Java. No campo Java Options inserir o parâmetro:
-Dcomponent.config.path="C:/dataSource (por exemplo)"
Figura 37 – Configuração Tomcat
145
13.4 Apêndice D – Configurando o banco de dados
1. Pesquisa. Inserir o nome da pesquisa, que será apresentado na tela e a ordenação do resultado
(asc ou desc).
Figura 38 – Tabela de Pesquisa
2. Entidades. Cadastre a entidade que deseje que seja pesquisável. Lembrando que o nome da
entidade deve ser o mesmo nome da entidade no banco original.
146
Figura 39 – Tabela de Entidades
3. Campos. Definir os valores conforme especificado nos requisitos R03, R07 e R09.
Figura 40 – Tabela de Campos
4. Definir os filtros para os campos. Lembrando que um filtro pode ter vários campos.
147
Figura 41 – Tabela de Filtro
5. Agora podemos vincular os campos em seus respectivos filtros.
Figura 42 – Tabela de vinculo entre Campos e Filtro
148
6. E os filtros a sua pesquisa.
Figura 43 – Tabela de vinculo entre Filtro e Pesquisa
7. Pronto! O banco de dados está configurado para ser utilizado.
13.5 Apêndice E – Exemplo de Uso
1. O primeiro passo é copiar o jar do framework e suas dependências para a pasta lib de seu
projeto. (componente.jar e biz.jar)
2. O segundo passo é mapear o framework no web.xml da sua aplicação. Exemplo abaixo:
a. Lembrando que o caminho do servlet é sempre o mesmo, mudando apenas o
mapeamento.
149
Figura 44 – Configuração do uso do componente no web.xml da aplicação web
3. Depois de mapeado, você poderá fazer uso do componente fazendo chamada ao servlet
mapeado e passando os parâmetros necessários. Como por exemplo:
a. Lembrando que os parâmetros são:
i. pesquisa = id da pesquisa que deseja executar
ii. modo = o modo como deseja executar r (relatório) ou b (busca)
iii. resultado = caminho do servlet para qual deseja que seja redirecionado após a
execução da pesquisa pelo usuário final (onde o desenvolvedor poderá
manipular os dados do resultado retornado)
b. Lembrando que todos os parâmetros são minúsculos.
150
Figura 45 – Chamada ao componente da interface
4. Pronto! O componente está pronto para uso! Basta agora que você manipule os dados
retornados pelo componente configurando o seu servlet.
5. Lembrando que é necessário que o banco de dados já esteja configurado com os dados
necessários.
151