4.1 CUSTOMIZAÇÃO DO IBM RUP
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
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
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.
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.
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).
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 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).
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.