Post on 23-Sep-2020
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE SISTEMAS DE INFORMAÇÃO – BACHARELADO
APLICAÇÃO WEB PARA GERENCIAMENTO DOS
PROCESSOS E SERVIÇOS PRESTADOS PELO
LABORATÓRIO DE COMPUTAÇÃO E INFORMÁTICA
RAFAEL PATRICIO
BLUMENAU 2008
2008/2-14
RAFAEL PATRICIO
APLICAÇÃO WEB PARA GERENCIAMENTO DOS
PROCESSOS E SERVIÇOS PRESTADOS PELO
LABORATÓRIO DE COMPUTAÇÃO E INFORMÁTICA
Trabalho de Conclusão de Curso submetido à Universidade Regional de Blumenau para a obtenção dos créditos na disciplina Trabalho de Conclusão de Curso II do curso de Sistemas de Informação— Bacharelado.
Prof. Dalton Solano dos Reis, Mestre - Orientador
BLUMENAU 2008
2008/2-14
APLICAÇÃO WEB PARA GENRECIAMENTO DOS
PROCESSOS E SERVIÇOS PRESTADOS PELO
LABORATÓRIO DE COMPUTAÇÃO E INFORMÁTICA
Por
RAFAEL PATRICIO
Trabalho aprovado para obtenção dos créditos na disciplina de Trabalho de Conclusão de Curso II, pela banca examinadora formada por:
______________________________________________________ Presidente: Prof. Dalton Solano dos Reis, Mestre – Orientador, FURB
______________________________________________________ Membro: Prof. Paulo Fernando da Silva, Mestre, FURB
______________________________________________________ Membro: Prof. Adilson Vahldick, Mestre, FURB
Blumenau, 11 de dezembro de 2008
Dedico este trabalho aos meus pais, que sempre acreditaram em mim, incentivaram e me apoiaram; aos meus verdadeiros amigos, que estiveram sempre presentes, interessados e dispostos a me ajudar; e ao meu orientador, que abriu esta porta e acreditou em minha capacidade.
AGRADECIMENTOS
A Deus, por jamais me abandonar, sempre iluminar o meu caminho e me dar forças,
sabedoria e paciência para lutar e alcançar os meus objetivos com humildade.
Aos meus pais, por todo o seu amor, carinho e dedicação, por estarem sempre
presentes nos momentos em que mais necessitei e que sempre acreditaram e confiaram em
mim, e a todo o momento me incentivaram.
Ao meu orientador, o senhor Dalton Solano dos Reis, por ter depositado em mim a
confiança para o desenvolvimento deste trabalho tão importante ao Laboratório de
Computação e Informática (LCI) e por toda a sua dedicação ao longo deste ano.
Ao meu amigo, Eduardo Paniz Mallmann vulgo Puri, por ter se tornado um grande e
verdadeiro amigo e pela sua participação fundamental na realização deste trabalho através de
sua paciência, inteligência, cooperação e capacidade de transmitir conhecimentos.
Ao professor Adilson Vahldick, por sua colaboração através das suas críticas e
sugestões, as quais contribuíram muito para o desenvolvimento e aperfeiçoamento deste
trabalho.
Ao senhores Vandeir Eduardo e Dangelo Moraes, funcionários do LCI, por toda a sua
atenção e colaboração em relação à implantação deste projeto.
Um grande homem sempre recebe a ajuda de outros grandes homens.
Kiko Sampaio
RESUMO
Este trabalho apresenta o desenvolvimento de uma aplicação Web cuja finalidade é automatizar o gerenciamento dos processos e serviços prestados pelo Laboratório de Computação e Informática (LCI). O foco da aplicação está relacionado ao gerenciamento das solicitações de serviços encaminhadas a equipe de funcionários deste laboratório, a qual é responsável pela manutenção de todos os laboratórios e equipamentos utilizados no Departamento de Sistemas e Computação (DSC). Entre as tecnologias utilizadas no desenvolvimento da mesma destacam-se o framework Struts 2 e o padrão Model View
Controller (MVC) de arquitetura. A aplicação utiliza o banco de dados MySQL e as suas páginas foram construídas em Java Server Pages (JSP).
Palavras-chave: Aplicação Web. Gerenciamento. Processos. Serviços. LCI. DSC. Struts 2. MVC.
ABSTRACT
This work presents the development of a Web application to the effect automatize the process management and services rendered by the Laboratório de Computação e Informática (LCI). The application central point has relations with the services solicitations management forwarded to the work-team of this laboratory which is responsible about the maintenance of all laboratories and equipments used by the Departamento de Sistemas e Computação (DSC). Among the technologies used at the application development makes salient the Struts 2 framework and Model View Controller (MVC) architecture standard. The application uses MySQL data base and its pages had been constructed using Java Server Pages (JSP).
Key-words: Web Application. Management. Process. Services. LCI. DSC. Struts 2. MVC.
LISTA DE ILUSTRAÇÕES
Figura 1 - Fluxo Struts 2 ........................................................................................................... 16
Figura 2 – Diagrama de casos de uso referente aos usuários solicitantes ................................ 22
Figura 3 – Diagrama de casos de uso referente aos usuários realizadores ............................... 23
Figura 4 – Diagrama de casos de uso referentes ao administrador do sistema ........................ 24
Quadro 1 – Detalhamento do caso de uso UC02 – Abrir chamado .......................................... 24
Quadro 2 – Detalhamento do caso de uso UC05 – Registrar observação ................................ 25
Quadro 3 – Detalhamento do caso de uso UC04 – Gerenciar chamados ................................. 25
Quadro 4 – Detalhamento do caso de uso UC06 – Preencher relatório de atividades ............. 26
Quadro 5 – Detalhamento do caso de uso UC07 – Registrar horário de trabalho .................... 26
Quadro 6 – Detalhamento do caso de uso UC08 – Gerenciar estoque ..................................... 27
Quadro 7 – Detalhamento do caso de uso UC10 – Gerenciar usuários .................................... 27
Figura 5 – Diagrama de classes ................................................................................................ 28
Figura 6 – Modelo de entidade e relacionamento..................................................................... 30
Figura 7 - Diagrama de seqüência ............................................................................................ 32
Figura 8 - Diagrama de navegação ........................................................................................... 33
Figura 9 - Diagrama de atividades ............................................................................................ 34
Figura 10 - Diagrama de pacotes .............................................................................................. 36
Quadro 8 – Exemplo de utilização do CSS .............................................................................. 37
Quadro 9 - Propriedade character-set em uma tabela na base de dados MySQL ..................... 38
Quadro 10 - Parâmetro useUnicode passado na conexão com a base de dados MySQL ......... 39
Quadro 11 - Tag File pageEncoding ........................................................................................ 39
Quadro 12 - Exemplo de utilização da linguagem PL/SQL ..................................................... 40
Figura 11 - Página gerência de estoque .................................................................................... 41
Quadro 13 – Composição JSP da página gerência de estoque ................................................. 42
Quadro 14 – Fragmento de código Struts referente à classe Estoque ...................................... 43
Quadro 15 – Fragmento de código referente à classe Estoque ................................................. 44
Figura 12 - Página gerência de chamados ................................................................................ 45
Figura 13 – Página abertura de um novo chamado .................................................................. 46
Figura 14 – Página cadastro de usuários receptores ................................................................. 47
Figura 15 – Página chamados sob responsabilidade do usuário ............................................... 48
Figura 16 – Página atualizar estágio chamado ......................................................................... 49
Figura 17 – Página definir responsáveis chamado ................................................................... 50
Figura 18 – Página registro de observações ............................................................................. 51
Figura 19 – Página sinalização de nova observação................................................................. 51
Figura 20 - Primeira versão da guia gerência de usuários ........................................................ 53
Figura 21 - Segunda versão da guia gerência de usuários ........................................................ 54
Figura 22 - Estrutura de abas em gerência de chamados .......................................................... 55
Figura 23 - Guia chamado em gerência de chamados .............................................................. 55
Figura 24 - Detalhamento do chamado em gerência de chamados .......................................... 56
Figura 25 - Primeira versão campos tipo combo ...................................................................... 57
Figura 26 - Segunda versão campos tipo combo ...................................................................... 57
Figura 27 - Formulário de Solicitação de Serviço ao LCI ........................................................ 63
LISTA DE SIGLAS
CASE – Computer Aided Software Engineering
CMMI – Capability Maturity Model Integration
CSS – Cascading Style Sheet
DSC – Departamento de Sistemas e Computação
FAQ – Frequently Asked Questions
FURB – Universidade Regional de Blumenau
J2SE – Java 2 Standard Edition
JSP – Java Server Pages
LCI – Laboratório de Computação e Informática
MVC – Model View Controller
PL/SQL – Procedural Language / Structured Query Language
RF – Requisitos Funcionais
RNF – Requisitos Não Funcionais
SLA – Service Level Agreement
TCC – Trabalho de Conclusão de Curso
TI – Tecnologia da Informação
UML – Unified Modeling Language
XML – Extensible Markup Language
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 12
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 13
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 13
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 14
2.1 CONTEXTUALIZAÇÃO ................................................................................................. 14
2.2 TECNOLOGIAS ............................................................................................................... 15
2.2.1 FRAMEWORK STRUTS 2 ............................................................................................ 15
2.2.2 MODEL VIEW CONTROLLER (MVC) ....................................................................... 17
2.2.3 CSS E JAVASCRIPT ..................................................................................................... 17
2.3 TRABALHOS CORRELATOS ........................................................................................ 18
3 DESENVOLVIMENTO .................................................................................................... 19
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA ............................................................... 19
3.2 ESPECIFICAÇÃO ............................................................................................................ 21
3.2.1 DIAGRAMAS DE CASOS DE USO ............................................................................. 21
3.2.2 DIAGRAMA DE CLASSES .......................................................................................... 27
3.2.3 MODELO DE ENTIDADE E RELACIONAMENTO .................................................. 29
3.2.4 DIAGRAMA DE SEQUÊNCIA ..................................................................................... 32
3.2.5 DIAGRAMA DE NAVEGAÇÃO .................................................................................. 32
3.2.6 DIAGRAMA DE ATIVIDADES ................................................................................... 33
3.3 IMPLEMENTAÇÃO ........................................................................................................ 34
3.3.1 TÉCNICAS E FERRAMENTAS UTILIZADAS ........................................................... 35
3.3.1.1 ARQUITETURA .......................................................................................................... 35
3.3.1.2 INTERFACE ................................................................................................................ 36
3.3.1.3 BASE DE DADOS ....................................................................................................... 37
3.3.1.4 ESTRUTURA ............................................................................................................... 40
3.3.2 OPERACIONALIDADE DA IMPLEMENTAÇÃO ...................................................... 44
3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 52
4 CONCLUSÕES .................................................................................................................. 59
4.1 EXTENSÕES .................................................................................................................... 60
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 61
ANEXO A – Formulário de Solicitação de Serviço ao LCI ................................................ 63
12
1 INTRODUÇÃO
Vive-se em uma sociedade de informação onde, cada vez mais, nos diversos
segmentos, a informatização e/ou automatização de processos vem tornando-se característica
comum. O objetivo principal por parte das instituições com esta mudança está relacionado ao
aumento da competitividade, a partir da redução de custos e da adequação dos processos
internos, visando atender da melhor forma e de maneira mais eficiente aos seus clientes.
Em relação às instituições de ensino, esta realidade não é diferente, onde existem
também vários processos os quais podem vir a serem aprimorados a partir dos diversos
recursos da informática. Neste sentido, a Universidade Regional de Blumenau (FURB)
encontra-se em estágio privilegiado de desenvolvimento, possuindo cursos específicos na área
tecnológica, bem como, um núcleo exclusivo de informática, disponibilizando vários recursos
facilitadores aos seus clientes e colaboradores, como, os sistemas de matrículas e de
impressões on-line (UNIVERSIDADE REGIONAL DE BLUMENAU, 2008b;
UNIVERSIDADE REGIONAL DE BLUMENAU, 2008c), entre outros. Além disso, possui
laboratórios de ensino e aprendizagem, como o Laboratório de Computação e Informática
(LCI).
Neste laboratório, LCI (UNIVERSIDADE REGIONAL DE BLUMENAU, 2008a),
trabalha uma equipe de profissionais a qual é responsável pela manutenção de todos os
laboratórios e equipamentos utilizados no Departamento de Sistemas e Computação (DSC).
Atualmente, para exemplificar, quando da existência de alguma necessidade em relação a
algum destes recursos, por parte dos professores e alunos, a mesma deve ser registrada em
formulário pré-impresso (ver anexo A), disponível nos murais em cada laboratório ou
verbalmente.
Este modelo apresenta algumas limitações, pois dificulta o gerenciamento das
solicitações por parte da equipe do LCI e impossibilita um acompanhamento adequado em
relação ao estágio das mesmas pelos seus respectivos solicitantes. A partir disto, e,
objetivando dar continuidade ao ciclo de informatização dos processos internos da
universidade, surgiu à necessidade de desenvolvimento de um sistema para o registro e
controle destas solicitações e de outras rotinas e serviços associados aos laboratórios.
13
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho é o desenvolvimento de uma aplicação Web para automatizar
o gerenciamento dos processos e serviços prestados pelo LCI.
Os objetivos específicos deste trabalho são:
a) gerenciar os processos internos do LCI gerados a partir dos serviços prestados pela
sua equipe de funcionários como: Gerenciamento de Chamados, Gerenciamento de
Estoque Interno e Gerenciamento de Atividades;
b) controlar o acesso dos usuários ao sistema através de login, senha e perfis, onde
cada usuário terá acesso somente às funcionalidades específicas de seu grupo;
c) desenvolver um ambiente Web disponibilizando estes recursos, eliminando, assim,
a dependência em relação ao local físico de trabalho.
1.2 ESTRUTURA DO TRABALHO
O presente trabalho está organizado em quatro capítulos, onde, o primeiro capítulo
descreve o problema inicial que motivou o desenvolvimento desta aplicação bem como os
objetivos específicos a serem alcançados pela mesma. O segundo capítulo descreve a
fundamentação teórica acerca deste problema, contextualizando o mesmo e apresentando a
revisão bibliográfica realizada. Já o terceiro capítulo descreve a especificação e a
implementação da aplicação, identificando os requisitos levantados e os resultados obtidos a
partir dos testes realizados. Por fim, o quarto capítulo descreve as conclusões obtidas, as
limitações e possíveis extensões deste trabalho.
14
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo é abordada a revisão bibliográfica realizada, apresentando a
contextualização do problema no mundo globalizado, as principais tecnologias utilizadas no
contexto da aplicação e as tecnologias complementares.
2.1 CONTEXTUALIZAÇÃO
No mundo globalizado as organizações buscam constantemente aperfeiçoarem os seus
processos visando tornarem-se mais competitivas. Para que isto seja possível, os seus gestores
necessitam de subsídios que os auxiliem na tomada de decisão. Neste contexto, cada vez mais,
o gerenciamento das informações, através da informatização, vem adquirindo um papel
fundamental (XAVIER, 2005).
Grandes volumes das informações a serem gerenciadas atualmente correspondem a
processos, os quais, normalmente, estão representados através de documentos impressos,
como, formulários e planilhas. Entretanto esta sistemática apresenta algumas deficiências:
a) segundo estudos realizados pela empresa PriceWaterHouseECoopers (1998) os
executivos gastam, em média, 150 horas por ano solicitando, aguardando e
localizando documentos;
b) segundo Gartner Group / Datapro (2008 apud TS&O Consultoria Soluções em TI)
cada funcionário guarda, em média, 20 mil folhas de papel por ano entre tipos
diversos de arquivos;
Além disso, é praticamente impossível a geração de informações estatísticas referentes
a estes processos, e ainda, existe a questão ambiental relacionada a impressões excessivas
e/ou desnecessárias.
Neste sentido surgiu a necessidade de informatização dos processos e serviços
prestados pelo LCI através de um sistema de gerenciamento. Conforme TS&O Consultoria
Soluções em TI (2008) a possibilidade de informatização e o gerenciamento das informações
acerca destes processos podem oferecer, entre outros benefícios:
a) agilidade na comunicação: uma vez que todas as informações referentes a um
chamado, por exemplo, estarão disponíveis on-line;
15
b) descentralização: a partir da eliminação da dependência em relação ao local físico
dos arquivos dos documentos que anteriormente controlavam estes processos;
c) controles e estatísticas: através da emissão de relatórios diversos, controles de
estágios, responsáveis e ações realizadas em relação ao atendimento dos
chamados, por exemplo;
d) histórico: uma vez que todas as informações relacionadas a estes processos estarão
armazenadas em meio digital.
2.2 TECNOLOGIAS
Nesta seção são abordadas as principais tecnologias utilizadas para o desenvolvimento
do sistema.
2.2.1 FRAMEWORK STRUTS 2
Segundo Cavaness (2003) um framework corresponde a um conjunto de classes e
interfaces que cooperam entre si para solucionar um tipo de problema de software. Em geral,
um framework apresenta as seguintes características:
a) compreende múltiplas classes e/ou componentes onde cada qual deve prover uma
abstração de um conceito particular;
b) define como estas abstrações trabalharão em conjunto para solucionar um
determinado problema;
c) possui componentes reutilizáveis;
d) organiza padrões em alto nível.
O Struts 2 é um framework open source da Apache Software Foundation que favorece
o desenvolvimento de aplicações Web baseadas no padrão Model View Controller (MVC) de
arquitetura (LETS FUN JAVA, 2008).
Segundo Apache Software Foundation (2008) o framework Struts é excelente para o
desenvolvimento de aplicações Java Web, tendo sido concebido organizar e aperfeiçoar o
processo de desenvolvimento e manutenção de aplicações neste sentido.
16
O funcionamento do Struts 2 é representado, basicamente, por um arquivo de
configuração eXtensible Markup Language (XML), o qual é responsável pelo mapeamento
das ações a serem realizadas pelo sistema a partir das interações realizadas pelos usuários
através da camada de aplicação. Este arquivo (struts.xml) é armazenado no mesmo
diretório das classes do projeto.
O struts.xml realiza a comunicação entre as camadas de visão e controle da
aplicação através do elemento XML <action> a partir dos atributos:
a) name: o qual identifica cada action no contexto da aplicação. O valor definido
neste atributo é utilizado para acesso às mesmas a partir da camada de aplicação;
b) class: o qual identifica a classe (camada de controle) a qual cada action está
associada;
c) method: o qual identifica o método assinado na respectiva classe que será invocado
quando do acesso a action em questão.
A execução deste método retorna uma String como resposta ao Struts indicando
sucesso (SUCCESS) em caso de êxito na sua execução ou erro (ERROR) em caso de exceções. O
Struts, por sua vez, processa esta resposta através do subelemento XML <result>, o qual está
vinculado a action, e encaminha uma resposta a camada de aplicação. Esta resposta,
geralmente, corresponde a uma nova página (NETO, 2007). Este fluxo é representado através
da Figura 1.
Fonte: Lets Fun Java (2008).
Figura 1 - Fluxo Struts 2
17
2.2.2 MODEL VIEW CONTROLLER (MVC)
Segundo Macoratti (2007) o MVC corresponde a um padrão de arquitetura de
aplicações que tem como objetivo separar em camadas distintas a lógica, a interface e o fluxo
da aplicação, onde:
a) a camada View implementa a interface através da qual o usuário interage com a
aplicação;
b) a camada Controller implementa o fluxo da aplicação, sendo responsável pela
comunicação entre as camadas View e Model;
c) a camada Model implementa a lógica da aplicação, sendo responsável pelo
armazenamento, manipulação e geração dos dados.
Entre as principais vantagens obtidas a partir da utilização do MVC destacam-se:
a) facilita e agiliza o processo de manutenção do software a partir do isolamento das
camadas;
b) possibilita o desenvolvimento/customização das camadas em paralelo;
c) maximiza o reaproveitamento de código.
2.2.3 CSS E JAVASCRIPT
Em relação às tecnologias complementares adotadas no desenvolvimento da aplicação
destacam-se o Cascading Style Sheet (CSS) e a linguagem JavaScript.
O CSS segundo Silva (2005) representa um mecanismo simples para adicionar estilos
(configurações de fontes, cores, entre outros) a documentos Web. Entre as principais
vantagens obtidas a partir da sua utilização citam-se:
a) controle da apresentação da aplicação a partir de um único arquivo;
b) simplificação e agilidade em relação a manutenção/customização.
O JavaScript é interpretado no cliente e segundo CriarWeb.com (2008) permite a
criação de páginas interativas. A grande vantagem obtida a partir da sua utilização consiste na
possibilidade de controlar as ações realizadas em cada página no ambiente do cliente.
18
2.3 TRABALHOS CORRELATOS
Para melhor fundamentação deste trabalho, abaixo estão relacionadas ferramentas
semelhantes e/ou com os mesmos objetivos, sendo aplicadas na área de Tecnologia da
Informação (TI) voltadas para a área de gestão de processos.
Relativa Soluções (2008) apresenta o software Relativa IT – Manager, o qual é um
sistema proprietário da empresa Relativa Soluções que possui uma central de gerenciamento
de serviços para o relacionamento entre os seus clientes e os colaboradores da Tecnologia da
Informação (TI) interna, que pode ocorrer, entre outras formas, através de um portal Web.
Neste portal, é possível, por exemplo, a abertura e acompanhamento de chamados. O software
possui, ainda, indicadores de desempenho e relatórios específicos de Service Level Agreement
(SLA).
Ribeiro (2007) propõe o desenvolvimento de uma ferramenta Web, também a ser
utilizada pela FURB, mas no caso para o gerenciamento das rotinas relacionadas à disciplina
de Trabalho de Conclusão de Curso (TCC) I. Este sistema utilizará banco de dados MySQL e
será desenvolvido em linguagem Java Server Pages (JSP).
Roeder (2006) cujo TCC originou uma ferramenta Web que também utiliza banco de
dados MySQL, e tinha como finalidade gerenciar o processo de manutenções de
equipamentos, que também é um dos processos a serem representados pelo sistema proposto.
Meisen (2005) cujo TCC originou também uma ferramenta Web, cuja finalidade era
auxiliar os gerentes de projetos e os analistas de sistemas em relação ao gerenciamento de
requisitos baseada nas recomendações do modelo Capability Maturity Model Integration
(CMMI). Esta ferramenta foi desenvolvida em linguagem JSP, utilizando a primeira versão do
framework Struts e a sua arquitetura foi construída segundo o padrão MVC.
Em comum a esta monografia estes trabalhos apresentam características como: o
ambiente Web, o qual é comum aos quatro, o banco de dados MySQL, comum aos trabalhos
de Ribeiro (2007) e Roeder (2006); a utilização do framework Struts e a arquitetura MVC,
comum ao trabalho de Meisen (2005); e a linguagem JSP, a qual é comum aos trabalhos de
Ribeiro (2007) e Meisen (2005). Nenhum destes, porém, representa e atende adequadamente a
realidade e os processos vigentes no LCI, sendo aplicações genéricas como o software
Relativa IT – Manager, ou específicas a outros segmentos/processos como os trabalhos de
Ribeiro (2007) e Roeder (2006).
19
3 DESENVOLVIMENTO
Neste capítulo é abordado o desenvolvimento do sistema proposto para o
gerenciamento dos processos internos e serviços prestados pelo LCI, apresentando os
requisitos, a especificação, a implementação e os resultados obtidos.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA
A necessidade de desenvolvimento deste sistema foi exposta em uma das reuniões da
disciplina de TCC I durante o primeiro semestre do corrente ano, pelo professor da disciplina
e coordenador do LCI, o senhor Dalton Solano dos Reis.
Os processos a serem representados, bem como os requisitos funcionais para o
desenvolvimento do mesmo foram levantados a partir de uma reunião com um dos
funcionários do LCI, o senhor Dangelo Moraes, e diversas reuniões semanais com o professor
coordenador do LCI, o qual é também o orientador deste trabalho.
A partir destas informações chegou-se a uma série de Requisitos Funcionais (RF) e
Requisitos Não Funcionais (RNF) necessários para o sistema, e, dentre estes, os principais são
listados a seguir:
c) o sistema deverá permitir aos alunos e professores realizarem a abertura de
chamados (solicitações de serviço) para a equipe de funcionários do LCI,
identificando a prioridade e uma descrição da solicitação (RF);
d) o sistema deverá permitir aos alunos e professores realizarem o acompanhamento
dos chamados abertos pelos mesmos, a fim de poderem verificar o estágio das suas
solicitações (RF);
e) o sistema deverá permitir a equipe de funcionários do LCI realizar o gerenciamento
destes chamados, sendo possível definir um ou mais responsáveis e registrar os
diferentes estágios de desenvolvimento dos mesmos (RF);
f) o sistema deverá permitir aos responsáveis pelo chamado, ou, por qualquer outro
usuário, participante no processo de desenvolvimento de determinado chamado, o
registro de observações pertinentes ao mesmo (RF);
20
g) o sistema deverá permitir a equipe de funcionários do LCI realizar o
preenchimento do relatório de atividades, o qual representa a descrição das suas
atividades realizadas semanalmente (RF);
h) o sistema deverá permitir a equipe de funcionários do LCI realizar o registro de
seus horários de trabalho, identificando, diariamente, os horários de entrada e
saída, bem como, o período de intervalo (RF);
i) o sistema deverá permitir a equipe de funcionários do LCI realizar o gerenciamento
dos recursos disponíveis em estoque, controlando a quantidade disponível de cada
item (RF);
j) o sistema deverá ser implementado utilizando as linguagens Java e JSP (RNF);
k) o sistema deverá utilizar banco de dados MySQL para armazenamento das
informações (RNF);
l) o sistema deverá estar disponível em ambiente Web, sendo compatível ao servidor
Apache (RNF).
Percebendo a existência de diferentes responsabilidades em relação à utilização do
sistema, optou-se pela modularização do mesmo de acordo com os diferentes perfis de
usuários. Foram criados quatro perfis de usuários, sendo Administrador, LCI, Aluno e
Professor; e quatro módulos, sendo Gerenciamento de Chamados, Gerenciamento de
Atividades, Gerenciamento de Estoque e Gerenciamento de Usuários.
O módulo de Gerenciamento de Chamados abrange as funcionalidades relacionadas
às solicitações de serviço junto ao LCI e contempla tanto os usuários solicitantes (alunos e
professores) quanto os usuários realizadores (LCI e Administrador). No caso do primeiro
grupo, os usuários solicitantes, é possível realizar a abertura de chamados, informando qual a
necessidade e a prioridade desejada para o atendimento da mesma, bem como, realizar um
acompanhamento em relação ao seu atendimento, verificando o estágio dos mesmos conforme
o processo de atendimento interno do LCI. Já no caso do segundo grupo, os usuários
realizadores, é possível realizar o gerenciamento destes chamados, conhecendo o solicitante
de cada chamado em particular e a data de abertura dos mesmos. Além disso, é possível
designar um ou mais responsáveis internos pelo atendimento de cada chamado e identificar,
durante o processo de atendimento dos mesmos, os diferentes estágios em que estes se
encontram em relação ao seu nível de desenvolvimento.
O módulo de Gerenciamento de Atividades é para o uso exclusivo dos usuários
realizadores (LCI e Administrador) e permite aos mesmos registrarem para cada dia de
trabalho, os seus horários de entrada e saída e o tempo de intervalo em minutos. Além disso, é
21
possível também realizar o preenchimento do relatório de atividades, indicando um período
inicial e final e descrevendo as atividades realizadas durante o mesmo.
O módulo de Gerenciamento de Estoque, assim como o anterior, é para uso
exclusivo dos usuários realizadores (LCI e Administrador) e permite o registro das diversas
peças e equipamentos disponíveis em estoque, bem como, as suas respectivas quantidades. A
partir deste registro, é possível a gestão em relação à disponibilidade e a necessidade de
recursos materiais.
O módulo de Gerenciamento de Usuários é para uso exclusivo do administrador do
sistema (Administrador) e permite realizar a manutenção do cadastro dos usuários do
sistema.
3.2 ESPECIFICAÇÃO
Nesta seção é abordada a especificação do sistema desenvolvido utilizando os
conceitos da Unified Modeling Language (UML) através da ferramenta Computer Aided
Software Engineering (CASE) Enterprise Architect (versão 6.1).
3.2.1 DIAGRAMAS DE CASOS DE USO
As possibilidades de interações de cada grupo de usuários com o sistema estão
diretamente relacionadas ao perfil dos mesmos na aplicação. A seguir são representados os
diagramas de casos de uso dos grupos de usuários destacados anteriormente (ver seção 3.1).
A Figura 2 representa o diagrama de casos de uso referentes aos usuários solicitantes
(alunos e professores), os quais são usuários dos perfis Aluno e Professor,
respectivamente.
22
Figura 2 – Diagrama de casos de uso referente aos usuários solicitantes
A Figura 3 representa o diagrama de casos de uso referentes aos usuários realizadores
(LCI e Administrador), os quais são usuários dos perfis Administrador e LCI,
respectivamente.
23
Figura 3 – Diagrama de casos de uso referente aos usuários realizadores
A Figura 4 representa o diagrama de casos de uso referentes ao administrador do
sistema exclusivamente, o qual será usuário do perfil Administrador.
24
Figura 4 – Diagrama de casos de uso referentes ao administrador do sistema
A seguir é realizado o detalhamento dos principais casos de uso correspondentes a
cada um dos perfis de usuários.
O Quadro 1 apresenta o detalhamento do caso de uso UC02 – Abrir chamado, o qual
está relacionado aos usuários dos perfis Aluno e Professor.
Objetivo:
Permitir ao usuário a criação de um novo chamado (solicitação de serviço) junto ao LCI.
Pré-condições:
- O usuário deverá possuir um cadastro ativo no sistema. - O usuário deverá estar logado. Pós-condição:
- Um novo chamado deverá ter sido registrado e estar pendente junto ao LCI. Cenário principal:
1) Após o logon do usuário, o sistema, por padrão, apresenta a página de gerenciamento de chamados.
2) O usuário clica na guia Chamado. 3) O usuário informa qual a sua necessidade, define a prioridade da
mesma e clica no botão confirmar. 4) Um novo chamado foi registrado e está pendente junto ao LCI.
Cenário de exceção:
1) No 3º passo caso o usuário não informe a sua necessidade e/ou não defina uma prioridade o chamado não será registrado e o sistema exibirá uma página de exceção em forma de Frequently Asked
Questions (FAQ). Quadro 1 – Detalhamento do caso de uso UC02 – Abrir chamado
O Quadro 2 apresenta o detalhamento do caso de uso UC05 – Registrar
observação, o qual está relacionado aos usuários de todos os perfis.
Objetivo: Permitir ao usuário realizar o registro de observações relacionadas a um chamado já registrado. Pré-condições: - O usuário deverá possuir um cadastro ativo no sistema. - O usuário deverá estar logado.
25
- O usuário deverá selecionar um chamado já existente para o registro de observações referentes ao mesmo. Pós-condição:
Uma nova observação referente a um chamado foi registrada. Cenário principal:
1) Após o logon do usuário, o sistema, por padrão, apresenta a página de gerenciamento de chamados.
2) O usuário clica sobre o número do chamado para o qual deseja registrar a observação.
3) O sistema posiciona-se na guia Chamado, exibindo a página de detalhamento do chamado em questão.
4) O usuário clica na guia Observações. 5) O usuário informa a observação e clica no botão confirmar. 6) Uma nova observação referente ao chamado selecionado no 2º passo
foi registrada.
Cenário de exceção:
1) No 5º passo caso o usuário não descreva uma observação a mesma não será registrada e o sistema exibirá uma página de exceção em forma de FAQ. Quadro 2 – Detalhamento do caso de uso UC05 – Registrar observação
O Quadro 3 apresenta o detalhamento do caso de uso UC04 – Gerenciar chamados, o
qual está relacionado aos usuários dos perfis Administrador e LCI.
Objetivo: Permitir ao usuário realizar o gerenciamento dos chamados sob a sua responsabilidade. Pré-condições: - O usuário deverá possuir um cadastro ativo no sistema. - O usuário deverá estar logado. Cenário principal:
1) Após o logon do usuário, o sistema, por padrão, apresenta a página de gerenciamento de chamados.
2) O sistema apresentará como padrão, todos os chamados cujo estágio atual seja Desenvolvimento e/ou Solicitado e o usuário logado esteja incluído como responsável pelo mesmo ou seja o administrador do sistema.
3) O usuário poderá organizar e planejar as suas atividades observando os estágios, as prioridades, as datas e o grau de dificuldade destes chamados.
4) O usuário poderá, ainda, pesquisar outros chamados a partir dos filtros disponíveis. Quadro 3 – Detalhamento do caso de uso UC04 – Gerenciar chamados
O Quadro 4 apresenta o detalhamento do caso de uso UC06 – Preencher relatório
de atividades, o qual está relacionado aos usuários dos perfis Administrador e LCI.
Objetivo: Permitir ao usuário realizar o registro do relatório pessoal de atividades no período. Pré-condições: - O usuário deverá possuir um cadastro ativo no sistema.
26
- O usuário deverá estar logado. - O usuário deverá possuir o perfil de Administrador ou do LCI. Pós-condição:
Um novo relatório pessoal de atividades no período foi registrado. Cenário principal:
1) Após o logon do usuário, o sistema, por padrão, apresenta a página de gerenciamento de chamados.
2) O usuário clica na guia Gerência de atividades. 3) O usuário clica na guia Relatório de atividades. 4) O usuário informa o período do relatório, descreve as atividades
realizadas neste período e clica no botão confirmar. 5) Um novo relatório pessoal de atividades foi registrado.
Cenário de exceção:
1) No 5º passo, caso o usuário não informe o período ou a não descreva as atividades realizadas, o relatório não será registrado e o sistema exibirá uma página de exceção em forma de FAQ. Quadro 4 – Detalhamento do caso de uso UC06 – Preencher relatório de atividades
O Quadro 5 apresenta o detalhamento do caso de uso UC07 – Registrar horário de
trabalho, o qual está relacionado aos usuários dos perfis Administrador e LCI.
Objetivo: Permitir ao usuário realizar o registro do controle pessoal de horários. Pré-condições: - O usuário deverá possuir um cadastro ativo no sistema. - O usuário deverá estar logado. - O usuário deverá possuir o perfil de Administrador ou do LCI. Pós-condição:
Um novo controle pessoal de horários foi registrado. Cenário principal:
1) Após o logon do usuário, o sistema, por padrão, apresenta a página de gerenciamento de chamados.
2) O usuário clica na guia Gerência de atividades. 3) O usuário clica na guia Controle de horários. 4) O usuário informa a data de chegada e clica no botão confirmar. 5) Um novo controle pessoal de horários foi registrado.
Cenário alternativo:
1) Ao final de cada dia, o usuário deverá complementar este registro adicionando a data de saída e o tempo de intervalo em minutos. Para isso, no 3º passo, o mesmo deverá selecionar o registro do dia desejado, clicando sobre o mesmo, informar a data de saída e o tempo de intervalo e clicar no botão atualizar.
Cenário de exceção:
1) No 5º passo, caso o usuário não informe a data de chegada, o controle de horários não será registrado e o sistema exibirá uma página de exceção em forma de FAQ. Quadro 5 – Detalhamento do caso de uso UC07 – Registrar horário de trabalho
O Quadro 6 apresenta o detalhamento do caso de uso UC08 – Gerenciar estoque, o
27
qual está relacionado aos usuários dos perfis Administrador e LCI.
Objetivo: Permitir ao usuário realizar o gerenciamento dos recursos disponíveis em estoque. Pré-condições: - O usuário deverá possuir um cadastro ativo no sistema. - O usuário deverá estar logado. - O usuário deverá possuir o perfil de Administrador ou do LCI. Cenário principal:
1) Após o logon do usuário, o sistema, por padrão, apresenta a página de gerenciamento de chamados.
2) O usuário clica na guia Gerência de estoque. 3) O sistema apresentará todos os recursos cadastrados, exibindo a
sua descrição, a quantidade disponível e o seu status. 4) O usuário poderá cadastrar novos recursos e atualizar e/ou excluir
os cadastros já existentes. Quadro 6 – Detalhamento do caso de uso UC08 – Gerenciar estoque
O Quadro 7 apresenta o detalhamento do caso de uso UC10 – Gerenciar usuários, o
qual está relacionado exclusivamente aos usuários do perfil Administrador.
Objetivo: Permitir ao usuário administrador realizar o gerenciamento dos usuários do sistema. Pré-condições: - O usuário deverá possuir um cadastro ativo no sistema. - O usuário deverá estar logado. - O usuário deverá possuir o perfil de Administrador. Cenário principal:
1) Após o logon do usuário, o sistema, por padrão, apresenta a página de gerenciamento de chamados.
2) O usuário clica na guia Gerência de usuários. 3) O sistema apresentará todos os usuários cadastrados. 4) O usuário poderá cadastrar novos usuários e atualizar e/ou excluir
os cadastros já existentes. Quadro 7 – Detalhamento do caso de uso UC10 – Gerenciar usuários
3.2.2 DIAGRAMA DE CLASSES
As interações realizadas pelos usuários com o sistema através da camada de aplicação
são controladas internamente através das classes, as quais também interagem entre si. A
seguir são representadas as interações entre as classes do sistema, bem como, os seus atributos
e métodos.
A Figura 5 representa o diagrama de classes referentes à camada de modelo do
28
sistema.
Figura 5 – Diagrama de classes
Em relação ao diagrama de classes apresentado:
a) A classe Chamado é responsável pelo processamento das informações referentes
aos chamados (solicitações de serviço) abertos junto ao LCI;
b) A classe Responsavel é responsável pelo processamento das informações
referentes aos usuários responsáveis pelo atendimento de cada chamado;
29
c) A classe Historico é responsável pelo processamento das informações referentes
as observações cadastradas relacionadas a cada chamado;
d) A classe Estagio é responsável pelo processamento das informações referentes
aos diferentes estágios de cada chamado durante o seu processo de atendimento;
e) A classe Usuario é responsável pelo processamento das informações referentes
aos usuários do sistema;
f) A classe Horario é responsável pelo processamento das informações referentes
aos horários de trabalho de cada funcionário do LCI (horário de entrada e saída e o
tempo de intervalo) para cada dia da semana;
g) A classe Relatorio é responsável pelo processamento das informações referentes
ao relatório de atividades semanal o qual deve ser preenchido por cada funcionário
do LCI descrevendo as atividades realizadas naquele período;
h) A classe Estoque é responsável pelo processamento das informações referentes
aos recursos disponíveis em estoque e a sua respectiva quantidade.
3.2.3 MODELO DE ENTIDADE E RELACIONAMENTO
As interações entre os usuários e o sistema na camada de aplicação, aliadas as
interações entre as classes internamente na camada de controle, podem gerar a necessidade de
uma nova interação entre a camada de controle e a camada de modelo, a qual é responsável
pelo tratamento das informações em nível de banco de dados.
A Figura 6 representa o modelo entidade e relacionamento (MER) referente à camada
de modelo do sistema.
30
Figura 6 – Modelo de entidade e relacionamento
Assim como a aplicação foi organizada em módulos, as entidades também estão
31
organizadas conforme o módulo ao qual estão vinculadas. As entidades exibidas na área
superior da Figura 6 estão relacionadas ao módulo de Gerenciamento de Chamados, onde:
a) a entidade LCI_CHAMADO armazena os registros referentes aos chamados
(solicitações de serviço) abertos junto ao LCI;
b) a entidade LCI_CHAMADO_RESPONSAVEL armazena os registros referentes aos
usuários responsáveis pelo atendimento de cada chamado;
c) a entidade LCI_CHAMADO_HISTORICO armazena os registros referentes as
observações cadastradas relacionadas a cada chamado;
d) a entidade LCI_CHAMADO_ESTAGIO armazena os registros referentes aos diferentes
estágios de cada chamado durante o seu processo de atendimento. Estes registros
têm objetivos gerenciais e estatísticos e são gerados internamente pela aplicação.
As entidades exibidas na área inferior direita da Figura 6 estão relacionadas ao módulo
de Gerenciamento de Atividades, onde:
a) a entidade LCI_HORARIO armazena os registros referentes aos horários de trabalho
de cada funcionário do LCI (horário de entrada e saída e o tempo de intervalo) para
cada dia da semana;
b) a entidade LCI_ATIVIDADE armazena os registros referentes ao relatório de
atividades semanal o qual deve ser preenchido por cada funcionário do LCI
descrevendo as atividades realizadas naquele período.
A entidade exibida na área inferior esquerda da Figura 6 (LCI_ESTOQUE) está
relacionada ao módulo de Gerenciamento de Estoque, onde são armazenados os registros
referentes aos recursos disponíveis em estoque e a sua respectiva quantidade.
A entidade exibida na área central da Figura 6 (LCI_USUARIO) está relacionada ao
módulo de Gerenciamento de Usuários, onde são armazenados os registros referentes aos
usuários do sistema, identificando o seu perfil e permissões em relação ao uso da aplicação.
Por fim, todas as entidades do modelo possuem ainda dois atributos em comum, os
quais têm objetivos gerenciais, sendo:
a) NR_SEQ_USUARIO_ORIGINAL o qual identifica o usuário responsável pelo
cadastramento do registro na base de dados;
b) NR_SEQ_USUARIO_ATUAL o qual identifica usuário responsável pela última
atualização do registro na base de dados.
32
3.2.4 DIAGRAMA DE SEQUÊNCIA
A Figura 7 representa o diagrama de seqüência referente aos processos realizados
internamente pela aplicação para o povoamento da entidade LCI_CHAMADO_ESTAGIO em
relação aos estágios de atendimento dos chamados.
Figura 7 - Diagrama de seqüência
3.2.5 DIAGRAMA DE NAVEGAÇÃO
A Figura 8 representa o diagrama de navegação da aplicação em relação à
possibilidade de abertura de um novo chamado.
33
Figura 8 - Diagrama de navegação
3.2.6 DIAGRAMA DE ATIVIDADES
A Figura 9 representa o diagrama de atividades da aplicação em relação ao processo de
pesquisa de chamados.
34
Figura 9 - Diagrama de atividades
3.3 IMPLEMENTAÇÃO
Nesta seção é abordada a implementação do sistema desenvolvido, apresentando as
técnicas e ferramentas utilizadas e a operacionalidade da implementação.
35
3.3.1 TÉCNICAS E FERRAMENTAS UTILIZADAS
O sistema aqui desenvolvido consiste em um sistema Web, o qual foi concebido
utilizando-se a linguagem Java 2 Standard Edition (J2SE), na sua versão 1.6.0.07 compilada
em versão 1.5, framework Struts 2 na sua versão 2.0.9 e banco de dados MySQL, na sua
versão 5.1.11. O servidor Web utilizado foi o Apache Tomcat na sua versão 5.5.17.
O modelo de entidade e relacionamento foi desenvolvido a partir da ferramenta
DbSchema. A implementação das classes e das páginas do sistema foram realizadas através
da ferramenta NetBeans IDE 5.5, enquanto a base de dados foi construída a partir das
ferramentas MySQL Administrador e MySQL Query Browser. A diagramação foi realizada
através da ferramenta Enterprise Architect, na sua versão 6.1.785.
3.3.1.1 ARQUITETURA
A arquitetura do sistema foi construída segundo o padrão MVC (ver seção 2.2). Optou-
se por este padrão por ser o mais recomendado no desenvolvimento de aplicações Web devido
a sua segurança, flexibilidade, padronização e organização.
A Figura 10 ilustra a divisão entre as camadas de modelo, visão e controle através do
diagrama de pacotes, bem como, a comunicação entre as mesmas a partir do Struts 2.
36
Figura 10 - Diagrama de pacotes
3.3.1.2 INTERFACE
As configurações gráficas do sistema foram construídas segundo o padrão CSS.
Optou-se por este padrão por ser o mais recomendado no desenvolvimento de aplicações Web,
em relação a sua apresentação visual, devido à organização resultante da sua utilização,
através da separação entre a formatação e o conteúdo das páginas.
Através do Quadro 8, o qual mostra os estilos aplicados aos botões Inserir,
Atualizar, Excluir e Confirmar pode-se perceber também a padronização resultante da
utilização do CSS. Uma vez que, a partir destas configurações estes botões serão idênticos em
todas as páginas da aplicação. Além da praticidade e agilidade em relação a sua manutenção,
caso necessário, pois, bastaria alterarmos o arquivo de configuração CSS e esta alteração seria
aplicada a todo o sistema.
.botaoInserir {
width : 90px;
height : 26px;
font : bold 13px/15px calibri;
text-decoration : none;
text-align : center;
background-position : left;
background-image : url(icones/add.gif);
37
background-repeat : no-repeat;}
.botaoAtualizar {
width : 90px;
height : 26px;
font : bold 13px/15px calibri;
text-decoration : none;
text-align : center;
background-position : left;
background-image : url(icones/refresh.gif);
background-repeat : no-repeat;}
.botaoExcluir {
width : 90px;
height : 26px;
font : bold 13px/15px calibri;
text-decoration : none;
text-align : center;
background-position : left;
background-image : url(icones/del.gif);
background-repeat : no-repeat;}
.botaoConfirmar {
width : 100px;
height : 26px;
font : bold 13px/15px calibri;
text-decoration : none;
text-align : center;
background-position : left;
background-image : url(icones/confirm.gif);
background-repeat : no-repeat;}
Quadro 8 – Exemplo de utilização do CSS
3.3.1.3 BASE DE DADOS
Conforme já citado no início desta seção, a base de dados da aplicação foi construída
em plataforma MySQL. A sua escolha deve-se, entre outros motivos, a sua portabilidade,
confiabilidade, desempenho e multiplataforma (em nível de sistema operacional); além de ser
um banco de dados open source.
38
Em relação ao MySQL cabe destacar algumas situações identificadas durante o
desenvolvimento do sistema como o case sensitive, os caracteres especiais, a performance e o
uso de Procedural Language / Structured Query Language (PL/SQL).
A necessidade em relação ao case sensitive (distinção entre os caracteres maiúsculos e
minúsculos) surgiu quando do cadastramento dos logins e senhas dos usuários para acesso ao
sistema. Por padrão, o MySQL não realiza esta distinção, o que neste caso poderia tornar o
sistema instável e inseguro. Então, após pesquisas neste sentido, descobriu-se a existência da
propriedade BYNARY em relação às colunas de uma tabela. Neste caso, para que o SGBD
realize automaticamente esta distinção a mesma deve ser definida como sendo verdadeira ao
criar e/ou adicionar uma coluna em uma tabela.
Em relação aos caracteres especiais (com acentuação), logo no início do
desenvolvimento da aplicação percebeu-se a ocorrência de erros ao gravar e recuperar
informações da base de dados que continham estes caracteres. Após levantamento de
informações acerca deste problema descobriu-se que em MySQL a base de dados, bem como
as tabelas e os objetos possuem a propriedade character-set, a qual define o conjunto e o
formato dos caracteres suportados, cujo formato padrão é o latin1, o qual não suporta
caracteres especiais. Neste caso, conforme mostra o Quadro 9, referente ao exemplo de
criação de tabela em MySQL, para que a base de dados ofereça suporte à estes caracteres esta
propriedade deve ser definida como sendo UTF8. Além disso, ao realizar a conexão com a
base de dados através da aplicação, deve ser passado o parâmetro useUnicode, conforme
mostra o Quadro 10.
CREATE TABLE `DB_JSPLCI`.`lci_usuario` ( `NR_SEQUENCIA` int(11) NOT NULL auto_increment, `DS_LOGIN` char(15) character set latin1 collate latin1_bin NOT NULL, `DS_SENHA` char(15) character set latin1 collate latin1_bin NOT NULL, `IE_PERFIL` char(1) NOT NULL, `IE_RECEPTOR` char(1) NOT NULL, `NM_USUARIO` char(80) NOT NULL, `DS_EMAIL` char(40) NOT NULL, `DS_EMAIL_ALTERNATIVO` char(40) default NULL, `IE_STATUS` char(1) NOT NULL, `NR_SEQ_USUARIO_ORIGINAL` int(11) default NULL, `NR_SEQ_USUARIO_ATUAL` int(11) default NULL, PRIMARY KEY (`NR_SEQUENCIA`), UNIQUE KEY `LCI_USUARIO_UK` (`DS_LOGIN`), KEY `LCI_USUARIO_FK1` (`NR_SEQ_USUARIO_ORIGINAL`), KEY `LCI_USUARIO_FK2` (`NR_SEQ_USUARIO_ATUAL`), CONSTRAINT `LCI_USUARIO_FK1` FOREIGN KEY (`NR_SEQ_USUARIO_ORIGINAL`) REFERENCES `lci_usuario` (`NR_SEQUENCIA`), CONSTRAINT `LCI_USUARIO_FK2` FOREIGN KEY (`NR_SEQ_USUARIO_ATUAL`) REFERENCES `lci_usuario` (`NR_SEQUENCIA`) ) ENGINE=InnoDB AUTO_-INCREMENT=10 DEFAULT CHARSET=UTF8;
Quadro 9 - Propriedade character-set em uma tabela na base de dados MySQL
39
private void conectar() throws Exception {
try {
if (c == null) {
Class.forName("com.mysql.jdbc.Driver");
C = DriverManager.getConnection(
"jdbc:mysql://campeche.inf.furb.br:3306/DB_JSPLCI?useUnicode=true",
"db_jsplci", "kso38ac6");
}
} catch(Exception e) {
throw e;
}
}
Quadro 10 - Parâmetro useUnicode passado na conexão com a base de dados MySQL
E ainda, é necessário que as páginas da aplicação também suportem este formato de
caracteres, e neste caso, tal configuração é realizada através da Tag File pageEncoding,
conforme mostra o Quadro 11.
<%@ page pageEncoding="UTF-8" %>
<html>
<body>
...
</body>
</html>
Quadro 11 - Tag File pageEncoding
Em relação ao desempenho, no início do corrente semestre foi realizada uma reunião
com o professor Adilson Vahldick onde foram discutidos alguns conceitos relacionados ao
Java e ao MySQL no contexto do sistema proposto. Nesta oportunidade foi esclarecido pelo
mesmo que o SGBD em MySQL apresenta melhor desempenho, em relação as informações
descritivas, quando o tipo de dado das mesmas é definido como Char, tendo sido
recomendado, sempre que possível, utilizá-lo. Por este motivo todos os atributos descritivos
de até 255 posições, que corresponde ao número máximo de caracteres suportado por este tipo
de dado, foram convertidos em Char a fim de aperfeiçoar o desempenho da base de dados da
aplicação.
Por fim, visando garantir maior organização, a partir da redução de código fonte na
40
camada de aplicação, e segurança, a partir da manipulação de dados exclusivamente na
camada de modelo, utilizou-se a linguagem PL/SQL para a construção de objetos como
triggers, procedures e functions.
O Quadro 12 mostra o exemplo de criação de uma trigger, a qual realiza a inserção
de um registro em uma das tabelas do sistema e invoca a execução de uma procedure.
DELIMITER $$ CREATE DEFINER = `db_jsplci`@`campeche.inf.furb.br` TRIGGER `lci_chamado_update` AFTER UPDATE ON `lci_chamado` FOR EACH ROW BEGIN IF (NEW.IE_ESTAGIO <> OLD.IE_ESTAGIO) THEN INSERT INTO lci_chamado_estagio (IE_ESTAGIO, DT_ESTAGIO, NR_SEQ_CHAMADO, NR_SEQ_USUARIO) VALUES (NEW.IE_ESTAGIO, NOW(), NEW.NR_SEQUENCIA, NEW.NR_SEQ_USUARIO_ATUAL); if (NEW.IE_ESTAGIO = 'D') then call lci_gerar_responsavel(NEW.NR_SEQUENCIA, NEW.NR_SEQ_USUARIO_ATUAL); end if; END IF; END $$ DELIMITER ;
Quadro 12 - Exemplo de utilização da linguagem PL/SQL
3.3.1.4 ESTRUTURA
A aplicação utiliza o conceito de framework, tendo sido construída baseada na
estrutura Struts 2 (ver seção 2.2). Optou-se por este framework por favorecer o
desenvolvimento de aplicações Web baseadas no padrão MVC de arquitetura, contexto no
qual a aplicação está inserida.
Além disso, o Struts 2 é um framework open source, e a sua utilização oferece maior
organização e controle a partir da centralização das informações referentes às interações entre
o cliente e o servidor na aplicação.
O Struts, no contexto da aplicação, basicamente, é o responsável pela comunicação
entre as camadas de visão e controle através das action. A seguir é ilustrado este
funcionamento através do detalhamento do processo de geração da página de Gerência de
estoque, conforme mostra a Figura 11.
41
Figura 11 - Página gerência de estoque
O sistema possui uma estrutura de navegação em abas onde cada página é composta
por iframes e cada iframe comporta um JSP. Conforme mostra o Quadro 13, a aba
Gerência de estoque é composta por dois iframes, sendo o primeiro (iGridEstoque), um
exemplo de comunicação através do Struts.
<html>
<head>
<link rel="stylesheet" type="text/css" href="lci.css">
<script src="lci.js" type="text/javascript"></script>
</head>
<body>
<iframe id="iGridEstoque" name="iGridEstoque"
src="gerarGridEstoque.action" width="100%" height="70%" scrolling="auto"
frameborder="1">
</iframe>
<iframe id="iDetalheEstoque" name="iDetalheEstoque"
src="iDetalheEstoque.jsp" width="100%" height="30%" scrolling="auto"
frameborder="1">
</iframe>
</body>
42
</html>
Quadro 13 – Composição JSP da página gerência de estoque
Neste caso, a propriedade src do iframe indica para a aplicação uma chamada da
action gerarGridEstoque, cadastrada no Struts e identificada pela propriedade name,
conforme mostra o Quadro 14 referente fragmento de código responsável pelo tratamento
desta classe no Struts.
<!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd"> <struts> <package name="Struts" extends="struts-default"> <interceptors> <interceptor-stack name="systemDefaultStack"> <interceptor-ref name="model-driven"/> <interceptor-ref name="defaultStack"/> </interceptor-stack> </interceptors> <default-interceptor-ref name="systemDefaultStack"/> <action class="br.com.webaction.Estoque" method="gerarGrid" name="gerarGridEstoque"> <result name="success"> iGridEstoque.jsp </result> </action> <action class="br.com.webaction.Estoque" method="gerarDetalhe" name="gerarDetalheEstoque"> <result name="success"> iDetalheEstoque.jsp </result> </action> <action class="br.com.webaction.Estoque" method="inserir" name="inserirEstoque"> <result name="success"> iEstoque.jsp </result> </action> <action class="br.com.webaction.Estoque" method="atualizar" name="atualizarEstoque"> <result name="success"> iEstoque.jsp </result> </action> <action class="br.com.webaction.Estoque" method="excluir" name="excluirEstoque"> <result name="success"> iEstoque.jsp </result> </action>
43
<action class="br.com.webaction.Estoque" method="gerarRelatorio" name="gerarRelatorioEstoque"> <result name="success"> iRelatorioEstoque.jsp </result> </action> </package> </struts>
Quadro 14 – Fragmento de código Struts referente à classe Estoque
Cada action está vinculada a uma classe através da propriedade class, que contem o
caminho da mesma nos arquivos do projeto e dispara a execução de um método desta classe,
definido na propriedade method. Os métodos disparados a partir do Struts devem retornar ao
mesmo uma string, sendo SUCCESS em caso de êxito na sua execução ou ERROR em caso de
exceções.
Neste caso, conforme mostra o Quadro 15, o Struts dispara o método gerarGrid
assinado na classe Estoque, e, obtendo sucesso, retorna ao cliente a página
iGridEstoque.jsp conforme definido na tag result.
package br.com.webaction;
import br.com.action.EstoqueAction;
import br.com.system.SystemAction;
import java.util.ArrayList;
import java.util.HashMap;
import org.apache.commons.beanutils.converters.IntegerArrayConverter;
public class Estoque extends SystemAction {
private ArrayList grid;
private HashMap detalhe;
private int nr_seq_detalhe;
private String ds_recurso;
private int qt_recurso;
private String ie_status;
private ArrayList relatorio;
public Estoque() {
}
public String gerarGrid() {
try {
44
EstoqueAction ea = new EstoqueAction();
setGrid(ea.gerarGrid());
return SUCCESS;
} catch (Exception e) {
return ERROR;
}
}
...
...
}
Quadro 15 – Fragmento de código referente à classe Estoque
Neste contexto, a comunicação entre as camadas de visão e controle é sempre
intermediada pelo Struts, onde, através das páginas (camada de visão) serão acionadas as
action cadastradas no Struts que irão disparar os métodos assinados nas classes (camada de
controle), as quais se comunicarão com a camada de modelo, caso necessário.
3.3.2 OPERACIONALIDADE DA IMPLEMENTAÇÃO
Nesta seção é abordada a operacionalidade da aplicação desenvolvida em relação aos
casos UC02 e UC04 (ver seção 3.2.1), pois estes representam a idéia central da aplicação,
bem como, o problema inicial que motivou o seu desenvolvimento.
Neste primeiro momento, é representado o UC02, onde um usuário vinculado ao perfil
Professor realizará a abertura de um novo chamado (solicitação de serviço) referente à
instalação de um determinado software em um laboratório de ensino.
Conforme mostra a Figura 12, após o logon do usuário no sistema, através da digitação
de login e senha, por padrão, é apresentada a página de gerenciamento de chamados, onde são
exibidos todos os chamados nos quais o usuário está envolvido, seja como solicitante ou como
responsável pela execução do mesmo.
Neste caso, os usuários dos perfis Aluno e Professor estarão envolvidos sempre como
sendo os solicitantes dos chamados, enquanto os usuários do perfil LCI poderão estar
envolvidos tanto como sendo os solicitantes ou como sendo os responsáveis
45
execução/atendimento dos mesmos.
Figura 12 - Página gerência de chamados
Nesta página (Figura 12), para realizar a abertura de um novo chamado junto ao LCI, o
usuário deve clicar na guia Chamado. Neste momento, conforme mostra a Figura 13, abre-se
uma nova página onde o usuário deverá informar qual a sua necessidade e a prioridade
desejada em relação ao atendimento da mesma. Após o preenchimento destas informações
deve-se clicar em confirmar para registrar o novo chamado.
46
Figura 13 – Página abertura de um novo chamado
Cada novo chamado registrado assume o estágio de Solicitado em relação ao LCI e
fica, inicialmente, sob a responsabilidade dos usuários receptores, conforme definição
realizada no cadastro de usuários, exemplificada através da Figura 14.
47
Figura 14 – Página cadastro de usuários receptores
A partir deste momento, é representando o UC04, onde um usuário vinculado ao perfil
LCI realizará o gerenciamento deste(s) chamado(s).
Conforme citado anteriormente, após o logon do usuário no sistema, por padrão, é
apresentada a página de gerenciamento de chamados, onde são exibidos todos os chamados
nos quais o usuário está envolvido seja como solicitante ou como responsável pela execução
dos mesmos.
Como padrão, inicialmente são apresentados somente os chamados cujo estágio seja
Solicitado e/ou Desenvolvimento, pois estes representam as solicitações que ainda se
encontram pendentes. No caso dos chamados em estágio Solicitado são exibidos no início
da relação destacados na cor amarela, conforme mostra a Figura 15.
48
Figura 15 – Página chamados sob responsabilidade do usuário
Desta maneira é possível identificar o chamado aberto anteriormente através do UC02.
Ao clicar sobre o código do chamado será aberta a página de detalhamento do mesmo, através
da qual será possível encaminhá-lo para Desenvolvimento selecionando-se o respectivo
estágio e clicando-se em atualizar, conforme mostra a Figura 16.
49
Figura 16 – Página atualizar estágio chamado
Neste momento o chamado fica sob a responsabilidade exclusiva deste usuário sendo
possível alterar o mesmo e/ou adicionar novos responsáveis caso necessário, através deste
mesmo nível de abas, conforme mostra a Figura 17, sendo possível selecionar somente
usuários do perfil LCI.
50
Figura 17 – Página definir responsáveis chamado
Além disso, é possível registrar observações pertinentes ao chamado em questão,
conforme mostra a Figura 18, sendo que cada nova observação inserida em relação a um
chamado será sinalizada aos demais usuários envolvidos na página de gerenciamento através
da coluna OBS, conforme mostra a Figura 19, para que os mesmos possam consultar estas
observações.
51
Figura 18 – Página registro de observações
Figura 19 – Página sinalização de nova observação
52
Por fim, tendo sido concluído o desenvolvimento de um chamado, basta ao usuário
responsável (perfil LCI) alterar o estágio do mesmo para Finalizado, e este não aparecerá
mais como pendente. Este processo também indicará ao usuário solicitante que o mesmo
poderá confirmar a realização da sua solicitação e conferir o atendimento da sua necessidade.
3.4 RESULTADOS E DISCUSSÃO
Procurou-se realizar adequadamente todas as etapas previstas em relação ao
desenvolvimento da aplicação, neste sentido inclusive, o cronograma elaborado foi adequado
para que fosse possível a realização da etapa de testes e validação, considerada muito
importante no contexto deste trabalho.
Com grande empenho, o sistema foi disponibilizado para início dos testes no dia 13 de
outubro de 2008, e em pouco menos de uma semana os usuários sentiram a necessidade de
algumas adaptações. Neste primeiro momento, havia apenas um usuário do perfil
Administrador, dois usuários dos perfis Aluno e/ou Professor e dois usuários do perfil LCI
realizando os testes, tendo sido abertos apenas cinco chamados fictícios. A seguir são
apresentadas as sensações iniciais obtidas em relação a esta bateria inicial de testes:
a) “Eu tenho que digitar duas vezes para cadastrar um usuário?”;
b) “Sempre devo clicar primeiro neste botão?”;
c) “A navegação/usabilidade está confundindo um pouco!”;
d) “Porque tem este Selecione! Aqui nestes campos?”.
Neste contexto, percebeu-se o interesse por parte dos usuários em relação à utilização
da ferramenta, porém, estes encontravam dificuldades de usabilidade em algumas páginas da
aplicação; E devido à impossibilidade de treinamento de todos os usuários envolvidos,
procurou-se criar uma interface mais intuitiva e de fácil interpretação. Uma das customizações
realizadas neste sentido está relacionada à habilitação dos botões conforme as ações
permitidas em cada página da aplicação em cada momento. Por exemplo, na versão inicial do
sistema ao acessar a guia Gerência de usuários estavam habilitados os botões inserir,
atualizar e excluir, conforme mostra a Figura 20. Porém, neste momento, somente era
possível utilizar a opção inserir, através da qual era aberta uma nova página. Então, foram
realizadas adequações para que ao acessar esta guia o sistema já venha posicionado nesta
página, conforme mostra a Figura 21, evitando possíveis dúvidas e erros de interpretação em
53
relação à utilização do sistema.
Figura 20 - Primeira versão da guia gerência de usuários
54
Figura 21 - Segunda versão da guia gerência de usuários
Na primeira versão da aplicação todas as páginas seguiam o padrão correspondente a
Figura 20. Após os testes e a partir das customizações solicitadas foi adotado o padrão de
funcionamento correspondente a Figura 21.
Outra customização realizada neste sentido está relacionada à guia Gerência de
chamados. Na versão inicial do sistema tanto ao clicar sobre o código de um chamado como
ao acessar diretamente a guia Chamado era exibida a mesma estrutura de abas, conforme
mostra a Figura 22. Embora as duas possibilidades representassem ações diferentes em
relação ao sistema, para os usuários este modelo de navegação estava gerando dúvidas e
dificuldades de utilização. Neste caso, o funcionamento do sistema foi ajustado para que,
através do acesso direto a guia Chamado somente seja possível realizar a abertura de um novo
chamado, conforme mostra a Figura 23. E quando do clique sobre o código de um chamado
seja exibido o detalhamento do mesmo, conforme mostra a Figura 24.
55
Figura 22 - Estrutura de abas em gerência de chamados
Figura 23 - Guia chamado em gerência de chamados
56
Figura 24 - Detalhamento do chamado em gerência de chamados
Além disso, também na versão inicial do sistema, todos os campos do tipo combo
apresentavam o texto Selecione! como padrão, conforme mostra a Figura 25. Porém,
percebendo a ocorrência de uma poluição visual nas páginas da aplicação ocasionada por este
texto, a mesma foi removida e todos estes campos passaram a apresentar-se, como padrão,
vazios, conforme mostra a Figura 26.
57
Figura 25 - Primeira versão campos tipo combo
Figura 26 - Segunda versão campos tipo combo
58
Após a realização destas customizações uma nova versão do sistema foi liberada para
testes pelos mesmos usuários no dia 28 de outubro de 2008, e nesta oportunidade os retornos
obtidos foram favoráveis, tendo sido abertos 16 chamados, até o dia 06 de dezembro de 2008,
sendo chamados reais relacionados ao processo de trabalho. A seguir são apresentadas as
sensações obtidas após os testes da nova versão:
a) “Ficaram boas as alterações no sistema!”;
b) “Agora está fácil de usar!”;
c) “A utilização do sistema está tranqüila..”.
Durante o período de testes do sistema identificou-se, ainda, a incompatibilidade do
mesmo com navegadores diferentes ao Internet Explorer (versão 7.0.5730.13). Além deste,
foram realizados testes com os navegadores Mozilla Firefox (versão 3.0.3) e Opera (versão
9.6). As incompatibilidades encontradas estão relacionadas à interface (alinhamento e
posicionamento de campos e informações em tela) e a comunicação destes browsers com o
Struts 2 a partir da não interpretação e/ou interpretação incorreta das action.
Por fim, em relação aos trabalhos correlatos destaca-se o software Relativa IT –
Manager por apresentar uma solução ampla em relação às demandas de solicitações de
serviço. O RITM, como é conhecido, corresponde a uma ferramenta bastante complexa e que
engloba diversas funcionalidades como o registro de tele atendimento, por exemplo, as quais
são dispensáveis em relação à demanda do LCI. Neste contexto, desenvolveu-se uma
ferramenta mais singela e específica para a representação dos processos internos do LCI.
59
4 CONCLUSÕES
No mundo globalizado expressões como iniciativa, agilidade, informação e segurança
estão diretamente relacionadas ao sucesso das organizações. Neste sentido, a evolução
tecnológica através da informatização de processos exerce um papel fundamental ao
contribuir para que as mesmas se mantenham atualizadas e competitivas.
Neste contexto, pode-se afirmar que a aplicação desenvolvida atendeu aos seus
objetivos. Embora módulos como o Gerenciamento de atividades e o Gerenciamento de
estoque ainda não tenham sido completamente implantados, a plena utilização do módulo de
Gerenciamento de chamados para o controle das solicitações de serviço junto ao LCI, que
era o principal objetivo desta aplicação, representa uma melhoria significativa em relação à
qualidade dos serviços prestados, permitindo maior organização, agilidade, segurança e
rastreabilidade das informações.
Pessoalmente, o desenvolvimento deste trabalho significou uma importante conquista,
agregando muito valor à minha vida em nível acadêmico e profissional, a partir do
aprendizado de novas tecnologias e a aquisição de novos conhecimentos, os quais serão úteis
em toda a minha carreira. A construção desta aplicação apresentou-se como um grande
desafio e constituiu-se uma experiência inesquecível. Durante o processo desde o
desenvolvimento da proposta até a implantação e testes do sistema algumas dificuldades
foram encontradas, as quais são detalhadas a seguir.
A falta de conhecimentos relacionados ao desenvolvimento de aplicações Web, uma
vez que jamais havia participado efetivamente do processo de desenvolvimento de qualquer
solução neste sentido, possuindo apenas conhecimentos em relação ao desenvolvimento de
aplicações Desktop de maneira estruturada. Desta forma, a própria linguagem Java e
paradigmas como a orientação a objeto e a arquitetura cliente-servidor representaram uma
grande mudança e exigiram muita dedicação e capacidade de adaptação, sendo necessária,
inclusive, a realização de “cursos” externos neste sentido, uma vez que durante a graduação a
grade curricular do curso sofreu alterações, influenciando este aprendizado.
Posteriormente, já durante o processo de desenvolvimento da aplicação encontrou-se
grandes dificuldades em relação à utilização de PL/SQL na base de dados MySQL,
principalmente, devido ao baixo volume de documentação de qualidade disponível para
pesquisa neste sentido, até por ser esta uma técnica ainda incipiente neste ambiente, o que fez
aumentar consideravelmente o grau de dificuldade de implementação destas rotinas.
60
Tecnologicamente, as técnicas utilizadas no desenvolvimento da aplicação foram
fundamentais ao sucesso da mesma. A harmonia entre o framework Struts 2 e a arquitetura
MVC criaram um ambiente de desenvolvimento favorável, sendo simples e de fácil
interpretação e manutenção.
A única limitação da aplicação está relacionada ao fato de a mesma ser compatível
somente ao navegador Internet Explorer.
4.1 EXTENSÕES
Entre as principais possibilidades de extensão deste trabalho sugere-se:
a) tornar a aplicação compatível aos diversos navegadores;
b) realizar testes em relação a camada de modelo da aplicação a fim de verificar a sua
compatibilidade com outros SGBD’s;
c) aperfeiçoar a utilização da aplicação pelos usuários, a partir da análise de
usabilidade, utilizando o método Cognitive Walkthrough, por exemplo;
d) substituir a estrutura de framework por uma estrutura ainda mais recente como o
AJAX, por exemplo;
e) agregar novas funcionalidades aos diversos módulos do sistema como, por
exemplo:
a) criar alertas aos funcionários do LCI quando a quantidade disponível em
estoque de determinados itens, considerados críticos, ficar zerada ou atingir
uma quantidade mínima permitida;
b) criar rotina para o envio de e-mail aos usuários solicitantes quando do
encerramento de um chamado automaticamente;
c) criar funcionalidades que permitam o preenchimento automático do relatório
de atividades a partir do atendimentos dos chamados;
d) criar relatórios, rotinas ou ferramentas de gerenciamento que permitam análises
em relação ao atendimento e tempo de resposta dos chamados a fim de
aprimorar o processo.
61
REFERÊNCIAS BIBLIOGRÁFICAS
APACHE SOFTWARE FOUNDATION. Struts 2. [S.l.], [2008]. Disponível em: < http:// struts.apache.org/2.x/>. Acesso em: 13 jan. 2009.
CAVANESS, Chuck. Programming Jakarta Struts. 1. ed. Pequim: O’Reylli, 2003.
CRIARWEB.COM. O que é JavaScript. [S.l.], [2008]. Disponível em: < http://www.criarweb.com/artigos/184.php>. Acesso em: 17 nov. 2008.
LETS FUN JAVA. Struts 2 : Features And Short Sumary. [S.l.], [2008]. Disponível em: < http://j2eefolks.blogspot.com/2007/04/struts-2-features-and-short-summary.html>. Acesso em: 17 nov. 2008.
MACORATTI. Padrões de Projeto : O modelo MVC – Model View Controller. [S.l.], [2007]. Disponível em: < http://www.macoratti.net/vbn_mvc.htm>. Acesso em: 17 nov. 2008.
MEISEN, Mariane Ferramenta de apoio a gerência de requisitos baseada no modelo CMMI. 2005. 88f. Trabalho de Conclusão de Curso (Bacharelado em Ciências da Computação) - Centro de Ciências Exatas e Naturais. Fundação Universidade Regional de Blumenau, Blumenau.
NETO, Ari Dias. Struts2: primeiros passos. Java Magazine, Rio de Janeiro, n. 41, p. 6-15, 2007.
PRICEWATERHOUSEECOOPERS. PWC. [S.l.], [2006]. Disponível em: < http://www.pwc.com/extweb/home.nsf/docid/F6511713621C22EB85256D13004907C1>. Acesso em: 12 jan. 2009.
RELATIVA SOLUÇÕES. Relativa IT – Manager. Florianópolis, [2008]. Disponível em: < http://www.relativasol.com.br/open.php?pk=55&fk=57&id_ses=4&canal=1 >. Acesso em: 06 abr. 2008.
RIBEIRO, Diego Colusso. SGTCC-Sistema de gestão de trabalho de conclusão de curso. 2007. 18 f. Proposta de Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação) - Centro de Ciências Exatas e Naturais. Fundação Universidade Regional de Blumenau, Blumenau.
ROEDER, Jackson Roberto. Sistema web para controle e gerenciamento de manutenções. 2006. 47f. Trabalho de Conclusão de Curso (Bacharelado em Sistemas de Informação) - Centro de Ciências Exatas e Naturais. Fundação Universidade Regional de Blumenau, Blumenau.
62
SILVA, Mauricio Samy. CSS – Uma visão geral. Rio de Janeiro, [2005]. Disponível em: < http://www.maujor.com/palestras/visaocss/visaocss.html>. Acesso em: 17 nov. 2008.
TS&O CONSULTORIA SOLUÇÕES EM TI. TS&O IT Solution. São Paulo, [2008]. Disponível em: < http://www.tso-cons.com>. Acesso em: 06 set. 2008.
UNIVERSIDADE REGIONAL DE BLUMENAU. Laboratório de Computação e Informática. Blumenau, [2008a]. Disponível em: < http://www.inf.furb.br/lci/index.php>. Acesso em: 31 mar. 2008.
UNIVERSIDADE REGIONAL DE BLUMENAU. Registros Acadêmicos da Graduação. Blumenau, [2008b]. Disponível em: <http://www.furb.br/rgra/>. Acesso em: 31 mar. 2008.
UNIVERSIDADE REGIONAL DE BLUMENAU. Serviços On-Line. Blumenau, [2008c]. Disponível em: < http://www.furb.br/academico/servicosAcademicos>. Acesso em: 31 mar. 2008.
XAVIER, Carlos Magno da Silva. Gerenciamento de Projetos Como definir e controlar o escopo do projeto. 1. ed. São Paulo : Saraiva, 2005.
63
ANEXO A – Formulário de Solicitação de Serviço ao LCI
A Figura 27 apresenta o formulário de Solicitação de Serviço ao LCI utilizado
anteriormente ao desenvolvimento desta aplicação.
Figura 27 - Formulário de Solicitação de Serviço ao LCI