APLICAÇÃO WEB PARA GERENCIAMENTO DOS PROCESSOS E...

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



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



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:


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.


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:


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:


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.


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:


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.


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:


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:


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;





background-image : url(icones/refresh.gif);


.botaoExcluir {

width : 90px;

height : 26px;





background-image : url(icones/del.gif);


.botaoConfirmar {

width : 100px;

height : 26px;





background-image : url(icones/confirm.gif);


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, ÌE_PERFIL` char(1) NOT NULL, ÌE_RECEPTOR` char(1) NOT NULL, `NM_USUARIO` char(80) NOT NULL, `DS_EMAIL` char(40) NOT NULL, `DS_EMAIL_ALTERNATIVO` char(40) default NULL, ÌE_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

APLICAÇÃO WEB PARA GERENCIAMENTO DOS PROCESSOS E...

Documents

Transcript of APLICAÇÃO WEB PARA GERENCIAMENTO DOS PROCESSOS E...