Вы находитесь на странице: 1из 102

UNIVERSIDADE CATÓLICA DE GOIÁS

DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO


GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

DESENVOLVIMENTO DE SISTEMA ELETRÔNICO DE PROTOCOLO


COM FRAMEWORK PRADO

JANDILSON DE MORAIS OLIVEIRA


JOÃO LUIZ DA COSTA LEANDRO

JUNHO
GOIÂNIA, 2007
i

UNIVERSIDADE CATÓLICA DE GOIÁS


DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO
GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO

DESENVOLVIMENTO DE SISTEMA ELETRÔNICO DE PROTOCOLO


COM FRAMEWORK PRADO

Trabalho de Conclusão de Curso apresentado por


Jandilson de Morais Oliveira e João Luiz da Costa
Leandro à Universidade Católica de Goiás, como
requisito parcial para obtenção do título de Bacharel em
Ciência da Computação aprovado em __/__/____ pela
Banca Examinadora:
Professor Vicente Paulo de Camargo. UCG – Orientador
ii

DESENVOLVIMENTO DE SISTEMA ELETRÔNICO DE PROTOCOLO


COM FRAMEWORK PRADO

JANDILSON DE MORAIS OLIVEIRA


JOÃO LUIZ DA COSTA LEANDRO

Trabalho de Conclusão de Curso apresentado por Jandilson de Morais Oliveira e João


Luiz da Costa Leandro à Universidade Católica de Goiás, como parte dos requisitos para
obtenção do título de Bacharel em Ciência da Computação.

______________________________ ________________________________________
Professor Vicente Paulo de Camargo Coordenador de Trabalho de Conclusão de Curso
Orientador
iii

AGRADECIMENTOS

Ao professor Vicente Paulo de Camargo, orientador acadêmico, pelo apoio e


conhecimento transmitidos. À Universidade Católica de Goiás por proporcionar a realização
deste trabalho. Aos colegas Felipe dos Santos Carvalho Gilowsky e Wellington Batista de
Siqueira pelo companheirismo.
iv

RESUMO

Apresenta-se um estudo baseado na engenharia de software onde se objetiva a


aplicação prática dos conhecimentos acadêmicos. São empregadas técnicas consagradas no
meio acadêmico e pelo mercado para o desenvolvimento de um Sistema Eletrônico de
Protocolo com Framework. Ao se propor a desenvolver um software para um cliente, a equipe
experimenta a realidade do desenvolvimento de software, buscando o entendimento e solução
do problema apresentado, utilizando-se da modelagem com UML e optando pelo paradigma
de orientação a objetos e pelo processo unificado para o desenvolvimento do software. Esse
contexto tem como objetivo ainda o desenvolvimento de uma aplicação Web com a utilização
de técnicas como MVC e Framework.
Palavras-chave: UML, processo unificado, aplicação Web, MVC, Framework.
v

ABSTRACT

A study based on the software engineering is presented where if objective the practical
application of the academic knowledge. Techniques consecrated in the half academic and for
the market for the development of a software are used. To if considering to develop a software
for a customer the team tries the reality of the software development, searching the agreement
and solution of the presented problem, using themselves of the modeling with UML and
opting to the paradigm of orientation objects and to the process unified for the development
of software. The development of a Web application is foreseen still with the use of techniques
as MVC and Framework.
Key-words: UML, unified process, Web application, MVC, Framework.
vi

SUMÁRIO

LISTA DE FIGURAS...............................................................................................................09
LISTA DE ABREVIATURAS.................................................................................................11
1. INTRODUÇÃO............................................................................................................12
2. FUNDAMENTAÇÃO TEÓRICA................................................................................14
2.1. A modelagem....................................................................................................14
2.1.1. A importância da modelagem..................................................................14
2.1.2. Os princípios da modelagem...................................................................15
2.2. Desenvolvimento orientado a objetos............................................................16
2.2.1. Encapsulamento.....................................................................................16
2.2.2. Mensagem..............................................................................................17
2.2.3. Classe.....................................................................................................18
2.2.4. Herança..................................................................................................18
2.2.5. Polimorfismo.........................................................................................19
2.2.6. Vantagens da Orientação a objetos........................................................20
2.3. UML..................................................................................................................21
2.4. O processo de desenvolvimento de software.................................................23
2.4.1. Ciclo de desenvolvimento.......................................................................24
2.4.2. Modelo iterativo e incremental................................................................24
2.4.3. O processo unificado...............................................................................24
2.4.3.1. Fases do processo unificado.....................................................25
2.4.3.2. Fluxo de trabalho do processo unificado..................................26
2.5. Aplicativos Web...............................................................................................27
2.5.1. Páginas estáticas e Dinâmicas.................................................................27
2.5.2. Folha de estilo (CSS)...............................................................................28
2.5.2.1. Vantagens da construção com CSS..........................................28
2.5.2.2. Desvantagens da construção com CSS.....................................29
2.6. Padrão Modelo-Visão-Controle (MVC)........................................................29
vii

2.7. A linguagem PHP............................................................................................30


2.8. Frameworks.....................................................................................................30
2.8.1. O framework Prado.................................................................................32
2.8.1.1. Arquitetura................................................................................33
2.8.1.2. Componentes............................................................................33
2.8.1.3. Controles...................................................................................33
2.8.1.4. Páginas......................................................................................34
2.8.1.5. Módulos....................................................................................34
2.8.1.6. Serviços.....................................................................................35
2.8.1.7. Aplicações.................................................................................36
2.8.1.8. Organização dos diretórios.......................................................36
3. DESENVOLVIMENTO DE SISTEMA ELETRÔNICO DE PROTOCOLO COM
FRAMEWORK PRADO..............................................................................................38
3.1. O projeto...........................................................................................................38
3.2. Tecnologias empregadas.................................................................................39
3.3. Concepção........................................................................................................40
3.4. Elaboração........................................................................................................40
3.4.1. Análise.....................................................................................................40
3.4.1.1. Expansão dos Casos de Uso do SEP.........................................41
3.4.1.2. Diagrama de Caso de Uso do SEP............................................44
3.4.1.3. Diagramas de Seqüência – Manter Locais ...............................45
3.4.1.4. Diagramas de Seqüência – Manter Usuários............................46
3.4.1.5. Diagramas de Seqüência – Manter Categorias.........................48
3.4.1.6. Diagramas de Seqüência – Manter Documentos......................49
3.4.1.7. Diagramas de Seqüência – Efetuar despacho...........................51
3.4.1.8. O modelo conceitual do SEP....................................................52
3.4.1.9. Listas das Operações do Sistema..............................................53
3.4.1.10. Especificações dos Contratos de Operações do Sistema .......55
3.4.2. Projeto......................................................................................................66
3.4.2.1. Diagrama de Classes do SEP....................................................66
3.4.2.2. Diagrama Entidade-Relacionamento........................................67
3.4.2.3. Dicionário de Dados.................................................................68
3.4.2.3.1. Entidades....................................................................68
viii

3.4.2.3.2. Relacionamentos........................................................69
3.4.2.4. Diagrama de Navegação do SEP..............................................71
3.4.2.5. Projeto Gráfico das janelas e associação de controles..............72
3.4.3. Considerações Técnicas...........................................................................86
3.4.3.1. Diretório do SEP.......................................................................86
3.4.3.2. Arquitetura do SEP...................................................................86
4. CONCLUSÃO..............................................................................................................87
5. REFERÊNCIAS BIBLIOGRÁFICAS..........................................................................89
6. GLOSÁRIO...................................................................................................................90
7. ANEXOS.......................................................................................................................91
ix

LISTA DE FIGURAS

Figura 1 – Encapsulamento.
Figura 2 – Troca de mensagens entre objetos.
Figura 3 – Classes e objetos.
Figura 4 – Herança.
Figura 5 – Polimorfismo.
Figura 6 – Diagrama de Casos de uso.
Figura 7 – Diagrama de Classes.
Figura 8 – Diagrama de Seqüência.
Figura 9 – O ciclo de vida de desenvolvimento de um software.
Figura 10 – Diferença entre aplicações utilizando reuso de classes e reuso de framework.
Figura 11 – Árvore de diretórios clássica de uma aplicação Prado.
Figura 12 – Diagrama de Casos de Uso do SEP.
Figura 13 – Diagrama de Seqüência do Caso de Uso Manter Locais – Opção Novo Local.
Figura 14 – Diagrama de Seqüência do Caso de Uso Manter Locais – Opção Alterar Local.
Figura 15 – Diagrama de Seqüência do Caso de Uso Manter Locais – Opção Excluir Local.
Figura 16 – Diagrama de Seqüência do Caso de Uso Manter Usuários – Opção Novo Usuário.
Figura 17 – Diagrama de Seqüência do Caso de Uso Manter Usuários – Opção Alterar
Usuário.
Figura 18 – Diagrama de Seqüência do Caso de Uso Manter Usuários –Opção Excluir
Usuário.
Figura 19 – Diagrama de Seqüência do Caso de Uso Manter Categorias –Opção Nova
Categoria.
Figura 20 – Diagrama de Seqüência do Caso de Uso Manter Categorias –Opção Alterar
Categoria.
Figura 21 – Diagrama de Seqüência do Caso de Uso Manter Categorias – Opção Excluir
Categoria.
Figura 22 – Diagrama de Seqüência do Caso de Uso Manter Documentos –Opção Novo
Documento.
x

Figura 23 – Diagrama de Seqüência do Caso de Uso Manter Documentos – Opção Alterar


Documento.
Figura 24 – Diagrama de Seqüência do Caso de Uso Manter Documentos – Opção Excluir
Documento.
Figura 25 – Diagrama de Seqüência do Caso de Uso Efetuar Despacho –Opção Enviar
Documento.
Figura 26 – Diagrama de Seqüência do Caso de Uso Efetuar Despacho –Opção Receber
Documento.
Figura 27 – Modelo Conceitual do SEP.
Figura 28 – Diagrama de Classes do SEP.
Figura 29 – Diagrama Entidade – Relacionamento do SEP.
Figura 30 – Diagrama de Navegação do SEP.
Figura 31 – Projeto Gráfico da Janela Login.
Figura 32 – Projeto Gráfico da Janela Principal.
Figura 33 – Projeto Gráfico da Janela Documentos.
Figura 34 – Projeto Gráfico da Janela Usuários.
Figura 35 – Projeto Gráfico da Janela Locais.
Figura 36 – Projeto Gráfico da Janela Categorias.
Figura 37 – Projeto Gráfico da Janela Pesquisar Documentos.
Figura 38 – Projeto Gráfico da Janela Despachos.
Figura 39 – Projeto Gráfico da Janela Despachos – Enviar.
Figura 40 – Projeto Gráfico da Janela Despachos – Receber.
Figura 41 – Projeto Gráfico da Janela Relatórios.
Figura 42 – Diretório do SEP.
Figura 43 – Arquitetura do SEP.
xi

LISTA DE ABREVIATURAS E SIGLAS

CSS: Cascading Style Sheets (Folha de Estilo em Cascata).


EV: Eventos do Sistema.
FK: Foreign Key (Chave Estrangeira).
HTML: Hypertext Markup Language (Linguagem de Formatação de Hipertexto).
HTTP: HiperText Transfer Control (Protocolo de Transferência de Hipertexto).
ID: Identificador.
WEB: Abreviatura de World Wide Web (Rede mundial).
MVC: Modelo, Visão e Controle.
OMG: Object Management Group (Organização de padronização de assuntos ligados à
orientação a objetos).
PHP: Pré-Processador de Hipertexto.
RS: Respostas do Sistema.
RF: Requisito funcional.
SEP: Sistema Eletrônico de Protocolo.
UML: Unified Modeling Language (Linguagem de modelagem unificada).
XML: Extensible MArkup Language (Linguagem de Marcação Extensível).
DESENVOLVIMENTO DE SISTEMA ELETRÔNICO DE PROTOCOLO
COM FRAMEWORK PRADO

CAPÍTULO I
INTRODUÇÃO

Os estudos realizados acerca do desenvolvimento de software mostram a importância


do esforço em busca da melhoria da qualidade do produto de software. O desenvolvimento de
software é uma atividade cheia de riscos que podem resultar em prejuízos inadmissíveis nos
dias atuais. Projetos de software que não terminam, ou que terminam com um resultado
diferente do esperado, assim como estouros de orçamento e de cronograma bem acima do
planejado, fizeram da engenharia de software uma das bases fundamentais para o sucesso de
qualquer equipe que se proponha a desenvolver software com qualidade, que atenda as
necessidades dos usuários num período adequado e que permita uma utilização e manutenção
eficaz [1].

Diante do exposto surge a motivação para a realização deste estudo que tem como
objetivo a aplicação prática do conhecimento acadêmico ministrado sobre desenvolvimento
de software. Basicamente serão empregadas as técnicas consagradas no meio acadêmico e
pelo mercado para o desenvolvimento de um software. A importância do estudo encontra-se
na experimentação prática da teoria, sendo que a equipe será submetida à situação típica da
profissão, onde se relacionará com os clientes, buscando as informações necessárias para o
entendimento e solução do problema apresentado, tomando as decisões inerentes ao processo
de desenvolvimento, seja na escolha do modelo a ser seguido, seja nas tecnologias mais
adequadas à aplicação, podendo assim verificar quais os principais desafios do
desenvolvimento de software.

Desta forma, esse trabalho culminará com o desenvolvimento de um software que é o


Sistema Eletrônico de Protocolo para a Fundação Aroeira.
13

Esse trabalho é composto pela a introdução ao projeto no capítulo 1 onde se contempla


uma visão geral sobre o que se propõe.

O capítulo 2 onde é exposta a fundamentação teórica sobre a qual o projeto é


desenvolvido.

O capítulo 3 em que se detalha o projeto evidenciando as tarefas realizadas e seus


resultados.

E por fim o capítulo 4 onde se apresentam as conclusões sobre o trabalho.


CAPITULO II
FUNDAMENTAÇÃO TEÓRICA

2.1. A modelagem

O principal objetivo de uma equipe de desenvolvimento de software deve ser a entrega


de um produto de qualidade, que atenda as necessidades dos usuários, num período adequado
e que permita uma utilização e manutenção eficaz. Apesar de o principal objetivo ser um
produto de software, isto não significa que atividades secundárias devam ficar de fora do
planejamento do software, uma vez que para se chegar ao propósito definido são necessários
técnicas e métodos que levem a elicitação dos requisitos do software junto aos usuários, bem
como o conhecimento e entendimento da equipe [1].

A modelagem é uma atividade fundamental na implantação de sistemas de software, a


construção de modelos serve para visualizar melhor a estrutura e o comportamento do
sistema. Os modelos nos ajudam a compreender melhor o que estamos desenvolvendo,
identificando pontos de otimização e de possíveis falhas [1].

2.1.1. A importância da modelagem

Os modelos são visões panorâmicas do sistema desejado, mostrando componentes


importantes e omitindo os detalhes menores de acordo com o nível de abstração. Com a ajuda
da modelagem delimitamos o problema, restringindo nosso foco em busca da solução para
aquele problema. A modelagem nos oferece o seguinte:

• Permite a visualização dos sistemas;


• Permite especificar a estrutura ou o comportamento do sistema;
• Oferece um guia para a construção do sistema;
15

• Documentação das decisões tomadas.

2.1.2. Os princípios da modelagem

O histórico da modelagem nas disciplinas de engenharia de software revela quatro


princípios a serem seguidos [1]:

O primeiro se refere à escolha dos modelos e sua influência na forma como um


problema é determinado e sua solução é encontrada. Este princípio nos diz que a escolha
correta do modelo pode contribuir imensamente para a identificação e solução dos problemas
de desenvolvimento já um modelo inadequado pode levar a confusão, desviando o foco para
questões irrelevantes.

O segundo princípio estabelece que cada modelo é passível de representação em


diferentes níveis de precisão. Em alguns momentos será necessária uma visão panorâmica do
sistema, como para ajudar na visualização da aparência e do funcionamento do sistema pelos
stakeholders. Em outros casos será preciso um nível mais baixo de abstração como em rotinas
de execução crítica. O modelo deverá atender a determinados níveis de abstração,
possibilitando ao usuário mover este nível para o atendimento da visão especifica que se
deseja.

O terceiro trata da relação dos modelos com a realidade. Os modelos simplificam a


realidade, o segredo está em saber o que deve ser representado e em que grau de importância.

Um quarto ponto a ser mencionado é que nenhum modelo é suficiente por si só, sendo
que muitas vezes é necessário recorrer a outras formas de representação que complementem
um determinado modelo.

Para compreender a arquitetura de um sistema orientado a objeto deve-se recorrer a


várias visões complementares e inter-relacionadas como: a visão dos casos em que o sistema
atuará, sendo expostos os requisitos do sistema, a visão do projeto, onde se define o espaço do
problema e o espaço da solução e a visão da implementação, onde se direciona para a
16

realização física do sistema. Cada visão poderá conter aspectos estruturais ou


comportamentais do sistema e em conjunto representam a base do projeto do software [1].

2.2. Desenvolvimento orientado a objetos

Para desenvolver um software é necessário criar primeiro uma visão do problema, esta
visão é representada em um modelo que orienta o processo de desenvolvimento a obtenção
desta visão é feita a partir de um paradigma que defina uma unidade de decomposição do
sistema destacando-se alguns aspectos do sistema [2].

A orientação a objetos enfoca a busca da estrutura do problema e não apenas da


informação. Este paradigma identifica em objetos, os elementos importantes do domínio do
problema que guardam dados e possuem funções que podem operar seus dados.

Um objeto é um conjunto de operações e um estado que armazena os efeitos das


operações que o objeto é capaz de realizar. Utilizar a orientação a objetos para analisar um
problema inclui uma série de características inerentes à tecnologia de objetos, que devem ser
bem entendidas para o uso correto do paradigma [2]. As principais características do
paradigma orientado a objetos são: encapsulamento, mensagens, classes, herança e
polimorfismo [2].

2.2.1. Encapsulamento

Essa característica vem da observação de que todos os dados e operações necessários


para a existência de um objeto devem estar armazenados no próprio objeto. Assim os dados
dos objetos não estão mais isolados das funções. O princípio é que o objeto possua todos os
dados e funções necessárias para sua existência. O encapsulamento protege os dados de um
objeto do acesso descontrolado de outros objetos. As informações do objeto e como ele
implementa esses serviços são mantidos ocultos. O ocultamento da informação é uma
conseqüência importante do encapsulamento de objetos.
17

A figura 1 exibe o conceito de encapsulamento, com o principio de que um objeto


deve possuir todos os dados e funções necessárias para sua existência.

Figura 1: Encapsulamento.

O encapsulamento implica em outra característica da orientação a objetos que é a


colaboração entre objetos a partir da troca de mensagens, ou seja, a saída de um objeto poderá
estar interligada à entrada de outro objeto, permitindo o acionamento da função de um objeto
por outro. O encapsulamento leva à reutilização, permitindo a separação da criação de objetos
da integração desses objetos.

2.2.2. Mensagens

Como um sistema é formado por um conjunto de objetos, o processamento do sistema


é obtido mediante a troca de mensagens entre objetos. Uma mensagem é a chamada de uma
função de um objeto, ou seja, o acionamento de uma operação encapsulada no objeto de
destino, feita a partir do objeto de origem. Para que haja a comunicação, é necessário que
exista algum vinculo integrando esses objetos, esses vínculos são relacionamentos que
asseguram o conhecimento que um objeto possui da existência do outro, a figura 2 representa
este conceito onde um objeto envia uma mensagem para o outro.

Figura 2: Troca de mensagens entre objetos.


18

2.2.3. Classes

Na modelagem orientada a objetos observa-se que existem grupos de objetos que


compartilham a mesma interface, isto é, apesar de serem objetos distintos, oferecem os
mesmos serviços para o sistema. Esses objetos seguem a mesma estrutura formando um tipo
abstrato de dado. Esse tipo de dado na verdade, quando implementado, gera uma classe. A
classe possui, além das definições, a implementação das operações, para criar um componente
para o sistema.

A classe é o molde para a criação de objetos, pois permite descrever um conjunto de


objetos que compartilha a mesma estrutura de dados e as mesmas operações. Todos os objetos
de uma classe possuem as mesmas definições e podem possuir valores diferentes nos dados,
respondendo de modo diferente às mensagens enviadas, a figura 3 exemplifica como vários
objetos podem ser gerados a partir de uma classe.

Figura 3: Classes e objetos.

2.2.4. Herança

A herança é uma das principais características da orientação a objetos e está associada


ao conceito de agrupamento de objetos de acordo com um conjunto de propriedades comuns.
Como classe é o agrupamento de objetos que compartilham a mesma estrutura de dados e
funções, é possível encontrar grupos que possuam um conjunto de propriedades e que a partir
desse grupo seja possível criar outros grupos que possuam propriedades ainda mais
específicas formando assim um subconjunto do anterior, herdando suas propriedades.
19

A herança permite ainda que as características herdadas da classe mãe possam ser
alteradas e expandidas pela classe filha. Essa capacidade dos modelos orientados a objetos
permite que a modelagem seja feita em camadas de classes, criando uma árvore para cada
classe com um nível decrescente de abstração. O uso de herança permite a criação de classes
genéricas, com funcionalidades gerais e que podem ser herdadas por várias classes em
diferentes situações simplificando a modelagem e implementação aumentando a capacidade
de reutilização das classes, no exemplo da figura 4 a herança é utilizada para distribuir os
equipamentos em categorias, pode-se observar que num primeiro momento todos os
elementos são equipamentos, porém existem elementos que podem pertencer a mais de uma
categoria, gerando a necessidade de novas categorias que englobem essa característica.

Figura 4: Herança.

2.2.5. Polimorfismo

Polimorfismo é a propriedade que permite que a mesma mensagem possa ser


respondida de forma diferente por duas ou mais classes, ou seja, o polimorfismo presente em
linguagens orientadas a objetos, permite que objetos de diferentes classes possam receber um
mesmo formato de mensagem. Isto permite a padronização das interfaces quando da criação
das classes de um domínio, o que facilita a reutilização de software na abordagem de
orientação a objetos, a figura 5 demonstra esse conceito onde a classe tv envia a mesma
mensagem a duas outras classes que responderão de acordo com a natureza de cada uma.
20

Figura 5: A mesma mensagem provoca respostas diferentes.

2.2.6. Vantagens da orientação a objetos

A escolha do paradigma orientado a objetos para o desenvolvimento de um software


resulta nas seguintes vantagens:

• O uso de objetos na modelagem torna mais fácil descrever as estruturas e o


comportamento existente no mundo real fazendo com que problemas sejam mais
facilmente identificados;
• O encapsulamento do conhecimento em componentes isola o comportamento em
partes, o que permite que as mudanças nos requisitos possam ser isoladas em cada
componente sem afetar o sistema como um todo;
• O uso de classes e objetos facilita a integração das fases do processo de
desenvolvimento, já que o mesmo paradigma é conduzido da análise à construção;
• O encapsulamento favorece o teste dos sistemas de software, que pode ser isolado para
cada componente resultando na melhora da qualidade do sistema;
• A reutilização que a orientação a objetos proporciona reduz custos e prazos no
desenvolvimento de software, possibilitando que o mesmo componente seja usado em
vários projetos.
21

2.3. UML

A UML é uma linguagem padrão para especificar, visualizar, construir e documentar


todos os artefatos de um sistema de software. As linguagens são formadas por um conjunto de
palavras e regras para a combinação destas palavras com o objetivo de comunicar algo. Assim
a UML é uma linguagem de modelagem cujo vocabulário e regras têm seu foco voltado para a
representação conceitual e física de um sistema [1].

A notação da UML é uma notação gráfica e textual na qual a descrição de um software


é feita com símbolos gráficos padronizados que se relacionam formando diagramas. Cada
diagrama apresenta uma visão parcial do sistema e a união dos diagramas deve representar um
único sistema de software. Entre os diagramas da UML destaca-se:

Diagrama de Casos de uso

O diagrama de casos de uso é útil por possibilitar a associação de outros artefatos que
representam a interação entre os atores e o sistema. A Figura 6 apresenta um diagrama casos
de uso onde, a elipse representa o caso de uso, o boneco representa o usuário, e o retângulo
representa a fronteira do sistema.

Figura 6: Diagrama de Casos de uso.

Diagrama de Classes

O diagrama de classes oferece uma visão estática da estrutura do sistema, a figura 7


apresenta um diagrama de classes com as classes A e B, onde cada uma possui seus atributos
e operações, apresenta ainda o relacionamento existente entre ambas.
22

Figura 7: Diagrama de Classes.

Diagrama de Seqüência

O diagrama de seqüência apresenta as mensagens entre classes no tempo, ou seja, a


seqüência dos eventos de sistema em um cenário de casos de uso, a figura 8 apresenta um
diagrama de seqüência com seus elementos, o ator (Funcionário) que se comunica com a
aplicação (Interface) que por sua vez se comunica com o controle do sistema (vídeo locadora).
Cada um desses elementos com sua linha de tempo representada por linhas verticais, na qual
os eventos ocorrem. As linhas horizontais representam o fluxo de informação.

Figura 8: Diagrama de Seqüência.

Os objetivos da UML:

• Fornecer aos desenvolvedores uma linguagem de modelagem visual;


• Dar suporte às especificações de projeto independente da linguagem de programação e
do processo de desenvolvimento;
• Prover uma base formal para o entendimento de uma linguagem de modelagem;
23

• Dar suporte aos conceitos de desenvolvimento de alto nível como componentes,


colaboração, frameworks e padrões;
• Integrar as boas práticas do projeto.

A UML Foi desenvolvida com o foco na padronização da documentação dos diversos


sistemas de software. A grande aceitação pela comunidade de desenvolvedores e pela
indústria de software tornou fundamental que qualquer projeto de software orientado a objetos
seja representado pela UML. As ferramentas disponíveis no mercado atual e o contingente de
pessoal técnico treinado permitem a adoção desta notação padronizada trazendo a vantagem
da separação entre análise, design e a construção [1].

2.4. O processo de desenvolvimento de software

A adoção de boas técnicas de desenvolvimento de software tem como objetivo


incorporar ao produto de software características que o tornem mais estruturado, de fácil
compreensão e bem documentado, possibilitando a redução em sua elaboração,
desenvolvimento e manutenção [3]. O desenvolvimento de um software é descrito como um
trabalho disciplinado que une criatividade, tecnologia e trabalho organizado. Para
transformarmos uma idéia em um produto de software é necessária a adoção de um modelo
que descreva a organização dos passos a serem seguidos para a sustentação da edificação do
software. Os modelos são organizados em fases que caracterizam as etapas de evolução pelas
quais o software deve passar. Em cada fase certas atividades devem ser realizadas,
produzindo-se documentos, esquemas e diagramas que resultam no código do programa de
computador. Um modelo de desenvolvimento de software possui algumas fases que são
clássicas, ou seja, aparecem de uma forma ou de outra no decorrer do processo: fase de
análise, de design, de construção dos componentes e de integração [2].
É na fase da análise que ocorre a identificação dos objetivos assim como dos requisitos
do problema. Uma vez conhecidos os requisitos e as necessidades do cliente, elabora-se uma
estratégia para a solução do problema, é a fase do design da solução. Com a definição do
design é iniciada a fase da construção dos componentes, onde novos componentes são
desenvolvidos ou reutilizados de outros projetos já testados e aprovados. Após a construção
24

dos componentes é realizada a fase de integração que coloca todas as partes juntas para a
obtenção do produto final [2].

2.4.1. Ciclo de desenvolvimento

O ciclo de desenvolvimento de um software consiste num fluxo de trabalho que gera


novos produtos a partir das informações obtidas no levantamento das necessidades do
problema. A cada ciclo de desenvolvimento é gerado um produto de saída que alimenta um
ciclo posterior. Assim espera-se que em um determinado estágio o produto atenda a todos os
requisitos e possa ser considerado terminado.

2.4.2. Modelo Iterativo e incremental

Uma iteração representa um ciclo completo de desenvolvimento, em cada fase podem


ocorrer várias iterações. Cada fase e iteração objetiva redução de riscos e funcionam como um
marco do progresso. Esse marco define um ponto para avaliar o alcance das metas e se o
projeto deve ser reestruturado por algum motivo para o prosseguimento. Os modelos com esta
característica são chamados de modelos iterativos. No final de cada iteração obtêm-se como
resultado uma versão de um produto executável que cresce de modo incremental de uma
iteração para outra até se chegar ao sistema final. Modelos com esse comportamento são
conhecidos por modelos incrementais.

2.4.3. O processo unificado

O processo unificado é ideal para o desenvolvimento de sistemas que não de adaptam


muito bem ao desenvolvimento linear, ou seja, sistemas que requerem uma solução iterativa
com uma compreensão crescente do problema através de aperfeiçoamentos sucessivos e do
desenvolvimento incremental de uma solução em vários ciclos.
25

A flexibilidade do processo permite a introdução de novos requisitos ou de mudanças


no objetivo do negócio sem maiores complicações. Permite ainda a identificação e solução de
riscos do projeto no início facilitando a realização de procedimentos preventivos. O processo
unificado é um processo configurável, uma vez que não existe nenhum processo adequado
para todas as empresas de desenvolvimento de software, a possibilidade de ajuste e
redimensionamento para atender desde projetos com pequenas equipes até grandes projetos é
uma característica desejável [3].

2.4.3.1. Fases do processo unificado

Cada fase do processo unificado define um conjunto de objetivos a ser alcançado,


gerando artefatos de acordo com as decisões tomadas. O processo unificado é composto pelas
seguintes fases: concepção, elaboração, construção e transição.

Na concepção se estabelece o caso de negócio para o sistema e delimita-se o escopo


do projeto. O caso de negócio aborda critérios de sucesso, riscos, estimativa de recursos
necessários e um plano mostrando a programação das atividades.

A Elaboração tem como meta a análise do domínio do problema, a definição da


arquitetura, o desenvolvimento do plano do projeto e a eliminação dos elementos de alto risco
do projeto. As decisões referentes à arquitetura são tomadas com base na compreensão de
todo o sistema, necessitando assim que a descrição dos requisitos do sistema e a execução dos
casos de uso significativos estejam prontas.

Durante a fase de construção o sistema é desenvolvido com a geração de código onde


surgem os componentes do software propriamente dito.

A transição é a fase onde o software é disponibilizado aos usuários e são realizados


ajustes no sistema com a finalidade de corrigir problemas identificados [3].
26

2.4.3.2. Fluxo de trabalho do processo unificado

O processo unificado é composto por nove fluxos de trabalho [1], são eles:

1. Modelagem de negócio – descreve a estrutura e a dinâmica da empresa;


2. Requisitos – descreve o método baseado em casos de uso para identificar requisitos;
3. Análise e projeto – descreve várias visões da arquitetura;
4. Implementação – leva em consideração o desenvolvimento do software, o teste da
unidade e a integração;
5. Teste – descreve casos de teste, procedimentos e medidas para acompanhamento de
erros;
6. Entrega – abrange a configuração do sistema a ser entregue;
7. Gerenciamento da configuração – controla as modificações e mantém a integridade
dos artefatos do projeto;
8. Gerenciamento do projeto – descreve várias estratégias para o trabalho com um
processo iterativo;
9. Ambiente – abrange a infra-estrutura necessária para o desenvolvimento do sistema.

Em cada fluxo de trabalho está um conjunto de atividades e artefatos correlacionados,


uma atividade corresponde as tarefas executadas pelos trabalhadores para criar ou modificar
os artefatos que podem ser algum documento, relatório ou executável, produzido ou
manipulado.

A figura 9 representa o ciclo de desenvolvimento no processo unificado onde estão


explicitas as fases na horizontal formando colunas, cortadas por linhas que representam os
vários fluxos de trabalho em cada fase e abaixo a divisão em iterações.
27

Figura 9: O ciclo de vida de desenvolvimento de um software [1].

2.5. Aplicativos Web

A Web é um serviço que disponibiliza várias páginas conectadas entre si por um


sistema de conexões, esse sistema sobre o qual se desenvolve a Web é conhecido como hiper-
texto. A web não se limita a apresentar textos e conexões, como também pode nos oferecer
imagens, vídeos, áudios e todo o tipo de apresentações [6].

Os serviços Web, são aplicações que utilizam a internet como meio de comunicação,
utilizando o paradigma cliente-servidor, onde o cliente faz requisições ao servidor Web que as
processa e em seguida as envia ao cliente que por sua vez exibe os resultados.

No navegador a página web é exibida como uma única entidade, porém esta é
composta por vários arquivos cada um deles com um determinado tipo de informação ou
função que compõe a página. O navegador interpreta o código das páginas escrito na
linguagem HTML, que é uma linguagem de formatação e divulgação, não oferecendo muitas
funcionalidades [6].

2.5.1. Páginas estáticas e Dinâmicas

A web dispõe de dois tipos básicos de páginas, as páginas estáticas oferecem as


funcionalidades básicas de conexão entre páginas, enquanto as páginas dinâmicas apresentam
28

funções e efeitos dignos de uma aplicação mais complexa. As primeiras são páginas mais
simples, construídas em código HTML e podem apresentar desde textos e imagens até áudio e
vídeo. O segundo tipo possibilita a inclusão de efeitos e funcionalidades que necessitam de
outras linguagens de programação além do HTML, oferecendo mais complexidade e
versatilidade [6].

2.5.2. Folha de estilo (CSS)

A Cascading Style Sheets (CSS), ou folha de estilo em cascata, é uma tecnologia que
permite a criação de páginas Web mais estruturadas onde se separa a parte de formatação da
página da parte de controle, facilitando a manutenção. As folhas de estilo em cascata ajudam a
separar o conteúdo da forma, ou seja, os elementos que compõem uma página da forma com a
qual se mostram. CSS auxilia na definição de estilos na página, já que permite ajustar de uma
forma muito mais precisa qualquer aspecto de qualquer elemento da página [6].

2.5.2.1. Vantagens da construção com CSS

• A separação do conteúdo da página e do estilo ou aspecto. Quanto mais separarmos


estes dois elementos, mais simples será a manutenção das páginas e o processamento
da informação, obtendo páginas mais limpas e claras;
• Economia na transferência. Se todos os estilos e posições dos elementos se introduzem
em um documento externo, liberaremos o código da página e ocupará muito menos.
Como a declaração de estilos se armazena no cachê do navegador, só se transfere no
primeiro acesso a página, as páginas posteriores que se solicitem serão carregadas
muito mais rápidas;
• Facilidade para alterar o aspecto da página sem tocar no código HTML. Como toda a
informação dos estilos e o posicionamento das camadas se encontram em um mesmo
arquivo, se desejarmos mudar qualquer elemento da página, deve-se apenas atualizar a
folha de estilos, e as mudanças serão vistas automaticamente em todo o documento
Web [6].
29

2.5.2.2. Desvantagens da construção com CSS

• A incompatibilidade com navegadores antigos. A maioria dos navegadores suporta


características avançadas das CSS, mas ainda há muitos navegadores desatualizados
sendo utilizados. Os navegadores que não suportam CSS interpretam o código da
página e o mostram sem nenhum posicionamento;
• Dependendo do navegador também mudam as etiquetas de estilos suportadas,
podendo fazer com que as páginas não sejam exibidas do mesmo modo para em cada
navegador;
• Aprender um novo padrão, ou seja, o inicio da programação com CSS requer um
estudo mais profundo [6].

2.6. Padrão Modelo-Visão-Controle (MVC)

O padrão Modelo, Visão e Controle (MVC) estabelece uma arquitetura de software


com o objetivo de separar a lógica do negócio da parte da interface com o usuário e da parte
de fluxo da aplicação. A separação em camadas visa aumentar a flexibilidade e a reutilização
do aplicativo. O modelo é o objeto de aplicação, a visão é a apresentação na tela e o controle
define a maneira como a interface do usuário reage às entradas do mesmo. Uma visão deve
refletir o estado do modelo, sempre que os dados do modelo mudam, este notifica as visões
que dependem dele, que por sua vez respondem atualizando seus estados. O mecanismo de
resposta é implementado no objeto de controle que executa as ações necessárias para
modificar o estado das visões [4].

No passado a aplicação consistia em uma camada onde a lógica de negocio e acesso ao


banco de dados, a entrada do usuário e a verificação estavam contidas em uma única máquina,
com isso o código ficava muito grande e a manutenção ficava comprometida. Em seguida
surgiu a necessidade de vários usuários terem acesso ao mesmo banco de dados, e com isso
surgiu o modelo com duas camadas, a camada envolvendo as tarefas executadas por
diferentes aplicativos e outra camada responsável pela manutenção da base de dados. Nesse
30

modelo se houvesse uma alteração, todas as máquinas deveriam ser atualizadas uma a uma
[4].

A internet foi o catalisador de uma nova mudança devida à necessidade de se separar a


lógica de negócio da interface com o usuário. Isto para permitir que os usuários da Web
pudessem acessar as mesmas aplicações sem ter que instalá-las em suas máquinas
previamente. O aplicativo passou a residir no Servidor Web onde é realizado todo o
processamento, cabendo à máquina cliente realizar as requisições através de um navegador
Web que por sua vez gera o código html para exibição na máquina cliente. Essa estratégia
permite que uma mesma lógica de negócio venha a ser acessada e visualizada através de
várias interfaces [4].

2.7. A linguagem PHP

A utilização da linguagem PHP no projeto se justifica por ser uma linguagem com
funcionalidades voltadas ao desenvolvimento Web, sendo uma das mais populares no mundo,
operando em mais de um terço dos servidores Web existente. O crescimento do PHP além de
quantitativo é também qualitativo, sendo cada vez mais utilizado em aplicações empresariais
indispensáveis.

2.8. Framework

A Engenharia de software utiliza-se de diferentes abordagens que buscam melhorar a


qualidade do produto de software, diminuir o tempo e o esforço de produção. Frameworks são
estruturas de classes que formam implementações incompletas que podem ser estendidas para
produzir diferentes aplicações de um mesmo domínio. O reuso de código e de projeto são os
grandes atrativos desta abordagem. Entretanto apresenta grande complexidade de
desenvolvimento e uso. O reuso de componentes previamente desenvolvidos, permite a
redução de tempo e esforço no desenvolvimento do software. Há também um ganho em
relação á manutenção já que com a constante reutilização do framework a equipe de
desenvolvimento agrega um conhecimento amplo sobre a aplicação. A estabilidade do código
31

também é outra vantagem obtida devido ao uso em várias aplicações sendo que problemas de
compatibilidade são minimizados. Os artefatos de software podem ser reutilizados tanto em
nível de código quanto em relação à análise e projeto. A reutilização dos produtos das etapas
de análise e projeto significa mais do que a simples reutilização de trechos de código. A
utilização destes componentes pode ser dificultada pela deficiência na documentação
necessária para a avaliação da sua adequação a uma determinada situação [5].

O conceito de framework parte da proposta de oferecer uma estrutura de suporte


definida a partir da qual vários projetos de software possam ser organizados e desenvolvidos.
Um framework é composto por programas de apoio, bibliotecas de código e documentação
para orientação da sua utilização. Um framework orientado a objeto é um conjunto de classes
com o objetivo de reutilizar um design, oferecendo um guia para uma solução de arquitetura
em um domínio determinado de software. O framework captura as funcionalidades comuns a
várias aplicações, oferece uma solução para uma família de problemas semelhantes por meio
de classes e interfaces e como os objetos colaboram para resolver os problemas detectados. O
conjunto de classes é flexível e extensível para permitir a construção de varias aplicações com
economia de esforço, acrescentando apenas as particularidades de cada aplicação [5].

A diferença fundamental entre um framework e a reutilização de classes de uma


biblioteca é que neste caso são usados artefatos de software isolados, cabendo ao
desenvolvedor estabelecer sua interligação, no caso do framework essa inter-relação é
estabelecida no projeto do framework.

A figura 10 apresenta essa diferença, a parte sombreada representa classes e


associações que são reutilizadas, no framework as classes já possuem uma estrutura cabendo
ao desenvolvedor acrescentar funcionalidades:
32

Figura 10: Diferença entre aplicações utilizando reuso de classes e reuso de framework [5].

2.8.1. O Framework Prado

O Framework Prado possui licença livre, é baseado em componentes e voltado ao


desenvolvimento de aplicações Web utilizando a linguagem PHP 5. Deve ser rodado em um
servidor web com suporte a PHP 5 ou superior, sendo compatível com os seguintes ambientes
[7]:

• Servidores Web: Apache http Server 2, Apache http Server 1 e Windows IIS;
• Navegadores: Internet Explorer 5.0 ou superior, Firefox 1.0 ou superior;
• Sistemas Operacionais: Windows Server 2003, Windows XP, Windows 2000,
Mac OS X, FreeBSD, RedHat Linux, Fedora Linux, Slackware Linux.
33

2.8.1.1. Arquitetura

O foco do framework Prado é a programação web, que lida na maior parte do tempo
com interações com os usuários, sendo baseado em componentes e orientado a eventos,
permitindo aos desenvolvedores serem mais produtivos [7].

2.8.1.2. Componentes

No Prado um componente é uma instância de TComponent ou de uma classe filha, a


classe implementa o mecanismo de propriedades e eventos de componentes. A propriedade de
um componente trata-se de uma variável pública que descreve uma característica de um
componente, como a cor de fundo, tamanho da fonte, etc. Eventos de componente são
propriedades especiais que tomam os nomes de métodos como seus valores [7].

Os componentes criados instanciam classes de componentes. Existem dois tipos de


instanciação de componentes: estática e dinâmica. A instanciação dinâmica de componentes
significa criar instâncias de componentes no seu código PHP. Isto é o mesmo que a criação de
objetos no PHP. A instanciação estática de componentes significa criar componentes através
de configurações. O trabalho de criação é realizado pelo Prado, pode-se configurar um
módulo para ser carregado quando a aplicação é executada. O módulo é como um
componente criado pelo Prado [7].

2.8.1.3. Controles

Um controle é uma instância da classe Tcontrol ou de uma de suas classes filha. Um


controle é um componente definido em conjunto com uma interface de usuário. A classe base
Tcontrol define o relacionamento pai-filho entre os controles, o que reflete na relação pai-
filho entre os elementos na interface do usuário. Os Controles são relacionados entre si
através de relacionamentos pai-filho. Cada controle-pai pode ter um ou mais controles-filhos.
Um controle-pai está em estado de transição na carga de seus controles-filhos. O resultado da
34

geração dos controles-filhos é usado normalmente para compor a apresentação do controle-


pai. A página é a raiz da árvore, sendo que a apresentação é retornada aos usuários finais [7].

2.8.1.4. Páginas

As Páginas são os controles no topo da hierarquia. A apresentação das páginas é


exibida diretamente para os usuários. Os usuários acessam as páginas enviando requisições ao
serviço de páginas (Page Request Service). Cada página deve ter um arquivo. A extensão no
nome do arquivo de visão deve ser .page. O nome do arquivo (sem a extensão) é o nome da
página. O Prado tenta localizar a classe (Camada de Controle) que define a página na pasta
que contém o arquivo. Então, o arquivo que contém a classe que define a página de visão deve
ter o mesmo nome do arquivo, porém com a extenção .php. Se a classe não for encontrada, a
página irá utilizar a classe Tpage [7].

2.8.1.5. Módulos

Um Módulo é uma instância de uma classe implementando a interface IModule. Um


módulo é normalmente projetado para fornecer funcionalidades específicas que podem ser
agregadas em uma aplicação Prado e compartilhadas por todos os componentes na aplicação.
O Prado utiliza configurações para especificar se carrega um módulo, que tipo de módulo
carregar e como inicializar os módulos carregados. Os desenvolvedores podem substituir os
módulos do núcleo com suas próprias implementações por meio de configuração da aplicação
ou podem escrever novos módulos para fornecer funcionalidades adicionais. Como exemplo,
um módulo pode ser desenvolvido para prover uma lógica comum de banco de dados para
uma ou mais páginas.

Há três módulos do núcleo que são carregados como padrão sempre que uma
aplicação é executada. São eles, o módulo request, o módulo response e o módulo error
handler. Além deles, o módulo session é carregado quando utilizado em uma aplicação. O
Prado prove implementações padrões para todos estes módulos. Módulos customizados
35

podem ser configurados ou desenvolvidos para sobrepor ou suplementar estes módulos do


núcleo.

O módulo Request prove o esquema de armazenamento e acesso as requisições de


usuários enviadas via HTTP. Os dados das requisições de usuários vêm de diversas fontes
incluindo URL, post data, session data, cookies data, etc. Todos estes dados podem ser
acessados via módulo request. Por padrão, O Prado utiliza THttpRequest como módulo
request. O módulo request pode ser acessado pela propriedade Request da aplicação e dos
controles.

O módulo response implementa o mecanismo para enviar saída aos usuários do


cliente. Por padrão, O Prado utiliza THttpResponse como módulo response. O módulo
response pode ser acessado pela propriedade Response da aplicação e dos controles.

O módulo session encapsula as funcionalidades relacionadas com a manipulação de


sessões de usuários. O módulo session é carregado automaticamente quando uma aplicação
usa a sessão. Por padrão, Prado utiliza THttpSession como módulo session, que é um simples
envoltório das funções de sessão fornecidas pelo PHP. O módulo session pode ser acessado
pela propriedade Session da aplicação e dos controles.

O módulo errorhandler é usado para capturar e processar todas as condições de erros


em uma aplicação. O Prado utiliza TErrorHandler como módulo errorhandler. Ele captura
todos os avisos, observações e excessões do PHP e os mostra de uma forma adequada ao
usuário final. O módulo errorhandler pode ser acessado pela propriedade errorhandler da
instancia da aplicação [7].

2.8.1.6. Serviços

Um Serviço é uma instância de uma classe que implementa a interface IService. Cada
tipo de serviço processa um tipo específico de requisição vinda dos usuários. Por exemplo, o
serviço Page (página) responde as requisições de páginas Prado, vindas dos usuários da
aplicação. Um serviço é identificado unicamente por sua propriedade ID. Por padrão, quando
36

THttpRequest é usado como módulo de requisição, nomes de variáveis GET são usados para
identificar qual serviço um usuário está solicitando. Se um nome de variável GET for igual ao
ID de algum serviço, a requisição é considerada um serviço e o valor da variável é passado
como um parâmetro do serviço. Para o serviço page o nome da variável GET deve ser page.
Prado implementa o TPageService para processar requisições de páginas de usuários. As
Páginas são armazenadas sob um diretório expecificado pela propriedade BasePath do serviço
page. O valor padrão desta propriedade é o diretório pages. Esse valor pode ser modificado na
configuração da aplicação [7].

2.8.1.7. Aplicações

Uma Aplicação é uma instância de Tapplication ou de suas classes filhas. Ela gerencia
módulos que fornecem diferentes funcionalidades e que são carregados quando necessários.
Fornece serviços aos usuários. É o lugar central para armazenar vários parâmetros utilizados
numa aplicação [7].

2.8.1.8. Organização dos Diretórios

Uma aplicação Prado deve estar organizada em diretórios com a seguinte estrutura:

www – Pasta raiz do documento web ou subdiretório.


index.php – Arquivo script de entrada do aplicativo Prado.
Pasta assets – diretório que armazena arquivos privados publicados.
Pasta protected – caminho base que armazena dados da aplicação e arquivos de script
privados. Este diretório deve ser inacessível para a web ou pode ser situado fora dos diretórios
web.
Pasta runtime – caminho base que armazena arquivos em tempo de execussão. Este diretório
é utilizado para armazenar informações em tempo de execussão, como o estado da aplicação.
Pasta pages – caminho base do armazenamento de todas as páginas Prado.
Home.page - Página padrão retornada quando o usuário não especifica a página requisitada.
Este arquivo é um template de página. O nome do arquivo sem sufixo é o nome da página. A
37

classe de uma página é TPage. Se houver um arquivo de classe Home.php(de controle), a


classe da página (de visão) será Home.page.

A figura 11 mostra a disposição desses elementos:

Figura 11: Árvore de diretórios clássica de uma aplicação Prado [7].


CAPITULO III
DESENVOLVIMENTO DE SISTEMA ELETRÔNICO DE PROTOCOLO COM
FRAMEWORK PRADO

3.1. O projeto

O volume de documentos que circulam dentro das empresas nos dias atuais demanda
alguma forma de controle para que não venha a afetar os processos aos quais estão
vinculados. O fluxo de informação dentro da empresa deve ser tratado com seriedade para
evitar prejuízos gerados por falta de clareza na comunicação. Uma vez que esta documentação
representa os processos desenvolvidos pela empresa, desde requisições de clientes até
decisões executivas, os diretores e gerentes percebem ser fundamental a certeza acerca da
origem, destino, entendimento e execução da informação que cada documento transporta.

A partir dessa visão nos colocamos diante da necessidade de soluções que tornem
seguro e democrático o acesso e manuseio da documentação bem como o acompanhamento
do seu percurso dentro da empresa, evitando que fique tal função a cargo de um único
indivíduo ou mesmo de vários sem uma padronização da forma como é tratada a informação
dentro da empresa.

Esse trabalho consiste no desenvolvimento de um sistema eletrônico de protocolo para


a Fundação Aroeira. Esse sistema englobará as rotinas relativas à expedição e circulação de
documentos, permitindo o gerenciamento da documentação de forma ágil e segura. O registro
da documentação que chega na Fundação Aroeira e aquela originada dentro da própria
instituição será feito no computador onde a partir de então será acompanhado o seu percurso
facilitando o conhecimento da sua localização, situação e manutenção. O acompanhamento da
documentação será feito “on line” através de buscas e da geração de relatórios de acordo com
a informação desejada. O sistema funcionará em rede permitindo a consulta das informações
de cada documento a partir de qualquer terminal, bastando para isto que o usuário esteja
39

devidamente cadastrado, possibilitando ainda o cadastro, manutenção e emissão de relatórios


sobre a documentação.

3.2. Tecnologias empregadas

A solução será obtida com a aplicação dos conceitos e técnicas da engenharia de


software, sendo primeiramente executada a modelagem do sistema utilizando-se a notação
oferecida pela UML, através de uma das ferramentas existentes no mercado.

O paradigma de orientação a objetos também será empregado na concepção do


sistema. Tal paradigma permite a estruturação do problema e a identificação dos elementos
importantes do sistema. Conceitos como encapsulamento, herança e polimorfismo serão
abordados.

A utilização do processo unificado permite um desenvolvimento incremental e


iterativo, estas características possibilitam a identificação prematura de riscos, bem como a
introdução de novos requisitos ao sistema sem maiores complicações. O ciclo de
desenvolvimento de um software deve ser bem gerenciado e definido para atingir os objetivos
propostos.

O MVC é outro padrão a ser seguido no desenvolvimento do software, pois a


separação entre interface, controle lógico e modelo é uma característica desejável numa
aplicação onde se espera obter flexibilidade.

A utilização do framework Prado, como base para o desenvolvimento da aplicação,


oferece a oportunidade de verificar o ganho com a adoção de um conceito que promete
economia de tempo e custo no desenvolvimento.

A opção por desenvolver uma aplicação Web segue a tendência que domina o mercado
atual com as empresas migrando suas aplicações para o ambiente Web.
40

3.3. Concepção

De acordo com o modelo do processo unificado, iniciou-se a fase de concepção com a


atividade de definição do escopo do projeto por meio de uma reunião, tendo sido previamente
definido os stakeholders do projeto, assim como suas respectivas responsabilidades (Anexo
A). A definição do escopo mostrou-se uma tarefa complexa, sendo que é comum a ocorrência
do stakeholder não ter noção do que deseja do sistema, este fato exigiu a análise do ambiente
da fundação Aroeira e quais as atividades desenvolvidas e como estas ocorrem para verificar
até onde o sistema deveria abranger. Com o auxilio de entrevistas e documentos, extraiu-se
alguns requisitos que começaram a modelar o sistema (Anexo B).

Uma segunda reunião serviu para que as informações, obtidas na primeira, fossem
desenvolvidas resultando em mais requisitos. Como resultado dessas reuniões obteve-se a
ratificação destas informações e a base para a obtenção do escopo do projeto que gerou o
termo de abertura do projeto (Anexo C) que após a elaboração foi encaminhado para
conhecimento e aprovação do patrocinador do projeto. Com a aprovação da documentação da
abertura passou-se a elaboração do Documento de Requisitos e Análise do Sistema (Anexo
D).

3.4. Elaboração

A fase de Elaboração compreende as etapas clássicas de Análise e Projeto [3].

3.4.1. Análise

Uma das primeiras tarefas da análise é a expansão dos casos de uso definidos na fase
anterior de concepção. É na expansão que os principais requisitos funcionais são associados a
eventos de sistema [3]. Para o caso do SEP segue os casos de uso expandidos:
41

3.4.1.1. Expansão dos Casos de Uso do SEP

Manter Locais
Caso de uso: Manter locais.
ID: RF001
Ator: Funcionário.
Interessados: Todos os departamentos da empresa.
Pré-condições: O usuário deve estar logado no sistema e com permissão específica.
Pós-condições: A manutenção é efetuada.
Fluxo principal:
1. [EV] O funcionário entra no sistema.
2. [EV] O funcionário escolhe a opção desejada.
3. O funcionário escolhe novo:
3.1 [EV] O funcionário informa o nome do local e, finaliza o cadastro.
4. O funcionário escolhe alterar:
4.1 [EV] O funcionário informa o nome do local a ser alterado.
4.2 [EV] O funcionário registra a alteração do local e, finaliza o processo.
5. O funcionário escolhe excluir:
5.1 [EV] O funcionário informa o nome do local a ser excluído.
5.2 [EV] O funcionário registra a exclusão do local e, finaliza o processo.
Tratamento de exceções:
3a. Local inválido.
3a.1 [RS] É mostrada uma mensagem que o local é inexistente ou já existe.
3a.2 O caso de uso retorna ao passo 3.
4a. Local já existente.
4a.1 [RS] É mostrada uma mensagem que o local já existe.
4a.2 O caso de uso retorna ao passo 4.

Manter Usuários
Caso de uso: Manter usuários.
ID: RF002
Ator: Funcionário.
Interessados: Funcionários da empresa.
Pré-condições: O usuário deve estar logado no sistema e com permissão específica.
Pós-condições: A manutenção é efetuada.
Requisitos correlacionados: RF001
Fluxo principal:
1. [EV] O funcionário entra no sistema.
2. [EV] O funcionário escolhe a opção desejada.
3. O funcionário escolhe novo:
3.1 [EV] O funcionário registra os dados de outro funcionário e finaliza o
cadastro.
4. O funcionário escolhe alterar.
4.1 [EV] O funcionário informa um usuário que deseja efetuar alterações.
4.2 [EV] O funcionário registra as devidas alterações e, finaliza o processo.
42

5. O funcionário escolhe excluir:


5.1 [EV] O funcionário informa um usuário que deseja excluir.
5.2 [EV] O funcionário confirma a exclusão e, finaliza o processo.
Tratamento de exceções:
3a. Nome do usuário já existente.
3a.1 [RS] É mostrada uma mensagem que usuário já existe.
3a.2 O caso de uso retorna ao passo 3.
4a. Nome do usuário já existente.
4a.1 [RS] É mostrada uma mensagem que usuário já existe.
4a.2 O caso de uso retorna ao passo 4.

Dados:
1 – Nome do usuário
2 – Matrícula
3 – Cargo
4 – Local
5 – Login do usuário
6 – Senha.

Manter Categorias
Caso de uso: Manter categorias.
ID: RF003
Ator: Funcionário.
Interessados: Todos os departamentos da empresa.
Pré-condições: O usuário deve estar logado no sistema e com permissão específica.
Pós-condições: A manutenção é efetuada.
Fluxo principal:
1. [EV] O funcionário entra no sistema.
2. [EV] O funcionário escolhe a opção desejada.
3. O funcionário escolhe novo:
3.1 [EV] O funcionário informa o nome da categoria e, finaliza o cadastro.
4. O funcionário escolhe alterar:
a. [EV] O funcionário informa o nome da categoria a ser alterada.
b. [EV] O funcionário registra a alteração da categoria e, finaliza o
processo.
5. O funcionário escolhe excluir:
a. [EV] O funcionário informa o nome da categoria a ser excluído.
b. [EV] O funcionário registra a exclusão da categoria e, finaliza o
processo.
Tratamento de exceções:
3a. Categoria inválida.
3a.1 [RS] É mostrada uma mensagem que a categoria é inexistente ou já existe.
3a.2 O caso de uso retorna ao passo 3.
4a. Categoria já existente.
4a.1 [RS] É mostrada uma mensagem que a categoria já existe.
43

4a.2 O caso de uso retorna ao passo 4.

Manter Documentos
Caso de uso: Manter documentos.
ID: RF004
Ator: Funcionário.
Interessados: Todos os departamentos da empresa.
Pré-condições: O usuário deve estar logado no sistema.
Pós-condições: A manutenção é efetuada.
Requisitos correlacionados: RF003
Fluxo principal:
1. [EV] O funcionário entra no sistema.
2. [EV] O funcionário escolhe a opção desejada.
3. O funcionário escolhe novo:
3.1 [EV] O funcionário registra os dados do novo documento.
3.2 [RS] O funcionário escreve o número de identificação gerado pelo sistema
no documento e, finaliza o cadastro.
4. O funcionário escolhe alterar:
4.1 [EV] O funcionário informa o número de identificação do documento.
4.2 [EV] O funcionário registra os dados que foram alterados e, finaliza
a alteração.
5. O funcionário escolhe excluir:
5.1 [EV] O funcionário informa o número de identificação do documento.
5.2 [EV] O funcionário confirma a exclusão e, finaliza o processo.
Tratamento de exceções:
3a. O funcionário não possui permissão para cadastrar.
3a.1 [RS] É mostrada uma mensagem que usuário não tem permissão para
cadastrar documentos, e tem que procurar o administrador do sistema.
3a.2 O caso de uso é encerrado.
4a. O número de identificação do documento é invalido.
4a.1 [EV] É mostrada uma mensagem que o número de identificação do
documento é inválido.
4a.2 O caso de uso retorna ao passo 4.
4b. Assunto do documento já existente.
4b.1 [EV] É mostrada uma mensagem que assunto já existe.
4b.2 O caso de uso retorna ao passo 4.
5a. O número de identificação do documento é invalido.
5a.1 [EV] É mostrada uma mensagem que o número de identificação do
documento é inválido.
5a.2 O caso de uso retorna ao passo 5.

Efetuar Despacho
Caso de uso: Efetuar despacho.
ID: RF005
Ator: Funcionários.
44

Interessados: Todos os departamentos da empresa.


Pré-condições: O usuário deve estar logado no sistema.
Pós-condições: O funcionário confirma o recebimento do documento.
Requisitos correlacionados: RF01,RF02,RF04
Fluxo principal:
1. [EV] O funcionário entra no sistema.
2. O funcionário escolhe enviar:
2.1 [EV] O funcionário escolhe o documento a ser enviado, o local de destino e
confirma o envio.
3. O funcionário escolhe receber:
3.1 [EV] O funcionário escolhe o documento a ser recebido.
3.2 [RS] O sistema mostra o local, usuário e data que o documento foi enviado.
3.3 [EV] O funcionário confirmar o recebimento e, finaliza o processo.

3.4.1.2. Diagrama de Casos de Uso do SEP

Figura 12: Diagrama de Casos de Uso do SEP.


45

3.4.1.3. Diagramas de Seqüência – Manter Locais

Figura 13: Diagrama de Seqüência do Caso de Uso Manter Locais – Opção Novo Local.

Figura 14: Diagrama de Seqüência do Caso de Uso Manter Locais – Opção Alterar Local.
46

Figura 15: Diagrama de Seqüência do Caso de Uso Manter Locais – Opção Excluir Local.

3.4.1.4. Diagramas de Seqüência – Manter Usuários

Figura 16: Diagrama de Seqüência do Caso de Uso Manter Usuários – Opção Novo Usuário.
47

Figura 17: Diagrama de Seqüência do Caso de Uso Manter Usuários – Opção Alterar Usuário.

Figura 18: Diagrama de Seqüência do Caso de Uso Manter Usuários –Opção Excluir Usuário.
48

3.4.1.5. Diagramas de Seqüência – Manter Categorias

Figura 19: Diagrama de Seqüência do Caso de Uso Manter Categorias –Opção Nova
Categoria.

Figura 20: Diagrama de Seqüência do Caso de Uso Manter Categorias –Opção Alterar
Categoria.
49

Figura 21: Diagrama de Seqüência do Caso de Uso Manter Categorias – Opção Excluir
Categoria.

3.4.1.6. Diagramas de Seqüência – Manter Documentos

Figura 22: Diagrama de Seqüência do Caso de Uso Manter Documentos –Opção Novo
Documento.
50

Figura 23: Diagrama de Seqüência do Caso de Uso Manter Documentos – Opção Alterar
Documento.

Figura 24: Diagrama de Seqüência do Caso de Uso Manter Documentos – Opção Excluir
Documento.
51

3.4.1.7. Diagramas de Seqüência – Efetuar despacho

Figura 25: Diagrama de Seqüência do Caso de Uso Efetuar Despacho –Opção Enviar
Documento.

Figura 26: Diagrama de Seqüência do Caso de Uso Efetuar Despacho –Opção Receber
Documento.
52

3.4.1.8. O modelo conceitual do SEP

As informações são analisadas em dois aspectos, o estático e o funcional, sendo o


modelo estático representado no diagrama do modelo conceitual, e o modelo funcional
representado por meio dos contratos de operações de sistema. Assim a análise apenas
especifica o que entra e o que sai do sistema, sem indicar como são tratadas as informações.
Segue os respectivos modelos para o caso do SEP:

Figura 27: Modelo Conceitual do SEP.


53

3.4.1.9. Listas das Operações do Sistema

• Classe Home
1. onLoad(sender).
2. validacao(sender, param).
3. documentoClicked(sender).
4. categoriaClicked(sender).
5. localClicked(sender).
6. usuarioClicked(sender).
7. despachoClicked(sender).
8. pesquisarClicked(sender).
9. relatorioClicked(sender).
10. sairClicked(sender).
11. selecao(sender,param).
12. enviaClicked(sender,param).
13. recebeClicked(sender,param).
14. atualizaRecebe(sender,param).
15. voltarClicked_des(sender,param).
16. mudandoPagina(sender,param).
17. criandoPagina(sender,param).
18. okClicked_pes(sender,param).
19. habilitar(tela).
20. desabilitar(tela).
21. exibirClicked_doc(sender,param).
22. novoClicked_doc(sender,param).
23. alterarClicked_doc(sender,param).
24. excluirClicked_doc(sender,param).
25. confirmarClicked_doc(sender,param).
26. novoClicked_cat(sender,param).
27. alterarClicked_cat(sender,param).
28. excluirClicked_cat(sender,param).
29. confirmarClicked_cat(sender,param).
30. novoClicked_loc(sender,param).
31. alterarClicked_loc(sender,param).
32. excluirClicked_loc(sender,param).
33. confirmarClicked_loc(sender,param).
34. exibirClicked_usu(sender,param).
35. novoClicked_usu(sender,param).
36. alterarClicked_usu(sender,param).
37. excluirClicked_usu(sender,param).
38. confirmarClicked_usu(sender,param).
39. confirmarClicked_des_env(sender,param).
40. confirmarClicked_des_rec(sender,param).
41. okClicked_rel(sender,param).
42. limparClicked(sender,param).
43. imprimeRel(inicio,fim,dados).
54

• Classe Local
1. preparaConsultaGeral(campo:String).
2. preparaConsultaPorCodigoDoLocal(código:Int).
3. preparaConsultaPorNomeDoLocal(local:Sting).
4. preparaInclusaoDoLocal(local:String).
5. preparaAlteracaoDoLocal(localAlterado:String, local:String).
6. preparaExclusaoDoLocal(local:String).
7. efetuaAtualizacao(umStringSql:String, umaOpcao:String).
8. efetuaConsulta(umStringSql:String).

• Classe Usuário
1. preparaConsultaGeral(campo:String).
2. preparaConsultaPeloCodigoDoLocal(codgloc:Int).
3. preparaConsultaPelaMatricula(matricula:Int).
4. preparaConsultaPorNomeDoUsuario(usuario:String).
5. preparaConsultaPeloLogin(login:String).
6. preparaInclusaoDoUsuario(Matricula:Int, Nome:String,Cargo:String,
Codigo_loc:Int,Acesso:String,Usuário:String,Senha:String).
7. preparaAlteracaoDoUsuarioCompleto(matriculaAnt:Int,matricula:Int,
nome:String,cargo:String,local:Int,acesso:String,usuário:String,senha:String).
8. preparaAlteracaoDoUsuarioIncompleto(matriculaAnt:Int,matricula:Int,
nome:String,cargo:String,local:Int,acesso:String).
9. preparaExclusaoDoUsuario(matricula:Int).
10. efetuaAtualizacao(umStringSql:String, umaOpcao:String).
11. efetuaConsulta(umStringSql:String).

• Classe Categoria
1. preparaConsultaGeral(campo:String).
2. preparaConsultaPorCodigoDaCategoria(codigo:Int).
3. preparaConsultaPorNomeDaCategoria(categoria:String).
4. preparaInclusaoDaCategoria(categoria:String).
5. preparaAlteracaoDaCategoria(categoriaAlterada:String,categoria:String).
6. preparaExclusaoDaCategoria(categoria:String).
7. efetuaAtualizacao(umStringSql:String, umaOpcao:String).
8. efetuaConsulta(umStringSql:String).

• Classe Documento
1. preparaConsultaGeral(campo:String).
2. preparaConsultaPeloCodigoDaCategoria(codgcateg:Int).
3. preparaConsultaPeloCodigoDoLocal(codgloc:Int).
4. preparaConsultaPorCodigoDoDocumento(codigo:Int).
5. preparaConsultaPorTituloDoDocumento(titulo:String).
6. preparaConsultaPorDataDoDocumento(data:String).
7. preparaInclusaoDoDocumento(Codigo_loc:Int,Codigo_Categ:Int,Assunto:
String,Informação:String, Mat_usu:Int,Data:String).
8. preparaAlteracaoDoDocumento(codgcateg:Int,assunto:String,informacao:
String,data:String,codgdoc:Int).
55

9. preparaExclusaoDoDocumento(codigo:Int).
10. efetuaAtualizacao(umStringSql:String, umaOpcao:String).
11. efetuaConsulta(umStringSql:String).

• Classe Despacho
1. preparaConsultaPeloCodigoDoDocumento(codgdoc:Int).
2. preparaConsultaDoDespachoEnvia(local:Int).
3. preparaConsultaDoDespachoRecebe(local:Int).
4. preparaConsultaDoDespachoAtualiza(documento:Int,local:Int).
5. preparaInclusaoDoDespachoParcial(Codigo_doc:Int,Local_ant:Int,
Local_atual:Int).
6. preparaAlteracaoDoDespachoEnvia(codgdoc:Int,destino:Int,data:String,
hora:String).
7. preparaAlteracaoDoDespachoRecebe(codgdoc:Int, data:String,
hora:String).
8. efetuaAtualizacao(umStringSql:String, umaOpcao:String).
9. efetuaConsulta(umStringSql:String).

3.4.1.10. Especificações dos Contratos de Operações do Sistema.

Classe: Home.
Operação: onLoad().
Pré-Condição: Quando o método de controle é invocado.
Pós-Condição: Habilita a janela Login.

Classe: Home.
Operação: validacao().
Pré-Condição: Apertar o botão “entrar”.
Pós-Condição: Habilita a janela Principal.
Exceções: Login ou senha do usuário invalido.

Classe: Home.
Operação: documentoClicked().
Pré-Condição: Apertar o botão “documentos”.
Pós-Condição: Habilita a janela Documentos.

Classe: Home.
Operação: categoriaClicked().
Pré-Condição: Apertar o botão “categorias”.
Pós-Condição: Habilita a janela Categoria.
Exceções: Usuário sem permissão para acessar está tela

Classe: Home.
Operação: localClicked().
56

Pré-Condição: Apertar o botão “locais”.


Pós-Condição: Habilita a janela Locais.
Exceções: Usuário sem permissão para acessar está tela

Classe: Home.
Operação: usuarioClicked().
Pré-Condição: Apertar o botão “usuarios”.
Pós-Condição: Habilita a janela Usuários.
Exceções: Usuário sem permissão para acessar está tela

Classe: Home.
Operação: despachoClicked().
Pré-Condição: Apertar o botão “despachos”.
Pós-Condição: Habilita a janela Despachos.

Classe: Home.
Operação: pesquisarClicked().
Pré-Condição: Apertar o botão “pesquisar”.
Pós-Condição: Habilita a janela Pesquisar Documentos.

Classe: Home.
Operação: relatorioClicked().
Pré-Condição: Apertar o botão “relatórios”.
Pós-Condição: Habilita a janela Relatórios.

Classe: Home.
Operação: sairClicked().
Pré-Condição: Apertar o botão “sair”.
Pós-Condição: Habilita a janela Login.

Classe: Home.
Operação: selecao().
Pré-Condição: Selecionar uma das opções de pesquisar documentos.
Pós-Condição: Modifica a tela Pesquisar Documentos de acordo com opção a
escolhida.

Classe: Home.
Operação: enviaClicked().
Pré-Condição: Apertar o botão “envia” da tela Despachos.
Pós-Condição: Habilita a janela Despachos - Enviar.

Classe: Home.
Operação: recebeClicked().
Pré-Condição: Apertar o botão “recebe” da tela Despachos.
Pós-Condição: Habilita a janela Despachos - Receber.
57

Classe: Home.
Operação: atualizaRecebe().
Pré-Condição: Selecionar um documento para receber no menu Documentos da tela
Despachos - Receber.
Pós-Condição: Mostra na tela os dados do envio do documento.

Classe: Home.
Operação: voltarClicked_des().
Pré-Condição: Apertar o botão “voltar” da tela Despachos – Enviar ou
Despecaho - Receber.
Pós-Condição: Habilita a tela Despachos.

Classe: Home.
Operação: mudandoPagina().
Pré-Condição: Escolher qual pagina da pesquisa de documentos quer visualizar.
Pós-Condição: Mudar a pagina da pesquisa de documentos.

Classe: Home.
Operação: criandoPagina().
Pré-Condição: Existir no resultado da pesquisa de documentos um número maior do
que três documentos.
Pós-Condição: As paginas da pesquisa de documentos foram criadas.

Classe: Home.
Operação: okClicked_pes().
Pré-Condição: Apertar o botão “Ok” da tela pesquisa documentos.
Pós-Condição: A pesquisa foi efetuada.

Classe: Home.
Operação: habilitar().
Pré-Condição: Os campos estarem desabilitados.
Pós-Condição: Foi habilitado os campos.

Classe: Home.
Operação: desabilitar().
Pré-Condição: Os campos estarem habilitados.
Pós-Condição: Foi desabilitado os campos.

Classe: Home.
Operação: exibirClicked_doc().
Pré-Condição: Digitar o código do documento.
Pós-Condição: Os dados do documento foram mostrados na tela.
Exceções: O campo código está vazio.

Classe: Home.
Operação: novoClicked_doc().
Pré-Condição:
Pós-Condição: Os campos da tela documentos vazios.
58

Classe: Home.
Operação: alterarClicked_doc().
Pré-Condição: Digitar o código do documento que deseja alterar.
Pós-Condição: Os dados do documento foram mostrados na tela.
Exceções: O campo código está vazio.

Classe: Home.
Operação: excluirClicked_doc().
Pré-Condição: Digitar o código do documento que deseja excluir.
Pós-Condição: Os dados do documento foram mostrados na tela.
Exceções: O campo código está vazio.

Classe: Home.
Operação: confirmarClicked_doc().
Pré-Condição: O botão confirmar estar habilitado e possuir dados válidos.
Pós-Condição: Banco de dados foi atualizado.
Exceções: Campos inválidos.

Classe: Home.
Operação: novoClicked_cat().
Pré-Condição:
Pós-Condição: Os campos da tela categorias vazios.

Classe: Home.
Operação: alterarClicked_cat().
Pré-Condição: Escolher uma categoria no menu.
Pós-Condição: A categoria escolhida foi mostrada na tela.

Classe: Home.
Operação: excluirClicked_cat().
Pré-Condição: Escolher uma categoria no menu.
Pós-Condição: A categoria escolhida foi mostrada na tela.

Classe: Home.
Operação: confirmarClicked_cat().
Pré-Condição: O botão confirmar estar habilitado e possuir categoria.
Pós-Condição: Banco de dados foi atualizado.

Classe: Home.
Operação: novoClicked_loc().
Pré-Condição:
Pós-Condição: Os campos da tela locais vazios.

Classe: Home.
Operação: alterarClicked_loc().
Pré-Condição: Escolher um local no menu.
59

Pós-Condição: O local escolhido foi mostrado na tela.

Classe: Home.
Operação: excluirClicked_loc().
Pré-Condição: Escolher um local no menu.
Pós-Condição: O local escolhido foi mostrado na tela.

Classe: Home.
Operação: confirmarClicked_loc().
Pré-Condição: O botão confirmar estar habilitado e possuir local.
Pós-Condição: Banco de dados foi atualizado.

Classe: Home.
Operação: exibirClicked_usu().
Pré-Condição: Escolher um usuário no menu.
Pós-Condição: Os dados do usuário foram mostrados na tela.

Classe: Home.
Operação: novoClicked_usu().
Pré-Condição:
Pós-Condição: Os campos da tela usuarios vazios.

Classe: Home.
Operação: alterarClicked_usu().
Pré-Condição: Escolher o usuário do menu que deseja alterar.
Pós-Condição: Os dados do usuário foram mostrados na tela.

Classe: Home.
Operação: excluirClicked_usu().
Pré-Condição: Escolher o usuário do menu que deseja excluir.
Pós-Condição: Os dados do usuário foram mostrados na tela.

Classe: Home.
Operação: confirmarClicked_usu().
Pré-Condição: O botão confirmar estar habilitado e possuir dados válidos.
Pós-Condição: Banco de dados foi atualizado.
Exceções: Campos inválidos.

Classe: Home.
Operação: confirmarClicked_des_env().
Pré-Condição: Escolher o documento que deseja enviar e o local de destino.
Pós-Condição: Banco de dados foi atualizado.

Classe: Home.
Operação: confirmarClicked_des_rec().
Pré-Condição: Escolher o documento que deseja receber.
Pós-Condição: Banco de dados foi atualizado.
60

Classe: Home.
Operação: okClicked_rel()
Pré-Condição: Data inicial tem que ser menor ou igual a data final.
Pós-Condição: Mostrar Relatório.
Exeções: Data inicial maior que a data final.

Classe: Home.
Operação: limparClicked().
Pré-Condição: O botão limpar estar habilitado.
Pós-Condição: Limpar campos da tela atual.

Classe: Home.
Operação: imprimeRel().
Pré-Condição: Possuírem os intervalos informados no banco de dados.
Pós-Condição: O relatório foi mostrado na tela.

Classe: Local.
Consulta: preparaConsultaGeral(campo:String).
Pré-Condição: Existe um campo com o nome igual a ‘campo’.
Retorno: Retorna uma string com um comando sql.

Classe: Local.
Consulta: preparaConsultaPorCodigoDoLocal(codigo:Int).
Pré-Condição: Existe um local com o código igual a ‘codigo’.
Retorno: Retorna uma string com um comando sql.

Classe: Local.
Consulta: preparaConsultaPorNomeDoLocal(local:Sting).
Pré-Condição: Existe um local com o nome igual a ‘local’.
Retorno: Retorna uma string com um comando sql.

Classe: Local.
Consulta: preparaInclusaoDoLocal(local:String).
Pré-Condição: Não existe um local com o nome igual a ‘local’.
Retorno: Retorna uma string com um comando sql.

Classe: Local.
Consulta: preparaAlteracaoDoLocal(localAlterado:String, local:String).
Pré-Condição: Existe um local com o nome igual a ‘localAlterado’.
Retorno: Retorna uma string com um comando sql.

Classe: Local.
Consulta: preparaExclusaoDoLocal(local:String).
Pré-Condição: Existe um local com o nome igual a ‘local’.
Retorno: Retorna uma string com um comando sql.
61

Classe: Local.
Operação: efetuaAtualizacao(umStringSql:String, umaOpcao:String).
Pré-Condição: Existe um comando sql com a sintaxe igual a ‘umStringSql’.
Existe uma opção igual a ‘umaOpcao’.
Pós-Condição: O banco de dados foi atualizado.

Classe: Local.
Consulta: efetuaConsulta(umStringSql:String).
Pré-Condição: Existe um comando sql com a sintaxe igual a ‘umStringSql’.
Retorno: Retorna um array com os dados requisitados pelo comando sql.

Classe: Usuário.
Consulta: preparaConsultaGeral(campo:String).
Pré-Condição: Existe um campo com o nome igual a ‘campo’.
Retorno: Retorna uma string com um comando sql.

Classe: Usuário.
Consulta: preparaConsultaPeloCodigoDoLocal(codgloc:Int).
Pré-Condição: Existe o código do local do usuário igual a ‘codgloc’.
Retorno: Retorna uma string com um comando sql.

Classe: Usuário.
Consulta: preparaConsultaPelaMatricula(matricula:Int).
Pré-Condição: Existe um usuário com a matricula igual a ‘matricula’.
Retorno: Retorna uma string com um comando sql.

Classe: Usuário.
Consulta: preparaConsultaPorNomeDoUsuario(usuario:String).
Pré-Condição: Existe um usuário com a nome igual a ‘usuario’.
Retorno: Retorna uma string com um comando sql.

Classe: Usuário.
Consulta: preparaConsultaPeloLogin(login:String).
Pré-Condição: Existe um usuário com a login igual a ‘login’.
Retorno: Retorna uma string com um comando sql.

Classe: Usuário.
Consulta: preparaInclusaoDoUsuario(Matricula:Int, Nome:String,Cargo:String,
Codigo_loc:Int,Acesso:String, Usuário:String,Senha:String).
Pré-Condição: Não existe um usuário com os dados informados.
Retorno: Retorna uma string com um comando sql.

Classe: Usuário.
Consulta: preparaAlteracaoDoUsuarioCompleto(matriculaAnt:Int,matricula:Int,
nome:String,cargo:String, local:Int,acesso:String,
usuário:String,senha:String).
Pré-Condição: Existe um usuário com a matricula igual a ‘matriculaAnt’.
62

Retorno: Retorna uma string com um comando sql.

Classe: Usuário.
Consulta: preparaAlteracaoDoUsuarioIncompleto(matriculaAnt:Int,
matricula:Int, nome:String, cargo:String, local:Int,acesso:String).
Pré-Condição: Existe um usuário com a matricula igual a ‘matriculaAnt’.
Login e senha do usuário não foram informados.
Retorno: Retorna uma string com um comando sql.

Classe: Usuário.
Consulta: preparaExclusaoDoUsuario(matricula:Int).
Pré-Condição: Existe um usuário com a matricula igual a ‘matricula’.
Retorno: Retorna uma string com um comando sql.

Classe: Usuário.
Operação: efetuaAtualizacao(umStringSql:String, umaOpcao:String).
Pré-Condição: Existe um comando sql com a sintaxe igual a ‘umStringSql’.
Existe uma opção igual a ‘umaOpcao’.
Pós-Condição: O banco de dados foi atualizado.

Classe: Usuário.
Consulta: efetuaConsulta(umStringSql:String).
Pré-Condição: Existe um comando sql com a sintaxe igual a ‘umStringSql’.
Retorno: Retorna um array com os dados requisitados pelo comando sql.

Classe: Categoria.
Consulta: preparaConsultaGeral(campo:String).
Pré-Condição: Existe um campo com o nome igual a ‘campo’.
Retorno: Retorna uma string com um comando sql.

Classe: Categoria.
Consulta: preparaConsultaPorCodigoDaCategoria(codigo:Int).
Pré-Condição: Existe uma categoria com o código igual a ‘codigo’.
Retorno: Retorna uma string com um comando sql.

Classe: Categoria.
Consulta: preparaConsultaPorNomeDaCategoria(categoria:String).
Pré-Condição: Existe uma categoria com um nome igual a ‘categoria’.
Retorno: Retorna uma string com um comando sql.

Classe: Categoria.
Consulta: preparaInclusaoDaCategoria(categoria:String).
Pré-Condição: Não existe uma categoria com um nome igual a ‘categoria’.
Retorno: Retorna uma string com um comando sql.

Classe: Categoria.
Consulta: preparaAlteracaoDaCategoria(categoriaAlterada:String,
categoria:String).
63

Pré-Condição: Existe uma categoria com um nome igual a ‘categoriaAlterada’.


Retorno: Retorna uma string com um comando sql.

Classe: Categoria.
Consulta: preparaExclusaoDaCategoria(categoria:String)
Pré-Condição: Existe uma categoria com um nome igual a ‘categoria’.
Retorno: Retorna uma string com um comando sql.

Classe: Categoria.
Operação: efetuaAtualizacao(umStringSql:String, umaOpcao:String).
Pré-Condição: Existe um comando sql com a sintaxe igual a ‘umStringSql’.
Existe uma opção igual a ‘umaOpcao’.
Pós-Condição: O banco de dados foi atualizado.

Classe: Categoria.
Consulta: efetuaConsulta(umStringSql:String).
Pré-Condição: Existe um comando sql com a sintaxe igual a ‘umStringSql’.
Retorno: Retorna um array com os dados requisitados pelo comando sql.

Classe: Documento.
Consulta: preparaConsultaGeral(campo:String).
Pré-Condição: Existe um campo com o nome igual a ‘campo’.
Retorno: Retorna uma string com um comando sql.

Classe: Documento.
Consulta: preparaConsultaPeloCodigoDaCategoria(codgcateg:Int).
Pré-Condição: Existe o código da categoria do documento igual a ‘codgcateg’.
Retorno: Retorna uma string com um comando sql.

Classe: Documento.
Consulta: preparaConsultaPeloCodigoDoLocal(codgloc:Int).
Pré-Condição: Existe o código do local do documento igual a ‘codglog’.
Retorno: Retorna uma string com um comando sql.

Classe: Documento.
Consulta: preparaConsultaPorCodigoDoDocumento(codigo:Int).
Pré-Condição: Existe um documento com o código igual a ‘codigo’.
Retorno: Retorna uma string com um comando sql.

Classe: Documento.
Consulta: preparaConsultaPorTituloDoDocumento(titulo:String).
Pré-Condição: Existe um documento com o titulo igual a ‘titulo’.
Retorno: Retorna uma string com um comando sql.

Classe: Documento.
Consulta: preparaConsultaPorDataDoDocumento(data:String).
Pré-Condição: Existe um documento com a data igual a ‘data’.
64

Retorno: Retorna uma string com um comando sql.

Classe: Documento.
Consulta: preparaInclusaoDoDocumento(Codigo_loc:Int,Codigo_Categ:Int,
Assunto:Sting,Informação:String,
Mat_usu:Int,Data:String).
Pré-Condição: Não existe um assunto do documento igual a “Assunto”.
Retorno: Retorna uma string com um comando sql.

Classe: Documento.
Consulta: preparaAlteracaoDoDocumento(codgcateg:Int,assunto:String,
informacao:String,data:String,
codgdoc:Int).
Pré-Condição: Existe um assunto do documento igual a “Assunto”.
Retorno: Retorna uma string com um comando sql.

Classe: Documento.
Consulta: preparaExclusaoDoDocumento(codigo:Int).
Pré-Condição: Existe um documento com a data igual a ‘data’.
Retorno: Retorna uma string com um comando sql.

Classe: Documento.
Operação: efetuaAtualizacao(umStringSql:String, umaOpcao:String).
Pré-Condição: Existe um comando sql com a sintaxe igual a ‘umStringSql’.
Existe uma opção igual a ‘umaOpcao’.
Pós-Condição: O banco de dados foi atualizado.

Classe: Documento.
Consulta: efetuaConsulta(umStringSql:String).
Pré-Condição: Existe um comando sql com a sintaxe igual a ‘umStringSql’.
Retorno: Retorna um array com os dados requisitados pelo comando sql.
Classe: Despacho.
Consulta: preparaConsultaPeloCodigoDoDocumento(codgdoc:Int).
Pré-Condição: Existe um código de documento igual a ‘codgdoc’.
Retorno: Retorna um array com os dados requisitados pelo comando sql.

Classe: Despacho.
Consulta: preparaConsultaDoDespachoEnvia(local:Int).
Pré-Condição: Existe um código do local atual igual a ‘local’ e a data do envio nula.
Retorno: Retorna um array com os dados requisitados pelo comando sql.

Classe: Despacho.
Consulta: preparaConsultaDoDespachoRecebe(local:Int).
Pré-Condição: Existe um código do local de destino igual a ‘local’ e a data de
recebimento nula.
Retorno: Retorna um array com os dados requisitados pelo comando sql.

Classe: Despacho.
65

Consulta: preparaConsultaDoDespachoAtualiza(documento:Int,local:Int).
Pré-Condição: Existe um código do documento igual a ‘documento’, o código do
local de destino igual a ‘local’ e a data de recebimento nula.
Retorno: Retorna um array com os dados requisitados pelo comando sql.

Classe: Despacho.
Consulta: preparaInclusaoDoDespachoParcial(Codigo_doc:Int,Local_ant:Int,
Local_atual:Int).
Pré-Condição: Um novo documento foi cadastrado ou um documento foi recebido.
Retorno: Retorna um array com os dados requisitados pelo comando sql.

Classe: Despacho.
Consulta: preparaAlteracaoDoDespachoEnvia(codgdoc:Int,destino:Int,
data:String, hora:String).
Pré-Condição: Um documento foi enviado para um local de destino igual a ‘destino’.
Retorno: Retorna um array com os dados requisitados pelo comando sql.

Classe: Despacho.
Consulta: preparaAlteracaoDoDespachoRecebe(codgdoc:Int, data:String,
hora:String)
Pré-Condição: Um documento foi recebido.
Retorno: Retorna um array com os dados requisitados pelo comando sql.

Classe: Despacho.
Operação: efetuaAtualizacao(umStringSql:String, umaOpcao:String).
Pré-Condição: Existe um comando sql com a sintaxe igual a ‘umStringSql’.
Existe uma opção igual a ‘umaOpcao’.
Pós-Condição: O banco de dados foi atualizado.

Classe: Despacho.
Consulta: efetuaConsulta(umStringSql:String).
Pré-Condição: Existe um comando sql com a sintaxe igual a ‘umStringSql’.
Retorno: Retorna um array com os dados requisitados pelo comando sql.
66

3.4.2. Projeto
3.4.2.1. Diagrama de Classes do SEP

Figura 28: Diagrama de Classes do SEP.


67

3.4.2.2. Diagrama Entidade-Relacionamento

Figura 29: Diagrama Entidade – Relacionamento do SEP.


68

3.4.2.3. Dicionário de Dados

3.4.2.3.1. Entidades

Categoria
Primary Foreign
Nome Tipo Tamanho Precisao Not Null Unique Comentário
Key Key
codigo_categ INTEGER 3 OK OK OK
desc_categ VARCHAR 30

Usuário
Primary Not
Nome Tipo Tamanho Precisao Foreign Key Unique Comentário
Key Null
Matricula INTEGER 6 OK OK OK
nome_usu VARCHAR 31
Cargo VARCHAR 30
codigo_loc INTEGER 3 FK_usuário_codigo_loc OK
info_acesso CHAR 1
Login VARCHAR 10
Senha VARCHAR 6

Documentos
Primary Not Comen
Nome Tipo Tamanho Precisao Foreign Key Unique
Key Null tário
codigo_doc INTEGER 6 OK OK OK
codigo_loc INTEGER 3 FK_documento_codigo_loc OK
codigo_categ INTEGER 3 FK_documento_codigo_categ OK
Titulo VARCHAR 31
Descricao VARCHAR 300
Matricula INTEGER 6 FK_documento_matricula OK
data_cadastro VARCHAR 10

Local
Primary Foreign
Nome Tipo Tamanho Precisao Not Null Unique Comentário
Key Key
codigo_loc INTEGER 3 OK OK OK
nome_loc VARCHAR 30

Despacho
Primary Not
Nome Tipo Tamanho Precisao Foreign Key Unique Comentário
Key Null
codigo_desp INTEGER 3 OK OK OK
codigo_doc INTEGER 6 FK_despacho_codigo_doc OK
local_ant INTEGER 3 FK_despacho_local_ant OK
local_atual INTEGER 3 FK_despacho_local_atual
local_dest INTEGER 3 FK_despacho_local_dest OK
data_envio VARCHAR 10
hora_envio VARCHAR 5
data_recebe VARCHAR 10
hora_recebe VARCHAR 5
69

3.4.2.3.2. Relacionamentos

FK_documento_matricula
Tipo 1 -|----o< N
Tabela usuário
RF
Atributo matricula
Tabela documentos
FK
Atributo matricula
RF = Tabela e atributo referenciado.
FK = Tabela e atributo da chave estrangeira.

FK_documento_codigo_loc
Tipo 1 -|----o< N
Tabela local
RF
Atributo codigo_loc
Tabela documentos
FK
Atributo codigo_loc
RF = Tabela e atributo referenciado.
FK = Tabela e atributo da chave estrangeira.

FK_documento_codigo_categ
Tipo 1 -|----o< N
Tabela categoria
RF
Atributo codigo_categ
Tabela documentos
FK
Atributo codigo_categ
RF = Tabela e atributo referenciado.
FK = Tabela e atributo da chave estrangeira.

FK_usuário_codigo_loc
Tipo 1 -|----o-- 1
Tabela local
RF
Atributo codigo_loc
Tabela usuário
FK
Atributo codigo_loc
RF = Tabela e atributo referenciado.
FK = Tabela e atributo da chave estrangeira

FK_despacho_codigo_doc
Tipo 1 -|----o< N
Tabela documentos
RF
Atributo codigo_doc
Tabela despachos
FK
Atributo codigo_doc
RF = Tabela e atributo referenciado.
FK = Tabela e atributo da chave estrangeira.

FK_despacho_local_atual
Tipo 0..1 -o----o< N
Tabela local
RF
Atributo codigo_loc
Tabela despachos
FK
Atributo local_atual
RF = Tabela e atributo referenciado.
FK = Tabela e atributo da chave estrangeira.
70

FK_despacho_local_dest
Tipo 1 -|----o< N
Tabela local
RF
Atributo codigo_loc
Tabela despachos
FK
Atributo local_dest
RF = Tabela e atributo referenciado.
FK = Tabela e atributo da chave estrangeira.

FK_despacho_local_ant
Tipo 1 -|----o< N
Tabela local
RF
Atributo codigo_loc
Tabela despachos
FK
Atributo local_ant
RF = Tabela e atributo referenciado.
FK = Tabela e atributo da chave estrangeira.
71

3.4.2.4. Diagrama de Navegação do SEP

Figura 30: Diagrama de Navegação do SEP.


72

3.4.2.5. Projeto Gráfico das janelas e associação de controles

Figura 31: Projeto Gráfico da Janela Login.

Login
Campo “Usuário”:
Campo alfanumérico com 10 posições.
Efetua consulta do usuário executando Usuário.preparaConsultaPeloLogin(login).
Campo “Senha”:
Campo alfanumérico com 6 posições.
Botão “Entrar”:
Ativa a operação Home.validacao().
Ativa a consulta Usuário.preparaConsultaPeloLogin(login).
Navegação para “Principal”.
73

Figura 32: Projeto Gráfico da Janela Principal.

Principal
Botão “Documentos”:
Navegação para “Manter Documentos”.
Botão “Despachos”:
Navegação para “Efetuar Despachos”.
Botão “Pesquisar”:
Navegação para “Pesquisar Documentos”.
Botão “Relatórios”:
Navegação para “Emitir Relatórios”.
Botão “Categorias”:
Navegação para “Manter Categorias”.
Botão “Locais”:
Navegação para “Manter Locais”.
Botão “Usuários”:
Navegação para “Manter Usuários”.
Botão “Sair”:
Navegação para “Login”.
74

Figura 33: Projeto Gráfico da Janela Documentos.

Manter Documentos
Inicialização:
Habilita o campo “Código”.
Nível 1: Habilita os botões “Exibir” e “Novo”
Desabilita os botões “Alterar” e “Excluir”.
Nível 2: Habilita os botões “Exibir”, “Novo”, “Alterar” e “Excluir”.
Desabilita:
Os botões “confirmar” e “limpar”.
Os campos “Data”, “Assunto” e “Informações”.
O menu “Categoria”.
Campo “Código”:
Campo numérico com 06 posições.
Efetua consulta do documento executando:
Documento.preparaConsultaPorCodigoDoDocumento(codgdoc).
Botão “Exibir”:
Ativa a operação Home.habilitar(documentos).
Desabilita o botão “Confirmar”.
Ativa a consulta:
Documento.preparaConsultaPorCodigoDoDocumento(codgdoc).
Ativa a consulta Documento.efetuaConsulta().
Preenche todos os campos com seus dados.
Botão “Novo”:
Ativa a operação Home.habilitar(documentos).
Habilita o botão “Confirmar”.
Limpa todos os campos.
75

Botão “Alterar”:
Ativa a operação Home.habilitar(documentos).
Habilita o botão “Confirmar”.
Ativa a consulta:
Documento.preparaConsultaPorCodigoDoDocumento(codgdoc).
Ativa a consulta Documento.efetuaConsulta().
Preenche todos os campos com seus dados.
Botão “Excluir”:
Ativa a operação Home.habilitar(documentos).
Habilita o botão “Confirmar”.
Ativa a consulta:
Documento.preparaConsultaPorCodigoDoDocumento(codgdoc).
Ativa a consulta Documento.efetuaConsulta().
Preenche todos os campos com seus dados.
Menu “Categoria”:
CombList com todas as categorias cadastradas.
Campo “Data”:
Campo tipo DatePicker para escolha da data.
Campo “Assunto”:
Campo alfanumérico com 60 posições.
Efetua consulta do assunto do documento executando:
Documento.preparaConsultaPorTituloDoDocumento(assunto).
Campo “Informações”:
Campo alfanumérico com 300 posições.
Botão “Confirmar”:
Se sessão “confirma” igual a novo:
Ativa a consulta Usuário.preparaConsultaPeloLogin(login).
Ativa a consulta Usuário.efetuaConsulta().
Ativa a operação:
Documento.preparaInclusaoDoDocumento(codgloc, codgcateg,
assunto, informacao,
mat_usu, data).
Ativa a operação Documento.efetuaAtualizacao().
Se sessão “confirma” igual a alterar:
Ativa a consulta:
Documento.preparaAlteracaoDoDocumento(codgcateg, assunto,
informacao, data,
codgdoc).
Ativa a operação Documento.efetuaAtualizacao().
Se sessão “confirma” igual a excluir:
Ativa a consulta Documento.preparaExclusaoDoDocumento(codgdoc).
Ativa a operação Documento.efetuaAtualizacao().
Ativa a operação Home.desabilitar(documentos).
Botão “Limpar”:
Limpa todos os campos.
Ativa a operação Home.desabilitar(documentos).
76

Figura 34: Projeto Gráfico da Janela Usuários.

Manter Usuários
Inicialização:
Ativa a consulta Usuário.preparaConsultaGeral().
Ativa a consulta Usuário.efetuaConsulta().
Habilita o ComboList.
Nível 1: Habilita os botões “Exibir” e “Novo”.
Desabilita os botões “Alterar” e “Excluir”.
Nível 2: Habilita os botões “Exibir”, “Novo”, “Alterar” e “Excluir”.
Desabilita:
Os botões “confirmar” e “limpar”.
Os campos “Nome”, “Matricula”, “Cargo”, “Usuário” e “Senha”.
Os botões RadioButtonList de permissão.
O menu “Local”.
ComboList:
Resultado da consulta Usuário.preparaConsultaGeral().
Botão “Exibir”:
Ativa a operação Home.habilitar(usuario).
Desabilita o botão “Confirmar”.
Ativa a consulta Usuário.preparaConsultaPorNomeDoUsuario(usuário).
Ativa a consulta Usuário.efetuaConsulta().
Preenche todos os campos com seus dados.
Botão “Novo”:
Ativa a operação Home.habilitar(usuarios).
Habilita o botão “Confirmar”.
Limpa todos os campos.
Botão “Alterar”:
77

Ativa a operação Home.habilitar(usuarios).


Habilita o botão “Confirmar”.
Ativa a consulta Usuário.preparaConsultaPorNomeDoUsuario(usuário).
Ativa a consulta Usuário.efetuaConsulta().
Preenche todos os campos com seus dados.
Botão “Excluir”:
Ativa a operação Home.habilitar(usuarios).
Habilita o botão “Confirmar”.
Ativa a consulta Usuário.preparaConsultaPorNomeDoUsuario(usuário).
Ativa a consulta Usuário.efetuaConsulta().
Preenche todos os campos com seus dados.
Campo “Nome”:
Campo alfanumérico com 31 posições.
Efetua consulta do usuário executando:
Usuário.preparaConsultaPorNomeDoUsuario(nome)
Campo “Matricula”:
Campo alfanumérico com 06 posições.
Campo “Cargo”:
Campo alfanumérico com 30 posições.
Menu “Local”:
ComboList com todos os locais cadastrados.
Botões RadioButtonList de permissão:
Determina qual tipo de permissão o usuário vai ter.
Campo “Usuário”:
Campo alfanumérico com 10 posições.
Campo “Senha”:
Campo alfanumérico com 06 posições.
Botão “Confirmar”:
Se sessão “confirma” igual a novo:
Ativa a consulta:
Usuário.preparaInclusaoDoUsuario(matricula, nome, cargo, codgloc,
acesso, usuario, senha).
Ativa a operação Usuário.efetuaAtualizacao().
Se sessão “confirma” igual a alterar:
Se usuário e senha não vazios:
Ativa a consulta:
Usuário.preparaAlteracaoDoUsuarioCompleto(matricula,
nome, cargo, codgloc, acesso, usuario, senha).
Ativa a operação Usuário.efetuaAtualizacao().
Se usuário e senha vazios:
Ativa a consulta do sistema:
Usuário.preparaAlteracaoDoUsuarioIncompleto(matricula,
nome, cargo, codgloc, acesso).
Ativa a operação Usuário.efetuaAtualizacao().
Se sessão “confirma” igual a excluir:
Ativa a consulta Usuário.preparaExclusaoDoUsuario(matricula).
Ativa a operação Usuário.efetuaAtualizacao().
Ativa a operação Home.desabilitar(usuarios).
Botão “Limpar”:
78

Limpa todos os campos.


Ativa a operação Home.desabilitar(usuarios).

Figura 35: Projeto Gráfico da Janela Locais.

Manter Locais
Inicialização:
Ativa a consulta Local.preparaConsultaGeral().
Ativa a consulta Local.efetuaConsulta().
Habilita ComboList.
Nível 1: Habilita o botão “Novo”
Desabilita os botões “Alterar” e “Excluir”.
Nível 2: Habilita os botões “Novo”, “Alterar” e “Excluir”.
Desabilita o campo “Local” e os botões “confirmar” e “limpar”.
ComboList:
Resultado da consulta Local.preparaConsultaGeral().
Botão “Novo”:
Ativa a operação Home.habilitar(locais).
Limpa o campo “Local”.
Botão “Alterar”:
Ativa a operação Home.habilitar(locais).
O item selecionado no menu preenche o campo “Local”.
Botão “Excluir”:
Ativa a operação Home.habilitar(locais).
O item selecionado no ComboList preenche o campo “Local”.
Campo “Local”:
Campo alfanumérico com 30 posições.
79

Efetua consulta do local executando:


Local.preparaConsultaPorNomeDoLocal(local).
Botão “Confirmar”:
Ativa a consulta Local.preparaConsultaPorNomeDoLocal(local).
Ativa a consulta Local.efetuaConsulta().
Se sessão “confirma” igual a novo:
Ativa a consulta Local.preparaInclusaoDoLocal(local).
Ativa a operação Local.efetuaAtualizacao().
Se sessão “confirma” igual a alterar:
Ativa a consulta Local.preparaAlteracaoDoLocal(local).
Ativa a operação Local.efetuaAtualizacao().
Se sessão “confirma” igual a excluir:
Ativa a consulta Local.preparaExclusaoDoLocal(local).
Ativa a operação Local.efetuaAtualizacao().
Ativa a operação Home.desabilitar(locais).
Botão “Limpar”:
Limpa o campo “Local”.
Ativa a operação Home.desabilitar(usuarios).

Figura 36: Projeto Gráfico da Janela Categorias.

Manter Categorias
Inicialização:
Ativa a consulta Categoria.preparaConsultaGeral().
Ativa a consulta Categoria.efetuaConsulta().
Habilita ComboList.
Nível 1: Habilita o botão “Novo”
80

Desabilita os botões “Alterar” e “Excluir”.


Nível 2: Habilita os botões “Novo”, “Alterar” e “Excluir”.
Desabilita o campo “Categoria” e os botões “confirmar” e “limpar”.
ComboList:
Resultado da consulta Categoria.preparaConsultaGeral().
Botão “Novo”:
Ativa a operação Home.habilitar(categorias).
Limpa o campo “Categoria”.
Botão “Alterar”:
Ativa a operação Home.habilitar(categorias).
O item selecionado no ComboList preenche o campo “Categoria”.
Botão “Excluir”:
Ativa a operação Home.habilitar(categorias).
O item selecionado no ComboList preenche o campo “Categoria”.
Campo “Categoria”:
Campo alfanumérico com 30 posições.
Efetua consulta da categoria executando:
Categoria.preparaConsultaPorNomeDaCategoria(categoria).
Botão “Confirmar”:
Ativa a consulta Categoria.preparaConsultaPorNomeDaCategoria(categoria).
Ativa a consulta Categoria.efetuaConsulta().
Se sessão “confirma” igual a novo:
Ativa a consulta Categoria.preparaInclusaoDaCategoria(categoria).
Ativa a operação Categoria.efetuaAtualizacao().
Se sessão “confirma” igual a alterar:
Ativa a consulta Categoria.preparaAlteracaoDoCategoria(categoria).
Ativa a operação Categoria.efetuaAtualizacao().
Se sessão “confirma” igual a excluir:
Ativa a consulta Categoria.preparaExclusaoDoCategoria(categoria).
Ativa a operação Categoria.efetuaAtualizacao().
Ativa a operação Home.desabilitar(categorias).
Botão “Limpar”:
Limpa o campo “Categoria”.
Ativa a operação Home.desabilitar(categorias).
81

Figura 37: Projeto Gráfico da Janela Pesquisar Documentos.

Pesquisar Documentos
Inicialização:
Habilita os botões RadioButtonList dos tipos de pesquisas.
Habilita o campo “Código”.
Habilita os botões “OK” e “LIMPAR”.
Botão RadioButtonList “Codigo”:
Habilita o campo “Codigo”.
Desabilita os outros campos.
Botão RadioButtonList “Categoria”:
Habilita o ComboList.
Desabilita os outros campos.
Botão RadioButtonList “Local”:
Habilita o ComboList.
Desabilita os outros campos.
Botão RadioButtonList “Data”:
Habilita o campo “Data”.
Desabilita os outros campos.
Botão RadioButtonList “Todos”:
Desabilita todos os campos.
Campo “Codigo”:
Campo numérico com 06 posições.
Efetua consulta do documento executando:
Documento.preparaConsultaPorCodigoDoDocumento(codgdoc).
Menu “Categorias”:
ComboList com todas as categorias cadastradas.
Menu “Locais”:
ComboList com todos os locais cadastrados.
82

Campo “Data”:
Campo tipo DatePicker para escolha da data.
Botão “Ok”:
Ativa as consulta:
Categoria.preparaConsultaPorCodigoDaCategoria(categoria).
Local.preparaConsultaPorCodigoDoLocal(local).
Ativa a consulta Documento.efetuaConsulta().
Ativa a consulta Categoria.efetuaConsulta().
Ativa a consulta Local.efetuaConsulta().
Botão “Limpar”:
Limpa todos os campos.

Figura 38: Projeto Gráfico da Janela Despachos.

Despachos
Inicialização:
Habilita os botões “Envia” e “Recebe”.
Botão “Envia”:
Navegação para “Despachos-Enviar”.
Botão “Recebe”:
Navegação para “Despachos-Receber”.
83

Figura 39: Projeto Gráfico da Janela Despachos – Enviar.

Despachos – Enviar
Inicialização:
Ativa as consultas do sistema:
Usuário.preparaConsultaPeloLogin(login).
Despacho.preparaConsultaDoDespachoEnvia(local).
Documento.preparaConsultaPorCodigoDoDocumento(codgdoc).
Local.preparaConsultaGeral(local).
Ativa a consulta Usuário.efetuaConsulta().
Ativa a consulta Despacho.efetuaConsulta().
Ativa a consulta Documento.efetuaConsulta().
Ativa a consulta Local.efetuaConsulta().
Habilita menu “Documento”.
Habilita menu “Destino” e os botões “Confirmar” e “Voltar”.
Menu “Documento”:
ComboList com todos os documentos a serem enviados no local do usuário.
Menu “Destino”:
ComboList com todos os locais cadastrados.
Botão “Confirmar”:
Ativa as consultas do sistema:
Documento.preparaConsultaPorTituloDoDocumento(assunto).
Local.preparaConsultaGeral(nome do local).
Documento.preparaConsultaPeloCodigoDoDocumento(codgdoc).
Despacho.preparaAlteracaoDoDespachoEnvia(codgdoc, local, data,hora).
Ativa a operação Documento.efetuaAtualizacao().
Ativa a consulta Local.efetuaConsulta().
Ativa a consulta Despacho.efetuaConsulta().
Botão “Limpar”:
84

Navegação para “Despachos”.

Figura 40: Projeto Gráfico da Janela Despachos – Receber.

Despachos – Receber
Inicialização:
Ativa as consultas do sistema:
Usuário.preparaConsultaPeloLogin(login).
Despacho.preparaConsultaDoDespachoRecebe (local).
Documento.preparaConsultaPorCodigoDoDocumento(codgdoc).
Ativa a consulta Usuário.efetuaConsulta().
Ativa a consulta Despacho.efetuaConsulta().
Ativa a consulta Documento.efetuaConsulta().
Habilita menu “Documento” e os botões “Confirmar” e “Voltar”.
Menu “Documento”:
ComboList com todos os documentos a serem recebidos no local do usuário
Botão “Confirmar”:
Ativa as consultas do sistema:
Documento.preparaConsultaPorTituloDoDocumento(assunto).
Usuário.preparaConsultaPeloLogin(login).
Despacho.preparaConsultaDoDespachoAtualiza(codgdoc,codgloc).
Despacho.preparaAlteracaoDoDespachoRecebe(codgdoc,data, hora).
Despacho.preparaInclusaoDoDespachoParcial(codgdoc,codglocAnt,codgloc).
Ativa a operação Documento.efetuaAtualizacao().
Ativa a consulta Usuário.efetuaConsulta().
Ativa a consulta Despacho.efetuaConsulta().
Botão “Limpar”:
85

Navegação para “Despachos”.

Figura 41: Projeto Gráfico da Janela Relatórios.

Emitir Relatórios
Inicialização:
Habilita o campo data inicial, o campo data final, o campo “Código do
Documento” e o botão “Ok”.
Campo “Data Inicial”:
Campo tipo DatePicker para escolha da data inicial.
Campo “Data Final”:
Campo tipo DatePicker para escolha da data final.
Campo “Código do Documento”:
Campos numérico com 06 posições.
Efetua consulta do documento executando:
Despacho.preparaConsultaPeloCodigoDoDocumento(codigo).
Botão “Ok”:
Ativa a consulta Despacho.efetuaConsulta().
Ativa a operação Home.imprimeRel(dataini,datafim,dados).
86

3.4.3. Considerações Técnicas

3.4.3.1. Diretório do SEP

A estrutura de diretórios do SEP segue a estrutura clássica de uma aplicação Prado,


sendo que dentro do diretório www deve ficar as pastas referentes à aplicação, a pasta de
framework Prado e ainda a pasta relativa ao banco de dados como mostra a figura 42.

Figura 42: Diretório do SEP.

3.4.3.2. Arquitetura do SEP

A arquitetura interna do SEP segue a arquitetura de qualquer aplicação que utiliza o


framework Prado, sendo composta por um arquivo .page que é a view (visão) do sistema. O
controle é definido em um arquivo .php, através da classe controladora do sistema (Home).
Existem outros arquivos .php que são as classes do sistema propriamente dito, ou seja, a parte
que modela o sistema. Por fim temos a conexão com o banco de dados, no caso utilizamos o
Gerenciador MySQL. Essa arquitetura está representada na figura 43.

Figura 43: Arquitetura do SEP.


DESENVOLVIMENTO DE SISTEMA ELETRÔNICO DE PROTOCOLO
COM FRAMEWORK PRADO

CAPÍTULO IV
CONCLUSÃO

O objetivo de desenvolver uma aplicação para verificar na prática as dificuldades


encontradas no decorrer do processo de desenvolvimento se mostrou digno do esforço. O
inicio dos trabalhos referentes à produção do software proporcionou a experiência desejada. A
prática da teoria estudada em engenharia de software mostrou-se bastante enriquecedora por
oferecer o cenário que será enfrentado no dia a dia do profissional envolvido com a criação de
software. A utilização das metodologias sugeridas na disciplina revelou-se eficiente assim
como pontos de dificuldade previstos nos modelos teóricos ocorreram.

Desde a dificuldade na definição do escopo do projeto até a elicitação dos requisitos


junto aos usuários, observou-se a eficácia de técnicas recomendadas em sala de aula, assim
como os desafios apontados pelos professores. No desenvolvimento dos artefatos da análise e
de projeto evidenciou-se a necessidade de conhecer bem o que cada um destes documentos
podem oferecer e a dificuldade em produzi-los de forma ao mesmo tempo clara e fiel ao
projeto proposto.

A utilização de conceitos e técnicas que visam diminuir o esforço na produção dos


artefatos gerados no desenvolvimento de software e que aumentam o reuso destes artefatos
mostrou-se digna do empenho em se adaptar e pesquisar sobre as mesmas. A utilização da
UML na modelagem da análise e projeto proporcionou uma clareza fundamental na
implementação, o fato de ser uma notação orientada a objetos trouxe facilidades na aplicação
deste conceito que aliado ao uso de um framework também orientado a objetos gerou uma
significativa redução de tempo e esforço no desenvolvimento, assim como na sua
88

manutenção. A utilização do framework mostrou-se digna do esforço em compreende-lo


trazendo a certeza de que sua adoção traz grandes benefícios a produção de software.

O produto final do trabalho pode ser divido em dois, o primeiro diz respeito ao
Sistema Eletrônico de Protocolo, que ao ser implantado na Fundação Aroeira certamente
garantirá o gerenciamento pretendido pelos clientes no início do projeto, podendo inclusive
evoluir para um Sistema Gerenciador de Documentos onde não apenas as informações a cerca
da documentação é gerenciada, mas também a própria informação é mantida em repositórios
específicos na forma de arquivos eletrônicos.

O segundo produto obtido é o conhecimento adquirido pela equipe de


desenvolvimento no decorrer do projeto. É grande o entusiasmo gerado pela aplicação da
Uml, Orientação a Objetos, framework e do Processo Unificado no desenvolvimento de uma
aplicação Web, sendo certa a utilização destes mesmos conceitos em projetos que a equipe já
planeja desenvolver. O objetivo de todos os envolvidos no projeto foi alcançado.
89

REFERÊNCIAS BIBLIOGRÁFICAS

[1]. Booch, Grady. Rumbaugh, James. Jacobson, Ivar. UML guia do usuário.
Rio de Janeiro: Campos, 2000.

[2]. Deboni, José Eduardo Zindel. Modelagem orientada a objetos com a UML.
São Paulo: Futura, 2003.

[3]. Wazlawick, Raul Sidnei. Análise e projeto de sistemas de informação orientados a


objetos.
Rio de Janeiro: Elsevier, 2004.

[4]. Gamma, Erich. Helm, Richard. Johnson, Ralph. Vlissides, John. Padrões de projeto:
soluções reutilizáveis de software orientado a objetos.
Porto Alegre: Bookman, 2000.

[5]. Silva, Ricardo Pereira e. Trabalho de Pós-graduação em Ciência da computação:


Avaliação de metodologias de análise e projeto orientadas a objetos voltadas ao
desenvolvimento de aplicações, sob a ótica de sua utilização no desenvolvimento de
frameworks orientados a objetos. Porto Alegre, Universidade Federal do Rio Grande do Sul,
Instituto de Informática. julho de 1996.

[6]. Niederst, Jennifer: Aprenda Web design.


Rio de janeiro: Editora Ciência Moderna Ltda., 2002.

[7]. Site do Framework Prado.


Disponível em: http://www.pradosoft.com - Visitado em: 04 de Novembro de 2006.
90

GLOSSÁRIO

Browser: Programa que permite a interação com documentos hospedados num servidor web.
Javascript: Linguagem de programação de computadores.
Servidor Web: Computador responsável por atender as requisições http de uma aplicação.
Stakeholder: Todos os envolvidos num processo.
91

ANEXO A

PAUTA DA 1º REUNIÃO

I.Informações Gerais

Nome do Projeto: Sistema Eletrônico de Protocolo Data: 20/09/2006


Tipo de Reunião: Definição do Escopo do Projeto Horário inicial: 17:00 HS
Local de Realização: Fundação Aroeira Horário final: 18:00 HS

II.Desenvolvimento da Reunião

A reunião teve inicio com a definição de que a funcionária Suellen Ribeiro será nosso
contato com a Fundação para toda informação que se faça necessária sobre o projeto,
assumindo a responsabilidade por repassar as decisões de competência superior e comunicá-
las aos Analistas.
A funcionária explicou como é realizado o controle da documentação da Fundação
atualmente, a atividade de controle da documentação é feita através de cadernos para
anotações e formulários de autuação da documentação tendo seu preenchimento à mão.
Quando um documento chega à Fundação a funcionária o registra no documento de autuação
e em seguida o encaminha ao devido local, o controle de quem recebeu o documento é feito
anotando-se informações como o nome e data do recebimento pelo responsável em um
caderno de anotações.
Ao se questionar os objetivos desejados com a implantação do Sistema Eletrônico de
Protocolo, definiu-se em consenso entre os participantes o seguinte:

• Maior controle por parte da administração sobre a documentação que circula na


Fundação;
• Democratização da informação, ou seja, todos terão acesso a informações (como o
local atual em que se encontra) sobre documentos e processos da Fundação;
• Possibilitar a observação e análise da forma como os documentos caminham dentro da
Fundação através de relatórios;
92

• A otimização da busca pela documentação de forma ágil e sem informações


desencontradas;
• Segurança da informação, ou seja, a certeza de onde, com quem e a quanto tempo está
um determinado documento.

III.Tarefas a serem cumpridas

• Definição formal do escopo do projeto;


• Definir agenda para nova reunião;

IV.Observações

V.Participantes
Nome do participante Função Assinatura
Suellen Ribeiro Usuário
Jandilson de Morais Oliveira Analista
93

ANEXO B

PAUTA DA 2º REUNIÃO

I.Informações Gerais

Nome do Projeto: Sistema Eletrônico de Protocolo Data: 28/09/2006


Tipo de Reunião: Definição do Escopo do Projeto Horário inicial: 17:00 HS
Local de Realização: Fundação Aroeira Horário final: 18:00 HS

II.Desenvolvimento da Reunião

A segunda reunião iniciou-se com a leitura e aprovação da Pauta da reunião anterior


pela funcionária Suellen Ribeiro. Em seguida houve uma segunda avaliação sobre o que
realmente o Sistema deve contemplar que resultou na ratificação do que foi proposto
anteriormente.
Após foi feita a coleta de informações mais detalhadas como a obtenção de uma cópia
do formulário de autuação de documentos impressa, uma cópia do organograma da empresa
que será útil para visualização do fluxo de informação dentro da Fundação e estudo
superficial das condições da rede de informática existente na Fundação.

III.Tarefas a serem cumpridas

• Definição formal do escopo do projeto;


• Elaboração do documento de visão geral do Sistema.

IV.Observações
V.Participantes
Nome do participante Função Assinatura
Suellen Ribeiro Usuário
Jandilson de Morais Oliveira Analista de Sistemas
João Luis da Costa Leandro Analista de Sistemas
94

ANEXO C

Termo de Abertura do Projeto

I.Informações Gerais

Nome do Projeto: Sistema Eletrônico de Protocolo - SEP Data: 27/10/2006

II.Objetivo do Projeto

O projeto tem como objetivo o desenvolvimento de um Sistema Eletrônico de


Protocolo (SEP) para a Fundação Aroeira, com o propósito de automatizar a rotina de
circulação de documentos trazendo agilidade, praticidade e segurança.

III.Visão Geral do Projeto

O Sistema Eletrônico de Protocolo permitirá registrar todos os documentos que


chegam à Fundação Aroeira, assim como documentos e correspondências emitidas pelos
setores internos.

O Sistema permitirá o cadastro de usuários (funcionários) que o utilizarão, tal cadastro


será realizado com os dados funcionais gerando um nome de usuário e uma senha que
especificam o nível do usuário. O nível de usuário define as ações que podem ser efetuadas,
sendo que o nível de um usuário será o de administrador e de usuário comum, onde o primeiro
possui todas as permissões de uso do Sistema e o segundo possui permissões de acordo com o
configurado pelo administrador. Isto possibilitará restrições de acesso a certas informações
conforme a configuração estabelecida para um determinado usuário.

Além do cadastro de usuários será feito o cadastro dos ambientes em que a


documentação circula permitindo ao Sistema acompanhar a evolução do documento na
Fundação Aroeira, assim sempre que uma divisão deixar de existir ou for criada, esta poderá
ser alterada também no sistema.
95

A utilização principal do Sistema se inicia com o cadastro específico do documento, o


qual receberá um número de identificação gerado pelo sistema. O Sistema atribuirá ao
documento o usuário que o cadastrou e o local de origem. O documento poderá então ser
mantido pelo sistema de acordo com as permissões de cada usuário.

Ao enviar um documento para outro local será feita a ação de “despachar” no Sistema
que consistirá em atribuir ao documento um local de destino, sendo o local atual do
documento alterado quando o usuário do destino conceder o “recebido” no Sistema.

O Sistema possibilitará o acompanhamento da tramitação da documentação na


Fundação Aroeira e o histórico de cada local em relação à documentação através de relatórios
que serão gerados a partir de parâmetros específicos.

O sistema será integrado à rede de informática existente na Fundação Aroeira sendo


disponibilizado a todos os usuários previamente cadastrados.

IV.Requisitos

• O sistema deve funcionar em rede;


• Manter usuários (Cadastrar, Excluir, Alterar e Pesquisar);
• Manter documentos (Cadastrar, Excluir, Alterar, Pesquisar e Despachar);
• Manter os locais internos e externos para movimentação dos documentos (Cadastrar,
Excluir, Alterar e Pesquisar);
• Segurança da informação (acesso ao sistema através de Senha e certeza em relação ao
Fluxo da Documentação);
• Definir permissões de uso aos usuários de acordo com atribuições;
• Relatórios (Usuários, Documentos, Locais, Datas e Históricos).

V.Justificativa

O Sistema Eletrônico de Protocolo permitirá que o usuário acompanhe “on line” o


andamento da documentação que lhe interessa, de forma segura e facilitada por buscas que
96

permitirão rastrear a documentação e a otimização dos procedimentos, facilitando o


monitoramento das informações sobre a documentação.

VI.Funções e Responsabilidades

Stakeholder Função Responsabilidade


Eugênio de Britto Jardim Patrocinador Aprovação de cada etapa e do produto
final.
Suellen Ribeiro Usuário Fornecer informações, críticas e
sugestões sobre o negócio.
Jandilson de Morais Oliveira Analista Análise e Desenvolvimento do
Projeto.
João Luiz da Costa Leandro Analista Análise e Desenvolvimento do
Projeto.
Funcionários em geral Usuários Compromisso e empenho no
treinamento e utilização do produto.

VII. Assinaturas

Goiânia, 27/10/2006

Desenvolvedores,

_______________________________ _____________________________
Jandilson de Morais Oliveira João Luiz da Costa Leandro

Pela Fundação Aroeira,

_______________________________ _____________________________
Suellen Riberio. Eugênio de Britto Jardim
97

ANEXO D

Documento de Requisitos e Análise do Sistema – SEP

I. Informações Gerais

Nome do Projeto: Sistema Eletrônico de Protocolo - SEP Data: 24/11/2006

II. Objetivo do Projeto

O projeto tem como objetivo o desenvolvimento de um Sistema Eletrônico de


Protocolo (SEP) para a Fundação Aroeira, com o propósito de automatizar a rotina de
circulação de documentos trazendo agilidade, praticidade e segurança.

1. Lista Geral de Requisitos

Tipo do requisito:
UC = caso de uso; CC = conceito; CS = consulta; RE = relatório;
RN = Regra de negócio; OR = outros requisitos;
Nome Descrição Tipo
Manter usuários. O sistema deve suportar alteração de usuários. UC
Manter documentos. O sistema deve suportar a alteração dos documentos. UC
Manter locais. O sistema deve suportar a alteração de locais. UC
Efetuar despacho. O sistema permitirá que o usuário possa enviar e receber UC
um documento alterando o local atual do documento.
Gerar relatório. O sistema suportará a geração de relatórios com RE
diferentes parâmetros.
Funcionamento em rede. O sistema funcionará em rede permitindo o acesso de OR
qualquer terminal por um usuário apto.
Controle de acesso. Somente usuários previamente cadastrados terão acesso OR
ao sistema.
98

2. Cadastro de requisitos

Código: Funcional : FXXX , Não Funcional : NFXXX;


Prioridade: (Baixa, média ou Alta);
Categoria: (Segurança, Interface, Performance, Persistência, Confiabilidade, Implementação,
Empacotamento, Legal, Outros).

Nome do Requisito: Código: Categoria: Prioridade:


Manter usuário. F001 Implementação Média.
Descrição:
O sistema deve permitir a manutenção dos usuários (cadastro, exclusão, alteração e
consulta).
Justificativa:
Os usuários mudam com o tempo (funcionários são admitidos e demitidos).
Restrição:
Apenas o administrador do sistema pode realizar a manutenção dos usuários.
Requisitos relacionados:

Observações: Responsável:
Jandilson de Morais Oliveira;
João Luiz da Costa Leandro;

Nome do Requisito: Código: Categoria: Prioridade:


Manter documento. F002 Implementação Média.
Descrição:
O sistema deve permitir a manutenção das informações dos documentos (cadastro,
exclusão, alteração e consulta).
Justificativa:
Os documentos mudam com o tempo (documentos são gerados, recebidos e enviados).
Restrição:
Apenas usuários autorizados podem realizar a manutenção das informações dos
documentos.
99

Requisitos relacionados:

Observações: Responsável:
Jandilson de Morais Oliveira;
João Luiz da Costa Leandro;

Nome do Requisito: Código: Categoria: Prioridade:


Manter local. F003 Implementação Média.
Descrição:
O sistema deve permitir a manutenção dos locais (cadastro, exclusão, alteração e
consulta).
Justificativa:
Os locais mudam com o tempo (departamentos são criados e extintos, além de locais
externos).
Restrição:
Apenas o administrador do sistema pode realizar a manutenção dos locais.
Requisitos relacionados:

Observações: Responsável:
Jandilson de Morais Oliveira;
João Luiz da Costa Leandro;

Nome do Requisito: Código: Categoria: Prioridade:


Efetuar despacho. F004 Implementação Média.
Descrição:
O sistema deve permitir o despacho dos documentos.
Justificativa:
Os documentos são enviados/recebidos em cada local alterando assim as informações
referentes ao local de origem, local de destino, local atual e data da entrada/saída.
Restrição:
Apenas usuários autorizados podem efetuar despachos dos documentos.
Requisitos relacionados:
100

Observações: Responsável:
Jandilson de Morais Oliveira;
João Luiz da Costa Leandro;

Nome do Requisito: Código: Categoria: Prioridade:


Gerar relatório. F006 Implementação Média.
Descrição:
O sistema deve permitir a geração de relatórios de acordo com os parâmetros
especificados (local, usuário, documento e data).
Justificativa:
Os relatórios oferecem o histórico de cada parâmetro de entrada.
Restrição:
Apenas usuários autorizados podem gerar relatórios.
Requisitos relacionados:

Observações: Responsável:
Jandilson de Morais Oliveira;
João Luiz da Costa Leandro;

Nome do Requisito: Código: Categoria: Prioridade:


Arquivo de log. NF001 Segurança Alta.
Descrição:
O sistema deve manter um arquivo de log onde serão armazenadas informações
específicas.
Justificativa:
Oferecer possibilidade de auditoria.
Restrição:
Apenas o administrador pode acessar o arquivo de log.
Requisitos relacionados:

Observações: Responsável:
101

Jandilson de Morais Oliveira;


João Luiz da Costa Leandro;

Nome do Requisito: Código: Categoria: Prioridade:


Segurança da informação. NF002 Segurança Alta.
Descrição:
O acesso ao sistema será feito por meio de login e senha pré-definidos no ato de
cadastramento do usuário.
Justificativa:
Acesso ao sistema apenas por pessoas autorizadas.
Restrição:

Requisitos relacionados:

Observações: Responsável:
Jandilson de Morais Oliveira;
João Luiz da Costa Leandro;

III. Assinaturas

Goiânia, 24/11/2006.

Desenvolvedores,

_______________________________ _____________________________
Jandilson de Morais Oliveira João Luiz da Costa Leandro

Pela Fundação Aroeira,

_______________________________ _____________________________
Suellen Riberio. Eugênio de Britto Jardim

Вам также может понравиться