Soni

UNIVERSIDADE DO SUL DE SANTA CATARINA
SONI JOÃO DA SILVA
REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE PATRIMÔNIO DO

TRIBUNAL REGIONAL DO TRABALHO DE SANTA CATARINA
Palhoça
2010
SONI JOÃO DA SILVA

Trabalho de Conclusão de Curso apresentado ao Curso

de Graduação em Ciência da Computação da
Universidade do Sul de Santa Catarina, como requisito
parcial à obtenção do título de Bacharelado em Ciência
da Computação.
Prof. e orientador: Osmar de Oliveira Braz Júnior, Msc. Eng.
Prof. e co-orientador: Ricardo Villarroel Dávalos, Dr. Eng.
Palhoça
2010
SONI JOÃO DA SILVA

Este Trabalho de Conclusão de Curso foi julgado

adequado à obtenção do título Bacharelado em Ciência
da Computação e aprovado em sua forma final pelo
Curso de Graduação em Ciência da Computação da
Universidade do Sul de Santa Catarina.
Palhoça, 15 de junho de 2010.
______________________________________________________
Prof. e orientador: Osmar de Oliveira Braz Júnior, Msc. Eng.
Universidade do Sul de Santa Catarina
______________________________________________________
Prof. Vera Rejane Niedersberg Schuhmacher, Msc.
Universidade do Sul de Santa Catarina
______________________________________________________
Antonio Manoel da Silva
Autor e Membro da Academia Palhocense de Letras
Ao meu pai em memória e minha mãe pela
educação, caráter e incentivo na busca de um
ideal. A minha esposa e filhos pela paciência e
compreensão nos momentos de ausência
familiar.
AGRADECIMENTOS
Agradeço a Deus pela saúde e força de vontade ao longo desta caminhada.

À minha esposa Sônia companheira de todas as horas, que em muitos momentos
realizou seus afazeres e os meus, para que eu me dedicasse integralmente a esta empreitada.
Aos meus filhos: Vânio e Fabrício que no decorrer destes anos de dedicação aos
estudos na graduação, de crianças se tornaram homens, pela compreensão dos momentos que
não podemos compartilhar juntos.
Ao Mestre e amigo, professor Osmar de Oliveira Braz Junior orientador, pela
condução, apoio no trabalho e pelo conhecimento adquirido nas disciplinas ministradas no
decorrer do curso, que foram o alicerce para o nosso aprendizado bem como do trabalho aqui
documentado.
À professora Vera Rejane Niedersberg Schuhmacher pelos ensinamentos,
estímulo e apoio nessa trajetória.
Ao professor Ivo Zimmermann pela colaboração na correção ortográfica e
gramatical que foi de fundamental importância na valorização desta obra.
Ao professor Co-orientador: Dr. Eng. Ricardo Villarroel Dávalos pela colaboração.
A todos os professores que tiveram sua parcela na construção da nossa formação
acadêmica.
Aos familiares e amigos de modo geral pela compreensão e apoio.
Aos funcionários do Tribunal Regional do Trabalho de Santa Cataria, da
Secretaria de Informática do Serviço de Desenvolvimento de Sistema, Gustavo Bestetti Ibarra
pelo apoio e ajuda na opção do tema e o fornecimento das informações prestadas. A Glademir
Maria Silveira Sartori por acreditar e confiar às informações sobre o sistema atual, essenciais
e indispensáveis para a engenharia reversa. Do Setor de Cadastro e Administração de Bens
principalmente ao Antonio Manoel da Silva pela ajuda na compreensão das telas do sistema
atual e do Almoxarifado pelos esclarecimentos sobre a rotina de trabalho envolvendo o
sistema. Aos colegas do nosso Setor de Gráfica pelo apoio, em especial a Alexandre Zaia pela
compreensão e estímulo.
Que Deus os abençoe.
“... você tem dois pés para cruzar a ponte...” (Raul Seixas / Marcelo Motta / Paulo
Coelho).
RESUMO
O desenvolvimento de um sistema de software, robusto, de qualidade é caro, entretanto, em

sistemas legados, que, com o passar dos anos, acabam obsoletos, seja devido a mudanças
tecnológicas, ao surgimento de alguma implementação que a metodologia de
desenvolvimento encontra-se ultrapassada ou à linguagem de programação que ficou obsoleta,
a reengenharia desse sistema tem vantagens sobre a construção de um novo, partindo do zero,
por diminuir custos e riscos devido a erros e tempo de desenvolvimento, uma vez que irá
buscar os requisitos no sistema existente. A utilização do processo de desenvolvimento, IBM
Rational Unified Process (IBM RUP) customizado as necessidades do sistema, veio a agregar
valores à obra por conduzir esse processo de forma iterativa e incremental, documentando o
processo de desenvolvimento do sistema.
Palavras-chave: Reengenharia. Engenharia reversa. Engenharia avante. IBM RUP.

ABSTRACT
The development of a software system, robust, of quality is expensive, however, in legacy

systems, which over the years, eventually are obsolete, either due to technological change, the
rise of another implementation where the development methodology is exceeded by it or if the
programming language has become obsolete, the reengineering of this system has advantages
over building of a new one from scratch, by reducing costs and risks due to errors and
development time, as it will pick up the system requirements of existent system. The use of
the development process, IBM Rational Unified Process (RUP IBM) customized to the needs
of the system, came to add value to work for leading this process of iterative and incremental
way, documenting the process of system development.
Key words: Reengineering. Reverse engineering. Forwards engineering. IBM RUP.

LISTA DE ILUSTRAÇÕES
Figura 1 – Consulta ao sistema atual........................................................................................ 17

Figura 2 – Eolípila. ................................................................................................................... 23
Figura 3 – Reengenharia na construção civil............................................................................ 24
Figura 4 – Usuários de um documento de requisitos. .............................................................. 31
Figura 5 – Modelo em cascata.................................................................................................. 37
Figura 6 – Prototipação. ........................................................................................................... 38
Figura 7 – Modelo espiral......................................................................................................... 39
Figura 8 – Modelo iterativo e incremental. .............................................................................. 40
Figura 9 – Método Fusion. ....................................................................................................... 42
Figura 10 – Rational Unified Process....................................................................................... 45
Figura 11 – Engenharia Avante x Engenharia Reversa............................................................ 49
Figura 12 – Etapas metodológicas............................................................................................ 53
Figura 13 – Sistema atual. ........................................................................................................ 54
Figura 14 – Sistema proposto. .................................................................................................. 55
Figura 15 – Workflow Gerenciamento de Projeto.................................................................... 59
Figura 16 – Workflow Requisitos. ........................................................................................... 60
Figura 17 – Workflow Refinamento do Plano de Desenvolvimento........................................ 60
Figura 18 – Workflow Análise e Design. ................................................................................. 62
Figura 19 – Workflow Ambiente.............................................................................................. 62
Figura 20 – Workflow Implementação..................................................................................... 63
Figura 21 – Workflow Teste..................................................................................................... 64
Figura 22 – Workflow Produto de Teste Beta.......................................................................... 65
Figura 23 – Workflow Finalizar Projeto................................................................................... 66
Figura 24 – Ambiente tecnológico. .......................................................................................... 66
Figura 25 – Tela Inicial. ........................................................................................................... 68
Figura 26 – Tela Inserir Patrimônio. ........................................................................................ 69
Figura 27 – Tela Consultar Itens da Nota de Empenho............................................................ 70
Figura 28 – Tela de Aviso de Confirmação de Inserção. ......................................................... 70
LISTA DE TABELAS
Tabela 1 – Workflows Estáticos no Rational Unified Process................................................ 44

Tabela 2 – Testes realizados no protótipo............................................................................... 72
LISTA DE SIGLAS
ASP – Active Server Pages

EA – Enterprise Architect
CASE – Computer-Aided Software Engineering
DBA – Database Administrator (Administrador do Banco de Dados)
ODBC – Open Data Base Connectivity
PDF – Portable Document Format
IBM RUP – Rational Unified Process
SCAB – Setor de Cadastro e Administração de Bens
SEDES – Serviço de Desenvolvimento de Sistema
SEINFO – Secretaria de Informática
SEMAP – Serviço de Material e Patrimônio
SGBD – Sistema Gerenciador de Banco de Dados
SIAFI – Sistema Integrado de Administração Financeira do Governo Federal
SRS – Software Requirements Specification
TRT/SC – Tribunal Regional do Trabalho de Santa Catarina
UML – Unified Modeling Language
VT – Vara do trabalho (unidades de primeira instância da Justiça do Trabalho)
WEB – World Wide Web
SUMÁRIO
1 INTRODUÇÃO..............................................................................................................................15
1.1 PROBLEMÁTICA .......................................................................................................................16
1.2 OBJETIVOS .................................................................................................................................19
1.2.1 Objetivo Geral..........................................................................................................................19
1.2.2 Objetivos Específicos ...............................................................................................................19
1.3 JUSTIFICATIVA .........................................................................................................................19
1.4 ESTRUTURA DA MONOGRAFIA ............................................................................................20
2 REVISÃO BIBLIOGRÁFICA .....................................................................................................22
2.1 ENGENHARIA ............................................................................................................................22
2.1.1 Engenharia de Software ..........................................................................................................24
2.1.1.1 Engenharia de Sistemas ..........................................................................................................26
2.2 PROCESSO DE SOFTWARE......................................................................................................27
2.2.1 Atividades do processo de desenvolvimento ..........................................................................28
2.2.1.1 Levantamento de Requisitos ...................................................................................................29
2.2.1.2 Análise de Requisitos..............................................................................................................32
2.2.1.3 Projeto.....................................................................................................................................33
2.2.1.4 Implementação........................................................................................................................35
2.2.1.5 Testes ......................................................................................................................................35
2.2.1.6 Implantação.............................................................................................................................36
2.3 MODELO DE PROCESSO DE SOFTWARE..............................................................................36
2.3.1.1 Modelo em Cascata.................................................................................................................36
2.3.1.2 Prototipação ............................................................................................................................37
2.3.1.3 Modelo Espiral........................................................................................................................38
2.3.1.4 Modelo Iterativo e Incremental...............................................................................................39
2.3.1.5 Método Fusion ........................................................................................................................41
2.3.1.6 Rational Unified Process.........................................................................................................42
2.4 PROCESSO DE DESENVOLVIMENTO DA REENGENHARIA .............................................45
2.4.1 Reengenharia de Software ......................................................................................................46
2.4.1.1 Avaliação da Reengenharia.....................................................................................................49
2.5 CONCLUSÕES DO CAPÍTULO .................................................................................................50
3 MÉTODO .......................................................................................................................................51
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA........................................................................51
3.2 ETAPAS METODOLÓGICAS ....................................................................................................52
3.3 PROPOSTA DA SOLUÇÃO........................................................................................................53
3.4 DELIMITAÇÕES .........................................................................................................................55
4 PROCESSO DE DESENVOLVIMENTO ...................................................................................57
4.1 CUSTOMIZAÇÃO DO IBM RUP ...............................................................................................57
4.1.1 Concepção.................................................................................................................................58
4.1.1.1 Gerenciamento de Projeto.......................................................................................................58
4.1.1.2 Requisitos................................................................................................................................59
4.1.2 Elaboração................................................................................................................................60
4.1.2.2 Requisitos................................................................................................................................61
4.1.2.3 Análise e Design .....................................................................................................................61
4.1.2.4 Ambiente.................................................................................................................................62
4.1.3 Construção................................................................................................................................63
4.1.3.1 Implementação........................................................................................................................63
4.1.3.2 Testes ......................................................................................................................................64
4.1.4 Transição ..................................................................................................................................64
4.1.4.1 Implantação.............................................................................................................................65
4.2 AMBIENTE DE DESENVOLVIMENTO ...................................................................................66
4.3 IMPLEMENTAÇÃO DO SISTEMA ...........................................................................................68
5 TESTE E VALIDACÃO ...............................................................................................................72
5.1 TESTE ..........................................................................................................................................72
5.2 VALIDAÇÃO...............................................................................................................................73
6 CONCLUSÕES E RECOMENDAÇÕES....................................................................................74
6.1 CONCLUSÕES ............................................................................................................................74
6.2 RECOMENDAÇÕES ...................................................................................................................75
REFERÊNCIAS ...................................................................................................................................76
APÊNDICES.........................................................................................................................................78
APÊNDICE A – VISÃO ......................................................................................................................79
APÊNDICE B – GLOSSÁRIO............................................................................................................91
APÊNDICE C – LISTA DE RISCOS.................................................................................................98
APÊNDICE D – PLANO DE DESENVOLVIMENTO DE SOFTWARE....................................103
APÊNDICE E – PLANO DE ITERAÇÃO ......................................................................................110
APÊNDICE F – ESPECIFICAÇÃO DE REQUISITOS DE SOFTWARE..................................116
APÊNDICE G – GUIA DE MODELAGEM DE CASOS DE USO...............................................126
APÊNDICE H – ESPECIFICAÇÃO DE CASOS DE USO PRIMÁRIOS ...................................131
APÊNDICE I – DOCUMENTO DE ARQUITETURA DE SOFTWARE....................................187
APÊNDICE J – GUIA DE DESIGN DO SISTEMA ATUAL........................................................198
APÊNDICE K – GUIA DE DESIGN DO SISTEMA PROPOSTO...............................................207
APÊNDICE L – ESPECIFICAÇÃO DA REALIZAÇÃO DE CASOS DE USO .........................223
APÊNDICE M - GUIA DE TESTE ..................................................................................................286
APÊNDICE N – PLANO DE IMPLANTAÇÃO .............................................................................291
15
1 INTRODUÇÃO
Com a globalização, as empresas buscam formas de redução de custos, para

manterem-se competitivas e atraentes no mercado, empregam tecnologia de ponta na
fabricação de produtos, investem em sistemas que automatizam a produção e a logística,
minimizando custos.
No passado, o serviço público era sinônimo de cabide de emprego, hoje,
felizmente, mudanças significativas são visíveis nesse contexto. O setor público sente a
necessidade de modernizar-se, enxugando a máquina administrativa e reduzindo custos, para
dar um atendimento digno de qualidade ao contribuinte.
O Tribunal Regional do Trabalho de Santa Catarina (TRT/SC), criado em 1981, é
um órgão especializado da Justiça do Trabalho de segunda instância e sua principal função
consiste em mediar conflitos entre empregados e empregadores.
O TRT/SC conta, atualmente, com cinquenta e seis varas trabalhistas, que são as
unidades de primeira instância no Estado de Santa Catarina.
Segundo BRASIL (2009A) (a Corregedoria (2009)), no período de janeiro a
novembro de 2009, a Justiça do Trabalho de Santa Catarina recebeu 59.368 processos em suas
unidades judiciárias de primeira instância, em que 59.269 desses processos foram
solucionados, outros estão em trâmite ou foram remetidos para a segunda instância.
Desde a sua criação, o TRT/SC passa por uma evolução constante, para manter-se
atualizado e operante com o aparelhamento da máquina administrativa e judiciária e
promovendo treinamentos constantes de seus colaboradores. .
Com o advento da World Wide Web (WEB), unindo áreas remotas, é possível a
criação de sistemas como: o processo eletrônico, em fase de implantação no TRT/SC,
agilizando a tramitação em juízo, atendendo as necessidades ambientais, com o fim da cópia
impressa, em que todo processo é produzido e julgado de forma eletrônica.
Com a implementação de novas tecnologias, surge a necessidade de remodelar o
organograma da instituição, em que setores ficam obsoletos e outros são criados. A Secretaria
de Informática (SEINFO) tem seu papel fundamental, trabalhando lado a lado com diversas
áreas, de forma a dar sustentabilidade ao cotidiano da instituição, com a criação e aquisição de
sistemas, automatizando todo processo administrativo e judiciário, sua manutenção e
administração.
16
O Setor de Cadastro e de Administração de Bens (SCAB) é vinculado ao Serviço

de Material e Patrimônio (SEMAP), que pertence a Secretaria Administrativa do TRT/SC.
Segundo BRASIL (2009B) (Patrimônio (2009)), entre as atribuições do SCAB, destacam-se:
- receber e conferir, juntamente com o Setor de Almoxarifado, os materiais
permanentes adquiridos pelo Tribunal;
- estocar os materiais permanentes;
- registrar a incorporação de bens permanentes móveis e imóveis ao patrimônio do
TRT/SC;
- proceder ao tombamento dos materiais permanentes;
- receber da direção do SEMAP determinações para fornecimento dos materiais e
processá-las;
- acondicionar e expedir aos usuários os materiais permanentes;
- registrar, controlar e manter atualizados os dados referentes à transferência dos
bens móveis entre as unidades administrativas e judiciárias;
- inventariar, anualmente, com apoio das Varas do Trabalho, localizadas fora da
Grande Florianópolis, o patrimônio do Tribunal;
- expedir termos de responsabilidade;
- atender e solucionar as questões dirigidas ao Setor acerca do fornecimento dos
materiais permanentes;
- manter atualizada a classificação dos bens permanentes e subsidiar o Setor de
Métodos e Controle com informações dos bens que poderão ser baixados do
patrimônio, incorporados ao mesmo e/ou doados a instituições que os requeiram;
- diligenciar e controlar os registros de bens imóveis;
- manter atualizados relatórios referentes aos bens do Tribunal.
O Sistema de Controle de Patrimônio tem por finalidade garantir a transparência
dos investimentos realizados na aquisição e na distribuição de equipamentos pelo TRT/SC,
permitindo auditorias interna ou externa, em que a prestação de contas seja transparente.
Proporcionar um ambiente de trabalho agradável para os colaboradores do SCAB,
buscando uma forma simples de desburocratizar a administração do patrimônio público, com
uma perfeita harmonia entre colaboradores e o sistema.
1.1 PROBLEMÁTICA
O TRT/SC conta com um sistema de gerenciamento de patrimônio genérico, que

“são sistemas do tipo stand-alone, produzidos por uma organização de desenvolvimento e
vendidos no mercado para qualquer cliente disposto a comprá-los”. (SOMMERVILLE, 2007,
p. 4).
O sistema atual, segundo o relato feito pelos funcionários do SCAB, é uma cópia
de um sistema existente no Tribunal Superior do Trabalho, que abrange várias áreas, e foi
customizado para o gerenciamento de controle de patrimônio do TRT/SC.
17
Por não ser um sistema personalizado, ser heterogêneo, em que a parte principal é
desenvolvida com a ferramenta Oracle-Forms, e tendo o TRT/SC o quadro de funcionários
especializado nessa ferramenta reduzido.
Em virtude de que os investimentos da instituição estão concentrados na
padronização dos sistemas na linguagem de programação Java em ambiente WEB, há o
interesse por parte da SEINFO em adquirir um novo sistema.
Seguindo o mesmo raciocínio do parágrafo anterior, relata-se ainda que o sistema
atual conta com um agravante, que é o fato de não possuir uma documentação adequada,
tornando, assim, sua manutenção uma tarefa problemática para a equipe de manutenção.
Segundo uma demonstração realizada pelos funcionários do SCAB, foi possível
constatar, que, na customização do sistema, consta telas que não são necessárias as tarefas
realizados pelo SCAB, ou outro setor que tenha acesso ao sistema de gerenciamento de
patrimônio, além de consultas e relatórios carentes de uma formatação adequada.
É possível verificar-se problemas de formatação de páginas, conforme a ilustração
apresentada na Figura 1, a seguir.
Figura 1 – Consulta ao sistema atual.

Fonte: Adaptado de BRASIL (2009B) (Patrimônio (2009)).
18
Para o funcionário responsável por um setor imprimir um termo de

responsabilidade de recebimento de material permanente, uma vez que o sistema atual não foi
instalado em todos os setores do TRT/SC, outra parte do sistema foi desenvolvida em
linguagem Active Server Pages (ASP) para ambiente WEB.
Para atender a necessidade descrita no parágrafo anterior, o Serviço de
Desenvolvimento de Sistema (SEDES) é obrigado a manter dois sistemas que atendem um
mesmo propósito que é o gerenciamento de patrimônio.
Devido aos problemas relatados nessa seção e as solicitações feitas pelo SCAB de
mudanças e atualizações serem atendidas em pequeno número em um prazo longo, ou não
serem atendidas, prejudicando, assim, o andamento do serviço executado por esse setor,
surgiu a necessidade de mudanças do sistema atual para um novo sistema, justificando-se,
assim, o desenvolvimento da presente monografia.
O Sistema de Gerenciamento de Patrimônio Proposto tem por finalidade:

• automatizar e padronizar o processo de gerenciamento de patrimônio do
TRT/SC, conforme as normas estabelecidas pela SEIMFO;
• oferecer artifícios para consultas e controle dos bens cadastrados, seja em
estoque, no almoxarifado, ou disponibilizados nas dependências do órgão, por
meio da autenticação do usuário na intranet, pelo seu perfil, com poderes
limitados por local de trabalho, em que será autorizado pelo administrador do
sistema. Para Panagopoulos (2009), “intranet é um ambiente que usa tecnologia
idêntica a da Internet, só que funciona dentro da rede local de uma empresa,
protegido do exterior por um firewall”;
• contará com uma interface amigável, que é uma das reinvidicacões dos
colaboradores do SCAB;
Em um segundo momento, pretende-se, ainda, implementar um catálogo dos bens
cadastrados, constando a imagem do bem em destaque, em que o setor requisitante poderá
navegar e decidir sobre a aquisição. Esse artifício não fará parte do escopo do trabalho.
19
1.2 OBJETIVOS
Nesta seção são apresentados os objetivos: geral e específicos.
1.2.1 Objetivo Geral
Desenvolver um protótipo de sistema de gerenciamento de patrimônio voltado

para WEB para o TRT/SC, por meio da reengenharia do sistema atual.
1.2.2 Objetivos Específicos
O projeto tem como objetivos específicos:

• integrar a reengenharia de software em um processo interativo e
incremental;
• estudar processos de reengenharia para aproveitamento das melhores
práticas em um processo de desenvolvimento;
• usar ferramenta CASE na engenharia reversa para recuperar o maior número
de artefatos para o novo sistema;
• construir um protótipo de sistema em ambiente WEB.
1.3 JUSTIFICATIVA
No segundo semestre de 2003, quando demos início aos estudos no curso de

Ciência da Computação, tínhamos um propósito que era o aprendizado de banco de dados e
20
sabíamos que era necessário aprender, também, uma linguagem de programação de alto nível.
Esse segundo item teve início já na primeira fase do curso e, durante todo o trajeto, ficou
evidente o nosso prazer em realizar as atividades inerentes às disciplinas de Programação e
Estrutura de Dados.
Com um aprendizado razoável em programação, deu-se início o aprendizado de
banco de dados, sendo que as disciplinas de Engenharia de Software vieram a contribuir ainda
mais, solidificado o aprendizado.
As disciplina de Programação para WEB e Interface Humano Computador
proporcionaram um aprendizado na elaboração das interfaces visuais e aprofundaram um
maior conhecimento na área de programação.
Já, nesse estágio do curso, sabíamos que o nosso trabalho final não poderia ser
outro senão um protótipo de sistema para WEB, que utilizasse persistência de dados.
Em busca de um tema, entramos em contato com a SEINFO do TRT/SC, que
sinalizou com a opção da criação desse sistema, uma vez que havia reivindicação por parte do
SCAB, conforme citado na seção 1.1 deste capítulo, de um sistema com maior funcionalidade
e praticidade.
O autor justifica o tema proposto por ser funcionário da instituição, o que lhe
favorece novas oportunidades de demonstrar seu conhecimento na área, pela produção do
trabalho dentro do TRT/SC.
1.4 ESTRUTURA DA MONOGRAFIA
O presente trabalho encontra-se estruturado da seguinte forma:

• capítulo 1 – descreve a introdução, objetivos, justificativa e estrutura da
monografia;
• capítulo 2 – é realizada uma coletânea do acervo bibliográfico pesquisado
que fundamenta o trabalho;
• capítulo 3 – são descritos os métodos usados para elaborar o trabalho;
• capítulo 4 – é realizado um estudo de caso, por meio da metodologia IBM
RUP, analisando o sistema atual e a realização do desenvolvimento de um
protótipo para o sistema proposto;
21
• capítulo 5 – apresenta os testes, e validação.

• capítulo 6 – são abordadas as conclusões e recomendações para trabalhos
futuros.
22
2 REVISÃO BIBLIOGRÁFICA
Este capítulo aborda as obras de diferentes autores sobre o assunto em questão,

embasando a monografia segundo os autores, delimitado o estudo para a área de
desenvolvimento de um software, tendo como base um sistema existente, em que será
aplicada a reengenharia.
“O software não se desgasta” (PRESSMAN, 1995, p. 14), porém, com o passar do
tempo, atualizações são necessárias, para que continue a ser útil, desenvolvendo as funções
para as quais foi projetado. Mudanças tecnológicas, modernização, padronização dos
sistemas, adição de funcionalidades não previstas no projeto original são questões que fazem
com que o software se deteriore ou acabe por não mais atender as necessidades da empresa.
2.1 ENGENHARIA
Quando se aborda o termo “engenharia de software”, é conveniente definir

engenharia em termos genéricos. Algumas definições sobre engenharia estão fundamentadas,
e, ao longo da história, alguns relatos da necessidade da criação da engenharia são descritos
no presente trabalho.
Segundo Houaiss (2001), a engenharia pode ser definida como "aplicação de
métodos científicos ou empíricos à utilização dos recursos da natureza em benefício do ser
humano".
A engenharia é tão antiga quanto a história da humanidade, ela “[...] confunde-se
com a história da própria humanidade e teve início a cerca de sete milhões de anos”. Mediante
estudos realizados por paleontólogos, a fabricação de ferramentas rudimentares teve início,
devido aos primeiros hominídeos serem carnívoros. (CAVALCANTE, 2009).
Conforme o descrito acima e indo ao encontro da modernização, Cavalcante
(2009) descreve o invento da eolípila, um aparelho formado por uma câmara com tubos
curvados, em que sai o vapor, inventado no primeiro século por Heron de Alexandria, é
relatado como sendo o primeiro motor a vapor documentado. A eolípila é mostrada, a seguir,
na Figura 2.
23
Figura 2 – Eolípila.
Fonte: Adaptado de Cavalcante (2009).
Se Heron tivesse dominado essa forma de energia rotativa, o motor a vapor teria
sido inventado quase dois mil anos antes da sua reinvenção. Cavalcante (2009) conclui que o
motor a vapor foi criado a partir de uma idéia existente, redesenhada e remodelada, dando
origem a um produto novo, ou seja, uma forma de reengenharia.
A reengenharia fica mais evidente, quando comparada entre objetos sólidos, como
é o caso da engenharia civil, ilustrado na Figura 3, a seguir.
24
Figura 3 – Reengenharia na construção civil.

Fonte: Adaptado de Braga (2006).
2.1.1 Engenharia de Software
A engenharia de software abrange um conjunto de três elementos fundamentais:

métodos, ferramentas e procedimentos – que possibilita ao gerente o controle do
processo de desenvolvimento do software e oferece ao profissional uma base para a
construção de software de alta qualidade e produtividade. (PRESSMAN, 1995, p.
31).
Para Sommerville (2007), “a engenharia de software é uma disciplina de
engenharia relacionada a todos os aspectos da produção de software, desde os estágios iniciais
de especificação do sistema até sua manutenção depois que este entrar em operação”.
Os métodos de engenharia de software proporcionam os detalhes de “como fazer”
para construir o software. Os métodos envolvem um amplo conjunto de tarefas que
incluem: planejamento e estimativa do projeto, análise de requisitos de software e de
sistemas, projeto de estrutura de dados, arquitetura de programa e algoritmo de
processamento, codificação, teste e manutenção. Os métodos da engenharia de
software muitas vezes introduzem uma notação gráfica ou orientada a linguagem
especial e introduzem um conjunto de critérios para a qualidade do software.
As ferramentas de engenharia de software proporcionam apoio automatizado ou
semi-automatizado aos métodos. Atualmente existem ferramentas para sustentar
cada um dos métodos anotados anteriormente. Quando as ferramentas são integradas
de forma que a informação criada por uma ferramenta possa ser usada por outra, é
estabelecido um sistema de suporte ao desenvolvimento de software chamado de
engenharia de software auxiliada por computador (CASE – Computer-Aided
Software Engineering). O CASE combina software, hardware e um banco de dados
de engenharia de software (uma estrutura de dados contendo importantes
informações sobre análise, projeto, codificação e teste).
25
Os procedimentos da engenharia de software constituem o elo de ligação que

mantém juntos os métodos e as ferramentas e possibilita o desenvolvimento racional
e oportuno de software de computador. Os procedimentos definem a sequência em
que os métodos serão aplicados, os produtos (deliverable) que exige que sejam
entregues (documentos, relatórios, formulários etc.), os controles que ajudam a
assegurar a qualidade e a coordenar as mudanças, e os marcos de referência que
possibilitam aos gerentes de software avaliar o processo. (PRESSMAN, 1995, p.
33).
Para Sommerville (2007), Software não é somente o programa, mas todos os

artefatos que fazem o programa funcionar adequadamente.
Conforme o exposto, no parágrafo acima, esses artefatos são programas e arquivos
de configuração que fazem a comunicação da plataforma com o software, envolvem, ainda,
um conjunto de documentos que são a planta do sistema, descrevendo a sua concepção e
manuais de usuário, que ensina de forma sucinta como operar com o software ou buscar ajuda
on line, obtendo as últimas atualizações e as informações do produto.
Nos primórdios, ao escrever um software, o desenvolvedor tinha sua planta na
cabeça, em que, em muitos casos, a documentação era rara ou inexistente. Caso houvesse
falhas, ele mesmo as reparava. A maior parte do software era desenvolvida e, em última
análise, usada pela própria pessoa ou organização. (PRESSMAN, 1995, p. 5).
Com o passar do tempo e com o avanço da tecnologia, novas ferramentas para
apoio à engenharia de software foram desenvolvidas. O CASE segundo Sommerville (2005, p.
57), é a denominação dada ao software, usado no apoio das atividades de processo de
software. Entre essas atividades, destacam-se: a engenharia de requisitos, projetos,
desenvolvimento de programas e teste.
Incluem-se, no grupo de ferramentas CASE, os editores de diagramas, dicionário
de dados, compiladores, debuggers, ferramenta de construção de sistemas etc. A seguir, é
apresentada uma definição da tecnologia CASE.
A tecnologia CASE fornece apoio ao processo de software pela automação de
algumas atividades de processo e pelo fornecimento de informações sobre o
software que esta sendo desenvolvido. Exemplo de atividades que podem ser
automatizadas com o uso do CASE incluem:
- o desenvolvimento de modelos gráficos de sistema como parte da especificação de
requisitos ou do projeto de software;
- a compreensão de um projeto por intermédio do uso de um dicionário de dados
com informações sobre as entidades e as relações em um projeto;
- a geração de interfaces com o usuário com base em uma descrição de interface
gráfica criada interativamente pelo usuário;
- o debugging do programa por meio do fornecimento de informações sobre um
programa em execução;
- a tradução automática de programas a partir de uma versão antiga de uma
linguagem de programação, como COBOL, para uma versão mais recente.
A tecnologia CASE está disponível atualmente para a maioria das atividades
rotineiras do processo de software. Isso levou a alguns aprimoramentos de qualidade
26
e produtividade de software, embora estes sejam menores do que os previstos pelos

primeiros defensores do CASE. (SOMMERVILLE, 2007, p. 57).
2.1.1.1 Engenharia de Sistemas
“A engenharia de sistemas é a atividade de especificação, projeto, implementação,

validação, implantação e manutenção de sistemas”. (SOMMERVILLLE, 2007, p. 17).
O autor mencionado no parágrafo anterior comenta que os engenheiros, ao
projetarem o sistema, levam em conta, além do software, o hardware e as interações do
sistema com usuários e seu ambiente. Fatores, como as restrições de criação e operação,
devem ser analisados para que o sistema tenha seus objetivos alcançados.
Para Pressman (1995), a engenharia de sistemas de software é uma atividade
destinada a solucionar problemas. As funções necessárias para o funcionamento do sistema
são desvendadas, analisadas e designadas dos elementos individuais do sistema.
O autor citado a cima comenta que o analista inicia os trabalhos por meio da
coleta de requisitos definidos pelo cliente e deriva uma representação da função, desempenho,
interfaces, restrições de projeto e estrutura de informações que podem ser atribuídos a cada
um dos elementos de sistema genéricos.
Segundo Maffeo (1992), “em termos genéricos, pode-se definir um sistema como
sendo: um conjunto, identificável e coerente de elementos que interagem, coesivamente, em
que cada elemento pode ser um sistema”.
Para Sommerville (2007), “um sistema pode ser definido como um conjunto de
elementos interrelacionados que interagem no desempenho de uma função”.
Seguindo a referência anterior, relata-se que sistemas técnicos, baseados em
computadores, são aqueles que incluem hardware e software, e não incluem procedimentos e
processos. São incluídos nessa categoria de sistemas televisores, telefones celulares, além de
grande parte dos softwares de computadores pessoais.
Continuando com a linha de raciocínio, Sommerville (2007) considera que as
organizações e usuários usam sistemas técnicos para alguma finalidade, mas o conhecimento
dessa finalidade não é o propósito do sistema, como exemplo, no caso de um processador de
textos, o processador não sabe que está escrevendo um livro.
27
Ainda, o mesmo autor enfatiza que os sistemas sociotécnicos podem incluir um ou

mais sistemas técnicos, mas incluem, também, conhecimento de como o sistema deve ser
usado para alcançar seu principal objetivo. Portanto, esses sistemas têm processos
operacionais definidos, incluem pessoas como partes inerentes ao sistema.
2.2 PROCESSO DE SOFTWARE
Um processo de software, para Sommerville (2007, p. 42), representa um

conjunto de atividades padronizadas para produção de um produto de software. As atividades
envolvem o desenvolvimento do software, usando uma linguagem de programação adequada
como, por exemplo: Java ou C. Porém, em circunstância em que já existe um sistema
operando, que não atende mais às necessidades da empresa e a seus usuários, o novo software
pode ser desenvolvido a partir da ampliação ou modificando o sistema existente.
O autor citado acima, menciona, que a complexidade de um processo de software
dependerá da natureza que esse software representa e a resolução do problema dependerá da
criatividade de seus criadores, em que a automatização do processo tem sucesso limitado.
Booch et al. (2000, p. 3) relatam que, ao entregar um software de qualidade e de
conformidade com aquilo que foi contratado, não é somente entregar documentos bonitos e
códigos bem elaborados, é necessário reunir-se e interagir com os usuários de forma
disciplinada, tendo como objetivo expor requisitos reais do sistema.
Sommerville (2007, p. 42) entende que as ferramentas CASE podem apoiar
algumas atividades de processo. Como não são ferramentas que assumem o processo criativo,
é necessária a criatividade dos engenheiros envolvidos no processo de software. A principal
razão para as limitações da eficiência dessas ferramentas são decorrentes da imensa
diversidade dos processos de software.
Destacam-se algumas ferramentas CASE usadas para aplicação na engenharia
reversa como: Rational Rose Developer for UNIX, que, segundo Rational (2009), importa um
sistema já implementado, permitindo, assim, uma melhor visualização desse sistema.
Seguindo a mesma linha de raciocínio destaca-se que a ferramenta Enterprise
Architect (EA), segundo SYSTEMS (2009), permite a obtenção do diagrama entidade e
28
relacionamento, partindo-se de SGBD existente com uso de um driver Open Data Base
Connectivity (ODBC).
Não existe um processo ideal, e varias organizações desenvolvem abordagens

inteiramente diferentes para o desenvolvimento de software. Os processos evoluíram
para explorar as capacidades das pessoas em uma organização e as características
específicas dos sistemas que estão sendo desenvolvidos. No caso de alguns sistemas,
como os sistemas críticos, é necessário um processo de desenvolvimento muito
estruturado. Nos sistemas de negócios, com requisitos que mudam rapidamente, um
processo flexível e ágil é provavelmente mais eficaz.
Embora existam muitos processos de software diferentes, algumas atividades
fundamentais são comuns a todos eles, como:
- especificação de software. A funcionalidade do software e as restrições sobre sua
operação devem ser definidas;
- projeto e implementação de software. O software que atenda à especificação deve
ser produzido;
- validação de software. O software deve ser validado para garantir que ele faça o
que o cliente deseja;
- evolução do software. O software deve evoluir para atender às necessidades
mutáveis do cliente. (SOMMERVILLE, 2007, p. 42).
2.2.1 Atividades do processo de desenvolvimento
Bezerra (2002, p. 20) destaca que o “processo de desenvolvimento classifica, em

atividades, as tarefas realizadas durante a construção de um sistema de software”.
Segundo Coleman et al. (1996, p. 300), durante o processo de desenvolvimento,
se alguma das atividades não puder ser realizada, o plano deve incluir uma atividade para a
tomada de decisão. Eles salientam, no entanto, que o plano deve estabelecer um cronograma,
alocando recursos para as atividades necessárias à produção que envolve os riscos.
No presente trabalho, na seção que trata sobre o modelo de processo de software,
serão descritos alguns dos modelos de processos, cada um com suas particularidades, na
forma de arranjo e encadeamento dessas atividades, porém algumas atividades, com pequenas
alterações, são comuns à maioria dos processos existentes. Algumas dessas atividades são
descritas a seguir.
29
2.2.1.1 Levantamento de Requisitos
Bezerra (2002, p. 20) destaca que a atividade de levantamento de requisitos

corresponde a etapa de compreensão do problema e que este levantamento tem como seu
principal objetivo a produção de uma visão única para os desenvolvedores e usuários do
problema a ser resolvido.
O autor citado anteriormente comenta que, é nessa etapa que desenvolvedores e
clientes procuram levantar e definir necessidades para o futuro sistema.
“Formalmente, um requisito é uma condição ou capacidade que deve ser
alcançada ou possuída por um sistema ou componente deste para satisfazer um contrato,
padrão, especificação ou outros documentos formalmente impostos”. Maciaszek (2000 apud
BEZERRA, 2002, p. 20).
Sommerville (2007, p. 80) entende que alguns dos problemas encontrados,

durante a engenharia de requisitos, resultam de uma falta de separação entre os níveis de
descrição, ou seja, ele separa os requisitos em:
• requisitos de usuário, que é uma abstração para os requisitos de alto nível;
• requisitos de sistema, para a descrição detalhada do que o sistema deve
fazer. Ambos os requisitos, são mais bem detalhados no decorrer do presente
capítulo.
Bezerra (2002, p. 20) destaca que os requisitos de sistema são definidos,
partindo-se do domínio de negócio.
Ainda, nessa mesma linha de considerações, é importante frisar que: domínio de
negócios é a área de conhecimento especifica em que um determinado sistema será
desenvolvido. Em outras palavras, domínio de negócios é uma visão do mundo real que tem
relevância no desenvolvimento de um sistema.
Os requisitos de sistemas de software, segundo Sommerville (2007, p. 79), podem
ser expressos como requisitos de usuário e de sistema como definidos anteriormente por ele, e
diferenciados por requisitos funcionais e requisitos não funcionais. Os requisitos serão
descritos detalhadamente mais adiante.
Continuando a análise anterior, Bezerra (2002, p. 20) ressalta que: “Os requisitos
de um sistema são descrições dos serviços fornecidos pelo sistema e as suas restrições
30
operacionais”. Considera, ainda, que esses requisitos representam o que o cliente deseja em
termos de sistema para resolução dos seus problemas.
“O processo de descobrir, analisar, documentar e verificar os serviços e restrições
é chamado de engenharia de requisitos”. (SOMMERVILE, 2007, p.79).
Com o levantamento dos requisitos, a equipe de desenvolvedores tem os artifícios
para identificar o domínio do negócio que deverá ser automatizado pelo novo sistema de
software. No entanto, a engenharia de requisitos pode ser o maior problema enfrentado no
desenvolvimento de sistemas de software grandes e complexos. (SOMMERVILE, 2007;
BEZERRA, 2002).
Sommerville (2007, p. 80) afirma que: (1) requisitos de usuário são declarações
em linguagem natural, contemplados com diagramas de quais serviços são esperados pelo
sistema proposto e suas restrições às quais deve operar; (2) requisitos de sistema são
definições detalhadas das funções, serviços e restrições operacionais do sistema. Os requisitos
de sistema são classificados em:
1. requisitos funcionais – são os requisitos que definem as funcionalidades do
sistema, reação do sistema em uma entrada específica e o comportamento
do sistema em uma situação. Quando são requisitos de usuários são
descritos de forma bastante abstrata, porém descrevem as funções de
sistema em detalhes como as entradas, saídas e exceções;
2. requisitos não funcionais – são declaradas nestes requisitos, as
características referentes à qualidade do sistema, com relação às suas
funcionalidades, apontando as restrições sobre serviços ou funções
oferecidas pelo sistema;
3. requisitos de domínio – são derivações do domínio da aplicação do sistema,
incluem uma terminologia específica de domínio ou se referem a conceitos
do domínio. Como esses requisitos são especializados, há certa dificuldade
de compreensão por parte dos engenheiros de software no que se refere à
relação com outros requisitos do sistema. (BEZERRA 2002;
SOMMERVILLE 2007).
Sommerville (2007, p. 91) explica que um documento de requisitos de software,
ou especificação de requisitos de software para alguns autores, ou ainda Software
Requirements Specification (SRS), “é a declaração oficial do que os desenvolvedores de
sistema devem implementar”.
31
O autor citado acima, entende que, nesse documento, devem-se conter os

requisitos de usuário e o detalhamento dos requisitos de sistema.
Seguindo a mesma linha de raciocínio, ele considera que, em alguns casos, ambos
os requisitos podem estar integrados na mesma descrição. Em outros casos, os requisitos de
usuário são definidos em uma introdução dentro da especificação do sistema.
Ainda, continuando com a mesma linha de raciocínio em que o autor citado
comenta que, sistemas de grande porte com um número elevado de requisitos, os requisitos
detalhados de sistema podem ser escritos em documentos separados. A Figura 4 ilustra os
possíveis usuários do documento e de como eles o utilizam.
Figura 4 – Usuários de um documento de requisitos.

Fonte: Adaptado de Sommerville (2007).
Bezerra (2002, p. 22) compreende que uma questão importante sobre o documento
de requisitos é que essa documentação não contenha as soluções de elucidação técnica
adotadas no desenvolvimento do sistema.
Por conseguinte, seguindo o mesmo entendimento do parágrafo anterior, o alvo do
levantamento de requisitos deve ser: o que o usuário necessita do novo sistema. O autor citado
anteriormente, alerta, ainda, que “novos sistemas serão avaliados pelo seu grau de
conformidade aos requisitos, não importa quão complexa a solução tecnológica tenha sido”.
Ainda nessa, mesma linha de considerações, ele esclarece que requisitos
descrevem o problema a ser resolvido pelo sistema, não descrevem a solução adotada com o
uso de software para a resolução do problema.
Destaca, ainda, que o sistema deva ser compreendido antes de ser construído. E
que, é com o levantamento dos requisitos que o sistema é compreendido, evidenciando, assim,
a importância para o perfeito desenvolvimento de todo o projeto.
32
Por conseguinte, ele entende que, em sistemas de certa complexidade, é

impossível pensar em todos os detalhes no início e que, principalmente, quando o sistema
entra em produção, durante o decorrer de seu uso, os próprios usuários descobrirão requisitos
que não tinham sido especificados durante o projeto.
2.2.1.2 Análise de Requisitos
Bezerra (2002, p. 24) sustenta que “o termo análise corresponde a ‘quebrar’ um

sistema em seus componentes e estudar como tais componentes interagem com o objetivo de
entender como esse sistema funciona”.
Continuando com a mesma linha de raciocínio, o autor citado anteriormente
considera que, no contexto dos sistemas, a análise de requisitos é a etapa em que o estudo dos
requisitos levantados deve ser detalhado. Após o estudo então os modelos que representam o
sistema serão construídos.
Já Pressman (1995, p. 231) salienta que o entendimento dos requisitos é
primordial para alcançar o sucesso no desenvolvimento do software. Ele argumenta que,
mesmo que tenha sido realizado um bom projeto e bem codificado, se foi mal analisado e
especificado, com certeza, desapontará o usuário, causando inconvenientes ao desenvolvedor.
Em vista disso, ele descreve que a tarefa de análise de requisitos é a forma de
realizar descobertas, um refinamento dos requisitos, modelagem e da especificação do
sistema. Então, o software, refinado durante o planejamento do projeto, será aperfeiçoado em
detalhes.
Rumbaugh et al. (1994, p. 345) sustentam que a diferença entre análise e o
projeto, dá à impressão de não seguir uma regra, ou ser confusa, eles entendem que a regra a
seguir guia o projetista na tomada de decisões a respeito do escopo correto da análise e
projeto.
Os autores citados acima observam que o modelo da análise deve acrescentar as
informações sob o mundo real, apresentando, assim, a visão externa do sistema, e que é este
modelo que o cliente deve compreender, pois fornecerá uma base útil sem dar margem a
dúvidas sobre os requisitos verdadeiros do sistema.
33
Seguindo a mesma linha de raciocínio os autores comentam que esses requisitos

verdadeiros são aqueles necessários, possíveis de serem alcançados, para o perfeito
funcionamento do produto de software.
Acrescentam, ainda, que, diferente do modelo de análise, o modelo de projeto
depende da relevância para a perfeita implementação em computador, devendo ser eficiente e
de codificação prática. Dizem, ainda, que, na prática, partes do modelo de análise podem ser
implementadas sem modificar, havendo, assim, uma considerável sobreposição dos modelos
citados.
Que os detalhes de níveis inferiores omitidos no modelo de análise devem ser
citados no modelo de projeto. Eles registram, ainda, que os dois modelos combinam-se,
oferecendo uma valiosa documentação, em perspectivas diferentes que se complementam.
Bezerra (2002, p. 24) sustenta que, no levantamento de requisitos bem como na
análise de requisitos, não será considerado o ambiente tecnológico a utilizar. O primordial,
aqui, é construir uma estratégia para solucionar o problema, sem a preocupação de como essa
estratégia será realizada.
Ele afirma que, no processo de desenvolvimento orientado a objetos, o resultado
da análise são os modelos representativos da estrutura das classes de objetos que compõem o
sistema. Aponta, ainda, que o resultado da análise, também, são modelos que especificam as
funcionalidades do sistema.
Pressman (1995, p. 231) menciona que analisar e especificar requisitos parece ser
uma tarefa simples, entretanto, o conteúdo de comunicação é muito elevado. Há um grau de
interpretações errôneas e informações falsas muito fortes. É, nesse momento, que o que o
cliente fala e acaba sendo interpretado de outra maneira, levando ao erro nos requisitos e na
sua posterior análise, caso não seja detectado.
2.2.1.3 Projeto
Alguns autores separam projeto em uma seção, em outros, é parte do ‘processo de

desenvolvimento’. Nesta monografia, considerou-se projeto como subtítulo de processo de
desenvolvimento.
34
É oportuno destacar que, segundo Bezerra (2002, p. 26), embora a análise e o

projeto sejam referenciados separadamente, essas duas fases não são assim tão distintos e que,
principalmente, no desenvolvimento de sistemas orientados a objetos, as atividades dessas
duas fases, constantemente, se misturam.
Ele sustenta que o os requisitos são o foco principal da análise. Considera que a
fase do projeto é a fase que determina a forma de como o sistema funcionará para atender os
requisitos, de acordo com a tecnologia existente. Nessa fase, a de projetos, são considerados
os aspectos físicos e dependentes de implementação.
Ele esclarece que as restrições tecnológicas são adicionadas na fase de projeto aos
modelos construídos na fase de análise. Alguns exemplos que podem ser considerados na fase
de projeto são: arquitetura do sistema, padrão de análise gráfica, linguagem de programação,
gerenciador de banco de dados etc.
Martins (2007, p. 258) destaca que “os objetivos do projeto devem ser específicos,
mensuráveis e realísticos”. Considera que o plano de projeto tem como seu foco principal os
objetivos do projeto, partindo do ponto de vista do negócio. A importância aqui é indicar o
que será produzido, não contemplando o por que será produzido.
Pressman (1995, p. 416) afirma que “o projeto de dados transforma o modelo de
domínio de informação criado durante a análise nas estruturas de dados que serão exigidas
para se implementar o software”.
Ele reforça, ainda, que a relação entre os componentes estruturais do sistema é
definida no projeto de arquitetura, e que o projeto procedimental irá transformar esses
componentes numa descrição procedimental de software. Em decorrência, o código fonte é
escrito e os testes realizados, podendo, assim, validar o software.
Bezerra (2002, p. 25) reforça que, no processo de desenvolvimento orientado a
objeto, as classes de objetos relacionadas, do sistema, são distribuídas, pelo projeto de
arquitetura, em subsistemas e seus componentes, distribuindo, assim, esses componentes
fisicamente pelos recursos de hardware disponíveis.
Enfatiza, entretanto, que os diagramas UML, utilizados nessa fase do projeto, são
os diagramas de implementação, e que as colaborações entre os objetos de cada módulo, no
momento de detalhamento do projeto, são modeladas, tendo como objetivo alcançar a
funcionalidade do módulo. Destaca que, ainda nessa fase do projeto, são criados os projetos
de interface com o usuário e banco de dados.
35
Ao referir-se aos diagramas UML, para complementar o parágrafo anterior, ele

afirma que são utilizados, aqui, os diagramas de: classe, casos de uso, de interação, de estados
e diagrama de atividades.
2.2.1.4 Implementação
É na fase de implementação que ocorre a programação propriamente dita escrita

em uma linguagem de alto nível, como exemplo Java ou C++, toda documentação descrita, na
fase de projeto, é codificada e compilada, resultando, então, um código executável.
(BEZERRA, 2002, p. 26).
No processo de desenvolvimento orientado a objetos, segundo o autor citado no
parágrafo anterior, as classes de objetos, são definidas e implementadas, mediante o uso de
uma linguagem de programação orientada objetos.
Coleman et al. (1996, p. 300) por sua vez, reforçam que a implementação tem de
ser correta, comportando-se da forma que foi escrita no projeto, satisfazendo, assim, os
requisitos levantados. Consideram que deva ser econômica, do ponto de vista de software e
hardware, economizando, assim, tempo e memória.
2.2.1.5 Testes
Bezerra (2002, p. 26) salienta que os testes são realizados, levando-se em conta
várias atividades, em que um relatório de teste deve ser obtido, contendo informações a
respeito de erros detectados no software. Ao final dos testes, os módulos do sistema são
integrados, compondo, assim, o produto que é o software.
36
2.2.1.6 Implantação
No processo de implantação, o sistema é empacotado e, posteriormente, será

distribuído para instalação no ambiente do usuário. Nessa etapa, os manuais do sistema são
escritos; usuários são treinados para o correto uso do sistema. (BEZERRA, 2002, P. 26).
2.3 MODELO DE PROCESSO DE SOFTWARE
Para Booch et al. (2000, p. 6), “os modelos fornecem uma cópia do projeto de um
sistema”. Esses autores relatam que, com o uso dos modelos, planos detalhados, podem ser
alcançados ou em um primeiro momento, uma visão mas abstrata do sistema. Afirmam, ainda,
que, com um modelo, quatro objetivos podem ser alcançados:
1. os modelos dão uma panorâmica do sistema como ele é, ou como
gostaríamos que ele fosse;
2. que, por meio dos modelos, pode ser especificada a estrutura ou
comportamento de um sistema;
3. que os modelos guiam os projetistas durante a construção do sistema;
4. que os modelos fornecem artifícios para documentar as decisões tomadas.
Sommerville (2007, p. 43) descreve um modelo de processo de software como
sendo “uma representação abstrata de um processo de software”. O autor destaca que cada
modelo expõe um processo de certa forma, fornecendo somente informações parciais sobre
esse processo. A seguir, apresenta-se uma breve descrição dos principais modelos.
2.3.1.1 Modelo em Cascata
Segundo Pressman (1995), o modelo em cascata “requer uma abordagem

sistemática, sequencial ao desenvolvimento do software, que se inicia no nível do sistema e
37
avança ao longo da análise, projeto, codificação, teste e manutenção”. Como é um modelo

sequencial, uma versão do software só fica pronta numa etapa avançada do desenvolvimento,
em que erros no projeto são percebidos. O modelo em cascata é representado, conforme a
Figura 5, mostrada a seguir.
Figura 5 – Modelo em cascata.

2.3.1.2 Prototipação
Para Pressman (1995, p. 35), a prototipação é definida como um processo que

conduz o desenvolvedor na criação de um modelo de software implementado posteriormente,
destacando que esse modelo pode assumir uma das formas descritas a seguir:
1. um protótipo desenhado em uma folha ou em uma ferramenta gráfica para
desenho no computador. Descreve as interações homem máquina,
capacitando o usuário a entender quantas interações ocorrerão;
2. um protótipo que implementa um subconjunto das funções requisitadas do
software a ser desenvolvido;
38
3. um programa existente que executa alguma ou todas as funções que o

software fornecerá e que possua outras características a serem melhoradas
posteriormente .
Para Pressman (1995, p. 36), a prototipação tem início com a coleta dos
requisitos, em que o desenvolvedor interage com o cliente, definindo os objetivos
globais para o software. A seguir, a Figura 6 ilustra o modelo.
Figura 6 – Prototipação.
Fonte: Adaptado de Pressman (1995).
2.3.1.3 Modelo Espiral
Nesse modelo, segundo Sommerville (2007, p. 48), “o processo é representado

como um espiral”, também, relata que cada loop na espiral demonstra uma fase do processo
de software, começando com a elaboração dos objetivos, como desempenho e funcionalidade.
39
O autor citado no parágrafo anterior destaca que os caminhos seguidos, para

alcançar os objetivos e as restrições impostas sobre cada um, são enumerados, sendo cada
alternativa avaliada em relação a cada objetivo em que os focos de risco do projeto são
identificados. O modelo espiral está representado na Figura 7, a seguir.
Figura 7 – Modelo espiral.

2.3.1.4 Modelo Iterativo e Incremental
Para Bezerra (2002, p. 33), “modelo de ciclo de vida incremental e iterativo foi
proposto como uma resposta aos problemas encontrados no modelo cascata”. Também, ele
relata que o desenvolvimento de um produto de software, seguindo essa abordagem, é
dividido em ciclos, sendo identificadas em cada ciclo de desenvolvimento as fases de análise,
projeto, implementação e testes.
Ele destaca, ainda, que, diferente do modelo em cascata em que as fases de
análise, projeto, implementação e testes, são realizados somente uma vez. Nesse modelo, um
40
processo de desenvolvimento de software divide o desenvolvimento em ciclos, em que cada

um dos ciclos compreende um subconjunto de requisitos.
Seguindo-se a linha de raciocínio anterior, em que os requisitos são
desenvolvidos, e, no ciclo seguinte, outro subconjunto de requisitos é considerado para ser
desenvolvido, produzindo, assim, um novo incremento no sistema que foi estendido a partir
do incremento anterior, em que foram adicionadas novas capacidades funcionais.
Os ciclos prosseguem e, assim, o desenvolvimento evoluir em versões, com a
criação de novas funcionalidades de forma incremental e iterativa até o completo
desenvolvimento do sistema.
O modelo iterativo e incremental é exibido, na Figura 8, apresentando três ciclos
de desenvolvimento para dar um melhor entendimento da sua funcionalidade.
Figura 8 – Modelo iterativo e incremental.

Fonte: Adaptado de Bezerra (2002).
Bezerra (2002, p. 34) comenta, entretanto, que, “no modelo de ciclo de vida
incremental e iterativo, um sistema de software é desenvolvido em vários passos similares
(iterativo). Em cada passo, o sistema é estendido com mais funcionalidades (incremental)”.
Bezerra (2002, p. 34) relata, ainda, que, nesse modelo, a participação do usuário,
nas atividades de desenvolvimento do sistema, diminui bastante a probabilidade de
interpretações erradas quanto aos requisitos levantados.
41
Entretanto, seguindo o mesmo raciocínio do parágrafo anterior o autor citado

comenta que vários autores alertam que, no modelo iterativo e incremental, o usuário pode se
entusiasmar excessivamente com a primeira versão do sistema e querer implementar essa
versão, prejudicando, assim, o andamento do projeto.
Outro ponto positivo a considerar é que os riscos do projeto podem ser mais bem
gerenciados, se seguidos, conforme esse modelo.
2.3.1.5 Método Fusion
A literatura pesquisada referente à reengenharia está embasada nas dissertações,

em que os autores fazem menção na tese desenvolvida por Penteado (1996). O estudo sobre
reengenharia foi realizado tomando, como base, esse rico acervo disponível na internet.
O acervo mencionado aponta para o Método Fusion, utilizado como o método de
desenvolvimento de software por esses autores em suas obras.
Continuando com o trabalho de pesquisa, em que a obra literária dos criadores do
Método Fusion, Coleman et al. (1996), a biblioteca desta instituição possui um exemplar,
teve-se contato direto com a obra e por isso considerou-se conveniente fazer-se referências a
ela.
Os autores citados no parágrafo anterior, quando se referem ao Método Fusion,
afirmam tratar-se de um método de desenvolvimento para produzir software orientado a
objetos, fornecendo recursos para análise, projeto e implementação.
Continuando o raciocínio acima eles destacam que esse método esteja baseado em
um conjunto resumido, porém completo, de notações para coleta de decisão, de análise e de
projeto. Estas notações são discutidas a seguir.
Uma característica a destacar sobre o Método Fusion é que, além do
desenvolvimento de novos sistemas, pode ser aplicado na reengenharia, segundo seus
criadores.
Esse método divide o processo de desenvolvimento em análise, projeto e
implementação. Essas fases serão discutidas, detalhadamente, na seção atividades do processo
de desenvolvimento. Seus autores observam que o método mantém um dicionário de dados
42
para a identificação e descrição detalhada das entidades existentes no sistema, servindo de

referência em todo o processo de desenvolvimento.
Entretanto, seus criadores mencionam que o método não possui uma etapa de
captura de requisitos. Consideram que o documento de requisitos inicial deverá ser fornecido
pelo usuário. O Método Fusion está representado na Figura 9, a seguir.
Figura 9 – Método Fusion.

Fonte: Adaptado de Coleman et al. (1996).
2.3.1.6 Rational Unified Process
O IBM RUP, segundo Sommerville (2007, p. 54), “é um modelo construído por

fases que identificam quatro fases discretas no processo de software”.
Alguns autores argumentam que o IBM RUP é um framework para gerar
processos. Sommerville (2007, p. 54) explica que, diferente do modelo em cascata, as fases
43
coincidem com as atividades do processo. O IBM RUP mantém uma relação mais restrita com
os negócios do que com assuntos técnicos. As fases do IBM RUP são descritas a seguir:
1. concepção ou iniciação – o objetivo dessa fase é instaurar um business case
para o sistema. Portanto, é necessário identificar as entidades externas, ou
seja, pessoas e sistemas que deverão interagir com o sistema. As
informações obtidas servem para avaliar a forma que o sistema contribui
com o negócio. Caso a contribuição seja pequena, o projeto pode ser
cancelado depois dessa fase;
2. elaboração – tem como objetivo desenvolver a compreensão do domínio do
problema, estabelecer um framework de arquitetura para o sistema, criar
um planejamento do projeto, sendo identificados os riscos principais, em
que, no fim dessa fase, um modelo de requisitos para o sistema será criado,
mediante a especificação dos casos de uso em UML, além de uma
descrição da arquitetura e um plano de desenvolvimento para o software.
3. construção – essa fase mantém estreita relação com o projeto, programação
e teste de sistema. O sistema é desenvolvido em partes paralelamente que
serão integradas nessa fase. No final dessa fase, o sistema já estará em
funcionamento com a documentação pronta para ser apresentada aos
usuários.
4. transição – é a fase em que o sistema é transferido da equipe de
desenvolvedores para os usuários, é posto em atividades, funcionando,
normalmente, em seu ambiente operacional.
Ainda, seguindo o relato acima, destaca-se que a iteração do IBM RUP é
constituída de duas formas, cada fase pode ser feita de forma iterativa, tendo resultados
desenvolvidos incrementalmente.
Quanto ao número de iterações, Kruchten (2003, p. 110) destaca que,
costumeiramente na fase de concepção de um projeto, não serão realizadas iterações reais,
devido essa fase normalmente contemplar somente o planejamento e a comercialização de
atividades.
Seguindo-se, ainda, o comentário, citado no parágrafo anterior, na fase de
elaboração, poderá ocorrer uma iteração, na fase de construção e de transição deverá ocorrer
no mínimo uma sendo que, no caso desta em que um software pode ser de baixa qualidade ou
de grande complexidade, haverá a necessidade de mais iterações.
44
Sommerville (2007, p. 54) enfatiza que a visão estática do IBM RUP visualiza as
atividades do processo de desenvolvimento, chamadas de workflows, para tanto são
denominados seis workflows de processos principais e três de apoio.
O IBM RUP foi projetado em conjunto com a linguagem UML, portanto a
descrição dos workflows segue a orientação em termos dos modelos associados.
Sommerville (2007, p. 54) argumenta que a principal vantagem de apresentar as
visões estática e dinâmica é devido às fases do processo de desenvolvimento não estarem
associados aos workflows específicos. Os principais workflows de engenharia e de apoio
podem ser observados na Tabela 1, a seguir.
Tabela 1 – Workflows Estáticos no Rational Unified Process
Workflows Descrição
Modelagem de Os processos de negócios são modelados, usando casos de uso de
negócios negócios.
Requisitos Os agentes que integram com o sistema são identificados, e os casos de
uso são desenvolvidos para modelar os requisitos de sistema.
Análise e projeto Um modelo de projeto é criado e documentado, usando modelos de
arquitetura, modelos de componente, modelo de objeto e modelos de
sequência.
Implementação Os componentes de sistema são implementados e estruturados em
subsistemas de implementação. A geração automática de código com
base nos modelos de projeto ajuda a acelerar esse processo.
Teste O teste é um processo iterativo realizado em conjunto com a
implementação. O teste de sistema segue o término da implementação.
Implantação Uma versão do produto é criada, distribuída aos usuários e instalada no
local de trabalho.
Gerenciamento de Esse workflow de apoio gerencia as mudanças do sistema.
configuração e
mudanças
Gerenciamento de Esse workflow de apoio gerencia o desenvolvimento do sistema.
projetos
Ambiente Esse workflow está relacionado à disponibilização de ferramentas
apropriadas de software para a equipe de desenvolvimento.
45
Segundo Kruchten (2003, p. 3), o IBM RUP pode ser implementado na

reengenharia por meio de artefatos extraídos do sistema legado com a aplicação da engenharia
reversa.
Os processos de desenvolvimentos do IBM RUP podem ser melhores
compreendidos na Figura 10, que demonstra o esforço realizado na atividade das disciplinas
em cada fase.
Figura 10 – Rational Unified Process.

Fonte: Adaptado de Syns (2009).
2.4 PROCESSO DE DESENVOLVIMENTO DA REENGENHARIA
Em se tratando de reengenharia, há várias situações de desenvolvimento, segundo

Coleman et al. (1996, p. 287) que podem ser: o acréscimo de novas funcionalidades com uma
nova tecnologia de implementação, até mesmo a introdução completa de uma nova
tecnologia.
Continuando a citação anterior, eles consideram que a reengenharia deva ser
usada em casos em que haja a necessidade de alteração de alguma ou total funcionalidade do
46
software. Na sequência, é descrito o processo em que é realizada uma implementação parcial

com alterações na funcionalidade:
1. identificar partes do sistema – se faz necessário a identificação da parte do
sistema a ser reimplementado e suas interações;
2. preparar o modelo de análise – partindo da documentação do sistema
existente, cabe aqui a produção de modelos de análise para o sistema ou
parte dele que será submetido a reengenharia;
3. mapear o modelo de análise para o sistema existente – esse mapeamento
está sujeito às seguintes restrições: mapear cada componente da análise e o
relacionamento existente no modelo de análise. Um documento deve conter
um elemento consistente com o código fonte;
4. importar novos requisitos – os modelos sofreram mudanças de acordo com
novos requisitos;
5. avaliar a interface do novo componente – nessa etapa, a interface deve ser
completamente definida, partindo da parte que será trocada e considerando
a parte do sistema restante;
6. projetar um novo subsistema – contempla o projeto do novo componente e
a sua interface para o sistema antigo;
7. modificar o sistema antigo – finalmente, com a adição de uma interface no
sistema antigo, permitindo, assim, que os agentes interajam com os
componentes do novo sistema.
2.4.1 Reengenharia de Software
Com a crescente evolução da tecnologia, a informática atua na linha de frente

dessa metamorfose tecnológica que o mundo globalizado vem sofrendo. Um software robusto
que atue numa área como, por exemplo: um sistema de controle de tráfegos aéreos em que
centenas de software operam em conjunto, são extremamente complexos e caros.
(SOMMERVILLE, 2007, p. 331).
Continuando com a linha de raciocínio, o autor citado sustenta que, com o passar
dos anos esses produtos acabam obsoletos devido a mudanças de tecnologia. Surge a
47
necessidade de implementação de alguma função que por terem sido projetados por uma
metodologia ultrapassada ou uma linguagem de programação em desuso não comportam as
mudanças necessárias.
Sommerville (2007, p. 331) destaca que, no projeto, a partir de um sistema legado,
a reengenharia desse sistema tem vantagens em relação à construção de um novo projeto,
partindo do zero, principalmente, pela redução de riscos devido ao desenvolvimento desse
tipo de software tender a erros de especificação ou problemas no desenvolvimento.
Conforme o raciocínio descrito, no parágrafo acima, o projeto tende a atrasos na
entrega, onerando os custos de desenvolvimento, podendo ocorrer inclusive a perda do
negócio. A reengenharia tem um custo reduzido em relação ao desenvolvimento de um novo
software, por buscar, principalmente, os requisitos no software existente.
Conforme o exposto nessa seção, se torna evidente que a reengenharia deve ser
usada quando da existência de um software legado.
Sommerville (2007, p. 331) enfatiza que a reengenharia de software aplicada, em
sistemas legados, torna sua manutenção fácil.
Seguindo a mesma linha de raciocínio, ele comenta que a reengenharia pode
produzir nova documentação, organização e reestruturação do sistema, convertendo o sistema
legado em uma linguagem de programação moderna com a modificação e atualização da
estrutura existente. O sistema continua a desenvolver suas atividades, com uma interface
atualizada mais moderna.
Jacobson e Lidström (1991, apud PENTEADO, 1996, p. 52) “definem
reengenharia como sendo composta de engenharia reversa + ∆ + engenharia avante”.
Mencionam que o processo seja iniciado com:
• na engenharia reversa, é feita uma definição abstrata do sistema;
• o ∆ é um representativo das modificações de funcionalidades do sistema e
da sua implementação;
• a engenharia avante é o desenvolvimento normal do sistema, criando o
aplicativo propriamente dito em uma linguagem de programação orientada a
objetos.
Segundo Chikofsky e Cross (1990, apud MORAIS, 2003), a reengenharia de
software é uma análise para a alteração de um sistema e reconstruí-lo em outra linguagem de
programação, podendo alterar funcionalidades e adicionar outras, empregando a engenharia
reversa, para identificar o maior número possível de artefatos do sistema e seus
interrelacionamentos.
48
Penteado (1996) destaca três cenários para a reengenharia, relacionados abaixo:

1. trocar a implementação sem perda da funcionalidade;
2. troca parcial da implementação sem perda da funcionalidade;
3. troca da funcionalidade.
Yourdon e Constantine (1978, apud PENTEADO, 1996, p. 52) definem
engenharia reversa como um conjunto de teorias, métodos e tecnologias de apoio ao projeto,
implementando um processo de extração de informações de um software existente,
produzindo a documentação necessária de acordo com o código existente.
Chikofsky e Cross (1990 apud BOSSONARO) definem a engenharia reversa
como sendo um processo para analisar um sistema, identificando seus componentes e
interrelacionamentos, para criação de representações desse sistema em outra forma ou em um
nível mais alto de abstração.
Para Morais (2003), a engenharia reversa, orientada a objetos, possibilita a
recuperação de um modelo de análise, partindo do código fonte do sistema antigo. Esse
modelo será usado na engenharia avante como complemento no processo de reengenharia
orientada a objetos.
Ré (2002) declara, em sua tese, que “um processo de engenharia reversa baseada,
na interface Web, é conduzido para esses sistemas-base, visando a produzir a especificação de
requisitos e, por intermédio dessa especificação, criar um modelo de classe do domínio”. A
Figura 11 representa o processo de engenharia avante x engenharia reversa.
49
Figura 11 – Engenharia Avante x Engenharia Reversa.

Fonte: Adaptado de Schneider (2009).
Para Penteado (1996), a engenharia avante pode ser definida como: “processo
tradicional que se inicia com abstrações de alto nível, lógicas e projetos independentes da
implementação para se chegar à implementação física do sistema, ou seja, o processo de ir do
projeto lógico para o projeto físico do sistema”.
Já para Morais (2003), a engenharia avante é definida como sendo as etapas de:
projeto, implementação e testes, em que foi realizada a engenharia reversa e o modelo
conceitual desse sistema foi obtido.
Os autores pesquisados referem-se ao termo engenharia avante como sendo: o
processo utilizado na engenharia de software que parte de um alto nível para um baixo nível
de abstração, que envolve o domínio do sistema de informação.
2.4.1.1 Avaliação da Reengenharia
Coleman et al. (1996, p. 287) enfatizam que os projetos de desenvolvimento

orientados a objetos enfrentaram o problema da reengenharia. É evidente que o
desenvolvimento de sistemas, partindo do zero, são raros. Também acrescentam que um
sistema legado não sofrerá reengenharia em sua totalidade de uma única vez.
O processo de desenvolvimento, decorrente da reengenharia descrito na seção
anterior, considera que os modelos de análise orientados a objetos podem ser usados para
caracterizar um sistema que não foi originalmente criado com orientação a objetos e que o
Método Fusion fornece um processo de desenvolvimento sistemático de engenharia direta.
Coleman et al. (1996, p. 288), reconhecem que, apesar de ter a publicação de
vários relatórios sobre a experiência de reengenharia, somente estruturas provisórias de
processos foram propostas.
50
2.5 CONCLUSÕES DO CAPÍTULO
O estudo realizado, neste capítulo, está fundamentado nos trabalhos existentes, os

quais consideram a construção de um sistema de software, partindo de um sistema legado.
O principal objetivo dos estudos realizados é evidenciar o uso da reengenharia
para a construção de um protótipo de software orientado a objetos.
A seção 2.1 apresenta conceitos sobre engenharia, dando uma noção do que é a
reengenharia, em que o leitor, a partir desta seção, poderá avaliar seus benefícios. Também
são descritos os principais fundamentos da engenharia do software e de sistemas.
Apresentam-se na seção 2.2 os conceitos de processos de software, demonstrando
as etapas para a realização do processo.
Foram descritos os principais modelos de processo de software na seção 2.3 com
maior ênfase para o processo do IBM RUP, em decorrência de que este processo será a
metodologia referenciada na monografia.
Na seção 2.4, foi descrito o processo de desenvolvimento da reengenharia,
detalhando a forma como será realizado o processo no sistema proposto.
Os artigos pesquisados fazem referências à reengenharia e à engenharia reversa,
entretanto, seus autores não demonstram, claramente, como ocorre a conversão dos dados
para o modelo orientado a objetos. Coleman et al. (1996) reconhece que, apesar de ter a
publicação de vários relatórios sobre a experiência de reengenharia, somente estruturas
provisórias de processos foram propostas.
51
3 MÉTODO
Galliano (1979) resume método como sendo “uma orientação geral, constituída
por um conjunto de etapas, ordenadamente dispostas, a serem vencidas na investigação da
verdade, no estudo de uma ciência ou para alcançar determinado fim”.
O presente capítulo tem como meta demonstrar como os objetivos pretendidos
para o assunto em questão serão alcançados e apresentar o planejamento do trabalho mediante
uma metodologia a ser seguida.
Segundo Andrade (1997), metodologia é o conjunto de métodos a serem seguidos
para alcançar o conhecimento.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
Para tratar-se aqui sobre as particularidades que envolvem métodos, é

imprescindível o perfeito entendimento sobre o que é uma pesquisa. Cervo e Bervian (2002)
definem a pesquisa como sendo: “uma atividade voltada para a solução de problemas teóricos
ou práticos, com o emprego de processos científicos”.
Os autores citados, no parágrafo anterior, afirmam que a pesquisa surge da
necessidade de resolução de um problema, ou do aparecimento de uma dúvida em que a
solução pode vir por meio do uso do método científico.
Cervo e Bervian (2002) definem, como trabalho científico, a pesquisa de caráter
inédito que tenham como objetivos ampliar a fronteira do conhecimento com o
estabelecimento de novas relações de causalidade para fatos e fenômenos conhecidos ou por
meio de novas conquistas para o conhecimento.
Seguindo a mesma linha de raciocínio, os autores mencionados, nesta seção, dão
conta de que o interesse e a curiosidade do homem pelo conhecimento o conduz a pesquisar a
realidade sob diferentes aspectos e dimensões, em que cada tipo de pesquisa tem objetivos
distintos, embora o núcleo de procedimentos seja comum.
Sobre a ótica dos autores citados, nesta seção, que consideram a pesquisa aplicada
em que o investigador é movido pela necessidade de contribuir para fins práticos, na busca de
52
soluções para problemas concretos, cabe esclarecer, aqui, que este trabalho será desenvolvido
sobre esta finalidade de pesquisa, pois contemplará o desenvolvimento de um sistema.
O fundamento teórico constituído, no presente trabalho, foi levado a efeito Poer
meio da pesquisa bibliográfica realizada com apoio de livros e a consulta de outros materiais
disponíveis na internet. A pesquisa bibliográfica, segundo Cervo e Bervian (2002), procura
explicar um problema tendo, como base, teorias e publicações em documentos.
3.2 ETAPAS METODOLÓGICAS
Esta monografia engloba o universo da pesquisa aplicada, ou seja, resolver um

problema concreto (ANDRADE 1997), em que o conhecimento, reunido por intermédio da
pesquisa bibliográfica, conduz a produção de artefatos para a solução do problema proposto
compreende o desenvolvimento de um sistema a partir de um sistema legado.
Como foi necessário um estudo do sistema atual, a compreensão das
funcionalidades desse sistema será realizada a partir da aplicação da engenharia reversa, na
busca de artefatos para a coleta de requisitos e complementada mediante entrevistas com os
usuários do sistema atual, assim, também com a observação das telas de gerenciamento desse
(sistema).
O modelo proposto seguirá a engenharia avante, após a coleta e análise dos
requisitos, em que será adotado um processo de desenvolvimento customizado a partir do
IBM RUP, usando a linguagem de modelagem unificada UML. As etapas metodológicas são
ilustradas na Figura 12, a seguir.
53
Figura 12 – Etapas metodológicas.

Fonte: O Autor.
3.3 PROPOSTA DA SOLUÇÃO
O presente trabalho apresenta como solução para elucidar os problemas

encontrados na administração do controle de patrimônio referente à manipulação dos bens do
TRT/SC, por intermédio das funções de inserção, atualização e movimentação, uma
ferramenta multiplataforma, desenvolvida na linguagem de programação Java para ambiente
WEB.
O autor destaca que, o sistema é acessado em qualquer estação de trabalho via
intranet pelos seus colaboradores. É oportuno lembrar que o acesso ao sistema atual é feito
54
pela autenticação do usuário, com poderes específicos fornecidos pelo administrador do

sistema. O sistema atual é exibido na Figura 13, a seguir.
Figura 13 – Sistema atual.

Fonte: Adaptado de Twiki (2007).
O sistema proposto adotará o mesmo sistema de acesso de usuários. Os pedidos de
material permanente serão efetuados remotamente, não havendo mais a necessidade de
pedidos em formulários impressos. A proposta de solução que envolverá o novo sistema é
demonstrada na Figura 14, a seguir.
55
Figura 14 – Sistema proposto.

Fonte: O Autor.
3.4 DELIMITAÇÕES
O protótipo de software, desenvolvido em decorrência dos estudos realizados

nesta monografia, está delimitado devido à complexidade e o volume de informações
coletadas, conforme segue:
• não será implementado a segurança por meio de usuário e senha;
• o protótipo de sistema não contempla o pedido de material via WEB;
• a forma de configuração e instalação do sistema não é apresentada na
monografia;
• o protótipo será desenvolvido, usando IBM RUP como metodologia
customizado para as necessidades do sistema;
• não será feito análise ergonômica do sistema atual;
• o modelo relacional será construído com base no sistema atual;
56
Neste capítulo foi apresentado o planejamento, baseado na pesquisa aplicada, para

a futura concepção do sistema proposto, utilizando o IBM RUP como processo.
57
4 PROCESSO DE DESENVOLVIMENTO
Este capítulo envolve a teoria sobre o processo de desenvolvimento do sistema,

destacando a modelagem, com foco sobre a Reengenharia e a construção do protótipo do
sistema na prática.
Muitos tipos de modelos são projetados para vários propósitos antes de construir
algo, permitindo conhecer o propósito antes de construí-lo. (BOOCH, 2000; RUMBAUGH,
1994).
A modelagem segundo os autores citados acima, é o componente central, que
envolve todas as atividades responsáveis à implantação de um sistema de software. Muitos
elementos contribuem para o sucesso do software, a utilização da modelagem é um desses
componentes.
Um sistema submetido à engenharia reversa é um sistema produzido a partir do
sistema original, que normalmente não possuía modelagem, ou que o modelo não foi
atualizado, ou sincronizado com o código fonte. (PENTEADO 1993, p. 125).
4.1 CUSTOMIZAÇÃO DO IBM RUP
Para um produto de software ter qualidade, esta qualidade depende dos processos
de software utilizados no desenvolvimento e manutenção desse produto. (KRUCHTEN,
2003). O autor citado, neste parágrafo, salienta, no entanto, que o processo deve ser tanto
enxuto quanto possível, evitando assim trabalho dispendioso da equipe de desenvolvedores.
Para a produção dos modelos do sistema proposto, de maneira previsível e
consistente, adotou-se o IBM RUP como processo, de forma customizada para a definição do
processo de desenvolvimento.
Um processo de software contempla uma sequência de atividades, que devem ser
executadas durante a elaboração do processo, produzindo papéis e artefatos resultantes dessas
atividades. (KRUCHTEN, 2003). Uma descrição detalhada do processo de desenvolvimento
será desenvolvida nas seções seguintes que contempla as fases do IBM RUP.
58
A ferramenta EA será utilizada para produção dos artefatos do processo de análise

e projeto do nesta monografia.
Na sequência, nas próximas seções, são aplicadas as atividades de cada uma das
quatro fases do IBM RUP customizado, descritas no capítulo anterior, com as disciplinas em
cada fase, demonstrando os fluxos de trabalho mais importantes para o projeto proposto.
4.1.1 Concepção
Segundo Rational (2009), formular o escopo do projeto é uma das atividades

básicas da fase de concepção que envolve a captura do contexto, descreve os casos de uso
para a elaboração dos requisitos, e as principais restrições para a obtenção de critérios para
aceitação do produto que será desenvolvido. Esta fase tem como meta o consenso entre os
integrantes da equipe sobre o objetivo do ciclo de vida do projeto.
As disciplinas para a fase de concepção são exibidas nas subseções sequentes.
4.1.1.1 Gerenciamento de Projeto
Esta disciplina tem como principais tarefas:

1. conceber novo projeto – o detalhamento deste fluxo de trabalho procura
apresentar o projeto, partindo de uma idéia até o momento em que se deve
tomar a decisão de continuar ou abandonar o projeto;
2. avaliação escopo e risco do projeto – neste detalhamento, procura-se
reavaliar as capacidades pretendidas e as características do projeto,
identificar possíveis riscos, com isso é possível fornecer uma base sólida do
planejamento;
3. elaborar plano de desenvolvimento de software – aqui são desenvolvidos os
componentes e o material incluso no Plano de Desenvolvimento de
Software, obtendo-se, assim, a concordância dos envolvidos no projeto;
59
4. planejar próxima iteração – a principal finalidade aqui é a criação de um

plano de iteração. A Figura 15, na sequência, representa a disciplina de
gerenciamento de projeto com as tarefas que foram descritas acima.
(RATIONAL 2009).
Figura 15 – Workflow Gerenciamento de Projeto.

Fonte: Adaptado de Rational (2009).
Na disciplina de Gerenciamento de projeto foram elaborados os seguintes
artefatos:
• Visão (APÊNDICE A);
• Glossário (APÊNDICE B);
• Lista de Riscos (APÊNDICE C);
• Plano de Desenvolvimento de Software (APÊNDICE D);
• Plano de Iteração (APÊNDICE E).
4.1.1.2 Requisitos
São descritas as principais tarefas relevantes ao projeto da disciplina de requisitos

a seguir:
1. compreender as necessidades dos envolvidos – a principal finalidade deste
fluxo de trabalho é obter informações do sistema existente e dos envolvidos
no projeto, para o entendimento de suas necessidades;
2. definir sistema – é necessário o entrosamento dos membros da equipe do
projeto, coletar as solicitações dos envolvidos e refinar o documento de
visão;
3. gerenciar o escopo do sistema – dar prioridade às informações obtidas,
realizando um refinamento e encontrando os requisitos do sistema e definir
os casos de uso de algumas funcionalidades do sistema. A Figura 16, a
60
seguir, representa a disciplina de requisitos, exibindo as tarefas exibidas

nesta seção. (RATIONAL 2009).
Figura 16 – Workflow Requisitos.

Nesta disciplina, foram gerados os artefatos:
• Especificação de Requisitos de Software (APÊNDICE F);
• Guia de Modelagem de Casos de Uso (APÊNDICE G);
• Especificação de Casos de Uso primários (APÊNDICE H).
4.1.2 Elaboração
Na fase de elaboração, será criado um baseline, ou seja, uma imagem da versão

revista e aprovada dos artefatos que compõem o repositório do projeto, fornecendo uma base
estável para a fase de construção. (RATIONAL 2009).
Nessa disciplina, segundo Rational (2009), a principal tarefa é um refinamento do

Plano de Desenvolvimento de Software que será atualizado e expandido, cobrindo, assim, as
fases de Construção e Transição. A Figura 17, a seguir, representa esse workflow.
Figura 17 – Workflow Refinamento do Plano de Desenvolvimento.

61

Nesta disciplina, foi atualizado o Plano de Desenvolvimento de Software
(APÊNDICE D);
4.1.2.2 Requisitos
Foi realizado um refinamento na Definição do sistema em que houve um

detalhamento dos casos de uso primários e descrição dos atores envolvidos no projeto. Os
artefatos revistos são:
• Especificação de Casos de Uso primários (APÊNDICE H).
4.1.2.3 Análise e Design
Na presente fase, a disciplina Análise e Design faz um esboço, desenvolvendo,

assim, uma arquitetura inicial, fornecendo um ponto de partida para o trabalho de análise
inicial. (RATIONAL 2009).
Detalharam-se os fluxos de trabalho de:
1. analisar comportamento – criar os elementos no qual o design possa se
basear a partir das descrições de comportamentos oferecidos pelos casos de
uso;
2. analisar base de dados – obter a base de dados do sistema legado
utilizando a engenharia reversa, usando ferramentas CASE;
3. projetar componentes – realizar um refinamento nas definições dos
elementos de design. O workflow referente à análise e design é
representado pela Figura 18, a seguir.
62
Figura 18 – Workflow Análise e Design.

Nesta disciplina, foram gerados os artefatos de:
• Documento de Arquitetura de Software (APÊNDICE I);
• Guia de Design do sistema atual (APÊNDICE J);
• Guia de Design do sistema proposto (APÊNDICE K);
• Especificação de Realização de Casos de Uso (APÊNDICE L).
4.1.2.4 Ambiente
O foco desta disciplina está nas atividades necessárias à configuração do processo

para um projeto, tendo como meta oferecer à organização um ambiente de desenvolvimento
de software, processos e ferramentas, dando suporte, assim, aos desenvolvedores.
(RATIONAL 2009). A Figura 19 demonstra o workflow referente à disciplina ambiente.
Figura 19 – Workflow Ambiente.

Nesta disciplina, foi atualizado o artefato de:
• Guia do Sistema Atual (APÊNDICE J).
63
4.1.3 Construção
Esta fase estabelece a conclusão do desenvolvimento do sistema, implementando

os requisitos finais, levando em conta a arquitetura da baseline. É considerado como sendo
um processo de manufatura, tendo como foco o gerenciamento de recurso e o controle de
operações, otimizando custos, produzindo programação de qualidade. (RATIONAL 2009).
O produto será desenvolvido de forma iterativa e incremental, pronto para
transição, ou seja, a entrega aos usuários, dessa forma serão desenvolvidos os casos de uso
restantes bem como os requisitos finais. Para isso, será incrementado o design, concluindo a
implementação e os testes do software.
Para o projeto em questão, foram consideradas as disciplinas discutidas nas seções
seguintes.
4.1.3.1 Implementação
Para implementar o projeto, foram considerados os seguintes fluxos de trabalho:

1. implementar componentes – após a escrita dos códigos fontes, os
componentes são adaptados, distribuídos e testados separados pelo
implementador;
2. integrar o sistema – ao final dos testes preliminares, o sistema pode ser
integrado e testado por um testador. (RATIONAL 2009). A Figura 20,
exibe o workflow referente à disciplina implementação.
Figura 20 – Workflow Implementação.

Na presente disciplina, foram atualizados os artefato de:
64
• Plano de Iteração (APÊNDICE E).
4.1.3.2 Testes
Os testes realizados levam em conta o fluxo de trabalho:

1. definir missão de avaliação – este fluxo de trabalho procura identificar o
foco adequado de esforço de teste. (RATIONAL 2009). A Figura 21
representa este workflow.
Figura 21 – Workflow Teste.

Artefato gerado:
• Guia de Teste (APÊNDICE M).
4.1.4 Transição
A importância desta fase está em assegurar que o usuário tenha a sua disposição o
software. É, nessa fase que deve ocorrer o maior número de iterações, estando incluso,
portanto, o teste do produto para o seu lançamento com pequenos ajustes com base no
feedback do usuário. (RATIONAL 2009).
Torna-se importante ressaltar, no entanto, que os ajustes realizados, a
configuração, a instalação, além dos problemas de usabilidade, são resolvidos aqui e que
problemas estruturais mais graves foram tratados nas fases anteriores. (RATIONAL 2009).
Consideraram-se as disciplinas descritas nas seções seguintes.
65
4.1.4.1 Implantação
Esta disciplina tem como objetivo disponibilizar o software para o usuário final.
Os fluxos de trabalho relevantes para o projeto, em questão, relacionados à implantação são:
1. produto de teste beta – ao criar um programa beta, o desenvolvedor obtém
um feedback sobre o produto em desenvolvimento de uma parcela de
usuários. (RATIONAL 2009). A Figura 22, a seguir, representa o
workflow para o produto de teste beta.
Figura 22 – Workflow Produto de Teste Beta.

O artefato gerado para este detalhamento da disciplina foi:
• Plano de Implantação (APÊNDICE N).
Os obstáculos foram superados, e o produto está pronto para ser entregue, os

fluxos de trabalho inerentes a esta disciplina são:
1. finalizar o projeto – o projeto é preparado para o enceramento, uma
avaliação de status final á preparada para a revisão de aceitação do
projeto, em que o cliente dá o aceite final, finalizando, assim, o projeto.
(RATIONAL 2009). A Figura 23, a seguir, representa este workflow.
66
Figura 23 – Workflow Finalizar Projeto.

O artefato atualizado para este detalhamento da disciplina foi:
• Plano de Desenvolvimento de Software (APÊNDICE D).
4.2 AMBIENTE DE DESENVOLVIMENTO
Esta seção tem por objetivo descrever a tecnologia aplicada no desenvolvimento

do sistema, bem como as ferramentas utilizadas em todo trabalho. A Figura 24 ilustra o
cenário tecnológico utilizado, demonstrando a maneira como as ferramentas interagem.
Figura 24 – Ambiente tecnológico.

Fonte: O Autor.
67
A seguir realizou-se uma descrição das ferramentas utilizadas e ilustradas na

Figura 24.
Os artefatos do modelo de desenvolvimento são disponibilizados por meio de
templates fornecidos juntamente com metodologia IBM RUP, discutida no capítulo 2, estes
artefatos foram customizados utilizando o editor de textos MS Word, tidos como a principal
documentação do sistema e estão disponibilizados nos apêndices desta monografia.
A ferramenta Enterprise Architet foi utilizada para realizar a engenharia reversa
nas bases de dados, em que se obtiveram os modelos persistentes referentes ao sistema atual,
uma vez que este sistema acessa várias bases de dados. Foram gerados os artefatos
necessários para a criação da base de dados do sistema proposto.
Oracle é o banco de dados relacional, utilizado pelo TRT/SC para a persistência
de dados, que o protótipo do sistema fará acesso utilizando DAO.
A IDE IBM Eclipse é responsável pela codificação na linguagem de programação
Java do sistema proposto com apoio da IDE Macromedia Dreamweaver, utilizada para a
geração dos arquivos JSP.
Apache Tomcat é o servidor WEB para o sistema desenvolvido em linguagem de
programação Java.
Apache Ant é a ferramenta que realiza a construção (deploy) da aplicação, ou seja,
compila o projeto em pacotes e transfere os arquivos necessários para o servidor WEB.
Java é a linguagem de programação utilizada na criação dos arquivos fontes, que
serão compilados via ferramenta Apache Ant e copiados da aplicação para o servidor WEB
local.
XML gera a linguagem de marcação para o projeto. É um dos formatos de arquivo
de configuração do servidor WEB, da ferramenta Apache Ant, em que este último contém o
arquivo build.xml, responsável pelo roteiro de compilação, empacotamento e distribuição do
aplicativo.
SERVLET são as classes Java responsável por processar as requisições e
respostas do lado servidor.
BROWSER é a ferramenta utilizada para acessar o sistema remotamente a partir
da máquina do cliente.
HTML é a linguagem de marcação utilizada para escrever páginas WEB. As
páginas criadas em HTML podem ser estilizadas, utilizando CSS e validadas com JavaScript,
uma linguagem de programação interpretada no lado cliente.
68
4.3 IMPLEMENTAÇÃO DO SISTEMA
Ao finalizar a compilação e o empacotamento do sistema, mediante o uso da

ferramenta Apache Ant, é gerado um arquivo compactado de nome: sgpat.war, o mesmo é
instalado no diretório webapps do servidor WEB. Os colaboradores acessam à tela inicial, ao
abrir um navegador como Mozila Firefox, utilizando um:
• endereço digitado no navegador ou browser;
• link do tipo favoritos no navegador;
• link na página da intranet do TRT/SC. Observação: este estará disponível
somente com o sistema proposto definitivo, não sendo contemplado no
protótipo.
Ao acessar o sistema via o browser pela primeira vez, o arquivo sgpat.war é
descompactado no diretório corrente, iniciando-se, assim, o primeiro acesso. A Figura 25
exibe a tela inicial do sistema.
Figura 25 – Tela Inicial.

Fonte: O Autor.
69
O protótipo do sistema contempla a inserção de um novo patrimônio, em que o

colaborador pressiona o botão “Patrimônio” na tela inicial, no item “Inserir”, o sistema exibe
a tela de cadastro de patrimônio.
O autor comenta que o fluxo de eventos, ocorrido nesse ambiente, poderá ser mais
bem compreendido com o artefato adaptado do IBM RUP, Especificação de Realização de
Caso de Uso, descrito no Apêndice K, item K3. A tela de inserção de um novo patrimônio
está demonstrada na Figura 26, a seguir.
Figura 26 – Tela Inserir Patrimônio.

Fonte: O Autor.
Com a tela de cadastro de patrimônio aberta, o colaborador necessita popular os
campos obrigatórios, inicialmente realizando as pesquisas na base de dados. De posse do
documento “Nota de Empenho de Material Permanente”, é informado o número desse
documento, ao pressionar o botão de pesquisa, o sistema exibe a tela com o resultado da
consulta.
O fluxo de eventos, ocorrido neste ambiente, segundo o autor, está descrito no
artefato adaptado do IBM RUP, Especificação de Realização de Caso de Uso, Apêndice K
item K6. Esta consulta esta demonstrada na Figura 27, a seguir.
70
Figura 27 – Tela Consultar Itens da Nota de Empenho.

Fonte: O Autor.
Na tela acima, são visualizados os itens referentes à nota de empenho, citada no
parágrafo anterior, o colaborador pressiona o botão enviar, os dados necessários ao cadastro
do patrimônio referentes a esta pesquisa são carregados na tela de cadastro de patrimônio.
Outras pesquisas são necessárias para a perfeita realização da inclusão de um
novo patrimônio. Essas pesquisas seguem o mesmo princípio da pesquisa de nota de
empenho, e tem o fluxo de evento demonstrado nos Apêndices desta monografia.
Ao popular os itens obrigatórios da tela de cadastro de patrimônio, o colaborador
pressiona no botão “Salvar” e o sistema fecha a tela de cadastro de patrimônio e, se o cadastro
é bem sucedido, abre a tela de confirmação de inserção. A tela de confirmação é visualizada
na Figura 28, a seguir.
Figura 28 – Tela de Aviso de Confirmação de Inserção.

Fonte: O Autor.
Após a inserção, o colaborador tem as opções de retornar para realizar um novo
cadastro, ou retornar a tela inicial do sistema.
71
O presente capítulo na Seção 4.1 demonstra a customização do processo IBM

RUP para o protótipo do sistema proposto. Foram abordadas as quatro fases e as disciplinas
deste processo nas subseções seguintes, sendo apresentados os papeis mais relevantes para o
projeto em questão.
Na Seção 4.2 apresentou-se a tecnologia utilizada no desenvolvimento do sistema
com uma breve descrição das ferramentas utilizadas.
Uma abordagem sobre o processo de implementação do sistema esta descrito na
Seção 4.3, em que o leitor tem a informação da forma de instalação do protótipo a realização
do cadastramento do patrimônio.
72
5 TESTE E VALIDACÃO
Neste Capitulo será realizado teste e a validação do protótipo construído nos

capítulos anteriores.
5.1 TESTE
O protótipo conta com cinquenta e nove arquivos, entre classes, arquivos de

configuração, validação e de imagens. A base de dados conta com sete tabelas, duas
sequências e um procedimento.
Em cada etapa implementada, foram realizados os testes unitários de rotinas nos
códigos para a realização das consultas, evitando-se a ocorrências de erros nas consultas e no
cadastramento do patrimônio.
Os testes foram realizados com a inserção de valores do tipo texto em campos
numéricos com resposta imediata via JavaScript, em que esses valores errôneos são
removidos e são aceitos somente os valores numéricos inteiros ou de ponto flutuante em
campos como peso. A integridade dos campos obrigatórios
Não foram utilizadas ferramentas ou uma metodologia específica. Os resultados
dos testes podem ser observados na, Tabela 2, a seguir.
Tabela 2 – Testes realizados no protótipo.
Descrição Resultado Forma de validação
Campos obrigatórios Não permitido campo vazio JavaScript
Campos numéricos Somente permitido números de 0 a 9 JavaScript
Campos de ponto Somente permitido números de 0 a 9 e JavaScript
flutuante somente uma vírgula
Campos de texto Retira aspas simples ou duplas antes de Tratamento do
gravar código em Java
Fonte: O Autor.
73
5.2 VALIDAÇÃO
O foco na construção do protótipo, foi os serviços executados pelo SCAB, tendo o

cadastro de patrimônio a maior atenção voltada, sendo este uma das inúmeras funções
atribuídas ao setor referido neste parágrafo.
No decorrer do desenvolvimento do protótipo, houve a iteração dos colaboradores
do SCAB, apontando as reais necessidades do setor, e sugerindo alterações, como o uso da
tecla enter para navegar entre os campos.
Algumas sugestões, em relação ao sistema atual, foram descritas no artefato do
IBM RUP Apêndice A – Visão, que, posteriormente, a esta monografia no desenvolvimento
do sistema proposto serão atendidas.
Os colaboradores não tiveram dificuldades na execução da atividade de cadastro
de patrimônio devido aos campos de preenchimento conter rótulos com o título coerente e nos
campos obrigatórios o uso de asteriscos para indicar a obrigatoriedade de seu preenchimento.
O protótipo foi considerado de fácil acesso e a interface, atendendo ao quesito de
usabilidade, com uma performance razoável, quanto ao tempo de acesso à base de dados.
74
6 CONCLUSÕES E RECOMENDAÇÕES
O presente Capítulo apresentada as conclusões e as recomendações para o

desenvolvimento de trabalhos futuros.
6.1 CONCLUSÕES
O aprendizado construído, no decorrer do curso, e o rico acervo disponibilizado

na biblioteca desta Instituição de Ensino foram de fundamental importância para o
desenvolvimento do projeto.
As maiores dificuldades encontradas na concepção do trabalho, foram:
• o pouco conhecimento do IBM RUP, que despendeu muito tempo e esforço
na sua compreensão e customização devido ao fato, que, o IBM RUP é um
processo de desenvolvimento que contempla pequenos e grandes projetos;
• a adaptação do processo para considerar a reengenharia;
• as ferramentas CASE, abordadas nas obras pesquisadas, não comportarem
as linguagens de programação utilizadas no sistema atual, ocasionando a não
migração dessas linguagem para a linguagem Java. O autor relata aqui, que,
por este motivo a Engenharia Reversa não pode ser utilizada na sua totalidade
no presente trabalho;
• a dificuldade de acesso à base de dados, teve seu peso no desenvolvimento
do trabalho, em que os estudos realizados nos fragmentos do material cedido
pela instituição, forneciam um entendimento sobre o sistema atual,
incompatível com a realidade, havendo alteração parcial na modelagem que já
estava pronta. Este estudo foi mais tarde sanado com a permissão total a base
de dados em que foi realizada a engenharia reversa, complementado com as
observações realizadas nas interfaces e o levantamento de requisitos com os
usuários.
Fica aqui registrado que foi de fundamental importância a colaboração prestada
quanto ao material cedido pela Instituição, para a realização deste projeto.
75
A elaboração do projeto de conclusão do curso, bem como o protótipo de sistema

desenvolvido, foram de fundamental importância para o amadurecimento e crescimento
pessoal e profissional, em que novas oportunidades na carreira começam a surgir.
6.2 RECOMENDAÇÕES
Para trabalhos futuros, recomenda-se um estudo aprofundado nas ferramentas para

a realização da engenharia reversa, orientada a objetos, visando à recuperação de artefatos de
um sistema desenvolvido em alguma linguagem obsoleta para uma linguagem moderna como
Java ou C++. Uma vez que no trabalho aqui desenvolvido somente houve a realização da
engenharia reversa na base de dados, complementada com a entrevista aos usuários e
conclusões tiradas mediante a visualização das interfaces.
Ao jovem acadêmico, que se empenhe no dia a dia, que estude muito, dedique seu
tempo à leitura, exercite as atividades propostas em sala de aula, pois a monografia é o fruto
do conhecimento acumulado durante a vida estudantil, complementado com a academia. E,
com certeza, será o cartão de visitas do futuro profissional.
76
REFERÊNCIAS
ANDRADE, Maria M. Introdução à Metodologia do Trabalho Científico. 2. ed. São Paulo:

Atlas, 1997.
BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de

Janeiro: Campus, 2002.
BOOCH, Grady; RUMBAUGH, James; JACOBSON, Ivar. UML Guia do Usuário. Rio de
BOSSONARO, Adriano A. Método RSCT Reengenharia Orientada a componentes

usando Transformações, 2004 . Disponível em: <
http://www.bdtd.ufscar.br/tde_busca/arquivo.php?codArquivo=888>. Acesso em: 22 set.
2009.
BRAGA, Rosana T. V. Engenharia Reversa e Reengenharia, 2006. Disponível em:

<http://www.inf.ufpr.br/silvia/ES/reengenharia/reengenharia.pdf>. Acesso em: 24 set. 2009.
BRASIL. Tribunal Regional do Trabalho de Santa Catarina. Secretaria da Corregedoria.

Movimento Processual. Disponível em:
<http://www.trt12.jus.br/portal/areas/seest/extranet/estatisticas/movimentoprocessual.jsp >.
Acesso em: 3. set. 2009A.
BRASIL. Tribunal Regional do Trabalho de Santa Catarina. Serviço de Material e Patrimônio.

Atribuições. Disponível em: < http://www.trt12.jus.br/portal/areas/semap/intranet/scab.jsp>.
Acesso em: 3. set. 2009B.
CAVALCANTE, Rodrigo G. Importância da História da Engenharia na Sociedade

Contemporânea. Disponível em: <
http://rodgcav.googlepages.com/IE_historia_engenharia.pdf>. Acesso em: 17 set. 2009.
CERVO, Amado Luiz; BERVIAN, Pedro A. Metodologia científica. 5. ed. São Paulo:
Prentice Hall, 2002.
CHIKOFSKY, Elliot J., CROSS, James H. Reverse Engineering and Design Recovery: a
Toxonomy. IEEE Software, p. 13-17, 1990
COLEMAN, Derek et al. Desenvolvimento Orientado a Objetos o Método Fusion. Rio de

GALLIANO, A. Guilherme. O Método Científico: Teoria e Prática. São Paulo: Harbra,

1979.
HOUAISS, Antônio. Dicionário Houaiss da língua portuguesa. Rio de Janeiro: Objetiva,

c2001.
77
JONES, Meiler P. Fundamentos do Desenho Orientado a Objeto com a UML. São Paulo:
Makron Books, 2001.
KRUCHTEN, Philippe. Introdução Ao IBM RUP - Rational Unified Process. Rio de

Janeiro: Ciência Moderna, 2003.
MAFFEO, Bruno. Engenharia de Software e Especificação de Sistemas. Rio de Janeiro:
Campus, 1992.
MARTINS, José C. C. Gerenciando Projetos de Desenvolvimento de Software com PMI,

IBM RUP e UML. 4. ed. Rio de Janeiro: Brasport 2007.
MORAIS, Rinaldo M. Um Estudo para Escolha do SGBD para Sistemas Submetidos à

Reengenharia Orientada a Objetos. Disponível em: <
http://www.bdtd.ufscar.br/tde_busca/arquivo.php?codArquivo=190>. Acesso em: 15 set.
2009.
PANAGOPOULOS, Thomas. Glossário do SIG. Disponível em: <

http://w3.ualg.pt/~tpanago/glossario.htm>. Acesso em: 3. set. 2009.
PENTEADO, Rosângela A. D. Um Método para Engenharia Reversa Orientada a

Objetos. Disponível em: < http://www.teses.usp.br/teses/disponiveis/76/76132/tde-02022009-
114503/>. Acesso em: 17 set. 2009.
PRESSMAN, Roger S. Engenharia de Software. São Paulo: Pearson Makron Books, 1995.
RATIONAL. Rational Rose Developer for UNIX. Disponível em: <http://www-

142.ibm.com/software/products/br/pt/rosedevuni>. Acesso em: 8 out. 2009.
RATIONAL Soluções. Disponível em: <http://www.wthreex.com/IBM

RUP/portugues/index.htm>. Acesso em: 8 nov. 2009.
RÉ, Reginaldo. Um Processo para Construção de Frameworks a partir da Engenharia

Reversa de Sistemas de Informação Baseados na Web: Aplicação ao Domínio dos
Leilões Virtuais. Disponível em: < http://www.teses.usp.br/teses/disponiveis/55/55134/tde-
20052003-120738/>. Acesso em: 17 set. 2009.
SCHNEIDER, Ricardo. L. Engenharia Reversa na Engenharia de Software. Disponível

em: < http://www.dcc.ufrj.br/~schneide/es/2001/1/g18/Engenharia%20Reversa.htm>. Acesso
em: 23 set. 2009.
SOMMERVILLE, Ian. Engenharia de Software. 8 ed. São Paulo: Addison Wesley, 2007.
SYNS, T. Soluções em Tecnologias da Informação. Disponível em: <

http://www.synstec.com.br/synsweb/faces/metodologia.jsp>. Acesso em: 23 set. 2009.
SYSTEMS, Sparx. Enterprise Architect. Disponível em:

<http://www.sparxsystems.com/products/ea/downloads.html>. Acesso em: 8 out. 2009.
TWIKI. VPNs com IPSec e Linux 2.6, 2007. Disponível em:

<http://wiki.sintectus.com/bin/view/grupoLinux/ArtigoVPN>. Acesso em: 24 out. 2009.
78
APÊNDICES
79
APÊNDICE A – Visão
INTEGRAÇÃO DSW ME
SGPAT
Visão
Versão 1.0
SGPAT Versão: 1.0
Visão Data: 18/11/2009
AP - A
Histórico da Revisão
Data Versão Descrição Autor
18/11/2009 1.0 Versão inicial Soni
22/11/2009 1.0 Revisão Usuário Soni
20/04/2010 1.0 Revisão Usuário Soni
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 11

SGPAT Versão: 1.0
AP - A
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
1.2 Escopo 4
1.3 Definições, Acrônimos e Abreviações. 4
1.4 Visão Geral 4
2. Posicionamento 4
2.1 Oportunidade de Negócios 4
2.2 Descrição do Problema 4
2.3 Sentença de Posição do Produto 5
3. Descrições dos Envolvidos e Usuários 5

3.1 Demografia do Mercado 5
3.2 Resumo dos Envolvidos 5
3.3 Resumo dos Usuários 6
3.4 Ambiente do Usuário 6
3.5 Perfis dos Envolvidos 6
3.5.1 Desenvolvedor 6
3.6 Perfis de Usuários 7
3.6.1 Usuário 7
3.7 Principais Necessidades dos Usuários ou dos Envolvidos 7
3.8 Alternativas e Concorrência 9
4. Visão Geral do Produto 10

4.1 Suposições e Dependências 10
4.2 Custo e Preço 10
4.3 Licenciamento e Instalação 10
5. Recursos do Produto 10
5.1 Cadastro Consulta e Relatórios 10
5.2 Segurança 10
6. Restrições 10
7. Faixas de Qualidade 10
8. Precedência e Prioridade 10
9. Outros Requisitos do Produto 10

9.1 Requisitos do Sistema 10
9.2 Requisitos Ambientais 10
9.3 Manual do Usuário 10
9.4 Ajuda On-line 11

SGPAT Versão: 1.0
AP - A
Visão
1. Introdução
1.1 Finalidade
O documento de visão do SGPAT foi elaborado com a finalidade de definir, de forma inequívoca, o escopo do
sistema, permitindo um entendimento entre os principais envolvidos, facilitando a comunicação com o
desenvolvedor e servindo como instrumento de verificação dos objetivos a serem alcançados.
1.2 Escopo
A visão do SGPAT está relacionada à criação do sistema proposto pela reengenharia do sistema existente em que
esse fará o controle de patrimônio do TRT/SC, em ambiente WEB.
1.3 Definições, Acrônimos e Abreviações.

Ver Glossário.
1.4 Visão Geral

Este documento descreve os principais envolvidos no sistema, apresentando as principais necessidades dos
colaboradores, bem como as características do sistema que atendem a estas necessidades. A seguir, é apresentada a
estrutura do documento por intermédio das seções:
A seção 2 da uma noção geral do sistema.
A seção 3 descreve os principais envolvidos no sistema
2. Posicionamento
2.1 Oportunidade de Negócios

No mercado, é possível a aquisição de sistemas prontos, ou licitados personalizado sobre encomenda. No primeiro
caso, porém um sistema para atender ás necessidades da empresa terá de ser adaptado, que, em muitos casos, resulta
num retalho de códigos, de forma que as atualizações e manutenção desse sistema passam a ser uma aventura. Um
sistema personalizado, seguindo uma metodologia em uma linguagem de programação como exemplo Java atende
as necessidades da empresa com uma melhor manutenabilidade.
2.2 Descrição do Problema

O problema é apresentado, conforme a tabela abaixo:
O problema de gerenciamento de patrimônio
afeta os envolvidos na administração do patrimônio
cujo impacto é a prestação de contas do patrimônio público
uma boa solução seria criar um sistema de controle em ambiente WEB, integrando
todo o TRT/SC

SGPAT Versão: 1.0
AP - A
2.3 Sentença de Posição do Produto

Para TRT/SC
Quem controla a administração do patrimônio
O (nome do produto) SGPAT
Que será padronizado segundo a padronização da empresa
Diferente do sistema atual ou produtos stand-alone
Nosso produto um sistema WEB, desenvolvido em Java orientado a objetos
3. Descrições dos Envolvidos e Usuários

Os envolvidos e usuários do sistema estão descritos na tabela abaixo, entretanto foram omitidos nomes evitando-se
assim problemas com autorizações:
Nome O que representa no projeto Papel
SEINFO Administra Abrange a área de informática do
TRT/SC
SEDES Apoio, contato Desenvolve e gerencia os projetos
(Gerente de Projeto) do TRT/SC
DESENVOLVEDOR Desenvolvimento de todo o Desenvolver o projeto proposto
projeto
SEMAP Colaborador Recebe relatórios
(Colaborador SEMAP)
SCAB Colaborador Administrar e controlar o
(Colaborador SCAB) patrimônio do TRT/SC
SELCO Colaborador Administra a relação de
fornecedores
OUTROS Colaborador Normalmente os setores que fazem
COLABORADORES o pedido de patrimônio para as
unidades
3.1 Demografia do Mercado

Nenhuma
3.2 Resumo dos Envolvidos

Os principais envolvidos no sistema são:
Nome Descrição Responsabilidades
XXXXX Diretor SEINFO Administrar os setores que fazem parte da
Secretaria de Informática
XXXXX Contato no SEDES Gerente de projetos
Desenvolvedor Soni João da Silva Desenvolver o projeto

SGPAT Versão: 1.0
AP - A
3.3 Resumo dos Usuários

Os principais usuários do sistema estão descritos na tabela a seguir:
Nome Descrição Responsabilidades Envolvidos
XXXX Diretor do SEMAP Administrar os Setores que fazem do Imprimir relatórios da

SEMAP situação dos patrimônio
XXXX Chefe do SCAB Administrar o setor de cadastro Coordenar os trabalhos do

administração de patrimônio setor
XXXX Funcionário do Acesso ao sistema para cadastro, Usuário principal do sistema

SCAB atualização e manipulação de
patrimônio

patrimônio

patrimônio
XXXX Funcionário do Acesso ao sistema para cadastro,

SELCO atualização e manipulação de
fornecedores
Outros Setores que fazem Fazer pedidos, receber termo de Consulta e pedido
setores pedidos recebimento do patrimônio
3.4 Ambiente do Usuário

Os usuários principais do sistema são os colaboradores do SCAB que administram e controlam o patrimônio,
possuem escolaridade de nível médio e nível superior, com conhecimento básico em informática. O sistema deverá
ter um acesso simultâneo de no máximo 30 usuários. As plataformas usadas pelo TRT/SC, são sistemas MS
Windows 98 e XP, o sistema será acessado por meio de um navegador como Mozilla Firefox versão 3.0 ou superior.
3.5 Perfis dos Envolvidos

O perfil do desenvolvedor do sistema são descritos na tabela a seguir:
3.5.1 Desenvolvedor
Representante Desenvolvedor do sistema.
Descrição Formação em Ciência da Computação ou sistema de Informação.
Tipo Formação Superior ou cursando
Responsabilidades Produção do Sistema.

SGPAT Versão: 1.0
AP - A
Critérios de Sucesso Produto de software, desenvolvimento de acordo com o processo.

Envolvimento Atuar como desenvolvedor.
Produtos Liberados
Comentários/Problemas
3.6 Perfis de Usuários

O perfil do usuário do sistema são descritos na tabela a seguir:
3.6.1 Usuário
Representante Colaboradores do SCAB.

Descrição Qualquer colaborador que manipule o sistema.
Tipo Técnico ou Analista Judiciário como formação média ou superior.
Responsabilidades Manter o sistema atualizado.
Critérios de Sucesso O sistema atende aos requisitos funcionais.
Envolvimento O usuário utilizará o sistema.
Produtos Liberados
Representante Colaboradores dos demais Setores.

Descrição Chefe do setor ou imediato.
Tipo Técnico ou Analista Judiciário como formação média ou superior.
Responsabilidades Realizar pedido de patrimônio
Critérios de Sucesso O sistema atende aos requisitos funcionais.
Envolvimento O usuário utilizará o sistema.
Produtos Liberados
3.7 Principais Necessidades dos Usuários ou dos Envolvidos

A seguir, um relato das necessidades dos colaboradores do SCAB que são os principais envolvidos no sistema:
1. Criar formulário (tela) com nome “Prancheta”, para a entrada de dados, com os seguintes campos: Tombo,
Descrição, Localização, Data, Status e Observação, com vinculação ao banco de dados do SUN. Com exceção do
campo Descrição, que será somente de leitura, isto é, não permitirá a digitação da descrição do Bem Patrimonial,
pois, ao ser digitado o tombo no campo “Tombo”, automaticamente será mostrada a descrição no campo
“Descrição”.
Finalidade: Registrar todos os materiais que entram e saem no SCAB, e são anotados diariamente na prancheta.

SGPAT Versão: 1.0
AP - A
Nota: Colocar um componente Listbox com todas as unidades para preenchimento do campo Localização.
2. Criar formulário (tela) de consulta pelos campos Tombo, Descrição, Localização, Data e Conserto, em razão do
exposto no item “1”
3. Criar o campo Solicitante e colocar o rótulo no campo Status, da tela de consulta (paconcd), para que mostre, no
primeiro, o motivo da transferência do Bem Patrimonial (tela pamovlot). e, no segundo, o status do Termo de
Responsabilidade.
Nota: O campo Status (sem rótulo) apresenta erro, pois, mesmo nos casos de movimentações sem Termo, é exibido
o status.
4. Mudar a forma de entrada dos tombos, para o Relatório por Tombos Específicos de Material em Uso. Fazer
idêntica a tela Pamovlot.
5. Fazer as seguintes alterações nas minutas (tela ca_minutas):
a) Mudar a forma de entrada dos tombos, como no item 3 acima.

b) Ampliar espaço de impressão para o campo tombamentos da minuta (tela Ca_minutas).
c) Criar Consultas/Relatórios por Tombo, por Minuta e por Unidade.
6. Padronizar nomenclatura dos Serviços de Distribuição para Consulta/Relatório. Ora temos que digitar Sedis, ora
Dist. Fazer uma varredura nas demais situações do sistema, para ver se existem outros casos a corrigir.
7. Excluir todas as mensagens desnecessárias emitidas pelo SUN, em diversas operações e situações. Por outro
lado, criar mensagem ao usuário, nos casos de exclusão de um Bem Patrimonial de uma terminada Movimentação
ou Termo, perguntando se realmente ele quer excluir. Atualmente, exclui sem salvar e sem emitir mensagem.
Nota: Dentre as mensagens que precisam ser excluídas, uma se sobressai: quando um Bem Patrimonial, do estoque,
é movimentado e excluído dentro do mesmo mês, o sistema emite uma mensagem, de que esta operação não pode
ser efetuada. “Material não pode movimentar para essa Unidade”. Todavia, essa mensagem só deveria aparecer nos
casos de movimentações fora do mês atual.
8. Colocar botões na barra de ferramentas, para abrirem as seguintes telas: Paconcd, Pamovlot, Paacomptermo,
Ca_minutas, Pacadast, Papedidos, Patermos, Pasepbai, Pabaixa.
9. Fazer constar no Histórico do Bem Patrimonial, o “Material p/ Baixa do Patrimônio” e “Material Baixado do
Patrimônio”. Atualmente, o sistema não considera, para efeito de registro no Histórico, estas duas Unidades.
10. Ativar barra de rolagem da guia SCAB, na Gerência de Pedidos. Motivo: acima de três materiais, no mesmo
pedido, o quarto fica fora da área da tela. Se o usuário acessar a todos os materiais do pedido, não consegue mais
voltar à guia de serviços acima.
11. Efetuar a correção dos botões tipo “setas” na barra de ferramentas, pois estão invertidos. Se possível, só ativá-
los nas telas em que serão utilizados. Nos demais casos, deixá-los desativados.
12. Colocar somatórios em todos os Relatórios.
13. Verificar erro no sistema quanto à efetivação de baixas. Às vezes, alguns patrimônio patrimoniais, já baixados,
permanecem figurando como “Material p/ Baixa do Patrimônio”, quando, na verdade, deveriam constar como
“Material Baixado do Patrimônio”.
Exemplos: Os tombos 35906 e 12835 já foram baixados no processo 042/2006, e suas baixas foram efetivadas em

SGPAT Versão: 1.0
AP - A
12/2/2007, porém, ainda permanecem na unidade denominada “Material p/ Baixa do Patrimônio”.
14. Corrigir o título da coluna “Pedida” (rótulo), por “Pedido”, na aba SCAB, Gerência de Pedidos.
15. Criar formulário (tela) destinado ao controle dos imóveis do Tribunal Regional do Trabalho da 12ª Região.
Nota: Requer ser discutido com área técnica, a fim de colher informações mais detalhadas.
16. Efetuar mudanças na forma de cadastro das descrições complementares do Patrimônio, Patrimoniais, tornando-a
mais sucinta no campo Descrição Completar, deixando as demais especificação para o campo Observações. Como
sugestão, propomos que seja extraído, do Banco de Dados, a tabela correspondente que contenha os dados referidos,
colocando-a no formato “xls”, para que possamos abrí-la no Excel e fazer as alterações necessárias, para só depois
devolvê-la ao Setor competente, que fará a atualização no Banco de dados.
17. Acrescentar caixa de texto na tela “paacomptermo”, para quando o usuário anular um termo, ele possa justificar
o motivo. Para tanto, ajustar esta tela (aumentar) para o mesmo tamanho da principal.
18. Permitir recurso de copiar e colar em todas as consultas e relatórios.
19. Criar uma coluna ao lado da do “Num Termo” na tela “Histórico do Patrimônio” - Paconcd, para fazer constar o
nº da movimentação.
20. Verificar a possibilidade de exclusão de um ou mais patrimônio de um Termo de Responsabilidade Provisório,

sem prejuízo da integridade do sistema. Às vezes, movimentamos uma lista de patrimônio patrimoniais para um
determinado setor, com emissão de Termo, e, antes que o responsável efetue o seu recebimento, alguns desses
patrimônio, por necessidade, já foram movimentados para outro setor, e isso implica que realizemos vários
procedimentos, para corrigir e atualizar os dados, resultando num verdadeiro malabarismo.
21. Relatório de Termo Provisórios: Fazer com que, após se efetuar uma consulta e fechar a tela Patermos – Pré
visualizado, possibilite retornar à tela Patermos – Form de parâmetros Run Time, pois, às vezes, queremos
consultar mais de um setor ou unidade, mas o sistema não permite.
22. Gerência de Pedidos, aba SCAB (tela Papedidos): às vezes, mesmo após efetuar o fornecimento do pedido, este
não vai para a aba Atendidos e permanece na aba SCAB. Corrigir a falha.
23. Totalização: Colocar duas caixas de edição na tela Paacomptermo (Acompanhamento de termo), semelhante a
tela Papedidos, de modo que mostre a quantidade total de termos e de materiais. Ou, então, criar uma tecla de
atalho, ou permitir, por meio da barra de rolagem, um modo mais fácil de se chegar ao último registro.
24. Corrigir mensagem “A tela (PACADAST) já está aberta!”, pois às vezes ela aparece do nada.
25. Tela paacomptermo (acompanhamento de termo): Fazer com que, ao abrir esta tela, o componente do rótulo
“Pendentes” venha ativado.
26. Tela paconcd (Consulta patrimonial) há um erro grave: quando um bem patrimonial é movimentado mais de
uma vez, no mesmo dia, o sistema ignora/retém algumas informações, deixando campos em branco. São eles:
Solicitante, Termo, Status, Movimento, Quem moveu, Setor anterior e Observação. Todavia, na tela “Histórico”
alguns destes dados são registrados, mas as datas aparecem desordenadas.
3.8 Alternativas e Concorrência

As alternativas que a SEINFO encontrou são: o desenvolvimento de uma solução própria ou contratar uma empresa
para desenvolver o software.

SGPAT Versão: 1.0
AP - A
4. Visão Geral do Produto

Esta seção mostra uma visão de alto nível sobre a capacidade do produto e configurações.
4.1 Suposições e Dependências

Nenhuma.
4.2 Custo e Preço

O sistema será desenvolvido nas dependências do TRT/SC como fruto de uma monografia, não envolve valores.
4.3 Licenciamento e Instalação

O sistema será desenvolvido, usando ferramentas livres e licenciadas pela instituição.
5. Recursos do Produto
Esta seção lista e descreve resumidamente os principais recursos do sistema:
5.1 Cadastro Consulta e Relatórios

O produto deve permitir o cadastro, alteração e consulta de patrimônio bem como outras relações emitindo
relatórios.
5.2 Segurança
O sistema deve autenticar um usuário antes de permitir a entrada no sistema, entretanto a segurança não.
6. Restrições
O sistema deve permitir somente usuários dos setores envolvidos diretamente e usuários responsáveis pelos demais
setores, esse tipo de restrição está fora do escopo do protótipo que será criado em decorrência da monografia.
7. Faixas de Qualidade
O código fonte deve ser desenvolvido, usando linguagem Java 6.0 ou superior que atenda as especificações de
desenvolvimento da SEINFO.
8. Precedência e Prioridade
1 – Cadastro de patrimônio – permitir o cadastramento, inserindo o número de tombamento e demais dados para
cada unidade adquirida.
9. Outros Requisitos do Produto

• oracle 10g como servidor de banco de dados;
• java 6 ou superior;
• tomcat Servidor web;
9.1 Requisitos do Sistema
Ver lista de requisitos.
9.2 Requisitos Ambientais

O servidor encontra-se em ambiente com controle de temperatura umidade e conta com dispositivo para falta de
energia.
Requisitos da Documentação
9.3 Manual do Usuário

Será elaborado um treinamento com os usuários não fazendo parte do escopo da monografia.

SGPAT Versão: 1.0
AP - A
9.4 Ajuda On-line

Futuramente, poderá ser disponibilizada ajuda on line na página da SEINFO ou SEDES ou até mesmo do SCAB.

91
APÊNDICE B – Glossário
INTEGRAÇÃO DSW ME
SGPAT
Glossário
Versão 1.0
SGPAT Versão: 1.0
Glossário Data: 18/11/2009
AP – B
22/04/2010 1.0 Atualização Soni

SGPAT Versão: 1.0
AP – B
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
1.2 Escopo 4
1.3 Visão Geral 4
2. Definições 4
2.1 Ant 4
2.2 Browser 4
2.3 CSS 4
2.4 DBA 4
2.5 DAO 4
2.6 DTD 5
2.7 Eclipse 5
2.8 HTTP 5
2.9 IDE 5
2.10 Java 5
2.11 JavaScript 5
2.12 JSP 5
2.13 Mozila 5
2.14 MVC 5
2.15 Oracle 5
2.16 Servlet 6
2.17 SGPAT 6
2.18 Tomcat 6
2.19 WAR 6
2.20 Website 6
2.21 WWW 6
2.22 XML 6

SGPAT Versão: 1.0
AP – B
Glossário
1. Introdução
Procura fornece uma visão geral de todo o documento, pretendendo apresentar, nesta seção, todas as
informações que poderão ser necessárias para que o leitor compreenda o documento. Este documento é
usado para definir a terminologia específica do domínio do problema, explicando termos, que poderão ser
desconhecidos para o leitor, das descrições de caso de uso ou de outros documentos do projeto.
Geralmente, este documento pode ser usado como um dicionário de dados informal, capturando definições
de dados para que as descrições de casos de uso e outros documentos do projeto possam estar focadas no
que o sistema deve fazer com as informações. Este documento deverá ser salvo em um arquivo denominado
Glossário.
1.1 Finalidade
Definir as terminologias do problema proposto, explicando os termos desconhecidos para os envolvidos no
sistema.
1.2 Escopo
Trata-se aqui dos termos usados no projeto.
1.3 Visão Geral

Descrição dos principais termos em ordem alfabética.
2. Definições
São descritos nas seções a seguir, os termos e suas finalidades.
2.1 Ant
É uma ferramenta utilizada para automatizar a construção de software. Ela é similar ao make, mas é escrita
na linguagem Java e foi desenvolvida inicialmente para ser utilizada em projetos desta linguagem. A mais
aparente diferença entre as ferramentas Ant e make é que a primeira utiliza um arquivo no formato XML
para descrever o processo de construção (build) e suas dependências, enquanto o make possui o seu próprio
formato de arquivo, o Makefile. Por padrão, este arquivo XML tem o nome build.xml.
2.2 Browser
É um programa de computador que habilita seus usuários a interagirem com documentos virtuais
da Internet, também conhecidos como páginas da web, que podem ser escritas em linguagens
como HTML, ASP, PHP.
2.3 CSS
Cascading Style Sheets ou folhas de estilos em cascata é uma ferramenta para construção do layout des
websites. Permite o projeto de websites com uma técnica completamente diferente da convencional e
possibilita uma considerável redução de tempo de trabalho.
2.4 DBA
É o administrador de banco de dados responsável por manter e gerenciar um banco de dados ou sistemas de
bancos de dados, profissional comumente chamado de DBA (do inglês DataBase Administrator).
2.5 DAO
Data Access Object – Objeto de acesso a dados é um modelo para persistência de dados em aplicações de
banco de dados.

SGPAT Versão: 1.0
AP – B
2.6 DTD
Definição de Tipo de Documento Contém as regras que definem quais as tags que podem ser
usadas em um documento XML e quais os valores válidos.
2.7 Eclipse
É uma IDE desenvolvida em Java, com código aberto para a construção de programas de computador. O
projeto Eclipse foi iniciado na IBM que desenvolveu a primeira versão do produto e doou-o como software
livre para a comunidade.
2.8 HTTP
Protocolo de Transferência de Hipertexto é um protocolo de comunicação (na camada de
aplicação segundo o Modelo OSI) utilizado para sistemas de informação de hipermedia
distribuídos e colaborativos.[1] Seu uso para a obtenção de recursos interligados levou ao
estabelecimento da World Wide Web.
2.9 IDE
Do inglês Integrated Development Environment ou Ambiente Integrado de Desenvolvimento, é um
programa de computador que reúne características e ferramentas de apoio ao desenvolvimento de software
com o objetivo de agilizar este processo.
2.10 Java
Foi originalmente chamada de D, mas a semelhança com uma nota ruim num boletim escolar, fez com que
o criador do Java, James Gosling, a renomeasse para Oak (carvalho), pela árvore que ele via através de sua
janela. A equipe de programação da Sun teve que procurar outro nome, pois já havia uma linguagem
chamada Oak. Java foi o nome selecionado de uma lista de sugestões, principalmente porque é uma gíria
para café, especialmente aquele que cresce na ilha de Java. Como os programadores bebiam muito café,
este pareceu ser um nome apropriado.
2.11 JavaScript
É uma linguagem de programação criada pela Netscape em 1995, que em princípio se chamava LiveScript,
a Netscape, após o sucesso inicial desta linguagem, recebe uma colaboração considerável da Sun, após esta
colaboração, podemos dizer que o JavaScript é uma linguagem compatível com a linguagem Java, por esta
razão, a semelhança dos nomes.
2.12 JSP
JavaServer Pages é uma tecnologia utilizada no desenvolvimento de aplicações para Web, similar às
tecnologias Active Server Pages (ASP) da Microsoft ou PHP. Por ser baseada na linguagem de
programação Java, tem a vantagem da portabilidade de plataforma, que permite a sua execução em diversos
sistemas operacionais, como o Windows da Microsoft, Unix e Linux. Esta tecnologia permite ao
desenvolvedor de páginas para Internet produzir aplicações que acessem o banco de dados, manipulem
arquivos no formato texto, capturem informações a partir de formulários e captem informações sobre o
visitante e sobre o servidor.
2.13 Mozila
Navegador e sucessor do Netscape Navigator.
2.14 MVC
Model view controller – modelo visão e controle é um padrão de arquitetura de software em camadas.
2.15 Oracle
É um Sistema de banco de dados relacional. - Larry Ellison, Ed Oates e Bob Miner trabalhavam em um
projeto de consultoria para a CIA (Central Intelligence Agency). O codinome para o projeto era Oracle (a

SGPAT Versão: 1.0
AP – B
CIA o via como um sistema que desse respostas a todas as perguntas ou algo do gênero). O projeto foi
desenhado de modo a recém-escrita linguagem de banco de dados SQL, da IBM. O projeto eventualmente
terminou, mas eles decidiram terminar o que haviam começado, e trazê-lo ao mundo. Eles mantiveram o
nome Oracle e criaram o motor RDBMS.
2.16 Servlet
É um componente do lado servidor que gera dados HTML e XML para a camada de apresentação de um
aplicativo Web. É basicamente uma classe na linguagem de programação Java que dinamicamente processa
requisições e respostas, proporcionando dessa maneira novos recursos aos servidores.
2.17 SGPAT
Sistema de Gerenciamento de Patrimônio.
2.18 Tomcat
É um servidor web Java, mais especificamente, um container de servlets. O Tomcat possui algumas
características próprias de um servidor de aplicação, porém não pode ser considerado um servidor de
aplicação por não preencher todos os requisitos necessários.
2.19 WAR
Web Application Archive formato de arquivo para o empacotamento do aplicativo desenvolvido para web.
2.20 Website
É um conjunto de páginas web, isto é, de hipertextos acessíveis geralmente pelo protocolo HTTP na
Internet. O conjunto de todos os sites públicos existentes compõe a World Wide Web.
2.21 WWW
World Wide Web em português significa, "rede de alcance mundial"; também conhecida como Web é um
sistema de documentos em hipermídia que são interligados e executados na Internet.
2.22 XML
Xtensible Markup Language é uma recomendação da W3C para gerar linguagens de marcação para
necessidades especiais. É um subtipo de SGML (acrônimo de Standard Generalized Markup Language, ou
Linguagem Padronizada de Marcação Genérica) capaz de descrever diversos tipos de dados. Seu propósito
principal é a facilidade de compartilhamento de informações pela Internet.

98
APÊNDICE C – Lista de Riscos

INTEGRAÇÃO DSW ME
SGPAT
Lista de Riscos
Versão 1.0
SGPAT Versão: 1.0
Lista de Riscos Data: 18/11/2009
AP - C
18/11/2009 1.0 Versão Inicial Soni

SGPAT Versão: 1.0
AP - C
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
1.2 Escopo 4
1.3 Definições, Acrônimos e Abreviações 4
1.4 Referências 4
1.5 Visão Geral 4
2. Riscos 4
2.1 Não obtenção do acesso ao sistema e à base de dados do sistema legado 4
2.1.1 Importância ou Ordenação do Risco 4
2.1.2 Descrição 4
2.1.3 Impactos 4
2.1.4 Indicadores 4
2.1.5 Estratégia de Diminuição 4
2.1.6 Plano de Contingência 4
2.1.7 Atualização 4

SGPAT Versão: 1.0
AP - C
Lista de Riscos
1. Introdução
1.1 Finalidade
O presente documento procura identificar os riscos, apontando a sua importância.
1.2 Escopo
A compreensão do projeto do SGPAT.
1.3 Definições, Acrônimos e Abreviações

Ver glossário.
1.4 Referências
Nenhuma.
1.5 Visão Geral
A seção seguinte descreve os riscos associados ao projeto.
2. Riscos
2.1 Não obtenção do acesso ao sistema e à base de dados do sistema legado
2.1.1 Importância ou Ordenação do Risco

Este risco inviabiliza o perfeito andamento do projeto, uma vez que o conhecimento do Modelo Entidade
Relacionamento é extremamente necessário bem como regras de negócio do sistema.
2.1.2 Descrição
O entendimento do Modelo Entidade Relacionamento existente é necessário para o conhecimento das
entidades, atributos e seus relacionamentos, tendo em vista que o sistema proposto deverá acessar a mesma
base de dados.
2.1.3 Impactos
Não funcionamento do sistema proposto com a base de dados, consumindo tempo desnecessário para
alteração do nome das entidades e relacionamentos.
2.1.4 Indicadores
É necessário a obtenção do Modelo Entidade e Relacionamento que deverá ser providenciado pelo DBA.
2.1.5 Estratégia de Diminuição

Solicitação do documento.
2.1.6 Plano de Contingência

Continuar o projeto sem o documento arcando com os prejuízos posteriores refletindo em atrasos de
entrega bem como custo no tempo de desenvolvimento.
2.1.7 Atualização
Os riscos foram sanados com o acesso a base de dados do sistema atual em que foi possível realizar a
engenharia reversa obtendo-se assim o modelo relacional.

103
APÊNDICE D – Plano de Desenvolvimento de Software

INTEGRAÇÃO DSW ME
SGPAT
Plano de Desenvolvimento de Software
Versão 1.0
SGPAT Versão: 1.0
Plano de Desenvolvimento de Software Data: 17/11/2009
AP - D
17/11/2009 1.0 Visão inicial Soni
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 6

SGPAT Versão: 1.0
AP - D
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
1.2 Escopo 4
1.4 Referências 4
2. Visão Geral do Projeto 4

2.1 Finalidade, Escopo e Objetivos do Projeto 4
2.2 Suposições e Restrições 5
2.3 Produtos Liberados do Projeto 5
2.4 Evolução do Plano de Desenvolvimento de Software 5
3. Organização do Projeto 5
3.1 Estrutura Organizacional 5
3.2 Interfaces Externas 5
3.3 Papéis e Responsabilidades 5
4. Processo de Gerenciamento 5
4.1 Estimativas do Projeto 5
4.2 Plano de Projeto 6
4.2.1 Plano de Fase 6
4.2.2 Releases 6
4.2.3 Recursos do Projeto 6
4.3 Planos de Iteração 6
4.4 Monitoramento e Controle do Projeto 6
4.4.1 Plano de Gerenciamento de Requisitos 6
4.5 Plano de Gerenciamento de Riscos 6

SGPAT Versão: 1.0
AP - D
Plano de Desenvolvimento de Software
1. Introdução
1.1 Finalidade
Descrever o Plano de Desenvolvimento de Software do SGPAT definindo os recursos necessários para o
andamento do projeto.
1.2 Escopo
O Plano de Desenvolvimento de Software, esta relacionado à criação do SGPAT por intermédio da
reengenharia do sistema existente em que esse fará o controle de patrimônio em ambiente WEB.

Ver documento Visão e Glossário.
1.4 Referências
São referenciados a seguir os artefatos produzidos durante o desenvolvimento do projeto.
• Glossário (APÊNDICE B);
• Lista de Riscos (APÊNDICE C);
• Plano de Iteração (APÊNDICE E);
• Especificação de Requisitos de Software (APÊNDICE F);
• Guia de Modelagem de Casos de Uso (APÊNDICE G);
• Especificação de Casos de Uso primários (APÊNDICE H);
• Especificação de Realização de Casos de Uso (APÊNDICE I);
• Documento de Arquitetura de Software (APÊNDICE J);
• Guia de Design (APÊNDICE K);
• Guia de Teste (APÊNDICE L);
• Plano de Implantação (APÊNDICE M).
2. Visão Geral do Projeto
2.1 Finalidade, Escopo e Objetivos do Projeto

O SGPAT será utilizado para o gerenciamento de patrimônio do TRT/SC, por intermédio da informatização
dos serviços de cadastramento e movimentação do patrimônio para os setores. O projeto pretende atender
algumas necessidades, principalmente do SCAB, que é o setor responsável por cadastrar e administrar o os
bens da instituição, por meio de um sistema WEB desenvolvido em comum acordo com os setores
envolvidos substituindo o sistema existente que é misto e que não é mais atualizado.

SGPAT Versão: 1.0
AP - D
2.2 Suposições e Restrições

Sendo o projeto fruto do desenvolvimento de uma monografia com prazo de entrega previsto para junho de
2010, destaca-se aqui que não há prazo para a conclusão do projeto, no entanto será entregue uma proposta
de solução do problema com um protótipo contemplando alguns módulos validados. O desenvolvimento do
projeto dependerá de acertos entre as partes envolvidas em que o autor se propõe a desenvolver o projeto
em colaboração com a SEINFO e o SEDES contando com apoio também do SEMAP, SELCO e SCAB, os
setores mais envolvidos, sem custos de desenvolvimento para a instituição.
2.3 Produtos Liberados do Projeto

Em cada fase do desenvolvimento do projeto serão liberados módulos de acordo com o andamento do
projeto.
2.4 Evolução do Plano de Desenvolvimento de Software

No termino de cada fase do projeto ou quando se julgar-se necessário, ocorreram às revisões no Plano de
Desenvolvimento do Software.
3. Organização do Projeto
3.1 Estrutura Organizacional

O projeto conta com somente um desenvolvedor o qual fará o papel de:
• analista;
• gerente de projetos;
• desenvolvedor.
O projeto conta com auxilio de um gerente de projetos funcionário da instituição.
3.2 Interfaces Externas

Não se aplica ao projeto inicial.
3.3 Papéis e Responsabilidades
Componente da equipe Função
Gerente do projeto;
Responsável pelo levantamento e gerenciamento de riscos;
Analista do projeto;
Soni João da Silva Responsável pela elaboração e revisão da documentação;
Responsável pela modelagem;
Responsável pela execução dos testes dos requisitos;
Responsável pela codificação;
Responsável pelos testes dos códigos desenvolvidos.
4. Processo de Gerenciamento
4.1 Estimativas do Projeto

A previsão de entrega do protótipo será em julho de 2010.

SGPAT Versão: 1.0
AP - D
4.2 Plano de Projeto
4.2.1 Plano de Fase

São alocados para a realização do projeto cinco horas diárias.
4.2.2 Releases
Versão 1.0 versão inicial com as funções de inserção de um novo patrimônio.
4.2.3 Recursos do Projeto

A seguir estão descritos os recursos disponibilizado para o projeto.
Recursos de Hardware:
1. computador pessoal – notbook com processador Intel core duo 1.6, 2 gb de ram e 100 g de hd;
2. computador do TRT/SC – desktop com processador Intel core duo 2.3, 3 gb de ram e 160 g de hd.
Recursos de Software:
1. MS Word xp – utilizado no desenvolvimento dos artefatos e na monografia;
2. EA – Enterprise Architect – utilizado na modelagem do projeto;
3. Oracle XE – SGBD utilizado para realizar os testes do protótipo;
4. IBM RUP – utilizado para o modelo de processo de desenvolvimento;
5. Servidor Apache TomCat 6.0.14 – utilizado como WEB container;
6. Apache ANT 1.7.0 – utilizado como deploy do projeto;
7. Eclipse Galileu – utilizado para geração de códigos Java;
8. IDE Macromedia Dreamweaver - utilizada para a geração dos arquivos JSP.
4.3 Planos de Iteração

A seguir são referenciados os planos de iteração;
Plano de Iteração encontra-se no (APÊNDICE E).
4.4 Monitoramento e Controle do Projeto
4.4.1 Plano de Gerenciamento de Requisitos

Especificação de Requisitos de Software (APÊNDICE F);
4.5 Plano de Gerenciamento de Riscos

Lista de Riscos (APÊNDICE C);

110
APÊNDICE E – Plano de Iteração

INTEGRAÇÃO DSW ME
SGPAT
Plano de Iteração
Versão 1.0
SGPAT Versão: 1.0
Plano de Iteração Data: 20/11/2009
AP – E

SGPAT Versão: 1.0
AP – E
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
1.2 Escopo 4
1.4 Referências 4
1.5 Visão Geral 4
2. Plano 4
3. Recursos 4
4. Casos de Uso 4
5. Critérios de Avaliação 5

SGPAT Versão: 1.0
AP – E
Plano de Iteração
1. Introdução
1.1 Finalidade
Este documento descreve um plano para iteração do projeto SGPAT, de forma detalhada tendo como
objetivos uma analise dos requisitos para o protótipo do sistema em questão.
1.2 Escopo
O presente plano aplica-se ao projeto do SGPAT na fase de iniciação com foco principalmente na
disciplina de gerenciamento de projetos.

Ver glossário.
1.4 Referências
1 – Visão.
1.5 Visão Geral
2. Plano
Não foi necessário estabelecer um cronograma para as atividades.
As iterações ocorrem à medida que as disciplinas são percorridas em cada fase obtendo-se um melhor
entendimento dos requisitos, construindo-se assim uma arquitetura robusta. A figura 1 a seguir demonstra
este processo.
Figura 1 – Processo iterativo.

3. Recursos
O projeto conta somente com um membro como integrante da equipe de desenvolvimento.
4. Casos de Uso
Os casos de uso estão definidos nos apêndices.

SGPAT Versão: 1.0
AP – E
5. Critérios de Avaliação
Uma primeira iteração tem como meta, a definição de um projeto piloto do sistema proposto, com
detalhamentos necessários, permitindo que o cliente tenha uma visão do projeto.

116
APÊNDICE F – Especificação de Requisitos de Software

INTEGRAÇÃO DSW ME
SGPAT
Especificação dos Requisitos de Software
Versão 1.0
SGPAT Versão 1.0
Especificação dos Requisitos de Software Data: 23/04/2010
AP – F

SGPAT Versão 1.0
AP – F
Índice Analítico
1. Introdução 4
2. Descrição Geral 4
3. Requisitos Específicos 4
3.1 Funcionalidade 4
3.2 Requisitos Não Funcionais 7
3.3 Regras de Negócios 8

SGPAT Versão 1.0
AP – F
Especificação dos Requisitos de Software

1. Introdução
A especificação de requisitos de Software é o documento para descrição e detalhamento dos requisitos.
Os requisitos foram gerado a partir da ferramenta EA.

Ver Glossário (APÊNDICE B)
2. Descrição Geral
Os requisitos vem esclarecer as principais atividades do sistema proposto. Em um primeiro momento
pretende atender as necessidades básicas dos Setores atingidos.
3. Requisitos Específicos
Contém todos os requisitos de software em um nível de detalhamento suficiente para possibilitar que os
designers projetem um sistema que satisfaça esses requisitos e que os testadores verifiquem se o sistema
satisfaz esses requisitos. Os requisitos estão divididos em requisitos funcionais e não funcionais
3.1 Funcionalidade
Os requisitos funcionais foram capturados por intermédio da ferramenta EA, estão descritos a seguir:
RF01 – Inclusão de fornecedor
«Functional» Satus: Proposed Priority: Medium Difficulty: Medium
Phase: 1.0 Version: 1.0
O sistema deve prover funcionalidades que permitam ao usuário cadastrar dados de um
fornecedor.
RF02 – Alteração de fornecedor

O sistema deve prover funcionalidades que permitam ao usuário alterar dados de um
fornecedor.
RF03 – Consultar fornecedor

Observação: O sistema deve prover funcionalidades que permitam ao usuário consultar
fornecedores por meio de filtro.
RF04 – Inclusão da nota de empenho do material

O sistema deve prover funcionalidades que permitam ao usuário inclusão da nota de
empenho do material.
RF05 – Alteração da nota de empenho do material

O sistema deve prover funcionalidades que permitam ao usuário alteração da nota de

SGPAT Versão 1.0
AP – F
RF06 – Consultar nota de empenho do material

O sistema deve prover funcionalidades que permitam ao usuário listar a nota de
RF07 - Inclusão de item do material

O sistema deve prover funcionalidades que permitam ao usuário cadastrar itens de
material adiquirido de um fornecedor.
RF08 - Alteração de itens do material

O sistema deve prover funcionalidades que permitam ao usuário alterar itens do
material adiquirido de um fornecedor.
RF09 – Consultar itens do material

fornecedores por meio de filtro.
RF10 - Inclusão da descrição complementar do item do material

O sistema deve prover funcionalidades que permitam ao usuário cadastrar a descrição
complementar do iten do material adiquirido de um fornecedor.
RF11 - Alteração da descrição complementar do item do material

O sistema deve prover funcionalidades que permitam ao usuário alterar a descrição
complementar do iten do material adiquirido de um fornecedor.
RF12 – Consultar descrição complementar do item do material

descrições complementares dos itens dos materiais por meio de filtro.
RF13 – Inclusão de grupo

Observação: O sistema deve prover funcionalidades que permitam ao usuário cadastrar
um novo grupo de bens.

SGPAT Versão 1.0
AP – F
RF14 – Alteração de grupo

Observação: O sistema deve prover funcionalidades que permitam ao usuário alterar
um grupo.
RF15 – Consultar grupo

grupos por meio de filtro.
RF16 – Inclusão de SIAFI

uma nova classificação de bem segundo o SIAFI.
RF17 – Alteração de SIAFI

uma classificação de bem segundo o SIAFI.
RF18 – Consultar SIAFI

valores da tabela SIAFI por meio de filtro.
RF19 – Inclusão de patrimônio

«Functional» Satus: Approved Priority: Medium Difficulty: Medium
um novo patrimônio.
RF20 – Alteração de patrimônio

um patrimônio.
RF21 - Consultar patrimônio no setor

O sistema deve prover funcionalidades que permitam aos funcionário do setor listar os
bens disponíveis no setor.

SGPAT Versão 1.0
AP – F
RF22 – Consultar patrimônio

um patrimônio por meio de filtro.
RF23 – Criar termo de responsabilidade provisório

Observação: O sistema deve prover funcionalidades que permitam ao usuário criar o
termo de responsabilidade provisório para o setor requisitante, quando destinar um
patrimônio.
3.2 Requisitos Não Funcionais

Os requisitos funcionais estão divididos em:
1. Requisitos de Produtos
RNF01 – Tempo de resposta

Observação: O sistema deverá apresentar um tempos de resposta inferior a 10 segundo
para noventa por cento das consultas.
RNF02 – Quantidade de usuários conectados

Observação: O sistema deverá suportar um número de 50 usuários simultáneos com
perda de desenpenho de no máximo 5% em qualquer operação.
RNF03 – Sistema multiplataformas

Observação: O sistema poderá ser acessado de qualquer plataforma por meio de um
navegador como MS Internet Explorer, Mozilla Firefox entre outros.
RNF04 – Sistema de persistência de dados

Observação: O sistema deverá estar acoplado a um SGBD Oracle 9g ou superior.
RNF05 – Tipo de conexão com o SGBD

Observação: A conexão do sistema como o SGBD deverá dar-se por meio de um pool
de conexão.
RNF06 – Acesso com Navegadores


SGPAT Versão 1.0
AP – F
Observação: O sistema poderá ser acessado por intermédio dos navegadores Internet
Explorer e Firefox.
RNF07 – Feedback Para Reportar Bugs

Observação: A constatação de bugs deverá ser informada por e-mail, em que estes
deverão ser verificados constantemente para a solução do problema de uma forma mais
rápida.
RNF08 – Treinamento dos Colaboradores

Observação: Um treinamento com os colaboradores deverá ser realizado para um
melhor entendimento das funções do sistema.
2. Requisitos Organizacionais
RNF01 – Resolução da tela

Observação: O sistema fica melhor se visualizado em uma resolução 1024 x 768.
RNF02 – Formato dos relatórios

Observação: Os relatórios serão exibidos em formato PDF ou RTF.
RNF03 – Manutenabilidade
Observação: O sistema será produzido em camadas facilitando possíveis atualizações
de versão.
3. Requisitos Externos
RNF01 - Dados do usuário

Observação: Os dados de cadastro do usuário bem como a senha não podem ser
expostos.
3.3 Regras de Negócios
RN01 - Cadastro do Fornecedor


SGPAT Versão 1.0
AP – F
Descrição: No momento do cadastro, o fornecedor deverá informar um nome e telefone

para contato bem como outros dados.
RN02 - Dados complementares do material

Descrição: Será cadastrado os dados complementares para os itens do material para o
posterior cadastro dos números de tombamentos destes itens.
RN03 - Criação de tombamentos

Descrição: Após o patrimônio ser devidamente tombado, esta operação não poderá ser
desfeita.
RN04 - Administração de fornecedores

Descrição: A manutenibilidade de fornecedores será atribuição do SELCO.
RN05 - Administração de material

Descrição: A manutenibilidade do material será atribuição do ALMOXARIFADO.
Esta atribuição compreende a manutenção da nota de empenho e itens de material.
RN06 - Administração do patrimônio

Descrição: A manutenibilidade do patrimônio será atribuição do SCAB.
Esta atribuição compreende a manutenção da descrição complementar do material bem
como de patrimônio alem de grupo de material e Siafi.

126
APÊNDICE G – Guia de Modelagem de Casos de Uso

INTEGRAÇÃO DSW ME
SGPAT
Guia de Modelagem de Casos de Uso
Versão 1.0
SGPAT Versão: 1.0
Guia de Modelagem de Casos de Uso Data: 22/11/2009
AP - G

SGPAT Versão: 1.0
AP - G
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
2. Como Descrever um Caso de Uso 4

SGPAT Versão: 1.0
AP - G
Guia de Modelagem de Casos de Uso

1. Introdução
Oferecer uma visão geral de todo o documento.
1.1 Finalidade
Proporcionar um guia para os modelos de caso de uso.
2. Como Descrever um Caso de Uso

Os diagramas de caso de uso têm fundamental importância na visualização, especificação e documentação
do comportamento de um elemento. (BOOCH, 2000).
Mediante um caso de uso são realizadas ações no sistema que tem como retorno valores para o ator que
realizou a ação. A seguir uma descrição dos principais elementos de um caso de uso:
• Ator – representa um conjunto de papéis representado pelo usuário;
• Nome do caso de uso – representa o caso de uso, deve ser único dentro de um pacote;
• Conexão – representa a ligação do ator com o caso de uso;
A figura 1 a seguir faz uma representação básica de um caso de uso.
Figura 1 – Representação básica de um caso de uso.

Fonte: O Autor.

131
APÊNDICE H – Especificação de Casos de Uso primários
H1 – CSU01 – Manter Grupo

INTEGRAÇÃO DSW ME
SGPAT
Especificação do caso de uso: CSU01 - Manter Grupo
Versão 1.0
SGPAT Versão: 1.0
CSU01 - Manter Grupo Data: 26/11/2009
AP – H

SGPAT Versão: 1.0
AP – H
Índice Analítico
1. CSU01 - Manter Grupo 4
1.1 Breve Descrição 4
2. Fluxo de Eventos 4
2.1 Fluxo Básico 4
2.1.1 Consultar Grupo 4
2.2 Fluxos Alternativos 4
2.2.1 Incluir Grupo 4
2.2.2 Alterar Grupo 5
3. Pós-condições 6

SGPAT Versão: 1.0
AP – H
1. CSU01 - Manter Grupo
1.1 Breve Descrição

Este caso de uso descreve a manutenção das informações do grupo de patrimônio em que são apresentadas
as funções de consultar, incluir e alterar.
2. Fluxo de Eventos
2.1 Fluxo Básico
2.1.1 Consultar Grupo

Este fluxo ocorre quando o usuário necessita de um grupo de patrimônio, o fluxo é demonstrado pela
Figura 1, a seguir.
act Diagrama de Ativ idade CSU01 - Consultar Grupo
Inicio
Usuário informa descrição e

seleciona pesquisar
[Não]
Achou?
[Sim]
Sitema exibe uma lista
Fim
Figura 1 - Diagrama de Atividade CSU01 - Consultar Grupo.

Fonte: O Autor.
Nos casos que o fluxo básico não corresponda às expectativas, o usuário tem os fluxos alternativos, a
seguir.
2.2 Fluxos Alternativos
2.2.1 Incluir Grupo

A forma de inclusão de um novo grupo é exibida na Figura 2, a seguir.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idade CSU01 - Icluir Grupo
Inicio
Usuário informa
descrição e seleciona Usuário informa demais Sistema emite mensagem
pesquisar dados e confirma de inserção
[Não]
Fim
O grupo já contém esta túpla?
[Sim]
Mensagem o sistema j á
conta com este v alor.
Informe outra descrição.
Figura 2 - Diagrama de Atividade CSU01 - Incluir Grupo.

Fonte: O Autor.
2.2.2 Alterar Grupo
A alteração de um item do grupo de patrimônio é exibida na Figura 3, a seguir.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idade CSU01 - Alterar Grupo
Inicio
Usuário informa parte da

descrição e realiza Sistema lista Usuário seleciona um
pesquisa v alor da lista
[Não]
[Sim]
Usuário altera campos e Sistema retorna ao

Achou? salv a fromulário para alteração
Fim
Figura 3 - Diagrama de Atividade CSU01 - Alterar Grupo.

Fonte: O Autor.
3. Pós-condições
Grupo de patrimônio incluído, alterado e disponibilizado na base de dados.

138
H2 – CSU02 – Manter Siafi

INTEGRAÇÃO DSW ME
SGPAT
Especificação do caso de uso: CSU02 - Manter SIAFI
Versão 1.0
SGPAT Versão: 1.0
CSU02 – Manter Tabela SIAFI Data: 26/11/2009
AP – H

SGPAT Versão: 1.0
AP – H
Índice Analítico
1. CSU02 – Manter a Tabela SIFI 4
2.1 Fluxo Básico 4
2.1.1 Consultar SIAFI 4
2.2.1 Inserir SIAFI 4
2.2.2 Alterar SIAFI 5

SGPAT Versão: 1.0
AP – H
1. CSU02 – Manter a Tabela SIFI

Este caso de uso descreve a manutenção das informações da tabela SIAFI, com detalhamento das funções
de consultar, incluir e alterar.
2. Fluxo de Eventos
2.1 Fluxo Básico
2.1.1 Consultar SIAFI

Este caso de uso ocorre quando o usuário necessita de um valor da tabela SIAFI, o fluxo é demonstrado na
Figura 1, a seguir.
act Diagrama de ativ idade CSU02 - Consultar SIAFI
Início
Usuário informa parte da descrição e

seleciona pesquisar
Achou?
[Sim]
Sistema lista
Fim
Figura 1 - Diagrama de Atividade CSU02 – Consultar SIAFI.

Fonte: O Autor.
Nos casos que o fluxo básico não corresponda às expectativas, o usuário tem os fluxos alternativos
a seguir.
2.2.1 Inserir SIAFI

O diagrama de atividade representado por meio da Figura 2, a seguir, em que exibe o fluxo de dados para
inserção de um novo valor na tabela SIAFI.

SGPAT Versão: 1.0
AP – H
Figura 2 - Diagrama de atividade CSU02 - Inserir SIAFI

Fonte: O Autor.
2.2.2 Alterar SIAFI

A Figura 3, a seguir, demonstra a forma de alteração de um valor na tabela SIAFI.

SGPAT Versão: 1.0
AP – H
Figura 3 - Diagrama de atividade CSU02 - Alterar SIAFI.

Fonte: O Autor.
3. Pós-condições
Siafi incluído, alterado e disponibilizado na base de dados.

145
H3 – CSU03 – Manter Patrimônio

INTEGRAÇÃO DSW ME
SGPAT
Especificação do caso de uso: CSU03 - Manter
Patrimônio
Versão 1.0
SGPAT Versão: 1.0
CSU03 – Manter Patrimônio Data: 26/11/2009
AP – H

SGPAT Versão: 1.0
AP – H
Índice Analítico
1. CSU03 – Manter Patrimônio 4
2.1 Fluxo Básico 4
2.1.1 Consultar Patrimônio 4
2.2.1 Incluir Patrimônio 4
2.2.2 Alterar Patrimônio 5
2.2.3 Criar Termo Provisório 6

SGPAT Versão: 1.0
AP – H
1. CSU03 – Manter Patrimônio

Este caso de uso descreve a manutenção das informações do patrimônio, em que são apresentadas as
funções de consulta, inserção, alteração e a criação de um termo de compromisso.
2. Fluxo de Eventos
2.1 Fluxo Básico
2.1.1 Consultar Patrimônio

Este fluxo de eventos está relacionado a manipulação do patrimônio adquiridos pelo TRT/SC. Os fluxos
alternativos demonstram as possíveis maneiras de manipular um patrimônio, este fluxo é demonstrado por
intermédio da Figura 1, a seguir.
act Diagrama de Ativ idade CSU03 – Consultar Patrimônio
Início
Usuário informa tombamento e Sistema exibe consulta

realiza pesquisa
Fim
Figura 1 - Diagrama de Atividade CSU01 - Consultar Patrimônio.

Fonte: O Autor.
Nos casos que o fluxo básico não corresponda às expectativas, o usuário tem os fluxos alternativos a seguir.
2.2.1 Incluir Patrimônio

Um novo patrimônio é cadastrado e devidamente tombado. A Figura 2, a seguir ilustra esta ocorrência.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idade CSU03 - Icluir Patrimônio
Início
Usuário informa o número Usuário informa parte da

da nota de empenho e descrição complementar,
pesquisa pesquisa e seleciona um v alor
encontrou?
[Não]
Usuário informa os demais

[Sim] dados e seleciona Cadastrar

descrição do grupo, pesquisa ,
seleciona um v alor
Sistema preenche com v alor

um

descrição do SIAFI,
pesquisa e seleciona um
v alor
Sistema emite mensagem

informando a quantidade de
itens cadastrados e o número
do último tombamento.
descrição do patrimônio e
realiza pesquisa, seleciona
um v alor
Fim
Figura 2 - Diagrama de Atividade CSU03 - Inserir Patrimônio.

Fonte: O Autor.
2.2.2 Alterar Patrimônio
O sistema permite que sejam alterados valores em um patrimônio cadastrado, exceto o número de
tombamento e o código do patrimônio. O modo de alteração de um patrimônio é visualizado por intermédio
da Figura 3, a seguir.

SGPAT Versão: 1.0
AP – H
Figura 3 - Diagrama de Atividade CSU03 - Alterar Patrimônio.

Fonte: O Autor.
2.2.3 Criar Termo Provisório
Ao disponibilizar um patrimônio para um setor, o SCAB imprime o termo de responsabilidade provisório,
esse documento exibe as informações atestando que o patrimônio se encontra em um setor. Esse documento
é representado pelo diagrama de atividade exibido na Figura 2, a seguir.

SGPAT Versão: 1.0
AP – H
Figura 2 - Diagrama de Atividade CSU03 - Criar Termo Provisório.

Fonte: O Autor.
3. Pós-condições
O patrimônio pode ser consultado, inserido, alterado e disponibilizado na base de dados, bem como o termo
provisório.

153
H4 – CSU04 – Manter a Descrição Complementar do Item do Material

INTEGRAÇÃO DSW ME
SGPAT
Especificação do caso de uso: CSU04 - Manter a
Descrição Complementar do Item do Material
Versão 1.0
SGPAT Versão: 1.0
CSU04 – Manter a Descrição Complementar do Item do Material Data: 26/11/2009
AP – H

SGPAT Versão: 1.0
AP – H
Índice Analítico
1. CSU04 – Manter a Descrição Complementar do Item do Material 4
2.1 Fluxo Básico 4
2.1.1 Consultar Descrição Complementar do Item do Material 4
2.2.1 Incluir Descrição Complementar do Item do Material 4
2.2.2 Alterar Descrição Complementar do Item do Material 5

SGPAT Versão: 1.0
AP – H
1. CSU04 – Manter a Descrição Complementar do Item do Material

Este caso de uso descreve a manutenção das informações da descrição complementar dos itens do material,
tais informações são necessárias para os colaboradores SCAB.
2. Fluxo de Eventos
2.1 Fluxo Básico
2.1.1 Consultar Descrição Complementar do Item do Material

Este caso de uso ocorre quando o usuário necessita pesquisar a descrição complementar dos itens de uma
determinada nota de empenho, este fluxo é demonstrado por intermédio da Figura 1, a seguir.
act Diagrama de Ativ idade CSU04 - Consultar Descrição Complementar do Item do Material
Usuário informa parte da Sistema lista os itens da

descricao e confirma descrição complementar
Inicio Fim
Figura 1 - Diagrama de Atividade CSU04 - Consultar Descrição Complementar do Item do Material.

Fonte: O Autor.
2.2.1 Incluir Descrição Complementar do Item do Material

A forma de inclusão da descrição complementar do item do material é exibida na Figura 2, a seguir.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idade CSU04 - Icluir Descrição Complementar do Item do Material
Inicio
Fim
Usuário pesquisa itens do

material, v erifica se o item
foi cadastrado
Sistma emite av iso de Sistema emite av iso de

erro OK
[Não]
Item cadastrado?
[Sim] [Não]
[Sim]
Tem erro?
Usuário pesquisa e lista a

descrição complementar do
item para v erificar se j á foi
cadastrada
[Não]
Descrição cadastrada? Usuário informa demasi

dados e confirma
[Sim]
Figura 2 - Diagrama de Atividade CSU04 - Incluir Descrição Complementar do Item do Material.

Fonte: O Autor.
2.2.2 Alterar Descrição Complementar do Item do Material
O sistema permite que sejam alterados valores da descrição complementar do item do material, sendo
vedado o campo chave primária composto por: número do item, ano da nota de empenho e número da nota
de empenho. A forma de alteração é visualizada por intermédio da Figura 2, a seguir.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idade CSU04 - Alterar Descrição Complementar do Item do Material
Inicio Fim
Usuário pesquisa e lista a

descrição complementar do
item para v erificar se j á foi
Sistema emite av iso de Sistma emite av iso de
cadastrada
OK erro
[Não]
[Sim]
Descrição cadastrada?
[Não]
Tem erro?
[Sim]
Alterar item do material? [Não]

Usuário informa dados a
alterar e confirma
[Sim]
Usuário pesquisa itens do

material caso quera alterar
Figura 2 - Diagrama de Atividade CSU03 - Alterar Patrimônio.

Fonte: O Autor.
3. Pós-condições
Descrição complementar do item do material incluída, alterada e disponibilizada na base de dados.

160
H5 – CSU05 – Manter Fornecedor

INTEGRAÇÃO DSW ME
SGPAT
Especificação do caso de uso: CSU05 - Manter
Fornecedor
Versão 1.0
SGPAT Versão: 1.0
CSU05 – Manter Fornecedor Data: 26/11/2009
AP – H

SGPAT Versão: 1.0
AP – H
Índice Analítico
1. CSU05 – Manter Fornecedor 4
2.1 Fluxo Básico 4
2.1.1 Consultar Fornecedor 4
2.2.1 Incluir Fornecedor 4
2.2.2 Alterar Fornecedor 5

SGPAT Versão: 1.0
AP – H
1. CSU05 – Manter Fornecedor

Este caso de uso descreve a manutenção das informações referente aos fornecedores do TRT/SC, em que
são apresentadas as funções de consulta, inserção e alteração de um fornecedor.
2. Fluxo de Eventos
2.1 Fluxo Básico
2.1.1 Consultar Fornecedor

Este fluxo ocorre quando o usuário necessita consultar um fornecedor de material, este fluxo é demonstrado
por intermédio da Figura 1, a seguir.
act Diagrama de Ativ idade CSU05 - Consultar Fornecedor
Início
Usuário informa parte da descrição do

fornecedor e seleciona pesquisar
[Não]
Fornecedor cadastrado?
[Sim]
Sistema lista os fornecedores
Fim
Figura 1 - Diagrama de Atividade CSU05 - Consultar Fornecedor.

Fonte: O Autor.
Os fluxos alternativos demonstram as possíveis maneiras de manipular um fornecedor.
2.2.1 Incluir Fornecedor

Um novo fornecedor é incluído no sistema, este fluxo de eventos é demonstrado na Figura 2, a seguir.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idade CSU05 - Incluir Fornecedor
Início
Usuário informa parte da descrição Usuário informa os demais

do fornecedor e seleciona pesquisar dados do fornecedor e salv a.
[Não] [Não]
Fornecedor cadastrado? Fim
[Sim]
Mensagem: Fornecedor cadastrado.

Informe outra descrição
Figura 2 - Diagrama de Atividade CSU05 - Inserir Fornecedor.

Fonte: O Autor.
2.2.2 Alterar Fornecedor
O sistema permite que sejam alterados valores em um fornecedor cadastrado exceto código do fornecedor.
A forma de alteração de um fornecedor é visualizada por intermédio da Figura 3, a seguir.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idade CSU05 - Alterar Fornecedor
Início
Usuário informa parte da descrição do Abre o formulário para alteração, o usuário informa
fornecedor e seleciona pesquisar os dados permitidos e clica em slv ar
[Não] Fornecedor cadastrado?
Fim
[Sim]
Sistema lista os fornecedores
Usuário seleciona um v alor e clica em

ok
Figura 3 - Diagrama de Atividade CSU05 - Alterar Fornecedor.

Fonte: O Autor.
3. Pós-condições
Fornecedor inserido, alterado e disponibilizado na base de dados.

167
H6 – CSU06 – Manter Nota de Empenho do Material

INTEGRAÇÃO DSW ME
SGPAT
Especificação do caso de uso: CSU06 - Manter Nota
de Empenho do Material
Versão 1.0
SGPAT Versão: 1.0
CSU03 – Manter Nota de Empenho do Material Data: 26/11/2009
AP – H

SGPAT Versão: 1.0
AP – H
Índice Analítico
1. CSU06 – Manter Nota de Empenho do Material 4
2.1 Fluxo Básico 4
2.1.1 Consultar Nota de Empenho do Material 4
2.2.1 Incluir Nota de Empenho do Material 4
2.2.2 Alterar Nota de Empenho do Material 5

SGPAT Versão: 1.0
AP – H
1. CSU06 – Manter Nota de Empenho do Material

Este caso de uso descreve a manutenção das informações referentes às notas de empenho da aquisição de
material, em que está demonstrado o detalhamento das funções de consultar, incluir e alterar.
2. Fluxo de Eventos
2.1 Fluxo Básico
2.1.1 Consultar Nota de Empenho do Material

Este fluxo ocorre quando o usuário necessita pesquisar uma nota de empenho de material, o fluxo é
demonstrado por intermédio da Figura 1, a seguir.
act Diagrama de Ativ idades CSU06 - Consultar Nota de Empenho do Material
Início
Usuário informa o número da

nota de empenho e clica em ok
Empenho cadastrado?
Sistema lista.
[Sim]
Fim
[Não]
Sistema emite
mesnsagem que a nota
não foi cadastrada e
retorna
Figura 1 - Diagrama de Atividade CSU06 - Consultar Nota de Empenho do Material

Fonte: O Autor.
2.2.1 Incluir Nota de Empenho do Material

A forma de inclusão de uma nota de empenho do material é exibida na Figura 2, a seguir.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idades CSU06 - Incluir Nota de Empenho do Material
Início
Usuário informa o número da

nota de empenho e clica em ok
Empenho cadastrado?
Sistema exibe mensagem que a nota
de empenho j á esta cadastrada
[Sim]
[Não]
Usuário informa demais dados e

confirma.
Sistema emite mensagem de

cadastro.
Fim
Figura 2 - Diagrama de Atividade CSU06 - Incluir Nota de Empenho do Material.

Fonte: O Autor.
2.2.2 Alterar Nota de Empenho do Material
O sistema permite que sejam alterados valores em referentes a uma nota de empenho de material já
cadastrada exceto o seu número. O modo de alteração de uma nota de empenho de material é visualizado
por intermédio da Figura 3, a seguir.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idades CSU06 - Alterar Nota de Empenho do Material
Início
Usuário informa o número da nota de

empenho e clica em ok
Empenho cadastrado?
Sistema lista a nota de empenho
[Sim] com campos editáv eis
[Não]
Usualrio altera os campos e

Sistema emite mesnsagem que a
salv a
nota não foi cadastrada e retorna
Fim
Figura 3 - Diagrama de Atividade CSU06 - Alterar Nota de Empenho do Material.

Fonte: O Autor.
3. Pós-condições
Nota de Empenho do Material inserida, alterada e disponibilizado na base de dados.

174
H7 – CSU07 – Manter Item do Material

INTEGRAÇÃO DSW ME
SGPAT
Especificação do caso de uso: CSU07 - Manter Item
do Material
Versão 1.0
SGPAT Versão: 1.0
CSU07 – Manter Item do Material Data: 26/11/2009
AP – H

SGPAT Versão: 1.0
AP – H
Índice Analítico
1. CSU07 - Manter Item do Material 4
2.1 Fluxo Básico 4
2.1.1 Consultar Item do Material 4
2.2.1 Incluir Item do Material 4
2.2.2 Alterar Item do Material 5

SGPAT Versão: 1.0
AP – H
1. CSU07 - Manter Item do Material

Este caso de uso descreve a manutenção das informações dos itens do material adquirido, em que são
apresentadas as funções de consulta, inserção e alteração.
2. Fluxo de Eventos
2.1 Fluxo Básico
2.1.1 Consultar Item do Material

Este fluxo ocorre quando o usuário necessita consultar itens do material, este fluxo é demonstrado por
intermédio da Figura 1, a seguir.
act Diagrama de Ativ idade CSU07 - Consultar Item do Material
Usuário informa número

da nota de empnho e sistema lista
confirma
Início
Fim
Figura 1 - Diagrama de Atividade CSU07 - Consultar Item do Material.

Fonte: O Autor.
2.2.1 Incluir Item do Material

A forma de inclusão de um novo item de material é exibida na Figura 2, a seguir.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idade CSU07 - Incluir Item do Material
Início
Usuárioinforma o número
da nota de empenho e
v erifica se o material foi
cadastrdo
Fim
[Não]
Material cadastrado?
Sistema emite av iso de sistema emite av iso de
OK erro
[Sim]
[Sim]
Tem erro

descrição e confirma
[Não]
Cadastrado?
Sistema av isa que o item Usuário informa dados e
j á esta cadastrado [Sim] [Não] confirma
Figura 2 - Diagrama de Atividade CSU07 - Incluir Item do Material.

Fonte: O Autor.
2.2.2 Alterar Item do Material
A alteração de um item do material é exibida na Figura 3, a seguir.

SGPAT Versão: 1.0
AP – H
act Diagrama de Ativ idade CSU07 - Alterar Item do Material
Início Fim
Sistema emite av iso de sistema emite av iso de

Usuárioinforma o número OK erro
da nota de empenho e
v erifica se o material foi
cadastrdo
Tem erro [Sim]
[Não]
Sistema abre o formulário

Usuário seleciona um com os campos
item e confirma preenchidos permitindo
edição dos permitidos
Material cadastrado?
Sistema lista
[Sim]
[Sim]
Cadastrado?
descrição e confirma
Fim
[Não]
Figura 3 - Diagrama de Atividade CSU07 - Alterar Item do Material.

Fonte: O Autor.
3. Pós-condições
Itens do material incluído, alterado e disponibilizado na base de dados.

181
H8 – CSU08 – Patrimônio Disponível no Setor

INTEGRAÇÃO DSW ME
SGPAT
Especificação do caso de uso: CSU08 - Patrimônio
Disponível no Setor
Versão 1.0
SGPAT Versão: 1.0
CSU08 – Patrimônio Disponível no Setor Data: 26/11/2009
AP – H

SGPAT Versão: 1.0
AP – H
Índice Analítico
1. CSU08 – Patrimônio Disponível no Setor 4
2.1 Fluxo Básico 4
2.1.1 Consultar Patrimônio Disponível no Setor 4

SGPAT Versão: 1.0
AP – H
1. CSU08 – Patrimônio Disponível no Setor

Este caso de uso descreve a forma de visualização do material permanente fornecido para o setor.
2. Fluxo de Eventos
2.1 Fluxo Básico
2.1.1 Consultar Patrimônio Disponível no Setor

Este fluxo ocorre quando o usuário necessita verificar se um determinado patrimônio encontra-se registrado
no setor. Este fluxo é demonstrado por intermédio da Figura 1, a seguir.
act Diagrama de Ativ idade CSU05 - Consultar Patromônio no Setor
Início
Usuário clica em exibir

patrimônio
Usuário informa login e

senha
Tem patrimônio so setor
[Não] [Não]
Sistema emite av iso: Não existe Sistema exibe uma lista de

material permanente no setor material do setor
Fim
Figura 1 - Diagrama de Atividade CSU05 - Consultar Patrimônio no Setor.

Fonte: O Autor.

SGPAT Versão: 1.0
AP – H
3. Pós-condições
Patrimônio verificado e disponibilizado na base de dados.

187
APÊNDICE I – Documento de Arquitetura de Software

INTEGRAÇÃO DSW ME
SGPAT
Documento de Arquitetura de Software
Versão 1.0
SGPAT Versão: 1.0
Documento de Arquitetura de Software Data: 28/04/2010
AP - I

SGPAT Versão: 1.0
AP - I
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
1.2 Definições, Acrônimos e Abreviações. 4
2. Metas e Restrições da Arquitetura 4
3. Visão de Casos de Uso 5

3.1 Realizações de Casos de Uso 6
4. Visão Lógica 8

SGPAT Versão: 1.0
AP - I
Documento de Arquitetura de Software

1. Introdução
O documento de arquitetura de software é um dos artefatos do RUP, que representa uma visualização do
processo de engenharia, utilizado no desenvolvimento do SGPAT.
1.1 Finalidade
Este documento oferece uma visão arquitetural abrangente, para representar diferentes aspectos do sistema.
Procura capturar e comunicar as decisões arquiteturais significativas que foram tomadas em relação ao
sistema.
1.2 Definições, Acrônimos e Abreviações.

Ver Glossário.
2. Metas e Restrições da Arquitetura

O desenvolvimento do sistema em um contexto geral, se da a partir de um sistema existente, em que, a base
de dados foi desenvolvida usando o sistema de gerenciamento de bando de dados Oracle 10g, a ferramenta
Oracle Forms para o desenvolvimento das telas, outra parte do sistema foi produzida em ASP. Após um
estudo nesta base (não houve tempo para o estudo do sistema), constataram-se alguns problemas, e
propõem-se como melhor solução, a migração dos dados para uma nova base, remodelada a partir da atual.
O sistema proposto esta sendo desenvolvido na linguagem de programação Java, utilizando Java scripts e
CSS. O desenvolvimento segue o modelo orientado a objetos, em camadas conforme padrão MVC (Model
View Controller), e o modelo DAO (Data Access Object), sendo este para a persistência de dados, ou seja,
a comunicação é realizada mediante o uso das classes DAO, em que, o sistema acessa a base de dados via
um pool de conexões. O padrão MVC é descrito a seguir.
• O Model (modelo) é responsável por encapsular e modelar os dados realizando a chamada de
métodos nas classes DAO, é o contato com a persistente de dados.
• O View (visão) é a visão propriamente dita, no presente trabalho desenvolvida em JSP, tem a
função de realizar a comunicação entre o cliente e a aplicação.
• Controller (controle) atua no servidor respondendo as requisições dos clientes, é a ponte de
ligação entre as camadas Model e View.
O sistema poderá ser instado independente de plataforma (multiplataforma), e será acessado por meio de
um navegador como Mozila firefox. A Figura 1, a seguir, representa a forma de acesso do cliente.

SGPAT Versão: 1.0
AP - I
Figura 1 – Visão de Distribuição do Sistema Proposto.

Fonte: O Autor.
3. Visão de Casos de Uso

Os gerentes de projeto e os envolvidos no sistema têm uma amostra dos casos de uso primários de maior
impacto arquitetural, chamados de casos de uso arquiteturalmente significativos. Esses casos de uso têm
importância, devido a representarem partes do projeto que podem contribuir para o fracasso da
implementação do sistema. Os atores e casos de uso primários são demonstrados na Figura 2, a seguir.
Figura 2 – Visão de Casos de Uso Primários.

Fonte: O Autor.
O detalhamento dos casos de uso primários é exibido na Figura 3, a seguir.

SGPAT Versão: 1.0
AP - I
Figura 3 – Detalhamento da Visão de Casos de Uso Primários.

Fonte: O Autor.
3.1 Realizações de Casos de Uso

Esta seção faz uma ilustração do funcionamento do SGPAT por meio de cenários dos pacotes e diagramas
dos casos de usos mais significativos, em que, separou-se os pacotes pelos setores que irão interagir com a
realização do caso de uso em questão. A Figura 4, a seguir, exibe uma representação destes pacotes.

SGPAT Versão: 1.0
AP - I
analysis Realização
Pacotes da Realização dos Casos de Uso
SCAB
SELCO
+ RCSU01 - Manter grupo
+ RCSU05 - Manter fornecedor
+ RCSU02 - Manter SIAFI
+ RCSU03 - Manter Patrimônio
+ RCSU04 - Manter a Descrição Complementar do Item do Material
ALMOXARIFADO OUTROS SETORES
+ RCSU06 - Manter Nota de Empenho do Material + RCSU08 - Patromônio Disponivel no Setor

+ RCSU07 - Manter Item do Material
Figura 4 – Pacotes da Realização de Casos de Uso.

Fonte: O Autor.
Os pacotes referentes ao Setor SCAB são demonstrados em detalhe na Figura 5, a seguir.
analysis SCAB
Realização - SCAB
RCSU01 - Manter grupo RCSU02 - Manter SIAFI

+ RCSU01 - Manter Grupo + RCSU02 - Manter SIAFI
RCSU03 - Manter Patrimônio RCSU04 - Manter a Descrição Complementar do Item do Material

+ RCSU03 - Manter Patimônio + CSU04 - Manter a Descrição Complementar do Material
Figura 5 – Detalhamento da Realização de Casos de Uso do Setor SCAB.

SGPAT Versão: 1.0
AP - I
Fonte: O Autor.
A realização do caso de uso RCSU03 é exibida por intermédio da Figura 6, a seguir.
sd RCSU03 - Manter Patrimônio
FrmIncPatrimonio CtrlIncPatrimonio
FrmMenu FrmFiltPatrimonio FrmListPatrimonio Patrimonio

Colaborador SCAB
FrmAltPatrimonio CtrlAlterarPatrimonio
Figura 6 – Diagrama de Comunicação do RCSU03 Manter Patrimônio.

Fonte: O Autor.
4. Visão Lógica
Esta seção representa a estrutura de relacionamento entre os elementos da aplicação, a seguir são
demonstrados os padrões e modelos em camadas:
1. Camada do modelo. A Figura 7, a seguir, representa esta camada.
Figura 7 – Camada do Modelo

Fonte: O Autor.
2. Camada visão. Essa camada esta representada por intermédio da Figura 8, a seguir.

SGPAT Versão: 1.0
AP - I
Figura 8 – Camada de Visão.

Fonte: O Autor.
3. Camada de Controle. A Figura 9, a seguir, representa esta camada.
Figura 9 – Camada de Controle.

Fonte: O Autor.
4. Camada DAO. A Figura 10, a seguir, exibe o DAO do projeto.

SGPAT Versão: 1.0
AP - I
Figura 10 – Camada DAO.

Fonte: O Autor.

198
APÊNDICE J – Guia de Design do Sistema Atual

INTEGRAÇÃO DSW ME
SGPAT
Guia de Design do Sistema Atual
Versão 1.0
SGPAT Versão: 1.0
Guia de Design do Sistema Atual Data: 08/12/2009
AP - J

SGPAT Versão: 1.0
AP - J
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
1.2 Escopo 4
2. Diretrizes de Design de Banco de Dados 4

2.1 Mapeamentos das Classes Persistentes 4
3. Diretrizes de Design de Arquitetura 6

3.1 Telas do Sistema Atual 6
3.1.1 Tela entrada de Material 6
3.1.2 Tela de Cadastro de Patrimônio 7
3.1.3 Tela de Movimentação de Patrimônio 8

SGPAT Versão: 1.0
AP - J
Guia de Design
1. Introdução
1.1 Finalidade
A finalidade deste documento é comunicar os padrões de design, convenções e estilos a serem usados no
design do sistema.
1.2 Escopo
Este documento serve como meio de comunicação entre o arquiteto de software e outros desenvolvedores

Ver Glossário e documento Visão.
2. Diretrizes de Design de Banco de Dados

No primeiro momento realizou-se a engenharia reversa da base de dados do sistema mediante o uso da
ferramenta EA, com acesso ao banco utilizando um driver ODBC . Os modelos gerados são descritos nas
seções a seguir:
2.1 Mapeamentos das Classes Persistentes
O banco de dados principal, GEPAT conta com noventa tabelas, em que considerou-se dois
relacionamentos principais, com as tabelas que tem alguma importância para o protótipo do Sistema
Proposto, desprezando-se as tabelas anônimas. Os relacionamentos são destacados a seguir:
• Mapeamento para a manipulação do patrimônio. A Figura 1, a seguir, representa este
mapeamento.
Figura 1 – Relacionamento Patrimônio.

SGPAT Versão: 1.0
AP - J
Fonte: O Autor.
• Mapeamento para a manipulação de fornecedores, não detectou-se uma ligação entre este
relacionamento e o anterior. A Figura 2, a seguir, representa este mapeamento.
Figura 2 – Relacionamento Fornecedor.

Fonte: O Autor.
• Mapeamento para a manipulação de materiais, este encontra-se no banco de dados SIGA.
A Figura 3, a seguir, representa este mapeamento.

SGPAT Versão: 1.0
AP - J
Figura 3 – Relacionamento Material.

Fonte: O Autor.
3. Diretrizes de Design de Arquitetura
3.1 Telas do Sistema Atual

A seguir uma panorâmica das principais telas do sistema atual com cadastro em andamento.
3.1.1 Tela entrada de Material
A entrada de material permanente no sistema é realizada por intermédio da tela Entrada de Material, em
que o colaborar, funcionário do Almoxarifado, entra no sistema por meio de login e senha, tendo seu nome
exibido no campo Nome do Operador. De posse dos documentos de entrada, realiza o cadastro do material,
conforme é demonstrado na Figura 4, a seguir.

SGPAT Versão: 1.0
AP - J
Figura 4 – Entrada de Material Permanente.

3.1.2 Tela de Cadastro de Patrimônio

A inclusão do número de tombamentos é realizada uma vez que o material tenha sido cadastrado pelo setor
de Almoxarifado. O colaborador SCAB após lagar-se no sistema, insere o número da nota de empenho do
material em que este documento é recebido do Setor de Almoxarifado, no campo Nr.Nota, realiza uma
pesquisa preenchendo assim os campos necessários referentes aquela nota, pesquisa um grupo e demais
dados, como a descrição e descrição complementar do material. Conforme a quantidade exposta no campo
Qtde é cadastrado um grupo de tombamentos em que o primeiro tombamento segue a partir de uma
sequência já cadastrada, a tela Cadastramento Genérico, é demonstrada na Figura 5, a seguir.

SGPAT Versão: 1.0
AP - J
Figura 5 – Relacionamento fornecedores.

3.1.3 Tela de Movimentação de Patrimônio

A movimentação de material permanente, após o material ser tombado por intermédio do sistema, ou o
material esteja tombado e disponível, é realizada mediante o acesso a tela movimentação em lotes,
seguindo assim os mesmos princípios das telas anteriores, conforme a demonstração na Figura 6, a seguir.
Figura 6 – Movimentação em Lote de Material Permanente.


207
APÊNDICE K – Guia de Design do Sistema Proposto

INTEGRAÇÃO DSW ME
SGPAT
Guia de Design do Sistema Proposto
Versão 1.0
SGPAT Versão: 1.0
Guia de Design do Sistema Proposto Data: 08/12/2009
AP – K

SGPAT Versão: 1.0
AP – K
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
1.2 Escopo 4
2. Diretrizes de Design de Banco de Dados 4

2.1 Mapeamentos das Classes Persistentes 4
2.2 Dicionário de dados das Classes Persistentes 5
3. Diretrizes de Design de Arquitetura 13

3.1 Telas do Sistema Proposto 13
3.1.1 Tela Inicial 13
3.1.2 Tela de Cadastro de Patrimônio 13
3.1.3 Tela de Consulta de Itens da Nota de Empenho 14
3.1.4 Tela de Confirmação de Inclusão do Patrimônio 14
3.1.5 Tela de Erro de Confirmação de Inclusão do Patrimônio 15

SGPAT Versão: 1.0
AP – K
Guia de Design
1. Introdução
1.1 Finalidade
A finalidade deste documento é comunicar os padrões de design, convenções e estilos a serem usados no
design do sistema.
1.2 Escopo
Este documento é um meio de comunicação entre o arquiteto de software e outros desenvolvedores.

Ver Glossário e documento Visão.
2. Diretrizes de Design de Banco de Dados

Após a realização da engenharia reversa da base de dados do sistema atual, o sistema foi mais bem
entendido criando-se um novo diagrama para o sistema proposto.
2.1 Mapeamentos das Classes Persistentes
O Protótipo do Sistema Proposto contará com uma base de dados relacional, em que as tabelas são
baseadas na base de dados do Sistema atual, com modificações e a migração dos dados. O mapeamento
é exibido na Figura 1, a seguir.
Figura 1 – Relacionamento do SGPAT.

SGPAT Versão: 1.0
AP – K
Fonte: O Autor.
2.2 Dicionário de dados das Classes Persistentes

O dicionário de dados esta representado na Tabela 1, a seguir.
AGENCIA_BANCO = *Número da agência em que o fornecedor

mantém a conta.
ANO_NE = *Ano da nota de empenho.**
{dígito numérico}
ANO_NE = *Ano do empenho.**
{dígito numérico}
CAT_ITENS_NE = *Conjunto de entidades que exibe
informações sobre cada itens da nota de
empenho.**
@ANO_NE + AUTOR +
CAT_NE_TIPO_COMPRA +
COD_GRUPO_MATERIAL +
COD_LOCALIZACAO_DESTINO +
COD_TIPO_MATERIAL + DAT_ENTREGA +
DAT_GARANTIA + DAT_SALDO + DETALHE
+ DTA_NOTA_FISCAL + EDITORA +
N_FORNECIMENTO + NUM_ITEM_NE +
NUM_MAPA + NUM_MATERIAL + NUM_NE +
NUM_NF + PRECO_UNITARIO + QTDE +
SALDO + SIT_RESIDUO + TIPO +
VALOR_RESIDUO + TOMBADO
CAT_ITENS_NE_FK01 = *permite a integridade dos campos
NUM_ITEM_NE, ANO_NE e NUM_NE na
tabela CAT_ITENS_NE, associado aos
campos NUM_ITEM_NE, ANO_NE e NUM_NE
na tabela CAT_NE assume um valor da chave
associada**
CAT_ITENS_NE_PK = *permite a integridade dos campos
tabela CAT_ITENS_NE, não permitindo valores
duplicados**
CAT_NE = *Conjunto de entidades que exibe
informações sobre cada material. **
@ANO_NE + COD_CREDITO +
COD_DEBITO + CODISERV_INCLUIU +
CONTRATO + DAT_ENTREGA +
DAT_INCLUSAO + ELEM_DESPESA +
LOGIN_REDE + NUM_MAPA + NUM_NE +
ORIGEM_DEV + RAZAO +
TF_COD_FORNEC + TIPO_COMPRA +
TIPO_EMPENHO
CAT_NE_FK01 = *permite a integridade do COD_FORNEC na
tabela CAT_NE, associado ao campo
COD_FORNEC na tabela FORNECEDOR
assume um valor da chave associada**
CAT_NE_PK = *permite a integridade dos campos
NUM_NE, ANO_NE e TIPO_COMPRA na
tabela CAT_NE, não permitindo valores
duplicados**

SGPAT Versão: 1.0
AP – K
CEP = *Código de Endereçamento Postal. **

{dígito caracter}
CNPJ = *Cadastro Nacional da Pessoa Jurídica. **
{dígito caracter}
COD_CLASSE_SIAFI = *Código da classe da conta SIAFI.**
{dígito numérico}
COD_ELEMENTO_SIAFI = *Código do elemento da conta SIAFI.**
{dígito numérico}
COD_EST_CONSERV = *Código do estado de conservação do
patrimônio.**
{dígito numérico}
COD_FORMA_AQUIS = *Código da forma de aquisição do
patrimônio.**
{dígito numérico}
COD_FORNEC = *Identifica o fornecedor.**
{dígito numérico}
COD_GRUPO = *Código do grupo do material. **
{dígito numérico}
COD_GRUPO = *Código do grupo de patrimônio.**
{dígito caracter}
COD_GRUPO_MATERIAL = *Código do grupo de permanente ou
consumo.**
{dígito numérico}
COD_GRUPO_SIAFI = *Código do grupo da conta SIAFI.**
{dígito numérico}
COD_ITEM_SIAFI = *Código do item da conta SIAFI.**
{dígito numérico}
COD_LOC_UN_ADM = *Código do local da unidade administrativa -
número sequencial.**
{dígito numérico}
COD_LOCALIZACAO_DESTINO = *Código do local em que foi fornecido o
material**
{dígito numérico}
COD_MOEDA = *Código da moeda.**
{dígito numérico}
COD_ORG_CESSION = *Código do órgão externo quando do
empréstimo do patrimônio.**
{dígito numérico}
COD_ORGAO_CEDENTE = *Código do proprietário do patrimônio que foi
cedido.**
{dígito numérico}
COD_PATRIMONIO = *Código do Patrimônio.**
{dígito numérico}
COD_PRAZO_GARANTIA = *Código do Prazo de Garantia**
{dígito numérico}
COD_PRODASEN = *Código chave do livro no sistema do
Prodasen.**
{dígito numérico}
COD_SERV_RESP = *Código do servidor responsável quando em
uso exclusivo.
COD_SIAFI_INT = *Código SIAFI. **
{dígito numérico}

SGPAT Versão: 1.0
AP – K
COD_SIAFI_INT = *Código SIAFI.**

{dígito numérico}
COD_SITUACAO = *Código da situação do patrimônio.**
{dígito numérico}
COD_SUBELEMENTO_SIAFI = *Código do sub elemento da conta SIAFI.**
{dígito numérico}
COD_SUBGRUPO_SIAFI = *Código do subgrupo da conta SIAFI.**
{dígito numérico}
COD_SUBITEM_SIAFI '= *Código do subitem da conta SIAFI.**
{dígito numérico}
COD_TIPO_MATERIAL
= *Código do tipo de material. **
{ dígito data }
COD_UN_ADM = *Código da unidade administrativa.**
{dígito numérico}
CONTA_BANCO = *Número da conta bancária. **
{dígito caracter}
CONTATO = *Pessoa responsável pela empresa. **
{dígito caracter}
CONTRATO = *Número do contrato caso já exista com o
TRT.**
{dígito numérico}
CPF = *Cadastro de Pessoa Física.**
{dígito caracter}
DAT_ENTREGA = *Data que o fornecedor entregou o material**
{ dígito data }
DAT_GARANTIA = *Data de garantia do material.**
{ dígito data }
DAT_SALDO = *Última atualização no saldo.**
{ dígito data }
DATA_ENTRADA = *Data de entrada do material.**
{ dígito data }
DES_COMPL = *Descrição complementar do material.**
{dígito caracter}
DES_COMPL_FORN_BAIXA = *Descrição complementar do patrimônio
quando foi baixado.
DES_GRUPO = *Descrição do grupo de patrimônio.**
{dígito caracter}
DES_SIAFI = *Descrição da conta SIAFI.**
{dígito caracter}
DESCRICAO = *Descrição do material do Setor de
Administração e Cadastro de Bens. **
{dígito caracter}
DTA_ALTERACAO_SIAFI = *Data de alteração do código SIAFI.**
{ dígito data }
DTA_AVALIACAO = *Data da avaliação.**
{ dígito data }
DTA_FIM_GARANTIA = *Data do fim da garantia.**
{ dígito data }
DTA_INVENTARIO = *Data do último inventário.**
{ dígito data }

SGPAT Versão: 1.0
AP – K
DTA_LOTE_SEPARACAO = *Data do lote de separação do material.**

{ dígito data }
DTA_NOTA_FISCAL = *Data da nota fiscal.**
{ dígito data }
DTA_TOMBAMENTO = *Data de tombamento do patrimônio.**
{ dígito data }
DTA_VALIDADE_AVALIACAO = *Data da validade da avaliação.**
{ dígito data }
FANTASIA
= *Descrição fantasia da empresa.**
{dígito caracter}
FAX1 = *Número do fax.**
{dígito numérico}
FAX2 = *Número do segundo fax.**
{dígito numérico}
FONE1 = *Telefone da empresa
{dígito numérico}
FORNECEDOR = *Conjunto de entidades que exibe
informações sobre cada fornecedor.**
@ AGENCIA_BANCO + BAIRRO + BL_PATRI
+ CADASTRO + CAIXA_POSTAL +
CD_BANCO + CELULAR + CEP + CNPJ +
COD_FORNEC + CODIGO + COD_RAMO +
COMPLEMENTO + CONTA_BANCO +
CONTATO + CONTATO_REPRESENTANTE +
CONTRATO + CPF + CP_SOCIAL+
DATA_ENTRADA + DATA_INTEGRALIZACAO
+ DATA_RENOVA +
DATA_ULT_ATUALIZACAO +
DAT_NASCIMENTO + DDD + E_MAIL +
E_MAIL1 + EXPEDIDOR + FANTASIA +
FAX_REPRESENTANTE + FAX1 + FAX2 +
FONE_REPRESENTANTE + FONE1 + FONE2
+ GRUPO + INCRICAO_INSS +
INSCRICAO_ESTADUAL +
INSCRICAO_MUNICIPAL +
MUNI_COD_MUNICIPIO +
NAT_COD_NATUREZA + NOME_CADASTRO
+ NUM_CADASTRO + NUM_CF + NUM_CRC
+ NUM_REGISTRO + OBS +
OPTANTE_SIMPLES + PIS_PASEP +
PRACA_BANCO + PUNICAO +
QUEM_ATUAL + QUEM_INSERIU + RAMAL1
+ RAMAL2 + RAZAO_SOCIAL + RG + RUA +
SICAF + SIMPLES_N + SITUACAO +
TIPO_EMPRESA + TIPO_FORNECEDOR +
TIPO_PESSOA + UF + WEB_SITE
INCRICAO_INSS = *Número de inscrição na previdência
Social.**
{dígito numérico}
IND_ATIVO = *Indica se código SIAFI esta ativo.**
{dígito caracter}

SGPAT Versão: 1.0
AP – K
IND_DOTACAO = *Indica se a conta é do tipo dotação.**

{dígito caracter}
IND_FINANCEIRO = *Indica se a conta é do tipo financeiro.**
{dígito caracter}
IND_ITEM_ORCAMENTO = *Indica se a conta é do tipo item do
orçamento.**
{dígito caracter}
IND_LIMITACAO = *Indica se o recebimento do orçamento é
limitado.**
{dígito caracter}
IND_NATUREZA = *número indicador da natureza da nota
fiscal.**
{dígito caracter}
IND_ORCAMENTO = *Indica se a conta é do tipo orçamento.**
{dígito caracter}
IND_OST = *Indica se a conta é do tipo outros serviços
de terceiros.**
{dígito caracter}
IND_PATRIMONIO = *Indica se a conta é do tipo patrimônio.**
{dígito caracter}
IND_PDM = *Indica se a descrição complementar já está
associado ao PDM (Padrão Descritivo de
Material).**
{dígito caracter}
LCT_DES_COMPL_FORN = *Conjunto de entidades que exibe
informações sobre cada detalhamento do
material no Setor de Cadastro e Administração
de Bens**
@ANO_NE + COD_GRUPO +
COD_SIAFI_INT + DES_COMPL +
DESCRICAO + IND_PDM + MARCA +
MODELO + NUM_ITEM_NE + NUM_NE +
PESO + VALOR
LCT_DES_COMPL_FORN_FK01 = *permite a integridade dos campos
tabela LCT_DES_COMPL_FORN, associado
aos campos NUM_ITEM_NE, ANO_NE e
NUM_NE na tabela CAT_ITENS_NE assume
um valor da chave associada**
LCT_DES_COMPL_FORN_FK02 = *permite a integridade do campo
COD_GRUPO na tabela
LCT_DES_COMPL_FORN, associado ao
campo COD_GRUPO na tabela PAT_GRUPO
LCT_DES_COMPL_FORN_FK03 = *permite a integridade do campo
COD_SIAFI_INT na tabela
LCT_DES_COMPL_FORN, associado ao
campo COD_SIAFI_INT na tabela LCT_SIAFI
LCT_DES_COMPL_FORN_PK = *permite a integridade dos campos
tabela LCT_DES_COMPL_FORN, não
permitindo valores duplicados**

SGPAT Versão: 1.0
AP – K
LCT_SIAFI = *Conjunto de entidades que exibe

informações sobre cada classificação do
Sistema Financeiro do Governo Federal**
@COD_CLASSE_SIAFI +
COD_ELEMENTO_SIAFI +
COD_GRUPO_SIAFI + COD_ITEM_SIAFI +
COD_SIAFI_INT +
COD_SUBELEMENTO_SIAFI +
COD_SUBGRUPO_SIAFI +
COD_SUBITEM_SIAFI + DES_SIAFI +
IND_ATIVO + IND_DOTACAO +
IND_FINANCEIRO +
IND_ITEM_ORCAMENTO + IND_LIMITACAO
+ IND_ORCAMENTO + IND_OST +
IND_PATRIMONIO
LCT_SIAFI_PK = *permite a integridade do campo COD_SIAFI
na tabela LCT_SIAFI, não permitindo valores
duplicados**
LOCAL_FISICO = *Local que se encontra o patrimônio.**
{dígito caracter}
MARCA = *Marca do equipamento.**
{dígito caracter}
MODELO = *Modelo do equipamento.**
{dígito caracter}
NOME_CADASTRO = *Nome de cadastro da empresa.**
{dígito caracter}
NUM_ITEM_NE = *Número do item da nota de empenho. **
{dígito numérico}
NUM_ITEM_NE = *Número do item.**
{dígito numérico}
NUM_LOTE_SEPARACAO = *Número do lote de separação.**
{dígito numérico}
NUM_NE = *Ano da nota de empenho. **
{dígito numérico}
NUM_NE = *Número do empenho.**
{dígito numérico}
NUM_PRAZO_GARANTIA = *Número quantificado de
COD_PRAZO_GARANTIA**
{dígito numérico}
NUM_REGISTRO = *Número de registro estadual da empresa.**
{dígito numérico}
NUM_SERIE = *Número de série do fabricante.**
{dígito caracter}
NUM_TOMBAMENTO = *Número de tombamento do patrimônio.**
{dígito numérico}
OBS = *Observações gerais.**
{dígito caracter}
OPTANTE_SIMPLES = *Identifica S ou N para sim ou não caso seja
opinante ou não do imposto SIMPLES **
{dígito caracter}

SGPAT Versão: 1.0
AP – K
PAT_GRUPO = *Conjunto de entidades que exibe

informações sobre cada grupo de patrimônio**
@COD_GRUPO + DES_GRUPO
PAT_GRUPO_PATR_PK = *permite a integridade do campo
COD_GRUPO na tabela LCT_GRUPO, não
PAT_PATRIMONIO = Conjunto de entidades que exibe
informações sobre cada tombamento do
patrimônio**
@ANO_NE + COD_EST_CONSERV +
COD_FORMA_AQUIS + COD_LOC_UN_ADM
+ COD_MOEDA + COD_ORGAO_CEDENTE +
COD_ORG_CESSION + COD_PATRIMONIO
+ COD_PRAZO_GARANTIA +
COD_PRODASEN + COD_SERV_RESP +
COD_SITUACAO + COD_UN_ADM +
DES_COMPL_FORN_BAIXA +
DTA_ALTERACAO_SIAFI + DTA_ATUAL +
DTA_AVALIACAO + DTA_ENTRADA +
DTA_FIM_GARANTIA + DTA_INVENTARIO +
DTA_LOTE_SEPARACAO +
DTA_TOMBAMENTO +
DTA_VALIDADE_AVALIACAO +
EMPRESTADA + HISTORICO +
IND_NATUREZA + LOCAL_FISICO + NEORIG
+ NUM_ITEM_NE +
NUM_LOTE_SEPARACAO + UM_NE +
NUM_PRAZO_GARANTIA + NUM_SERIE +
NUM_TOMBAMENTO + OBS + PESO +
QUEM_ATUAL + QUEM_BAI + QUEM_SEP +
SETOR_ANT + VAL_AQUIS +
VAL_AVALIACAO + VAL_DOLAR
PAT_PATRIMONIO_FK01 = *permite a integridade dos campos
tabela PAT_PATRIMONIO, associado aos
campos NUM_ITEM_NE, ANO_NE e NUM_NE
na tabela LCT_DES_COMPL_FORN assume
um valor da chave associada**
PAT_PATRIMONIO_PK = *permite a integridade do campo
COD_PATRIMONIO na tabela
PAT_PATRIMONIO, não permitindo valores
duplicados**
PESO = *Peso do material. **
{dígito numérico}
PRACA_BANCO = *Cidade que o fornecedor mantém a conta
bancária.**
{dígito caracter}
PRECO_UNITARIO = *Preço unitário.**
{dígito numérico}
PUNICAO = *Caso a empresa cometa uma falta.**
{dígito caracter}
QTDE = *Quantidade adquiria.**
{dígito numérico}

SGPAT Versão: 1.0
AP – K
QUEM_ATUAL = *Código do funcionário.**

{dígito caracter}
QUEM_BAI = *Código do funcionário que realizou a baixa
do patrimônio.**
{dígito caracter}
QUEM_SEP = *Código do funcionário que separou.**
{dígito numérico}
RAMAL1 = *Ramal da empresa. **
{dígito numérico}
SALDO = *Total no estoque.**
{dígito numérico}
SEQ_PAT_PATRIMONIO_COD =* Adiciona um número sequencial no código
do patrimônio na tabela PAT_PATRIMONIO**
{dígito numérico}
SEQ_PAT_PATRIMONIO_TOMBAMENTO =* Adiciona um número sequencial no número
de patrimônio na tabela PAT_PATRIMONIO**
{dígito numérico}
SETOR_ANT = *Setor anterior quando o patrimônio é
estornado.**
{dígito caracter}
SITUACAO = *Situação da empresa.**
{dígito caracter}
TF_PK = *permite a integridade do campo
COD_FORNEC na tabela FORNECEDOR, não
TIPO = *Tipo pode ser [I] Entrega Imediata - [C]
Consumo - [P] Permanente - [F] Fabricação
Própria - [D] Devolução - [S] Estornado
TIPO_COMPRA = *É a classe do processo. Exceções: [DEV]
Devolução ** {dígito
caracter}
TIPO_EMPENHO = *Tipo de empenho pode ser [I] Entrega
Imediata - [P] Permanente - [D] Devolução.**
{dígito caracter}
TIPO_PESSOA = *Pessoa física ou jurídica.**
{dígito caracter}
TOMBADO = *indica que o material foi ou não tombado
valores S ou N default N. **
{dígito caracter}
VAL_AQUIS = *Valor da aquisição.**
{dígito numérico}
VAL_AVALIACAO = *Valor da avaliação.
VAL_DOLAR = *Valor do patrimônio em dólar.**
{dígito numérico}
VALOR = *Valor unitário do material.**
{dígito numérico}
Fonte: O Autor.

SGPAT Versão: 1.0
AP – K
3. Diretrizes de Design de Arquitetura
3.1 Telas do Sistema Proposto

A seguir uma panorâmica das principais telas do Sistema Proposto.
3.1.1 Tela Inicial
Os colaboradores acessam a tela inicial, ao abrir o sistema por meio de um navegador como Mozila Firefox. A tela
inicial é exibida na Figura 2, a seguir.
Figura 2 – Tela Inicial.

Fonte: O Autor.
3.1.2 Tela de Cadastro de Patrimônio

A tela de cadastro de patrimônio é demonstrada na Figura 3, a seguir.

SGPAT Versão: 1.0
AP – K
Figura 3 – Tela Inserir Patrimônio.

Fonte: O Autor.
3.1.3 Tela de Consulta de Itens da Nota de Empenho

A Figura 4, a seguir, representa a Tela de Consulta de Itens da Nota de Empenho
Figura 4 – Tela Consultar Itens da Nota de Empenho.

Fonte: O Autor.
As consultas de Grupo, SIAFI e Pesquisar Descrição, os fluxos de eventos são semelhantes a consulta demonstrada
na figura anterior, não estão documentas aqui, entretanto o fluxo de eventos de cada uma delas esta documentado no
artefato adaptado do IBM RUP, Especificação de Realização de Caso de Uso, Apêndice K, nas sub seções.
3.1.4 Tela de Confirmação de Inclusão do Patrimônio
A tela de confirmação de inclusão do patrimônio, caso a inclusão seja bem sucedida, é exibida na Figura 5, a seguir.

SGPAT Versão: 1.0
AP – K
Figura 5 – Tela de Aviso de Confirmação de Inserção.

Fonte: O Autor.
3.1.5 Tela de Erro de Confirmação de Inclusão do Patrimônio
Caso o evento de inserção de um novo patrimônio não tenha sucesso o sistema exibe a tela demonstrada na Figura 6,
a seguir.
Figura 5 – Tela de Aviso de Erro de Confirmação de Inserção.

Fonte: O Autor.

223
APÊNDICE L – Especificação da Realização de Casos de Uso
L1 – RCSU01 – Manter Grupo

INTEGRAÇÃO DSW ME
SGPAT
Especificação de Realização de Casos de Uso:
RCSU01 - Manter grupo
Versão 1.0
SGPAT Versão: 1.0
RCSU01 - Manter grupo Data: 29/04/2010
AP - J

SGPAT Versão: 1.0
AP - J
Índice Analítico
1. Introdução 4
1.2 Visão Geral 4
2. Fluxo de Eventos — Design 4
3. Diagrama de comunicação 4
4. Diagrama de Sequência 5

SGPAT Versão: 1.0
AP - J

RCSU01 - Manter Grupo
1. Introdução
Este documento apresenta a forma utilizada na realização do caso de uso Manter Grupo.

Ver documento Glossário.
1.2 Visão Geral

O documento contém os diagramas de comunicação e sequência.
2. Fluxo de Eventos — Design

É iniciado por um Ator com acesso a restrito.
O colaborador SCAB pode consultar um determinado grupo, na falta do mesmo poderá inserir no sistema,
ou ainda atualizar os dados caso o grupo existente não corresponda às expectativas.
3. Diagrama de comunicação
A Figura 1, a seguir, representa o diagrama de comunicação para a realização do caso de uso Manter
Grupo.
sd RCSU01 - Manter grupo
Manter grupo
FrmIncGrupo CtrlIncGrupo
FrmMenu FrmFiltGrupo FrmListGrupo Grupo

Colaborador SCAB
FrmAltGrupo CtrlAltGrupo
Figura 1 – Diagrama de Comunicação Manter grupo.

Fonte: O Autor.

SGPAT Versão: 1.0
AP - J
4. Diagrama de Sequência
A seguir os diagramas de sequência para o caso de uso citado.
1. Incluir grupo, este diagrama está representado na Figura 2, a seguir.
sd Incluir grupo
Colaborador SCAB
FrmIncGrupo CtrlIncGrupo Grupo FrmListGrupo
bc_incluirGrupo()
tx_descricao(String)
bc_listar()
Grupo()
descricao(String)
listar() :list
Grupo não incluido pode incluir()
Grupo()
incluir()
incluir() :boolean
Grupo incluido()
Figura 2 – Diagrama de Sequência Incluir Grupo.

Fonte: O Autor.
2. Alterar Grupo, este diagrama está representado na Figura 3, a seguir.

SGPAT Versão: 1.0
AP - J
sd Alterar grupo
Colaborador SCAB
FrmAltGrupo CtrlAltGrupo Grupo FrmListGrupo
bc_listar()
Grupo()
descricao(String)
listar() :list
Dados do grupo()
Grupo()
alterar()
alterar() :boolean
Grupo alterado()
Figura 3 – Diagrama de Sequência Alterar Grupo.

Fonte: O Autor.
3. Listar grupo, este diagrama está representado na Figura 4, a seguir.

SGPAT Versão: 1.0
AP - J
sd Listar grupo
Colaborador SCAB
FrmFiltGrupo FrmListGrupo Grupo
bc_listarGrupo()
bc_listar()
Grupo()
descricao(String)
listar() :list
Grupos listados()
Figura 4 – Diagrama de Sequência Listar Grupo.

Fonte: O Autor.

231
L2 – RCSU02 – Manter Siafi

INTEGRAÇÃO DSW ME
SGPAT
RCSU02 - Manter SIAFI
Versão 1.0
SGPAT Versão: 1.0
RCSU02 - Manter SIAFI Data: 29/04/2010
AP - J

SGPAT Versão: 1.0
AP - J
Índice Analítico
1. Introdução 4
1.2 Visão Geral 4
3. Diagrama de Comunicação 4

SGPAT Versão: 1.0
AP - J

RCSU02 - Manter SIAFI
1. Introdução
Este documento apresenta a forma utilizada na realização do caso de uso Manter SIAFI.

1.2 Visão Geral

O documento contém os diagramas de Comunicação e Sequência.

É iniciado por um Ator com acesso restrito.
O colaborador SCAB pode consultar um valor na tabela SIAFI, na falta do mesmo poderá inserir no
sistema ou ainda atualizar os dados de uma tupla na tabela SIAFI.
3. Diagrama de Comunicação
SIAFI.
sd RCSU02 - Manter SIAFI
FrmIncSiafi CtrlIncSiafi
FrmMenu FrmFiltSiafi FrmListSiafi Siafi

Colaborador SCAB
FrmAltSiaf CtrlAltSiafi
Figura 1 – Diagrama de Comunicação Manter SIAFI.

Fonte: O Autor.
1. Incluir SIAFI, este diagrama esta representado na Figura 2, a seguir.

SGPAT Versão: 1.0
AP - J
sd Incluir SIAFI
Colaborador SCAB
FrmIncSiafi CtrlIncSiafi Siafi FrmListSiafi
bc_incluirSiafi()
bc_listar()
Siafi()
descricao(String)
listar() :
List
Siafi não incluido pode incluir()
Siafi()
incluir()
incluir() :boolean
Siafi incluido()
Figura 2 – Diagrama de Sequência Incluir SIAFI.

Fonte: O Autor.
2. Alterar SIAFI, este diagrama esta representado na Figura 3, a seguir.

SGPAT Versão: 1.0
AP - J
sd Alterar SIAFI
Colaborador SCAB
FrmAltSiaf CtrlAltSiafi Siafi FrmListSiafi
bc_alterarSiafi()
bc_listar()
Siafi()
descricao(String)
listar() :
List
Dados do Siafi()
Siafi()
alterar()
alterar() :boolean
Siafi alterado()
Figura 3 – Diagrama de Sequência Alterar SIAFI.

Fonte: O Autor.
3. Listar SIAFI, este diagrama esta representado na Figura 4, a seguir.

SGPAT Versão: 1.0
AP - J
sd Listar SIAFI
Colaborador SCAB
FrmFiltSiafi FrmListSiafi Siafi
bc_listarSiafi()
bc_listar()
Siafi()
descricao(String)
listar() :List
Siafi listado()
Figura 4 – Diagrama de Sequência Listar SIAFI.

Fonte: O Autor.

239
L3 – RCSU03 – Manter Patrimônio

INTEGRAÇÃO DSW ME
SGPAT
RCSU03 - Manter Patrimônio
Versão 1.0
SGPAT Versão: 1.0
RCSU03 - Manter Patrimônio Data: 29/04/2010
AP - J

SGPAT Versão: 1.0
AP - J
Índice Analítico
1. Introdução 4
1.2 Visão Geral 4

SGPAT Versão: 1.0
AP - J

RCSU03 - Manter Patrimônio
1. Introdução
Este documento apresenta a forma utilizada na realização do caso de uso Manter Patrimônio.

1.2 Visão Geral


O colaborador SCAB pode consultar um determinado patrimônio, na falta do mesmo poderá inserir no
sistema ou ainda atualizar os dados de um determinado patrimônio.
Patrimônio.
sd RCSU03 - Manter Patrimônio
FrmIncPatrimonio CtrlIncPatrimonio

Colaborador SCAB
FrmAltPatrimonio CtrlAlterarPatrimonio
Figura 1 – Diagrama de Comunicação Manter Patrimônio.

Fonte: O Autor.
A seguir os diagramas de sequência para o caso de uso Manter Patrimônio.
1. Incluir Patrimônio, este diagrama esta representado na Figura 2, a seguir.

SGPAT Versão: 1.0
AP - J
Figura 2 – Diagrama de Sequência Incluir Patrimônio.

Fonte: O Autor.
2. Alterar Patrimônio, este diagrama esta representado na Figura 3, a seguir.

SGPAT Versão: 1.0
AP - J
Figura 3 – Diagrama de Sequência Alterar Patrimônio.

Fonte: O Autor.
3. Listar Patrimônio, este diagrama esta representado na Figura 4, a seguir.

SGPAT Versão: 1.0
AP - J
sd Listar Patrimônio
Colaborador SCAB
FrmFiltPatrimonio FrmListPatrimonio Patrimonio
bc_listarPatrimonio()
tx_tombamento()
bc_listar()
Patrimonio()
tombamento(int)
listar() :List
Lista de patrimônio()
Figura 4 – Diagrama de Sequência Listar Patrimônio.

Fonte: O Autor.
4. Criar Termo de Responsabilidade, este diagrama esta representado na Figura 5, a seguir.

sd Criar Termo de Responsabilidade
Colaborador SCAB
bc_criarTermo()
tx_tombamento()
bc_listar()
Patrimonio()
tombamento(int)
listar() :List
Termo criado()
Figura 5 – Diagrama de Sequência Criar Termo de Responsabilidade.

SGPAT Versão: 1.0
AP - J
Fonte: O Autor.

248
L4 – RCSU04 – Manter a Descrição Complementar do Item do Material

INTEGRAÇÃO DSW ME
SGPAT
RCSU04 - Manter a Descrição Complementar do Item
do Material
Versão 1.0
SGPAT Versão: 1.0
RCSU04 - Manter a Descrição Complementar do Item do Material Data: 29/04/2010
AP – J

SGPAT Versão: 1.0
AP – J
Índice Analítico
1. Introdução 4
1.2 Visão Geral 4

SGPAT Versão: 1.0
AP – J

RCSU04 - Manter a Descrição Complementar do Item
do Material
1. Introdução
Este documento apresenta a forma utilizada na realização do caso de uso Manter a Descrição
Complementar do Item do Material.

1.2 Visão Geral


O colaborador SCAB pode consultar um valor da descrição complementar do item do material, na falta do
mesmo poderá inserir no sistema ou ainda atualizar os dados caso esteja cadastrado.
Descrição Complementar do Item do Material.
sd CSU04 - Manter a Descrição Complementar do Material
FrmIncDesCompItemMaterial CtrlIncDesCompItemMaterial
FrmMenu FrmFiltDesCompItemMaterial FrmListDesCompItemMaterial DesCompItemMaterial

Colaborador SCAB
FrmAltDesCompItemMaterial CtrlAltDesCompItemMaterial
Figura 1 – Diagrama de Comunicação Manter Descrição Complementar do Item do Material.

Fonte: O Autor.
1. Incluir Descrição Complementar do Item do Material, este diagrama está representado pela Figura 2, a seguir.

SGPAT Versão: 1.0
AP – J
sd Incluir Descrição Complementar do Material
Colaborador SCAB
FrmIncDesCompItemMaterial CtrlIncDesCompItemMaterial DesCompItemMaterial FrmListDesCompItemMaterial
bc_incDesCompItemMaterial()
bc_listar()
DesCompItemMaterial()
listar() :List
descricao(String)
Descrição Complementar do Item do Material não encontrado pode incluir()
incluir()
incluir() :boolean
Descrição Complementar do Item do Material incluido()
1 - Pesquisar item do material
Figura 2 – Diagrama de Sequência Incluir Descrição Complementar do Item do Material.

Fonte: O Autor.
2. Alterar Descrição Complementar do Item do Material, este diagrama está representado por intermédio da Figura
3, a seguir.

SGPAT Versão: 1.0
AP – J
sd Alterar Descrição Complementar do Material
Colaborador SCAB
FrmAltDesCompItemMaterial CtrlAltDesCompItemMaterial DesCompItemMaterial FrmListDesCompItemMaterial
bc_altDesCompItemMaterial()
bc_listar()
descricao(String)
listar() :List
Lista de Descrição
Complementar do
Item do Material ()
alterar()
alterar() :boolean
Descrição Complementar do Item do Material alterada()
1 - Pesquisar item do material
Figura 3 – Diagrama de Sequência Alterar Descrição Complementar do Item do Material.

Fonte: O Autor.
3. Listar Descrição Complementar do Item do Material, este diagrama está representado por intermédio da Figura 4,
a seguir.

SGPAT Versão: 1.0
AP – J
sd Listar Descrição Complementar do Material
Colaborador SCAB
FrmFiltDesCompItemMaterial FrmListDesCompItemMaterial DesCompItemMaterial
bc_listarDesCompItemMaterial()
bc_listar()
descricao(String)
listar() :List
Lista da Descrição Complementar do Item do Material ()
Figura 4 – Diagrama de Sequência Listar Descrição Complementar do Item do Material.

Fonte: O Autor.

256
L5 – RCSU05 – Manter Fornecedor

INTEGRAÇÃO DSW ME
SGPAT
RCSU05 - Manter Fornecedor
Versão 1.0
SGPAT Versão: 1.0
RCSU05 - Manter Fornecedor Data: 29/04/2010
AP – J

SGPAT Versão: 1.0
AP – J
Índice Analítico
1. Introdução 4
1.2 Visão Geral 4

SGPAT Versão: 1.0
AP – J

RCSU05 - Manter Fornecedor
1. Introdução
Este documento apresenta a forma utilizada na realização do caso de uso Manter Fornecedor.

1.2 Visão Geral


O colaborador SELCO pode consultar um determinado Fornecedor, na falta do mesmo poderá inserir no
sistema ou ainda atualizar os dados de um determinado Fornecedor.
Fornecedor.
sd RCSU05 - Manter Fornecedor
FrmIncFornecedor CrtlIncFornecedor
Fornecedor
FrmMenu FrmFiltFornecedor FrmListFornecedor
Colaborador SELCO
FrmAltFornecedor CtrlAltFornecedor
Figura 1 – Diagrama de Comunicação Manter Fornecedor.

Fonte: O Autor.
1. Incluir Fornecedor, este diagrama está representado por intermédio da Figura 2, a seguir.

SGPAT Versão: 1.0
AP – J
sd Incluir fornecedor
Colaborador SELCO
FrmIncFornecedor CrtlIncFornecedor Fornecedor FrmListFornecedor
bc_incluirFornecedor()
bc_listar()
Fornecedor()
descricao(String)
listar() :List
Fornecedor não cadastrado pode cadastrar()
Fornecedor()
incluir()
incluir() :boolean
Fornecedor incluido()
Figura 2 – Diagrama de Sequência Incluir Fornecedor.

Fonte: O Autor.
2. Alterar Fornecedor, este diagrama está representado por intermédio da Figura 3, a seguir.

SGPAT Versão: 1.0
AP – J
sd Alterar fornecedor
Colaborador SCAB
FrmAltFornecedor CtrlAltFornecedor Fornecedor FrmListFornecedor
bc_alterarFornecedor()
bc_listar()
Fornecedor()
descricao(String)
listar() :List
Dados do fornecedor()
Fornecedor()
alterar()
alterar() :boolean
Fornecedor alterado()
Figura 3 – Diagrama de Sequência Alterar Fornecedor.

Fonte: O Autor.
3. Listar Fornecedor, este diagrama está representado pela Figura 4, a seguir.

SGPAT Versão: 1.0
AP – J
sd Listar fornecedor
Colaborador SCAB
FrmFiltFornecedor FrmListFornecedor Fornecedor
bc_listarFornecedor()
bc_listar()
Fornecedor()
descricao(String)
listar() :List
Relação de fornecedores()
Figura 4 – Diagrama de Sequência Listar Fornecedor.

Fonte: O Autor.

264
L6 – RCSU06 – Manter Nota de Empenho do Material

INTEGRAÇÃO DSW ME
SGPAT
RCSU06 - Manter Nota de Empenho do Material
Versão 1.0
SGPAT Versão: 1.0
RCSU06 - Manter Nota de Empenho do Material Data: 29/04/2010
AP – J

SGPAT Versão: 1.0
AP – J
Índice Analítico
1. Introdução 4
1.2 Visão Geral 4

SGPAT Versão: 1.0
AP – J

RCSU06 - Manter Nota de Empenho do Material
1. Introdução
Este documento apresenta a forma utilizada na realização do caso de uso Manter Nota de Empenho do
Material.

1.2 Visão Geral


O colaborador Almoxarifado poderá consultar uma nota de empenho, na falta da mesma poderá inserir no
sistema ou ainda realizar a atualização da mesma.
A Figura 1, a seguir, representa o diagrama de comunicação para a realização do caso de uso Manter Nota
de Empenho do Material.
sd RCSU06 - Manter Nota de Empenho do Material
FrmIncNeMaterial CtrlIncNeMaterial
FrmMenu FrmFiltNeMaterial FrmListNeMaterial NeMaterial

Colaborador
Almoxarifado
FrmAltNeMaterial CtrlAltNeMaterial
Figura 1 – Diagrama de Comunicação Manter Nota de Empenho do Material.

Fonte: O Autor.
1. Incluir Nota de Empenho do Material, este diagrama está representado por intermédio da Figura 2, a seguir.

SGPAT Versão: 1.0
AP – J
sd Incluir Nota de Empenho do Material
Colaborador Almoxarifado
FrmIncNeMaterial CtrlIncNeMaterial NeMaterial FrmListNeMaterial
bc_incluirNeMaterial()
tx_numNe(String)
bc_listar()
NeMaterial()
numNe(int)
listar(List)
Nota de empenho não incluida. Pode incluir()
NeMaterial()
incluir()
incluir() :boolean
Nota de empenho incluida()
1 - Pesquisar fornecedor
Figura 2 – Diagrama de Sequência Incluir Nota de Empenho do Material.

Fonte: O Autor.
2. Alterar Nota de Empenho do Material, este diagrama está representado por intermédio da Figura 3, a seguir.

SGPAT Versão: 1.0
AP – J
sd Alterar Nota de Empenho do Material
FrmAltNeMaterial CtrlAltNeMaterial NeMaterial FrmListNeMaterial
bc_alterarNeMaterial()
tx_numNe(String)
bc_listar()
NeMaterial()
numNe(int)
listar(List)
Dados da nota de empenho do material()
NeMaterial()
alterar()
alterar() :boolean
Nota de Empenho do Material alterado()
1 - Pesquisar fornecedor
Figura 3 – Diagrama de Sequência Alterar Nota de Empenho do Material.

Fonte: O Autor.
3. Listar Nota de Empenho do Material, este diagrama está representado pela Figura 4, a seguir.

SGPAT Versão: 1.0
AP – J
sd Listar Nota de Empenho do Material
FrmFiltNeMaterial FrmListNeMaterial NeMaterial
bc_listarNeMaterial()
tx_numNe(String)
bc_listar()
NeMaterial()
numNe(int)
listar(List)
Relação dos dados da nota()
Figura 4 – Diagrama de Sequência Listar Nota de Empenho do Material.

Fonte: O Autor.

272
L7 – RCSU07 – Manter Item do Material

INTEGRAÇÃO DSW ME
SGPAT
RCSU07 – Manter Item do Material
Versão 1.0
SGPAT Versão: 1.0
RCSU07 - Manter Item do Material Data: 29/04/2010
AP – J

SGPAT Versão: 1.0
AP – J
Índice Analítico
1. Introdução 4
1.2 Visão Geral 4

SGPAT Versão: 1.0
AP – J

RCSU07 - Manter Item do Material
1. Introdução
Este documento apresenta a forma utilizada na realização do caso de uso Manter Item do Material.

1.2 Visão Geral


O colaborador Almoxarifado pode consultar um determinado item do material, na falta do mesmo poderá
inserir no sistema ou ainda atualizar.
A Figura 1, a seguir, representa o diagrama de comunicação para a realização do caso de uso Manter Item
do Material.
sd RCSU07 - Manter Item do Material
FrmIncItemMaterial CtrlIncItemMaterial
Colaborador FrmMenu FrmFiltItemMaterial FrmListItemMaterial ItemMaterial

Almoxarifado
FrmAltItemMaterial CtrlAltItemMaterial
Figura 1 – Diagrama de Comunicação Manter Item do Material.

Fonte: O autor.

SGPAT Versão: 1.0
AP – J
1. Incluir Item do Material, este diagrama está representado por intermédio da Figura 2, a seguir.
sd Incluir Item do Material
FrmIncItemMaterial CtrlIncItemMaterial ItemMaterial FrmListItemMaterial
bc_incluirItemMaterial()
tx_descricao()
bc_listar()
ItemMaterial()
descricao(String)
listar() :List
Item não incluido. Pode incluir()
ItemMaterial()
incluir()
incluir() :boolean
Item cadastrado()
Figura 2 – Diagrama de Sequência Incluir Item do Material.

Fonte: O autor.
2. Alterar Item do Material, este diagrama está representado por intermédio da Figura 3, a seguir.

SGPAT Versão: 1.0
AP – J
sd Alterar Item do Material
FrmAltItemMaterial CtrlAltItemMaterial ItemMaterial FrmListItemMaterial
bc_AlterarItemMaterial()
tx_descricao()
bc_listar()
ItemMaterial()
descricao(String)
listar()
Dados do item do material()
ItemMaterial()
alterar()
alterar() :boolean
Item alterado()
Figura 3 – Diagrama de Sequência Alterar Item do Material.

Fonte: O Autor.
3. Listar Item do Material, este diagrama está representado pela Figura 4 a seguir.

SGPAT Versão: 1.0
AP – J
sd Listar Item do Material
FrmFiltItemMaterial FrmListItemMaterial ItemMaterial
bc_listarItemMaterial()
tx_descricao()
bc_listar()
ItemMaterial()
descricao(String)
listar()
Lista de Itens do Material()
Figura 4 – Diagrama de Sequência Listar Item do Material.

Fonte: O autor.

280
L8 – RCSU08 – Patrimônio Disponível no Setor

INTEGRAÇÃO DSW ME
SGPAT
RCSU08 - Patrimônio Disponível no Setor
Versão 1.0
SGPAT Versão: 1.0
Patrimônio Disponível no Setor Data: 29/04/2010
AP – J

SGPAT Versão: 1.0
AP – J
Índice Analítico
1. Introdução 4
1.2 Visão Geral 4

SGPAT Versão: 1.0
AP – J

RCSU08 - Patrimônio Disponível no Setor
1. Introdução
Este documento apresenta a forma utilizada na realização do caso de uso Patrimônio Disponível no Setor.

1.2 Visão Geral


Os colaboradores podem consultar os materiais permanentes disponíveis no setor.
A Figura,1 a seguir, representa o diagrama de comunicação para a realização do caso de uso citado neste
documento.
sd RCSU08 - Patromônio Disponiv el no Setor

Outros Colaboradores (from Realização)
(from Atores)
Figura 1 – Diagrama de Comunicação Patrimônio Disponível no Setor.

Fonte: O autor.
O diagrama de sequência para realizar a consulta ao material disponível no setor é representado por intermédio da
Figura 2, a seguir.

SGPAT Versão: 1.0
AP – J
sd Verificar Patromônio Disponiv el no Setor
Outros Colaboradores
bc_verificarPatrimonioSetor()
bc_listar()
Patrimonio()
listar() :List
Lista de materiais existentes no setor()
Figura 2 – Diagrama de Sequência Patrimônio Disponível no Setor.

Fonte: O Autor.

286
APÊNDICE M - Guia de Teste

INTEGRAÇÃO DSW ME
SGPAT
Guia de Teste
Versão 1.0
SGPAT Versão: 1.0
Guia de Teste Data: 29/04/2010
AP – M

SGPAT Versão: 1.0
AP – M
Índice Analítico
1. Introdução 4
1.1 Finalidade 4
2. Metas do Teste 4
3. Medidas-chave 4
4. Critérios de Conclusão do Teste 4

SGPAT Versão: 1.0
AP – M
Guia de Teste
1. Introdução
Durante o processo de desenvolvimento do software, um ambiente de teste deve ser preparado em que os
resultados obtidos devem ser armazenados para serem analisados e comparados.
1.1 Finalidade
Este documento fornece uma guia de teste para o projeto.

Ver Glossário
2. Metas do Teste
Um produto de software para produzir os resultados esperados durante a sua construção precisa ser
conveniente e adequadamente testado, para que um número mínimo de ajustes seja necessário durante a sua
vida útil.
3. Medidas-chave
Algumas medidas a serem tomadas quanto aos testes:
• verificação – avaliar se o planejamento foi atendido, os casos de uso foram realizados;
• modificações – realizacao de um estudo para modificar requisitos solicitados pelo cliente.
• Inconsistência – revisar os artefatos realizando uma varredura para encontrar inconsistência nos
requisitos.
4. Critérios de Conclusão do Teste

Após o sistema estar estável os testes podem ser concluídos, entretanto as atividades de teste continuam
além do projeto se estendendo ao cliente.

291
APÊNDICE N – Plano de Implantação

INTEGRAÇÃO DSW ME
SGPAT
Plano de Implantação
Versão 1.0
SGPAT Versão: 1.0
Plano de Implantação Data: 29/04/2010
AP – N

SGPAT Versão: 1.0
AP – N
Índice Analítico
1. Introdução 4
2. Planejamento de Implantação 4
2.1.1 Software de Suporte 4
3. Treinamento 4

SGPAT Versão: 1.0
AP – N
Plano de Implantação
1. Introdução
O presente documento tem como objetivo descrever como o será realizada a implantação do sistema.

Ver Glossário.
2. Planejamento de Implantação
Após a validação o produto, será concluído e empacotado em um arquivo no formato .war para posterior
instalação no cliente.
2.1.1 Software de Suporte

São necessários para a implementação do sistema desenvolvido:
• Oracle 9g ou superior;
• Java 5 ou superior;
• Apache Tomcat 5 ou superior
3. Treinamento
O treinamento será realizado com os principais envolvido e futuramente será criado um manual não
fazendo parte do escopo da monografia.

Soni

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Soni

Enviado por

Direitos autorais:

Formatos disponíveis

UNIVERSIDADE DO SUL DE SANTA CATARINA

SONI JOÃO DA SILVA

REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE PATRIMÔNIO DO

REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE PATRIMÔNIO DO

Trabalho de Conclusão de Curso apresentado ao Curso

Prof. e orientador: Osmar de Oliveira Braz Júnior, Msc. Eng.

Prof. e co-orientador: Ricardo Villarroel Dávalos, Dr. Eng.

REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE PATRIMÔNIO DO

Este Trabalho de Conclusão de Curso foi julgado

Palhoça, 15 de junho de 2010.

Agradeço a Deus pela saúde e força de vontade ao longo desta caminhada.

O desenvolvimento de um sistema de software, robusto, de qualidade é caro, entretanto, em

Palavras-chave: Reengenharia. Engenharia reversa. Engenharia avante. IBM RUP.

The development of a software system, robust, of quality is expensive, however, in legacy

Key words: Reengineering. Reverse engineering. Forwards engineering. IBM RUP.

Figura 1 – Consulta ao sistema atual........................................................................................ 17

Tabela 1 – Workflows Estáticos no Rational Unified Process................................................ 44

ASP – Active Server Pages

Com a globalização, as empresas buscam formas de redução de custos, para

O Setor de Cadastro e de Administração de Bens (SCAB) é vinculado ao Serviço

O TRT/SC conta com um sistema de gerenciamento de patrimônio genérico, que

Figura 1 – Consulta ao sistema atual.

Para o funcionário responsável por um setor imprimir um termo de

O Sistema de Gerenciamento de Patrimônio Proposto tem por finalidade:

Nesta seção são apresentados os objetivos: geral e específicos.

1.2.1 Objetivo Geral

Desenvolver um protótipo de sistema de gerenciamento de patrimônio voltado

1.2.2 Objetivos Específicos

O projeto tem como objetivos específicos:

No segundo semestre de 2003, quando demos início aos estudos no curso de

1.4 ESTRUTURA DA MONOGRAFIA

O presente trabalho encontra-se estruturado da seguinte forma:

• capítulo 5 – apresenta os testes, e validação.

Este capítulo aborda as obras de diferentes autores sobre o assunto em questão,

Quando se aborda o termo “engenharia de software”, é conveniente definir

Figura 3 – Reengenharia na construção civil.

2.1.1 Engenharia de Software

A engenharia de software abrange um conjunto de três elementos fundamentais:

Os procedimentos da engenharia de software constituem o elo de ligação que

Para Sommerville (2007), Software não é somente o programa, mas todos os

e produtividade de software, embora estes sejam menores do que os previstos pelos

2.1.1.1 Engenharia de Sistemas

“A engenharia de sistemas é a atividade de especificação, projeto, implementação,

Ainda, o mesmo autor enfatiza que os sistemas sociotécnicos podem incluir um ou

2.2 PROCESSO DE SOFTWARE

Um processo de software, para Sommerville (2007, p. 42), representa um

Não existe um processo ideal, e varias organizações desenvolvem abordagens

2.2.1 Atividades do processo de desenvolvimento

Bezerra (2002, p. 20) destaca que o “processo de desenvolvimento classifica, em

2.2.1.1 Levantamento de Requisitos

Bezerra (2002, p. 20) destaca que a atividade de levantamento de requisitos

Sommerville (2007, p. 80) entende que alguns dos problemas encontrados,

O autor citado acima, entende que, nesse documento, devem-se conter os

Figura 4 – Usuários de um documento de requisitos.

Por conseguinte, ele entende que, em sistemas de certa complexidade, é

2.2.1.2 Análise de Requisitos

Bezerra (2002, p. 24) sustenta que “o termo análise corresponde a ‘quebrar’ um

Seguindo a mesma linha de raciocínio os autores comentam que esses requisitos

Alguns autores separam projeto em uma seção, em outros, é parte do ‘processo de

É oportuno destacar que, segundo Bezerra (2002, p. 26), embora a análise e o

Ao referir-se aos diagramas UML, para complementar o parágrafo anterior, ele

É na fase de implementação que ocorre a programação propriamente dita escrita

No processo de implantação, o sistema é empacotado e, posteriormente, será