Resumo: Sistemas Web são alterados com dinamismo crescente devido ao alcance dos clientes a um baixo custo, o que acarreta em uma grande demanda de ofertas de produtos e serviços, gerando constantes manutenções nesse tipo de software. O objetivo desse estudo é apresentar a utilização da visão dinâmica da IHC, como uma ferramenta de apoio no processo de Manutenção de Software auxiliando nas tarefas de: definição do escopo, identificação de impactos e na definição de procedimentos de qualidade. Esse estudo foi analisado em projetos de manutenção de um sistema web financeiro, onde se destacaram os pontos positivos e as dificuldades vivenciadas.
Palavras-chave: Interface Homem-Computador; Arquitetura de Software; Gestão de Projetos de Manutenção de Softwares; Web Sites; Qualidade.

Abstract: Web systems change so rapidly because they can be reached by users at low cost, what creates a huge demand for products and services, so frequently maintenance is required for this kind of software. This paper presents the utilization of HCI dynamic vision as a tool for supporting the software maintenance process and the activities of scope definition, impact identification and quality procedure definition. This article also presents the application of this approach to the maintenance of financial/banking internet projects and discusses its strengths and weakness.
Key words: Human-Computer Interaction; Software Architecture; Software Maintenance Project Management;  Web Sites; Quality.
 
 
 

1. Introdução

O sucesso de um software consiste em, na fase de desenvolvimento, atender qualitativamente as necessidades do usuário e do seu negócio, levando em consideração prazos e custos compatíveis com a realidade do mercado.

Assim, é possível atribuir a qualidade alcançada através da concepção de uma arquitetura sólida e flexível às mudanças, ao desenvolvimento de software com rapidez, efetividade e eficiência, com um mínimo de código e retrabalho. Para atender esse objetivo são utilizadas técnicas como modelagem de processo de negócio, modelagem de requisitos (utilizando o conceito de Orientação ao Objeto), projeto da interface e navegação, técnicas de componentização e procedimentos de validação do software, como testes e revisões técnicas, tanto no processo de concepção de um novo sistema, como nos procedimentos de manutenção corretiva e/ou inovadora de sistemas em operação, conforme roteiros de desenvolvimento existentes na literatura, entre eles pode-se citar o proposto por Pressman (1995).

Desta forma, com a contínua necessidade de intervenções em um software e sua extrema importância para viabilizar a operacionalidade de um sistema, os aspectos de correções de erros, a adequação e as novas características do negócio no qual está inserido são considerações importantes a se fazer.

Em sistemas para Internet, essas intervenções tendem a ser muito mais dinâmicas devido à necessidade de disponibilidade imediata e à grande concorrência existente, na qual quem primeiro oferece um serviço e com um alto nível de qualidade tem grande possibilidade de ganhar a preferência dos usuários, conforme descrito por Nielsen (2000). Esse tipo de software deve apresentar fortes requisitos de desempenho e segurança transacional e de informações, características ainda mais importantes quando se trata de sistemas web para o segmento financeiro. Assim projetos de manutenção efetuados nesse tipo de software devem, sobretudo, garantir o desempenho (tempo de resposta) e a disponibilidade em tempo integral.

Segundo Linger; Moore (2001), o processo de manutenção de software mal realizado em um sistema em produção pode levar à sua indisponibilidade temporária, proporcionando prejuízos de negócio e a redução do tempo de vida do software devido à inserção de novos defeitos. Com o intuito de minimizar esses impactos, Fiutem et al. (1996) propôs em seu estudo que a cada atividade de manutenção de um sistema é necessário o entendimento da sua arquitetura, identificando os elementos de software que a compõem e os seus relacionamentos.

O objetivo deste trabalho é apresentar como a visão dinâmica da IHC, centrada no fluxo de navegação, de um sistema web em operação, com a estrutura proposta nesse estudo, que utiliza uma configuração especializada do diagrama de atividades da UML, representa o mapeamento existente nas interligações entre os vários elementos que compõem a sua arquitetura (páginas e links, componentes, módulos e elementos de base de dados, interfaces com sistemas externos, entre outros) através do comportamento de navegação. É objetivo também desse estudo apresentar esse diagrama como uma importante ferramenta de apoio no processo de Manutenção de Software auxiliando muito fortemente nas tarefas de: definição do escopo da manutenção; identificação precisa dos riscos e dos pontos de impactos; definição de métodos e procedimentos de qualidade.
 

2.  A Estrutura do Fluxo de Navegação para Sistema Web Proposta

O Fluxo de Navegação de um sistema web, apresentado nesse estudo, consiste em uma ferramenta gráfica que representa as interfaces gráficas (páginas e links) dos sites, juntamente com seus produtos e serviços, bem como o fluxo da navegação da interface e as transações locais e remotas acessadas, devendo ser orientado pelo fluxo do processo de negócio. Trata-se de representação gráfica especializada, que contém os diversos elementos que compõem a arquitetura do software, tais como: as páginas e links, os componentes, módulos e elementos de base de dados, as interfaces com sistemas externos (protocolos de comunicação), entre outros, bem como a interligação desses elementos através do Fluxo de Navegação da interface. Esse tipo de representação é uma importante ferramenta no processo de manutenção de sistemas softwares, pois segundo Fiutem et al. (1996) a primeira atividade nesse tipo de projeto é identificar os itens que compõem a arquitetura do sistema bem como os seus relacionamentos (definição do escopo do projeto de manutenção).

Entre os elementos de software mapeados no modelo apresentado neste estudo, a "página" possui uma característica especial.Trata-se da definição de uma estrutura estática padrão para esse objeto, conforme proposto por Ricca; Tonella (2001), pois para o mapeamento do Fluxo de Navegação de um sistema web, é necessário que todas as páginas que o compõem sejam semelhantes (padronização visual) e possuam o mesmo tipo de comportamento (estilo funcional).

Para se obter a visão estática de uma IHC, pode-se valer da utilização de ferramentas gráficas, como por exemplo, o Diagrama de Classes da notação UML, que, nessa abordagem, será utilizado para apresentar as diferentes partes que compõem a página da IHC de um sistema web, seguindo um padrão estabelecido, e como elas estão relacionadas. A figura 2.1 apresenta a estrutura estática de uma página, representada pelo Diagrama de Classes, composta de Cabeçalho, Barra de Link, Barra de Menu, Corpo da Página e Rodapé.

Fig. 2.1 Visão Estática da IHC - Utilizando Diagramas de Classes.
 

Conforme proposto por Ricca; Tonella (2001), a partir da definição da arquitetura estática da página é possível mapear a visão dinâmica da IHC, ou seja, o Fluxo de Navegação dos elementos de software que compõem um sistema web. A obtenção dessa ferramenta gráfica pode ser realizada através da utilização do diagrama de atividades da notação UML.

A modelagem do Fluxo de Navegação proposta nesse trabalho utiliza esse diagrama (com uma configuração especializada apresentada a seguir) para representar o Fluxo de Navegação de um sistema web, porém não mapeando somente a ligação existente entre páginas e links, mas também na interligação existente, através desse fluxo, dos vários elementos que compõem a arquitetura do sistema web (páginas e links, componentes, módulos e elementos de base de dados, interfaces com sistemas externos, entre outros).

Nesta configuração particular do Diagrama de Atividades da notação UML, os estados e as atividades representam os artefatos de software que possuem grande importância na garantia da manutenibilidade do sistema, tais como páginas (apresentação ao usuário), transações ou protocolos de comunicação (acesso a legado ou a sistemas externos), elementos de base de dados, módulos e componentes (lógica de negócio), utilizando a abordagem da representação gráfica especializada, (como por exemplo, a utilização de cores) para identificar facilmente, no aspecto visual, cada um desses elementos apresentados no diagrama. Além disso, cada um desses itens possui um código estruturado de identificação que será referenciado nos demais documentos que compõem o projeto. A identificação dos pontos de início e de término de cada diagrama, também é realizada através de estados que neste caso utilizam a representação gráfica de estado inicial e final do diagrama de atividades.

As ações de transição de estados (setas) representam os links existentes entre as páginas, além dos acessos e retornos aos componentes, módulos, elementos de base de dados, transações ou protocolos de comunicação. O Fluxo de Navegação deve espelhar o fluxo do processo de negócio do sistema, ou seja, apresentar os elementos de software que estão envolvidos e a maneira como são acionados na execução de uma funcionalidade, e conter uma organização baseada em níveis para facilitar o seu entendimento, além de possuir um identificador que contenha informações destinadas a sua identificação, como por exemplo: nome do site, do serviço e nível de explosão que está representado. Segundo Conallen (2000), para grandes sistemas web é melhor que os Fluxos de Navegação sejam divididos em vários diagramas, cada um focando uma funcionalidade.

A figura 2.2 a seguir foi elaborada para apresentar um modelo de Fluxo de Navegação construído com base na notação descrita acima, para um serviço de um site genérico, destacando telas, links, e componentes acionados.

Fig 2.2 Exemplo de Fluxo de Navegação Construído com Base na Notação Proposta.
 

Conforme ilustra a figura anterior, as páginas do sistema "Genérico" são compostas por cabeçalho, barra de menu e corpo de página. Todas as páginas possuem uma barra de menu com comportamento apresentado pelo Fluxo "Barra de Menu", diferenciando somente o corpo de página. O serviço "Serviço Item 1" possui, em seu corpo de página, uma funcionalidade composta por quatro páginas e duas lógicas de negócio, assim o Fluxo de Navegação relativo a esse serviço mapeia o fluxo dessa funcionalidade e pode ser modelado em dois processos: "Processo de Negócio 1" e "Processo de Negócio 2". O primeiro é representado pelos estados GEPG005, GECM010 e GEPG001 e o segundo pelos estados GECM020 e GEPG002.

Esta figura apresenta também a notação especializada que foi utilizada para construção desse Fluxo, destacando a diferenciação do aspecto visual de cada um dos elementos apresentados no diagrama: as páginas são representadas pelos estados com sombreamento na cor branco e os componentes pelos estados com sombreamento na cor cinza.
 

3. O Fluxo de Navegação como Ferramenta de Apoio no Processo de Manutenção de Software Web

A modelagem da IHC, é um importante mecanismo no processo de desenvolvimento de manutenção de software de um sistema web, apoiando na elaboração dos artefatos gerados em cada etapa do ciclo de desenvolvimento como, por exemplo, o proposto por Pressman (1995). Dentre as ferramentas existentes para a modelagem da IHC está o modelo do Fluxo de Navegação.

A modelagem do Fluxo de Navegação proposta nesse estudo e descrita no item 2 trata-se de uma representação gráfica dos artefatos de software que compõem o sistema e suas interações, o que a torna uma ferramenta de apoio no ciclo de desenvolvimento de manutenção de software, pois a cada atividade de manutenção de um sistema é necessário o entendimento da sua arquitetura, identificando os elementos de software que a compõem e os seus relacionamentos para apoiar nas  tarefas de: definição do escopo da manutenção, identificação precisa dos riscos e dos pontos de impactos, definição de métodos e procedimentos de qualidade. Esta seção tem como objetivo apresentar como este tipo de apoio é realizado.

3.1 Subsídios para Definição de Escopo de um Projeto de Manutenção em Sistemas Web
Em projetos de manutenção de software é gasto um grande esforço para entender o sistema e identificar as partes ou itens de software que devem ser modificados, devido à dificuldade existente na realização dessas atividades, o que ocorre, em sua grande maioria, por falta de um modelo que represente a arquitetura do sistema (elementos que a compõem e seus relacionamentos).

Como já dito anteriormente, o Fluxo de Navegação apresenta os elementos de software que compõem o sistema e deve espelhar o fluxo do processo de negócio. Assim, utilizando essa ferramenta gráfica, a definição do escopo da manutenção torna-se mais clara, pois é possível identificar mais facilmente quais itens de software estão contidos no modelo do domínio do problema. Esse processo de identificação se constitui de dois aspectos: a utilização de técnicas de modelagem de processo de negócio para mapear os requisitos, e o confronto desse modelo com o Fluxo de Navegação referente ao fluxo de negócio mapeado.

Além da definição do escopo da manutenção é possível também identificar, através da leitura de códigos fontes ou de documentos de especificação técnica de implementação, quais itens de software (páginas, componentes, módulos, entre outros já citados) que compõem o escopo definido, efetivamente sofrerão intervenção de código.

A figura 3.1.1 apresenta um exemplo de identificação de contexto de uma manutenção e dos itens de software que serão alterados, através do Fluxo de Navegação. Supondo-se que seja identificada uma manutenção inovadora no "Processo de Negócio 2" no sistema "Genérico", devido à necessidade de incluir novos requisitos, o contexto dessa manutenção é referente ao serviço "Serviço Item 1" desse sistema, representado pelo Fluxo de Navegação da figura 3.1.1, ou seja, todos os elementos de software apresentados nesse diagrama poderão sofrer interferências direta ou indiretamente na realização dessa intervenção. Nesse sistema todos os requisitos do "Processo de Negócio 2" estão implementados no componente "Componente Processo Negócio 2", representado pelo estado GECM020, assim a intervenção será realizada somente nesse ponto (interferência direta), ou melhor, todos os produtos de software do sistema em operação, referentes ou ligados a essa lógica de negócio, deverão ser utilizados no processo de definição da arquitetura da manutenção de software que será efetuado.

Fig.3.1.1 Fluxo de Navegação Identificando o Elemento de Software de Interferência Direta da Manutenção.
 

A tabela 3.1.1 a seguir apresenta um resumo parcial do escopo desse projeto de manutenção do "Processo de Negócio 2" no sistema "Genérico", apresentando o item de software de interferência direta identificado no Fluxo de navegação representado na figura 3.1.1.
 
 

Escopo da Manutenção
Grau de Complexidade	Itens de Software
Interferência Direta (Código Fonte)	GECM020

Tab. 3.1.1 Resumo Parcial do Escopo do Projeto de Manutenção de Software
 

3.2 Análise de Impactos na Manutenção de Sistemas Web
O Fluxo de Navegação é também uma importante ferramenta de apoio na análise de impactos e riscos de uma manutenção corretiva ou evolutiva. Essa análise pode ser obtida a partir da identificação dos elementos de software que sofrerão intervenção de código, no qual é possível visualizar e analisar com mais precisão os impactos dessa alteração (a abrangência) no sistema como um todo, identificando quais itens de software que, apesar de não sofrerem intervenções diretas (código fonte), serão atingidos indiretamente (através dos "caminhos" facilmente identificáveis no diagrama apresentado na figura 3.2.1) e assim deverão ser também testados no processo de qualidade da manutenção, além de identificar os riscos intrínsecos na alteração.

A figura 3.2.1 apresenta o mesmo exemplo de contexto de manutenção identificado no item anterior desse capítulo ("Serviço Item 1"), contudo demonstra os impactos que a intervenção que será realizada no "Componente Processo Negócio 2", representado pelo estado GECM020, acarretarão aos outros elementos de software que compõem essa funcionalidade, representados pelos estados GEPG005, GEPG001, GECM010, GEPG002 e GEPG004, visto que todos estão fortemente acoplados. Assim, o risco intrínseco nessa alteração caracteriza-se como alto, dado que o processo de negócio do "Serviço do Item 1" poderá ficar parcialmente ou totalmente comprometido, caso a execução dessa manutenção de software não seja bem sucedida.

O processo necessário para a estabelecer a qualidade dessa manutenção de software não será efetuado somente através do componente representado pelo estado GECM020, mas também por todos os itens de software que serão atingidos pelo impacto dessa intervenção, representados pelos estados GEPG005, GEPG001, GECM010, GEPG002 e GEPG004.

A partir das informações já apresentadas nesse projeto de manutenção de software - escopo definido, item de software que sofrerá interferência direta, itens de software que sofrerão impactos e a intensidade do risco presente nessa atividade.

Fig. 3.2.1 Fluxo de Navegação Identificando os Impactos da Manutenção.
 

A tabela 3.2.1 a seguir apresenta um resumo do escopo desse projeto de manutenção do "Processo de Negócio 2" no sistema "Genérico", apresentando os itens de software de interferência direta e os que sofrerão impactos, bem como os riscos existentes na execução desse projeto, identificados no Fluxo de navegação representado na figura 3.2.1.
 
 

Escopo da Manutenção
Grau de Complexidade	Itens de Software
Interferência Direta (Código Fonte)	GECM020
Impacto	GEPG005, GECM010, GEPG001 e GEPG002.
Risco	Alto acoplamento dos elementos de software: GEPG005, GECM010, GEPG001 e GEPG002 ao componente GECM020.

Tab. 3.2.1 Resumo do Escopo do Projeto de Manutenção de Software.
 

3.3   Elaboração da Cobertura de Testes da Manutenção em Sistemas Web
O Fluxo de Navegação caracteriza-se também como uma ferramenta de apoio na obtenção de um processo de validação, conforme sugerido por Ricca; Tonella (2001) e Tonella; Ricca (2002), e como controle de qualidade da manutenção, pois auxilia na elaboração dos planos de teste do sistema, identificando e roteirizando os casos de testes (cobertura) através dos "caminhos" facilmente identificáveis no diagrama.

Abaixo, a figura 3.3.1 ilustra os "caminhos" existentes no diagrama que representa o Fluxo de Navegação do serviço "Serviço Item 1" do site "Genérico".

Fig. 3.3.1 Fluxo de Navegação do Serviço Item 1.
 

No Fluxo de Navegação apresentado na figura acima, é possível identificar, com facilidade, três "caminhos" existentes no diagrama e que serão convertidos como casos de testes no sistema, apresentados na tabela 3.3.1 a seguir.
 
 

Cobertura de Testes
#	Caso de Teste (Objetivo)	Composição de Estados
1	Caso de Teste 1	Composto pelos estados: GEPG005, GECM010, GEPG001, GECM020 e GEPG002.
2	Caso de Teste 2	Composto pelos estados: GEPG005, GECM010, GEPG004 e GEPG005.
3	Caso de Teste 3	Composto pelos estados: GEPG005, GECM010, GEPG001,  GECM020, GEPG004 e GEPG005.

Tab. 3.3.1 Cobertura de Testes.
 

Essa ferramenta pode também auxiliar na execução dos testes de validação de um sistema em empresas que não tenham adotado o procedimento de elaboração de Planos de Validação e Roteiros de Testes, pois através das setas é possível identificar os comportamentos que o software deve reproduzir a partir das interações efetuadas.
 

4. Resultados

A abordagem proposta, descrita na seção anterior, foi aplicada a projetos de software com ênfase em aplicações financeiras para Web.

Dados extraídos desses projetos, coletados durante o período de aproximadamente um ano junto a um grupo de desenvolvedores de uma organização, demonstraram algumas dificuldades em relação aos aspectos de desenvolvimento de manutenção nos sistemas em operação. Entre elas destacam-se:
 

Os aspectos apresentados ocorreram em virtude da falta de documentação de negócio, da arquitetura das soluções desenvolvidas, da interface (IHC) e do Fluxo de Navegação do sistema em produção, bem como a atualização desses artefatos a cada manutenção efetuada no sistema.

O referido grupo passou a utilizar a por aproximadamente um ano a abordagem proposta neste trabalho para alguns projetos de manutenção de sites que sofreram um processo de reengenharia de elaboração da documentação de negócio, do esboço da arquitetura técnica da solução em operação, bem como de modelagem da interface (IHC) e de mapeamento do Fluxo de Navegação. Os novos sites que foram desenvolvidos sobre o novo processo de desenvolvimento e assim possuem todos os artefatos de software já citados, também estão utilizando a abordagem proposta no processo de desenvolvimento de manutenção corretiva e/ou inovadora.

Como características particulares deste caso em estudo, pode-se destacar:
 

Entre as vantagens alcançadas pela incorporação desta abordagem no processo de desenvolvimento de manutenção de software destacam-se:
 

Entretanto, algumas dificuldades e pontos críticos da utilização da abordagem proposta foram encontrados, entre eles:
 

O estudo de caso realizado apresentou resultados satisfatórios na utilização da modelagem do Fluxo de Navegação proposta nesse estudo como ferramenta de apoio no processo de desenvolvimento de manutenção de software web. Devido a sua estrutura, composta pelos artefatos de software que compõem o sistema e suas interações, esse mecanismo foi utilizado em todas as atividades existentes nesse processo como entendimento da solicitação, análise dos impactos e planejamento da intervenção, manutenção dos programas e suas respectivas validações, fornecendo subsídios para elaborar os produtos referentes a: definição de escopo; análise de impactos e riscos e na definição da cobertura de testes; além de disponibilizar uma ferramenta conceitual que traduz a linguagem do comportamento do usuário para outra que apóia o desenvolvedor na construção/alteração da aplicação.

Esse trabalho foi focado em projetos de manutenção de sistemas web para uma instituição financeira, ou seja, não é possível garantir uma generalização dessa proposta para todos os tipos de sistemas existentes na área de software, como por exemplo, em projetos de robótica, pois podem ocorrer divergências no comportamento de navegação devido às características particulares da arquitetura. Assim, a aplicação da abordagem proposta em ambientes sistêmicos diferentes ao estudado pode ser escopo para trabalhos futuros.

Conforme apresentado, a modelagem do Fluxo de Navegação proposta nesse estudo, apresentou bons resultados sendo utilizada como ferramenta de apoio no processo de desenvolvimento de manutenção de software web. Contudo foram identificados pontos críticos que devem ser vencidos, entre eles o processo de aculturamento das equipes e a falta de notação padronizada para esse tipo de representação, além da ausência de ferramentas automatizadas para elaboração e manutenção do Fluxo de Navegação nos moldes propostos nesse artigo, que mapeia não só as páginas do sistema como também outros produtos de software. A especificação e a construção desse tipo de ferramenta também pode ser escopo para trabalhos futuros.
 

Referências Bibliográficas

BACHMANN, F. et al. Documenting Software Architecture: Documenting Behavior. Carnigie-Melon Software Engineering Institute, Pittsburgh, Tecnical Note, CMU/SEI-2002-TN-001, Janeiro 2002.

CONALLEN, J. Building Web Applications with UML. Boston, Addison-Wesley Publishing Company, 2000.

FIUTEM, R. et al. A Cliché-Based Environment to Support Architectural Reverse Engineering. IEEE Computer Society, Proceedings of the 1996 International Conference on Software Maintenance (ICSM '96), 1063-6773/96, 1996.

LINGER, R.; MOORE, A. Foundations for Survivable System Development: Service Traces, Intrusion Traces, and Evaluation Models. Carnigie-Melon Software Engineering Institute, Pittsburgh, Tecnical Report, CMU/SEI-2001-TR-029, Outubro 2001.

NIELSEN, J. Projetando Web Sites. Rio de Janeiro, Editora Campus, 2000.

PRESSMAN, R. Engenharia de Software. São Paulo, Makron Books, 1995.

PMBOK GUIDE. Project Management Body of Knowledge. Pennsylvania; PMI, 2004.

RICCA, F.; TONELLA, P. Analysis and Testing of Web Applications. IEEE Computer Society, 0-7695-1050-7/01, p.25-34, 2001.

RICCA, F.; TONELLA, P. Construction of the System Dependence Graph for Web Application Slicing. IEEE Computer Society, Proceedings of the Second IEEE International Workshop on Source Code Analysis and Manipulation (SCAM'02), 0-7695-1793-5/02, 2002.

TONELLA, P.; RICCA, F. Dynamic Model Extraction and Statistical Analysis of Web Applications. IEEE Computer Society, Proceedings of the Fourth International Workshop on Web Site Evolution (WSE'02), 0-7695-1804-4/02, 2002.
 

Sobre os autores / About the Authors:

Reginaldo Arakaki
reginaldo.arakaki@poli.usp.br

Doutor em Engenharia da Computação e Sistemas
Professor Doutor do Departamento de Engenharia de Computação e Sistemas Digitais/ Membro do Grupo de Tecnologia de Software

Endereço:
Escola Politécnica da Universidade de São Paulo
Av. Prof. Luciano Gualberto, trv3, no 158, Edifício da Engenharia de Eletricidade
Cep 05508-900, São Paulo, SP
Fone: 0xx-11-3091-5200

Alexandra A. Souza
alexandra.souza@poli.usp.br

Doutoranda em Engenharia da Computação e Sistemas Digitais

Endereço:
Escola Politécnica da Universidade de São Paulo
Av. Prof. Luciano Gualberto, trv3, no 158, Edifício da Engenharia de Eletricidade
Cep 05508-900, São Paulo, SP
Fone: 0xx-11-5582-9276