Objetivo
Conceiturar sistemas legados, tecnologias atuais para manter sistemas críticos em produção, estendendo o seu ciclo de vida, integrado-os a novos sistemas e tecnologias. E a importância desses sistemas para as organiações, tanto de ponto de vista estratégico quanto do econômico, o desenvovimento de técnicas e tecnologias para a sua integração aos novos sistemas. Um pequeno estudo de caso é apresentado, demostrando uma das abordagens para integração.
1. INTRODIÇÃO
Escolher e executar adequadamente processos de desenvolvimento de software, são aspectos fundamentais para desenvolver produtos de software de qualidade.
A Engenharia de Requisitos tem surgido para melhorar o processo de desenvolvimento de software em um dos pontos cruciais para a obtenção de um produto de qualidade: a correta elicitação, análise, especificação e validação de requisitos. É de consenso tanto da comunidade acadêmica quanto industrial que um produto de software de qualidade é aquele que é capaz de atender os requisitos funcionais e não-funcionais dos respectivos usuários.
Assim, verifica-se, que a qualidade de um produto de software é
fortemente influenciada pela qualidade do processo utilizado. Melhorar o processo de desenvolvimento é um aspecto fundamental para a melhoria da qualidade do produto.
Fornecer software de qualidade não é apenas uma questão de funcionalidade visual. É necessário atentar para a documentação do mesmo, a facilidade para rastrear e avaliar impactos de mudanças nos requisitos, verificar a satisfação dos requisitos não funcionais, entre outros aspectos críticos. Este sentimento é também expresso em, no qual são identificados os problemas mais comuns em projetos de software como falhas na elicitação e análise de requisitos e impossibilidade completa de manutenção, devido principalmente à falta ou inadequada documentação.
Estes problemas agravam-se, em muitos casos, desenvolvedores de software, nos quais há a necessidade de atualizar e/ou reconstruir sistemas legados, juntamente com a difícil tarefa de evoluir de metodologias tradicionais tais como abordagem estruturada atuais, como o Processo Unificado. As dificuldades neste processo são inúmeras. É importante considerar todas as informações úteis e que possam ser aproveitadas a partir da documentação existente do sistema legado. Um conjunto de diretrizes que visam facilitar o processo de transição em sistemas legados, que permitem mapear importantes informações em Diagramas de Fluxos de dados (DFDs) para Casos de uso em UML.
Desta forma, inicialmente, os principais processos e metodos de desenvolvimento de software existentes atualmente. Propõe-se um conjunto de evolução natural que muitas empresas se defrontam em relação à transição do uso de métodos tradicionais estruturados para o uso de metodos e processos orientados a objetos. É apresentando um conjunto de diretrizes para auxiliar engenheiros de requisitos na transição do uso de metodos.
2. Desenvolvimento de Sistemas
Independente do metodo escolhida para a construção de um produto de software, a mesma deve possuir uma semântica bem-definida, de modo que, qualquer outro desenvolvedor possa interpretar e ser capaz de entender os propósitos do sistema sem ambigüidades.
Deve também propiciar e nortear o desenvolvimento de forma que o
produto final de software possua características fundamentais relacionadas a
qualidade do produto em si.
Ao definirmos os termos da abordagem de cada um, sem contar que a experiência do analista é fator primordial para o sucesso de qualquer análise. Muitas suposições são feitas quando tratamos a respeito de seus benefícios e vantagens em relação a outras já existentes. O que se observa na prática, é uma constante evolução decorrente de experiências pessoais de um grupo de pessoas. Essa evolução tem levado a criação de abordagens de desenvolvimento de software mais eficientes, bem definidas e preocupadas em integrar efetivamente com os usuários no processo de desenvolvimento de software, e de forma mais critica, no processo de engenharia de requisitos. Busca-se também desenvolver softwares mais coesos, de fácil gerenciamento, passíveis de certificação e com um custo menor.
3. O Processo de Transição em Sistemas Legados
Muitas são as contribuições relacionadas a atualização de sistemas legados em relação a uma nova metodologia.
Sistemas legados possuem lógica de programação, decisões de projeto,
requisitos de usuário e regras de negócio, que podem ser recuperados, facilitando sua reconstrução, sem perda da semântica. Assim, abandoná-los e começar o projeto do zero seria uma perda considerável.
Nas próximas seções apontaremos decisivas para realizar a transição, visando melhorar / atualizar os sistemas legados.
3.1 Treinamento de Pessoal
Este treinamento requer que a equipe que irá realizar esta difícil tarefa, tenha algumas qualidades que julgamos serem essenciais:
a) Conhecimento da nova metodologia( RUP, na maioria dos casos);
b) Conhecimento de ferramentas CASE que facilitem o trabalho de migração;
c) Excelente ambiente de trabalho, não só em relação ao grau de relacionamento do grupo como também em relação a um local apropriado para o desenvolvimento do trabalho, sem precisar dividir o ambiente de trabalho com várias pessoas de setores diferentes, por exemplo.
Estas qualidades são fundamentais para que o processo de migração seja mais efetivo e produtivo.
3.2 Organização da Base de Informações
A organização da base de informações é decisiva para facilitar a engenharia reversa de um sistema legado utilizanda. As seguintes situações podem ser observadas:
a) Um sistema sem documentação neste caso, estão disponíveis apenas as informações do código fonte do sistema;
b) Um sistema com documentação atualizada Neste caso, documentação em ordem, o processo é facilitado, uma vez que podemos verificar a análise efetuada anteriormente e as atualizações que se tornaram necessárias com o passar dos anos. Temos um histórico completo do sistema, simplificando a organização.
c) Um sistema com uma documentação não atualizada Nesta situação bastante comum, as equipes mal tiveram tempo de realizar as atualizações nos códigos fontes do sistema. Normalmente, as equipes que trabalham no sistema não foram as mesmas que o desenvolveram.
As situações acima, devemos ter em mente que a equipe que irá realizar a tarefa de evolução de sistemas legados, não será a mesma que o desenvolveu. Assim, precisamos nos basear em alguns pontos cruciais para o desenvolvimento do projeto, conforme segue:
Deve-se integrar efetivamente, o usuário/cliente no processo de desenvolvimento.
A integração e interação constante de usuário/cliente durante todo o processo de transição do uso e modificando e reconstruindo sistemas legados
é ponto decisivo para o sucesso do processo.
Deve-se considerar efetivamente os requisitos que o sistema deve atender (ou
requisitos verdadeiros). Os requisitos do sistema são o que o sistema produz ou emite em forma de relatórios e consultas visuais em tela para os respectivos
usuários. O que o sistema produz justifica a sua existência e a sua essência.
Preocupar-se com a satisfação dos requisitos de clientes e usuários é uma questão chave no processo de transição adotado.
Para compreendermos melhor este processo, tomemos como base os três tipos diferentes de situações apresentadas em relação a sistemas legados (baseados na documentação existente) e suas respectivas ações a serem desenvolvido.
A transição da Análise essencial ou estruturada Orientada a Objetos, como RUP. Cabe ressaltar que os metodos orientadas a objetos consideram os casos de uso como elementos chaves e essenciais no processo de desenvolvimento.
Sistemas Legados, Situação da Documentação, Inexistente Precária, Atualizada Análise Estruturada/Análise Essencial Implementado na Análise Estruturada Fases:
1 Realizar a Conversão de DFDs em Casos de Uso;
2 Analisar E/S do Sistema;
3 Validar com os Stakeholders as E/S;
4 Organizar Casos de Uso.
Implementados na Análise Essencial Fases:
1- Analisar código fonte do Sistema;
2- Analisar E/S do Sistema;
3- Validar com os Stakeholders as E/S;
Fases:
1 Atualizar DFDs - Analisar DFDs existentes e compará-los com a análise efetuada no código fonte;
2 Realizar a Conversão de DFDs em Casos de Uso;
3 Analisar E/S do Sistema;
4 Validar com os Stakeholders as E/S;
5 Organizar Casos de Uso
Fases:
1 Analisar Diagrama de Contexto;
2 Realizar a Conversão de DFDs em Casos de Uso;
3 Analisar E/S do Sistema;
4 Validar Stakeholders apontados na Fase 1 e as E/S apontadas na Fase 3.
5 Organizar Casos de Uso.
Passos a serem seguidos na realização de engenharia reversa em sistemas legados.
Na análises e comparações a serem efetuadas em sistemas legados considerando a documentação existente.
Relatos apontam para o consenso de que a análise do código fonte e sua organização, auxilia o engenheiro de software a remodelar o sistema sob o enfoque orientado a objetos. Contudo, pouca atenção se dá as outras possibilidades de uso de informações, como por exemplo, o mapeamento de modelos e diagramas que representam, tipicamente, os aspectos essenciais de um sistema. Desta forma, pode-se enriquecer a coleta de informações
necessária a atualização/reconstrução de sistemas legados. podem efetivamente ser mapeados para casos de uso em UML, facilitando o trabalho de transição.
A seguir apresentamos um conjunto de diretrizes que permitem mapear Diagramas de Fluxos de Dados para casos de uso em UML. As diretrizes a serem propostas podem ser aplicadas para mapear elementos de metodologias tradicionais (Estruturada ou Essencial), para o Processo Unificado, uma vez que nosso principal enfoque será obter os casos de uso referentes ao sistema, os quais são elementos chaves nos dois processos orientados a objetos.
3.3 Mapeando elementos de Diagramas de Fluxos de Dados para Casos de Uso em UML. Um dos maiores problemas atuais no desenvolvimento de software está relacionado ao processo de transição. Atualmente, muitas organizações são
obrigadas a mudar seus sistemas computacionais utilizando novas abordagens de
desenvolvimento, as quais apresentam algumas vantagens tais como: maior flexibilidade, suporte automatizado para todo o processo de desenvolvimento, etapas e artefatos bem definidos, bem como possibilidade de uso efetivo do paradigma orientado a objetos. Contudo, na maioria das situações, existem informações importantes nos sistemas legados que devem ser mapeadas para novos artefatos gerados no uso de novas metodologias.
Neste contexto, verificamos que tipicamente Diagramas de Fluxos de Dados
desenvolvidos utilizando metodologias tradicionais precisam ser mapeados de forma mais efetiva e sistemática para a técnica de casos de uso. É importante ressaltar que casos de uso fazem parte da UML e são considerados essenciais na maioria dos processos de desenvolvimento orientados a objetos atualmente utilizados.
Não é correto assumir que apenas o código fonte em sistemas legados é suficiente para elicitar e documentar todos os requisitos essenciais de sistemas computacionais objetos de transição e evolução. É necessário atentar para toda documentação disponível que possa auxiliar na transição e evolução de sistemas de software.
O foco das diretrizes está no mapeamento de Diagramas de Fluxos de Dados
para Casos de Uso em UML. Após a descrição das diretrizes, apresentamos uma
tabela que mostra a aplicabilidade das diretrizes para cada situação, tomando como base a documentação disponível dos sistemas legados.
Estas diretrizes são dependentes exclusivamente da situação documental disponível, podendo ser aplicadas, dependendo da situação da
documentação do software legado. Situação da Documentação Existente Diretrizes a serem implementadas
Uso das diretrizes propostas de acordo com a situação documental disponível.
a) A Análise do Diagrama de Contexto - Esta diretriz tem por objetivo relacionar as entidades externas como prováveis atores do sistema legados. Nessa diretriz todas as entidades externas serão relacionadas como possíveis atores do sistema. A análise do diagrama de contexto.
b) Conversão do Diagrama de Fluxo de Dados para Diagrama de
Casos de Uso
b.1) Para cada nível do sistema legado será elaborado um Caso de Uso, como
b.2) Analisar a especificação do processo. Caso não possua Entidade Externa, ele é o resultado de um outro processo anterior que o originou. Neste caso, deve ser definido apenas como um Entidades Externas que serão prováveis
atores do sistema:
- Cliente
- Atendente
- Gerente
Sistema de Controle de Locadora Cliente Atendente Gerente Fluxos de entrada/saída são mapeados para especificação do caso de uso pré e póscondições Entidade Externa é mapeada para ator no diagrama de casos de uso O processo, é mapeado para Caso de uso e o Português estruturado deste processo é mapeado para a especificação do caso de uso do tipo <> ou <> , o qual será chamado em outro caso de uso. Devemos ter o cuidado de validá-lo com o DFD que o chamou, e assim incluí-lo no processo de conversão
3). Normalmente, a especificação do processo indica quais são os passos necessários para se atingir um determinado objetivo. Deste modo, pode-se a partir da especificação do processo analisado já incluir no caso de uso correspondente as colaborações e generalizações indicadas. A Conversão para caso de uso especial. Análise e conversão da especificação do processo Validar Cliente.
Fonte: Código do Português Estruturado.
b.3) Analisar os fluxos de entrada e saída, bem como a especificação do processo. Este passo é importante para validar os depósitos de dados identificados
4) O caso de uso Validar Cliente é descrito com base nas informações contidas na especificação do processo. Definimos o objetivo do caso de uso analisado, sua prioridade, indicando se sua execução é essencial ao sistema, as pré-condições existentes para sua execução, as pós-condições após a sua execução e o cenário principal juntamente com os fluxos secundários, indicando alternativas de execução. Descreve-se também os caso de uso pai e subordinados, os quais são detectados no decorrer da conversão.
No passo 1 do cenário principal (O caso de uso inicia Quando DeptVendas requer avalidação do cliente) devemos indicar o responsável pela execução do mesmo.
Apesar da especificação do processo não indicar o ator, possui como
Entidade Externa o DeptVendas, logo, ele é incluído como ator do Caso de Uso. Criar cliente Novo outros passos é realizada uma referência a especificação do processo, como por exemplo, em Se cliente encontrado, que foi representado pelo
passo 2 O sistema verifica a existência do cliente. Os fluxos de exceção são tratados pelos casos de uso secundários (include ou extend), associados ao caso de uso principal Validar Cliente. Caso de Uso Validar Cliente Objetivo Este caso de uso descreve o procedimento para que um cliente seja validado de acordo com sua situação decorrente do crédito Prioridade ( x )Essencial ( ) Secundário Pré-Condições Dados do cliente e Pedido do cliente incluído. Pós-Condições Pedido do Cliente Processado. Cenário Principal
1. O caso de uso inicia Quando DeptVendas requer a validação do cliente;
2. O sistema verifica existência do cliente (caso de uso checar cliente é incluído);
3. O sistema verifica o crédito do cliente (caso de uso checar crédito é incluído);
4. O sistema reune todos os pedidos do cliente (caso de uso reunir pedidos é incluído);
5. O sistema cadastra todos os pedidos do cliente (caso de uso criar pedido cliente é incluído).
Fluxos Secundários Caso de Uso Pai Caso de Uso Subordinado Checar cliente Checar crédito Reunir pedidos Criar pedido Tabela 4. Especificação do Caso de Uso.
c) Organização das Entradas e Saídas do Sistema esta diretriz tem por objetivo relacionar e validar as entradas e saídas do sistema. Este passo requer o auxílio da equipe ou responsável pela manutenção do sistema, que indicará para cada entrada (em tela) e saída (relatório existente) o usuário responsável pela informação.
Deste modo, o engenheiro de software terá uma relação de todos os atores (stakeholders) que são afetados.
d) Validação dos Stakeholders esta diretriz tem por objetivo validar os
stakeholders apontados. Deste modo, o engenheiro de software deve
comparar com os atores já identificados e realizar as alterações
necessárias nos casos de uso identificados.
e) Organizar Casos de Uso esta diretriz tem por objetivo organizar os diagramas de caso de uso de acordo com as notações propostas pela UML. Casos de uso devem ser agrupados em pacotes ou pela especificação de relacionamentos de generalização, inclusão e extensão, existentes entre os mesmos.
4. Principais Dificuldades Presentes no Processo de Transição
A experiência já ditava regras desde a Análise Estruturada, uma vez que apenas os analistas experientes tinham conhecimento para discernir o lógico do físico, pois os poucos que conseguiam aprender a fazer esta distinção, não tinham sucesso em passar esta aptidão aos colegas.
Na prática, o que verificamos é que, com pouquíssimas exceções, as pessoas não
conseguem aprender uma nova metodologia de desenvolvimento com tanta facilidade.
Para muitos analistas, uso do RUP envolve diversas dificuldades técnicas e de origem pessoal. A realidade de nossas empresas, tanto privadas, quanto estatais ou do governo, como é o caso do Exército Brasileiro, está começando a mudar. A experiência de um dos autores do presente artigo no Exército Brasileiro mostra que grupos de desenvolvimento de sistemas de Brasília, Capital Federal, se encontram num dilema entre a transição, pois ainda utilizam a Análise Estruturada.
A transição tem se mostrado lenta e gradual buscando um só objetivo: o desenvolvimento e migração de sistemas existentes e a desenvolver. São fruto da experiência de desenvolvimento dos autores, bem como das dificuldades encontradas no âmbito da análise de sistemas do Exército Brasileiro.
5. Considerações Finais e Trabalhos Futuros
Apresentamos, inicialmente, um relato das principais de desenvolvimento de sistemas existentes, buscando facilitar o estudo dos fatores envolvidos no processo de migração de projetos elaborados através da Análise Estruturada ou a Análise Essencial para projetos elaborados utilizando processos Orientadas a Objeto.
Com base neste estudo, propomos um conjunto para auxiliar
engenheiros de software/requisitos no processo de transição entre metodologias
tradicionais e orientadas a objetos. Basicamente, propõe-se de forma sistemática,
mapear as informações existentes na documentação do processo tradicional para o processo de desenvolvimento orientado a objetos. Apoiamo-nos no fato de que as informações presentes que podem auxiliar o processo de construção e descrição de casos de uso em UML. Defende-se a idéia de que as diretrizes propostas devem ser aplicadas de acordo com a documentação disponível em relação aos sistemas legados sendo tratados.
Verificamos neste trabalho que o processo de transição de abordagens de
desenvolvimento tradicionais para as utilizadas na orientação a objetos implica,
inicialmente, em uma mudança de cultura bastante complexa dentro da empresa.
Consideramos também que outros aspectos importantes tais como rastreamento de requisitos, modelagem organizacional e tratamento de requisitos não-funcionais, não considerados na análise estruturada e essencial de sistemas, devem ser inseridos gradualmente na equipe de desenvolvimento aumentando progressivamente o grau de maturidade dessas organizações.
a) Associar a modelagem organizacional com a modelagem funcional da empresa
com base na documentação existente dos sistemas legados;
b) Desenvolver uma ferramenta que suporte a conversão do DFDs para Casos de Uso usando as propostas, pois como já mencionamos, a técnica de
casos de uso é chave na UML, bem como nos principais processos de
desenvolvimento Orientado a Objetos.
6. Conclusão
Sistema legado é o termo utilizado em referência aos sistemas computacionais de uma organização que, apesar de serem bastante antigos, fornecem serviços essenciais. Geralmente utilizam bancos de dados obsoletos.
Normalmente são aplicações complexas, de difícil manutenção e que pelo grau de criticidade e custo para modernização, continuam ativas.
Por falta de documentação e com a saída do pessoal técnico que participou originalmente no seu desenvolvimento os sistemas legados podem apresentar problemas como: dificuldade de compreensão das regras de negócio neles implementadas, desconhecimento das razões que levaram a determinadas decisões, problemas na estruturação dos módulos de código, miscelânea de estilos de programação, obsolescência das ferramentas de desenvolvimento e impossibilidade de eaproveitamento dos equipamentos nos quais são executados para execução de softwares mais atuais.
7. Referências Bibliográficas
Filho, T. L. Metodologia de Desenvolvimento de Sistemas , Axcel Books, Rio de Janeiro,2003.
Scott, Kendall. O Processo Unificado Explicado . Bookman,, Porto Alegre,2003
Chung, L.; Nixon, B.; Yu,Eric;Mylopoulos,John. Non-Functional requirements in Software engineering , USA: Kluwer Academic Publishers, 2000,439p.
Booch, G.; Rumbaugh, J., Jacobson, I. The Unified Modeling Language, Addison- Wesley,1999.
Shlaer,S.; Mellor,S. Análise de Sistemas Orientada para Objetos , Makron Books, São Paulo,1990. Gane, C.; Sarson,Trish. Structured Systems Analysis , New York, Improved System Technologies, 1977. Jacobson, I.; Booch, G.; Rumbaugh, J. The Unified Software Development Process , Addison-Wesley (1999).
D Souza, D. and A.Wills. Objects, Components and Frameworks with UML: The
Catalysis Approach , USA: Addison-Wesley, (1995). ISO International Standard Organization. ISSO 9000 Quality Management system. 1.ed.
Geneva: ISSO 2000. McMenamin, S.; Palmer,J. F. Análise Essencial de Sistemas, Makron Books, São Paulo,1984. Toranzo, Marco A., Uma Proposta para Melhorar o Rastreamento de Requisitos de Software , Centro de Informática, Universidade Federal de Pernambuco, Tese de Doutorado, Dezembro, (2002).
Fukuda, A. P. Refinamento Automático de sistemas Orientados a Objetos Distruidos São Carlos/SP, 2000. Dissertação de Mestrado. Universidade Federal de São Carlos Fontanete,V. et al. Reengenharia de Sistemas Legados Baseada em Componentes usando Transformações . São Carlos/SP,2003. Artigo. Universidade Federal de São Carlos. Jesus,E.S. Engenharia Reversa de Sistemas Legados Usando Transformações . São Carlos/SP, 2002, Dissertação de Mestrado, Universidade Federal de São Carlos. Werner, C.M.L.; Braga, R. M.M. Desenvolvimento Baseado em Componentes . XIV Simpósio Brasileiro de Engenharia de Software SBES2000 Minicursos e Tutoriais pg. 297- 329 2-6 de Outubro, 2000. Jesus, E. S. Engenharia Reversa de Sistemas Legados Usando Transformações , 2000 - Dissertação de Mestrado, Ciências da Computação, UFSCAR. Chikofsky, E. Reverse Engineering and Design Recovery A Taxonomy . IEEE Software Santander, Victor F.A. Integração de Modelagem Organizacional com Modelagem Funcional na Engenharia de Requisitos . Centro de Informática, Universidade Federal de Pernambuco, Tese de Doutorado, Dezembro, (2003).
