universidade federal de santa catarina - Projetos

UNIVERSIDADE FEDERAL DE SANTA CATARINA
CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
UMA APLICAÇÃO WEB PARA GERENCIAMENTO DE
DOCUMENTOS ATENDENDO A NBR ISO 9000:2000
GERALDO VOLPATO CALEGARI JUNIOR
FLORIANÓPOLIS, MAIO DE 2004.
UNIVERSIDADE FEDERAL DE SANTA CATARINA
CENTRO TECNOLÓGICO
DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA
CURSO DE CIÊNCIAS DA COMPUTAÇÃO
UMA APLICAÇÃO WEB PARA GERENCIAMENTO DE
DOCUMENTOS ATENDENDO A NBR ISO 9000:2000
GERALDO VOLPATO CALEGARI JUNIOR
Projeto apresentado à disciplina de Projetos
em Ciência da Computação II, orientado pelo
professor Renato Cislaghi.
FLORIANÓPOLIS, MAIO DE 2004.
II
SUMÁRIO
LISTA DE FIGURAS ............................................................................................ VII
LISTA DE SIGLAS E ABREVIATURAS .............................................................. VIII
1. INTRODUÇÃO ................................................................................................... 9
1.1. Apresentação ............................................................................................... 9
1.2. Objetivos ...................................................................................................... 9
1.2.1. Geral ..................................................................................................... 9
1.2.2. Específicos .......................................................................................... 10
1.3. Justificativa ................................................................................................ 10
1.4. Estrutura do Trabalho ................................................................................ 11
2. FUNDAMENTAÇÃO TEÓRICA ........................................................................ 13
2.1. Qualidade e Normalização ......................................................................... 13
2.1.1. O conceito de “Qualidade” .................................................................. 13
2.1.2. Histórico da Qualidade ........................................................................ 14
2.1.3. ISO ...................................................................................................... 15
2.1.4. ISO Série 9000 .................................................................................... 16
2.1.5. Requisitos da norma NBR ISO 9001:2000 .......................................... 17
2.1.5.1. Sistema de gestão da qualidade................................................... 17
2.1.5.2. Responsabilidade da direção ....................................................... 17
2.1.5.3. Gestão de recursos ...................................................................... 18
2.1.5.4. Realização do produto .................................................................. 18
2.1.5.5. Medição, análise e melhoria ......................................................... 18
2.1.6. Requisitos de documentação .............................................................. 19
2.1.7. Gerenciamento de documentos da qualidade baseado na ISO 9000 [1]
...................................................................................................................... 21
2.2. Arquitetura Cliente/Servidor ....................................................................... 23
III
2.2.1. Arquitetura Cliente/Servidor de duas camadas ................................... 23
2.2.2. Arquitetura Cliente/Servidor de três camadas ..................................... 24
2.3. Tecnologia Java ......................................................................................... 25
2.3.1. Linguagem Java .................................................................................. 25
2.3.2. Plataforma J2EE ................................................................................. 26
2.3.2.1. Arquitetura .................................................................................... 26
2.3.2.2. Infra-Estrutura ............................................................................... 27
2.3.2.3. Tecnologias .................................................................................. 28
2.3.2.3.1. Servlets .................................................................................. 29
2.3.2.3.2. JavaServer Pages (JSP) ........................................................ 30
2.3.2.3.3. Enterprise JavaBeans (EJB) .................................................. 30
2.4. Reuso de Software e Projeto ..................................................................... 31
2.4.1. Design Patterns ................................................................................... 31
2.4.1.1. Model-View-Controller .................................................................. 31
2.4.1.2. Facade .......................................................................................... 32
2.4.1.3. Factory Method ............................................................................. 33
2.4.1.4. Singleton ....................................................................................... 34
2.4.2. Frameworks ........................................................................................ 35
2.4.2.1. Velocity ......................................................................................... 35
2.4.2.2. Hibernate ...................................................................................... 36
2.5. Processo de Software ................................................................................ 38
2.5.1. ICONIX ................................................................................................ 38
2.5.1.1. Análise de requisitos ..................................................................... 39
2.5.1.2. Análise e projeto preliminar .......................................................... 40
2.5.1.3. Projeto .......................................................................................... 40
2.5.1.4. Implementação ............................................................................. 40
3. APLICAÇÃO PROPOSTA ................................................................................ 41
3.1. Análise ....................................................................................................... 42
3.1.2. Requisitos Funcionais ......................................................................... 42
3.1.3. Requisitos não funcionais ................................................................... 43
3.1.4. Atores .................................................................................................. 43
3.1.4.1. Gestor ........................................................................................... 43
3.1.4.2. Colaborador .................................................................................. 44
IV
3.1.5. Casos de uso ...................................................................................... 44
3.1.5.1. Efetuar Login (colaborador / gestor) ............................................. 44
3.1.5.2. Listar documentos (colaborador/gestor) ....................................... 44
3.1.5.3. Abrir documento (colaborador/gestor) .......................................... 45
3.1.5.4. Elaborar Documento (gestor)........................................................ 45
3.1.5.5. Enviar Documento para Consenso (gestor) .................................. 45
3.1.5.6. Registrar Adequação do Documento (colaborador)...................... 46
3.1.5.7. Registrar Aprovação do Documento (colaborador)....................... 47
3.1.5.8. Revisar Documento (gestor) ......................................................... 47
3.1.5.9. Cancelar Documento (gestor) ....................................................... 47
3.1.5.10. Enviar lembrete de pendência (gestor) ....................................... 48
3.1.6. Diagrama de Casos de uso ................................................................. 48
3.1.7. Modelo de Domínio ............................................................................. 49
3.1.7.1. Classe Documento ....................................................................... 49
3.1.7.2. Classe Consenso.......................................................................... 49
3.1.7.3. Classe Aprovacao......................................................................... 50
3.1.7.4. Classe Area .................................................................................. 50
3.1.7.6. Classe Colaborador ...................................................................... 50
3.1.7.7. Classe WorkflowManager ............................................................. 50
3.2. Projeto ....................................................................................................... 51
3.2.1. Diagramas de interação ...................................................................... 51
3.2.1.1. Diagrama de seqüência – Efetuar Login ....................................... 51
3.2.1.2. Diagrama de seqüência – Listar Documentos .............................. 51
3.2.1.3. Diagrama de seqüência – Abrir Documento ................................. 52
3.2.1.4. Diagrama de seqüência – Elaborar Documento ........................... 52
3.1.2.5. Diagrama de seqüência – Enviar Documento para Consenso ..... 52
3.1.2.6. Diagrama de seqüência – Registrar Adequação do Documento .. 52
3.1.2.7. Diagrama de seqüência – Registrar Aprovação do Documento ... 53
3.1.2.8. Diagrama de seqüência – Revisar Documento ............................ 53
3.2.2. Diagrama de classes de projeto .......................................................... 53
3.2.3. Diagramas de Estados ........................................................................ 58
3.2.4. Diagrama E-R do banco de dados ...................................................... 59
3.3. Implementação .......................................................................................... 60
V
3.3.1. Ambiente de Desenvolvimento ............................................................ 60
3.3.1.1. Ferramenta IDE ............................................................................ 60
3.3.1.2. Servidor de Aplicações ................................................................. 60
3.3.1.3. Banco de Dados ........................................................................... 61
3.3.2. Arquitetura da Aplicação ..................................................................... 61
3.3.2.1. Implementação do padrão MVC ................................................... 61
3.3.3. Classes Implementadas ...................................................................... 62
3.3.3.1. Classes da Camada de Controle .................................................. 62
3.3.3.1.1. Classe Controller .................................................................. 62
3.3.3.1.2. Classe Action ........................................................................ 63
3.3.3.1.3. Classe DocumentoAction .................................................... 63
3.3.3.1.4. Classe ViewAction ................................................................ 63
3.3.3.1.5. Classe LoginAction .............................................................. 63
3.3.3.1.6. Classe ConsensoAction ....................................................... 63
3.3.3.1.7. Classe AprovacaoAction...................................................... 64
3.3.3.1.8. Classe ActionFactory ........................................................... 64
3.3.3.2. Classe da Camada de Negócios .................................................. 64
3.3.3.2.1. Classe GerenciadorDocumentos ........................................ 64
3.3.3.2.2. Classe FacadeGerenciador .................................................. 64
3.3.3.2.3. Classe WorkflowManager .................................................... 65
3.3.3.2.4. Classe SegurancaHandler.................................................... 65
3.3.3.2.5. Classes de Objetos do Negócio ............................................. 65
3.3.3.2.6. Classes da Sub-Camada de Persistência .............................. 65
3.3.3.2.7. Classes Utilitárias ................................................................... 66
3.3.4. Layout do Sistema............................................................................... 67
3.3.5. Considerações .................................................................................... 69
3.4. Testes ........................................................................................................ 70
3.4.1. O Ambiente de Teste .......................................................................... 70
3.4.2. Funcionamento em Ambiente Distribuído ........................................... 70
3.4.3. Testes de Uso do Sistema .................................................................. 71
4. CONSIDERAÇÕES FINAIS ............................................................................. 73
4.1. Conclusão .................................................................................................. 73
4.2. Dificuldades Encontradas .......................................................................... 74
VI
4.3. Trabalhos Futuros ...................................................................................... 74
ANEXOS .............................................................................................................. 79
Anexo 1: Diagrama de Seqüência – Efetuar Login............................................... 80
Anexo 2: Diagrama de Seqüência – Listar Documentos ...................................... 81
Anexo 3: Diagrama de Seqüência – Abrir Documento ......................................... 82
Anexo 4: Diagrama de Seqüência – Elaborar Documento ................................... 83
Anexo 5: Diagrama de Seqüência – Enviar Documento para Consenso ............. 84
Anexo 6: Diagrama de Seqüência – Registrar Adequação do Documento .......... 85
Anexo 7: Diagrama de Seqüência – Registrar Aprovação do Documento ........... 86
Anexo 8: Diagrama de Seqüência – Revisar Documento .................................... 87
Anexo 9: Código Fonte ......................................................................................... 88
VII
LISTA DE FIGURAS
Figura 2.1: Arquitetura J2EE ................................................................................ 27
Figura 2.2: Servidores e Contêineres J2EE ......................................................... 28
Figura 2.3: Tecnologias J2EE .............................................................................. 29
Figura 2.4: Design Pattern - Model-View-Controller ............................................. 32
Figura 2.5: Design Pattern - Facade .................................................................... 33
Figura 2.6: Design Pattern - Factory Method........................................................ 34
Figura 2.7: Design Pattern - Singleton ................................................................. 34
Figura 2.8: ICONIX - Visão Geral da Estrutura de Desenvolvimento ................... 39
Figura 3.1: Diagrama de Casos de Uso ............................................................... 48
Figura 3.2: Diagrama de Classes Conceituais ..................................................... 49
Figura 3.3: Diagrama de Classes - Pacote Default (raiz) ..................................... 54
Figura 3.4: Diagrama de Classes - Pacote Controller .......................................... 55
Figura 3.5: Diagrama de Classes - Pacote Model ................................................ 56
Figura 3.6: Diagrama de Classes - Pacote Persistencia ...................................... 57
Figura 3.7: Diagrama de Estados – Objeto Documento ....................................... 58
Figura 3.8: Diagrama de Entidade-Relacionamento do Banco de Dados ............ 59
Figura 3.9: Layout do Sistema – Tela de Login .................................................... 67
Figura 3.10: Layout do Sistema – Pendências do Colaborador ........................... 67
Figura 3.11: Layout do Sistema – Documento Em Elaboração ............................ 68
Figura 3.12: Layout do Sistema – Registro de Aprovação ................................... 68
VIII
LISTA DE SIGLAS E ABREVIATURAS
API - Applications Programming Interface
CQT - Controle da Qualidade Total
DAO – Database Access Object
DBMS – Database Management System
EIS – Enterprise Information System
EJB - Enterprise JavaBeans
HTML - HyperText Markup Language
IDE - Integrated Development Environment
ISO – International Organization for Standardization
J2EE – Java 2 Enterprise Edition
J2SE - Java 2 Standard Edition
JDBC - Java DataBase Connectivity
JMS - Java Message Service
JSP – JavaServer Pages
JTA - Java Transaction
MVC –Model-View-Controller
RTF - Rich Text Format
SQL – Structured Query Language
TQC - Total Quality Control
TQM - Total Quality Management
UML - Unified Modeling Language
VTL - Velocity Template Language
9
Capítulo I
1. INTRODUÇÃO
1.1. Apresentação
As normas da família ISO 90001 são utilizadas como guias para a implementação
e documentação de sistemas de gestão da qualidade. Tais normas não traçam
regras, apenas fornecem diretrizes que servem de orientação para as
organizações durante o processo de implantação de um sistema da qualidade.
Em sistemas de gestão da qualidade baseados na ISO 9000, o controle de
documentos é um dos alicerces do sistema da qualidade, pois, “com ele, o
cumprimento dos requisitos estabelecidos é evidenciado, a informação atualizada
sobre como desenvolver cada atividade é de conhecimento dos colaboradores da
empresa e, além disso, os processos de trabalho da empresa contam com um
ambiente propício para sua melhoria contínua” [1]
As atividades de gerenciamento de documentos do sistema da qualidade são
dinâmicas representando um trabalho bastante dispendioso quando feito de modo
não automatizado. Diante desse fato, o presente trabalho pretende ser uma
solução informatizada para este problema.
1.2. Objetivos
1.2.1. Geral
Implementar uma aplicação Web para gerenciamento de documentos que seja
compatível com os requisitos do processo de controle de documentos das normas
da série NBR ISO 9000.
1
Conjunto de normas que fornecem diretrizes para a gestão de sistemas da qualidade.
10
1.2.2. Específicos
Implementar um software que possa auxiliar empresas/instituições a solucionarem
problemas típicos de um Sistema de Gestão da Qualidade decorrentes do
controle de documentos.
Tal software deverá:

Controlar a identificação de códigos na geração de documentos;

Automatizar o fluxo de consenso dos documentos (sistema de workflow);

Automatizar o fluxo de revisão, aprovação e cancelamento de documentos
(sistema de workflow);

Disponibilização pela Web dos documentos aos colaboradores da
empresa/instituição;
Este trabalho também tem por objetivo:

A aplicação prática dos conhecimentos obtidos nas disciplinas de análise e
projetos e engenharia de software;

Estudo e utilização da tecnologia Java para Web.
1.3. Justificativa
As normas ISO 9000 foram desenvolvidas para servirem de guias para Gestão da
Qualidade de forma eficaz. São aplicáveis a qualquer organização seja ela de
qualquer tamanho, pública ou privada e sem considerar o produto/serviço
oferecido.
O controle de documentos é um dos alicerces do sistema da qualidade, pois, com
ele, o cumprimento dos requisitos estabelecidos é evidenciado, a informação
atualizada sobre como desenvolver cada atividade é de conhecimento dos
colaboradores da empresa e, além disso, os processos de trabalho da empresa
contam com um ambiente propício para sua melhoria contínua.
11
As atividades relativas ao controle de documentos são dinâmicas e acompanham
o desenvolvimento do sistema da qualidade. É de fundamental importância a
implantação de um sistema informatizado para gerenciar essas atividades.
Benefícios com um sistema informatizado para controle de documentos do
sistema da qualidade:

Maior integração entre a área de gestão da qualidade e as demais áreas
da instituição;

Melhor difusão do conhecimento na instituição;

Melhor comunicação entre as partes: gestores e usuários;

Nova interface leve e intuitiva para o usuário das informações;

Mais segurança no acesso às informações do sistema de gestão da
qualidade;

Mais tranqüilidade nas revisões e aprovações de documentos;

Mais rapidez na divulgação de novas versões de documentos do sistema
de gestão da qualidade;

Mais facilidades de localização de documentos;

Menores traumas decorrentes de não-conformidades2 em documentação;

Forte redução de despesas com cópias impressas;

Acesso ao sistema em qualquer lugar do mundo.
1.4. Estrutura do Trabalho
O presente trabalho está estruturado da seguinte forma:
No capítulo 2 é apresentada toda a fundamentação teórica que serviu de alicerce
no desenvolvimento deste trabalho. O capítulo ??? é possui uma seção que
apresenta uma visão geral sobre os conceitos referentes à normalização e
qualidade. As demais seções apresentam questões sobre tecnologia e
engenharia de software. Os assuntos deste capítulo não são abordados a fundo
não entrando muito em detalhes.
2
Não cumprimento de algum requisito da norma.
12
O capítulo 3 apresenta o processo realizado no desenvolvimento da aplicação
proposta. As seções deste capítulo descrevem as etapas de Análise, Projeto,
Implementação e Testes.
No capítulo 4 são apresentadas as dificuldades encontradas, sugestões de
trabalhos futuros e a conclusão final.
13
Capítulo II
2. FUNDAMENTAÇÃO TEÓRICA
2.1. Qualidade e Normalização
2.1.1. O conceito de “Qualidade”
A palavra Qualidade está cada vez mais presente no nosso dia a dia. Nos
comerciais na TV, nos outdoors, estampado nos produtos, desde um selinho
numa caixinha de leite até um enorme selo de qualidade no ônibus que
utilizamos.
No entanto, ao se utilizar a palavra “Qualidade”, muitas vezes, não se consegue
transmitir o seu verdadeiro significado. Ao perguntar qual a verdadeira definição
da palavra Qualidade podemos encontrar as mais diversas respostas, como por
exemplo: um conceito subjetivo (“Não sei ao certo o que é qualidade, mas eu a
reconheço quando a vejo”). Ou, um conceito baseado no produto (“O produto
possui algo, que lhe acrescenta valor, que os produtos similares não possuem”).
Entretanto, o conceito de qualidade baseado no cliente (“É a adequação ao uso”;
“É a conformidade às exigências do cliente”) é o mais interessante, pois refere-se
à satisfação de quem vai utilizar o produto.
Este tipo de enfoque, baseado no cliente, fez com que as empresas olhassem
para o mundo exterior e criassem produtos que as pessoas querem e não
produtos que os engenheiros de projeto (ou outros responsáveis pelo
desenvolvimento de um produto) achavam que as pessoas queriam. [2]
14
Segundo a definição da ISO3 (International Organization for Standardization), um
produto de qualidade é aquele que satisfaz às necessidades do cliente em todos
os aspectos tais como especificações, método ou data da entrega, preço, etc.
Para [2], um produto ou serviço de qualidade é aquele que atende perfeitamente,
de forma confiável, de forma acessível, de forma segura e no tempo certo às
necessidades dos clientes.
2.1.2. Histórico da Qualidade
No modelo de produção artesanal, o artesão era o responsável pelo controle de
qualidade. Com a Revolução Industrial4, surgiu o processo de divisão das tarefas
de produção e o controle da qualidade era feito pelo mestre industrial, que
supervisionava cada um dos grupos da linha de produção. Mas com a produção
em alta escala, tornou-se inviável a supervisão de todo o processo por um único
mestre.
Surgiu então uma evolução do controle da qualidade: o controle estatístico
baseado na inspeção por amostragem e gráficos de controle (timidamente
começava a despontar o conceito de prevenção de falhas). Um novo enfoque, em
termos de controle da qualidade, é adotado para aumentar a eficiência dessas
ações de prevenção/correção a falhas, o Controle da Qualidade Total - CQT (em
inglês, Total Quality Control – TQC), também conhecido por Total Quality
Management - (TQM).
No CQT, foram introduzidos aprimoramentos como: preocupação com a
satisfação do cliente, conceito de melhoria contínua, envolvimento dos
funcionários e valorização do respeito ao indivíduo.
Organização internacional que tem a missão de promover o desenvolvimento de normas, testes
e certificação para estabelecer uma padronização mundial. http://www.iso.org
4 Revolução ocorrida na Inglaterra do século XVIII que significou a substituição da ferramenta pela
máquina, e contribuiu para consolidar o capitalismo como modo de produção dominante.
3
15
O CQT é mais do que uma simples utilização de metodologias, técnicas, sistemas
ou ferramentas. O CQT é uma filosofia organizacional, expressa através de ações
da gerência, de cima para baixo, que focalizam o processo de organização como
um todo e que buscam a vantagem competitiva a longo prazo, tendo como armas
estratégicas: a qualidade, o respeito, a participação e a confiança de todos os
funcionários. [2]
Nos dias atuais, com a disputa pela preferência do mercado, a preocupação com
a qualidade dos produtos oferecidos torna-se um fator competitivo. Neste
contexto, a adoção de um sistema de gestão da qualidade é a forma que as
empresas utilizam para fornecerem evidências objetivas aos consumidores de
que esta se preocupa com a qualidade dos produtos oferecidos.
Com as atuais tendências de globalização torna-se necessário adotar-se um
mesmo vocabulário padronizado e reconhecido internacionalmente no que diz
respeito aos sistemas da qualidade. Isso garantirá o reconhecimento da qualidade
dos produtos a nível mundial. Para isso foram criadas normas internacionais,
emitidas pela ISO, sobre sistemas de gestão da qualidade.
2.1.3. ISO
ISO – International Organization for Standardization (Organização Internacional
para Normalização) é uma organização não governamental fundada em 1947,
com sede em Genebra, Suíça. A sigla ISO é uma referência à palavra grega
“isos”, que significa igual.
Sua missão de promover o desenvolvimento de
normas, testes e certificação para estabelecer uma padronização mundial com o
principal objetivo de facilitar o comércio internacional de bens e serviços. Esta
organização é formada por representantes de 91 países, cada um representado
por um organismo de normas, testes e certificação. O Inmetro5 é o representante
brasileiro.
5
Instituto Nacional de Metrologia, Normalização e Qualidade Industrial. http://www.inmetro.gov.br
16
2.1.4. ISO Série 9000
As normas da ISO Série 9000 podem ser utilizadas por qualquer tipo de empresa,
seja ela grande, pequena, de caráter industrial, prestadora de serviços ou até
mesmo uma entidade governamental.
A ISO 9000 tem como único objetivo orientar a implantação de sistemas de
gestão da qualidade nas empresas. Ela não é destinada a um produto nem para
uma indústria específica. Deste modo, as normas ISO 9000 não conferem
qualidade extra a um produto, apenas garantem que tal seja produzido por um
processo certificado e apresentará sempre as mesmas características e o mesmo
padrão de qualidade.
A primeira versão da ISO Série 9000 foi lançada em 1987 e era formada por um
conjunto de cinco normas (ISO 9000 a ISO 9004), passando por duas revisões,
uma em 1994 e outra em 2000. Na versão 2000 a norma ISO 9001 cancela e
substitui as normas ISO 9002 e ISO 9003. A ISO 9000 e a ISO 9004 são guias e a
ISO 9001 é a norma certificadora.

ISO 9000: Sistemas de Gestão da Qualidade – Conceitos e terminologia:
Descreve os fundamentos de sistemas de gestão da qualidade

ISO 9001: Sistemas de Gestão da Qualidade – Requisitos: Especifica
requisitos para um sistema de gestão da qualidade, onde uma organização
precisa demonstrar sua capacidade para fornecer produtos que atendam
os requisitos do cliente e os requisitos regulamentares aplicáveis, e
objetiva aumentar a satisfação do cliente.

ISO 9004: Sistemas de Gestão da Qualidade – Guia para melhoria de
desempenho: Fornece diretrizes que consideram tanto a eficácia como a
eficiência do sistema de gestão da qualidade. O objetivo desta norma é
melhorar o desempenho da organização e a satisfação dos clientes e das
outras partes interessadas.

ISO 19011: Diretrizes para auditorias de Sistemas de Gestão: Fornece
diretrizes sobre auditoria de sistemas de gestão da qualidade e ambiental.
17
A série ISO 9000 foi adotada no Brasil pela ABNT 6 com o nome de NBR ISO
9000.
2.1.5. Requisitos da norma NBR ISO 9001:2000
2.1.5.1. Sistema de gestão da qualidade
A organização deve estabelecer, documentar, implementar e manter um sistema
de gestão da qualidade e melhorar continuamente a sua eficácia.. Esses
processos devem ser monitorados, analisados e, se necessário, aperfeiçoados
através de ações de melhoria contínua.
Os requisitos relacionados ao controle de documentos da qualidade fazem parte
dessa seção da norma ISO 9001:2000 e serão abordados de modo mais sucinto
na seção 2.1.6 do presente trabalho.
2.1.5.2. Responsabilidade da direção
A organização deve fornecer evidências objetivas do comprometimento da Alta
Direção com o desenvolvimento, implementação, melhoria contínua e eficácia do
sistema de gestão da qualidade. A Alta Direção deve garantir que os requisitos
dos clientes sejam determinados e atendidos com o objetivo de aumentar a
satisfação dos mesmos. Também é de responsabilidade da Alta Direção
assegurar que a Política da Qualidade esteja apropriada ao propósito da
empresa, seja comunicada e entendida por todos e analisada criticamente para
manutenção de sua adequação.
Dentre outras responsabilidades da direção deve assegurar que:

Os objetivos da qualidade estejam de acordo com a política da qualidade;

O planejamento do sistema de gestão da qualidade satisfaça os objetivos
da qualidade;
6
Assosiação Brasileira de Normas Técnicas. http://www.abnt.org.br/
18

As responsabilidades e autoridades estejam definidas e comunicadas na
empresa;

Os processos de comunicação interna estejam estabelecidos com objetivo
de difundir as informações relativas à eficácia do sistema de gestão da
qualidade de maneira apropriada.
2.1.5.3. Gestão de recursos
A organização deve fornecer recursos para implementar e manter o sistema de
gestão da qualidade e melhorar sua eficácia visando aumentar a satisfação de
seus clientes. Deve também fornecer a infra-estrutura necessária para alcançar a
conformidade com os requisitos do produto.
2.1.5.4. Realização do produto
A organização deve planejar e desenvolver os processos necessários para a
realização do produto. A etapa de levantamento dos requisitos do produto deve
ser analisada, documentada e comunicada de forma adequada ao cliente. Após o
levantamento
dos
requisitos
segue-se
a
etapa
de
planejamento
e
desenvolvimento, a qual deve ter mecanismos para verificação do correto
atendimento dos requisitos bem como uma validação final do mesmo.
2.1.5.5. Medição, análise e melhoria
A organização deve planejar e implementar processos de monitoramento,
medição, análise e melhoria contínua. A realização de pesquisas de satisfação
dos clientes é um mecanismo que ajuda na identificação de oportunidades de
melhoria.
Os dados apropriados devem ser coletados e analisados para
demonstrar a eficácia do sistema de gestão da qualidade.
19
2.1.6. Requisitos de documentação
“4.2.3 Controle de documentos
Os documentos requeridos pelo sistema de gestão da qualidade devem ser
controlados. Registros são um tipo especial de documento e devem ser
controlados de acordo com os requisitos apresentados em 4.2.4.
Um procedimento documentado deve ser estabelecido para definir os controles
necessários para:
a) aprovar documentos quanto à sua adequação, antes da sua emissão,
b) analisar criticamente e atualizar, quando necessário, e reaprovar documentos,
c) assegurar que alterações e a situação da revisão atual dos documentos sejam
identificadas,
d) assegurar que as versões pertinentes de documentos aplicáveis estejam
disponíveis nos locais de uso,
e) assegurar que os documentos permaneçam legíveis e prontamente
identificáveis,
f) assegurar que documentos de origem externa sejam identificados e que sua
distribuição seja controlada, e
g) evitar o uso não intencional de documentos obsoletos e aplicar identificação
adequada nos casos em que forem retidos por qualquer propósito.” [3]
A documentação dos processos de trabalho possui um grande valor dentro de um
sistema de gestão da qualidade, sendo considerada um elemento chave. Seu
objetivo é contribuir para que a organização possa:

Atingir a conformidade com os requisitos do cliente e a melhoria da
qualidade;

Prover treinamento apropriado aos seus colaboradores;

Fornecer evidências objetivas do cumprimento dos requisitos da norma;

Realizar a avaliação da eficácia e a melhoria contínua do sistema de
gestão da qualidade.
A geração da documentação é uma atividade que agrega valor.
20
“Os seguintes tipos de documentos são usados em sistemas de gestão da
qualidade:
a) documentos que fornecem informações consistentes, tanto internamente
como externamente, sobre o sistema de gestão da qualidade da
organização; tais documentos são referidos como manuais da qualidade;
b) documentos que descrevem como o sistema de gestão da qualidade é
aplicado em um projeto, contrato ou produto específico; tais documentos
são referidos como planos da qualidade;
c) documentos que estabelecem requisitos; tais documentos são referidos
como especificações;
d) documentos
que
estabelecem
recomendações
ou
sugestões;
tais
documentos são referidos como diretrizes;
e) documentos que fornecem informações sobre como realizar atividades e
processos
de
forma
consistente;
tais
documentos
podem
incluir
procedimentos documentados, instruções de trabalho e desenhos;
f) documentos que fornecem evidência objetiva de atividades realizadas ou
de resultados alcançados; tais documentos são referidos como registros.
Cada organização determina a extensão da documentação necessária e os meios
a serem utilizados. Isto depende de diversos fatores, tais como: o tipo e tamanho
da organização, a complexidade e interação dos processos, a complexidade dos
produtos, os requisitos do cliente, os requisitos regulamentares aplicáveis, a
demonstração da capacidade do pessoal e o grau necessário para demonstrar o
atendimento de requisitos do sistema de gestão da qualidade.” [4]
Segundo [1], numa releitura das normas ISO 9000, o requisito controle de
documentos traz as seguintes diretrizes básicas:

A organização deve estabelecer e manter procedimentos documentados
para controle, alteração e aprovação dos documentos integrantes do
sistema da qualidade;

Devem existir processos de trabalho documentados para:
o elaboração/emissão,
21
o aprovação,
o alteração/revisão/cancelamento,
o distribuição/recolhimento,
o controle de todos os documentos do sistema da qualidade em
operação;

Os documentos devem definir claramente os métodos e responsabilidades
na execução dessas tarefas;

Os documentos devem estar disponíveis nos locais de trabalho, e quando
obsoletos, devem ser prontamente removidos e substituídos.
2.1.7. Gerenciamento de documentos da qualidade baseado na ISO
9000 [1]
Toda documentação deve ser legível, datada (incluindo as datas de revisão),
clara, prontamente identificável, além de incluir a devida autorização.
Devem ser estabelecidos métodos para o controle da emissão, distribuição e
revisão dos documentos.
Os métodos devem assegurar que os documentos sejam:

Aprovados pelo pessoal autorizado;

Liberados e colocados à disposição nas áreas em que as informações são
necessárias;

Compreensíveis e aceitáveis pelos usuários;

Analisados criticamente, caso seja necessária alguma revisão;

Retirados de circulação ao se tornarem obsoletos.
Com a interpretação da norma, o gerenciamento de documentos do sistema da
qualidade consiste em controlar os processos de trabalho que envolve o
cumprimento dos requisitos controle de documentos e de dados e controle de
registros da qualidade.
22
As atividades relativas ao gerenciamento de documentos são, basicamente, as
seguintes:

Controle de emissão de documentos;

Controle de revisão de documentos;

Guarda centralizada dos originais;

Elaboração e manutenção do arquivo histórico dos documentos do sistema
da qualidade (retenção de documentos obsoletos e não aplicáveis);

Distribuição e troca de cópias controladas;

Cancelamento e recolhimento de documentos desatualizados;

Elaboração e gerenciamento da tabela de temporalidade documental;

Capacitação do pessoal envolvido (treinamento);
Essas atividades são dinâmicas e acompanham o desenvolvimento do sistema da
qualidade. É imprescindível implantar um sistema (de preferência informatizado),
para gerenciar essas atividades. Neste sistema, podem ser controlados os
seguintes elementos:

Assunto do documento;

Classificação/codificação;

Tipo;

Elaborador e responsável pela aprovação;

Data do original;

Data do documento vigente;

Histórico das revisões;

Documentos relacionados;

Perfil de cópias controladas;

Registros da qualidade relacionados;

Nome dos funcionários treinados, etc.
Esse gerenciamento deve acompanhar o desenvolvimento do documento, desde
sua emissão até sua saída do sistema da qualidade (cancelamento). Estruturar
um sistema dinâmico e organizado é requisito mandatário para o desenvolvimento
de um sistema da qualidade baseado na ISO 9000.
23
2.2. Arquitetura Cliente/Servidor
O termo cliente/servidor foi usado pela primeira vez nos anos 80 em referência
aos computadores pessoais (PCs) em uma rede. O modelo cliente/servidor atual
começou a ganhar aceitação no final dos anos 80. A arquitetura cliente/servidor é
versátil, baseada em mensagens e possui uma infra-estrutura modular,
características para melhorar a usabilidade, flexibilidade, interoperabilidade e
escalabilidade, se compararmos com a computação centralizada dos mainframes
de compartilhamento de tempo. [5]
Na arquitetura cliente/servidor introduziu-se o conceito de serviço onde o lado
cliente executa o papel de solicitante e o lado servidor o papel de executor,
podendo uma mesma máquina agir como cliente ou servidor ao mesmo tempo.
A arquitetura também introduziu o servidor de banco de dados que veio cobrir
uma série de limitações da arquitetura de compartilhamento de arquivos utilizada
até então. “Utilizando sistemas de manutenção de banco de dados relacionais
(DBMS – Database Management System), as consultas dos usuários poderiam
ser respondidas diretamente”. [5]
2.2.1. Arquitetura Cliente/Servidor de duas camadas
Na arquitetura Cliente/Servidor de duas camadas a carga de trabalho fica do lado
cliente deixando o lado servidor com a responsabilidade de prover os serviços de
banco de dados.
Para [6], a desvantagem desse tipo de arquitetura é que ela começa a apresentar
problemas quando o número de clientes aumenta. Podem ocorrer problemas
como, por exemplo, a sobrecarga da rede ocasionando queda da performance.
Um outro problema é o custo, pois cada cliente precisa ter uma máquina potente
o suficiente para rodar a aplicação.
24
Enfim, a arquitetura Cliente/Servidor com 2 camadas é uma boa solução para a
computação distribuída quando os grupos de trabalho são na ordem de dezenas
ou centenas de pessoas interagindo na rede simultaneamente. [5]
2.2.2. Arquitetura Cliente/Servidor de três camadas
A arquitetura Cliente/Servidor de três camadas, também conhecida como
arquitetura Cliente/Servidor multicamadas, surgiu para suprir as limitações que da
arquitetura em duas camadas. Na arquitetura em três camadas, uma camada
intermediária foi adicionada entre a camada cliente e o servidor. Existe uma
variedade de formas diferentes de se implementar esta camada intermediária,
como servidores de mensagens, servidores de aplicação e monitores de
processamento de transições. [5]
A performance e a flexibilidade aumentaram em relação à arquitetura de duas
camadas para grandes grupos de usuários.
A desvantagem da arquitetura de três camadas é que o desenvolvimento de
aplicações nesse modelo é demanda um maior esforço.
25
2.3. Tecnologia Java
2.3.1. Linguagem Java
Java™ foi criada, em 1994, na Sun MicroSystems por uma pequena equipe
liderada por James Gosling. A principio foi projetada para ser utilizada na
programação de aparelhos como celulares, relógios e palms, mas devido à
explosão da Internet a partir de 1995, identificou-se no Java uma linguagem ideal
para aplicações na Internet. Desde então não parou mais de crescer.
Segundo [7], Java deixou de ser apenas uma linguagem de programação
passando a ser também uma plataforma.
Java é uma linguagem de programação de alto nível e possui as seguintes
características:

Simples

Orientada a Objetos

Distribuída

Interpretada

Robusta

Segura

Arquitetura neutra

Portável

Alta performance

Multithreading

Dinâmica
No modo de compilação e execução, o Java difere de linguagens de programação
tradicionais, como o C++. Em um ambiente de programação tradicional, você
escreve e compila o código fonte de um programa dentro do código do objeto
para um hardware e sistema operacional específicos.[7]
26
Os programas em Java são constituídos de um conjunto de classes. E estas
classes são constituídas por um conjunto de métodos que realizam tarefas e
retornam as informações ao completarem suas tarefas. [8]
As bibliotecas de classes, também conhecidas como Java APIs (Applications
Programming Interfaces – interfaces de programas aplicativos), são artefatos de
grande utilidade na criação de aplicações Java pois são um incentivo à
reutilização de código.
Para os que desejam aprofundar os conhecimentos no assunto, o site oficial do
Java - http://java.sun.com - é o lugar indicado.
A lista completa das APIs da especificação Java pode ser encontrada em
http://java.sun.com/products.
2.3.2. Plataforma J2EE
A plataforma J2EE (Java 2 Enterprise Edition) não é uma nova linguagem, e sim
uma nova abordagem que visa simplificar o modelo de desenvolvimento de
aplicações mais complexas. De fato, a plataforma J2EE é executada sobre a
plataforma J2SE (Java 2 Standard Edition); além disto, todos os componentes
desenvolvidos para a plataforma J2EE são desenvolvidos em Java. [9]
2.3.2.1. Arquitetura
Segundo [9], a plataforma J2EE define um padrão para desenvolvimento de
aplicações corporativas multicamadas. A aplicação lógica é dividida em
componentes de acordo com a função, e estes vários componentes podem ser
instalados em diferentes máquinas dependendo da camada em que se
encontram:

Componentes da camada cliente rodam na máquina cliente.

Componentes da camada Web rodam no servidor J2EE.
27

Componentes da camada de Negócio rodam no servidor J2EE.

A camada de Sistemas de Informações Corporativas (EIS) – roda no
servidor EIS.
Essa arquitetura baseada em componentes do J2EE, ilustrada na Figura 2.1,
facilita o desenvolvimento modular do sistema, ou seja, as partes do projeto
podem ser desenvolvidas separadamente facilitando a divisão do trabalho.
Figura 2.1: Arquitetura J2EE
2.3.2.2. Infra-Estrutura
A arquitetura J2EE exige uma infra-estrutura de suporte para armazenar o código
da aplicação, os chamados “Contêineres”. Estes contêineres são aplicações
provedoras de serviços, que irão implementar as APIs definidas para o tipo de
serviços oferecidos. [9]
Deste modo, temos diferentes contêineres apropriados para cada tipo de serviço
demandado na J2EE:
28

Contêiner EJB (Enterprise JavaBeans): gerencia a execução de
componentes EJB, proveêm um ambiente de execução para suportar as
aplicações distribuídas, controle transacional, persistência, etc. Roda sobre
o servidor J2EE.

Contêiner Web: gerencia a execução de páginas JSP e componentes
Servlets de aplicações J2EE. E ainda podem atender requisições de Web
Services. Roda sobre o servidor J2EE.

Contêiner de Aplicações Cliente: gerencia a execução de componentes
de aplicações cliente. As aplicações cliente e o contêiner rodam na
máquina Cliente.

Contêiner Applet: gerencia a execução de applets. Consiste de um
browser Web e um Plugin Java rodando juntos na máquina cliente.
Na Figura 2.2 podemos visualizar a infra-estrutura J2EE e o relacionamento com
os componentes.
Figura 2.2: Servidores e Contêineres J2EE
2.3.2.3. Tecnologias
29
A plataforma J2EE se utiliza de tecnologias padronizadas Java, tanto para o
desenvolvimento de aplicações quanto para prover suporte ao acesso às
funcionalidades.
A Figura 2.3 ilustra as tecnologias utilizadas na plataforma J2EE. As tecnologias
primárias são usadas diretamente pelo desenvolvedor para gerar a aplicação
desejada: Servlets, JavaServer Pages (JSP) e Enterprise JavaBeans (EJB). Já as
tecnologias de suporte são usadas para prover acesso a uma determinada
funcionalidade desejada seja recursos, transação, comunicação, outros sistemas
ou autenticação: Java DataBase Connectivity (JDBC), Java Transaction (JTA),
Java Message Service (JMS), etc.
.
Figura 2.3: Tecnologias J2EE
2.3.2.3.1. Servlets
De acordo com [9], Servlets são componentes que interagem com outros
componentes clientes seguindo um modelo requisição/resposta, ou seja, a
30
aplicação cliente irá invocar um método específico de um Servlet e este irá
disparar a execução de uma série de atividades.
Pode-se usar Servlets tanto para a implementação da apresentação da aplicação
quanto para a lógica de negócios.
A tecnologia Servlet é a base do desenvolvimento de aplicativo web usando a
linguagem de programação Java.[6]
2.3.2.3.2. JavaServer Pages (JSP)
São páginas em texto formatado, contendo porções que serão convertidas e
entendidas como código Java. Estas porções são compiladas em uma aplicação
Java, no momento que se necessita do seu uso. O uso mais comum é em
páginas dinâmicas, onde se criam páginas mesclando a linguagem HTML com
porções de código Java para acesso a componentes e dados de aplicações Java.
Seu uso é recomendado para a apresentação da aplicação. [9]
Na verdade, JSP é uma extensão da tecnologia Servlet, e é prática comum usar
ambas. Servlets e páginas JSP nos mesmos aplicativos web. [6]
2.3.2.3.3. Enterprise JavaBeans (EJB)
Segundo [9], EJBs são componentes flexíveis voltados para aplicações de
negócios distribuídas ou de maior complexidade. Podem representar uma
entidade de negócio, uma lógica de negócio ou uma comunicação assíncrona.
Em resumo, um Enterprise JavaBean é um componente do lado servidor
exatamente como qualquer outro componente, no entanto precisam estar de
acordo com as especificações EJB e só são distribuídos e podem executar
apenas em um contêiner EJB. [6]
31
2.4. Reuso de Software e Projeto
No contexto da Engenharia de Software, diferentes abordagens buscam melhorar
a quantidade de artefatos de software, bem como diminuir o tempo e o esforço
necessários para produzi-los. [11]
2.4.1. Design Patterns
Design Patterns ou Padrões de Projeto são soluções elegantes e reutilizáveis
para problemas recorrentes que encontramos diariamente no processo de
desenvolvimento de aplicativos para o mundo real. Eles tratam da concepção e da
interação entre objetos, definindo ao mesmo tempo um padrão de comunicação
que é compartilhado por toda a equipe de desenvolvimento. [12]
Para [13], um Pattern descreve uma solução comprovada para um problema de
desenho recorrente, dando ênfase particular no contexto e forçando a
aproximação do problema, e as conseqüências e o impacto de sua solução.
A utilização de Design Patterns, por si só, não garante o sucesso do
desenvolvimento. A documentação do pattern fornece informações que indicam
quando ele pode ser aplicado, mas apenas a experiência do projetista pode
proporcionar o entendimento de quando um padrão particular irá melhorar o
desenho do sistema.
2.4.1.1. Model-View-Controller
O design pattern MVC determina a separação das camadas de visualiação
(View), controle de interação com o usuário (Controller) e o modelo de objetos
(Model) facilitando o desenvolvimento modular e a manutenção do sistema.
32
Esse pattern é bastante utilizado por empresas que desenvolvem aplicações de
grande porte onde o trabalho em equipe é indispensável. O MVC facilita bastante
a divisão do trabalho.
No MVC o fluxo da aplicação é intermediado por um controlador central
(Controller) que tem a função de repassar as requisições (tarefas) aos
responsáveis que estão localizados no modelo (Model). Após a execução da
tarefa pelos objetos do modelo, a requisição é respondida através do controlador
e apresentada na visão (View), como ilustra a Figura 2.4.
Request http
1
2
Lógica de negócios
4
3
Servlet
Contêiner
(Tomcat)
Modelo
Controlador
6
Apresentação
5
Response http
Figura 2.4: Design Pattern - Model-View-Controller
2.4.1.2. Facade
O Facade pertence à categoria dos patterns estruturais. Fornece uma interface
única de acesso a um subsistema tornanando-o mais fácil de utilzar.
Como podemos visualizar na Figura 2.5, as classes/objetos que integram o
pattern Facade são:

Classe Facade: Delega as chamadas para a classe do subsistema que é
responsável pela a execução.
33

Classes do Subsistema: Estas classes implementam a funcionalidade do
subsistema e trabalham agregadas ao objeto Facade.
Figura 2.5: Design Pattern - Facade
2.4.1.3. Factory Method
De acordo com [13], o padrão Factory Method é caracterizado por retornar uma
instância dentre muitas possíveis classes, dependendo dos dados providos a ele.
Geralmente, todas as classes que ele retorna têm uma classe pai e métodos em
comum, mas cada um executa tarefas diferentes e é otimizado para diferentes
tipos de dados.
Ele resolve o problema, por exemplo, da criação de objetos de diferentes tipos de
acordo com um determinado parâmetro. A classe responsável pela criação do
objeto não precisa conhecer a lógica de criação desse objeto de acordo com o
parâmetro de entrada. A classe utiliza os serviços da “Fábrica de Objetos” para
criar o objeto seguindo uma determinada lógica.
A figura 2.6 ilustra de maneira simples o funcionamento desse pattern da
categoria dos patterns criacionais7.
7
Padrões (patterns) que lidam com a melhor forma de se criar instâncias dos objetos.
34
Figura 2.6: Design Pattern - Factory Method
2.4.1.4. Singleton
O pattern Sigleton garante que apenas uma instância de uma determinada classe
irá existir. Por exemplo, um sistema pode ter apenas um gerenciador de janelas,
ou gerenciador de impressão, ou então um único ponto de acesso ao banco de
dados.
A maneira mais fácil de se fazer uma classe que possua uma única instância dela
mesma é utilizar uma variável estática na classe, onde será guardada a referência
para a instância corrente.
A Figura 2.7 mostra o diagrama UML de uma classe Singleton.
Figura 2.7: Design Pattern - Singleton
35
2.4.2. Frameworks
Frameworks são estruturas de classes que constituem implementações
incompletas que, estendidas, permitem produzir diferentes artefatos de software.
A grande vantagem desta abordagem é a promoção de reuso de código e projeto,
que pode diminuir o tempo e o esforço exigidos na produção de software. [11]
2.4.2.1. Velocity
O Velocity é um framework de templates8 Java (“Template-Engine”). É mais
freqüentemente aplicado no desenvolvimento de aplicações Web Java, pois
permite a completa abolição do código Java no meio do HTML, tornando-se uma
alternativa bastante eficiente para implementação da camada de apresentação
(View), ou seja, a camada visual da aplicação em projetos que implementam o
padrão MVC (Model-View-Controller).
O seu uso não restringe-se apenas ao
mundo Java Web, pode ser usado em qualquer aplicação que tenha função de
processamento de textos, como por exemplo formatação de mensagens com
base em um template, criação de documentos RTF(Rich Text Format), SQL, etc.
Outra utilização bastante freqüente desse framework é na geração de arquivos
xml.
O Velocity utiliza uma linguagem própria para a construção dos templates, a
Velocity Template Language – VTL. Essa linguagem é bastante pequena
possuindo uma sintaxe bastante simples de ser compreendida. Tornando a
facilidade do uso um ponto bastante forte dessa tecnologia.
Essa ferramenta é um subprojeto do projeto Jakarta, da Fundação Apache 9. É
Open Source permitindo o uso em qualquer tipo de aplicação sem custo algum.
Também disponibiliza o código fonte e estimula os usuários a participarem do
projeto.
Estrutura pré-definida ou modelo.
A Fundação Apache dá suporte à comunidade desenvolvedora de software livre.
http://www.apache.org
8
9
36
A documentação completa desse framework pode ser encontrada no site oficial
do projeto: http://jakarta.apache.org/velocity/index.html.
2.4.2.2. Hibernate
Hibernate é um framework que fornece um mecanismo de persistência de objetos
em banco de dados relacionais de maneira simples e transparente para
aplicações Java em plataforma web ou desktop. A utilização dessa ferramenta
aumenta a produtividade e diminui o esforço, pois elimina o trabalho de ficar
escrevendo sentenças SQL, misturando-as no meio do código Java e
programando mapeamentos de consultas para objetos.
O processo de desenvolvimento com o Hibernate é muito mais simples do que
usando JDBC puro. A utilização do Hibernate engloba 5 atividades:

Criação das tabelas no banco de dados onde os objetos vão persistir;

Criação dos objetos cujo estado vai ser persistido;

Criação do arquivo XML utilizado para realizar o mapeamento dos campos
da tabela às propriedades do objeto;

Criação do arquivo XML que conterá as propriedades para que o Hibernate
se conecte ao banco de dados;

Criação das classes DAOs que irão persistir os objetos.
O Hibernate utiliza um dialeto SQL próprio que pode ser traduzindo para os
códigos SQL relativos aos diversos bancos de dados existentes. Deste modo,
para mudar a aplicação de um banco de dados para outro basta mudar um
parâmetro de configuração que diz qual é o tipo utilizado.
Outros atrativos para a utilização do Hibernate são a grande documentação
disponível e o grande número de projetos utilizando esse framework, fato este
que evidencia sua aceitação pela comunidade de desenvolvedores.
37
Não bastasse tudo o que foi citado, o Hibernate tem mais um ponto positivo, é um
software livre e seu uso é permitido em projetos comerciais e Open Source.
No
site
do
projeto,
http://www.hibernate.org/,
encontra-se
uma
extensa
documentação, exemplos, ferramentas, projetos relacionados, entre outros
materiais.
38
2.5. Processo de Software
Os processos usados para desenvolver um projeto de software têm a maior
importância na qualidade do software produzido e na produtividade alcançada
pelo projeto. No entanto, não existe um modelo uniforme que possa descrever
com precisão o que de fato acontece durante todas as fases da produção de um
software; os processos implementados são muito variados, e as necessidades de
cada organização diferem substancialmente. [15]
Segundo [16], um processo de desenvolvimento de software tem quatro funções:

Fornecer uma diretriz sobre a seqüência de atividades de uma equipe.

Especificar artefatos que devem ser desenvolvidos.

Direcionar as tarefas de desenvolvedores individuais e da equipe como um
todo.

Oferecer critérios para monitorar e comparar produtos e atividades do
projeto.
Em muitos projetos opta-se pela utilização de um processo híbrido que utiliza
artefatos característicos de diferentes metodologias. Assim, podemos criar um
processo personalizado que atende a um determinado grupo de aplicações
utilizando o melhor de cada metodologia existente.
2.5.1. ICONIX
O ICONIX é um processo simplificado que unifica conjuntos de métodos de
orientação a objetos em uma abordagem completa, com o objetivo de dar
cobertura ao ciclo de vida. Foi elaborado por Doug Rosenberg e Kendall Scott a
partir da síntese do processo unificado pelos “três amigos” - Booch, Rumbaugh, e
Jacobson o qual tem dado suporte e conhecimento a metodologia ICONIX desde
1993. Além disso, o ICONIX está adaptado ao padrão da UML, é dirigido por
casos de uso e o seu processo é iterativo incremental. [17]
39
Figura 2.8: ICONIX - Visão Geral da Estrutura de Desenvolvimento
O desenvolvimento de software seguindo o processo ICONIX prevê a execução
de quatro atividades básicas:

Análise de requisitos;

Análise e desenho preliminar;

Desenho;

Implementação.
2.5.1.1. Análise de requisitos

Levantamento dos casos de uso e atores do sistema representando a
interação entre estes através do diagrama de casos de uso da UML.

Construção do modelo de domínio contendo os objetos referentes ao
problema e as relações entre esses objetos. Um diagrama UML de classes
de domínio é utilizado para representação.
40

Dependendo da situação poderá ser realizada uma prototipação rápida da
interface do sistema para facilitar a compreensão do cliente sobre o
sistema proposto.
2.5.1.2. Análise e projeto preliminar

Detalhamento dos casos de uso de modo a representarem o fluxo principal,
os fluxos alternativos e a ocorrência de erros.

Realizar a análise de robustez para cada caso de uso.

Atualizar o diagrama de classes
2.5.1.3. Projeto

Especificar o comportamento dinâmico do sistema identificando as trocas
de mensagens entre os objetos. Os diagramas de seqüência são utilizados
nessa representação.

Atualizar continuamente o diagrama de classes com os atributos e métodos
identificados.

Finalizar o modelo estático.
2.5.1.4. Implementação

Produzir, se necessário, diagramas de apoio à implementação tais como,
diagramas de componentes e de implantação.

Escrever ou gerar o código do sistema.

Realizar testes unitários, de integração e de aceitação do usuário.
41
Capítulo III
3. APLICAÇÃO PROPOSTA
O processo de desenvolvimento utilizado foi baseado na metodologia ICONIX
apresentada na seção 2.5.1. Prevendo as seguintes etapas:

Análise

Projeto

Implementação

Testes
As etapas de Análise de Requisitos e Análise e Projeto Preliminar da metodologia
ICONIX foram agrupadas em uma só etapa denominada Análise e tendo como
sub atividades o levantamento dos requisitos (funcionais e não funcionais),
identificação e detalhamento dos casos uso, identificação dos atores e
representação da interação entre os casos de uso e atores do sistema.
Os testes serão realizados em uma etapa separada. No ICONIX os testes fazem
parte da etapa de implementação.
42
3.1. Análise
Essa etapa foi realizada baseando-se no sistema de gestão da qualidade utilizado
pelo Instituto Euvaldo Lodi - IEL/SC. Esta instituição possui a certificação ISO
9000:2000 e se dispôs a auxiliar no desenvolvimento desse trabalho no que diz
respeito aos assuntos relacionados à qualidade.
3.1.2. Requisitos Funcionais
1. O sistema deverá automatizar o processo de controle da documentação de
sistemas de gestão da qualidade baseados na norma NBR ISO 9000:2000
facilitando o atendimento dos requisitos de documentação da mesma. Essa
automatização será baseada no ciclo de vida dos documentos segundo a norma.
Abaixo uma síntese desse ciclo de vida:

Elaboração

Consenso das áreas envolvidas

Aprovação

Disponibilização

Revisão (se necessário)

Cancelamento (se necessário)
2. O sistema deverá assegurar que documentos, em sua versão mais atual,
estejam disponibilizados e acessíveis via Web para todos os colaboradores da
organização.
3. O sistema deverá armazenar registros históricos de consensos, aprovações e
revisões dos documentos. Os documentos que já estão fora de circulação por
motivo de revisão ou cancelamento também devem ser mantidos no sistema,
acessíveis apenas pelos gestores do sistema.
4. O sistema deverá permitir consultas aos documentos categorizadas por tipo de
documento, área e data de publicação.
43
5. O sistema deverá enviar avisos de pendências de consenso e aprovação de
documentos aos colaboradores para que o processo ocorra com rapidez.
3.1.3. Requisitos não funcionais
1. O sistema deverá ter uma interface amigável e intuitiva favorecendo uma
melhor utilização do mesmo por parte dos colaboradores.
2. O sistema deverá garantir a segurança dos documentos publicados não
permitindo o acesso de usuários não autorizados.
3. O sistema deverá apresentar bom desempenho não exigindo uma largura de
banda considerável, podendo ser acessível de forma rápida numa conexão de
Internet discada.
4. O sistema poderá ser utilizado por organizações de qualquer porte que buscam
a certificação de qualidade da ISO, e também para aquelas que já possuem
certificação e que desejam melhorar o seu processo de controle da
documentação do sistema de gestão da qualidade.
3.1.4. Atores
3.1.4.1. Gestor
Realiza a gestão do sistema. Responsável pela elaboração, alteração,
cancelamento e revisão dos documentos. Também é responsável pelo envio de
avisos de pendências de consenso/aprovação para os responsáveis.
Tarefas:

Elaborar Documento;

Enviar Documento para Consenso;

Cancelar Documento;
44

Revisar Documento;

Enviar Lembrete de Pendências;

Listar Documentos;

Abrir Documento;
3.1.4.2. Colaborador
Responsável pela aprovação de documentos.
Tarefas:

Registrar Consenso do documento;

Registrar Aprovação do documento;

Listar Documentos;

Abrir Documento;
3.1.5. Casos de uso
3.1.5.1. Efetuar Login (colaborador / gestor)
1. O colaborador/gestor entra no sistema informando seu login e senha;
2. O colaborador/gestor submete essas informações;
3. O sistema realiza a validação e verifica a sua permissão (gestor ou
colaborador);
Extensões:
2a. Se o usuário não estiver cadastrado no sistema, o acesso é negado;
3.1.5.2. Listar documentos (colaborador/gestor)
1. Inclui Efetuar Login;
2. O colaborador/gestor seleciona a lista desejada (por Área, por Tipo, por
Data de Publicação ou por Status);
3. O sistema mostra a lista de documentos;
Extensões:
45
1a. Se o gestor já estiver logado no sistema não é necessário efetuar login
novamente;
3.1.5.3. Abrir documento (colaborador/gestor)
1. Inclui Efetuar Login;
2. Inclui Listar documentos;
4. O colaborador/gestor seleciona o documento desejado a partir da lista;
5. O sistema mostra o documento selecionado;
Extensões:
1a. Se o gestor já estiver logado no sistema não é necessário efetuar login
novamente;
3.1.5.4. Elaborar Documento (gestor)
1. Inclui Efetuar Login;
2. O gestor do sistema preenche as informações referentes ao documento
(tipo do documento, área, título e número da revisão).
3. O gestor do sistema submete essas informações;
4. O sistema gera um código automático para o documento com base no tipo
e área do documento e mostra o próximo formulário.
5. Inclui Enviar Documento para Consenso;
Extensões:
1a. Se o gestor já estiver logado no sistema não é necessário efetuar login
novamente;
5a. Se o gestor não possuir todas as informações necessárias para preencher
ele pode optar por realizar a etapa de elaboração posteriormente.
3.1.5.5. Enviar Documento para Consenso (gestor)
1. Inclui Abrir documento;
46
2. O gestor preenche as informações referentes ao documento (objetivo da
elaboração/revisão, prazo para consenso, responsável pela aprovação e
responsáveis pelo consenso) e anexa o documento (Word, Excel, etc)
previamente elaborado;
3. O gestor envia o documento para consenso;
4. O sistema mostra a confirmação de que a operação foi realizada com
sucesso;
5. O sistema envia email de aviso para os responsáveis pelo consenso do
documento;
Extensões:
1a. Se o documento for mostrado diretamente a partir da criação do
documento, não é necessário localizar e abri-lo novamente;
3.1.5.6. Registrar Adequação do Documento (colaborador)
1. Inclui Abrir documento;
2. O colaborador registra seu parecer sobre o documento julgando se este é
adequado ou não e registra as observações desejadas;
3. O colaborador submete as informações;
4. O sistema mostra confirmação de que a operação foi realizada com
sucesso;
5. Se o colaborador for o último a registrar o consenso do documento e, se
todos os responsáveis pelo consenso registrarem o documento como
adequado, o sistema envia o documento para aprovação.
Extensões:
5a. Se um dos responsáveis pelo consenso registrar o documento como não
adequado, o sistema envia email para o responsável pela elaboração do
documento informando que o documento não foi consensado e necessita
alterações. (status: Documento Devolvido pelo Consenso);
47
3.1.5.7. Registrar Aprovação do Documento (colaborador)
1. Inclui Abrir documento;
2. O colaborador registra seu parecer sobre o documento aprovando-o ou não
e registra as observações desejadas;
3. O colaborador submete as informações;
4. O sistema mostra confirmação de que a operação foi realizada com
sucesso;
5. Se o colaborador aprovar o documento, o sistema publica o documento e
envia email para os responsáveis pelo consenso e elaboração que este já
está disponível para uso de todos.
Extensões:
5a. Se o colaborador não aprovar o documento, o sistema envia email para o
responsável pela elaboração do documento informando que o documento não
foi aprovado e necessita alterações.
3.1.5.8. Revisar Documento (gestor)
1. Inclui Abrir documento;
2. O gestor seleciona a opção de criação de uma nova revisão para o
documento;
3. O sistema cria uma cópia do documento, mantendo a revisão anterior
publicada.
4. Inclui Enviar Documento para Consenso
3.1.5.9. Cancelar Documento (gestor)
1. Inclui Abrir documento;
2. O gestor seleciona a opção de cancelamento do documento e informa o
motivo do cancelamento;
3. O sistema envia email para os responsáveis pelo consenso avisando que o
documento foi cancelado e não está mais disponível para uso.
48
3.1.5.10. Enviar lembrete de pendência (gestor)
1. Inclui Abrir documento;
2. O gestor seleciona a opção de enviar lembrete;
3. O sistema envia email para os responsáveis para o consenso/responsável
pela aprovação;
3.1.6. Diagrama de Casos de uso
O diagrama apresentado na Figura 3.1 mostra a interação entre atores e casos de
uso do sistema.
Listar Documentos
<<include>>
<<include>>
Efetuar Login
Abrir Documento
<<include>>
Enviar Documento
para Consenso
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
<<include>>
Enviar Lembrete
de Pendencia
Revisar
Documento
<<include>>
Colaborador
Registrar Aprovação
do Documento
Cancelar
Documento
<<include>>
Registrar Adequação
do Documento
Elaborar Documento
Gestor
Figura 3.1: Diagrama de Casos de Uso
49
3.1.7. Modelo de Domínio
Com base no levantamento dos casos de uso e requisitos do sistema foram
identificados os objetos do mundo real que fazem parte domínio do sistema e as
relações existentes entre esses objetos. O resultado desta tarefa foi o diagrama
de classes conceituais representado na Figura 3.2.
Documento
Consenso
-id:int
-codigo:String
-revisao:int
-tipo:TipoDocumento
-area:Area
-data:Date
-path:String
-filename:String
-status:int
-respCadastro:Colaborador
-prazoConsenso:Date
-consenso:List
-aprovacao:List
-dataAprovacao:Date
-dataPublicacao:Date
relativo ao documento
Colaborador
responsável pelo cadastro
responsável
-id:int
-nome:String
-login:String
-senha:String
-email:String
-id:int
-data:Date
-status:int
-resultado:String
-responsavel:Colaborador
-obs:String
-doc:Documento
responsável
responsável
relativo ao documento
Aprovacao
-id:int
-data:Date
-status:int
-resultado:String
-responsavel:Colaborador
-obs:String
-doc:Documento
WorkflowManager
TipoDocumento
Area
-id:int
-tipo:int
-codigo:int
-numeracao:int
-id:int
-area:String
-codigo:String
-responsavel:Colaborador
-equipe:List
Figura 3.2: Diagrama de Classes Conceituais
3.1.7.1. Classe Documento
Classe que representa a estrutura principal do sistema, o Documento e seus
atributos.
3.1.7.2. Classe Consenso
Cada documento deve passar por um consenso dos colaboradores que o utilizam
(todos os colaboradores de setores selecionados, ou colaboradores selecionados
50
individualmente).
Essa classe representa o consenso do documento com seus
atributos.
3.1.7.3. Classe Aprovacao
Cada documento deve passar por uma aprovação do colaborador responsável
pela área de utilização do documento.
3.1.7.4. Classe Area
Os documentos podem ser agrupados por área dentro da organização (Área
Administrativa, Diretoria, etc.). Essa classe representa essas unidades de
agrupamento.
3.1.7.6. Classe Colaborador
Esta classe representa o usuário do sistema, o colaborador da organização.
3.1.7.7. Classe WorkflowManager
Classe que controla a automatização do clico de vida dos documentos no sistema
(elaboração, consenso, aprovação e publicação) Implementa o workflow do
sistema.
51
3.2. Projeto
3.2.1. Diagramas de interação
Os diagramas de interação mostram a estrutura dinâmica do sistema ilustrando
como os objetos colaboram entre si para o atendimento dos requisitos.
Nos diagramas elaborados as operações referentes à persistência dos dados
estão num nível de abstração maior, já que o uso do framework Hibernate,
descrito na seção 2.4.2.2, deixa essas operações transparentes para o projetista.
As operações ocorridas durante a mudança de estado interno do documento
também foram abstraídas com o objetivo de facilitar a compreensão dos
diagramas.
Outro aspecto interessante para ser observado nos diagramas é a utilização dos
padrões de projeto citados na seção 2.4.1.
3.2.1.1. Diagrama de seqüência – Efetuar Login
Este diagrama representa a operação Efetuar Login que irá garantir o controle de
acesso ao sistema. O usuário informa seu login e senha e o sistema realiza a
validação verificando se este faz parte da lista de colaboradores cadastrados e se
a senha informada está correta. Se a validação for realizada com sucesso
identifica o tipo de acesso (colaborador ou gestor). (Anexo 1)
3.2.1.2. Diagrama de seqüência – Listar Documentos
Este diagrama representa a operação Listar Documentos. O usuário seleciona
uma das listas disponíveis de acordo com o seu acesso (Documentos por status,
por data, por área, etc). O sistema acessa o banco de dados buscando pelos
documentos que satisfazem à condição escolhida. (Anexo 2)
52
3.2.1.3. Diagrama de seqüência – Abrir Documento
Este diagrama representa a operação Abrir Documento.
Após a lista de
documentos ter sido gerada, o usuário seleciona um dos documentos listados
nela. O sistema localiza o documento no banco de dados escolhido e mostra na
tela. (Anexo 3)
3.2.1.4. Diagrama de seqüência – Elaborar Documento
Este diagrama representa a operação Elaborar Documento. O gestor preenche
as informações referentes ao documento a ser criado e envia. O sistema gera o
código do documento com base no tipo e área selecionados, cria os registros de
consenso e aprovação e armazena o documento no banco de dados. A partir
desse ponto o documento passa a existir no sistema. (Anexo 4)
3.1.2.5. Diagrama de seqüência – Enviar Documento para Consenso
Este diagrama representa a operação Enviar Documento para Consenso. Após
terminada a etapa de elaboração do documento o próximo passo é enviá-lo para
consenso. O sistema envia email para os responsáveis pelo consenso do
documento para que estes realizem essa operação. (Anexo 5)
3.1.2.6. Diagrama de seqüência – Registrar Adequação do Documento
Este diagrama representa a operação Registrar Adequação do Documento. Ao
receber o email informando que existe um documento aguardando seu consenso,
o usuário entra no sistema e abre o documento referido e registra seu parecer
sobre julgando-o adequado ou não adequado. O sistema armazena esse parecer
e verifica se todos os responsáveis já registraram o consenso. Se sim, verifica se
todos adequaram o documento. Se o documento foi adequado o sistema envia o
documento para aprovação. Senão, o documento é devolvido para o responsável
pela elaboração para que este possa efetuar as alterações necessárias. (Anexo 6)
53
3.1.2.7. Diagrama de seqüência – Registrar Aprovação do Documento
Este diagrama representa a operação Registrar Aprovação do Documento. Ao
receber o email informando que existe um documento aguardando sua
aprovação, o usuário entra no sistema e abre o documento referido e registra seu
parecer aprovando ou não o documento. O sistema armazena esse parecer e se
for aprovado, publica o documento no sistema. Caso não seja aprovado, o
documento é devolvido para o responsável pela elaboração para que este possa
efetuar as alterações necessárias. (Anexo 7)
3.1.2.8. Diagrama de seqüência – Revisar Documento
Este diagrama representa a operação Revisar Documento. Ao executar essa
operação o sistema gera uma cópia documento revisado para que possam ser
feitas as alterações necessárias e seja enviado para consenso. (Anexo 8)
3.2.2. Diagrama de classes de projeto
A estrutura estática do sistema é representada através de diagramas de classes.
Estas classes foram obtidas através do refinamento do modelo de domínio com
auxílio dos diagramas de seqüência que ajudaram a identificar novos atributos e
métodos.
O sistema foi dividido em pacotes de classes. No pacote default (raiz da
aplicação) temos a classe Controller e os pacotes model e controller como
podemos ver na Figura 3.3.
54
VelocityServlet
Controller
-log:Log
#loadConfiguration:Properties
+handleRequest:Template
-processRequest:String
model
mensagem
persistencia
seguranca
workflow
+Aprovacao
+Colaborador
+Consenso
+Documento
+Area
+GeradorCodigo
+FacadeGerenciador
+GerenciadorDocumentos
+Constantes
+Propriedades
+FormatadorDatas
+TipoDocumento
controller
+Action
+ActionFactory
+ConsensoAction
+DocumentAction
+LoginAction
+ViewAction
+EntradaAction
+AprovacaoAction
Figura 3.3: Diagrama de Classes - Pacote Default (raiz)
A Figura 3.4 mostra o projeto das classes do pacote controller. Essas classes,
juntamente com a classe Controller, compõem a camada controladora do sistema.
55
ActionFactory
-instance:ActionFactory
-ActionFactory
+getInstance:ActionFactory
+newAction:Action
+newAction:Action
Action
#request:HttpServletRequest
#multi:MultipartRequest
+Action
+Action
+execute:String
DocumentAction
ConsensoAction
-log:Log
-log:Log
+DocumentAction
+DocumentAction
+execute:String
EntradaAction
AprovacaoAction
LoginAction
+EntradaAction
+execute:String
ViewAction
-log:Log
-log:Log
+LoginAction
+execute:String
+ViewAction
+execute:String
+ConsensoAction
+execute:String
-log:Log
+AprovacaoAction
+execute:String
Figura 3.4: Diagrama de Classes - Pacote Controller
O projeto das classes de negócio é mostrado na figura 3.5. devido a
complexidade e para facilitar a compreensão essa camada foi dividida em
pacotes.
O diagrama desse pacote não mostra os relacionamentos fracos (dependência e
associação) existentes entre as classes para facilitar a compreensão.
56
Documento
TipoDocumento
0..*
1
interface
Constantes
FacadeGerenciador
-colaborador:Colaborador
+Documento
aprovacaoAtiva:Aprovacao
consensoAtivo:List
statusTexto:String
motivoCancelamento:String
dataCancelamento:Date
dataObsoleto:Date
aprovacao:List
area:Area
codigo:String
consenso:List
dataCriacao:Date
dataPublicacao:Date
docsRelacionados:List
filename:String
id:Long
objetivo:String
path:String
prazoConsenso:Date
respCadastro:Colaborador
revisao:Integer
status:Integer
tipo:TipoDocumento
titulo:String
1..*
id:Long
codigo:String
denominacao:String
numeracao:Long
ativo:String
Aprovacao
+Aprovacao
1
id:Long
resultado:String
justificativa:String
data:Date
status:String
responsavel:Colaborador
documento:Documento
dataEnvio:Date
ativo:String
1..*
1..*
1..*
1..*
1
Consenso
1
Colaborador
+Consenso
+Colaborador
id:Long
resultado:String
justificativa:String
status:String
prazo:Date
documento:Documento
responsavel:Colaborador
data:Date
dataEnvio:Date
ativo:String
id:Long
login:String
nome:String
email:String
senha:String
acesso:String
ativo:String
trabalhaPara:Set
0..*
1
id:Long
codigo:String
denominacao:String
responsavel:Colaborador
equipe:Set
ativo:String
+AREA:int
+COLABORADOR:int
+TIPODOCUMENTO:int
+DOCUMENTO:int
+APROVACAO:int
+CONSENSO:int
GeradorCodigo
-log:Log
+GeradorCodigo
+geraCodigo:String
1
Area
-instance:FacadeGerenciador
-log:Log
-gerenciador:GerenciadorDocumentos
1
GerenciadorDocumentos
1
-log:Log
-instance:GerenciadorDocumentos
-props:Propriedades
-databaseHandler:DatabaseHandler
-segurancaHandler:SegurancaHandler
-agenteMensageiro:AgenteMensageiro
-workflowManager:WorkflowManager
1
-geradorCodigo:GeradorCodigo
-GerenciadorDocumentos
+getInstance:GerenciadorDocumentos
+getAplicacaoHost:String
+getAplicacaoPath:String
+getDocsHost:String
+getDocsPath:String
+getDocsPathPublicados:String
+getDocsPathFluxo:String
+getDocsPathObsoletos:String
+getDocsPathCancelados:String
+getSmtpHost:String
+getListaTipos:List
+getListaAreas:List
+getListaColaboradores:List
+getListaDocumentosStatus:List
+getListaPendenciasConsenso:List
+getListaPendenciasAprovacao:List
+getRegistroConsenso:Consenso
+getRegistroAprovacao:Aprovacao
+getColaborador:Colaborador
1
+getDocumento:Documento
+valideUsuario:int
+armazenaConsenso:void
+addListaConsenso:void
+addColaboradorConsenso:void
+delColaboradorConsenso:void
+flowNextState:void
+criaDocumento:Documento
seguranca
persistencia
+ColaboradorDAO
+ConsensoDAO
+DatabaseHandler
+DocumentoDAO
+AprovacaoDAO
+AreaDAO
+DAO
+DAOException
+HibernateSession
+TipoDocumentoDAO
FormatadorDatas
-instance:FormatadorDatas
-FormatadorDatas
+getInstance:FormatadorDatas
+stringToDate:Date
+dateToString:String
Propriedades
-log:Log
-props:Properties
1
+Propriedades
+inicializaPropriedades:void
aplicacaoHost:String
aplicacaoPath:String
docsHost:String
docsPath:String
docsPathPublicados:String
docsPathFluxo:String
docsPathObsoletos:String
docsPathCancelados:String
smtpHost:String
0..*
+SegurancaHandler
1
-FacadeGerenciador
+getInstance:FacadeGerenciador
+getAplicacaoHost:String
+getAplicacaoPath:String
+getDocsHost:String
+getDocsPath:String
+getDocsPathPublicados:String
+getDocsPathFluxo:String
+getDocsPathObsoletos:String
+getDocsPathCancelados:String
+getSmtpHost:String
+getListaTipos:List
+getListaAreas:List
+getListaColaboradores:List
+getListaDocumentosStatus:List
+getListaPendenciasConsenso:List
+getListaPendenciasAprovacao:List
+getRegistroConsenso:Consenso
+getRegistroAprovacao:Aprovacao
+getColaborador:Colaborador
+getDocumento:Documento
+valideUsuario:int
+armazenaConsenso:void
+addListaConsenso:void
+addColaboradorConsenso:void
+delColaboradorConsenso:void
+criaDocumento:Documento
+flowNextState:void
workflow
+WorkflowManager
mensagem
+MensagemFactory
+MimeMessage
+AgenteMensageiro
Figura 3.5: Diagrama de Classes - Pacote Model
57
A Figura 3.6 mostra a estrutura do pacote persistencia que está dentro do pacote
model.
HibernateSession
DAO
+session:ThreadLocal
-cfg:Configuration
-sf:SessionFactory
-log:Log
#armazenaObj:void
#removeObj:void
#recuperaObj:Object
#recuperaObj:Object
#recuperaObjs:List
#rollback:void
#closeSession:void
+currentSession:Session
+closeSession:void
-loadClasses:void
ColaboradorDAO
ConsensoDAO
+armazenaColaborador:Colaborador
+getColaborador:Colaborador
+removeColaborador:void
+removeColaborador:void
+searchColaboradores:List
+armazenaConsenso:Consenso
+getConsenso:Consenso
+removeConsenso:void
+removeConsenso:void
+searchConsenso:List
AreaDAO
DocumentoDAO
TipoDocumentoDAO
AprovacaoDAO
+armazenaArea:Area
+getArea:Area
+removeArea:void
+removeArea:void
+searchAreas:List
+armazenaDocumento:Documento
+getDocumento:Documento
+removeDocumento:void
+removeDocumento:void
+searchDocumentos:List
+armazenaTipo:TipoDocumento
+getTipo:TipoDocumento
+removeTipo:void
+removeTipo:void
+searchTiposDocumento:List
+armazenaAprovacao:Aprovacao
+getAprovacao:Aprovacao
+removeAprovacao:void
+removeAprovacao:void
+searchAprovacao:List
Exception
DAOException
DatabaseHandler
#exception:Exception
-log:Log
+DAOException
+DAOException
+DAOException
+DAOException
+DAOException
+printStackTrace:void
+printStackTrace:void
+toString:String
+DatabaseHandler
+getColaborador:Colaborador
+getDocumento:Documento
+getArea:Area
+getColaborador:Colaborador
+getTipoDocumento:TipoDocumento
+getConsenso:Consenso
+getAprovacao:Aprovacao
+search:List
+armazena:void
fatal:boolean
Figura 3.6: Diagrama de Classes - Pacote Persistencia
58
3.2.3. Diagramas de Estados
Os diagramas de estados possibilitam a visualização do ciclo de vida dos objetos.
A Figura 3.7 mostra o ciclo de vida do objeto Documento no sistema.
<<<<documento>>>>
Em Criação
Novo Documento
Solicitar Código
<<<<documento>>>>
Em Elaboração
Enviar para Consenso
<<<<documento>>>>
Enviado para Consenso
Enviar para Consenso
<<<<documento>>>>
Devolvido pelo Consenso
Devolver para o Responsável pela
Elaboração[Se no mínimo UM dos
Responsávels pelo Consenso
julgar o Documento NÃO
ADEQUADO]
Enviar para Aprovação[Se o
Documento for julgado
ADEQUADO por TODOS os
Responsáveis pelo Consenso]
<<<<documento>>>>
Enviado para Aprovação
Enviar para Consenso
<<<<documento>>>>
Devolvido pelo Aprovador
Devolver para o Resposável pela
Elaboração[Se o Responsável
pelo Aprovação NÃO APROVAR]
Publicar no Sistema[Se o
Responsável pela Aprovação
APROVAR]
Revisar/Cria uma cópia do
documento
<<<<documento>>>>
Publicado
<<<<documento>>>>
Cancelado
Cancelar
Revisar
<<<<documento>>>>
Obsoleto
Figura 3.7: Diagrama de Estados – Objeto Documento
59
3.2.4. Diagrama E-R do banco de dados
O projeto do banco de dados é outro ponto de fundamental importância. Um
projeto mal feito pode ocasionar sérios problemas na implementação do sistema.
A Figura 3.8 apresenta o diagrama Entidade-Relacionamento do banco de dados
do sistema.
tipodoc
eh do tipo
documento
id_tipodoc
area
codigo
denominacao
numeracao
ativo
id_area
id_colaborador(FK)
codigo
denominacao
ativo
relacao
id_area(FK)
id_colaborador(FK)
pertence a area
id_documento
id_tipodoc(FK)
id_area(FK)
id_colaborador(FK)
colaborador
responsavel
titulo
codigo
data_criacao
data_publicacao
data_cancelamento
data_obsoleto
prazo_consenso
revisao
status
filename
path
objetivo
motivo_cancelamento
responsável pelo cadastro
responsavel
id_colaborador
relacao
login
nome
email
senha
acesso
ativo
responsavel
aprovacao do documento
aprovacao
id_aprovacao
id_documento(FK)
id_colaborador(FK)
consenso
consenso do documento
area_colaborador
id_consenso
id_documento(FK)
id_colaborador(FK)
resultado
justificativa
data
data_envio
status
ativo
id_documento
resultado
justificativa
data
data_envio
status
prazo
ativo
Figura 3.8: Diagrama de Entidade-Relacionamento do Banco de Dados
60
3.3. Implementação
3.3.1. Ambiente de Desenvolvimento
O ambiente de desenvolvimento utilizado para a implementação do projeto foi
montado utilizando-se basicamente ferramentas livres Java. Existe um grande
número de ferramentas gratuitas disponíveis para a plataforma Java: servidores
de aplicação, IDEs, bancos de dados, entre outras.
3.3.1.1. Ferramenta IDE
O Eclipse surgiu como projeto interno da IBM, que foi doado para a comunidade
Open Source no ano de 2001, e desde então vem evoluindo muito rapidamente. É
uma ferramenta integrada de desenvolvimento que fornece um ambiente
completo para o desenvolvimento de aplicações com suporte a várias linguagens
(Java, C++, PHP, Cobol, etc). Também possui outros recursos inexistentes em
outras ferramentas.
Um outro ponto positivo do Eclipse é a possibilidade de instalação de plugins com
funcionalidades específicas: Desenvolvimento de aplicações Web Java, Edição de
Templates Velocity, Persistência de dados com Hibernate, Interface com bancos
de dados, editores gráficos de diagramas UML, e muitos outros disponíveis, na
maioria das vezes, gratuitamente.
O
Eclipse
pode
ser
encontrado
em
http://www.eclipse.org.
No
site
http://www.eclipse-plugin.com pode-se encontrar plugins Eclipse para os mais
diversos fins.
3.3.1.2. Servidor de Aplicações
O Tomcat é um container de aplicações web desenvolvido pela Fundação
Apache. É focado na linguagem Java, mais especificamente nas tecnologias de
Servlets e JavaServer Pages(JSP).
61
Optou-se por sua utilização por tratar-se de um software livre e pelo fato de ser
mais simples e adequado ao porte da aplicação.
3.3.1.3. Banco de Dados
Dentre as várias alternativas de bancos de dados livres, optou-se por utilizar o
MySQL por ser ele quase que um padrão no desenvolvimento de aplicações Web.
Mais uma vez referenciando o uso do framework para persistência de dados
Hibernate, destaca-se o fato de que o sistema não estar “amarrado” somente ao
MySQL. Pode-se optar por utilizar qualquer outro banco de dados compatível com
JDBC somente alterando-se os arquivos xml de configuração.
3.3.2. Arquitetura da Aplicação
A arquitetura Cliente-Servidor de três camadas foi escolhida por ser a que melhor
atende aos requisitos da aplicação.
A aplicação foi desenvolvida utilizando a linguagem Java sobre a plataforma
J2EE(Java 2 Enterprise Edition) usando a tecnologia primária Servlets e a
tecnologia de suporte JavaMail;
A aplicação será desenvolvida utilizando o padrão de projeto MVC (Model-ViewController) descrito na seção 2.4.1.1. Foi escolhido por ser, atualmente, o principal
padrão de projetos para aplicações web.
3.3.2.1. Implementação do padrão MVC

A camada que responsável pelo controle da interação com o usuário
(Controller) foi implementada utilizando a tecnologia Servlet.
62

O framework Velocity foi utilizado na implementação da camada de
visualização (View). Segundo [18], uma das vantagens do Velocity, em
relação a outras tecnologias de implementação dessa camada (JSP por
exemplo), é a de facilmente limitar as possibilidades que um designer tem
em escrever o código da página. Enquanto em uma página JSP o designer
tem acesso a todas as classes Java disponíveis na aplicação web, é
possível configurar o Velocity para que cada template tenha acesso a
somente alguns objetos.

A camada que contém os objetos do negócio (Model) é completamente
independente das outras duas camadas e poderia ser utilizada em
qualquer outra aplicação não web.

O framework de Hibernate, descrito na seção 2.4.2.2, foi utilizado para
implementar a sub-camada de persistência dentro da camada de negócio.
Proporcionando mais uma vez, o desenvolvimento modular do sistema.
3.3.3. Classes Implementadas
O código das classes implementadas está na seção de anexos.
3.3.3.1. Classes da Camada de Controle
3.3.3.1.1. Classe Controller
É a classe responsável por receber todas as requisições do cliente. O controlador
processa a requisição identificando o tipo de ação e instanciando um objeto
Action que irá realizar a tarefa desejada. Após o término da tarefa o controlador
renderiza a saída em formato HTML a partir do template Velocity indicado pela
ação.
Essa classe é derivada da classe VelocityServket que faz parte do framework
Velocity.
63
3.3.3.1.2. Classe Action
Classe abstrata que a partir da qual são derivadas todas as classes que executam
as ações do sistema.
3.3.3.1.3. Classe DocumentoAction
Classe derivada de Action responsável pela execução das ações de manipulação
dos documentos.

Abrir documento

Elaborar documento

Proceder troca de estado do documento
Em cada estado do ciclo de vida do documento, executa as possíveis ações e
após a execução retorna o template para visualização.
3.3.3.1.4. Classe ViewAction
Classe derivada de Action que executa as ações referentes a listagem de
documentos. De acordo com o tipo de lista selecionado pelo cliente interagem
com os objetos de negócio e retorna o template com os dados para a
visualização.
3.3.3.1.5. Classe LoginAction
Classe derivada de Action que executa a ação de validação do usuário no
sistema. Se o usuário for validade com sucesso retorna o template de página
principal do sistema.
3.3.3.1.6. Classe ConsensoAction
64
Classe derivada de Action que executa as ações referentes aos registros de
adequação do documento:

Registrar adequação

Abrir registro de adequação

Visualizar histórico da adequação do documento
3.3.3.1.7. Classe AprovacaoAction
Classe derivada de Action que executa as ações referentes aos registros de
aprovação do documento:

Registrar aprovação

Abrir registro de aprovação

Visualizar histórico da aprovação do documento
3.3.3.1.8. Classe ActionFactory
Essa classe implementa o design pattern Factory Method e responsável por
implementar a lógica de criação dos objetos Action. A classe Controller não
precisa conhecer todos os tipos de objetos Action e a lógica de criação, para isso
ela usa a classe ActionFactory para criá-los.
3.3.3.2. Classe da Camada de Negócios
3.3.3.2.1. Classe GerenciadorDocumentos
Esta é a classe principal da camada de negócios. Realização a manipulação dos
objetos de negócio e com a subcamada de persistência.
3.3.3.2.2. Classe FacadeGerenciador
Essa classe é o ponto único de acesso à camada de negócios. Recebe todas as
requisições da camada de controle.
65
3.3.3.2.3. Classe WorkflowManager
Classe que implementa a máquina de estados do documento. Possui um único
método que efetua a troca de estados do documento no sistema. Faz a alteração
do estado interno do documento alterando atributos, alterando objetos
relacionados (Aprovação e Consenso). Interage com o sistema de mensagens
para enviar emails para os responsáveis.
3.3.3.2.4. Classe SegurancaHandler
Realiza as ações referentes à segurança do sistema. Para essa versão, apenas a
função de validação foi implementada.
3.3.3.2.5. Classes de Objetos do Negócio
As seguintes classes já foram descritas na seção 3.1.7:
1. Documento
2. Consenso
3. Aprovacao
4. Colaborador
5. Area
6. TipoDocumento
3.3.3.2.6. Classes da Sub-Camada de Persistência
1. DatabaseHandler: responsável pela interação com os objetos de dados.
Seguindo o pattern Facade essa classe seria a interface única de acesso
aos objetos da sub-camada de persistência.
2. HibernateSession: responsável por obter a sessão do banco de dados.
Realiza a interação com o framework Hibernate.
3. DAO: classe que realiza a interação entre os objetos persistentes e o
framework Hibernate.
66
Para cada classe de objetos de negócio, seção 3.3.3.2.5., existe uma classe
“xxxDAO” derivada de DAO.
3.3.3.2.7. Classes Utilitárias
1. GeradorCódigo: utilizada para gerar o código do documento num formato
padrão de acordo com a Área e o Tipo do Documento.
2. Propriedades: armazena as propriedades dinâmicas do sistema (nome do
servidor, diretórios, etc) que são lidas do arquivo de configuração.
3. MensagemFactory: responsável pela criação das mensagens enviadas
aos responsáveis pelas ações no sistema.
4. AgenteMensageiro: responsável pelo envio das mensagens. Utiliza a
tecnologia JavaMail.
5. FormatadorDatas: realiza a manipulação de datas. Converte de String
para Date e o inverso também.
67
3.3.4. Layout do Sistema
Na Figura 3.9 temos a tela inicial que solicita o login ao usuário.
Figura 3.9: Layout do Sistema – Tela de Login
Após a validação do colaborador, o sistema lista as suas pendências de
consenso/aprovação. Figura 3.10.
Figura 3.10: Layout do Sistema – Pendências do Colaborador
68
A Figura 3.11 ilustra o formulário de dados de um documento em elaboração.
Figura 3.11: Layout do Sistema – Documento Em Elaboração
Figura 3.12, temos um registro de aprovação do documento.
Figura 3.12: Layout do Sistema – Registro de Aprovação
69
3.3.5. Considerações
O sistema não implementa as ações de gerenciamento dos cadastros de
colaboradores, tipos de documentos e áreas, pois não fazia parte do escopo
definido. Para utilização do sistema supõe-se essas tabelas já existentes e
alimentadas.
No desenvolvimento da interface do sistema, tentou-se atender alguns requisitos
de usabilidade tais como: funções de validação dos dados antes de enviá-los,
máscaras de entradas para campos data, mensagens de confirmação,
mensagens de erro compreensíveis, entre outros.
( Anda não consegui um servidor público e gratuito para hospedar a aplicação e
disponibilizá-la para avaliação. Deste modo, coloco-me a disposição para
apresentação
do
sistema.
)
70
3.4. Testes
Os testes realizados durante a implementação não foram documentados. Após o
término da etapa de implementação, o sistema foi instalado e testado em
ambiente distribuído.
3.4.1. O Ambiente de Teste
Os testes foram realizados com a ajuda da equipe da Unidade de Sistemas de
Informação e Qualidade do Instituto Euvaldo de Santa Cataria – IEL/SC que
também participou do processo de levantamento dos requisitos.
3.4.2. Funcionamento em Ambiente Distribuído
Esse teste serviu para testar o comportamento do sistema em ambiente
distribuído.
Foram encontrados os seguintes problemas:

Os arquivos de configuração do sistema (arquivos xml) não estavam sendo
carregados corretamente. O acesso aos arquivos estava sendo realizado
com um path absoluto e ao mudar de sistema operacional esse tipo de
ação pode dar problema. A solução transformar o path da aplicação de
absoluto para relativo.

Manipulação de arquivos na rede: o nome do host do servidor de arquivos
no arquivo de configuração do sistema estava num formato incorreto. A
forma correta de mapear o servidor de arquivos corrigiu esse problema.
71
3.4.3. Testes de Uso do Sistema
O objetivo destes testes é evidenciar que o sistema atende corretamente aos
requisitos e casos de uso levantados na etapa de análise.
Fluxo de publicação de documento (fluxo normal)
1. O documento da área técnica Formulário de Cadastro de Cliente – TCN FM
001 foi elaborado e enviado para consenso com sucesso;
2. Os responsáveis pelo consenso do documento receberam os avisos por
email e efetuaram o registro de adequação com sucesso;
3. O responsável pela aprovação recebeu o aviso por email e efetuou o
registro com sucesso;
4. O documento foi publicado e disponibilizado para acesso de todos os
colaboradores;
Fluxo de publicação de documento (fluxo alternativo)
1. O documento da área técnica Formulário de Cadastro de Fornecedor –
TCN FM 001 foi elaborado e enviado para consenso com sucesso;
2. Os responsáveis pelo consenso do documento receberam os avisos por
email e efetuaram o registro de adequação com sucesso. Um dos
membros julgou o documento como não adequado.
3. O responsável pela elaboração do documento recebeu o aviso por email,
efetuou as alterações necessárias e enviou novamente para consenso. O
histórico de consenso estava disponível para que o elaborador pudesse
visualizar as decisões anteriores;
4. Os responsáveis pelo consenso do documento receberam os avisos por
email e efetuaram o registro de adequação com sucesso. O histórico de
consenso estava disponível para que os envolvidos pudessem visualizar as
decisões anteriores;
5. O responsável pela aprovação recebeu o aviso por email e efetuou o
registro com sucesso;
6. O documento foi publicado e disponibilizado para acesso de todos os
colaboradores;
72
Fluxo de publicação de documento (fluxo alternativo)
1. O documento da área administrativa Padrão de Processo de Aquisição –
ADM PP 001 foi elaborado e enviado para consenso com sucesso;
2. Os responsáveis pelo consenso do documento receberam os avisos por
email e efetuaram o registro de adequação com sucesso.
3. O responsável pela aprovação recebeu o aviso por email e efetuou o
registro não aprovando o documento.
4. O responsável pela elaboração do documento recebeu o aviso por email,
efetuou as alterações necessárias e enviou novamente para consenso. O
histórico de consenso estava disponível para que os envolvidos
visualizassem as decisões anteriores;
5. Os responsáveis pelo consenso do documento receberam os avisos por
email e efetuaram o registro de adequação com sucesso. Os históricos de
consenso e aprovação estavam disponíveis para que os envolvidos
visualizassem as decisões anteriores;
6. O responsável pela aprovação recebeu o aviso por email e efetuou o
registro com sucesso;
7. O documento foi publicado e disponibilizado para acesso de todos os
colaboradores;
Deste modo, vários outros documentos foram inseridos no sistema evidenciando
o atendimento dos requisitos e casos de uso estabelecidos.
Apenas algumas observações referentes à usabilidade do sistema foram
levantadas pelos envolvidos nos testes.
Um ponto positivo identificado foi a manutenção dos registros históricos pelo
sistema.
73
Capítulo 4
4. CONSIDERAÇÕES FINAIS
4.1. Conclusão
A
adoção
dos
processos
de
gestão
da
qualidade
dentro
de
uma
empresa/organização não é uma tarefa simples. No caso da ISO 9000, os
requisitos devem ser todos atendidos e evidenciados. Nesse contexto, a
ferramenta
desenvolvida
poderá
trazer
a
facilidade
de
automatizar
o
gerenciamento da documentação que é um dos requisitos mais importantes da
norma.
Os objetivos referentes ao atendimento das recomendações da ISO para
gerenciamento de documentos foram alcançados com sucesso. O sistema
desenvolvido automatiza o fluxo de elaboração, aprovação e publicação de
documentos e mantém o histórico dos registros de consenso e aprovação. Após a
aprovação, o documento é publicado e disponibilizado para acesso de todos os
colaboradores da empresa/organização.
O objetivo de aplicação prática dos conhecimentos obtidos nas disciplinas de
Análise e Projetos e Engenharia de Software também foi alcançado. O sistema foi
desenvolvido seguindo uma metodologia que serviu de guia no desenvolvimento.
Os design patterns foram de extrema importância nas decisões tomadas na etapa
de projeto do sistema. A reutilização de código com o uso de frameworks foi outro
fator que de fundamental importância no desenvolvimento do trabalho.
Por fim, a utilização da tecnologia Java foi outro objetivo alcançado na medida em
o desenvolvimento deste trabalho possibilitou o aprendizado mais aprofundado da
mesma. ( Muito se aprendeu com este trabalho. Java é realmente fascinante.
)
74
4.2. Dificuldades Encontradas
Apesar de já conhecer a linguagem Java houve um pouco de dificuldade ao
embarcar na plataforma J2EE. Foi um grande desafio encarar um trabalho desses
partindo do “Hello World”. O estudo da tecnologia tomou um bom tempo.
Outra dificuldade foi na modelagem, pois a falta de experiência é a grande inimiga
nessas horas. O projeto foi mudado várias vezes até chegar ao estado atual.
Diante deste contexto, os padrões de projeto foram de fundamental importância
para decidir questões sobre a modelagem e o projeto.
A persistência dos objetos foi um problema de início, mas com a utilização do
framework Hibernate foi superado. Um pouco de tempo foi gasto na leitura dos
manuais desse framework, mas o resultado compensou.
4.3. Trabalhos Futuros
Desenvolvimento do módulo de segurança com funções de assinatura digital para
os documentos garantindo assim a autenticidade dos registros de adequação e
consenso.
Desenvolvimento do módulo de Auditorias Internas para automatização do
processo de Auditorias Internas da Qualidade. Com funções para agendar, criar e
preencher relatórios de auditorias, entre outras.
Desenvolvimento
do
módulo
de
Ações
Corretivas
e
Preventivas
para
automatização do processo de registro de não-conformidades, ações corretivas e
preventivas. Esse sistema facilitaria o fornecimento de evidências objetivas do
comprometimento da organização com o processo de melhoria contínua. Quando
ocorre uma não-conformidade, deve-se gerar ações corretivas determinando
75
atividades de modo a corrigir o problema ocorrido e evitar que ele não ocorra
novamente.
76
Bibliografia
[1] VALLS, Valéria Martin. O gerenciamento dos documentos do Sistema da
Qualidade. Revista Ciência da Informação – Vol 25, N.º 2, 1995. Disponível
em <http://www.ibict.br/cionline/250296/25029601.pdf>
Data de Acesso:
22/12/2003.
[2] ISRAELIAN, Eliane. et al. Uma Introdução às Normas da Série ISO 9000.
Allchemy
Web,
1996.
Disponível
em:
<http://allchemy.iq.usp.br/pub/metabolizando/bd6c001z.doc> Data de Acesso:
22/12/2003.
[3] ABNT - Associação Brasileira de Normas Técnicas. Sistemas de gestão da
qualidade – Requisitos. NBR ISO 9001:2000.
[4] ABNT - Associação Brasileira de Normas Técnicas (ABNT). Sistemas de
gestão da qualidade – Fundamentos e vocabulário. NBR ISO 9000:2000.
[5] SADOSKI, Darleen. Client/Server Architectures – An Overview. Carnegie
Mellon
Software
Engineering
Institue,
1997.
Disponível
<http://www.sei.cmu.edu/str/descriptions/clientserver_body.html>
Data
em:
de
Acesso: 10/05/2004.
[6] KURNIAWAN, Budi. Java para Web com Servlets, JSP e EJB. Rio de
Janeiro: Editora Ciência Moderna Ltda., 2002.
[7] CAMPIONE, Mary; WALRATH, Kathy; HUML, Alison. The Java™ Tutorial.
Disponível
em:
<http://java.sun.com/docs/books/tutorial/>
Data
de
Acesso:12/05/2004.
[8] DEITEL, H.M. Java, como programar / H. M. Deitel e P.J. Deitel; tradução de
Carlos Arthur Lang Lisboa. – 4.ed. – Porto Alegre : Bookman, 2003.
77
[9] YUNG, Leandro. J2EE Visão Geral. Revista JavaMagazine, Número 04, 2004.
[10] ARMSTRONG, Eric. et al. The J2EE™ 1.4 Tutorial. Disponível em:
<http://java.sun.com/j2ee/1.4/docs/tutorial/doc/index.html> Data de Acesso:
15/05/2004.
[11] SILVA, Ricardo Pereira e. Suporte ao desenvolvimento e uso de
frameworks e componentes. Porto Alegre: Universidade Federal do Rio
Grande do Sul, 2000. (Tese, Doutorado em Ciência da Computação).
Disponível em: <http://www.inf.ufsc.br/~ricardo/download/tese.pdf>
Data de
Acesso: 20/05/2004.
[12] OODESIGN, Equipe. Padrões de Projeto de Software. Portal OODesign.
Disponível em: <http://www.oodesign.com.br/patterns/> Data de Acesso:
21/05/2004.
[13] DESTRO, Daniel. Implementando Design Patterns com Java. Grupo de
Usuários
Java,
2004.
Disponível
em:
<http://www.guj.com.br/article.get.print.chain?article.id=137> Data de Acesso:
21/05/2004.
[14] DATA & OBJECT FACTORY. Software Design Patterns. Developer
Training. Disponível em: <http://www.dofactory.com/Patterns/Patterns.aspx>
Data de Acesso 22/05/2004.
[15] SILVA, Alberto M. R.; VIDEIRA, Carlos A. E. UML, Metodologias e
Ferramentas Case. Lisboa: Centro Atlântico, 2001.
[16] CONALLEN, Jim. Desenvolvimento de aplicações Web com UML / Jim
Conallen; tradução de Altair Dias Caldas de Moraes, Cláudio Belleza Dias. Rio de Janeiro: Campus, 2003.
78
[17] BONA, C.; COSTA T. C. Processo de Software: Um Estudo de Caso em
ICONIX. III Congresso Brasileiro de Computação, 2003.
[18] SILVEIRA, Azevedo Guilherme de; VILLELA, Carlos. GUJ2 – Criando uma
comunidade ainda melhor. Revista JavaMagazine, Número 04, 2004.
[19] ALMEIDA, A. DARLT, R. Pesquisa e Desenvolvimento em UML. UNISUL,
2001.
[20] HIBERNATE.ORG. Hibernate Reference Documentation. Disponível em:
<http://www.hibernate.org/hib_docs/reference/en/html/>
[21] PRESSMAN, Roger S. Engenharia de Software. - São Paulo: Makron
Books ,1995.
79
ANEXOS
80
Anexo 1: Diagrama de Seqüência – Efetuar Login
81
Anexo 2: Diagrama de Seqüência – Listar Documentos
82
Anexo 3: Diagrama de Seqüência – Abrir Documento
83
Anexo 4: Diagrama de Seqüência – Elaborar Documento
84
Anexo 5: Diagrama de Seqüência – Enviar Documento para Consenso
85
Anexo 6: Diagrama de Seqüência – Registrar Adequação do Documento
86
Anexo 7: Diagrama de Seqüência – Registrar Aprovação do Documento
87
Anexo 8: Diagrama de Seqüência – Revisar Documento
88
Anexo 9: Código Fonte
Ainda está sendo documentado.
89