UNIVERSIDADE CATÓLICA DE GOIÁS
DEPARTAMENTO DE COMPUTAÇÃO
GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO
SISTEMA DE PADRONIZAÇÃO E GERENCIAMENTO DE
DOCUMENTOS ELETRÔNICOS
DANIEL MARQUES DE REZENDE
ROGERIO RIBEIRO DE SOUZA FILHO
Novembro
2008
2
UNIVERSIDADE CATÓLICA DE GOIÁS
DEPARTAMENTO DE COMPUTAÇÃO
GRADUAÇÃO EM ENGENHARIA DE COMPUTAÇÃO
SISTEMA DE PADRONIZAÇÃO E GERENCIAMENTO DE
DOCUMENTOS ELETRÔNICOS
Trabalho de Trabalho de Conclusão de Curso apresentado por
Daniel Marques de Rezende e Rogério Ribeiro de Souza Filho à
Universidade Católica de Goiás, como requisito parcial para
obtenção do título de Bacharel em Engenharia de Computação,
aprovado em 26/11/2008, pela Banca Examinadora:
Professor Joriver, UCG – Orientador
Novembro
2008
SISTEMA DE PADRONIZAÇÃO E GERENCIAMENTO DE
DOCUMENTOS ELETRÔNICOS
DANIEL MARQUES DE REZENDE
ROGERIO RIBEIRO DE SOUZA FILHO
Trabalho de Conclusão de Curso apresentado por Daniel Marques de Rezende e
Rogério Ribeiro de Souza Filho à Universidade Católica de Goiás, como parte dos requisitos para
obtenção do título de Bacharel em Engenharia de Computação.
_________________________
Professor Joriver Canedo, MSc.
Orientador
_________________________________
Professor Jeová Martins Ribeiro.
Coordenador de Trabalho de Conclusão de Curso
à Deus pela minha vida e oportunidades.
Aos nossos familiarese amigos.
“O senhor ... Mire e veja que o mais importante e bonito do
mundo é isto, que as pessoas não estão sempre iguais, não
foram terminadas, mas que elas vão sempre mudando.
Afinam ou desafinam – verdade maior. É o que a vida me
ensinou. Isto me alegra, montão.”
Guimarães Rosa
RESUMO
Apresenta-se os conceitos básicos da gerência eletrônica de documentos (GED) e
conceituação acerca dos processos, mais conhecidos, utilizados na engenharia de software. Com
base nos conhecimentos adquiridos acerca do processo de desenvolvimento espiral, foram
apresentadas as diversas fases necessárias para o desenvolvimento de um sistema básico de
gerenciamento eletrônico de documentos e um modelo de banco de dados para armazenar tais
documentos. Apresenta-se também uma solução para possibilitar ao usuário a criação de modelos
de documentos, conforme as necessidades da empresa que venha adquirir o sistema. Foi utilizada
a linguagem de programação Visual Basic .NET[5] para a implementação do sistema, por ser
uma linguagem orientada a objetos bastante difundida no meio comercial, e a ferramenta case
Jude Community como apoio à especificação dos diagramas de casos de uso, de seqüência e de
classes.
Palavras-Chave: Gerenciamento Eletrônico de Documentos, Desenvolvimento Espiral,
Desenvolvimento orientado a objeto.
ABSTRACT
It presents the basic concepts of management of electronic documents (GED) and
conceptualization about the processes, better known, used in software engineering. Based on the
knowledge gained about the process of development spiral, was presented the various stages
needed for the development of a basic system for managing electronic documents and a sample
database to store such documents. It also presents a solution to enable the user to create models of
documents, according to the needs of the company which will acquire the system. We used the
programming language Visual Basic. NET [5] for the implementation of the system, because it is
an object oriented language to be widespread in the commercial, and the tool case Jude
Community to support the specification diagrams of use cases of sequence and classes.
Key Words: Management of Electronic Documents, Spiral Development, object oriented
Development.
SISTEMA DE PADRONIZAÇÃO E GERENCIAMENTO DE
DOCUMENTOS ELETRÔNICOS
SUMÁRIO
LISTA DE FIGURAS ......................................................................................................
x
LISTA DE ABREVIATURAS
xii
......................................................................................
1.
INTRODUÇÃO
2.
ESTUDOS BIBLIOGRÁFICOS
2.1.
Processos de software
2.1.1.
2.1.2.
2.1.3.
2.2.
.....................................................................................................
.............................................................................
3
................................................................................
3
Modelos de processos de software
...............................................
3
..................................................
4
2.1.1.1.
O modelo em cascata
2.1.1.2.
Desenvolvimento evolucionário
2.1.1.3.
Engenharia de software baseada em componentes
................................
5
.....
6
....................................................................
7
2.1.2.1.
Entrega incremental .....................................................
8
2.1.2.2.
Desenvolvimento em espiral
9
Interação de processo
Atividades de processo de software
......................................
............................................
11
.........................................
11
...................................
11
2.1.3.1.
Especificação de software
2.1.3.2.
Desenvolvimento de software
2.1.3.3.
Validação de software
...............................................
13
2.1.3.4.
Evolução do software
..................................................
14
...........................................................
15
.................................................................
16
Processo de engenharia de requisitos
2.2.1.
1
Requisitos de software
2.2.1.1.
Requisitos funcionais e não funcionais
.......................
17
2.2.1.1.1.
Requisitos funcionais
.............................
17
2.2.1.1.2.
Requisitos não funcionais .......................
17
2.2.1.2.
Requisitos de usuários
...............................................
18
2.2.1.3.
Requisitos de sistemas
...............................................
19
2.2.1.4.
Especificação de Interface
.........................................
19
Elicitação e analise de requisitos
2.2.3.
Validação de requisitos
..................................................
19
.................................................................
21
2.2.3.1.
Planejamento e gerenciamento de requisitos
..............
22
2.2.3.2.
Gerenciamento de mudança de requisitos
.................
24
...............................................................................................
25
2.3.
Casos de uso
2.4.
Diagrama de classe
2.5.
Diagrama de seqüência
2.6.
2.7.
3.
2.2.2.
......................................................................................
26
................................................................................
26
Banco de dados
.........................................................................................
27
2.6.1.
My Sql
.........................................................................................
27
2.6.2.
Postgre Sql
2.6.3.
Oracle
...................................................................................
27
.........................................................................................
28
Programação orientada a objeto
SISTEMA PROPOSTO
.................................................................
28
.........................................................................................
30
3.1.
Benefícios do produto
................................................................................
30
3.2.
Diagrama de contexto
................................................................................
31
3.3.
Usuários ........................................................................................................
31
3.4.
Interface de hardware
...................................................................................
32
3.5.
Interface de software
...................................................................................
32
3.6.
Restrições
.....................................................................................................
32
3.7.
Requisitos específicos
3.7.1.
Requisitos funcionais
3.7.1.1.
3.7.2.
................................................................................
....................................................................
Diagrama de caso de uso
............................................
3.7.1.1.1.
Diagramas dos casos de uso
.................
3.7.1.1.2.
Descrição dos casos de uso completo
37
37
34
34
..
37
Requisitos não funcionais ..............................................................
41
3.8.
Diagrama de classes
...................................................................................
3.9.
Diagrama de entidades e relacionamentos do banco de dados
3.10.
Diagramas de seqüência
3.11.
Interfaces de usuário
61
....................
62
.............................................................................
63
...................................................................................
83
4.
CONCLUSÃO
........................................................................................................
5.
REFERÊNCIAS BIBLIOGRÁFICAS
....................................................................
103
104
6.
GLOSSÁRIO
...........................................................................................................
106
x
LISTA DE FIGURAS
Figura 2.1 – Ciclo de vida de software em cascata ............................................................. 4
Figura 2.2 – Desenvolvimento evolucionário ..................................................................... 6
Figura 2.3 – Engenharia de software baseada em componentes ......................................... 7
Figura 2.4 – Entrega incremental ........................................................................................ 8
Figura 2.5 – Modelo em espiral do processo de software ................................................... 9
Figura 2.6 – Modelo geral de processo de projeto .............................................................. 12
Figura 2.7 – Processo de teste ............................................................................................. 13
Figura 2.8 – Evolução de sistema........................................................................................ 14
Figura 2.9 – Processo de engenharia de requisitos.............................................................. 15
Figura 2.10 – Modelo em espiral dos processos de engenharia de requisitos ..................... 16
Figura 2.11 – Tipos de requisitos não funcionais ............................................................... 18
Figura 2.12 – Processo de elicitação e análise de requisitos ............................................... 20
Figura 2.13 – Gerenciamento de mudanças de requisitos ................................................... 24
Figura 3.1 – Diagrama de contexto ..................................................................................... 31
Figura 3.2 – Diagrama de caso de uso acesso ao sistema.................................................... 34
Figura 3.3 – Diagrama de caso de uso gerenciamento de usuários ..................................... 34
Figura 3.4 – Diagrama de caso de uso modelagem do documento ..................................... 35
Figura 3.5 – Diagrama de caso de uso gerenciamento do documento ................................ 35
Figura 3.6 – Diagrama de caso de uso consultar documento .............................................. 36
Figura 3.7 – Diagrama de caso de uso arquivo morto ......................................................... 36
Figura 3.8 – Diagrama de classes ........................................................................................ 61
Figura 3.9 – Diagrama de relacionamentos do banco de dados .......................................... 62
Figura 3.10 – DSS01 Diagrama de seqüência acessar sistema ........................................... 63
Figura 3.11 – DSS02 Diagrama de seqüência bloquear sistema ......................................... 64
Figura 3.12 – DSS03 Diagrama de seqüência cadastrar usuário......................................... 65
Figura 3.13 – DSS04 Diagrama de seqüência alterar usuário ............................................. 66
Figura 3.14 – DSS05 Diagrama de seqüência remover usuário .......................................... 67
xi
Figura 3.15 – DSS06 Diagrama de seqüência consultar usuário......................................... 68
Figura 3.16 – DSS08 Diagrama de seqüência consultar modelo ........................................ 68
Figura 3.17 – DSS07 Diagrama de seqüência criar modelo................................................ 69
Figura 3.18 – DSS09 Diagrama de seqüência alterar modelo............................................. 70
Figura 3.19 – DSS10 Diagrama de seqüência remover modelo.......................................... 71
Figura 3.20 – DSS11 Diagrama de seqüência liberar modelo............................................. 72
Figura 3.21 – DSS12 Diagrama de seqüência criar documento .......................................... 73
Figura 3.22 – DSS13 Diagrama de seqüência consultar documento................................... 74
Figura 3.23 – DSS14 Diagrama de seqüência alterar documento ....................................... 75
Figura 3.24 – DSS15 Diagrama de seqüência remover documento .................................... 76
Figura 3.25 – DSS16 Diagrama de seqüência liberar documento....................................... 77
Figura 3.26 – DSS17 Diagrama de seqüência divulgar documento .................................... 78
Figura 3.27 – DSS18 Diagrama de seqüência imprimir documento ................................... 79
Figura 3.28 – DSS19 Diagrama de seqüência mover documento para o arquivo morto .... 80
Figura 3.29 – DSS20 Diagrama de seqüência recuperar documento do arquivo morto ..... 81
Figura 3.30 – DSS21 Diagrama de seqüência remover documento do arquivo morto ....... 82
Figura 3.31 – DSS23 Diagrama de seqüência consultar documento no arquivo morto...... 82
Figura 3.32 – Tela 01 – Tela principal do sistema .............................................................. 83
Figura 3.33 – Tela 02 – Tela principal do sistema .............................................................. 84
Figura 3.34 – Tela 03 – Tela principal do sistema .............................................................. 85
Figura 3.35 – Tela 04 – Tela principal do sistema .............................................................. 86
Figura 3.36 – Tela 05 – Tela principal do sistema .............................................................. 87
Figura 3.37 – Tela 06 – Acessar sistema ............................................................................. 88
Figura 3.38 – Tela 07 – Configurar sistema ........................................................................ 89
Figura 3.39 – Tela 08 – Configurar sistema ........................................................................ 90
Figura 3.40 – Tela 09 – Teste de conexão do banco de dados ............................................ 91
Figura 3.41 – Tela 10 – Gerenciamento de usuário............................................................. 92
Figura 3.42 – Tela 11 – Gerenciamento de modelos........................................................... 93
Figura 3.43 – Tela 12 – Gerenciamento de modelos........................................................... 94
Figura 3.44 – Tela 13 – Gerenciamento de modelos........................................................... 95
Figura 3.45 – Tela 14 – Visualizar modelo ......................................................................... 96
xii
Figura 3.46 – Tela 15 – Liberar modelo.............................................................................. 97
Figura 3.47 – Tela 16 – Gerenciamento de documentos ..................................................... 98
Figura 3.48 – Tela 17 – Liberar documento ........................................................................ 99
Figura 3.49 – Tela 18 – Consultar documento .................................................................... 100
Figura 3.50 – Tela 19 – Divulgar documento...................................................................... 101
Figura 3.51 – Tela 20 – Arquivo morto............................................................................... 102
xiii
LISTA DE ABREVIATURAS E SIGLAS
GED
Gerenciamento Eletrônico de Documentos.
OCR
Reconhecimento Óptico de Caracteres.
UML
Linguagem de Modelagem Unificada.
RE
Engenharia de Requisitos.
CASE
Engenharia de Software auxiliada por Computador.
PC
Computador Pessoal – Microcomputador.
COTS
Sistemas comerciais independentes.
HD
Disco rígido.
SGBD
Sistema Gerenciador de Banco de Dados.
SQL
Linguagem de Consulta Estruturada
ODBC
Conectividade de Base de Dados Aberto.
1
SISTEMA DE PADRONIZAÇÃO E GERENCIAMENTO DE
DOCUMENTOS ELETRÔNICOS
CAPÍTULO I
1. INTRODUÇÃO
Cada vez mais as empresas e organizações estão gerando documentos em forma de
papel. A rapidez na localização das informações contidas nos documentos é hoje uma questão
prioritária.
A morosidade na localização e a falta de cuidado no arquivamento dos documentos de
registros funcionais e financeiros, bem como as obrigações fiscais, não passam de falta de
organização e métodos no armazenamento e recuperação de documentos. Organizá-los em pastas
e arquivos físicos dificulta a agilidade de recuperação, trazendo conseqüências para os processos.
Além disso, a informação contida em documentos, em forma de papel, tem uma menor
flexibilidade e tende a gerar maiores gastos, que são destinados a manutenção de locais cada vez
maiores para o armazenamento da documentação física, diferente de quando é feito na forma
eletrônica.
Utilizava-se da tecnologia de processamento de documentos que se restringia a
melhorar recursos para gerar, imprimir e transportar os mesmos. Atualmente é utilizada a
tecnologia GED, que implementou algumas soluções importantes na maneira de criar, armazenar
e distribuir um documento, baseado em tecnologias de extração do meio físico (papel) para o
meio digital (imagem digitalizada), reduzindo assim, a necessidade crescente de espaço físico. A
tecnologia GED oferece também uma solução para aumentar a agilidade do processo de
gerenciamento manual de documentos para o usuário, com segurança e confiabilidade.
O que é GED?
O gerenciamento eletrônico de documentos ou “Document Imaging” é o processo de
conversão dos documentos em suporte de papel ou microfilme em bitmaps eletrônico, que
representam a figura de uma pagina e o seu gerenciamento através de um software, o qual
2
permite que os mesmos sejam indexados, armazenados, pesquisados, recuperados e visualizados.
A escanerização ou digitalização é um processo de conversão dos documentos em papel ou
microfilme, o qual é similar ao usado por uma fotocopiadora ou FAC-SÍMILE. Os documentos
são convertidos através de um equipamento chamado scanner.
Uma vez convertido em imagem eletrônica, cada documento é nomeado e indexado
através de informações obtidas dele mesmo, como títulos, nomes, datas ou outras identificações
e, então, arquivado eletronicamente. Mais tarde, os documentos podem ser recuperados
pesquisando-se através dos índices digitados (titulo ou o código de identificação).
Se desejado, o computador pode “ler” o texto de cada página (imagem) através de um
processo chamado Reconhecimento Óptico de Caracteres – OCR que cria um arquivo de texto, o
qual pode ser usado para indexar o documento. O processo de utilização do texto de um
documento para pesquisa e recuperação é reconhecido como “full-text indexing and retrieving”,
uma ferramenta poderosa que permite uma pessoa achar qualquer página através de certas
palavras ou frases.
Além do gerenciamento eletrônico, este projeto tem como objetivo facilitar a criação de
documentos a serem moldados de acordo com o padrão adotado pela organização, tornando assim
um documento padrão automatizado para ser utilizado entre os usuários da mesma.
Neste projeto fizemos uma breve introdução bibliográfica sobre os processos de
software (item 2.1), citando alguns modelos de processos, interação de processo, atividades de
processo e também processos de engenharia de requisitos (item 2.2), casos de uso (item 2.3),
diagramas de classe (item 2.4), diagramas de seqüência (item 2.5), banco de dados (2.6),
orientação a objetos (item 2.7).
Para o desenvolvimento do sistema em questão foi utilizado o sistema de
desenvolvimento em espiral apoiado pela ferramenta case Jude Community como apoio à
especificação dos diagramas de casos de uso, de seqüência e de classes, modelado o banco de
dados com suporte da ferramenta Power Designer e implementado na linguagem orientada a
objetos Visual Basic .NET[5].
3
CAPÍTULO II
2. ESTUDOS BIBLIOGRÁFICOS
Nos estudos bibliográficos serão abordados os processos de software mais conhecidos,
seus modelos, interação e atividades, também serão abordados os processos de engenharia de
requisitos, requisitos de software, estudo de viabilidade, elicitação e validação de requisitos.
2.1. PROCESSOS DE SOFTWARE
Processo de software é um conjunto de atividades que envolvem o desenvolvimento de
software. Apesar de existir muitos processos de softwares diferentes tais como, sistemas críticos e
sistemas de negócios, algumas atividades são comuns a todos eles como as atividades abaixo
retiradas do Sommerville [2]:
•
Especificação de software – “a funcionalidade do software e as restrições sobre sua
operação devem ser definidas”;
•
Projeto e implementação de software – “o software que atenda à especificação
deve ser produzido”;
•
Validação de software – “o software deve ser validado para garantir que ele faça o
que o cliente deseja”;
•
Evolução de software – “o software deve evoluir para atender às necessidades
mutáveis do cliente”.
2.1.1. MODELOS DE PROCESSO DE SOFTWARE
Um modelo de processo de software é uma representação abstrata de um processo de
software, onde cada modelo representa um processo sob determinada perspectiva.
Os modelos de processos conhecidos retirados do Sommerville [2]:
4
•
Modelo em cascata – “considera as atividades fundamentais do processo,
compreendendo especificação, desenvolvimento, validação e evolução, e as
representam como fases de processos separadas, tais como especificação de
requisitos, projeto de software, implementação, teste e assim por diante”;
•
Desenvolvimento evolucionário – “esta abordagem intercala as atividades de
especificação, desenvolvimento e validação. Um sistema inicial é desenvolvido
rapidamente baseado em especificações abstratas. Este sistema é, então, refinado
com as entradas do cliente para produzir um sistema que satisfaça as necessidades
do cliente”;
•
Engenharia de software baseada em componentes – “esta abordagem baseia-se
na existência de um número significativo de componentes reusáveis. O processo de
desenvolvimento do sistema enfoca a integração desses componentes, em vez de
desenvolvê-los a partir do zero”.
2.1.1.1. O MODELO EM CASCATA
Este modelo é denominado cascata, devido ao encadeamento de uma fase com a outra,
como podemos observar na Figura 2.1, retirado do Sommerville [2]. A fase seguinte só deve
começar quando a fase atual for encerrada, e cada uma das fases desse modelo deverá gerar um
documento de aprovação.
Figura 2.1 – Ciclo de vida de software em cascata.
5
Estágios do modelo cascata baseado no Sommerville [2]:
•
Análise e definição de requisitos – “os serviços, restrições e objetivos do sistema
são definidos por meio de consulta aos usuários do sistema. Eles são, portanto,
definidos detalhadamente e servem como uma especificação de sistema”.
•
Projeto de sistema e software – “o processo de projeto de sistema divide os
requisitos em sistemas de hardware ou de software. Ele estabelece uma arquitetura
geral do sistema. O projeto de software envolve a identificação e a descrição das
abstrações fundamentais do sistema de software e suas relações”.
•
Implementação e teste de sistema – “durante esse estágio, o projeto de software é
realizado como um conjunto de programas ou unidades de programa. O teste
unitário envolve a verificação de que cada unidade atende à sua especificação”.
•
Integração e teste de sistema – “as unidades individuais de programa ou os
programas são integrados e testados como um sistema completo para garantir que os
requisitos de software foram atendidos. Após os testes, o sistema de software é
liberado para o cliente”.
•
Operação e manutenção – “geralmente esta é a fase mais longa do ciclo de vida. O
sistema é instalado e colocado em operação. A manutenção envolve a correção de
erros não detectados nos estágios anteriores do ciclo de vida, no aprimoramento da
implementação das unidades de sistema e na ampliação dos serviços de sistema à
medida que novos requisitos são identificados”.
Pelo fato do modelo cascata não ser um modelo flexível, é recomendado que este
modelo seja usado apenas quando os requisitos forem bem compreendidos e houver pouca
probabilidade de mudanças radicais durante o desenvolvimento do sistema.
2.1.1.2. DESENVOLVIMENTO EVOLUCIONÁRIO
O desenvolvimento evolucionário se baseia na exposição de resultados aos comentários
dos usuários, refinando esse(s) resultado(s) com várias versões até que se obtenha o sistema
adequado, como é mostrado na Figura 2.2, retirada do Sommerville [2].
6
Figura 2.2 – Desenvolvimento evolucionário.
Existem dois tipos fundamentais de desenvolvimento evolucionário especificados em
Sommerville [2]:
•
Desenvolvimento exploratório – “no qual o objetivo do processo é trabalhar com o
cliente para explorar os requisitos e entregar um sistema final. O desenvolvimento
começa com as partes do sistema compreendidas. O sistema evolui por meio da
adição de novas características propostas pelo cliente”.
•
Prototipação – “na qual o objetivo do processo de desenvolvimento evolucionário é
compreender os requisitos do cliente e, a partir disso, desenvolver melhor definição
de requisitos para o sistema. O protótipo se concentra na experimentação dos
requisitos mal compreendidos do cliente”.
2.1.1.3. ENGENHARIA DE SOFTWARE BASEADA EM COMPONENTES
Quando as pessoas que trabalham no projeto conhecem os projetos ou os códigos
similares, é provável que haja algum reuso de software.
De acordo com Sommerville [2], demonstrado na Figura 2.3, à abordagem orientada a
reuso depende de uma grande base de componentes de software reusáveis e algum framework de
integração desses componentes.
7
Figura 2.3 – Engenharia de software baseada em componentes.
•
Análise de componentes – “dada uma especificação de requisitos, é feita uma
busca pelos componentes para implementar essa especificação. Geralmente, não
existe uma correspondência exata e os componentes que podem ser usados fornecem
apenas parte da funcionalidade necessária”.
•
Modificação de requisitos – “durante esse estágio, os requisitos são analisados
usando informações sobre os componentes encontrados. Eles são modificados para
refletir os componentes disponíveis. Quando as modificações são impossíveis, a
atividade de analise de componentes pode ser novamente realizada para procurar
soluções alternativas”.
•
Projeto de sistema com reuso – “durante este estágio, o framework do sistema é
projetado ou um framework existente e reusado. Os projetistas levam em
consideração os componentes reusados, organizando o framework para eles. Pode
ser necessário projetar algum software novo caso os componentes reusáveis não
estejam disponíveis”.
•
Desenvolvimento e integração – “o software que não pode ser adquirido
externamente é desenvolvido e os componentes e os sistemas COTS são integrados
para criar um novo sistema. A integração de sistema, neste modelo, pode ser parte
do processo de desenvolvimento, em vez de ser uma atividade separada”.
2.1.2. ITERAÇÃO DE PROCESSO
Como alterações em projetos de grande porte são inevitáveis, devido a mudanças de
requisitos, tecnologias disponíveis atualmente e a pressões externas do mercado, devido à
8
competitividade entre as empresas. As atividades de processo são repetidas regularmente à
medida que o sistema é retrabalhado, em resposta às solicitações de mudanças.
Os modelos utilizados para apoiar a iteração de processos são:
•
Entrega incremental – “a especificação, o projeto e a implementação de software
são divididos em uma série de incrementos desenvolvidos um de cada vez”.
•
Desenvolvimento espiral – “o desenvolvimento do sistema evolui em espiral para
fora a partir de um esboço inicial até o sistema final”.
2.1.2.1. ENTREGA INCREMENTAL
A entrega incremental é uma abordagem intermediaria que combina as vantagens do
modelo de desenvolvimento em cascata e o modelo de abordagem evolucionaria, como podemos
observar na Figura 2.4 encontrada no Sommerville [2].
Figura 2.4 – Entrega incremental.
Vantagens:
•
“Os clientes não precisam esperar até a entrega do sistema inteiro para se
beneficiarem dele. O primeiro incremento satisfaz os requisitos mais críticos e,
dessa forma, é possível usar o software imediatamente”;
•
“Os clientes podem usar os incrementos iniciais como protótipos e ganhar
experiência, obtendo informações sobre os requisitos dos incrementos posteriores do
sistema”;
9
•
“Existe um risco menor de falha geral do projeto. Embora possa ser encontrados
problemas em alguns incrementos, é provável que alguns sejam entregues com
sucesso aos clientes”;
•
“Como os serviços de prioridade mais alta são entregues primeiro, e os incrementos
posteriores são integrados a eles, é inevitável que os serviços mais importantes de
sistema recebam mais testes. Isso significa que os clientes têm menor probabilidade
de encontrar falhas de software nas partes mais importantes do sistema”.
No entanto, “os incrementos devem ser relativamente pequenos com até 20 mil linhas
de código, e cada um deve entregar alguma funcionalidade de sistema”.
2.1.2.2. DESENVOLVIMENTO EM ESPIRAL
Ao invés de se representar as atividades do processo de software de forma seqüencial
com algum retorno entre uma atividade e outra, é representada como uma espiral de acordo com a
Figura 2.5. Cada fase do processo pode ser representada como uma volta da espiral, sendo que as
fases do desenvolvimento evoluem da volta mais interna para a mais externa.
Figura 2.5 – Modelo em espiral do processo de software.
10
De acordo com Sommerville [2], cada volta na espiral está dividida em quatro setores:
•
Definição de objetivos – “os objetivos específicos dessa fase são definidos. As
restrições sobre o processo e o produto são identificadas em um plano detalhado de
gerenciamento é elaborado. Os riscos de projeto são identificados. Dependendo
disso, estratégias alternativas podem ser planejadas”.
•
Avaliação e redução de riscos – “para cada risco de projeto identificado, uma
analise detalhada realizada. Providencias são tomadas para reduzir o risco. Por
exemplo, se houver risco de que os requisitos não sejam apropriados, um protótipo
do sistema poderá ser desenvolvido”.
•
Desenvolvimento e validação – “após a avaliação de risco, um modelo de
desenvolvimento para o sistema é selecionado. Por exemplo, se os riscos da
interface com o usuário forem dominantes, o modelo de desenvolvimento
apropriado pode ser a prototipação evolucionaria. Se os riscos de segurança
constituírem
a
principal
consideração,
o
desenvolvimento
baseado
em
transformações formais pode ser mais apropriados e assim por diante”.
•
Planejamento – “o projeto é revisado e uma decisão é tomada para prosseguimento
a próxima volta da espiral. Se a decisão for pelo prosseguimento, serão elaborados
planos para a próxima fase do projeto”.
Comparando com outros modelos, a principal diferença entre o modelo espiral e eles, é
o reconhecimento explicito do risco.
A elaboração de objetivos como desempenho e funcionalidade, podem fazer parte de
um ciclo da espiral. Os caminhos alternativos para alcançar esses objetivos e as restrições
impostas sobre cada um deles são, então, enumerados. Cada alternativa é avaliada em relação a
cada objetivo e as fontes de riscos de projetos são identificadas. O próximo passo é resolver esses
riscos por meios de atividades de coletas de informações, tais como analise mais detalhada,
prototipação e simulação. Após a avaliação dos riscos, é realizada uma parte do desenvolvimento,
seguida pela atividade de planejamento para próxima fase do processo.
11
2.1.3. ATIVIDADES DE PROCESSO DE SOFTWARE
Especificação, desenvolvimento, validação e evolução, são as quatro atividades básicas
do processo, e há duas formas de organizá-las. No modelo em cascata as atividades são
organizadas em seqüencia, e no modelo evolucionário são intercaladas.
2.1.3.1. ESPECIFICAÇÃO DE SOFTWARE
A especificação de software é o processo utilizado para definir quais serviços são
necessários e identificar as restrições de operação e de desenvolvimento do sistema, esse
processo também é conhecido como engenharia de requisitos.
Os requisitos são apresentados de duas formas diferentes: uma das formas é para
usuários finais e clientes com uma declaração de requisitos de alto nível, e a outra forma é para
projetistas de sistemas com uma declaração mais detalhada.
2.1.3.2. DESENVOLVIMENTO DE SOFTWARE
O desenvolvimento de software é o processo de conversão de uma especificação de
sistema em um sistema executável.
“Um projeto de software é a descrição da estrutura de software a ser implementada, dos
dados que são partes do sistema, das interfaces entre os componentes do sistema e, às vezes, dos
algoritmos usados.” Sommerville [2].
Para aprimoramento de modelos anteriores utiliza-se o processo feed-back, o ato de
decompor um projeto para descobrir erros e omissões em estágios anteriores de projeto. A Figura
2.6 é um modelo desse processo que sugere que os estágios do processo de projeto sejam
seqüenciais.
12
Figura 2.6 – Modelo geral de processo de projeto.
As atividades específicas do processo de projeto listadas abaixo, podem ser uma
especificação abstrata e formal que serve para esclarecer os requisitos, ou pode ser uma
especificação de como uma parte do software será realizada. De acordo com Sommerville [2]:
•
Projeto de arquitetura – “os subsistemas constituintes do sistema e os seus
relacionamentos são identificados e documentados”.
•
Especificação abstrata – “para cada subsistema, é produzida uma especificação
abstrata dos serviços e as restrições sob as quais ele deve operar”.
•
Projeto de interface – “para cada subsistema, é projetada e documentada a
interface com outros subsistemas. A especificação de interface não deve ser
ambígua, pois ela permite que o subsistema seja usado sem que se tenha
conhecimento da sua operação”.
•
Projeto de componente – “os serviços são alocados aos componentes e as
interfaces desses componentes são projetadas”.
•
Projeto de estruturas de dados – “as estruturas de dados usadas na implementação
do sistema são projetadas detalhadamente e especificadas”.
•
Projeto de algoritmo – “os algoritmos usados para fornecer os serviços são
projetados detalhadamente e especificados”.
13
2.1.3.3. VALIDAÇÃO DE SOFTWARE
“A validação do software, destina-se a mostrar que um sistema está em conformidade
com sua especificação e que atende às expectativas do cliente que está adquirindo o sistema.”
Sommerville [2].
Ou seja, cada etapa do processo de software, desde a definição de requisitos de usuários
até o desenvolvimento do programa, irá passar pelo processo de verificação tais como inspeções e
revisões.
A Figura 2.7 mostra um processo de teste em três estágios, onde primeiramente os
componentes do sistema são testados, depois é testado o sistema integrado e, finalmente, o
sistema é testado com os dados do cliente.
Figura 2.7 – Processo de teste.
Estágios do processo de teste retirados do Sommerville [2]:
•
Teste de componentes (ou unidade) – “os componentes individuais são testados
para
garantir
que
operem
corretamente.
Cada
componente
é
testado
independentemente, sem os outros componentes de sistema. Os componentes podem
ser entidades simples, tais como funções ou classes de objetos, ou podem ser grupos
coerentes dessas entidades”.
•
Teste de sistema – “os componentes são integrados para compor o sistema. Esse
processo está relacionado com a busca de erros que resultam das interações não
previstas entre os componentes e problemas de interface de componentes. Está
também relacionado à validação de que o sistema atende aos requisitos funcionais e
não funcionais e ao teste no qual os componentes são integrados para formar
14
subsistemas testados individualmente antes que sejam integrados para formar o
sistema final”.
•
Teste de aceitação – “este é o final do processo de teste, antes que o sistema seja
aceito para o uso operacional. O sistema é testado com os dados fornecidos pelo
cliente do sistema, em vez de dados simulados de teste. O teste de aceitação pode
revelar erros e omissões na definição de requisitos de sistema, em vez de dados
simulados de teste. O teste de aceitação pode revelar erros e omissões na definição
de requisitos de sistema, pois os dados reais exercitam o sistema de formas
diferentes dos dados de teste. O teste de aceitação pode também revelar problemas
de requisitos, em que os recursos do sistema não atendem realmente às necessidades
do usuário ou o desempenho do sistema é inaceitável”.
2.1.3.4. EVOLUÇÃO DE SOFTWARE
De acordo com Sommerville [2] a flexibilidade dos sistemas de software é uma das
principais razões pelas quais cada vez mais o software está sendo incorporado a sistemas
complexos de grande porte. Após a decisão de aquisição de hardware, é muito oneroso fazer
mudanças no projeto de hardware. No entanto, mudanças podem ser feitas no software a qualquer
instante durante ou após o desenvolvimento do sistema. Mesmo mudanças extensas são mais
baratas do que as mudanças correspondentes no hardware do sistema.
“É mais realista pensar na engenharia de software como um processo evolutivo, Figura
2.8, no qual o software é continuamente alterado ao longo de sua vida, em resposta às mudanças
de requisitos e as necessidades do cliente”, Sommerville [2].
Figura 2.8 – Evolução de sistema.
15
2.2. PROCESSOS DE ENGENHARIA DE REQUISITOS
De acordo com Sommerville [2], “o objetivo do processo de engenharia de requisitos é
criar e manter um documento de requisitos do sistema”. O processo geral inclui quatro
subprocessos Figura 2.9 de alto nível de engenharia de requisitos que são especificados nos
subtópicos 2.10 (requisitos de software), 2.11 (estudo de viabilidade), 1.12 (elicitação e análise
de requisitos) e 2.13 (validação de requisitos).
Figura 2.9 – Processo de engenharia de requisitos.
Como podemos observar em Sommerville [2], os processos de engenharia de requisitos
no formato espiral conforme ilustrado na Figura 2.10, mostra os processos como uma atividade
de três estágios, na qual as atividades estão organizadas como um processo iterativo em espiral.
Porém o modelo espiral acomoda abordagens de desenvolvimento em que os requisitos são
desenvolvidos para diferentes níveis de detalhes. O número de iterações na espiral pode variar no
decorrer do levantamento dos requisitos, de modo que pode-se sair da espiral depois de alguns ou
todos os requisitos de usuário tiverem sidos elicitados diferindo do exemplo inicial demonstrado
na Figura 2.9.
16
Figura 2.10 – Modelo em espiral dos processos de engenharia de requisitos.
2.2.1. REQUISITOS DE SOFTWARE
Segundo Sommerville, os requisitos de um sistema são descrições dos serviços
fornecidos pelo sistema e as suas restrições operacionais. O termo requisito não é usado pela
indústria de software de maneira consistente. Em alguns casos, um requisito é simplesmente uma
declaração abstrata de alto nível de um serviço que o sistema deve fornecer ou uma função do
sistema. Davis (Davis 1993) explica por que essas diferenças existem:
“Se uma empresa deseja estabelecer um contrato para o desenvolvimento de um grande
projeto de software, ela precisa definir suas necessidades de maneira suficientemente abstrata,
para que uma solução não seja predefinida. Os requisitos devem ser redigidos de modo que os
diversos fornecedores possam apresentar propostas, talvez, diferentes maneiras de atender ás
necessidades organizacionais do cliente. Após a aprovação do contrato, o fornecedor deve redigir
uma definição mais detalhada do sistema para o cliente, de modo que o cliente possa
compreender e validar o que o software fará. Esses dois documentos podem ser chamados de
documentos de requisitos do sistema.”
17
2.2.1.1. REQUISITOS FUNCIONAIS E NÃO FUNCIONAIS
Os requisitos de sistema de software são, freqüentemente, classificados em requisitos
funcionais e requisitos não funcionais:
2.2.1.1.1. REQUISITOS FUNCIONAIS
Os requisitos funcionais de um sistema descrevem o que o sistema deve fazer. Esses
requisitos dependem do tipo do software que está sendo desenvolvido, dos usuários a que o
software se destina e da abordagem geral considerada pela organização ao redigir os requisitos.
Os requisitos funcionais descrevem a função do sistema detalhadamente, suas entradas e saídas,
exceções etc. Em principio, a especificação de requisitos funcionais de um sistema deve ser
completa e consistente. Completeza significa que todos os serviços exigidos pelo usuário devem
ser definidos. Consistência significa que os requisitos não devem ter definições contraditórias. Na
prática, em sistemas grandes e complexos, é praticamente impossível atingir a consistência e a
completeza de requisitos.
2.2.1.1.2. REQUISITOS NÃO FUNCIONAIS
Sommerville [2], afirma que requisitos não funcionais “são aqueles não diretamente
relacionados as funções especificas fornecidas pelo sistema. Eles podem estar relacionados às
propriedades emergentes do sistema, como confiabilidade, tempo de resposta e espaço de
armazenamento”.
Tipos de requisitos não funcionais, que podem ser observados na Figura 3.3 abaixo:
•
Requisitos de produto – estes requisitos especificam o comportamento do produto;
•
Requisitos organizacionais – estes requisitos são derivados de políticas e
procedimentos da organização do cliente e do desenvolvedor;
•
Requisitos externos – abrange todos os requisitos derivados de fatores externos ao
sistema e seu processo de desenvolvimento.
18
Figura 2.11 – Tipos de requisitos não funcionais.
2.2.1.2. REQUISITOS DE USUÁRIOS
Requisitos de usuários devem especifica apenas o comportamento externo do sistema e
evitar, sempre que possível, características de projeto do sistema, de modo que sejam
compreensíveis pelos usuários do sistema que não possuem conhecimento técnico detalhado.
Diretrizes sugeridas por Sommerville [2], para minimizar o mal-entendimento ao redigir
requisitos de usuários:
•
“Invente um formato padrão e assegure-se que todas as definições de requisitos
aderiram a esse formato”;
•
“Use a linguagem de forma consistente”;
•
“Use destaque no texto (negrito, itálico ou cor) para ressaltar as partes principais dos
requisitos”;
•
“Evitar, sempre que possível, o uso de jargões de informática”.
19
2.2.1.3. REQUISITOS DE SISTEMA
É a especificação completa e consistente de todo o sistema. Devem simplesmente
descrever o comportamento externo do sistema e suas restrições operacionais, e eles não devem
estar relacionados a como o sistema pode ser projetado ou implementado.
2.2.1.4. ESPECIFICAÇÃO DE INTERFACE
Sommerville [2] define especificação de interface em três tipos:
•
Interfaces de procedimentos – “nas quais programas ou subsistemas existentes
oferecem uma serie de serviços acessados pela chamada de procedimentos de
interface”;
•
Estruturas de dados – “que são passadas de um subsistema para outro”;
•
Representações de dados – “estabelecidas para um sistema preexistentes”.
2.2.2. ELICITAÇÃO E ANÁLISE DE REQUISITOS
Nesse estágio os engenheiros de software trabalham diretamente com os clientes e
usuários finais do sistema para aprender sobre o domínio da aplicação, quais serviços o sistema
deve fornecer, o desempenho esperado do sistema, restrições de hardware etc.
Um modelo de processo bastante genérico de elicitação e análise de requisitos é
apresentado na Figura 2.12. Esse modelo poderá variar de organização para organização,
dependendo de fatores locais, como o nível de conhecimento da equipe, o tipo do sistema que
está sendo desenvolvido e os padrões usados. Optamos por demonstrar o processo de elicitação e
análise de requisitos em formato de espiral como adotado por Sommerville [2], de modo que as
atividades se intercalem à medida que o processo progrida da parte interna da espiral para a parte
externa.
20
Figura 2.12 – Processo de elicitação e análise de requisitos.
As atividades deste processo são retiradas de Sommerville [2]:
•
Obtenção de requisitos – “É o processo de interação com os stakehoders no
sistema para coletar seus requisitos. Os requisitos de domínio são também
descobertos durante essa atividade, provenientes dos stakeholders e da
documentação”.
•
Classificação e organização de requisitos – “Esta atividade envolve a coleção de
requisitos não estruturados, agrupa os requisitos relacionados e os organiza em
conjuntos coerentes”.
•
Priorização e negociação de requisitos – “Inevitavelmente, quando vários
stakeholders participam do processo, os requisitos serão conflitantes. Esta atividade
está relacionada à priorização de requisitos, à procura e à resolução de conflitos por
meio de negociação”.
21
•
Documentação de requisitos – “Os requisitos são documentados e colocados na
próxima volta da espiral, Figura 2.12. Podem ser produzidos documentos formais ou
informais”.
2.2.3. VALIDAÇÃO DE REQUISITOS
A validação de requisitos dedica-se a mostrar que os requisitos realmente definem o
sistema que o usuário deseja. A validação de requisitos se sobrepõe à análise; está relacionada à
descoberta de problemas com os requisitos. A validação de requisitos é importante porque os
erros em um documento de requisitos podem levar a custos excessivos de retrabalho quando são
descobertos durante o desenvolvimento ou depois que o sistema está em operação. O custo de
correção de um problema de requisitos, fazendo uma mudança de sistema, é muito maior do que
a correção de erros de projeto e de codificação. A razão disso é que uma mudança de requisitos
significa geralmente que o projeto e a implementação do sistema devem também ser mudados e o
sistema deve ser novamente testado.
Durante o processo de validação de requisitos, devem ser realizadas verificações nos
requisitos do documento de requisitos. De acordo com Sommerville [2], essas verificações
incluem:
• Verificações de validade. “Um usuário pode pensar que um sistema é necessário
para desempenhar determinadas funções. Contudo, mais estudos e analises podem
identificar que funções adicionais e diferentes são necessárias”.
• Verificações de consistência. “Os requisitos em um documento não devem ser
conflitantes. Isso significa que não devem existir restrições ou descrições
contraditórias para a mesma função do sistema”.
• Verificações de completeza. “O documento de requisitos deve incluir requisitos que
definam todas as funções e as restrições desejadas pelo usuário do sistema”.
• Verificações de realismo. “Usando o conhecimento da tecnologia existente, os
requisitos devem ser verificados quanto a se realmente podem ser implementados.
Essas verificações também devem levar em consideração o orçamento e o prazo para
desenvolvimento do sistema”.
22
• Facilidade de verificação. “Para reduzir o potencial de divergências entre cliente e
fornecedor, os requisitos do sistema devem sempre ser escritos de modo que sejam
verificáveis. Isto significa que deve-se escrever um conjunto de testes que possa
demonstrar que o sistema entregue atende a cada requisito especificado”.
Uma série de técnicas de validação de requisitos pode ser usada em conjunto ou
individualmente:
• Revisões de requisitos. “Os requisitos são analisados sistematicamente por uma
equipe de revisores”.
• Prototipação. “Nesta abordagem de validação, um modelo executável do sistema é
apresentado para usuários finais e clientes. Eles podem experimentar o modelo para
verificar se atende às suas necessidades reais”.
• Geração de casos de teste. “Os requisitos devem ser testáveis. Se os testes dos
requisitos forem criados como parte do processo de validação, eles freqüentemente
revelarão problemas de requisitos. Se um teste for difícil ou impossível de ser
projetado, isso significa geralmente que os requisitos serão difíceis de ser
implementados e devem ser reconsiderados”.
2.2.3.1. PLANEJAMENTO DE GERENCIAMENTO DE REQUISITOS
Para cada projeto, o estágio de planejamento estabelece o nível de detalhamento
necessário para o gerenciamento de requisitos. Durante o estágio de gerenciamento de requisitos
deve-se decidir sobre[2]:
• Identificação de requisitos. “Cada requisito deve ser identificado unicamente de
modo que possa ser feita a referência cruzada entre este e outros requisitos para que
ele possa ser usado nas avaliações de rastreabilidade”.
• Processo de gerenciamento de mudanças. “É o conjunto de atividades que avaliam
o impacto e custo das mudanças”.
• Políticas de rastreabilidade. “Essas políticas definem os relacionamentos entre os
requisitos e o projeto do sistema, que devem ser registrados, e como esses registros
devem ser mantidos”.
23
• Apoio de ferramentas CASE. “O gerenciamento de requisitos envolve grandes
quantidades de informações sobre os requisitos. As ferramentas que podem ser usadas
variam desde sistemas especializados de gerenciamento de requisitos a planilhas e
sistemas simples de banco de dados”.
“Existem vários relacionamentos entre os requisitos e entre os requisitos de projeto do
sistema. Existem também ligações entre requisitos e os motivos básicos de por esses requisitos
foram propostos. Quando aas mudanças são propostas, deve-se rastrear seu impacto em outros
requisitos e no projeto do sistema. A rastreabilidade é a propriedade de uma especificação que
reflete a facilidade de encontrar os requisitos relacionados”.
Existem três tipos de informações de rastreabilidade que podem ser mantidos[2]:
• “Informações de rastreabilidade da origem ligam os requisitos aos stakeholders
que propuseram os requisitos e aos motivos desses requisitos. Quando uma mudança
é proposta, utiliza-se essas informações para encontrar e consultar os stakeholders
sobre a mudança”.
• “Informações de rastreabilidade de requisitos ligam os requisitos dependentes
dentro do documento de requisitos. Utiliza-se essas informações para avaliar quantos
requisitos provavelmente serão afetados pela mudança proposta e a extensão das
mudanças de requisitos conseqüentes que podem ser necessários”.
• “Informações de rastreabilidade de projeto ligam os requisitos aos módulos de
projeto, nos quais esses requisitos são implementados. Usa-se essas informações para
avaliar o impacto das mudanças de requisitos propostos no projeto e na
implementação do sistema”.
“As informações de rastreablilidade são freqüentemente representadas por meio de
matrizes de rastreabilidade que relacionam os requisitos aos stakeholders, aos outros requisitos ou
aos módulos de projeto. Em uma matriz de rastreabilidade de requisitos, cada requisito é
introduzido em uma linha e uma coluna da matriz. As dependências entre diferentes requisitos
são registradas na célula correspondente à intersecção de linha/coluna”.
“As matrizes de rastreabilidade podem ser usadas quando um pequeno número de
requisitos deve ser gerenciado, mas para sistemas de grande porte, com muitos requisitos,
tornam-se muito difíceis de serem gerenciadas e sua manutenção é dispendiosa. Para esses
sistemas, deve-se captar as informações de rastreabilidade em um banco de dados de requisitos,
24
no qual cada registro é explicitamente ligado a requisitos relacionados. Pode-se então avaliar o
impacto das mudanças usando os recursos de acesso ao banco de dados. As matrizes de
rastreabilidade podem ser geradas automaticamente baseadas no banco de dados”.
O gerenciamento de requisitos precisa de apoio automatizado; as ferramentas CASE
para essa finalidade devem ser selecionadas durante a fase de planejamento. Segundo
Sommerville [2] o apoio de ferramentas é necessário para:
• Armazenamento de requisitos. “Os requisitos devem ser mantidos em um
repositório de dados seguro e gerenciado acessível a todos os envolvidos no processo
de engenharia de requisitos”.
• Gerenciamento de mudanças. “O processo de gerenciamento de mudanças (figura
2.13) é simplificado se um apoio ativo de ferramentas estiver disponível”.
• Gerenciamento de rastreabilidade. “Conforme explicado anteriormente, o apoio de
ferramentas para rastreabilidade permite que requisitos relacionados sejam obtidos.
Algumas ferramentas usam técnicas de processamento de linguagem natural para
auxiliar na descoberta de possíveis relacionamentos entre os requisitos”.
Figura 2.13 – Gerenciamento de mudanças de requisitos.
Para sistemas de pequeno porte, o uso de ferramentas especializadas de gerenciamento
de requisitos pode não ser necessário. O processo de gerenciamento de requisitos pode ter apoio
de recursos disponíveis em processadores de texto, planilhas e bancos de dados de PC. Contudo
para sistemas de grande porte, é necessária uma ferramenta de apoio mais especializada[2].
2.2.3.2. GERENCIAMENTO DE MUDANÇAS DE REQUISITOS
O gerenciamento de mudanças de requisitos Figura 2.13, deve ser aplicado a todas as
mudanças propostas aos requisitos. A vantagem de usar um processo formal para gerenciamento
de mudanças é que todas as propostas de mudanças são tratadas consistentemente, e que as
25
mudanças no documento de requisitos são feitas de maneira controlada. Existem três principais
estágios para um processo de gerenciamento de mudanças[2]:
•
Análise do problema e especificação da mudança – “o processo se inicia com um
problema de requisitos identificado ou, às vezes, com uma proposta de mudança
específica. Durante este estágio, o problema ou a proposta de mudança de requisitos
é analisada para verificar se é válida. Os resultados da análise são realimentados
para o solicitante da mudança e, algumas vezes, é feita uma proposta de mudança de
requisitos mais específica”.
•
Análise da mudança estimativa de custo – “efeito da mudança proposta é avaliado
usando as informações de rastreabilidade e o conhecimento geral sobre os requisitos
do sistema. Uma vez completada esta análise, é tomada uma decisão sobre
prosseguir ou não com a mudança de requisitos”.
•
Implementação da mudança – “o documento de requisitos e, quando necessário, o
projeto e implementação de sistema são modificados. Deve-se organizar o
documento de requisitos de modo que se possa realizar as mudanças sem reescrita
ou reorganização extensivas”.
2.3. CASOS DE USO
Na Engenharia de Software, um caso de uso é um tipo de classificador representando
uma unidade funcional coerente provida pelo sistema, subsistema, ou classe manifestada por
seqüências de mensagens intercambiáveis entre os sistemas e um ou mais atores. Pode ser
representado por uma elipse contendo, internamente, o nome do caso de uso.
Um Caso de Uso representa uma unidade discreta da interação entre um usuário
(humano ou máquina) e o sistema. Um Caso de Uso é uma unidade de um trabalho significante.
Cada Caso de Uso tem uma descrição o qual descreve a funcionalidade que irá ser construída no
sistema proposto. Um caso de uso pode "incluir" outra funcionalidade de caso de uso ou
"estender" outro caso de uso com seu próprio comportamento.
Casos de uso são tipicamente relacionados a "atores". Um ator é um humano ou entidade
máquina que interage com o sistema para executar um significante trabalho.
26
2.4. DIAGRAMA DE CLASSE
Em programação, um diagrama de classes é uma representação da estrutura e relações
das classes que servem de modelo para objetos.
É uma modelagem muito útil para o sistema, define todas as classes que o sistema
necessita possuir e é a base para a construção dos diagramas de comunicação, seqüência e
estados.
2.5. DIAGRAMA DE SEQÜÊNCIA
Diagrama de seqüência, ou diagrama de seqüência de mensagens é um diagrama usado
em UML, representando a seqüência de processos (mais especificamente, de mensagens passadas
entre objetos) num programa de computador. Como um projeto pode ter uma grande quantidade
de métodos em classes diferentes, pode ser difícil determinar a seqüência global do
comportamento. O diagrama de seqüência representa essa informação de uma forma simples e
lógica.
Um diagrama de seqüência descreve a maneira como os grupos de objetos colaboram
em algum comportamento ao longo do tempo. Ele registra o comportamento de um único caso de
uso e exibe os objetos e as mensagens passadas entre esses objetos no caso de uso.
Em síntese: o Diagrama de Sequência é uma das ferramentas UML usadas para
representar interações entre objetos de um cenário, realizadas através de operações ou métodos.
Este diagrama é construído a partir do diagrama de casos de usos. Primeiro, se define qual o
papel do sistema (casos de uso), depois, é definido como o software realizará seu papel
(Sequência de operações).
O diagrama de sequência dá ênfase a ordenação temporal em que as mensagens são
trocadas entre os objetos de um sistema. Entende-se por mensagens os serviços solicitados de um
objeto a outro, e as respostas desenvolvidas para as solicitações.
27
2.6. BANCO DE DADOS
Bancos de dados são conjuntos de registros dispostos em estrutura regular que
possibilita a reorganização dos mesmos e produção de informação. Um banco de dados
normalmente agrupa registros utilizáveis para um mesmo fim.
Um banco de dados é usualmente mantido e acessado por meio de um software
conhecido como Sistema Gerenciador de Banco de Dados (SGBD). Normalmente um SGBD
adota um modelo de dados, de forma pura, reduzida ou estendida. Muitas vezes o termo banco de
dados é usado como sinônimo de SGDB.
O modelo de dados mais adotado hoje em dia é o modelo relacional, onde as estruturas
têm a forma de tabelas, compostas por linhas e colunas.
No projeto em questão foi adotado o sistema de banco de dados relacional Postegre.
2.6.1. MY SQL
O MySQL é um sistema de gerenciamento de banco de dados (SGBD), que utiliza a
linguagem SQL (Structured Query Language - Linguagem de Consulta Estruturada) como
interface. É atualmente um dos bancos de dados mais populares, com mais de 10 milhões de
instalações pelo mundo
2.6.2. POSTGRE SQL
PostgreSQL é um poderoso, sistema de banco de dados relacional open source, ou seja,
seu código fonte é aberto para a comunidade que deseja cooperar com seu desenvolvimento.
Possui mais de 15 anos de desenvolvimento ativo e uma arquitetura amplamente aprovada que
ganhou uma forte reputação devido a sua confiabilidade e integridade dos dados. Ele roda em
todos os principais sistemas operacionais. Tem todo o apoio para chaves estrangeiras, joins,
views, triggers, e procedimentos armazenados (em vários idiomas). Ela inclui a maioria dos tipos
de dados SQL92 e SQL99, incluindo INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR,
DATE INTERVAL, e TIMESTAMP. Também suporta armazenamento de objetos grandes
binários, incluindo imagens, sons ou vídeos. Possui também uma documentação excepcional.
28
2.6.3. ORACLE
O Oracle é um SGBD (sistema gerenciador de banco de dados) que surgiu no fim dos
anos 70, quando Larry Ellison vislumbrou uma oportunidade que outras companhias não haviam
percebido, quando encontrou uma descrição de um protótipo funcional de um banco de dados
relacional e descobriu que nenhuma empresa tinha se empenhado em comercializar essa
tecnologia.
Ellison e os co-fundadores da Oracle Corporation, Bob Miner e Ed Oates, perceberam
que havia um tremendo potencial de negócios no modelo de banco de dados relacional tornando
assim a maior empresa de software empresarial do mundo.
O SGBD da Oracle é líder de mercado. O Oracle 9i foi pioneiro no suporte ao modelo
web. O Oracle 10g, mais recente, se baseia na tecnologia de grid. Recentemente fora lançado o
Oracle 11g que veio com melhorias em relação ao Oracle 10g.
Além da base de dados, a Oracle desenvolve uma suíte de desenvolvimento chamada de
Oracle Developer Suite, utilizada na construção de programas de computador que interagem com
a sua base de dados.
A Oracle também criou a linguagem de programação PL/SQL, utilizada no
processamento de transações.
2.7. PROGRAMAÇÃO ORIENTADA A OBJETOS
A orientação a objetos, também conhecida como POO (Programação Orientada a
Objetos) é um paradigma de análise, projeto e programação de sistemas de software baseado na
composição e interação entre diversas unidades de software chamadas de objetos.
Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de
programação.
A análise e projeto orientados a objetos têm como meta identificar o melhor conjunto de
objetos para descrever um sistema de software. O funcionamento deste sistema se dá através do
relacionamento e troca de mensagens entre estes objetos.
Na programação orientada a objetos, implementa-se um conjunto de classes que
definem os objetos presentes no sistema de software. Cada classe determina o comportamento
29
(definidos nos métodos) e estados possíveis (atributos) de seus objetos, assim como o
relacionamento com outros objetos. No projeto em questão será utilizada a orientação ao objeto.
30
CAPÍTULO III
3. SISTEMA PROPOSTO
O produto Sistema de Gerenciamento e Padronização de Documentos Eletrônicos visa
facilitar a criação de um documento a ser moldado de acordo com o padrão adotado pela
organização e gerenciamento dos mesmos, que serão utilizados por usuários de uma organização.
Em alguns modelos de GED, o processo de criação do arquivo eletrônico é obtido
através da digitalização do mesmo, mas no produto em questão não haverá digitalização do
documento, ele será todo eletrônico desde o momento de sua criação.
Neste projeto o sistema não receberá dados do meio físico, todo o processo para criação
e gerenciamento do documento partirá do próprio sistema, tornando o processo mais ágil.
3.1. BENEFÍCIOS DO PRODUTO
•
Facilidade na localização do documento – reduz o tempo pesquisa, proporcionando
maior agilidade nos processo da organização;
•
Segurança contra deterioração ou por extravio do meio físico – sem a perda do
documento não haverá a o desperdício de tempo para refazer o mesmo;
•
Acessar o documento por vários usuários ao mesmo tempo – maior agilidade na
disseminação da informação contida em um documento;
•
Economia de espaço físico para armazenamento dos documentos – reduz o custo
financeiro, com a manutenção de grandes áreas destinadas ao arquivamento dos
mesmos;
•
Agilidade na atualização dos documentos – economia de tempo;
•
Formatação automatiza – garantia de um documento padronizado de acordo com as
normas da empresa;
•
Segurança através de códigos de acessos – maior confiabilidade da documentação
eletrônica;
31
•
Eliminação de papel.
3.2. DIAGRAMA DE CONTEXTO
O Sistema de Gerenciamento e Padronização de Documentos Eletrônicos deve ser
desenvolvido de modo que possibilite o gestor do sistema modelar o documento padronizando-o.
E este mesmo documento modelado anteriormente poderá ser utilizado pelos usuários do sistema
para gerar, alterar e consultar documentos que estarão armazenados no banco de dados. As
configurações do documento modelado deverão ser salvas no banco de dados, como pode ser
observado na Figura 3.1.
Figura 3.1 – Diagrama de contexto.
3.3. USUÁRIOS
Para este sistema haverá quatro tipos de usuários com níveis de acessos diferentes:
32
•
Master – será o responsável pelos documentos, terá acesso a qualquer módulo do
sistema, gestão de usuários, gestão do modelo padrão, gestão do documento, gestão
do arquivo morto e impressão.
•
Gestor – gestão de usuários, gestão do modelo padrão, gestão do documento e
impressão;
•
Digitador – terá uma serie de restrições, mas ainda assim terá liberdade para gestão
do documento, limitado apenas a criar, alterar e imprimir;
•
Consultor – somente terá acesso a fazer pesquisas eletrônicas e impressão.
3.4. INTERFACE DE HARDWARE
O projeto não utilizará nenhum equipamento em especial.
3.5. INTERFACE DE SOFTWARE
Para a máquina servidora deverá constar os seguintes softwares:
•
Sistema Operacional – Windows 2000;
•
Banco de dados – Postgres.
E para os periféricos:
•
Sistema Operacional – Windows XP;
•
Framework 2.0;
•
Driver ODBC 8.1 – para o postgres.
3.6. RESTRIÇÕES
O projeto será desenvolvido por dois estudantes de Engenharia da Computação com
prazo determinado por dois períodos no ano de 2008 limitados por seus horários empregatícios e
aulas de preleção, de acordo com as normas de Trabalho de Conclusão de Curso da Universidade
Católica de Goiás.
Não gerencia documentos que não foram criados pelo próprio sistema, pois este trabalha
com modelos pré-modelados por um gestor, para que tenha um padrão em todos os documentos.
33
3.7. REQUISITOS ESPECÍFICOS
3.7.1. REQUISITOS FUNCIONAIS
•
Deixar em aberto para o usuário responsável, a possibilidade de criar vários modelos
diferentes de documentos;
•
Após a modelagem, o usuário poderá escolher um modelo de documento e inserir as
informações do documento em cima do modelo escolhido. O documento não mais
será produzido diretamente em um editor de texto, e sim em vários campos
relacionados ao modelo gerado, automatizando a formatação do texto.
•
Após o documento ser gerado será indexado um código seqüencial para o controle
de localização, e organização do documento.
•
Permitir que vários usuários possam, de acordo com o nível de permissão, consultar
o mesmo documento no mesmo instante.
•
Em caso de alteração de um documento, manter o documento original inalterado e
criar uma cópia onde poderão ser feitas novas alterações. De forma que possa ser
visto um histórico das alterações em cada documento.
•
Restringir acesso ao documento enquanto o mesmo está em estado de alteração.
•
Liberar o documento para uso.
•
Divulgar o documento sempre que necessário, desde que o documento já esteja
liberado.
•
Imprimir documento, desde que o documento já esteja liberado.
•
O usuário poderá enviar um documento para o arquivo morto, sempre que achar
necessário;
•
Recuperar um documento do arquivo morto, conforme a necessidade;
•
O Master poderá eliminar o documento do arquivo morto;
•
Consultar no arquivo morto.
•
Criar níveis de permissão do usuário para a manipulação dos documentos;
34
3.7.1.1. CASOS DE USO
Os casos de usos, aqui apresentados foram desenvolvidos de acordo com os padrões
UML descritos em Larman [3] e desenhados utilizando a ferramenta case Jude Community .
3.7.1.1.1. DIAGRAMAS DOS CASOS DE USO
Figura 3.2 – Diagrama de caso de uso acesso ao sistema.
Observando-se figura 3.2, verifica-se como funcionará o acesso e o bloqueio dos
usuários com relação às telas do sistema.
Figura 3.3 – Diagrama de caso de uso gerenciamento de usuários.
Observando-se a figura 3.3, verifica-se como o usuário poderá cadastrar, alterar e
remover outros usuários.
35
Figura 3.4 – Diagrama de caso de uso modelagem do documento.
Observando-se a figura 3.4, verifica-se que somente os usuários master ou gestor,
poderão gerenciar a modelagem do documento, criando, alterando, removendo, salvando e
registrando-o.
Figura 3.5 – Diagrama de caso de uso gerenciamento do documento.
Observando-se a figura 3.5, verifica-se como os usuários master ou gestor e digitador
poderão gerenciar o documento, porém o usuário digitador não terá privilégios para remover um
documento.
36
Figura 3.6 – Diagrama de caso de uso consultar documento.
Observando-se a figura 3.6, verifica-se que todos os usuários poderão consultar ou
imprimir os documentos.
Figura 3.7 – Diagrama de caso de uso Arquivo Morto.
Observando-se a figura 3.7, verifica-se que somente o usuário master poderá realizar
operações referentes ao arquivo morto.
37
3.7.1.1.2. DESCRIÇÃO DOS CASOS DE USO COMPLETO
Caso de uso CDU1: Acessar sistema
Escopo: Libera acesso ao sistema, de acordo com o nível de usuário.
Ator principal: Master.
Interessados e interesses:
− Usuário: Deseja acessar o sistema.
− Empresa: Que o usuário acesse somente o que lhe foi permitido.
Pré-condições: Usuário devidamente cadastrado.
Pós-condições: Telas liberadas de acordo com o nível de acesso.
Fluxo básico:
1. Sistema limpa campos de usuário e senha.
2. Sistema solicita usuário e senha.
3. Usuário informa usuário e senha.
4. Sistema faz uma consulta para verificar se o usuário existe.
5. Sistema verifica se usuário e senha são validos.
6. Sistema permite o acesso.
Fluxos alternativos:
*a. Campo usuário vazio.
1. Sistema informa que o campo usuário está vazio.
*b. Campo senha está vazio.
1. Sistema informa que o campo senha está vazio.
*c. Usuário não existe.
1. Sistema informa que o usuário não é cadastrado.
2. Sistema limpa o campo do usuário.
3. Usuário informa novamente qual é o seu usuário.
*d. Usuário inválido.
1. Sistema informa que o usuário é invalido.
2. Sistema limpa o campo do usuário.
3. Usuário informa novamente qual é o seu usuário.
38
*e. Senha inválida.
1. Sistema informa que a senha é invalida.
2. Sistema limpa o campo da senha.
3. Usuário informa novamente qual é a sua senha.
*f. A qualquer momento o usuário solicita o cancelamento do acesso antes que seja
efetuado.
1. Sistema mantém o acesso do usuário bloqueado.
2. Sistema fecha tela de acesso.
Caso de uso CDU2: Bloquear sistema
Escopo: Bloqueia todo o acesso ao sistema.
Ator principal: Master.
Interessados e interesses:
− Empresa: Manter o sistema inacessível aos usuários não cadastrados.
Pré-condições: O sistema precisa estar desbloqueado.
Pós-condições: Sistema bloqueado.
Fluxo básico:
1. Usuário solicita o bloqueio do sistema.
2. Sistema bloqueia e minimiza todas as telas abertas.
Fluxos alternativos:
*a. Em caso de falha ao bloquear.
1. Aborta o sistema.
2. Informa o motivo do sistema está sendo abortado.
Caso de uso CDU3: cadastrar usuário
Escopo: Registra novos usuários.
Ator principal: Gestor.
Interessados e interesses:
39
− Usuário: Deseja ser cadastrado, para obter acesso ao sistema.
− Empresa: Deseja ter o controle sobre quem está acessando o sistema.
Pré-condições:
− Não pode haver mais de um cadastro para o mesmo usuário.
− O sistema precisa estar desbloqueado.
− Apenas usuários “Master” e “Gestor”, poderão efetuar cadastros de usuários.
Fluxo básico:
1. Usuário acessa tela de cadastro.
2. Sistema limpa todos os campos da tela de cadastro.
3. Usuário (Master ou Gestor) inicia um novo cadastro.
4. Usuário novo informa os dados (nome, CPF, usuário, senha, contra-senha, nível,
etc.).
5. Sistema verifica se senha e contra-senha são iguais, e se não estão vazias.
6. Sistema valida CPF.
7. Sistema verifica pelo CPF se novo usuário já existe.
8. Sistema registra novo usuário.
9. Sistema registra qual usuário, data e hora que efetivou o cadastro.
10. Usuário recebe confirmação de cadastro.
Fluxos alternativos:
*a. Senha diferente de contra-senha.
1. Usuário recebe informação de que a senha e contra-senha estão diferentes.
2. Sistema limpa campos da senha e da contra-senha.
*b. Campo senha não está preenchido.
1. Sistema informa que o campo senha está vazio.
*c. Campo CPF está vazio.
1. Sistema informa que o campo CPF está vazio.
*d. Campo nome está vazio.
1. Sistema informa que o campo nome está vazio.
*e. Campo usuário está vazio.
1. Sistema informa que o campo usuário está vazio.
*f. CPF inválido.
40
1. Sistema informa que o CPF é invalido.
2. Sistema limpa o campo do CPF para inserir novamente.
*g. A qualquer momento o usuário solicita que tela de cadastro seja finalizada.
1. Sistema pergunta se usuário deseja salvar os dados presentes na tela.
2. Usuário informa opção desejada.
a. Opção escolhida foi salvar.
1. Sistema continua a partir do passo 5 do fluxo básico.
b. Opção escolhida foi descartar dados.
1. Sistema encerra tela de cadastro.
*h. A qualquer momento usuário solicita novo cadastro antes de finalizar o cadastro
atual.
1. Sistema pergunta se usuário deseja continuar cadastro atual.
2. Usuário informa opção desejada.
a. Opção escolhida foi continuar.
1. Usuário continua cadastro atual.
b. Opção escolhida foi começar um novo cadastro.
1. Sistema continua a partir do passo 2 do fluxo básico.
*i. Usuário já está cadastrado.
1. Sistema informa que o usuário já está cadastrado.
2. Sistema limpa o campo do CPF.
3. Sistema continua a partir do passo 4 do fluxo básico.
*j. Falha de registro no banco de dados.
1. Sistema informa qual foi a falha ocorrida.
2. Sistema continua a partir do passo 4 do fluxo básico.
Caso de uso CDU4: alterar usuário
Escopo: Alterar cadastro de usuários.
Ator principal: Gestor.
Interessados e interesses:
− Usuário: Deseja atualizar seu cadastro.
41
Pré-condições:
− Usuário deverá estar cadastrado no sistema.
− O sistema precisa estar desbloqueado.
− Apenas usuários “Master” e “Gestor”, poderão alterar os cadastros de usuários.
Fluxo básico:
1. Acessa tela de cadastro.
2. Sistema limpa os campos da tela.
3. Usuário informa quem será alterado.
4. Sistema verifica se usuário existe.
5. Sistema mostra os dados do usuário escolhido.
6. Sistema solicita os novos dados.
7. Usuário informa os novos dados.
8. Sistema verifica se senha e contra-senha são iguais, e se não estão vazias.
9. Sistema valida CPF.
10. Sistema verifica pelo CPF se novo usuário já existe.
11. Sistema registra dados.
12. Sistema registra qual usuário, data e hora que efetivou a alteração.
13. Usuário recebe confirmação de alteração do cadastro.
14. Sistema limpa os campos da tela de cadastro.
Fluxos alternativos:
*a. Senha diferente de contra-senha.
1. Usuário recebe informação de que a senha e contra-senha estão diferentes.
2. Sistema limpa campos da senha e da contra-senha.
*b. Campo senha não está preenchido.
1. Sistema informa que o campo senha está vazio.
*c. Campo CPF está vazio.
1. Sistema informa que o campo CPF está vazio.
*d. Campo nome está vazio.
1. Sistema informa que o campo nome está vazio.
*e. Campo usuário está vazio.
1. Sistema informa que o campo usuário está vazio.
42
*f. CPF inválido.
1. Sistema informa que o CPF é invalido.
2. Sistema limpa o campo do CPF para inserir novamente.
*g. A qualquer momento o usuário solicita que tela de cadastro seja finalizada.
1. Sistema pergunta se usuário deseja salvar os dados presentes na tela.
2. Usuário informa opção desejada.
a. Opção escolhida foi salvar.
1. Sistema continua a partir do passo 7 do fluxo básico.
b. Opção escolhida foi descartar dados.
1. Sistema encerra tela de cadastro.
*h. A qualquer momento usuário solicita novo cadastro antes de finalizar o cadastro
atual.
1. Sistema pergunta se usuário deseja continuar alteração de cadastro atual.
2. Usuário informa opção desejada.
a. Opção escolhida foi continuar.
1. Usuário continua cadastro atual.
b. Opção escolhida foi começar um novo cadastro.
1. Sistema continua a partir do passo 2 do fluxo básico.
*i. Usuário já está cadastrado.
1. Sistema informa que o usuário já está cadastrado.
2. Sistema limpa o campo do CPF.
3. Sistema continua a partir do passo 6 do fluxo básico.
*j. Falha de registro no banco de dados.
1. Sistema informa qual a falha ocorrida.
2. Sistema continua a partir do passo 6 do fluxo básico.
Caso de uso CDU5: remover usuário
Escopo: Remove o usuário desde que ele não tenha nenhum vinculo com os dados do
sistema.
Ator principal: Gestor.
43
Interessados e interesses:
− Usuário: Deseja remover cadastro do sistema.
Pré-condições:
− Usuário a ser removido deverá estar cadastrado no sistema.
− O sistema precisa estar desbloqueado.
− Apenas usuários “Master” e “Gestor”, poderão remover os cadastros de usuários.
Fluxo básico:
1. Usuário acessa tela de cadastro.
2. Sistema limpas os campos da tela.
3. Usuário informa quem será removido.
4. Sistema verifica se o usuário a ser removido está cadastrado.
5. Sistema mostra os dados do usuário.
6. Usuário solicita a remoção do cadastro.
7. Sistema solicita confirmação para remoção.
8. Sistema remove usuário.
9. Sistema registra qual usuário, data e hora que efetivou a remoção.
10. Sistema informa que usuário foi removido.
Fluxos alternativos:
*a. Usuário não está cadastrado.
1. Sistema informa que usuário não está cadastrado ou já foi removido.
2. Sistema continua a partir do passo 2 do fluxo básico.
*b. Sistema não consegue encontrar as informações do usuário escolhido.
1. Sistema informa que teve problema para buscar os dados do usuário.
2. Sistema continua a partir do passo 2 do fluxo básico.
*c. Na resposta de confirmação usuário opta por não remover.
1. Mantêm os dados do usuário na tela.
2. Aguarda próxima opção do usuário.
*d. Erro no momento da remoção.
1. Sistema informa que não conseguiu remover o usuário.
2. Sistema continua a partir do passo 2 do fluxo básico.
44
Caso de uso CDU06: consultar usuário
Escopo: Onde o sistema acessa uma lista de cadastro de usuários e retorna os dados do
usuário em questão.
Ator principal: Sistema.
Interessados e interesses:
− Usuário: Deseja saber seus dados.
Pré-condições:
− O sistema precisa estar desbloqueado.
Pós-condições:
− Retorna os dados do usuário.
Fluxo básico:
1. Usuário informa o critério para consulta (CPF ou nome).
2. Sistema pesquisa o usuário em uma lista de usuários já cadastrados.
3. Sistema retorna os dados do usuário encontrado.
Fluxos alternativos:
*a. Usuário não foi encontrado na lista.
1. Sistema informa que usuário não está cadastrado.
Caso de uso CDU07: criar modelo
Escopo: Cria um novo modelo, definindo os tipos diferentes de documentos prémoldados.
Ator principal: Gestor.
Interessados e interesses:
− Empresa: Padronizar os documentos da empresa.
Pré-condições:
− Apenas usuários “Master” e “Gestor”, poderão fazer a modelagem do documento.
− O sistema precisa estar desbloqueado.
Fluxo básico:
45
1. Usuário acessa a tela de modelagem.
2. Sistema limpa toda a tela.
3. Usuário informa dados descritivos do modelo (id, nome, descrição, etc.).
4. Usuário adiciona campo.
1. Sistema cria o campo com nome padrão e disponibiliza o campo em uma lista de
campos disponíveis.
2. Usuário informa as propriedades do campo (nome, tipo de letra, tamanho da
letra, etc.).
3. Sistema verifica se foi informado o nome do campo.
4. Sistema verifica se já existe campo com este nome no mesmo modelo.
5. Usuário continua repetindo estes procedimentos até adicionar todos os campos
desejados.
5. Usuário move o campo escolhido da lista de campos disponíveis, posicionando-o no
local desejado da área modelagem.
6. Sistema registra qual usuário, data e hora que criou o modelo.
Fluxos alternativos:
*a. Ocorrer erro durante a criação do campo.
1. Sistema informa que ocorreu o erro.
2. Sistema retorna ao passo 4 do fluxo básico.
*b. O nome do campo não foi informado.
1. Sistema informa que o nome do campo ainda não foi informado.
2. Sistema solicita que seja informado o nome do campo.
3. Sistema continua a partir do item 4.2 do fluxo básico.
*c. Já existe um campo cadastrado no modelo com o mesmo nome.
1. Sistema informa que o campo já existe.
2. Continua a partir do passo 4 do fluxo básico.
*d. Ocorreu um erro no momento em que o campo é movimentado.
1. Sistema informa o erro ocorrido.
2. Sistema retorna o campo para a lista de campos disponíveis.
3. Sistema continua a partir do passo 5 do fluxo básico.
46
*e. A qualquer momento usuário fecha ou solicita novo modelo antes de finalizar o
modelo atual.
1. Sistema pergunta se usuário deseja continuar a modelagem atual.
2. Usuário informa opção desejada.
a. Opção escolhida foi continuar.
1. Usuário continua modelagem atual.
b. Opção escolhida foi não continuar.
2. Sistema continua a partir do passo 2 do fluxo básico.
Caso de uso CDU08: consultar modelo
Escopo: Onde o sistema acessa uma lista de modelos já cadastrados e retorna os dados
do modelo em questão.
Ator principal: Sistema.
Interessados e interesses:
− Sistema: Deseja saber se o modelo existe para não haja duplicidade.
Pré-condições:
− O sistema precisa estar desbloqueado.
Pós-condições:
− Retorna os dados do modelo.
Fluxo básico:
1. Usuário informa o critério para consulta (Id ou nome).
2. Sistema pesquisa em uma lista de modelos já salvos.
3. Sistema retorna os dados do modelo encontrado.
Fluxos alternativos:
*a. Modelo não foi encontrado na lista.
1. Sistema informa que modelo não está cadastrado.
47
Caso de uso CDU09: alterar modelo
Escopo: Onde o usuário irá alterar o modelo do documento, desde que nenhum
documento tenha sido criado a partir do modelo a ser alterado.
Ator principal: Gestor.
Interessados e interesses:
− Usuário: Poderá alterar um modelo, para que não haja a necessidade de excluir e
criar outro.
Pré-condições:
− Apenas usuários “Master” e “Gestor”, poderão fazer alterações no modelo.
− O sistema precisa estar desbloqueado.
− O modelo precisa existir.
− Não poderá existir nenhum documento produzido a partir do modelo a ser alterado.
Fluxo básico:
1. Usuário acessa a tela de modelagem.
2. Sistema limpa a tela.
3. Usuário informa o modelo.
4. Sistema verifica se não existe nenhum documento produzido a partir do modelo a
ser alterado.
5. Sistema busca dados do modelo.
6. Usuário informa os novos dados descritivos do modelo.
7. Usuário adiciona novos campos.
1. Sistema cria o campo com nome padrão e disponibiliza o campo em uma lista de
campos disponíveis.
2. Usuário informa as propriedades do campo (nome, tipo de letra, tamanho da
letra, etc.).
3. Sistema verifica se foi informado o nome do campo.
4. Sistema verifica se já existe campo com este nome no mesmo modelo.
5. Usuário continua repetindo estes procedimentos até adicionar todos os campos
desejados.
8. Usuário altera campos do modelo.
48
1. Usuário seleciona o campo desejado.
2. Sistema informa as propriedades do campo escolhido.
3. Usuário informa as novas propriedades do campo.
4. Sistema verifica se foi informado o nome do campo.
5. Sistema verifica se já existe campo com este nome no mesmo modelo.
6. Usuário continua repetindo estes procedimentos até alterar todos os campos
desejados.
9. Usuário exclui campos do modelo.
1. Usuário seleciona o campo desejado.
2. Sistema informa as propriedades do campo.
3. Usuário confirma exclusão.
4. Sistema exclui o campo.
10. Usuário movimenta os campos na tela alterando-os de posição de acordo com suas
necessidades.
11. Sistema registra qual usuário, data e hora que efetivou a alteração.
Fluxos alternativos:
*a. Ocorrer erro durante a criação do campo.
1. Sistema informa que ocorreu o erro.
2. Sistema retorna ao passo 7 do fluxo básico.
*b. Ocorrer erro durante a alteração do campo.
1. Sistema informa que ocorreu o erro.
2. Sistema retorna ao passo 8 do fluxo básico.
*c. Ocorrer erro durante a remoção do campo.
1. Sistema informa que ocorreu o erro.
2. Sistema retorna ao passo 9 do fluxo básico.
*d. O nome do campo não foi informado
1. Sistema informa que o nome do campo ainda não foi informado.
2. Sistema solicita que seja informado o nome do campo.
*e. Já existe um campo cadastrado no modelo com o mesmo nome.
1. Sistema informa que o campo já existe.
*f. Existe um documento produzido a partir do modelo desejado.
49
1. Sistema informa que não poderá alterar.
2. Sistema continua a partir do passo 2 do fluxo básico.
*g. Ocorreu um erro no momento em que o campo é movimentado
1. Sistema informa o erro ocorrido.
2. Sistema retorna o campo para a lista de campos disponíveis.
3. Sistema continua a partir do passo 10 do fluxo básico.
*h. A qualquer momento usuário fecha ou solicita novo modelo antes de finalizar a
alteração do modelo.
1. Sistema pergunta se usuário deseja continuar alteração do modelo atual.
2. Usuário informa opção desejada.
a. Opção escolhida foi continuar.
1. Usuário continua alteração do modelo atual.
b. Opção escolhida foi não continuar.
3. Sistema continua a partir do passo 2 do fluxo básico.
Caso de uso CDU10: remover modelo
Escopo: O modelo pode ser removido desde que nenhum documento tenha sido
produzido a partir do modelo a ser removido.
Ator principal: Gestor.
Interessados e interesses:
− Usuário: Poderá remover o modelo que não tenha sido aprovado.
Pré-condições:
− Apenas usuários “Master” e “Gestor”, poderão remover um modelo.
− O sistema precisa estar desbloqueado.
− O modelo precisa existir.
− Não poderá existir nenhum documento produzido a partir do modelo a ser removido.
Fluxo básico:
1. Usuário acessa tela de modelagem.
2. Sistema limpas os campos da tela.
3. Usuário informa o modelo para ser removido.
50
4. Sistema verifica se o modelo a ser removido está cadastrado.
5. Sistema verifica se não existe documento produzido a partir do modelo desejado.
6. Sistema mostra os dados do modelo.
7. Usuário solicita a remoção do modelo.
8. Sistema solicita confirmação para remoção.
9. Sistema remove modelo.
10.
Sistema registra qual usuário, data e hora que efetivou a remoção.
11.
Sistema informa que modelo foi removido.
Fluxos alternativos:
*a. Modelo não está cadastrado.
1. Sistema informa que modelo não existe.
2. Sistema continua a partir do passo 2 do fluxo básico.
*b. Sistema não consegue encontrar as informações do modelo escolhido.
1. Sistema informa que teve problema para buscar os dados do modelo.
2. Sistema continua a partir do passo 2 do fluxo básico.
*c. Existe um documento produzido a partir do modelo desejado.
1. Sistema informa que documento não pode ser removido.
2. Sistema continua a partir do passo 2 do fluxo básico.
*d. Na resposta de confirmação usuário opta por não remover.
1. Mantêm os dados do modelo na tela.
2. Aguarda próxima opção do usuário.
*e. Erro no momento da remoção.
3. Sistema informa que não conseguiu remover o modelo.
4. Sistema continua a partir do passo 2 do fluxo básico.
Caso de uso CDU11: liberar modelo
Escopo: Libera o modelo para poder dar continuidade na produção do documento.
Ator principal: Gestor.
Interessados e interesses:
− Usuário: Quando estiver pronto o usuário poderá validar antes de liberá-lo para uso.
51
Pré-condições:
− Apenas usuários “Master” e “Gestor”, poderão liberar o modelo.
− O sistema precisa estar desbloqueado.
− O modelo precisa estar registrado no banco.
Fluxo básico:
1. Usuário informa o modelo desejado.
2. Sistema verifica se foi informado o modelo
3. Sistema verifica se o modelo existe.
4. Sistema verifica se o modelo não está liberado.
5. Sistema libera o modelo para uso.
6. Sistema registra qual usuário, data e hora que liberou o modelo.
7. Sistema informa que o modelo está liberado.
Fluxos alternativos:
*a. O modelo não foi informado.
1. Sistema informa que faltou informar o modelo.
2. Sistema solicita que seja informado o modelo.
*b. O modelo desejado não existe.
1. Sistema informa que o modelo não existe.
2. Sistema solicita que seja informado outro modelo.
Caso de uso CDU12: criar documento
Escopo: Insere os dados do novo documento de acordo com o modelo escolhido.
Ator principal: Digitador.
Pré-condições:
− Apenas usuários “Master”, “Gestor” e “Digitador”, poderão criar o documento.
− O sistema precisa estar desbloqueado.
− O modelo precisa estar liberado.
Fluxo básico:
1. Sistema limpa a tela.
2. Usuário informa um nome para o documento.
52
3. Sistema verifica se não existe um documento com o mesmo nome.
4. Usuário informa o modelo desejado a partir de uma lista de modelos já registrados e
liberados.
5. Sistema preenche a tela com os campos do modelo escolhido.
6. Usuário preenche os campos do modelo.
7. Usuário salva o documento.
8. Sistema salva as informações dos campos.
9. Sistema salva as informações do documento.
10. Sistema registra qual usuário, data e hora que criou o documento.
11. Sistema informa que novo documento foi criado.
Fluxos alternativos:
*a. Já existe um documento com o nome desejado.
1. Sistema informa que já existe documento.
2. Sistema continua a partir do passo 4 do fluxo básico.
*b. Sistema não consegue buscar os campos do modelo
1. Sistema informa o erro.
*c. O modelo desejado não existe.
1. Sistema informa que o modelo não existe.
2. Sistema solicita que seja informado outro modelo.
Caso de uso CDU13: consultar documento
Escopo: Onde o sistema acessa uma lista de documentos já registrados e retorna os
dados do documento em questão.
Ator principal: Consultor.
Interessados e interesses:
− Usuário: Deseja obter as informações do documento.
Pré-condições:
− O sistema precisa estar desbloqueado.
Pós-condições:
− Retorna os dados do documento.
53
Fluxo básico:
1. Usuário informa o critério para consulta (Id ou nome).
2. Sistema pesquisa em uma lista de documentos já registrados e liberados.
3. Sistema retorna os dados do documento encontrado.
Fluxos alternativos:
*a. Documento não foi encontrado na lista.
1. Sistema informa que documento não está cadastrado.
Caso de uso CDU14: alterar documento
Escopo: É feito uma copia do documento escolhido, onde as alterações serão realizadas
na copia, deixando a original inalterada. Para que no futuro possa ser visualizada a diferença
entre cada versão do documento já alterado.
Ator principal: Digitador.
Interessados e interesses:
− Usuário: Poderá alterar o documento, para que não haja a necessidade de excluir e
criar outro.
Pré-condições:
− Apenas usuários “Master”, “Gestor” e “Digitador”, poderão fazer alterações no
modelo.
− O sistema precisa estar desbloqueado.
− O documento precisa existir.
Fluxo básico:
1. Sistema limpa a tela.
2. Usuário informa o documento.
3. Sistema verifica se existe o documento.
4. Sistema busca os dados do documento.
5. Sistema cria um copia idêntica do documento incrementando a versão que será
alterada.
6. Sistema mostra na tela os dados do documento.
7. Usuário informa os novos dados do documento (nome, id, descrição, etc.).
54
8. Usuário informa os novos dados dos campos.
9. Usuário salva documento.
10. Sistema valida os dados.
11. Sistema verifica se já existe documento com o mesmo nome.
12. Sistema salva dados dos campos.
13. Sistema salva dados do documento.
14. Sistema registra qual usuário, data e hora que alterou o documento.
15. Sistema informa que documento foi alterado.
Fluxos alternativos:
*a. Não existe o documento.
1. Sistema informa que não poderá alterar.
2. Sistema continua a partir do passo 1 do fluxo básico.
*b. A qualquer momento usuário fecha ou solicita novo documento antes de finalizar a
alteração do documento.
1. Sistema pergunta se usuário deseja continuar alteração do documento atual.
2. Usuário informa opção desejada.
a. Opção escolhida foi continuar.
1. Usuário continua alteração do documento atual.
b. Opção escolhida foi não continuar.
4. Sistema continua a partir do passo 1 do fluxo básico.
Caso de uso CDU15: remover documento
Escopo: Onde o usuário irá remover o documento.
Ator principal: Master.
Interessados e interesses:
− Usuário: Poderá remover os documentos considerados inutilizados para obter mais
disponibilidade de espaço.
Pré-condições:
− Apenas usuário “Master”, poderá remover documento.
− O sistema precisa estar desbloqueado.
55
− O documento precisa existir.
Fluxo básico:
1. Sistema limpa a tela.
2. Usuário informa o documento.
3. Sistema verifica se existe o documento.
4. Sistema busca e informa os dados do documento.
5. Usuário confirma exclusão.
6. Sistema remove documento.
7. Sistema registra qual usuário, data e hora que removeu o documento.
8. Sistema informa que o documento foi removido.
Fluxos alternativos:
*a. Não existe o documento.
1. Sistema informa que não poderá remover.
2. Sistema continua a partir do passo 1 do fluxo básico.
Caso de uso CDU16: liberar documento
Escopo: Libera o documento para que os demais usuários possam utilizá-los conforme
as atribuições de cada um.
Ator principal: Master.
Interessados e interesses:
− Usuário: Controlar as disponibilidades do documento.
Pré-condições:
− Apenas usuário “Master”, irá liberar o documento.
− O sistema precisa estar desbloqueado.
Fluxo básico:
1. Usuário informa o documento que deseja liberar.
2. Sistema verifica se o documento existe.
3. Sistema verifica se o documento não está liberado.
4. Sistema informa os dados do documento na tela.
56
5. Usuário escolhe quais os usuários que terão permissão de uso em relação ao
documento.
6. Usuário confirma liberação.
7. Sistema libera documento.
8. Sistema registra qual usuário, data e hora que liberou o documento.
9. Sistema informa que o documento foi liberado com sucesso.
Fluxos alternativos:
*a. O documento informado não existe.
1. Sistema informa que não existe.
2. Sistema solicita que seja informado outro documento.
*b. Documento já consta como liberado.
1. Sistema informa que o documento desejado já está liberado.
Caso de uso CDU17: divulgar documento
Escopo: Após o sistema liberar o documento, o sistema irá enviar e-mail para cada
usuário selecionado para visualizar o documento.
Ator principal: Digitador.
Interessados e interesses:
− Usuário: Informa aos outros usuários que o documento está pronto para ser
utilizado.
Pré-condições:
− Apenas usuários “Master”, “Gestor” e “Digitador”, irão divulgar o documento.
− O documento precisa estar liberado.
− O sistema precisa estar desbloqueado.
Fluxo básico:
1. Usuário informa o documento que deseja divulgar.
2. Sistema verifica se o documento existe.
3. Sistema verifica se o documento está liberado.
4. Sistema envia e-mail para os usuários com permissão de uso do documento.
5. Sistema registra qual usuário, data e hora que divulgou o documento.
57
6. Sistema informa que o documento foi divulgado com sucesso.
Fluxos alternativos:
*a. O documento informado não existe.
1. Sistema informa que não existe.
2. Sistema solicita que seja informado outro documento.
*b. Sistema não consegue enviar e-mail.
1. Sistema informa que não conseguiu fazer a divulgação.
*c. Documento não consta como liberado
1. Sistema informa que o documento desejado não está liberado.
Caso de uso CDU18: imprimir documento
Escopo: Impressão do documento.
Ator principal: Consultor.
Interessados e interesses:
− Usuário: Poder enviar para outras empresas ou setores que não utilizam o sistema.
Pré-condições:
− O documento precisa estar liberado para o usuário que deseja imprimir o
documento.
− O sistema precisa estar desbloqueado.
Fluxo básico:
1. Usuário informa o documento que deseja imprimir.
2. Sistema verifica se o documento existe.
3. Sistema verifica se o documento está liberado.
4. Sistema imprime documento.
Fluxos alternativos:
*a. O documento informado não existe.
1. Sistema informa que não existe.
2. Sistema solicita que seja informado outro documento.
*b. Documento não consta como liberado
1. Sistema informa que o documento desejado não está liberado.
58
Caso de uso CDU19: mover documento para arquivo morto
Escopo: Enviar para arquivo morto os documentos que atualmente não estão em uso.
Ator principal: Master.
Interessados e interesses:
− Master: Poder diminuir a carga de documento no sistema.
Pré-condições:
− O sistema precisa estar desbloqueado.
Fluxo básico:
1. Usuário informa o documento que deseja enviar para arquivo morto.
2. Sistema verifica se o documento existe.
3. Usuário confirma o envio.
4. Sistema envia para o arquivo morto
5. Sistema registra qual usuário, data e hora que enviou o documento.
6. Sistema informa que o documento foi enviado para o arquivo morto.
Fluxos alternativos:
*a. O documento informado não existe
1. Sistema informa que não existe.
2. Sistema solicita que seja informado outro documento.
Caso de uso CDU20: recuperar documento do arquivo morto
Escopo: Recuperar documentos do arquivo morto, para que possam ser usados
novamente.
Ator principal: Master.
Interessados e interesses:
− Master: Disponibilizar um documento considerado inativo.
Pré-condições:
− O sistema precisa estar desbloqueado.
− Documento precisa estar no arquivo morto.
59
Fluxo básico:
1. Usuário informa o documento que deseja recuperar.
2. Sistema verifica se o documento existe no arquivo morto.
3. Usuário confirma a recuperação.
4. Sistema verifica se já existe documento com o mesmo nome nos arquivos ativos.
5. Sistema recupera o documento.
6. Sistema registra qual usuário, data e hora que recuperou o documento.
7. Sistema informa que o documento foi recuperado.
Fluxos alternativos:
*a. O documento informado não existe no arquivo morto.
1. Sistema informa que não existe.
2. Sistema solicita que seja informado outro documento.
*b. Já existe um documento com o mesmo nome na lista de documentos ativos.
1. Sistema informa que já existe documento com o mesmo nome.
2. Sistema solicita que seja informado um novo nome para o documento que está
sendo recuperado.
3. Usuário informa o novo nome.
Caso de uso CDU21: remover do arquivo morto
Escopo: Remove definitivamente do sistema o documento.
Ator principal: Master.
Interessados e interesses:
− Master: Diminuir a carga de dados no arquivo morto.
Pré-condições:
− O sistema precisa estar desbloqueado.
− Documento precisa estar no arquivo morto.
Fluxo básico:
1. Usuário informa o documento que deseja remover.
2. Sistema verifica se o documento existe no arquivo morto.
3. Usuário confirma a remoção.
60
4. Sistema remove documento do arquivo morto.
5. Sistema registra qual usuário, data e hora que removeu o documento.
6. Sistema informa que o documento foi removido do arquivo morto.
Fluxos alternativos:
*a. O documento informado não existe no arquivo morto.
1. Sistema informa que não existe.
2. Sistema solicita que seja informado outro documento.
Caso de uso CDU22: consultar arquivo morto
Escopo: Onde o sistema acessa uma lista de documentos já registrados no arquivo
morto e retorna os dados do documento em questão.
Ator principal: Master.
Interessados e interesses:
− Master: Visualizar o documento do arquivo morto.
Pré-condições:
− O sistema precisa estar desbloqueado.
Fluxo básico:
1. Usuário informa o documento.
2. Sistema verifica se o documento existe no arquivo morto.
3. Sistema pesquisa em uma lista de documentos já registrados no arquivo morto.
4. Sistema retorna os dados do documento encontrado.
Fluxos alternativos:
*a. O documento informado não existe no arquivo morto.
1. Sistema informa que não existe.
2. Sistema solicita que seja informado outro documento.
3.7.2. REQUISITOS NÃO FUNCIONAIS
•
Registrar copia do documento gerado com formato pdf em HD;
•
Copia de segurança do banco de dados;
61
3.8. DIAGRAMA DE CLASSES
Figura 3.8 – Diagrama de classes.
Observando-se a figura 3.8, verifica-se a composição das classes e seus
relacionamentos.
62
3.9. DIAGRAMA DE ENTIDADES E RELACIONAMENTOS DO BANCO DE DADOS
Figura 3.9 – Diagrama de relacionamentos do bando de dados.
Observando-se a figura 3.9, verifica-se a composição das entidades do banco de dados e
seus relacionamentos, criados a partir do modelo de dados orientados ao objeto.
63
3.10.
DIAGRAMA DE SEQUÊNCIA
Figura 3.10 – DDS01 Diagrama de seqüência acessar sistema.
Observando-se a figura 3.10, verifica-se a seqüência de eventos e interações entre o
sistema e o usuário, necessários para o desbloqueio das funcionalidades do sistema de acordo
com o nível de permissão do usuário ao sistema.
64
Figura 3.11 – DDS02 Diagrama de seqüência bloquear sistema.
Observando-se a figura 3.11, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para o bloqueio das telas utilizadas por determinado usuário.
65
Figura 3.12 – DDS03 Diagrama de seqüência cadastrar usuário.
Observando-se a figura 3.12, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para se efetuar o cadastro do usuário.
66
Figura 3.13 – DDS04 Diagrama de seqüência alterar usuário.
Observando-se a figura 3.13, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para se efetuar a alteração do cadastro do usuário.
67
Figura 3.14 – DDS05 Diagrama de seqüência remover usuário.
Observando-se a figura 3.14, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para se efetuar a remoção do usuário.
68
Figura 3.15 – DDS06 Diagrama de seqüência consultar usuário.
Observando-se a figura 3.15, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para se efetuar consulta de usuários.
Figura 3.16 – DDS08 Diagrama de seqüência consultar modelo.
Observando-se a figura 3.16, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para se efetuar consulta aos modelos.
69
Figura 3.17 –DDS07 Diagrama de seqüência criar modelo.
Observando-se a figura 3.17, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para a criação do modelo.
70
Figura 3.18 – DDS09 Diagrama de seqüência alterar modelo.
Observando-se a figura 3.18, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para alterar o modelo.
71
Figura 3.19 – DDS10 Diagrama de seqüência remover modelo.
Observando-se a figura 3.19, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para se efetuar a remoção do modelo.
72
Figura 3.20 – DDS11 Diagrama de seqüência liberar modelo.
Observando-se a figura 3.20, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para liberar o modelo para uso.
73
Figura 3.21 – DDS12Diagrama de seqüência criar documento.
Observando-se a figura 3.21, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para criar o documento.
74
Figura 3.22 – DDS13 Diagrama de seqüência consultar documento.
Observando-se a figura 3.22, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para se efetuar consulta de documentos.
75
Figura 3.23 – DDS14 Diagrama de seqüência alterar documento.
Observando-se a figura 3.23, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para alterar o documento.
76
Figura 3.24 – DDS15 Diagrama de seqüência remover documento.
Observando-se a figura 3.24, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para se efetuar a remoção do documento.
77
Figura 3.25 – DDS16 Diagrama de seqüência liberar documento.
Observando-se a figura 3.25, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para liberar o documento.
78
Figura 3.26 – DDS17 Diagrama de seqüência divulgar documento.
Observando-se a figura 3.26, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para se efetuar a divulgação do documento.
79
Figura 3.27 – DDS18 Diagrama de seqüência imprimir documento.
Observando-se a figura 3.27, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para imprimir o documento.
80
Figura 3.28 – DDS19 Diagrama de seqüência mover documento para o arquivo morto.
Observando-se a figura 3.28, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para mover o documento para o arquivo morto.
81
Figura 3.29 – DDS20 Diagrama de seqüência recuperar documento do arquivo morto.
Observando-se a figura 3.29, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para recuperar o documento do arquivo morto.
82
Figura 3.30 – DDS21 Diagrama de seqüência remover documento do arquivo morto.
Observando-se a figura 3.30, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para remover o documento do arquivo morto.
Figura 3.31 – DDS22 Diagrama de seqüência consultar documento no arquivo morto.
Observando-se a figura 3.31, verifica-se a seqüência de eventos e interações entre o
usuário e o sistema, necessários para se consultar o documento no arquivo morto.
83
3.11. INTERFACES DE USUÁRIO
Nesta seção são ilustradas a figuras que representam os modelos de telas do sistema a
serem apresentadas aos usuários, conforme a função desejada.
Figura 3.32 – Tela 01 - Tela principal do sistema.
Observando-se a figura 3.32, verifica-se a tela principal do sistema, seus menus:
Arquivo, Documento, Modelo e Usuário. Temos também no canto inferior esquerdo: a imagem
de um cadeado indicando que o sistema está bloqueado, no meio uma mensagem indicando que
nenhum usuário está logado e no canto inferior direito a seqüência numérica que indica a versão
do sistema.
84
Figura 3.33 – Tela 02 - Tela principal do sistema.
Observando-se a figura 3.33, verifica-se o sub menu do menu Arquivo, onde o usuário
poderá escolher as ações de configurar, liberar, bloquear e sair do sistema.
85
Figura 3.34 – Tela 03 - Tela principal do sistema.
Observando-se a figura 3.34, verifica-se o sub menu do menu Documento, onde o
usuário poderá escolher as ações de gerenciar e liberar o documento.
86
Figura 3.35 – Tela 04 - Tela principal do sistema.
Observando-se a figura 3.35, verifica-se o sub menu do menu Modelo, onde o usuário
poderá escolher as ações de modelar ou liberar o modelo.
87
Figura 3.36 – Tela 05 - Tela principal do sistema.
Observando-se a figura 3.36, verifica-se o sub menu do menu Usuário, onde o usuário
poderá escolher a ação de cadastrar outro usuário no sistema.
88
Figura 3.37 – Tela 06 - Acessar sistema.
Observando-se a figura 3.37, verifica-se a tela de acesso ao sistema, onde o usuário
poderá inserir o nome de usuário e a senha de acesso ao sistema.
89
Figura 3.38 – Tela 07 - Configurar sistema.
Observando-se a figura 3.38, verifica-se a tela de configuração do sistema, onde o
usuário poderá editar as preferências do sistema: modo de inicialização do sistema e modo de
apresentação da tela de acesso ao sistema.
90
Figura 3.39 – Tela 08 – Configurar sistema.
Observando-se a figura 3.39, verifica-se a aba de teste de conexão Banco, na tela de
configuração do sistema, onde o usuário poderá informar o nome do driver ODBC Postegre para
a conexão com o banco de dados.
91
Figura 3.40 – Tela 09 – Teste de conexão do banco de dados.
Observando-se a figura 3.40, verifica-se a tela de configuração do sistema, onde o
usuário ao clicar no ícone
, inicializará um teste de conexão do sistema com o banco de dados,
apresentado pela tela Teste de conexão, que irá mostrar o andamento do teste e seus resultados.
92
Figura 3.41 – Tela 10 – Gerenciamento de usuário.
Observando-se a figura 3.41, verifica-se a tela gerenciamento de usuários, onde o
usuário poderá escolher usuários em uma lista, limpar os campos do formulário (
por nome de usuário (
), salvar dados (
), remover (
) ou fechar a tela (
).
), pesquisar
93
Figura 3.42 – Tela 11 – Gerenciamento de modelos.
Observando-se a figura 3.42, verifica-se a tela de gerenciamento de modelos, onde o
usuário poderá criar um novo modelo (
), pesquisar modelos existentes na lista Modelos (lado
esquerdo), pesquisar através do código ou o nome do modelo (
na lista Modelos (lado esquerdo) salvar (
Visual (
), remover (
), pesquisar modelos existentes
), acessar o menu Campos (
) ou fechar a tela Modelos do sistema clicando no ícone
.
) e
94
Figura 3.43 – Tela 12 – Gerenciamento de modelos.
Observando-se a figura 3.43, verifica-se na tela de gerenciamento de modelos o sub
menu do menu Campos, onde o usuário poderá adicionar campos fixos ou campos flexíveis ao
modelo.
95
Figura 3.44 – Tela 13 – Gerenciamento de modelos.
Observando-se a figura 3.44, verifica-se na tela de gerenciamento de modelos o sub
menu do menu Visual, onde o usuário poderá atualizar o layout de construção do modelo
(Renderizar) e visualizar o modelo.
96
Figura 3.45 – Tela 14 – Visualizar modelo.
Observando-se a figura 3.45, verifica-se a tela de visualização do modelo, onde o
usuário poderá visualizar, atualizar (
ícone
.
) a imagem do modelo ou fechar a tela clicando no
97
Figura 3.46 – Tela 15 – Liberar modelo.
Observando-se a figura 3.46, verifica-se a tela Liberar modelos, onde o usuário poderá
selecionar os modelos em uma lista de modelos a serem liberados, confirmar os modelos
escolhidos clicando em no ícone
e fechar a tela, clicando no ícone
.
98
Figura 3.47 – Tela 16 – Gerenciamento de documentos.
Observando-se a figura 3.47, verifica-se a tela de gerenciamento de documentos, onde o
usuário poderá criar um novo documento (
) a partir do modelo selecionado, salvar (
pesquisar através do código ou nome do documento (
tela (
), remover documentos (
), pesquisar os documentos em uma lista de documentos.
),
), fechar a
99
Figura 3.48 – Tela 17 – Liberar documento.
Observando-se a figura 3.48, verifica-se a tela Liberar documentos, onde o usuário
poderá selecionar os documentos em uma lista de documentos a serem liberados, limpar os
campos com as informações dos documentos (
no ícone
e fechar a tela, clicando no ícone
), confirmar os documentos escolhidos clicando
.
100
Figura 3.49 – Tela 18 – Consultar documento.
Observando-se a figura 3.48, verifica-se a tela Consultar documentos, onde o usuário
poderá selecionar o documento que deseja visualizar em uma lista de documentos que estão
devidamente liberados para o usuário em especifico, limpar o espaço onde o do documento
escolhido aparece (
clicando no ícone
), imprimir o documento escolhido clicando no ícone (
.
) e fechar a tela,
101
Figura 3.50 – Tela 19 – Divulgar documento.
Observando-se a figura 3.50, verifica-se a tela Divulgar documento, onde o usuário
poderá selecionar os documentos em uma lista de documentos a serem divulgados, limpar os
campos com as informações dos documentos (
selecionados (
) ou fechar a tela (
).
), divulgar o documento aos usuários
102
Figura 3.51 – Tela 20 – Arquivo Morto.
Observando-se a figura 3.51, verifica-se a tela Arquivo morto, onde o usuário poderá
visualizar se o documento desejado está no arquivo morto ou o arquivo corrente, limpar para
preparar a tela e atualizar ambas as listas de arquivos (
(
), pesquisar o documento por nome
), poderá enviar um documento para o arquivo morto arrastando o documento da lista
documentos operantes para a lista de documentos desativados, quando for para restaurar um
arquivo que está localizado no arquivo morto basta arrastar o arquivo da lista de arquivos
desativados para a lista de arquivos operantes, remover some removerá documentos localizados
no arquivo morto (
) ou fechar a tela (
).
103
CAPÍTULO IV
4. CONCLUSÃO
O objetivo inicial deste projeto foi aprofundar os conhecimentos na especialidade de
engenharia de software, seguindo as principais técnicas utilizadas para o desenvolvimento de
sistemas de software. Tal objetivo foi alcançado a contento devido aos estudos realizados durante
toda a fase de projeto, melhorando e ampliando os conhecimentos.
Concluímos que os processos descritos, apesar de aparentemente simples no contexto,
ocultam uma grande variedade de padrões com graus de complexidade variáveis. Porém o uso de
ferramentas case como apoio ao desenvolvimento do sistema contribuiu significativamente com a
agilidade da análise do mesmo.
Observamos que o modelo em espiral do processo de software foi a melhor escolha,
pois ao longo de todo o processo por várias vezes percebemos que teria de haver acréscimos ou
mudanças em algumas fases do modelo.
Apesar de ser um sistema GED, o sistema desenvolvido ainda não é capaz de gerenciar
documentos eletrônicos que não fazem parte dele ou que não foram produzidos por ele, pois dois
períodos não seriam suficientes para abordar esse tópico. Mas em contra partida o sistema é
capaz de padronizar um documento e gerenciá-lo, evitando que documentos de mesma espécie
tenham formatações diferentes.
No futuro poderiam ser acrescentadas novas funcionalidades ao sistema, como por
exemplo, gerenciar outros tipos de documentos eletrônicos, digitalizar e gerenciar documentos
que estão em papel, inserir assinatura digital, reconhecimento do usuário por digital e
visualização de um documento por uma página na web.
104
REFERÊNCIAS BIBLIOGRÁFICAS
1. ARQDIGITAL. Gerenciamento eletrônico de documentos – GED. Disponível em:
<http://www.arqdigital.com.br/ged.htm>. Acesso em: 16 de Fevereiro, 2008.
2. Sommerville, Ian. Engenharia de software. Tradução: Selma Shin Shimuzu Melnikoff,
Reginaldo Arakaki, Edilson de Andrade Barbosa. São Paulo: Pearson Addison Wesley,
2007 – Sommerville.
3. Larman, Craig. Utilizando UML e padrões: Uma itrodução à análise e ao projeto
orientados a objeto e ao desenvolvimento iterativo. Tradução Rosana Vaccare Braga.
Porto Alegre: Bookman, 2007.
4. Presman, Roger S. Engenharia de software. Tradução Rosângela Delloso Penteado. São
Paulo: McGall-Hill, 2006.
5. Deitel, H. M.. Visual Basic .NET : como programar . Tradução Célia Yumi Okano
Taniwaki. São Paulo: Pearson Education do Brasil, 2004.
6. Majela, Geraldo Ferreira de Macedo. Bases para implantação de um sistema de
gerenciamento
eletrônico
de
documentos
–
GED.
Disponível
em:
<http://teses.eps.ufsc.br/defesa/pdf/12288.pdf>. Acesso em: 10 de Abril, 2008.
7. Chaves, Prado Tecnologia e digitalização S/C Ltda. Disponível em: Captura,
reconhecimento
e
armazenamento
de
imagens
digitais
<http://www.pradochaves.com.br/download/Digitalizacao.pdf>. Acesso em: 14 de Abril,
2008.
105
8. Martins Rossio, Neire. Reiney, Alice. Pires, Reinaldo. Digitalização de documentos.
Disponível
em:
<http://www.powerbrasil.com.br/pdf/Digitalizacao_Unicamp.pdf>.
Acesso em: 18 de Abril, 2008.
9. Luiz, Flavio D’Oliveira e Silva. Gerenciamento eletrônico de documentos (GED):
Principio
e
aplicações.
Disponível
em:
<http://www.arquivar.com.br/espaco_profissional/sala_leitura/teses-dissertacoes-emonografias/GED_natureza_principios_aplicacao.pdf>. Acesso em: 18 de Abril, 2008.
10. Vinícius, Marcos Mendonça Andrade. Gerenciamento eletrônico da informação:
Ferramenta para a gerência eficiente dos processos de trabalho. Disponível em:
<http://www.ndc.uff.br/textos/gei.pdf >. Acesso em: 19 de Abril, 2008.
11. Murrieta, Maíra Costa. A gestão eletrônica de documentos no estado maior da
aeronáutica. Fundação Getúlio Vargas: MBA em administração estratégica de sistemas de
informação. 2004, 73p.
12. PostegreeSql. About. Disponível em: <http://www.postgresql.org/about/>. Acesso em: 19
de Novembro, 2008.
106
GLOSSÁRIO
Stakeholders – Se refere a qualquer pessoa ou grupo afetado pelo sistema a ser implantado,
direta ou indiretamente. Os stakeholders incluem os usuários finais que interagem com o
sistema e todo o pessoal na organização que possa ser afetado por sua instalação. Outros
stakeholders podem ser os engenheiros que estão desenvolvendo ou mantendo sistemas
relacionados, gerentes de negócios, especialistas do domínio e representantes do sindicato.
Document Imaging - Processo de conversão dos documentos em suporte de papel ou
microfilme em bitmaps eletrônico.
Escanerização (ou digitalização) - Processo de conversão dos documentos em papel ou
microfilme para uma seqüência de códigos binários feito, geralmente por scanner.
Elicitar - Do lat. elicitus, part. pass. de elicere, ‘extrair’, ‘tirar de’, + -ar2; ingl. (to) elicit.
Ferramenta CASE - Uma ferramenta CASE (do inglês Computer-Aided Software
Engineering) é uma ferramenta de software como um editor de projeto ou debugger
(depurador) de programa, usado para apoiar uma atividade no processo de desenvolvimento
de software.
UML – uma linguagem gráfica usada no desenvolvimento orientado a objetos, que inclui
diversos tipos de modelos que fornecem diferentes visões de um sistema. A UML tornou-se
um padrão de fato para a modelagem orientada a objetos.