REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE …
295
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
Transcript of REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE …
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
REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE PATRIMÔNIO DO
TRIBUNAL REGIONAL DO TRABALHO DE SANTA CATARINA
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
REENGENHARIA DO SISTEMA DE GERENCIAMENTO DE PATRIMÔNIO DO
TRIBUNAL REGIONAL DO TRABALHO DE SANTA CATARINA
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 3.5 CONCLUSÕES DO CAPÍTULO .................................................................................................56 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.1 Gerenciamento de Projeto.......................................................................................................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.1.4.2 Gerenciamento de Projeto.......................................................................................................65 4.2 AMBIENTE DE DESENVOLVIMENTO ...................................................................................66 4.3 IMPLEMENTAÇÃO DO SISTEMA ...........................................................................................68 4.4 CONCLUSÕES DO CAPÍTULO .................................................................................................71 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. Fonte: Adaptado de Sommerville (2007).
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. Fonte: Adaptado de Sommerville (2007).
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
negócios
Os processos de negócios são modelados, usando casos de uso de
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
configuração e
mudanças
Esse workflow de apoio gerencia as mudanças do sistema.
Gerenciamento de
projetos
Esse workflow de apoio gerencia o desenvolvimento do sistema.
Ambiente Esse workflow está relacionado à disponibilização de ferramentas
apropriadas de software para a equipe de desenvolvimento. Fonte: Adaptado de Sommerville (2007).
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
3.5 CONCLUSÕES DO CAPÍTULO
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. Fonte: Adaptado de Rational (2009).
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).
4.1.2.1 Gerenciamento de Projeto
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
Fonte: Adaptado de Rational (2009).
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:
• Visão (APÊNDICE A);
• 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. Fonte: Adaptado de Rational (2009).
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. Fonte: Adaptado de Rational (2009).
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. Fonte: Adaptado de Rational (2009).
Na presente disciplina, foram atualizados os artefato de:
• Plano de Desenvolvimento de Software (APÊNDICE D);
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. Fonte: Adaptado de Rational (2009).
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. Fonte: Adaptado de Rational (2009).
O artefato gerado para este detalhamento da disciplina foi:
• Plano de Implantação (APÊNDICE N).
4.1.4.2 Gerenciamento de Projeto
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. Fonte: Adaptado de Rational (2009).
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
4.4 CONCLUSÕES DO CAPÍTULO
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
flutuante
Somente permitido números de 0 a 9 e
somente uma vírgula
JavaScript
Campos de texto Retira aspas simples ou duplas antes de
gravar
Tratamento do
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 Janeiro: Campus, 2000. 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 Janeiro: Campus, 1996. 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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 11
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
SGPAT Versão: 1.0 Visão Data: 18/11/2009 AP - A
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 11
Í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 Visão Data: 18/11/2009 AP - A
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 11
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 Visão Data: 18/11/2009 AP - A
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 11
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 (Gerente de Projeto)
Apoio, contato Desenvolve e gerencia os projetos do TRT/SC
DESENVOLVEDOR Desenvolvimento de todo o projeto
Desenvolver o projeto proposto
SEMAP (Colaborador SEMAP)
Colaborador Recebe relatórios
SCAB (Colaborador SCAB)
Colaborador Administrar e controlar o patrimônio do TRT/SC
SELCO Colaborador Administra a relação de fornecedores
OUTROS COLABORADORES
Colaborador Normalmente os setores que fazem 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 Visão Data: 18/11/2009 AP - A
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 11
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 SEMAP
Imprimir relatórios da situação dos patrimônio
XXXX Chefe do SCAB Administrar o setor de cadastro administração de patrimônio
Coordenar os trabalhos do setor
XXXX Funcionário do SCAB
Acesso ao sistema para cadastro, atualização e manipulação de patrimônio
Usuário principal do sistema
XXXX Funcionário do SCAB
Acesso ao sistema para cadastro, atualização e manipulação de patrimônio
Usuário principal do sistema
XXXX Funcionário do SCAB
Acesso ao sistema para cadastro, atualização e manipulação de patrimônio
Usuário principal do sistema
XXXX Funcionário do SELCO
Acesso ao sistema para cadastro, atualização e manipulação de fornecedores
Outros setores
Setores que fazem pedidos
Fazer pedidos, receber termo de recebimento do patrimônio
Consulta e pedido
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 Visão Data: 18/11/2009 AP - A
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 11
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
Comentários/Problemas
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
Comentários/Problemas
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 Visão Data: 18/11/2009 AP - A
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 8 de 11
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 Visão Data: 18/11/2009 AP - A
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 9 de 11
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 Visão Data: 18/11/2009 AP - A
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 10 de 11
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 Visão Data: 18/11/2009 AP - A
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 11 de 11
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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 6
Histórico da Revisão Data Versão Descrição Autor
18/11/2009 1.0 Versão inicial Soni
22/04/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 Glossário Data: 18/11/2009 AP – B
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 6
Í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 Glossário Data: 18/11/2009 AP – B
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 6
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 Glossário Data: 18/11/2009 AP – B
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 6
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 Glossário Data: 18/11/2009 AP – B
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 6
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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 4
Histórico da Revisão Data Versão Descrição Autor
18/11/2009 1.0 Versão Inicial Soni
22/04/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 Lista de Riscos Data: 18/11/2009 AP - C
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 4
Í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 Lista de Riscos Data: 18/11/2009 AP - C
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 4
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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 6
Histórico da Revisão Data Versão Descrição Autor
17/11/2009 1.0 Visão inicial Soni
23/04/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 Plano de Desenvolvimento de Software Data: 17/11/2009 AP - D
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 6
Í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
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 Plano de Desenvolvimento de Software Data: 17/11/2009 AP - D
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 6
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.
1.3 Definições, Acrônimos e Abreviações Ver documento Visão e Glossário.
1.4 Referências São referenciados a seguir os artefatos produzidos durante o desenvolvimento do projeto.
• 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);
• 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 Plano de Desenvolvimento de Software Data: 17/11/2009 AP - D
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 6
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
Soni João da Silva
Gerente do projeto; Responsável pelo levantamento e gerenciamento de riscos; Analista do projeto; 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 Plano de Desenvolvimento de Software Data: 17/11/2009 AP - D
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 6 de 6
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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 5
Histórico da Revisão Data Versão Descrição Autor
20/11/2009 1.0 Versão inicial Soni
23/04/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 Plano de Iteração Data: 20/11/2009 AP – E
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 5
Í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. Plano 4
3. Recursos 4
4. Casos de Uso 4
5. Critérios de Avaliação 5
SGPAT Versão: 1.0 Plano de Iteração Data: 20/11/2009 AP – E
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 5
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.
1.3 Definições, Acrônimos e Abreviações 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. Fonte: Adaptado de Rational (2009).
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 Plano de Iteração Data: 20/11/2009 AP – E
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 5
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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 9
Histórico da Revisão Data Versão Descrição Autor
23/04/2010 1.0 Versão inicial Soni
SGPAT Versão 1.0 Especificação dos Requisitos de Software Data: 23/04/2010 AP – F
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 9
Índice Analítico 1. Introdução 4
1.1 Definições, Acrônimos e Abreviações 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 Especificação dos Requisitos de Software Data: 23/04/2010 AP – F
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 9
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.
1.1 Definições, Acrônimos e Abreviações 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 Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
O sistema deve prover funcionalidades que permitam ao usuário cadastrar dados de um fornecedor.
RF02 – Alteração de fornecedor
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
O sistema deve prover funcionalidades que permitam ao usuário alterar dados de um fornecedor.
RF03 – Consultar fornecedor
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
O sistema deve prover funcionalidades que permitam ao usuário alteração da nota de
SGPAT Versão 1.0 Especificação dos Requisitos de Software Data: 23/04/2010 AP – F
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 9
empenho do material. RF06 – Consultar nota de empenho do material
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
O sistema deve prover funcionalidades que permitam ao usuário listar a nota de empenho do material.
RF07 - Inclusão de item do material
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
O sistema deve prover funcionalidades que permitam ao usuário alterar itens do material adiquirido de um fornecedor.
RF09 – Consultar itens do material
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário consultar fornecedores por meio de filtro.
RF10 - Inclusão da descrição complementar do item do material
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário consultar descrições complementares dos itens dos materiais por meio de filtro.
RF13 – Inclusão de grupo
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário cadastrar um novo grupo de bens.
SGPAT Versão 1.0 Especificação dos Requisitos de Software Data: 23/04/2010 AP – F
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 6 de 9
RF14 – Alteração de grupo
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário alterar um grupo.
RF15 – Consultar grupo
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário consultar grupos por meio de filtro.
RF16 – Inclusão de SIAFI
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário cadastrar uma nova classificação de bem segundo o SIAFI.
RF17 – Alteração de SIAFI
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário alterar uma classificação de bem segundo o SIAFI.
RF18 – Consultar SIAFI
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário consultar valores da tabela SIAFI por meio de filtro.
RF19 – Inclusão de patrimônio
Satus: Approved Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário cadastrar um novo patrimônio.
RF20 – Alteração de patrimônio
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário alterar um patrimônio.
RF21 - Consultar patrimônio no setor
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
O sistema deve prover funcionalidades que permitam aos funcionário do setor listar os bens disponíveis no setor.
SGPAT Versão 1.0 Especificação dos Requisitos de Software Data: 23/04/2010 AP – F
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 7 de 9
RF22 – Consultar patrimônio Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deve prover funcionalidades que permitam ao usuário consultar um patrimônio por meio de filtro.
RF23 – Criar termo de responsabilidade provisório
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema deverá estar acoplado a um SGBD Oracle 9g ou superior. RNF05 – Tipo de conexão com o SGBD
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium «Functional» Phase: 1.0 Version: 1.0
SGPAT Versão 1.0 Especificação dos Requisitos de Software Data: 23/04/2010 AP – F
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 8 de 9
Observação: O sistema poderá ser acessado por intermédio dos navegadores Internet Explorer e Firefox.
RNF07 – Feedback Para Reportar Bugs
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema fica melhor se visualizado em uma resolução 1024 x 768. RNF02 – Formato dos relatórios
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: Os relatórios serão exibidos em formato PDF ou RTF. RNF03 – Manutenabilidade
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Observação: O sistema será produzido em camadas facilitando possíveis atualizações de versão.
3. Requisitos Externos
RNF01 - Dados do usuário
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium «Functional» Phase: 1.0 Version: 1.0
SGPAT Versão 1.0 Especificação dos Requisitos de Software Data: 23/04/2010 AP – F
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 9 de 9
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Descrição: Após o patrimônio ser devidamente tombado, esta operação não poderá ser desfeita.
RN04 - Administração de fornecedores
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
Descrição: A manutenibilidade de fornecedores será atribuição do SELCO. RN05 - Administração de material
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Satus: Proposed Priority: Medium Difficulty: Medium Phase: 1.0 Version: 1.0
«Functional»
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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 4
Histórico da Revisão Data Versão Descrição Autor
22/11/2009 1.0 Versão inicial Soni
SGPAT Versão: 1.0 Guia de Modelagem de Casos de Uso Data: 22/11/2009 AP - G
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 4
Índice Analítico 1. Introdução 4
1.1 Finalidade 4
2. Como Descrever um Caso de Uso 4
SGPAT Versão: 1.0 Guia de Modelagem de Casos de Uso Data: 22/11/2009 AP - G
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 4
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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 6
Histórico da Revisão Data Versão Descrição Autor
26/11/2009 1.0 Versão inicial Soni
23/04/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 CSU01 - Manter Grupo Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 6
Í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 CSU01 - Manter Grupo Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 6
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 eseleciona pesquisar
Achou?
Sitema exibe uma lista
Fim
[Não]
[Sim]
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 CSU01 - Manter Grupo Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 6
act Diagrama de Ativ idade CSU01 - Icluir Grupo
Inicio
Usuário informadescrição e seleciona
pesquisarUsuário informa demais
dados e confirma Sistema emite mensagem
de inserção
Fim
O grupo já contém esta túpla?
Mensagem o sistema jáconta com este v alor.
Informe outra descrição.
[Não]
[Sim]
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 CSU01 - Manter Grupo Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 6 de 6
act Diagrama de Ativ idade CSU01 - Alterar Grupo
Inicio
Usuário informa parte dadescrição e realiza
pesquisaSistema lista Usuário seleciona um
v alor da lista
Achou?Sistema retorna ao
fromulário para alteraçãoUsuário altera campos e
salv a
Fim
[Sim][Não]
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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 6
Histórico da Revisão Data Versão Descrição Autor
26/11/2009 1.0 Versão inicial Soni
01/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 CSU02 – Manter Tabela SIAFI Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 6
Índice Analítico 1. CSU02 – Manter a Tabela SIFI 4
1.1 Breve Descrição 4
2. Fluxo de Eventos 4 2.1 Fluxo Básico 4
2.1.1 Consultar SIAFI 4 2.2 Fluxos Alternativos 4
2.2.1 Inserir SIAFI 4 2.2.2 Alterar SIAFI 5
3. Pós-condições 6
SGPAT Versão: 1.0 CSU02 – Manter Tabela SIAFI Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 6
1. CSU02 – Manter a Tabela SIFI
1.1 Breve Descrição 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 eseleciona pesquisar
Achou?
Sistema lista
Fim
[Sim]
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 Fluxos Alternativos
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 CSU02 – Manter Tabela SIAFI Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 6
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 CSU02 – Manter Tabela SIAFI Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 6 de 6
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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 7
Histórico da Revisão Data Versão Descrição Autor
26/11/2009 1.0 Versão inicial Soni
01/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 CSU03 – Manter Patrimônio Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 7
Índice Analítico 1. CSU03 – Manter Patrimônio 4
1.1 Breve Descrição 4
2. Fluxo de Eventos 4 2.1 Fluxo Básico 4
2.1.1 Consultar Patrimônio 4 2.2 Fluxos Alternativos 4
2.2.1 Incluir Patrimônio 4 2.2.2 Alterar Patrimônio 5 2.2.3 Criar Termo Provisório 6
3. Pós-condições 7
SGPAT Versão: 1.0 CSU03 – Manter Patrimônio Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 7
1. CSU03 – Manter Patrimônio
1.1 Breve Descrição 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
Fim
Início
Usuário informa tombamento erealiza pesquisa
Sistema exibe consulta
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 Fluxos Alternativos
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 CSU03 – Manter Patrimônio Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 7
act Diagrama de Ativ idade CSU03 - Icluir Patrimônio
Início
Usuário informa parte dadescrição do grupo, pesquisa ,
seleciona um v alor
Usuário informa parte dadescrição do patrimônio e
realiza pesquisa, selecionaum v alor
Usuário informa os demaisdados e seleciona Cadastrar
Sistema preenche com v alorum
Sistema emite mensageminformando a quantidade de
itens cadastrados e o númerodo último tombamento.
Fim
Usuário informa o númeroda nota de empenho e
pesquisa
encontrou?
Usuário informa parte dadescrição do SIAFI,
pesquisa e seleciona umv alor
Usuário informa parte dadescrição complementar,
pesquisa e seleciona um v alor
[Não]
[Sim]
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 CSU03 – Manter Patrimônio Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 6 de 7
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 CSU03 – Manter Patrimônio Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 7 de 7
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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 6
Histórico da Revisão Data Versão Descrição Autor
26/11/2009 1.0 Versão inicial Soni
01/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 CSU04 – Manter a Descrição Complementar do Item do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 6
Índice Analítico 1. CSU04 – Manter a Descrição Complementar do Item do Material 4
1.1 Breve Descrição 4
2. Fluxo de Eventos 4 2.1 Fluxo Básico 4
2.1.1 Consultar Descrição Complementar do Item do Material 4 2.2 Fluxos Alternativos 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
3. Pós-condições 6
SGPAT Versão: 1.0 CSU04 – Manter a Descrição Complementar do Item do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 6
1. CSU04 – Manter a Descrição Complementar do Item do Material
1.1 Breve Descrição 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
Inicio
Usuário informa parte dadescricao e confirma
Sistema lista os itens dadescrição complementar
Fim
Figura 1 - Diagrama de Atividade CSU04 - Consultar Descrição Complementar do Item do Material. 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 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 CSU04 – Manter a Descrição Complementar do Item do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 6
act Diagrama de Ativ idade CSU04 - Icluir Descrição Complementar do Item do Material
Inicio
Usuário pesquisa itens domaterial, v erifica se o item
foi cadastrado
Item cadastrado?
Usuário pesquisa e lista adescrição complementar doitem para v erificar se já foi
cadastrada
Descrição cadastrada? Usuário informa demasidados e confirma
Tem erro?
Sistma emite av iso deerro
Sistema emite av iso deOK
Fim
[Sim] [Não]
[Não]
[Sim]
[Não]
[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 CSU04 – Manter a Descrição Complementar do Item do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 6 de 6
act Diagrama de Ativ idade CSU04 - Alterar Descrição Complementar do Item do Material
Inicio
Usuário pesquisa e lista adescrição complementar doitem para v erificar se já foi
cadastrada
Descrição cadastrada?
Usuário pesquisa itens domaterial caso quera alterar
Alterar item do material?Usuário informa dados a
alterar e confirma
Sistema emite av iso deOK
Sistma emite av iso deerro
Tem erro?
Fim
[Sim]
[Não]
[Não]
[Sim]
[Sim]
[Não]
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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 6
Histórico da Revisão Data Versão Descrição Autor
26/11/2009 1.0 Versão inicial Soni
01/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 CSU05 – Manter Fornecedor Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 6
Índice Analítico 1. CSU05 – Manter Fornecedor 4
1.1 Breve Descrição 4
2. Fluxo de Eventos 4 2.1 Fluxo Básico 4
2.1.1 Consultar Fornecedor 4 2.2 Fluxos Alternativos 4
2.2.1 Incluir Fornecedor 4 2.2.2 Alterar Fornecedor 5
3. Pós-condições 6
SGPAT Versão: 1.0 CSU05 – Manter Fornecedor Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 6
1. CSU05 – Manter Fornecedor
1.1 Breve Descrição 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 dofornecedor e seleciona pesquisar
Fornecedor cadastrado?
Sistema lista os fornecedores
Fim
[Sim]
[Não]
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 Fluxos Alternativos
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 CSU05 – Manter Fornecedor Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 6
act Diagrama de Ativ idade CSU05 - Incluir Fornecedor
Início
Usuário informa parte da descriçãodo fornecedor e seleciona pesquisar
Fornecedor cadastrado?
Usuário informa os demaisdados do fornecedor e salv a.
Mensagem: Fornecedor cadastrado.Informe outra descrição
Fim
[Não]
[Sim]
[Nã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 CSU05 – Manter Fornecedor Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 6 de 6
act Diagrama de Ativ idade CSU05 - Alterar Fornecedor
Início
Usuário informa parte da descrição dofornecedor e seleciona pesquisar
Fornecedor cadastrado?
Sistema lista os fornecedores
Usuário seleciona um v alor e clica emok
Abre o formulário para alteração, o usuário informaos dados permitidos e clica em slv ar
Fim
[Sim]
[Não]
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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 6
Histórico da Revisão Data Versão Descrição Autor
26/11/2009 1.0 Versão inicial Soni
01/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 CSU03 – Manter Nota de Empenho do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 6
Índice Analítico 1. CSU06 – Manter Nota de Empenho do Material 4
1.1 Breve Descrição 4
2. Fluxo de Eventos 4 2.1 Fluxo Básico 4
2.1.1 Consultar Nota de Empenho do Material 4 2.2 Fluxos Alternativos 4
2.2.1 Incluir Nota de Empenho do Material 4 2.2.2 Alterar Nota de Empenho do Material 5
3. Pós-condições 6
SGPAT Versão: 1.0 CSU03 – Manter Nota de Empenho do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 6
1. CSU06 – Manter Nota de Empenho do Material
1.1 Breve Descrição 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
Usuário informa o número danota de empenho e clica em ok
Início
Empenho cadastrado?
Sistema emitemesnsagem que a nota
não foi cadastrada eretorna
Sistema lista.
Fim[Sim]
[Não]
Figura 1 - Diagrama de Atividade CSU06 - Consultar Nota de Empenho do Material 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 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 CSU03 – Manter Nota de Empenho do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 6
act Diagrama de Ativ idades CSU06 - Incluir Nota de Empenho do Material
Início
Usuário informa o número danota de empenho e clica em ok
Empenho cadastrado?
Usuário informa demais dados econfirma.
Sistema emite mensagem decadastro.
Sistema exibe mensagem que a notade empenho já esta cadastrada
Fim
[Sim]
[Não]
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 CSU03 – Manter Nota de Empenho do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 6 de 6
act Diagrama de Ativ idades CSU06 - Alterar Nota de Empenho do Material
Início
Usuário informa o número da nota deempenho e clica em ok
Empenho cadastrado?
Sistema emite mesnsagem que anota não foi cadastrada e retorna
Sistema lista a nota de empenhocom campos editáv eis
Usualrio altera os campos esalv a
Fim
[Sim]
[Não]
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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 6
Histórico da Revisão Data Versão Descrição Autor
26/11/2009 1.0 Versão inicial Soni
01/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 CSU07 – Manter Item do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 6
Índice Analítico 1. CSU07 - Manter Item do Material 4
1.1 Breve Descrição 4
2. Fluxo de Eventos 4 2.1 Fluxo Básico 4
2.1.1 Consultar Item do Material 4 2.2 Fluxos Alternativos 4
2.2.1 Incluir Item do Material 4 2.2.2 Alterar Item do Material 5
3. Pós-condições 6
SGPAT Versão: 1.0 CSU07 – Manter Item do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 6
1. CSU07 - Manter Item do Material
1.1 Breve Descrição 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
Início
Usuário informa númeroda nota de empnho e
confirmasistema lista
Fim
Figura 1 - Diagrama de Atividade CSU07 - Consultar Item do Material. 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 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 CSU07 – Manter Item do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 6
act Diagrama de Ativ idade CSU07 - Incluir Item do Material
Início
Usuárioinforma o númeroda nota de empenho e
verifica se o material foicadastrdo
Material cadastrado?
Usuário informa parte dadescrição e confirma
Cadastrado?
Sistema av isa que o itemjá esta cadastrado
Usuário informa dados econfirma
Tem erro
Sistema emite av iso deOK
sistema emite av iso deerro
Fim
[Sim]
[Não]
[Não][Sim]
[Sim]
[Não]
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 CSU07 – Manter Item do Material Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 6 de 6
act Diagrama de Ativ idade CSU07 - Alterar Item do Material
Início
Usuárioinforma o númeroda nota de empenho e
v erifica se o material foicadastrdo
Material cadastrado?
Usuário informa parte dadescrição e confirma
Cadastrado?
Sistema lista
Usuário seleciona umitem e confirma
Sistema abre o formuláriocom os campos
preenchidos permitindoedição dos permitidos
Tem erro
Fim
Fim
Sistema emite av iso deOK
sistema emite av iso deerro
[Sim]
[Não]
[Sim]
[Sim]
[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
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 2 de 5
Histórico da Revisão Data Versão Descrição Autor
26/11/2009 1.0 Versão inicial Soni
01/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 CSU08 – Patrimônio Disponível no Setor Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 3 de 5
Índice Analítico 1. CSU08 – Patrimônio Disponível no Setor 4
1.1 Breve Descrição 4
2. Fluxo de Eventos 4 2.1 Fluxo Básico 4
2.1.1 Consultar Patrimônio Disponível no Setor 4
3. Pós-condições 5
SGPAT Versão: 1.0 CSU08 – Patrimônio Disponível no Setor Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 4 de 5
1. CSU08 – Patrimônio Disponível no Setor
1.1 Breve Descrição 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 exibirpatrimônio
Usuário informa login esenha
Tem patrimônio so setor
Sistema exibe uma lista dematerial do setor
Sistema emite av iso: Não existematerial permanente no setor
Fim
[Não][Não]
Figura 1 - Diagrama de Atividade CSU05 - Consultar Patrimônio no Setor. Fonte: O Autor.
SGPAT Versão: 1.0 CSU08 – Patrimônio Disponível no Setor Data: 26/11/2009 AP – H
Confidencial © INTEGRAÇÃO DSW ME, 2010 Página 5 de 5
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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 10
Histórico da Revisão Data Versão Descrição Autor
28/04/2010 1.0 Versão inicial Soni
03/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 Documento de Arquitetura de Software Data: 28/04/2010 AP - I
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 10
Í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 Documento de Arquitetura de Software Data: 28/04/2010 AP - I
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 10
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 Documento de Arquitetura de Software Data: 28/04/2010 AP - I
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 10
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 Documento de Arquitetura de Software Data: 28/04/2010 AP - I
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 10
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 Documento de Arquitetura de Software Data: 28/04/2010 AP - I
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 10
analysis Realização
SCAB
+ RCSU01 - Manter grupo+ RCSU02 - Manter SIAFI+ RCSU03 - Manter Patrimônio+ RCSU04 - Manter a Descrição Complementar do Item do Material
SELCO
+ RCSU05 - Manter fornecedor
ALMOXARIFADO
+ RCSU06 - Manter Nota de Empenho do Material+ RCSU07 - Manter Item do Material
OUTROS SETORES
+ RCSU08 - Patromônio Disponivel no Setor
Pacotes da Realização dos Casos de Uso
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
RCSU01 - Manter grupo
+ RCSU01 - Manter Grupo
RCSU03 - Manter Patrimônio
+ RCSU03 - Manter Patimônio
RCSU02 - Manter SIAFI
+ RCSU02 - Manter SIAFI
RCSU04 - Manter a Descrição Complementar do Item do Material
+ CSU04 - Manter a Descrição Complementar do Material
Realização - SCAB
Figura 5 – Detalhamento da Realização de Casos de Uso do Setor SCAB.
SGPAT Versão: 1.0 Documento de Arquitetura de Software Data: 28/04/2010 AP - I
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 8 de 10
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
Colaborador SCAB
CtrlIncPatrimonio
PatrimonioFrmMenu
FrmAltPatrimonio CtrlAlterarPatrimonio
FrmListPatrimonioFrmFiltPatrimonio
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 Documento de Arquitetura de Software Data: 28/04/2010 AP - I
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 9 de 10
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 Documento de Arquitetura de Software Data: 28/04/2010 AP - I
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 10 de 10
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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 8
Histórico da Revisão Data Versão Descrição Autor
08/12/2009 1.0 Versão inicial Soni
15/04/2010 1.0 Atualização Soni
13/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 Guia de Design do Sistema Atual Data: 08/12/2009 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 8
Í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
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 Guia de Design do Sistema Atual Data: 08/12/2009 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 8
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
1.3 Definições, Acrônimos e Abreviações 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 Guia de Design do Sistema Atual Data: 08/12/2009 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 8
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 Guia de Design do Sistema Atual Data: 08/12/2009 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 8
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 Guia de Design do Sistema Atual Data: 08/12/2009 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 8
Figura 4 – Entrada de Material Permanente. Fonte: Adaptado de BRASIL (2009B) (Patrimônio (2009)).
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 Guia de Design do Sistema Atual Data: 08/12/2009 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 8 de 8
Figura 5 – Relacionamento fornecedores. Fonte: Adaptado de BRASIL (2009B) (Patrimônio (2009)).
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. Fonte: Adaptado de BRASIL (2009B) (Patrimônio (2009)).
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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 15
Histórico da Revisão Data Versão Descrição Autor
08/12/2009 1.0 Versão inicial Soni
15/04/2010 1.0 Versão inicial Soni
04/05/2010 1.0 Atualização Soni
13/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 15
Í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
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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 15
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.
1.3 Definições, Acrônimos e Abreviações 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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 15
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 NUM_ITEM_NE, ANO_NE e NUM_NE na 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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 15
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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 15
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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 8 de 15
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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 9 de 15
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 NUM_ITEM_NE, ANO_NE e NUM_NE na 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 assume um valor da chave associada**
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 assume um valor da chave associada**
LCT_DES_COMPL_FORN_PK = *permite a integridade dos campos NUM_ITEM_NE, ANO_NE e NUM_NE na tabela LCT_DES_COMPL_FORN, não permitindo valores duplicados**
SGPAT Versão: 1.0 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 10 de 15
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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 11 de 15
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 permitindo valores duplicados**
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 NUM_ITEM_NE, ANO_NE e NUM_NE na 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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 12 de 15
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 permitindo valores duplicados**
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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 13 de 15
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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 14 de 15
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 Guia de Design do Sistema Proposto Data: 08/12/2009 AP – K
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 15 de 15
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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 7
Histórico da Revisão Data Versão Descrição Autor
29/04/2010 1.0 Versão inicial Soni
03/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 RCSU01 - Manter grupo Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 7
Índice Analítico 1. Introdução 4
1.1 Definições, Acrônimos e Abreviações 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 RCSU01 - Manter grupo Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 7
Especificação de Realização de Casos de Uso: RCSU01 - Manter Grupo
1. Introdução Este documento apresenta a forma utilizada na realização do caso de uso Manter Grupo.
1.1 Definições, Acrônimos e Abreviações 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
FrmMenuColaborador SCAB
FrmIncGrupo
FrmListGrupoFrmFiltGrupo Grupo
CtrlIncGrupo
FrmAltGrupo CtrlAltGrupo
Manter grupo
Figura 1 – Diagrama de Comunicação Manter grupo. Fonte: O Autor.
SGPAT Versão: 1.0 RCSU01 - Manter grupo Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 7
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 SCABFrmIncGrupo GrupoCtrlIncGrupo FrmListGrupo
bc_incluirGrupo()
tx_descricao(String)
bc_listar()
Grupo()
descricao(String)
listar() :l ist
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 RCSU01 - Manter grupo Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 7
sd Alterar grupo
Colaborador SCABGrupoFrmAltGrupo CtrlAltGrupo FrmListGrupo
tx_descricao(String)
bc_listar()
Grupo()
descricao(String)
listar() :l ist
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 RCSU01 - Manter grupo Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 7
sd Listar grupo
Colaborador SCABGrupoFrmFiltGrupo FrmListGrupo
bc_listarGrupo()
tx_descricao(String)
bc_listar()
Grupo()
descricao(String)
listar() :l ist
Grupos listados()
Figura 4 – Diagrama de Sequência Listar Grupo. Fonte: O Autor.
231
L2 – RCSU02 – Manter Siafi
INTEGRAÇÃO DSW ME
SGPAT Especificação de Realização de Casos de Uso:
RCSU02 - Manter SIAFI
Versão 1.0
SGPAT Versão: 1.0 RCSU02 - Manter SIAFI Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 7
Histórico da Revisão Data Versão Descrição Autor
29/04/2010 1.0 Versão inicial Soni
03/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 RCSU02 - Manter SIAFI Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 7
Índice Analítico 1. Introdução 4
1.1 Definições, Acrônimos e Abreviações 4 1.2 Visão Geral 4
2. Fluxo de Eventos — Design 4
3. Diagrama de Comunicação 4
4. Diagrama de Sequência 4
SGPAT Versão: 1.0 RCSU02 - Manter SIAFI Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 7
Especificação de Realização de Casos de Uso: RCSU02 - Manter SIAFI
1. Introdução Este documento apresenta a forma utilizada na realização do caso de uso Manter SIAFI.
1.1 Definições, Acrônimos e Abreviações 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 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 A Figura 1, a seguir, representa o diagrama de comunicação para a realização do caso de uso Manter SIAFI.
sd RCSU02 - Manter SIAFI
Colaborador SCABFrmMenu Siafi
FrmIncSiafi CtrlIncSiafi
FrmAltSiaf CtrlAltSiafi
FrmFiltSiafi FrmListSiafi
Figura 1 – Diagrama de Comunicação Manter SIAFI. Fonte: O Autor.
4. Diagrama de Sequência A seguir os diagramas de sequência para o caso de uso citado. 1. Incluir SIAFI, este diagrama esta representado na Figura 2, a seguir.
SGPAT Versão: 1.0 RCSU02 - Manter SIAFI Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 7
sd Incluir SIAFI
Colaborador SCABSiafiFrmIncSiafi CtrlIncSiafi FrmListSiafi
bc_incluirSiafi()
tx_descricao(String)
bc_listar()
Siafi()
descricao(String)
l istar() :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 RCSU02 - Manter SIAFI Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 7
sd Alterar SIAFI
Colaborador SCABFrmAltSiaf SiafiCtrlAltSiafi FrmListSiafi
bc_alterarSiafi()
tx_descricao(String)
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 RCSU02 - Manter SIAFI Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 7
sd Listar SIAFI
Colaborador SCABFrmFiltSiafi FrmListSiafi Siafi
bc_listarSiafi()
tx_descricao(String)
bc_listar()
Siafi()
descricao(String)
listar() :List
Siafi l istado()
Figura 4 – Diagrama de Sequência Listar SIAFI. Fonte: O Autor.
239
L3 – RCSU03 – Manter Patrimônio
INTEGRAÇÃO DSW ME
SGPAT Especificação de Realização de Casos de Uso:
RCSU03 - Manter Patrimônio
Versão 1.0
SGPAT Versão: 1.0 RCSU03 - Manter Patrimônio Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 8
Histórico da Revisão Data Versão Descrição Autor
29/04/2010 1.0 Versão inicial Soni
03/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 RCSU03 - Manter Patrimônio Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 8
Índice Analítico 1. Introdução 4
1.1 Definições, Acrônimos e Abreviações 4 1.2 Visão Geral 4
2. Fluxo de Eventos — Design 4
3. Diagrama de Comunicação 4
4. Diagrama de Sequência 4
SGPAT Versão: 1.0 RCSU03 - Manter Patrimônio Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 8
Especificação de Realização de Casos de Uso: RCSU03 - Manter Patrimônio
1. Introdução Este documento apresenta a forma utilizada na realização do caso de uso Manter Patrimônio.
1.1 Definições, Acrônimos e Abreviações 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 restrito.
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.
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 Patrimônio.
sd RCSU03 - Manter Patrimônio
FrmIncPatrimonio
Colaborador SCAB
CtrlIncPatrimonio
PatrimonioFrmMenu
FrmAltPatrimonio CtrlAlterarPatrimonio
FrmListPatrimonioFrmFiltPatrimonio
Figura 1 – Diagrama de Comunicação Manter Patrimônio. Fonte: O Autor.
4. Diagrama de Sequência 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 RCSU03 - Manter Patrimônio Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 8
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 RCSU03 - Manter Patrimônio Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 8
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 RCSU03 - Manter Patrimônio Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 8
sd Listar Patrimônio
Colaborador SCABPatrimonioFrmFiltPatrimonio FrmListPatrimonio
bc_listarPatrimonio()
tx_tombamento()
bc_listar()
Patrimonio()
tombamento(int)
l istar() :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 SCABFrmFiltPatrimonio FrmListPatrimonio Patrimonio
bc_criarTermo()
tx_tombamento()
bc_listar()
Patrimonio()
tombamento(int)
l istar() :List
Termo criado()
Figura 5 – Diagrama de Sequência Criar Termo de Responsabilidade.
SGPAT Versão: 1.0 RCSU03 - Manter Patrimônio Data: 29/04/2010 AP - J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 8 de 8
Fonte: O Autor.
248
L4 – RCSU04 – Manter a Descrição Complementar do Item do Material
INTEGRAÇÃO DSW ME
SGPAT Especificação de Realização de Casos de Uso:
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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 7
Histórico da Revisão Data Versão Descrição Autor
29/04/2010 1.0 Versão inicial Soni
03/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 RCSU04 - Manter a Descrição Complementar do Item do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 7
Índice Analítico 1. Introdução 4
1.1 Definições, Acrônimos e Abreviações 4 1.2 Visão Geral 4
2. Fluxo de Eventos — Design 4
3. Diagrama de Comunicação 4
4. Diagrama de Sequência 4
SGPAT Versão: 1.0 RCSU04 - Manter a Descrição Complementar do Item do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 7
Especificação de Realização de Casos de Uso: 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.1 Definições, Acrônimos e Abreviações 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 restrito.
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.
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 Descrição Complementar do Item do Material.
sd CSU04 - Manter a Descrição Complementar do Material
Colaborador SCABFrmMenu FrmFiltDesCompItemMaterial FrmListDesCompItemMaterial DesCompItemMaterial
FrmIncDesCompItemMaterial CtrlIncDesCompItemMaterial
FrmAltDesCompItemMaterial CtrlAltDesCompItemMaterial
Figura 1 – Diagrama de Comunicação Manter Descrição Complementar do Item do Material. Fonte: O Autor.
4. Diagrama de Sequência A seguir os diagramas de sequência para o caso de uso citado. 1. Incluir Descrição Complementar do Item do Material, este diagrama está representado pela Figura 2, a seguir.
SGPAT Versão: 1.0 RCSU04 - Manter a Descrição Complementar do Item do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 7
sd Incluir Descrição Complementar do Material
Colaborador SCABFrmIncDesCompItemMaterial CtrlIncDesCompItemMaterial DesCompItemMaterial FrmListDesCompItemMaterial
1 - Pesquisar item do material
bc_incDesCompItemMaterial()
tx_descricao(String)
bc_listar()
DesCompItemMaterial()
l istar() :List
descricao(String)
Descrição Complementar do Item do Material não encontrado pode incluir()
DesCompItemMaterial()
incluir()
incluir() :boolean
Descrição Complementar do Item do Material incluido()
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 RCSU04 - Manter a Descrição Complementar do Item do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 7
sd Alterar Descrição Complementar do Material
Colaborador SCABFrmAltDesCompItemMaterial CtrlAltDesCompItemMaterial DesCompItemMaterial FrmListDesCompItemMaterial
1 - Pesquisar item do material
bc_altDesCompItemMaterial()
tx_descricao(String)
bc_listar()
DesCompItemMaterial()
descricao(String)
l istar() :List
Lista de DescriçãoComplementar doItem do Material ()
DesCompItemMaterial()
alterar()
alterar() :boolean
Descrição Complementar do Item do Material alterada()
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 RCSU04 - Manter a Descrição Complementar do Item do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 7
sd Listar Descrição Complementar do Material
Colaborador SCABFrmFiltDesCompItemMaterial FrmListDesCompItemMaterial DesCompItemMaterial
bc_listarDesCompItemMaterial()
tx_descricao(String)
bc_listar()
DesCompItemMaterial()
descricao(String)
l istar() :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 Especificação de Realização de Casos de Uso:
RCSU05 - Manter Fornecedor
Versão 1.0
SGPAT Versão: 1.0 RCSU05 - Manter Fornecedor Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 7
Histórico da Revisão Data Versão Descrição Autor
29/04/2010 1.0 Versão inicial Soni
03/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 RCSU05 - Manter Fornecedor Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 7
Índice Analítico 1. Introdução 4
1.1 Definições, Acrônimos e Abreviações 4 1.2 Visão Geral 4
2. Fluxo de Eventos — Design 4
3. Diagrama de Comunicação 4
4. Diagrama de Sequência 4
SGPAT Versão: 1.0 RCSU05 - Manter Fornecedor Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 7
Especificação de Realização de Casos de Uso: RCSU05 - Manter Fornecedor
1. Introdução Este documento apresenta a forma utilizada na realização do caso de uso Manter Fornecedor.
1.1 Definições, Acrônimos e Abreviações 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 restrito.
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.
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 Fornecedor.
sd RCSU05 - Manter Fornecedor
Colaborador SELCO
Fornecedor
FrmIncFornecedor CrtlIncFornecedor
FrmAltFornecedor CtrlAltFornecedor
FrmMenu FrmFiltFornecedor FrmListFornecedor
Figura 1 – Diagrama de Comunicação Manter Fornecedor. Fonte: O Autor.
4. Diagrama de Sequência A seguir os diagramas de sequência para o caso de uso citado. 1. Incluir Fornecedor, este diagrama está representado por intermédio da Figura 2, a seguir.
SGPAT Versão: 1.0 RCSU05 - Manter Fornecedor Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 7
sd Incluir fornecedor
Colaborador SELCOFornecedorFrmIncFornecedor CrtlIncFornecedor FrmListFornecedor
bc_incluirFornecedor()
tx_descricao(String)
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 RCSU05 - Manter Fornecedor Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 7
sd Alterar fornecedor
Colaborador SCABFornecedorFrmAltFornecedor CtrlAltFornecedor FrmListFornecedor
bc_alterarFornecedor()
tx_descricao(String)
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 RCSU05 - Manter Fornecedor Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 7
sd Listar fornecedor
Colaborador SCABFornecedorFrmFiltFornecedor FrmListFornecedor
bc_listarFornecedor()
tx_descricao(String)
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 Especificação de Realização de Casos de Uso: 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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 7
Histórico da Revisão Data Versão Descrição Autor
29/04/2010 1.0 Versão inicial Soni
03/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 RCSU06 - Manter Nota de Empenho do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 7
Índice Analítico 1. Introdução 4
1.1 Definições, Acrônimos e Abreviações 4 1.2 Visão Geral 4
2. Fluxo de Eventos — Design 4
3. Diagrama de Comunicação 4
4. Diagrama de Sequência 4
SGPAT Versão: 1.0 RCSU06 - Manter Nota de Empenho do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 7
Especificação de Realização de Casos de Uso: 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.1 Definições, Acrônimos e Abreviações 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 restrito.
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.
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 Nota de Empenho do Material.
sd RCSU06 - Manter Nota de Empenho do Material
Colaborador Almoxarifado
FrmMenu NeMaterial
FrmIncNeMaterial CtrlIncNeMaterial
FrmAltNeMaterial CtrlAltNeMaterial
FrmFiltNeMaterial FrmListNeMaterial
Figura 1 – Diagrama de Comunicação Manter Nota de Empenho do Material. Fonte: O Autor.
4. Diagrama de Sequência A seguir os diagramas de sequência para o caso de uso citado. 1. Incluir Nota de Empenho do Material, este diagrama está representado por intermédio da Figura 2, a seguir.
SGPAT Versão: 1.0 RCSU06 - Manter Nota de Empenho do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 7
sd Incluir Nota de Empenho do Material
Colaborador AlmoxarifadoNeMaterialFrmIncNeMaterial CtrlIncNeMaterial FrmListNeMaterial
1 - Pesquisar fornecedor
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()
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 RCSU06 - Manter Nota de Empenho do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 7
sd Alterar Nota de Empenho do Material
Colaborador AlmoxarifadoNeMaterialFrmAltNeMaterial CtrlAltNeMaterial FrmListNeMaterial
1 - Pesquisar fornecedor
bc_alterarNeMaterial()
tx_numNe(String)
bc_listar()
NeMaterial()
numNe(int)
l istar(List)
Dados da nota de empenho do material()
NeMaterial()
alterar()
alterar() :boolean
Nota de Empenho do Material alterado()
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 RCSU06 - Manter Nota de Empenho do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 7
sd Listar Nota de Empenho do Material
Colaborador AlmoxarifadoNeMaterialFrmFiltNeMaterial FrmListNeMaterial
bc_listarNeMaterial()
tx_numNe(String)
bc_listar()
NeMaterial()
numNe(int)
l istar(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 Especificação de Realização de Casos de Uso:
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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 7
Histórico da Revisão Data Versão Descrição Autor
29/04/2010 1.0 Versão inicial Soni
03/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 RCSU07 - Manter Item do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 7
Índice Analítico 1. Introdução 4
1.1 Definições, Acrônimos e Abreviações 4 1.2 Visão Geral 4
2. Fluxo de Eventos — Design 4
3. Diagrama de Comunicação 4
4. Diagrama de Sequência 4
SGPAT Versão: 1.0 RCSU07 - Manter Item do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 7
Especificação de Realização de Casos de Uso: 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.1 Definições, Acrônimos e Abreviações 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 Almoxarifado pode consultar um determinado item do material, na falta do mesmo poderá inserir no sistema ou ainda atualizar.
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 Item do Material.
sd RCSU07 - Manter Item do Material
FrmMenuColaborador Almoxarifado
FrmFiltItemMaterial ItemMaterialFrmListItemMaterial
FrmAltItemMaterial
FrmIncItemMaterial CtrlIncItemMaterial
CtrlAltItemMaterial
Figura 1 – Diagrama de Comunicação Manter Item do Material. Fonte: O autor.
4. Diagrama de Sequência A seguir os diagramas de sequência para o caso de uso citado.
SGPAT Versão: 1.0 RCSU07 - Manter Item do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 7
1. Incluir Item do Material, este diagrama está representado por intermédio da Figura 2, a seguir. sd Incluir Item do Material
Colaborador AlmoxarifadoFrmIncItemMaterial 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 RCSU07 - Manter Item do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 6 de 7
sd Alterar Item do Material
Colaborador AlmoxarifadoFrmAltItemMaterial CtrlAltItemMaterial ItemMaterial FrmListItemMaterial
bc_AlterarItemMaterial()
tx_descricao()
bc_listar()
ItemMaterial()
descricao(String)
l istar()
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 RCSU07 - Manter Item do Material Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 7 de 7
sd Listar Item do Material
Colaborador AlmoxarifadoFrmFiltItemMaterial 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 Especificação de Realização de Casos de Uso:
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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 5
Histórico da Revisão Data Versão Descrição Autor
29/04/2010 1.0 Versão inicial Soni
03/05/2010 1.0 Atualização Soni
SGPAT Versão: 1.0 Patrimônio Disponível no Setor Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 5
Índice Analítico 1. Introdução 4
1.1 Definições, Acrônimos e Abreviações 4 1.2 Visão Geral 4
2. Fluxo de Eventos — Design 4
3. Diagrama de Comunicação 4
4. Diagrama de Sequência 4
SGPAT Versão: 1.0 Patrimônio Disponível no Setor Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 5
Especificação de Realização de Casos de Uso: 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.1 Definições, Acrônimos e Abreviações 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.
Os colaboradores podem consultar os materiais permanentes disponíveis no setor.
3. Diagrama de Comunicação 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
FrmFiltPatrimonioFrmMenu
(from Realização)Outros Colaboradores
(from Atores)
FrmListPatrimonio Patrimonio
Figura 1 – Diagrama de Comunicação Patrimônio Disponível no Setor. Fonte: O autor.
4. Diagrama de Sequência 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 Patrimônio Disponível no Setor Data: 29/04/2010 AP – J
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 5 de 5
sd Verificar Patromônio Disponiv el no Setor
Outros ColaboradoresFrmFiltPatrimonio FrmListPatrimonio Patrimonio
bc_verificarPatrimonioSetor()
bc_listar()
Patrimonio()
l istar() :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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 4
Histórico da Revisão Data Versão Descrição Autor
29/04/2010 1.0 Versão inicial Soni
SGPAT Versão: 1.0 Guia de Teste Data: 29/04/2010 AP – M
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 4
Índice Analítico 1. Introdução 4
1.1 Finalidade 4 1.2 Definições, Acrônimos e Abreviações 4
2. Metas do Teste 4
3. Medidas-chave 4
4. Critérios de Conclusão do Teste 4
SGPAT Versão: 1.0 Guia de Teste Data: 29/04/2010 AP – M
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 4
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.
1.2 Definições, Acrônimos e Abreviações 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
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 2 de 4
Histórico da Revisão Data Versão Descrição Autor
29/04/2010 1.0 Versão inicial Soni
SGPAT Versão: 1.0 Plano de Implantação Data: 29/04/2010 AP – N
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 3 de 4
Índice Analítico 1. Introdução 4
1.1 Definições, Acrônimos e Abreviações 4
2. Planejamento de Implantação 4 2.1.1 Software de Suporte 4
3. Treinamento 4
SGPAT Versão: 1.0 Plano de Implantação Data: 29/04/2010 AP – N
Confidencial ©INTEGRAÇÃO DSW ME, 2010 Página 4 de 4
Plano de Implantação 1. Introdução O presente documento tem como objetivo descrever como o será realizada a implantação do sistema.
1.1 Definições, Acrônimos e Abreviações 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.
