UNIVERSIDADE FEDERAL DE SÃO CARLOS
CENTRO DE CIÊNCIAS EXATAS E DE TECNOLOGIA
PROGRAMA DE PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
REENGENHARIA DE INTERFACES COM REALIDADE
VIRTUAL CONSIDERANDO O PARADIGMA DE
ORIENTAÇÃO A OBJETOS
ORIENTADORA: Profa. Dra. Júnia Coutinho Anacleto Silva
ALUNO: Cristiano Lemos Soares
SÃO CARLOS – SP
2002
Ficha catalográfica elaborada pelo DePT da
Biblioteca Comunitária da UFSCar
S676ri
Soares, Cristiano Lemos.
Reengenharia de interfaces com realidade virtual
considerando o paradigma de orientação a objetos /
Cristiano Lemos Soares. -- São Carlos : UFSCar, 2004.
180 p.
Dissertação (Mestrado) -- Universidade Federal de São
Carlos, 2002.
1. Realidade virtual. 2. Reengenharia de sistemas. 3.
Interface orientada a objetos. I. Título.
CDD: 006 (21a)
1
AGRADECIMENTOS
À Prof ª. Dr ª. Júnia Coutinho Anacleto Silva e à Prof ª. Dr ª. Rosângela Ap. Dellosso Penteado,
pela orientação, paciência, apoio e amizade que foram fundamentais para a realização deste
trabalho.
Aos meus companheiros de laboratório, em especial Camilla, Rafael, Thiago e Alice por suportar
meus dias de mal-humor, por me dar apoio nos momentos difíceis e tornar este trabalho divertido.
Aos meus amigos da república Lineu: Alexandre, Luis, Márcio, Paulo (Xineiz) e Ronaldo, com
os quais passei a maior parte dos meus melhores momentos durante este período e que me
mostraram o verdadeiro significado da amizade.
A minha namorada Juliana, simplesmente por ser a pessoa maravilhosa que é, estando sempre ao
meu lado quando precisei.
A minha família que me deu muito carinho e apoio para que esta jornada se tornasse possível.
A Fundação de Amparo à Pesquisa do Estado de São Paulo, FAPESP, pelo suporte financeiro
fornecido durante a realização deste trabalho.
2
RESUMO
Com a evolução constante das tecnologias aplicadas a interfaces do usuário, uma nova
geração dessas interfaces vem se estabelecendo. Interfaces baseadas em reconhecimento de voz,
reconhecimento de gestos e gráficos 3D, entre outras tecnologias, visam tornar a interação
homem-computador mais fácil, oferecendo meios de interação mais intuitivos aos conhecimentos
humanos, a fim de disponibilizar os recursos computacionais a um número cada vez maior de
usuários. Dentre as novas tecnologias de interface surge, com destaque, a Realidade Virtual (RV)
facilitando a visualização, manipulação e interação de usuários com ambientes computacionais
tridimensionais (3D). Além da RV, a aplicação do paradigma de orientação a objetos apresenta-se
como uma opção para desenvolvimento de interfaces não só intuitivas e naturais, mas também
com possibilidade de reuso de seus componentes facilitando futuros desenvolvimentos. Em
contrapartida às facilidades oferecidas em sua manipulação, a interface com RV adiciona
complexidade durante seu desenvolvimento devido à falta de ferramentas e métodos de apoio,
seja na engenharia avante quanto na reengenharia de interfaces. Assim, os objetivos deste projeto
são: apresentar diretivas para a reengenharia de interfaces orientadas a objetos com recursos de
RV utilizando o ambiente GaCIV (Gabaritos Configuráveis para elaboração de Interfaces com
RV); confirmar o uso do ambiente GaCIV como uma ferramenta de apoio efetivo ao
desenvolvedor de interfaces dando suporte à aplicação da RV no desenvolvimento de interfaces
avançadas, seja em um processo convencional de engenharia de sistemas ou em um processo de
reengenharia; analisar se o processo de reengenharia de interfaces com apoio do ambiente GaCIV
se torna mais eficiente quando o sistema em questão for desenvolvido sob o paradigma OO.
Foram verificadas as vantagens e desvantagens em integrar uma nova interface com recursos de
RV através do ambiente computacional GaCIV com sistemas: 1) legados que possuem
documentação obtida por um processo de engenharia reversa OO; 2) segmentados que têm o
código implementado na linguagem procedural com características de OO inseridas a partir dos
modelos obtidos com a engenharia reversa OO; 3) submetidos ao processo de reengenharia com a
mudança de paradigma de desenvolvimento como de linguagem de programação OO.
3
LISTA DE ILUSTRAÇÕES
FIGURA 1.1 – INTEGRAÇÃO PROPOSTA....................................................................................... 6
FIGURA 3.1 – MODELO DE OBJETOS COM VISÕES REPRESENTADAS DO OVID, ADAPTADA DE
(IBM, 2001B) ............................................................................................................................. 27
FIGURA 3.2 – VISÃO GERAL DA METODOLOGIA FUSION-RE/I (FELTRIM ET AL, 1999) .......... 29
FIGURA 4.1 – CRIAÇÃO DE INTERFACES COM RV COM O GACIV............................................ 34
FIGURA 4.2– CRIAÇÃO DE NOVOS GABARITOS NO GACIV ....................................................... 35
FIGURA 4.3 – LIGAÇÃO ENTRE OBJETO E APLICAÇÃO NO GACIV............................................. 36
FIGURA 4.4 – O GACIV E A REENGENHARIA DE INTERFACE..................................................... 39
FIGURA 5.1 – PROCESSO DE REENGENHARIA PARA INTERFACES COM RV PROPOSTO NESTE
TRABALHO .................................................................................................................................. 42
FIGURA 5.2 – GABARITO PRELIMINAR PARA GERAÇÃO DAS INTERFACES COM RV PARA O
SISTEMA EXEMPLO...................................................................................................................... 46
FIGURA 5.3 – ESTILO DE INTERFACE TEXTUAL UTILIZADO PELO SISTEMA LEGADO .................. 48
FIGURA 5.4 – ESTRUTURA DA ÁRVORE DE MENUS DO SISTEMA LEGADO .................................. 49
FIGURA 5.5 – OBJETO COMPUTADOR NO MENU PRINCIPAL DO SISTEMA LEGADO COM INTERFACE
COM RV...................................................................................................................................... 50
FIGURA 5.6 – ESTRUTURA DA ÁRVORE DE MENUS DA INTERFACE DO SISTEMA SEGMENTADO .. 51
FIGURA 5.7 – EXECUÇÃO DO MÓDULO DE APLICAÇÃO “CONSCLI.EXE” GERADO A PARTIR DA
VERSÃO SEGMENTADA DO SISTEMA EXEMPLO ............................................................................ 53
FIGURA 5.8 – EXECUÇÃO DO MÓDULO DE APLICAÇÃO “CONSULTA.EXE” GERADO A PARTIR DA
VERSÃO SEGMENTADA DO SISTEMA EXEMPLO ............................................................................ 54
FIGURA 5.9 – MÓDULOS DO SISTEMA SEGMENTADO NA ESTRUTURA DA ÁRVORE DE MENUS ... 54
TABELA 5.1 – ASSOCIAÇÃO ENTRE MENUS ORIGINAIS, NOME DOS MÓDULOS CRIADOS E
ARQUIVOS DE IMPLEMENTAÇÃO DOS MÓDULOS CRIADOS PARA O SISTEMA SEGMENTADO .......... 55
FIGURA 5.10 – OBJETO 3D “IMPRESSORA” LIGADO AO MÓDULO “IMPRESSOS” DO SISTEMA
SEGMENTADO ............................................................................................................................. 56
FIGURA 5.11 – OBJETO 3D “ARQUIVO” LIGADO AO MÓDULO “MANUTENÇÃO DE ARQUIVOS” DO
SISTEMA SEGMENTADO ............................................................................................................... 56
FIGURA 5.12 – INTERFACE DA VERSÃO OO DO SISTEMA EXEMPLO .......................................... 57
FIGURA 5.13 – ÁRVORE DE MENUS DA INTERFACE DO SISTEMA OO......................................... 58
FIGURA 5.15 – HINT DO OBJETO “CLIENTE” NA OOUI DO SISTEMA OO................................... 60
FIGURA 5.16 – ÍCONES REORGANIZADOS PELO USUÁRIO NA OOUI DO SISTEMA OO ............... 60
FIGURA 5.17 – MENU POPUP COM MÉTODOS PARA INTERAÇÃO COM O OBJETO “CLIENTE” DA
INTERFACE DO SISTEMA OO. ...................................................................................................... 61
FIGURA 5.18 – OBJETO DA INTERFACE AVANÇADA PARA REPRESENTAR O OBJETO
“FORNECEDOR” DA INTERFACE DO SISTEMA OO ........................................................................ 62
FIGURA 5.19 – OBJETO DA INTERFACE AVANÇADA DO SISTEMA OO PARA REPRESENTAR O
OBJETO “CLIENTE” ..................................................................................................................... 62
FIGURA 5.20 – OPÇÕES DE MÉTODOS PARA INTERAGIR COM OBJETO “CLIENTE” DO SISTEMA OO
COM RECURSOS DE RV ............................................................................................................... 63
FIGURA 6.1 – ÁRVORE DE MENUS DO SISTEMA LEGADO ........................................................... 66
FIGURA 6.2 – TELA DE LANÇAMENTO DA 1A PARTE DA ORDEM DE SERVIÇO DO SISTEMA
LEGADO ...................................................................................................................................... 67
FIGURA 6.3 – TELA DE VERIFICAÇÃO DE “VEÍCULOS DO CLIENTE”.......................................... 68
FIGURA 6.4 – MENSAGEM DE ERRO DO SISTEMA LEGADO ........................................................ 68
4
FIGURA 6.5 – PREENCHIMENTO DE DADOS DO CLIENTE COM SELEÇÃO..................................... 69
FIGURA 6.6 – PREENCHIMENTO DE DADOS DO CLIENTE SEM SELEÇÃO ..................................... 69
FIGURA 6.7- ESTRUTURA DE ÁRVORE DE MENUS DO SISTEMA SEGMENTADO ........................... 70
FIGURA 6.8 – MENU DE CONSULTAS DO SISTEMA SEGMENTADO .............................................. 71
FIGURA 6.9 – MENU DE CONSULTAS A PEÇAS DO SISTEMA SEGMENTADO ................................ 71
FIGURA 6.10 – ÁRVORE DE MENUS DO SISTEMA OO ................................................................ 72
FIGURA 6.11 – CAIXA DE ITENS SELECIONÁVEIS PARA A FUNCIONALIDADE “CONSULTAR
CLIENTE” DO SISTEMA OO ......................................................................................................... 73
FIGURA 6.12 – JANELA DE ALERTA AO USUÁRIO NO SISTEMA OO............................................ 74
FIGURA 6.13 – HINT APRESENTADO PARA CAMPO “CATEGORIA” DO FORMULÁRIO DE CADASTRO
DE CLIENTES NO SISTEMA OO ..................................................................................................... 74
FIGURA 6.14 – ESCOLHA DE OPÇÃO DE CONSULTA DE PEÇAS NO SISTEMA OO......................... 75
TABELA 6.1 – DIRETIVAS PARA “USUÁRIOS EM AMBIENTES VIRTUAIS” ................................. 76
TABELA 6.2 – DIRETIVAS PARA “NAVEGAÇÃO E LOCOMOÇÃO” .............................................. 76
TABELA 6.3 – DIRETIVAS PARA “SELEÇÃO DE OBJETO” .......................................................... 76
TABELA 6.4 – DIRETIVA PARA “APRESENTAÇÃO DO USUÁRIO E REPRESENTAÇÃO”................ 76
TABELA 6.5 – DIRETIVA PARA “ENVOLVIMENTO VIRTUAL E CONFIGURAÇÃO”....................... 77
TABELA 6.6 – DIRETIVAS PARA “MECANISMOS DE ENTRADA EM GERAL” .............................. 77
TABELA 6.7 – DIRETIVAS PARA “SISTEMA COM AMBIENTE VIRTUAL E INFORMAÇÃO DA
APLICAÇÃO”............................................................................................................................... 77
FIGURA 6.15 – INTERFACES DO SISTEMA LEGADO ................................................................... 79
FIGURA 6.16 – ESTRUTURAS DE INTERFACE PARA O SISTEMA LEGADO COM INTERFACE COM RV
................................................................................................................................................... 80
FIGURA 6.17– INTERFACES DO SISTEMA SEGMENTADO ........................................................... 81
FIGURA 6.18 – CONTEXTO DE “COMPRAS E VENDAS” NA INTERFACE COM RV DO SISTEMA
SEGMENTADO ............................................................................................................................. 82
FIGURA 6.19 – CONTEXTO DE “PÁTIO DE OFICINA” NA INTERFACE COM RV DO SISTEMA
SEGMENTADO ............................................................................................................................. 82
FIGURA 6.20 – MENU DE LANÇAMENTOS DO SISTEMA SEGMENTADO ....................................... 84
FIGURA 6.21 – INTERFACES PARA O SISTEMA OO.................................................................... 85
FIGURA 6.22 – AÇÕES PERMITIDAS PARA O OBJETO “CLIENTE” ............................................... 85
FIGURA 7.2 – OBJETO “LUPA” REPRESENTANDO A TAREFA “CONSULTAR ARQUIVO” NA
INTERFACE COM RV PARA O SISTEMA SEGMENTADO ................................................................ 100
FIGURA 7.3 – OBJETOS COMPLEMENTARES PARA A INTERFACE COM RV PARA O SISTEMA
SEGMENTADO ........................................................................................................................... 101
5
SUMÁRIO
CAPÍTULO 1 – INTRODUÇÃO 1
1.1 CONSIDERAÇÕES INICIAIS ....................................................................................................... 1
1.2 A ABORDAGEM DE ENGENHARIA REVERSA E A REALIDADE VIRTUAL ................................... 2
1.3 RELEVÂNCIA DO TRABALHO ................................................................................................... 3
1.4 OBJETIVOS .............................................................................................................................. 4
1.5 ESTRUTURA DA DISSERTAÇÃO ................................................................................................ 6
CAPÍTULO 2 – INTERFACES COM REALIDADE VIRTUAL
7
2.1 CONSIDERAÇÕES INICIAIS ....................................................................................................... 7
2.2 CONCEITUAÇÃO ...................................................................................................................... 8
2.2.1 Comparação entre interfaces com RV e outros estilos de interfaces ........................... 10
2.2.2 Aplicações..................................................................................................................... 11
2.3 CARACTERÍSTICAS DE USABILIDADE EM SISTEMAS COM INTERFACES COM RV.................... 11
2.4 DESAFIOS NO DESENVOLVIMENTO DE SISTEMAS COM INTERFACES COM RV ....................... 13
2.5 CONSIDERAÇÕES FINAIS ....................................................................................................... 14
CAPÍTULO 3 - REENGENHARIA DE INTERFACES 15
3.1 CONSIDERAÇÕES INICIAIS ..................................................................................................... 15
3.2 O PROCESSO DE REENGENHARIA DE SISTEMAS NO CONTEXTO DE USABILIDADE .................... 15
3.3 MÉTODOS PARA APOIO À REENGENHARIA DE INTERFACES .................................................... 16
3.3.1 Abordagens para o processo de reengenharia de interfaces ....................................... 17
3.3.2 Reengenharia de interfaces para interfaces com RV ................................................... 19
3.3.3 Revisão de Métodos e Modelos para apoio à reengenharia de interfaces................... 20
3.3.3.1 Statecharts ............................................................................................................. 22
3.3.3.2 GOMS - Goals, Operators, Methods and Selection rules ..................................... 24
3.3.3.3 OVID - Object, View and Interaction Design ....................................................... 26
3.3.3.4 FUSION RE/I ........................................................................................................ 28
3.4 CONSIDERAÇÕES FINAIS ....................................................................................................... 30
CAPÍTULO 4 - O AMBIENTE GACIV 31
4.1 CONSIDERAÇÕES INICIAIS ..................................................................................................... 31
4.2 CARACTERÍSTICAS ................................................................................................................ 31
4.3 POTENCIALIDADES ................................................................................................................ 37
4.3.1 GaCIV e OOUI ............................................................................................................. 38
4.3.2 GaCIV e Reengenharia................................................................................................. 38
4.3.3 GaCIV e Reuso ............................................................................................................. 40
4.4 CONSIDERAÇÕES FINAIS ....................................................................................................... 40
CAPÍTULO 5 - ESTUDO DE CASO - O SISTEMA DA OFICINA MECÂNICA
41
5.1 CONSIDERAÇÕES INICIAIS ..................................................................................................... 41
5.2 PROPOSTA DE PROCESSO DE REENGENHARIA DESTE TRABALHO............................................ 41
6
5.3 MODELOS PARA A REENGENHARIA DE INTERFACES.............................................................. 44
5.3.1 GOMS ........................................................................................................................... 44
5.3.2 Statecharts .................................................................................................................... 45
5.3.3 OVID............................................................................................................................. 45
5.4 CRIAÇÃO DO GABARITO PRELIMINAR DE OBJETOS 3D PARA O DOMÍNIO DO SISTEMA
EXEMPLO .................................................................................................................................... 46
5.5 SISTEMA LEGADO.................................................................................................................. 48
5.5.1 Características de implementação ............................................................................... 48
5.5.2 O processo de reengenharia de interfaces com RV para o sistema legado ................. 49
5.6 SISTEMA SEGMENTADO ......................................................................................................... 50
5.6.1 Características de implementação ............................................................................... 50
5.6.2 O processo de reengenharia do sistema segmentado................................................... 51
5.6.3 O processo de reengenharia de interfaces com RV para o sistema segmentado ......... 52
5.7 SISTEMA ORIENTADO A OBJETOS ......................................................................................... 56
5.7.1 Características de implementação ............................................................................... 57
5.7.2 O processo de reengenharia do sistema orientado a objetos....................................... 58
5.7.3 O processo de reengenharia de interfaces com rv para o sistema orientado a objetos61
5.8 CONSIDERAÇÕES FINAIS ....................................................................................................... 63
CAPÍTULO 6 – ANÁLISE DOS RESULTADOS OBTIDOS 64
6.1 CONSIDERAÇÕES INICIAIS ..................................................................................................... 64
6.2 CRITÉRIOS DE USABILIDADE PARA SISTEMAS TEXTUAIS E WIMP ......................................... 65
6.3 ANÁLISE DA INTERFACE DO SISTEMA LEGADO ..................................................................... 66
6.4 ANÁLISE DA INTERFACE DO SISTEMA SEGMENTADO ............................................................ 69
6.5 ANÁLISE DE USABILIDADE DA INTERFACE DO SISTEMA OO................................................. 72
6.6 CRITÉRIOS DE USABILIDADE PARA SISTEMAS COM INTERFACES COM RV.............................. 75
6.7 ANÁLISE COMPARATIVA DOS PROCESSOS DE REENGENHARIA .............................................. 77
6.7.1 Sistema Legado............................................................................................................. 79
6.7.2 Sistema Segmentado ..................................................................................................... 80
6.7.3 Sistema OO ................................................................................................................... 84
6.7.4 Comparação entre os processos de reengenharia de interface: Sistema Legado vs.
Segmentado vs. OO ............................................................................................................... 86
6.7 CONSIDERAÇÕES FINAIS........................................................................................................ 88
CAPÍTULO 7 - CONCLUSÕES 90
7.1 CONSIDERAÇÕES INICIAIS ..................................................................................................... 90
7.2 CONSIDERAÇÕES SOBRE O ESCOPO DO TRABALHO ............................................................... 90
7.3 PRINCIPAIS CONTRIBUIÇÕES ................................................................................................. 92
7.3.1 Conclusões esperadas segundo a proposta de trabalho .............................................. 92
7.3.2 Diretivas para reengenharia de interfaces com RV ..................................................... 95
7.3.2.1 Diretivas para o processo de reengenharia de interfaces com RV ........................ 95
7.3.2.2 Diretivas de usabilidade para a reengenharia de interfaces com RV .................... 98
7.4 TRABALHOS FUTUROS ........................................................................................................ 101
REFERÊNCIAS BIBLIOGRÁFICAS
104
APÊNDICE A - MODELO DE CLASSES PARA A REENGENHARIA.
114
7
APÊNDICE B - USE CASES
116
APÊNDICE C – DIAGRAMAS DE SEQUÊNCIA
131
APÊNDICE D - CENÁRIOS TEXTUAIS
155
APÊNDICE E - DIAGRAMAS DE CAIXAS
169
ANEXO I – MODELO DE CLASSES ORIGINAL
172
ANEXO II – MODELO DE CICLO DE VIDA
174
ANEXO III – MAPA DE MENUS
175
8
1
Capítulo 1 – Introdução
1.1 Considerações Iniciais
Os sistemas legados, alguns gerados com técnicas não estruturadas de desenvolvimento,
outros deteriorados devido às mudanças não documentadas em seus códigos, na maioria das
vezes são a base na qual se apóiam os negócios de seus usuários. Devido à desestruturação e falta
de documentação, inúmeros problemas surgem quando a manutenção é necessária. Sem
documentação, o engenheiro de software não pode conduzir as alterações desejadas sem que haja
um efeito gatilho nos erros encontrados e consertados. Ou seja, conserta-se um e outros ocorrem,
sucessivamente, como um “efeito dominó”. Esses sistemas apresentam, além dos problemas de
manutenção em seu código fonte, interfaces que deixa a desejar em relação à interface de
sistemas desenvolvidos mais recentemente, que utilizam recursos gráficos e visuais. Em alguns
casos, o usuário tem o desejo de mudar o sistema para uma linguagem que siga um paradigma
diferente daquela que está implementado, e que essa transformação seja gradativa e sem perda da
sua funcionalidade.
Existem várias maneiras para atingir os problemas citados acima. Geralmente esse
processo de troca de linguagem, de paradigma de desenvolvimento, de interfaces se dá de forma
gradativa. Para que essas modificações ocorram, caso não exista a documentação do sistema
legado, deve-se utilizar um processo de engenharia reversa e em seguida, quando a mudança de
paradigma de desenvolvimento e/ou de linguagem de programação ocorrer, um processo de
reengenharia é realizado para re-implementação do sistema na forma desejada.
Outra forma para resolver esse problema é a utilização de interfaces com recursos mais
avançados, para agregar qualidade ao sistema legado. Assim, é estudado aqui o processo de
engenharia reversa/reengenharia, integrado com a elaboração de novas interfaces através do uso
do ambiente GaCIV (Gabaritos Configuráveis para Interfaces com Realidade Virtual), para a
geração de interfaces com realidade virtual (RV) e integração com sistemas legados.
Este capítulo está organizado da seguinte forma: a abordagem de engenharia reversa e a
aplicação de RV em interfaces são mostradas em 1.2; a relevância do trabalho é comentada em
1.3; os objetivos buscados com esse trabalho são apresentados na seção 1.4. Na seção 1.5 é
apresentada a estrutura desta dissertação.
2
1.2 A Abordagem de Engenharia Reversa e a Realidade Virtual
O objetivo da engenharia reversa é obter um modelo em um nível mais alto de abstração
do sistema existente. Geralmente a partir do código fonte, que é o único material disponível,
recupera-se um modelo de projeto para completo entendimento desse sistema. Para o objetivo de
mudança de paradigma de desenvolvimento com ou sem troca da linguagem de programação, a
necessidade é recuperar um modelo de análise, e não de projeto, como citado anteriormente. Por
exemplo, a partir de um sistema implementado em linguagem procedural, deseja-se submetê-lo a
um processo de reengenharia com mudança de linguagem para uma linguagem orientada a
objetos (OO). Nesse caso, há necessidade de primeiramente criar-se um modelo de análise com
esse paradigma para em seguida fazer o desenvolvimento do projeto, e só daí passar à fase de
implementação.
O usuário pode desejar alterar, em um primeiro momento, somente a interface e continuar
com o código fonte existente. A engenharia reversa pode auxiliar esse usuário, permitindo que
uma nova interface seja acoplada a esse sistema. Ou seja, é possível recuperar um modelo com
alto grau de abstração desse sistema para então prepara-lo para ganhar nova interface com o
usuário. Assim, o sistema passa por uma manutenção adaptativa (Pressman, 1997) apoiada na
documentação recuperada com o processo de engenharia reversa.
Este trabalho aplica um processo de engenharia reversa OO chamado Fusion
RE/I(Penteado, 1996) (Penteado et al, 1998), que a partir de códigos procedurais obtém modelos
de análise orientados a objetos, baseado na notação Fusion e UML.
As classes são recuperadas a partir das estruturas de dados existentes no código fonte.
Abstraindo-se essas estruturas, extrai-se as classes que realmente representam o sistema. Em
seguida, os use cases são elaborados permitindo o completo entendimento da funcionalidade do
sistema. É importante ressaltar que os métodos considerados são aqueles correspondentes aos
procedimentos implementados, com pequenas alterações para garantir as características OO.
Após a recuperação dos modelos de análise orientados a objetos, é realizado o processo
de reengenharia, no qual a funcionalidade e a linguagem de implementação do sistema original
são preservadas. Tal processo é chamado de segmentação (Penteado, 1998).
Para ilustrar a abordagem proposta, primeiramente foi analisada a possibilidade de alterar
a interface do sistema existente utilizando os recursos de RV, como proposto em (Silva, 1999),
sem alterar a linguagem de programação original, utilizando somente o modelo de análise OO
3
recuperado pela engenharia reversa (Penteado, 1996) (Penteado et al, 1996). Em seguida o
mesmo procedimento foi realizado utilizando a segmentação (Penteado, 1998). Por fim, o sistema
estudado foi implementado em uma linguagem de programação OO, Java®, e esse sistema
também recebeu uma interface com RV. Todo o processo de desenvolvimento de interfaces nos
três casos citados foi feito utilizando o GaCIV como apoio automatizado. O GaCIV utiliza
gabaritos configuráveis para o desenvolvimento de interfaces avançadas com RV.
Os projetos com interfaces avançadas, envolvendo recursos tridimensionais (3D) e RV,
são geralmente mais difíceis de se construir do que interfaces convencionais (textuais e WIMP).
O procedimento mais comum para desenvolver interfaces consiste na geração de um protótipo,
que é avaliado e reconstruído iterativamente, até a interface final ser projetada. É interessante
ressaltar a utilização do paradigma OO no desenvolvimento de sistemas interativos, cujo
componente de interface apresenta-se em destaque (Lucena & Liesenberg, 1997). Isso porque a
característica da modularização de projeto, apresentada nesse paradigma, leva à menor carga de
programação, devido à possibilidade de reutilização de código e modularização de projeto. Essa
característica garante maior flexibilidade ao processo de desenvolvimento desses sistemas.
Estudos da IBM, encontrados em (IBM, 2000a) (IBM, 2000b), comprovam a aplicação da
orientação a objetos no desenvolvimento de interfaces.
Entretanto, ainda existe uma carência de diretivas, métodos, técnicas e ferramentas
computacionais de alto nível, de suporte à aplicação de RV, que auxiliem o projetista de
interfaces no desenvolvimento de suas tarefas junto ao usuário, bem como na sua interação com o
engenheiro de software, garantindo a qualidade de seu projeto (Silva, 1998), e utilizando as
técnicas mais avançadas para desenvolvimento de interfaces, como a RV, dentro do paradigma da
orientação a objetos para desenvolvimento de sistemas.
1.3 Relevância do Trabalho
Nos estudos feitos até então, tem-se observado que o paradigma OO (Pressman, 1997)
ampara não apenas o desenvolvimento do componente de aplicação dos sistemas interativos, mas
também o da interface, visto que a prototipação na Implementação está se tornando cada vez mais
viável graças à menor carga de programação, devido à existência de classes e objetos,
reutilização de código e modularização de projeto, dentre outros.
4
A proposta deste projeto é verificar se uma reengenharia de sistemas com a mudança de
paradigma procedural para o paradigma da orientação a objetos facilita o desenvolvimento de
interfaces avançadas para tais sistemas, através do uso do ambiente GaCIV. Além disso, é
também estudada a influência do paradigma de desenvolvimento e implementação do sistema na
reengenharia de interfaces para interfaces com RV, considerando características de usabilidade
das interfaces resultantes. É esperada a confirmação da adequação do paradigma da orientação a
objetos no processo de engenharia reversa e reengenharia de sistemas, visando a implementação
de interfaces avançadas com recursos de RV.
O resultado esperado deste trabalho é fornecer diretrizes para que o engenheiro de
software e o projetista de interface, ao utilizarem o GaCIV no apoio à reengenharia de interfaces
com recursos de RV, reconheçam as vantagens existentes quando o código da aplicação for OO.
Com isso, espera-se, também, comprovar que o processo de reengenharia de interfaces apoiado
pelo GaCIV se torna mais eficiente se o sistema em questão foi desenvolvido sob o paradigma
OO.
Durante este projeto foi realizada a engenharia reversa e reengenharia das interfaces de
um sistema exemplo, implementado em Clipper, para que fossem feitas análises comparativas das
diversas versões do sistema - legado, segmentado e implementado em uma linguagem OO,
conforme planejado inicialmente. Tais análises foram realizadas considerando o desenvolvimento
de novas interfaces através do GaCIV para cada versão do sistema exemplo, verificando a
viabilidade do uso do ambiente GaCIV para o apoio ao processo de engenharia reversa e
reengenharia.
1.4 Objetivos
Buscou-se investigar sistemas que foram desenvolvidos pela abordagem procedural,
submetê-los ao processo de engenharia reversa e elaborar diretivas seguras para facilitar o
processo de construção de novas interfaces com os recursos de RV.
Este estudo visa perceber as vantagens e desvantagens em integrar uma nova interface
com recursos de RV através do ambiente computacional GaCIV com os sistemas: 1) legados, que
possuem documentação obtida por um processo de engenharia reversa OO; 2) segmentados, que
têm o código implementado na linguagem procedural com características OO inseridas a partir
5
dos modelos obtidos com a engenharia reversa OO; 3) submetidos ao processo de reengenharia
com a mudança de paradigma de desenvolvimento, como de linguagem de programação para OO.
Além disso, também foram avaliados a usabilidade e funcionalidade das interfaces resultantes.
Outro objetivo desse trabalho é oferecer ao usuário, através do ambiente computacional
GaCIV, um apoio na elaboração de suas interfaces 3D. A proposta do ambiente é oferecer os
recursos de RV de forma mais acessível e prática, em módulos semi-prontos, agilizando o
processo de aplicação da RV no desenvolvimento de interfaces. Espera-se, assim, colaborar
efetivamente com os projetistas de interfaces e engenheiros de software no desenvolvimento de
sistemas utilizando RV.
O mesmo sistema-exemplo foi utilizado em três versões: legado, segmentado e OO. Com
esse procedimento buscou-se verificar o apoio efetivo da orientação a objetos no
desenvolvimento de interfaces com recursos de RV. Essa verificação se deu em dois níveis: de
produto nas diferentes versões e de processo apoiado pelo GaCIV.
O objetivo de ter produtos em diferentes versões é para poder analisar a qualidade da
interface em cada uma delas. Assim, é possível analisar se há ganho em qualidade das interfaces
geradas para sistemas OO.
De acordo com a proposta do GaCIV o processo de reengenharia da interface sob o
paradigma OO tem suas vantagens em relação a outros paradigmas. Essa afirmação pode ser
verificada a partir dos resultados obtidos.
A figura 1.1 exibe a idéia geral desenvolvida nesse processo de integração. Os retângulos
representam o sistema utilizado em cada uma das versões a serem analisadas. As elipses exibem
os produtos obtidos após um processamento. O retângulo com borda dupla representa o ambiente
computacional utilizado para a integração proposta. As setas tracejadas representam o
processamento realizado para a geração de um produto e as setas contínuas representam a
integração entre ambiente e os demais componentes.
6
sistema
legado
Modelos
da EROO
Modelos
de
Projeto OO
Código Legado
+ Nova Interface 1
GaCIV
sistema
segmentado
Código Legado
+ Nova Interface 2
Sistema OO
Código Legado
+ Nova Interface 3
FIGURA 1.1 – Integração Proposta
A documentação obtida após a engenharia reversa auxilia o engenheiro de software a dar
manutenção no sistema legado e, se ele decidir pela mudança de linguagem de programação, essa
documentação apóia a fase de projeto.
1.5 Estrutura da Dissertação
O trabalho descrito neste capítulo é apresentado detalhadamente nesta dissertação da
seguinte forma: o capítulo 2 dá uma visão geral da aplicação da tecnologia de RV em interfaces;
o capítulo 3 apresenta o processo de reengenharia de interfaces e seu papel na manutenção de
sistemas legados, além de métodos e metodologias para a prática desse processo; no capítulo 4 é
apresentado o ambiente GaCIV de desenvolvimento de interfaces com RV, sua estrutura e
funcionamento; o estudo de caso realizado é detalhado no capítulo 5 e analisado no capítulo 6; no
capítulo 7 são apresentadas as conclusões obtidas, diretivas para o processo de reengenharia de
interfaces para interfaces com RV e trabalhos futuros.
7
Capítulo 2 – Interfaces com Realidade Virtual
2.1 Considerações iniciais
Durante o período entre a década de 1950 e 1960, a primeira geração de “interfaces” era
formada por cartões perfurados e computadores que só funcionavam em modo batch, sem haver
interação real entre homem e máquina. A segunda geração de interfaces, durante o início da
década de 1960, foi marcada pelo uso de mainframes e minicomputadores, através da técnica de
divisão de tempo (“timesharing”) com monitores alfanuméricos. Usuários podiam então interagir
com o computador digitando comandos com parâmetros. A geração seguinte surgiu das pesquisas
da Xerox PARC durante a década de 1970 (Van Dam, 1997) (Myers, 1996). Estações de trabalho
ligadas em rede com monitores gráficos e WIMP GUI’s (Windows, Icons, Menus, Pointin Device
– Graphical User Interface), que segundo Van Dam (1997) são interfaces gráficas do usuário
baseadas em janelas, ícones, menus, e um dispositivo de seleção, tipicamente um mouse.
As interfaces do tipo WIMP se popularizaram rapidamente e se tornaram dominantes no
mercado por mais de duas décadas. Em relação às gerações anteriores, trata-se de uma revolução
que permitiu o acesso a computadores por usuários não especializados (crianças, leigos em
computação, etc), além de trazer à tona questões sobre a importância da interface no
desenvolvimento de sistemas. Apesar do sucesso comercial, muitos problemas são associados às
interfaces estilo WIMP, alguns deles são citados por Van Dam (1997):
-
Quanto mais complexa a aplicação, mais difícil aprender e usar a interface devido ao
grande número de widgets e funcionalidades diferentes. O uso de cada widget
separadamente é fácil. Porém, quando considerados em conjunto, a interação ganha
complexidade;
-
Usuários focam a maior parte de sua atenção na interface e não na tarefa que pretendem
realizar;
-
Quando a informação é 3D, o mapeamento entre tarefas 3D e controles 2D não é natural;
-
Interfaces WIMP não permitem a exploração de todas as formas de interação humana,
deixando de lado, por exemplo, a fala, a audição e o toque.
Segundo Van Dam (1997), a quarta geração de interfaces é formada por interfaces que
implementam pelo menos uma interação independente de widgets WIMP. Essas interfaces são
chamadas de Pós-WIMP e têm por objetivo:
8
-
Envolver diversos sentidos humanos em paralelo;
-
Tornar a interação mais natural e intuitiva;
-
Permitir a interação de múltiplos usuários simultaneamente;
-
Aumentar a liberdade em relação à proximidade física do usuário e sistema.
A tecnologia de interação de quarta geração mais difundida é a RV. Trata-se de uma
tecnologia que tem como principal característica exploração de diversos sentidos do usuário para
causar uma sensação de imersão do usuário em um ambiente virtual onde o usuário manipula
objetos e realiza tarefas de maneira semelhante à realizada no mundo real (Weiss & Jessel, 1998).
Dessa forma a RV torna a interação do usuário mais intuitiva e natural atingindo muitos aspectos
de usabilidade desejados para interfaces de sistemas interativos.
As mudanças propostas pela RV e outras tecnologias de interface Pós-WIMP causam um
impacto direto à forma de desenvolvimento de interfaces. A implementação de tais interfaces
ainda apresenta alto grau de complexidade e custo em relação às interfaces WIMP.
Os conceitos relacionados a RV são apresentados na seção 2.2; na seção 2.3 são
detalhados aspectos de usabilidade relacionados à RV; e na seção 2.4 são encontradas
considerações sobre o desenvolvimento de interfaces com RV.
2.2 Conceituação
As características principais de interfaces com RV incluem gráficos 3D e um modelo de
ambiente, representando vida real ou estruturas e lugares artificiais. Um usuário interage com o
ambiente virtual navegando dentro dele. As percepções e interações com o ambiente podem ser
mapeadas a partir da realidade utilizando estímulos multi-sensoriais (Bowman et al, 2001).
O ambiente virtual é um dos principais componentes da interface com RV e envolve: o
usuário, que controla o ponto de vista da navegação; agentes, que são personagens ou objetos do
mundo virtual que podem executar ações independentemente do usuário; e objetos que povoam o
ambiente.
Outro importante componente é a interação básica oferecida pelas interfaces com RV:
navegação e interação com objetos. As interações com objetos de interfaces com RV não são
padronizadas, possibilitando diversas opções de interação: segurar objetos, rotaciona-los, movelos e manipulação para modifica-los. Em (Bowman et al, 2001) é apresentado uma pesquisa do
estado-da-arte das tecnologias e técnicas de interação utilizadas em interfaces com RV.
9
Freqüentemente as interfaces com RV envolvem novos dispositivos de hardware e
avançadas tecnologias, específicas para prover diferentes possibilidades de interação, tais como:
-
joysticks, mouse 3D e magics wands podem ser utilizados como dispositivos de
entrada para realização da navegação através do ambiente virtual em diferentes grausde-liberdade;
-
head-mounted displays podem ser usados como dispositivos de saída para
visualização do ambiente virtual de forma estereoscópica reforçando a imersão do
usuário no sistema;
-
dispositivos de force feedback, usados para simular sensação tátil ao usuário;
-
dispositivos de som estéreos permitem percepção de sons dinâmicos no ambiente.
Ambientes virtuais podem ser diferenciados de acordo com seu relacionamento com o
mundo real e o hardware utilizado (Bolzoni, 1994)1 apud (Kaur, 1998):
-
Ambientes imersivos utilizam head-mounted displays ou outro tipo de dispositivo de
visualização para aumentar a sensação de imersão do usuário;
-
Ambientes desktops ou não-imersivos utilizam monitores comuns e permitem que o
usuário mantenha contato com o mundo real;
-
Ambientes projetados, tais como as “Cavernas Virtuais” onde o ambiente virtual é
projetado;
-
Ambientes aumentados utilizam objetos reais com características virtuais especiais,
geralmente apresentadas através de um visualizador translúcido.
Ambientes imersivos têm o potencial de prover ao usuário maior envolvimento com o
ambiente virtual. Entretanto isola-o do mundo real, dificultando utilização de artefatos do mundo
real. Ambientes desktop, ou RV não-imersiva, permitem que o usuário navegue e interaja em um
ambiente 3D, mas sem causar a mesma sensação de imersão causada pela técnica citada
anteriormente. O usuário pode visualizar o ambiente virtual em computadores comuns,
interagindo através do teclado, mouse comum ou mouses 3D, por exemplo. Ambientes projetados
permitem que o usuário compartilhe sua experiência com outros usuários. Ambientes
1
(Bolzoni, 1994) Bolzoni M. L. G., Eliciting a context for rules of interaction: a taxonomy of metaphors for humanobjects communication in virtual and synthetic environments. In: 2nd UK Virtual Reality Interest Group
Conference, Theale, Reading, 1994, Proceedings. UK Virtual Reality-Special Interest Group and Contributors, pp
18-87.
10
aumentados, ou Realidade Aumentada, melhoram a visão do mundo real com informações extras,
porém requer exata correlação entre imagem real e informação superposta.
2.2.1 Comparação entre interfaces com RV e outros estilos de interfaces
A geração anterior de interfaces, interfaces WIMP, é caracterizada principalmente pela
característica de Manipulação Direta. Manipulação Direta (MD) é o termo utilizado para se
referir a uma classe de interfaces gráficas que permitem operar o sistema “diretamente” usando
ações manuais em vez de comandos textuais. Essa classe de sistemas mudou o paradigma da
interação humano-computador, do “diálogo” de comandos para a manipulação de elementos
visuais.
Comparando a nova geração, representada aqui pela interface com RV, e interfaces de
MD, algumas diferenças são evidentes:
-
Interfaces com RV são estruturadas em forma de gráficos 3D, acrescentando uma
dimensão ao estilo de interfaces de MD;
-
A interface com RV apresenta metáforas para a vida real ou ambiente artificial com
uma organização razoavelmente estática em contraposição às interfaces de MD que
apresentam continuamente objetos 2D relevantes às tarefas do usuário em um espaço
gráfico também 2D;
-
Interfaces de MD tem um paradigma de interação padrão estabelecido, enquanto
interfaces com RV precisam amadurecer esse conceito;
Entretanto, as interfaces com RV podem ser consideradas como uma continuação do estilo
conhecido como MD, pois as interações realizadas com objetos da interface com RV
compartilham algumas similaridades com o estilo anterior, como, por exemplo, selecionar e
mover objetos.
Interfaces com RV são semelhantes a hipertextos em relação à navegação do usuário. Nos
dois estilos de interfaces, o usuário precisa navegar buscando os objetos de seu interesse. As
interfaces com RV são exploratórias, com poucas tarefas estruturadas para realização de tarefas.
11
2.2.2 Aplicações
Ambientes com RV provêem mundos virtuais gerados por computador permitindo que o
usuário o explore e o manipule. Eles têm sido usados para diversas áreas específicas de aplicação:
-
Artes e entretenimento, na confecção de jogos e cinemas 3D;
-
Propaganda, em stands virtuais para atrair a atenção de clientes;
-
Teleoperação, criando interfaces realistas para controle de realização de tarefas
remotas através de robôs;
-
Telepresença ou Ambientes Virtuais Colaborativos, permitindo que pessoas distantes
geograficamente possam se comunicar e interagir;
-
Projeto e avaliação, como por exemplo, modelos virtuais para provar roupas ou provar
saídas de emergência de um prédio, através de seu modelo virtual;
-
Educação. Ambientes virtuais permitem que o usuário aprenda sobre um assunto
experimentando-a
diretamente,
como
por
exemplo
aprender
sobre
DNA’s
visualizando e manipulando representações virtuais de modelos virtuais de um DNA;
-
Treinamento, ambientes virtuais podem servir para simular operações de guerra,
situações de vôo, com o intuito de prover ambientes realistas nos quais podem ser
praticadas algumas habilidades;
-
Tratamentos para fobias diversas e psicoterapia para pacientes, ajudando-os a superar
problemas através da exposição gradual a situações mais difíceis;
-
Visualização de informação, provendo modelos 3D interativos de conjunto de
informações, adicionando possibilidade de interação e exploração.
Apesar das diversas aplicações possíveis, não há estudos conclusivos de quais domínios
de aplicações obtêm maiores benefícios quando utiliza interface com RV.
2.3 Características de Usabilidade em Sistemas com Interfaces com RV
Segundo Bryson (1995)2 apud (Kaur, 1998), ambientes virtuais reduzem a distância
psicológica ao representar domínios de tarefas de forma mais realística, facilitando interações
mais naturais. Em contrapartida, alguns problemas comumente encontrados em interfaces com
RV levam o usuário a sentir dificuldades em interagir com o sistema, causando frustração e
2
(Bryson S. 1995) Approches to the sucessful design and implementation of VR. In: Virtual Reality Applications,
ed. por R.A. Earnshaw, J. A. Vince e H. Jones (London: Academic Press).
12
queda na usabilidade da interface: desorientação, dificuldades para reconhecimento e confusão
causada por interações não naturais. Isso ocorre em grande parte porque se espera que as
interfaces com RV reflitam fielmente a realidade o que é ainda impossível devido a limitações
tecnológicas. Para atacar problemas desse tipo, Kaur (1998) propõe uma série de limitações para
que a interface não reflita idealmente a realidade e sim apresente soluções coerentes com as
limitações tecnológicas, tais como:
-
optar por limitações nas interações, como ausência de feedback tátil;
-
substituições, como o uso de gestos para a navegação ao invés de movimentação de
todo o corpo;
-
dar “poderes” ao usuário, por exemplo, permitir que o usuário voe no ambiente
virtual;
As soluções dadas trazem à tona questões de usabilidade tais como:
-
qual o nível de dificuldade que o usuário vai encontrar para utilizar seus “poderes”;
-
as substituições de interação podem variar muito de uma interface com RV para outra
devido à falta de padrões de interação;
-
quais são as técnicas de interação desejadas e quais são dispensáveis para cada
domínio de aplicação, de forma que o usuário possua um vocabulário suficiente de
técnicas de interação para se sentir envolvido no sistema.
A compreensão dos sentidos envolvidos para a realização das tarefas do usuário pode ser
a solução durante o desenvolvimento de interfaces com RV.
Além disso, é importante compreender e representar de forma adequada o modelo mental
que o usuário tem de suas tarefas através de metáforas. Um conjunto de interações pode ser bemsucedido se for bem comunicado ao usuário através da metáfora escolhida.
O teste de usabilidade de interfaces com RV imersiva junto ao usuário pode apresentar
diversas dificuldades, tais como a dificuldade de compartilhar uma mesma experiência de
interação
entre o usuário e o avaliador e obter informações úteis a partir dela. Possíveis
problemas dessa natureza, entretanto, devem servir como estímulo ao teste de interfaces com RV
junto ao usuário, pois indicam a necessidade de treinamento especial para avaliadores e, até
mesmo, criação de novas ferramentas e processos para o teste de usabilidade nesse ambiente
(Nielsen, 1993).
13
Nielsen (1993) indica a possibilidade de uso de avaliação com base em heurísticas de
usabilidade para RV. Atualmente pode-se encontrar diversas heurísticas para aspectos específicos
de usabilidade (Hinckley et al, 1994) (Bricken, 1990) (Hannaford & Venema, 1995), porém
poucas abrangem todos os aspectos em conjunto como em (Gabbard, 1997).
2.4 Desafios no Desenvolvimento de Sistemas com Interfaces com RV
Da mesma maneira como ocorre com heurísticas de usabilidades, atualmente podem ser
encontradas na literatura diretivas para o desenvolvimento de diversos aspectos específicos de
interfaces com RV, porém poucas abrangem todos os aspectos em uma só abordagem como
(Kaur, 1998). Isso acontece devido à complexidade da tecnologia RV.
O desenvolvimento de interfaces com RV envolve os seguintes aspectos:
-
desenvolvimento do ambiente virtual; o ambiente virtual deve ser baseado em um
domínio do mundo real utilizando metáforas para representação desse domínio. É
necessário determinar com qual nível de detalhamento de gráficos o ambiente deve ser
representado;
-
a representação do usuário deve ser coerente com a percepção própria do usuário;
-
agentes são componentes da interface que podem servir simplesmente como
instrutores para os usuários durante a navegação no ambiente 3D mas também podem
executar tarefas mais complexas como seguir e auxiliar o usuário em suas tarefas;
-
criação de objetos para povoar o ambiente virtual de forma a diferenciar objetos
interativos de não interativos;
-
realismo; objetos podem ser representados em vários níveis de realismo dependendo,
por exemplo, da importância do objeto para a tarefa realizada pelo usuário;
-
modelagem de outras modalidades de interação, como sonora e tátil, como formas
alternativas de feedback;
-
navegação do usuário, aspectos em relação aos graus de liberdade permitidos para
movimentação e velocidade;
-
interação com objeto; diversos métodos de interação podem ser vistos em (Bowman et
al, 2001) para seleção e manipulação de objetos. Como dito anteriormente, as
interações com objetos em interfaces com RV não possuem padrão e por isso podem
14
variar muito de um projeto para outro, sendo portanto um dos aspectos mais
complexos no desenvolvimento de interfaces com RV;
-
em ambientes colaborativos, deve-se criar métodos de comunicação entre os usuários;
-
integração entre dispositivos de entrada e saída e mapeamento de interação do usuário
para esses dispositivos; em (Bowman et al, 2001) são apresentados opções de
dispositivos utilizados para entrada e saída.
Apesar da complexidade do desenvolvimento da interface com RV, não existe na
literatura modelos ou métodos específicos para esse processo, tornando mais difícil a criação de
interfaces dessa natureza. O engenheiro de software precisa escolher entre os inúmeros modelos e
métodos de HCI, adaptando-os de acordo com as necessidades do projeto, para representação do
modelo de interação, modelo do ambiente virtual e dispositivos de entrada e saída utilizados.
2.5 Considerações Finais
Neste capítulo foram apresentados conceitos relacionados à tecnologia RV. Devido aos
diferentes e complexos aspectos dessa tecnologia, é necessário dar maior atenção à usabilidade e
implementação dessas interfaces.
O uso de interfaces com RV pode resolver muitos problemas de usabilidade encontrados
em sistemas utilizando outros estilos de interface. Para que sistemas com interfaces antigas
possam utilizar essa nova tecnologia é interessante realizar um processo de reengenharia de
interfaces, como é mostrado no capítulo 3.
15
Capítulo 3 - Reengenharia de Interfaces
3.1 Considerações iniciais
Neste capítulo são apresentados os estudos realizados buscando soluções para o uso de
métodos e modelos na reengenharia de interfaces para interfaces com RV. Na seção 3.2 é
apresentada uma visão da reengenharia de sistemas no contexto de usabilidade e tópicos sobre a
reengenharia de interfaces para interfaces com RV são abordados na seção 3.3. A seção 3.4
apresenta algumas considerações finais.
3.2 O processo de reengenharia de sistemas no contexto de usabilidade
Sistemas legados são representados muitas vezes por sistemas gerados para uma
arquitetura baseada em mainframes, utilizando técnicas de desenvolvimento não estruturadas e
linguagens de programação obsoletas. A estrutura do sistema muitas vezes se apresenta
deteriorada por mudanças e adaptações mal documentadas. Entretanto, esses sistemas não
raramente são vitais para apoio aos negócios, pois reúnem todo o conhecimento e dados sobre o
domínio de uma aplicação.
Existem diversas opções para recuperar e gerenciar sistemas legados. Algumas soluções
típicas são:
-
descartar o sistema legado e construir um novo sistema equivalente;
-
utilizar o sistema como componente de um sistema maior;
-
continuar realizando manutenções;
-
modificar o sistema, aumentando seu período de vida.
Modificações podem variar de simplificação do sistema legado à manutenção preventiva
(re-documentação e re-estruturação), ou mesmo manutenções adaptativas, tais como: redesenvolvimento da interface, encapsulamento e migração.
A reengenharia para melhorar a compreensão e manutenibilidade de sistemas é uma
prática aceita pela comunidade de manutenção de software. A reengenharia de sistemas, segundo
a taxonomia de Chikofsky e Cross II (1990), é “o exame e alteração de um sistema para
reconstituição em uma nova forma, e subseqüente implementação da nova forma”. Fica evidente,
16
portanto, que a reengenharia de sistemas implica em uma fase de engenharia reversa para a
recuperação de uma visão abstrata do sistema e uma fase de transformação ou re-interpretação
dessa visão seguida da implementação da nova visão do sistema.
Os principais objetivos da reengenharia, segundo Sneed (1995) são:
-
Aumentar a manutenibilidade;
-
Migrar o software existente para uma plataforma melhor ou de custo mais baixo.
-
Atingir maior confiabilidade.
-
Modificar a estrutura do sistema existente para facilitar futuras adições de
funcionalidades.
Segundo Pressman (1997), além desses objetivos, pode-se ainda usar a reengenharia para
mudança de paradigma da implementação do sistema e para mudança de interfaces.
A reengenharia de interfaces pode tornar interfaces de sistemas legados mais amigáveis e
dessa forma aumentar o tempo de vida do sistema (Merlo, 1995). Em (Vanniamparampil et al,
1995) a reengenharia de interfaces é definida como a realização de um novo projeto de interface a
partir de uma interface existente para melhorar a performance e satisfação do usuário, além de
diminuir o tempo de aprendizagem e a taxa de erros do usuário. Atualmente, o termo usabilidade
substitui o termo “amigável” (“user friendly”) e é usado como sinônimo para características
desejáveis em um sistema para que eles correspondam às expectativas de performance do
usuário. Usabilidade define um conjunto de características desejáveis para que a interface possa
prover acesso às funções de uma aplicação de modo que reflita a maneira de pensar do usuário
(Wood, 1998). Isso requer que a aplicação não só forneça suporte para aspectos necessários ao
trabalho do usuário, mas também forneça meios para eles interagirem com o sistema de forma
intuitiva e natural (Wood, 1998).
Para muitas organizações, o re-desenvolvimento completo dos sistemas legados não é
uma opção, forçando-os a optar por alternativas para lidar com o sistema legado. Uma das opções
é a realização da reengenharia da interface para melhorar sua usabilidade, prolongando seu tempo
de vida.
3.3 Métodos para apoio à reengenharia de interfaces
Nessa seção são apresentados diversos métodos e abordagens para a aplicação de
reengenharia de interfaces, incluindo a reengenharia de interfaces com RV.
17
3.3.1 Abordagens para o processo de reengenharia de interfaces
Apesar das diferentes técnicas desenvolvidas para a realização da reengenharia de
interfaces, existem duas abordagens principais: o encapsulamento (wrapping) da interface com
uma nova interface mais acessível; e o re-desenvolvimento, que significa a re-escrita do código
do sistema legado para aperfeiçoamento da interface. Como constatado em (Bisbal et al, 1999), a
classificação das abordagens de processos de reengenharia de sistemas nem sempre é precisa
pois, por exemplo, a migração de um software para uma nova plataforma de hardware pode
envolver encapsulamento de parte do sistema, manutenção de outra parte e re-desenvolvimento
de outra.
O encapsulamento implica na criação de uma nova camada de interface que se sobrepõe à
interface original do sistema tornando-se um intermediário entre a antiga interface e o usuário ou
outras aplicações. Essa nova interface transforma os dados recebidos pela antiga interface para
ser apresentada em um novo estilo de interface, mudando o estilo de apresentação dos dados,
estilo de interação com o usuário ou para se adaptar a novas arquiteturas computacionais (Sneed,
2001).
O re-desenvolvimento das interfaces de um sistema legado é um processo que envolve a
identificação, compreensão e separação do código da interface original do código da aplicação,
substituindo-a pela nova interface.
Comparando os processos de reengenharia para encapsulamento, manutenção e redesenvolvimento, o encapsulamento é o processo que causa menos impacto no código do sistema
legado, enquanto o re-desenvolvimento é o processo que resulta em maiores alterações no código,
além de envolver maiores esforços e custos. O processo de manutenção fica entre os extremos,
encapsulamento e re-desenvolvimento, em relação a esforços e impacto no código da aplicação.
Isto acontece porque, dependendo da manutenção necessária, a interface pode ser parte
encapsulada ou re-desenvolvida (Bisbal et al, 1999).
Um exemplo de reengenharia de interfaces para a migração de sistemas legados para uma
nova arquitetura de hardware pode ser vista em (Sneed, 2001). Nesse caso, técnicas de
encapsulamento foram aplicadas na interface de um sistema legado desenvolvido originalmente
em COBOL de forma a torna-lo acessível através da tecnologia XML em uma Intranet ou mesmo
pela Internet. Com as técnicas utilizadas, o sistema legado, desenvolvido originalmente apenas
para acesso local, pôde ser reutilizado diminuindo custos e tempo de desenvolvimento
18
necessários para uma reengenharia de todo o sistema. Para essa abordagem pouco código do
sistema original foi modificado, apenas foram criadas novas interfaces XML para gerar
documentos XML como saída e aceitar documentos XML como entrada de dados.
Modelos e métodos para a abordagem de re-desenvolvimento das interfaces do sistema
legado são apresentados em (Merlo et al, 1993), que utiliza a representação AUIDL para esse
processo; e em (Moore, 1996) e (Moore, 2002), onde é apresentado o ambiente MORPH para
automatização do processo de reengenharia de interfaces.
A tentativa de compreensão de códigos-fonte de sistemas legados pode significar grandes
gastos econômicos e de tempo devido à complexidade e extensão de códigos desse tipo, a não ser
que seja utilizada alguma ferramenta de apoio automatizado. Além disso, dificuldades como a
ausência dos desenvolvedores e usuários do sistema original, códigos acrescentados sem
documentação ou a existência apenas da versão executável do sistema legado podem tornar essa
abordagem impraticável (Stroulia et al, 1999).
Em (Stroulia et al, 1999) é encontrada uma técnica de reengenharia de interfaces onde é
utilizada a execução do sistema pelo usuário como fonte de informações sobre o sistema. A partir
dessa execução, baseando-se nas interações realizadas pelo usuário durante o diálogo com o
sistema legado, é construído um “mapa” da interface do sistema em termos de telas e transições
entre elas. Esse diagrama de transição de telas é usado para representar as telas navegadas pelo
usuário para realizar sua tarefa. Juntamente com o fluxo de informações trocados entre usuário e
sistema, o diagrama de transição de telas é analisado e utilizado posteriormente para o
desenvolvimento da nova interface gráfica. Todo o processo é apoiado por ferramentas
automatizadas e gera como resultado uma interface gráfica dinâmica em HTML.
Em (Tucker & Stirewalt, 1999) é detalhado um processo de reengenharia de interfaces
para sistemas “batch” com pouca interação de forma a torna-los mais interativos. Nesse tipo de
sistema o usuário entra com um comando “batch” e geralmente obtém arquivos de dados
complexos resultantes de funções também complexas dificultando o seu entendimento. Segundo
Tucker e Stirewalt (1999), a usabilidade desses sistemas pode ser melhorada se o usuário tiver
mais controle e puder filtrar esses dados. A solução dada é a modularização do sistema e da
interface para expor dados intermediários ao usuário. Com isso o usuário obtém maior controle
dos dados durante a execução do programa. Esse processo exige total re-desenvolvimento do
sistema legado.
19
3.3.2 Reengenharia de interfaces para interfaces com RV
A reengenharia de interfaces para interfaces com RV, assim como a engenharia avante de
interfaces com RV, apresenta maior complexidade do que outros tipos de interfaces, por envolver
mapeamento de interfaces com características de apresentação e interação limitadas e
padronizadas para uma tecnologia relativamente nova e não padronizada, com diversos estilos de
interação e possibilidades de configuração de dispositivos de entrada e saída. Interfaces com RV
extrapolam o paradigma de Manipulação Direta, permitindo inúmeras técnicas de interação,
incluindo sons, feedback tátil e olfativo, dificultando a representação em modelos tradicionais de
interação, como pode ser visto em (Willans & Harrison, 2001).
Sistemas interativos legados, tais como aplicações comerciais para controle de estoque,
gerenciamento de estabelecimentos comerciais, além de sistemas de empréstimos/consultas a
bibliotecas entre outros, trabalham, na sua maioria, com informações textuais e acesso a bancos
de dados. Para que esse tipo de informação seja apresentada em interfaces com RV, é necessário
que se faça o re-desenvolvimento da interface da aplicação original, possibilitando o tratamento
dessas informações para apresentação em forma de gráficos 3D. Essa abordagem pode esbarrar
no simples fato de que algumas informações são mais facilmente observadas na forma de textos
ou gráficos 2D, como mostrado em (Nielsen, 1998).
Outra solução é a criação de interfaces mistas que utilizam recursos de interfaces com RV
juntamente com recursos 2D tais como botões, menus popup, caixas de textos etc. Essa solução
possui a vantagem de manter alguns padrões de interação e visualização de dados 2D utilizados
em sistemas legados, dentro de um ambiente mais envolvente para o usuário.
Este trabalho propõe o encapsulamento do sistema legado com interfaces com RV de
forma que as novas interfaces sejam utilizadas para substituir as camadas mais altas de abstração
da árvore de menus de sistemas legados, isto é, telas de interface usadas apenas para classificar as
funcionalidades do sistema legado. Essas telas são úteis para a organização das diversas
funcionalidades, porém acabam ficando entre o usuário e suas tarefas. Além disso, acredita-se
que o maior poder de representação de gráficos 3D podem melhorar a usabilidade do sistema ao
facilitar o reconhecimento das tarefas do usuário.
A reengenharia para interfaces com RV apresenta possibilidades de incrementar metáforas
de representação das funcionalidades não só devido ao poder de representação, mas também
pelos diversos dispositivos de entrada e saída possíveis para interação com usuário. É
20
interessante, portanto, que o engenheiro de software tenha uma visão do domínio do sistema
independente de modelos de projeto usados na implementação do sistema legado. Isso deve-se à
possibilidade de que a re-implementação das interfaces do sistema fuja radicalmente dos padrões
de interação utilizados para sistemas textuais ou WIMP. Entretanto, é importante ressaltar que o
modelo mental do usuário em relação às suas tarefas não pode ser descartado e sim seguido como
diretiva para todo o projeto com RV.
Além disso, devido à falta de padrões no uso de tecnologias e estilos de interação em
interfaces com RV, cabe ao engenheiro de software decidir quando realizar mudanças drásticas
de estilo de interação e quando adaptar padrões existentes para tecnologias 2D de forma a
facilitar a adaptação dos usuários do sistema legado à nova interface. Outro fator importante para
a decisão do engenheiro de software quanto ao uso dos estilos de interação e tecnologias de RV é
o impacto causado no sistema legado. Quanto mais radical for a mudança da interface, maior será
o impacto causado no sistema original, podendo causar a necessidade de reengenharia do próprio
sistema, no pior caso, para adaptar os formatos dos dados de entrada e saída para a nova
interface, o que tornaria o processo custoso e possivelmente inviável.
Não foram encontrados na literatura processos específicos para a realização de
reengenharia de interfaces para interfaces com RV. Entretanto, diversos métodos e modelos
foram encontrados para a engenharia reversa e a engenharia avante de interfaces em geral. A
aplicabilidade desses métodos e modelos em processos, visando o uso de RV, foi analisada e os
resultados obtidos são apresentados na seção 3.3.3 a seguir.
3.3.3 Revisão de Métodos e Modelos para apoio à reengenharia de interfaces
Desde a constatação do importante papel representado pela interface em sistemas
interativos durante a Segunda Guerra Mundial (ACM, 1999), diversas teorias, modelos e métodos
foram criados para o estudo e desenvolvimento de interfaces. Como mostrado em (Assis, 1999),
de acordo com Shneiderman (1998), “uma teoria é uma abstração da realidade que, embora nem
sempre seja completa, proporciona entendimento a quem a estuda e produz conclusões similares
a todos que a utilizam e é útil na solução de determinados problemas práticos”. Porém, para
tornar o conteúdo de uma teoria praticável, é preciso que se criem modelos que a representem,
para ser adotados e utilizados por desenvolvedores.
21
Dentre os modelos originados para o desenvolvimento de interfaces, deve-se dar destaque
ao modelo cognitivo que apresenta uma base teórica (fundamentada na psicologia cognitiva) para
o entendimento de como o usuário se comporta diante de uma interface de computador. A partir
desse modelo, vários métodos de desenvolvimento, teste e avaliação de interfaces foram criados
tais como o CLG (Moran, 1981), o TAL (Reisner, 1981) e o GOMS (Card & Newell, 1983). O
GOMS faz uso de um modelo do comportamento humano, o MPH (Modelo do Processador
Humano), formulado a partir de metáforas computacionais para representar teorias psicológicas.
Além da abordagem cognitiva foram desenvolvidas e/ou adaptadas abordagens
computacionais para o desenvolvimento de interfaces e sistemas interativos. Com isso surgiram
abordagens como a de Projeto Centrado no Usuário (PCU). Projetos em que o desenvolvimento
dá prioridade às necessidades, às limitações, enfim, às características dos usuários do sistema
(Gulliksen et al,1998), como é o caso das metodologias USE (Wasserman et al, 1986), LUCID
(Cognetics, 1999) e a Engenharia de Usabilidade (Nielsen, 1993). Outra abordagem de
desenvolvimento de sistemas interativos é o Projeto Participatório (Kuhn & Muller, 1993)
(Gulliksen et al,1998), no qual as preocupações em relação à satisfação do usuário, demonstradas
na abordagem PCU, persistem porém, com a característica adicional da participação ativa do
usuário no desenvolvimento do sistema em uma ou mais fases do processo (Gulliksen et al,1998).
Muitas metodologias foram desenvolvidas seguindo essa abordagem, sendo que a metodologia
The Bridge (Dayton et al, 1998) apresentada neste capítulo foi escolhida apenas devido à
facilidade de serem identificadas, em seus métodos, as características básicas de uma
metodologia de Projeto Participatório (Kuhn & Muller, 1993).
Muitos conceitos surgiram a partir da década de 40 e amadureceram dando origem ao
termo “usabilidade” da interface. A maior parte desses conceitos está inclusa nos Projetos
Centrados no Usuário e no Projeto Participatório.
Grandes melhorias foram feitas em relação às interfaces do usuário nos últimos 20 anos,
através do uso de componentes e recursos GUI’s (Xerox Star, desktop Apple Macintosh e
Windows) e a transição de métodos centrados no sistema para centrados no usuário (Wood,
1998).
Mais recentemente, no final da década de oitenta, o grupo de IHC da IBM percebeu que
os usuários não se beneficiavam com os sistemas operacionais caracterizados pela capacidade de
abrir diversas janelas e permitir que vários aplicativos executassem “ao mesmo tempo”, pelo
22
contrário, os usuários ficavam sobrecarregados e não obtinham nenhuma ajuda do computador
para gerenciar os aplicativos (IBM, 2001a). Essa percepção levou ao desenvolvimento da
interface do usuário orientada a objetos (OOUI). Mais tarde, pesquisadores da IBM criaram o
OVID (Object, View and Interaction Design), uma abordagem de PCU para o desenvolvimento
de OOUI’s. Essa mesma metodologia pode ser utilizada por equipes de desenvolvedores que
tenham usuários em sua formação, podendo ser vista como uma abordagem Participatória
também.
Outra metodologia que aborda a modelagem de OOUI’s é a metodologia OOHDM
(Feltrim, 1998) criada visando o desenvolvimento de sistemas hipermídia.
O modelo que utiliza Statecharts para modelar interfaces, criado por Horrocks (1999)
apresenta uma visão diferente da interação homem computador. Nesta visão, o diálogo direto
entre homem e computador deve ser desenvolvido antes da aplicação por equipes
multidisciplinares, com profissionais de áreas diversas (comunicação visual, psicólogos,
profissionais da área de ergonomia, etc), não necessariamente pertencentes à área de computação.
Depois disso, deve-se criar então um modelo para integração da interface com a aplicação
(desenvolvida paralelamente) e para isso o uso do Statecharts é proposto.
Alguns modelos para representação da interface e suas possíveis aplicações em um
processo de reengenharia de interface são analisados em (Moore, 1996). Dentre os modelos e
métodos analisados por Moore, destacam-se o Statecharts e GOMS. As metodologias OVID e
FUSION RE/I também foram analisados por este pesquisador, complementando a análise de
Moore com modelos e métodos utilizados em desenvolvimento de software interativo orientado a
objetos com foco na interface. As conclusões obtidas a partir dessa pesquisa são apresentadas nas
seções da 3.3.3.1 a 3.3.3.4. Uma análise mais detalhada dos métodos e modelos é encontrada em
(Soares et al, 2001a).
3.3.3.1 Statecharts
Statecharts possuem a capacidade de expressar hierarquias de estados, agrupando-os em
unidades maiores, o que possibilita representar árvores de menus de interfaces extensas. Além
disso, statecharts podem representar concorrência e broadcast.
Em (Horrocks, 1999) não há uma seqüência rígida de passos para o desenvolvimento de
um projeto de software da interface do usuário usando statecharts. Ao invés disso, Horrocks
23
(1999) oferece uma série de heurísticas de projeto que podem ser aplicadas durante o
desenvolvimento de projeto. A idéia principal do desenvolvimento de projetos desse tipo é
gradualmente identificar estados de um statechart dos níveis de abstração mais alto para os mais
baixos (top – down). Porém, devido à necessidade de se conhecer o comportamento de cada
componente da interface isoladamente antes de se ter uma visão geral do comportamento da
interface como um todo, a abordagem top-down aplicada sozinha pode ser ineficiente (Horrocks,
1999). Em alguns momentos é necessária uma visão bottom-up para se compreender o
comportamento da interface.
Em um projeto de reengenharia de interfaces para RV visando o encapsulamento do
sistema legado, a análise top-down para recuperar as hierarquias de classificação utilizadas
originalmente é o suficiente para construir uma representação da interface com statecharts, sem
considerar o nível de interfaces ligadas às funcionalidades. Para isso algumas diretivas sugeridas
por Horrocks (1999) podem ser seguidas:
-
Identificar o statechart de alto nível. Geralmente os estados de mais alto nível correspondem
às telas pelas quais se navega ao utilizar a interface. Cada tela deve ser modelada
separadamente, mas deve-se prestar atenção em como elas interagem. Outros candidatos a
estados de alto nível são as janelas e sub–janelas da interface.
-
Tentar manter o diagrama limpo para facilitar a visualização. Evitar sobreposição de arcos e
proximidade excessiva de estados.
-
Transições concorrentes devem ser totalmente independentes uma das outras. Se as partes
concorrentes possuem alguma dependência insolúvel, deve-se tentar uni-las.
-
Evitar arcos que ultrapassam vários níveis em uma hierarquia de estados.
-
Nomear estados. Cada estado deve ter um nome significativo.
Para um processo de re-desenvolvimento da interface para interface com RV, incluindo as
interfaces associadas às funcionalidades do sistema legado, o engenheiro de software pode achar
importante modelar o comportamento de objetos das telas de interface, visando mapear o estilo
de interação original na nova interface utilizando as seguintes diretivas:
-
Analisar regras da tela. Verificar o comportamento dos itens associados a uma tela. Podem
ser considerados itens: botões, itens de menus, itens de texto, radio buttons e assim por
diante. Dentro dessa heurística, os seguintes itens devem ser observados:
1- Que eventos o usuário precisa gerar para entrar na tela? E para sair?
24
2- Existe algum tipo de “modo” nessa tela? Isto é, o software, nesse ponto, pode entrar
em um estado onde os eventos do usuário terão significados diferentes?
3- Algum item tem seu comportamento alterado durante a interação do usuário com essa
tela?
4- Quais itens não têm seu comportamento alterado?
-
Converter regras de telas para um statechart.
-
Agrupar itens de comportamento relacionado, que possam ser agrupados em um mesmo
estado. Buscar grupos de itens que trabalham juntos como uma única entidade.
-
Separar itens de comportamento não relacionado. Comportamentos independentes devem
pertencer a estados diferentes.
-
Sincronizar partes concorrentes com eventos simultâneos. É possível que um evento
provocado pelo usuário resulte em transições simultâneas em partes concorrentes e essas
transições devem estar sincronizadas.
3.3.3.2 GOMS - Goals, Operators, Methods and Selection rules
O GOMS faz uso do MPH para descrever o comportamento humano (Card & Newell,
1983). O MPH é uma aproximação das capacidades de processamento de informações de uma
pessoa, descrevendo o comportamento humano em termos de memórias, processadores, seus
parâmetros e interconexões. O MPH é usado para prever aproximações do comportamento sendo
uma visão simplificada de teorias de psicologia e dados empíricos que podem ser usados por
não-psicólogos para prever o comportamento do usuário durante a interação humano-computador
(Card & Newell, 1983).
O MPH é dividido em três subsistemas: o sistema perceptivo, o sistema motor e o sistema
cognitivo, cada um com seus processadores e memórias. O sistema perceptivo recebe os
estímulos visuais e auditivos para serem processados e codificados. A memória de trabalho do
sistema cognitivo recebe a informação codificada do sistema perceptivo. O sistema cognitivo usa
informações previamente armazenadas na memória de longo-termo para tomar decisões sobre
como responder. O sistema motor executa as respostas.
Os parâmetros do sistema de memória são: capacidade de armazenamento em itens (µ), o
tempo de degradação de um item (λ) e o tipo principal de código (κ). Card et al., como mostrado
25
em (Card & Newell, 1983), atribui valores aproximados para os parâmetros identificados por
eles.
Presume-se que a estrutura cognitiva do usuário é composta de quatro componentes: um
conjunto de metas, um conjunto de operadores, um conjunto de métodos para atingir os objetivos,
e um conjunto de regras de seleção de métodos para atingir as metas. Tais componentes são
definidos como:
-
Metas (Goals): estruturas simbólicas que definem um estado a ser atingido e determina
um conjunto de possíveis métodos pelos quais pode-se atingir o estado desejado. As
metas fornecem um ponto de retorno para o processador humano (MPH), caso haja erros e
informações sobre o que já foi realizado.
-
Operadores (Operators): ações perceptivas, motoras ou cognitivas básicas cuja execução
é necessária para mudar qualquer aspecto do estado mental do usuário ou para afetar o
ambiente da tarefa realizada (Card & Newell, 1983). O modelo GOMS não permite
comportamento concorrente, assumindo que o comportamento seja uma execução
seqüencial de operadores (Card & Newell, 1983). A definição do nível de abstração dos
operadores define a granularidade da análise de tarefas. Quanto maior a granularidade
mais detalhes dos mecanismos psicológicos envolvidos na realização da tarefa estarão
envolvidos. Quanto menor a granularidade, mais detalhes dos mecanismos de realização
(nível de abstração maior) da tarefa estarão envolvidos.
-
Métodos (Methods): descrições de procedimentos para atingir metas (Gray & BoehmDavis, 2000). Em GOMS, métodos são procedimentos presumidamente aprendidos pelos
usuários e não planos que eles possam criar durante a realização da tarefa. Assume-se que
esses métodos estão na memória de longo-termo do usuário.
Regras de Seleção (Selection Rules). Regras de seleção são regras usadas para escolher
um entre vários métodos existentes para atingir um mesmo objetivo (Gray & BoehmDavis, 2000).
O modelo resultante do GOMS deve ser usado para avaliação da tarefa do usuário em
relação ao seu desempenho após a análise da mesma ou para a implementação direta. Ele assume
que os usuários realizam suas ações de forma racional para atingir suas metas e, portanto, o
comportamento do usuário pode ser previsto ao determinar as metas do usuário (goals), seus
métodos (methods), operadores (operators) e restrições da tarefa.
26
No contexto da reengenharia de interfaces para interfaces com RV, o modelo gerado com
a utilização do GOMS pode ser utilizado na fase de engenharia reversa para identificar as tarefas
realizadas pelo usuário em alto nível de abstração e em detalhes, se necessário. Com a visão
abstrata do sistema, o engenheiro de software pode identificar possíveis metáforas e hierarquias
de classificação de funcionalidades a serem representadas por objetos 3D na interface com RV. O
GOMS tem como objetivo recuperar o modelo mental que o usuário faz do sistema ou analizar o
desempenho do usuário para realizar certas tarefas. Portanto o GOMS busca a visão do usuário
em relação ao sistema, o que pode ser muito útil para melhor compreensão do domínio e
formulação de uma metáfora para a interface com RV.
3.3.3.3 OVID - Object, View and Interaction Design
O OVID, segundo Roberts (1998), é uma metodologia formal criada pela IBM para
desenvolvimento de interfaces orientadas a objetos. A notação utilizada como base é UML. No
OVID, o foco de atenção está em três itens:
-
Objetos;
-
Visões;
-
Interações.
Objetos, no OVID, são percepções dos objetos reais utilizados pelos usuários quando
realizam suas tarefas no mundo real.
Visões são criadas a partir dos objetos, e representam aspectos dos objetos que devem ser
mostrados aos usuários para que eles tenham toda a informação necessária para realizar suas
tarefas.
Interações entre usuários e objetos devem corresponder, de alguma forma, às interações
entre o usuário e os objetos do mundo real, para que não haja inconsistências na interface.
Inicialmente, é realizada uma análise de tarefas. Durante essa fase são coletadas
informações sobre os usuários e o trabalho que eles realizam. Essa coleta pode ser realizada de
diversas formas: entrevistas, observação, testes das versões anteriores do sistema e análise do
sistema.
Para a análise de tarefas propriamente dita, qualquer técnica de análise existente pode ser
usada. Porém, duas técnicas são apresentadas em (Roberts, 1998), devido a sua popularidade:
análise hierárquica de tarefas e use cases.
27
A partir da análise de tarefas, objetos devem ser identificados. Para tanto, recomenda-se
examinar o texto gerado durante a análise de tarefas buscando substantivos que serão candidatos
a objetos.
Com o modelo de objetos pronto, deve-se então identificar as visões. As visões devem ser
criadas a partir dos aspectos dos objetos aos quais o usuário deve ter acesso para realizar suas
tarefas. Deve-se priorizar as tarefas mais freqüentemente realizadas. As visões são representadas
no modelo de objetos por objetos ligados pela relação de agregação aos objetos aos quais elas
pertencem. As visões são completadas por notas. Estas notas são ligadas às visões e aos
relacionamentos de onde recebem alguma informação como mostra a figura 3.1.
FIGURA 3.1 – Modelo de objetos com visões representadas do OVID, adaptada de (IBM, 2001b)
Após ter as visões definidas, deve-se determinar as tarefas suportadas pelas visões. Com
esse objetivo, é criado um diagrama de interação para cada tarefa. O diagrama de interação
corresponde ao diagrama de seqüência da UML.
Os modelos utilizados em OVID podem ser aplicados na fase de engenharia reversa em
um processo de reengenharia de interfaces de sistemas OO visando o re-desenvolvimento da
interface para interfaces com RV. A notação de visões é interessante para representar de forma
abstrata as interfaces e a origem dos dados utilizados nela pois está livre de qualquer detalhe de
implementação, facilitando uma visão geral do sistema e dos dados a serem apresentados na nova
interface com RV. Para tanto, é necessária a recuperação do modelo de classes do sistema, em
uma análise bottom-up do sistema, ou simplesmente através da recuperação da documentação do
sistema. Com o modelo de classes recuperado, uma análise top-down, a partir da execução do
28
sistema legado, deve ser feita para recuperar as tarefas do usuário e as visões, associando-as ao
modelo de classes.
Para a fase de engenharia avante da nova interface com RV, o diagrama de classes deve
ser refinado, acrescentando objetos do modelo de implementação que explicitam como os objetos
serão apresentados no ambiente virtual, e em seguida gerar o diagrama de interação.
3.3.3.4 FUSION RE/I
Existem alguns métodos para apoiar a engenharia reversa orientada a objetos de sistemas.
O FUSION-RE (Penteado, 1996) é um conjunto de regras bem definidas para a engenharia
reversa de sistemas que não seguem o paradigma de orientação a objetos. Os resultados desta
abordagem são modelos de análise seguindo o paradigma de orientação a objetos. Esse método
foi utilizado em alguns sistemas implementados em diferentes linguagens não orientadas a
objetos. Os passos que compõem esse método são:
1- Revitalização da Arquitetura do Sistema. Recuperação de listas cruzadas dos procedimentos
utilizados. Essas listas recebem o nome de listas “Chama/Chamado”;
2- Elaboração do Modelo de Análise do Sistema Atual (MASA). A partir do código legado, são
construídos os modelos de análise orientados a objetos;
3- Elaboração do Modelo de Análise do Sistema (MAS). Abstrações são feitas no MASA para
que somente as classes da aplicação sejam consideradas;
4- Mapeamento MAS x MASA. Esse mapeamento é realizado para facilitar a conversão dos
procedimentos em métodos, dos elementos de dados em atributos com nomes mais
significativos.
Uma das extensões do método FUSION-RE é o FUSION-RE/I (Costa, 1997) que mantém
praticamente a mesma abordagem, recuperando os modelos de análise FUSION (Coleman et al,
1994) com a característica adicional de partir da interface do sistema para facilitar a recuperação
de visões do sistema.
29
FIGURA 3.2 – Visão Geral da metodologia FUSION-RE/I (Feltrim et al, 1999)
Como pode ser visto na figura 3.2, esse método é composto por duas etapas:
1- Abstração da funcionalidade do sistema;
2- Identificação dos procedimentos que implementam as operações da interface do sistema,
associando-os à sua funcionalidade, à interface ou a um dos “temas” do sistema.
A utilização da interface como fonte de informações para a recuperação de visões do
sistema ocorre durante as atividades desenvolvidas na primeira etapa do FUSION-RE/I. O
processo de recuperação de informações a partir da interface do sistema prevê o uso exaustivo do
software e cruzamento de informações com os dados obtido de todas as outras fontes de
informações existentes (manuais, documentação, conceitos, informações com usuários, etc) para
recuperar os modelos de interface, isto é, o modelo de ciclo de vida e operações. Nessa mesma
fase é recuperado o modelo de objetos.
O modelo de ciclo de vida recupera as seqüências permitidas de operações e eventos do
sistema a partir da observação da interface do sistema e representa-as por expressões regulares na
notação do FUSION.
O modelo de operações caracteriza o efeito de cada operação do sistema em termos de
mudanças de estado e eventos gerados. A representação do modelo de operações é feita através
de gabaritos textuais com informações: nome da operação, descrição, itens lidos, itens
modificados, eventos gerados, pré-condição e resultados.
30
O método FUSION-RE/I foi utilizado no processo de reengenharia de um sistema
hipermídia durante a fase de engenharia reversa para recuperação da documentação do software
em (Feltrim et al, 1999).
Os modelos de interface recuperados com FUSION RE/I, juntamente aos modelos do
sistema, representam importantes modelos para a compreensão do sistema legado em um
processo de re-desenvolvimento da interface do sistema para interfaces com RV, mesmo porque a
reengenharia pode ser vista como um processo de reengenharia do sistema para agregar melhorias
em sua interface. Entretanto, faltam modelos que mapeiam a interface mostrando sua organização
de forma a facilitar a compreensão dos critérios utilizados para classificar as funcionalidades do
sistema. A recuperação desses critérios facilita a criação de metáforas em um possível processo
de encapsulamento e reorganização da interface com interface com RV, como realizada neste
trabalho.
3.4 Considerações Finais
Neste capítulo foi visto como o processo de reengenharia de interfaces pode ser usado na
manutenção de sistemas legados, foram apresentadas diversas abordagens de reengenharia de
interfaces e como métodos e modelos de engenharia de software de interfaces podem ser
utilizados em processos de reengenharia de software, especialmente em processos de
reengenharia de interfaces para interfaces com RV.
31
Capítulo 4 - O Ambiente GaCIV
4.1 Considerações Iniciais
As mudanças propostas pela RV e outras tecnologias de interface Pós-WIMP causam um
impacto direto à forma de desenvolvimento de interfaces. A implementação de tais interfaces
ainda apresenta alto grau de complexidade e custo em relação às interfaces WIMP. O ambiente
GaCIV, apresentado neste capítulo, tem como objetivo dar apoio à criação de interfaces PósWIMP de forma rápida e viável.
Na seção 4.2 são apresentadas as características do GaCIV; na seção 4.3 são mostradas as
principais aplicações do GaCIV em processos de engenharia de software; e na seção 4.4 são
comentadas algumas considerações finais.
4.2 Características
O GaCIV, ambiente com Gabaritos Configuráveis para elaboração de Interfaces com RV,
auxilia a construção de interfaces com RV que está sendo desenvolvida no Departamento de
Computação da Universidade Federal de São Carlos, projeto financiado pela Fapesp. Nesse
trabalho as interfaces com RV serão referenciadas como interfaces com RV.
Os principais objetivos desse ambiente são:
-
facilitar o uso da tecnologia de RV não-imersiva para a criação de interfaces dessa
natureza;
-
facilitar a aproximação entre projetistas de interfaces, engenheiros de software e usuário
durante o desenvolvimento de uma aplicação com interfaces com
RV como será
mostrado mais adiante.
As interfaces com RV construídas com a utilização do GaCIV são geradas por gabaritos
configuráveis. Segundo (Assis & Silva, 2000a) (Silva, 1999), um gabarito é um ambiente virtual
que contém um conjunto de objetos que o caracterizam. Os objetos que fazem parte do ambiente
virtual podem ser escolhidos e configurados de acordo com as especificações do usuário. É
possível também criar uma biblioteca de gabaritos para ser usada pelo projetista de interfaces que
terá a oportunidade de escolher a interface mais adequada para uma determinada aplicação e
também escolher a melhor configuração dessa interface de acordo com as necessidades do
32
usuário. Portanto, as principais características das interfaces com RV geradas utilizando o
ambiente GaCIV são:
-
natureza não-imersiva, isto é, apresentam objetos e ambientes 3D que podem ser
visualizados em dispositivos 2D tais como monitores comuns, sem a necessidade de
equipamentos avançados e custosos como por exemplo head-mounted displays;
-
preservam o estilo de interação 2D utilizado em interfaces WIMP, sendo o mouse comum
o único dispositivo de entrada necessário para a seleção e manipulação de objetos.
Objetos podem ser selecionados desde que estejam no campo de visão do usuário,
independente da distância que os separam, evitando a necessidade de excessiva
locomoção do usuário dentro do ambiente RV. Objetos apresentados no ambiente estão
ligados a aplicações que são executadas quando os objetos são selecionados, funcionando
como “ícones 3D” que representam as funcionalidades do sistema. Os objetos não
interagem entre si;
-
Navegação não exige posicionamento preciso do usuário para que tarefas sejam
executadas e é realizado utilizando o mouse como dispositivo de entrada. O cursor indica
a direção a ser seguida pelo usuário e o movimento no plano XZ é feito através do
pressionamento contínuo do botão esquerdo enquanto o movimento no plano XY é feito
através do pressionamento contínuo do botão direito;
-
Substituem ou adicionam camadas na árvore de interface de aplicações desenvolvidas
previamente, resultando, em muitos casos, em interfaces mistas combinando gráficos 3D
e interfaces 2D WIMP ou mesmo textuais;
-
Objetos e ambiente 3D gerados e posicionados de acordo com o contexto da aplicação e
as necessidades do usuário;
-
O ponto de vista do usuário no ambiente virtual gerado é egocêntrico.
Para atingir os objetivos de suporte à criação de interfaces com RV de forma prática e
acessível, o GaCIV permite três operações:
-
criação de interfaces com RV a partir de gabaritos;
-
gerar novos gabaritos;
-
inserir novos ambientes e objetos a serem usados em gabaritos.
Para a criação de interfaces com o GaCIV, a equipe de desenvolvimento deve escolher um
gabarito da biblioteca de gabaritos. Os objetos que caracterizam o gabarito serão então
33
apresentados para que o projetista possa selecionar quais serão utilizados para criação da
interface. Ao ser escolhido, o objeto é inserido automaticamente em uma posição sugerida pela
configuração padrão do gabarito. Os objetos inseridos podem ser modificados em relação à sua
posição e tamanho, além de poderem ser duplicados ou excluídos, permitindo assim a
personalização da interface de acordo com os requisitos do sistema. Com os objetos devidamente
inseridos no gabarito, o projetista obtém a interface com RV para o sistema em desenvolvimento
(Assis & Silva, 2000b). Essa interface deverá ser devidamente conectada à aplicação como será
visto adiante. Na figura 4.1 pode ser visto um esquema conceitual. Nesse esquema, a equipe de
desenvolvimento de interfaces deve operar o GaCIV para criar a interface de um sistema. Nesse
processo de criação, a equipe deve utilizar um ambiente e objetos do banco de dados do GaCIV
que deverão ser associados à aplicação através do Interbuilder.
34
Ambiente1.nff
Objeto1.nff
Ambiente
Objeto2.nff
Objeton.nff
GaCIV
Aplicação
Programa1.exe
INTERBUILDER
BD GaCIV
Programa2.exe
Nova Aplicação.EXE
Programan.exe
Sistema
Programa1.exe
Interface
OO
com RV
Programa2.exe
Legenda:
consulta
geração
associação
Programan.exe
FIGURA 4.1 – Criação de Interfaces com RV com o GaCIV
A operação de gerar novos gabaritos compreende a associação de um ambiente, existente
na biblioteca do GaCIV, ao novo gabarito e posteriormente a adição de objetos, também
previamente existentes na biblioteca de objetos, no gabarito criado. Depois de finalizada a
configuração do gabarito, este ficará armazenado na base de dados do GaCIV.
Na figura 4.2 mostra a tela do GaCIV durante a operação de criação de novos gabaritos. Nessa
tela podem ser vistas, à esquerda, três listas. A lista superior oferece as opções de ambientes, A
35
lista inferior - esquerda mostra objetos do banco de dados do GaCIV e a lista inferior - direita
mostra os objetos inclusos no gabarito em desenvolvimento que dará origem a uma interface. Os
botões mostrados entre as listas de objetos indicam as opções de incluir e excluir um objeto.
Os botões acima da lista de ambientes permitem mudar a escala de um objeto e centralizar
a posição do usuário no ambiente virtual.
Ao lado direito da tela estão o nome do gabarito em desenvolvimento, o nome do
ambiente utilizado e a visão 3D do gabarito.
Na barra superior são encontrados menus popup. Os menus apresentam opções para
manipulação de arquivos, ambientes, objetos, gabaritos e interfaces.
FIGURA 4.2– Criação de novos gabaritos no GaCIV
Novos objetos e ambientes também podem ser inseridos na base de dados do GaCIV para
permitir uma maior gama de alternativas ao projetista de interfaces. Os objetos e ambientes a
serem inseridos devem ter sido criados em editores 3D e, mais tarde, convertidos em arquivos do
formato “nff”, o qual é o formato aceito pelo ambiente. Os nomes dos objetos e ambientes, após
serem escolhidos e atribuídos pelos usuários, serão acrescentados na base de dados do GaCIV.
36
Como é mostrado em (Assis & Silva, 2000b) e em (Silva, 1999), o GaCIV permite que o
desenvolvimento da interface ocorra de forma independente e paralela ao desenvolvimento da
aplicação, permitindo assim a independência de diálogo. Para integração dos componentes de
interface gerados pelo GaCIV com a aplicação utiliza se o recurso de link. O link é atribuído pelo
GaCIV a cada objeto da interface. Como visto em (Assis & Silva, 2000a), um link é uma
interligação entre o objeto da interface e um arquivo executável. Dessa forma, quando um objeto
da interface é ativado, uma aplicação associada a esse objeto é executada. Essa característica de
associação de objetos a módulos da aplicação torna interessante a aplicação do paradigma de
orientação a objetos durante o desenvolvimento dos sistemas interativos, pois a orientação a
objetos facilita a modularização da aplicação (Assis & Silva, 2000a) (Silva & Penteado, 2000).
A ação de ligação mostrada na figura 4.3 consiste em selecionar o objeto (no caso, o
fogão), clicar no botão “Link” e escolher a aplicação que deve ser associada a ele. A janela
central, vista na figura 4.3, mostra as diversas opções de aplicações existentes para o usuário
ligar ao objeto fogão.
FIGURA 4.3 – Ligação entre objeto e aplicação no GaCIV.
Segundo Assis e Silva (2000b), com a capacidade de criar novos gabaritos e inserção de
novos objetos e ambientes, o GaCIV permite a aplicação de um modelo de desenvolvimento de
37
sistemas interativos baseada no PCU (Gulliksen et al,1998). Com o GaCIV, uma equipe formada
por um engenheiro de software, um projetista de interfaces e um designer gráfico podem
trabalhar cooperativamente e desenvolver um gabarito que se adeque ao levantamento de
requisitos feito junto ao usuário, para desenvolvimento de um sistema interativo.
Os seguintes passos podem ser seguidos por essa equipe para a criação da interface:
-
Com a análise de requisitos do sistema previamente realizada, o usuário participa de
reuniões com a equipe de desenvolvimento para definição dos objetos virtuais que devem
fazer parte da interface de acordo com sua visão da funcionalidade do sistema, sendo tal
tarefa parte da etapa de levantamento de requisitos. Nesse passo, pode-se utilizar o
recurso de prototipação rápida;
-
Se algum objeto não existente na biblioteca do GaCIV for requisitado pelo usuário, o
designer gráfico deve criá-los. Ao mesmo tempo, o desenvolvedor de interfaces pode
elaborar o gabarito da interface a partir de objetos existentes;
-
Trabalhando paralelamente aos outros dois participantes da equipe, o engenheiro de
software pode desenvolver o código da aplicação, visto que os requisitos foram definidos
e um protótipo rápido da interface validado pelo usuário;
-
Criados os objetos criados, o desenvolvedor estará apto a inseri-los no gabarito, cuidando
de todos os aspectos relativos à usabilidade da interface;
-
Assim que a interface e a codificação da aplicação estiverem completas, a interface
poderá ser ligada aos módulos de aplicação correspondentes, estabelecendo-se os links
entre objetos e programas executáveis;
-
Ao fim de todos esses passos, o sistema interativo estará completo, formado por um
arquivo executável contendo os módulos da aplicação e a interface gerada no GaCIV,
conforme indica a figura 4.1.
4.3 Potencialidades
O GaCIV, como suporte de desenvolvimento de interfaces avançadas, pode dar apoio a
diversas atividades de engenharia de software. Algumas dessas atividades são discutidas a seguir.
38
4.3.1 GaCIV e OOUI
Os objetos representados com gráficos 3D podem representar de forma bem mais realista
os objetos utilizados pelo usuário no mundo real para realizar suas tarefas (IBM, 2001a) . Ao
reconhecer mais facilmente os objetos, os usuários podem focar sua atenção nas tarefas que
realizam ao invés de gastarem esforços para aprender a utilizar a interface. A representação
realista para facilitar a interação do usuário com o sistema é parte importante da criação de
OOUI’s. A criação de interfaces com RV com o GaCIV favorecem esse aspecto. Além disso, os
objetos pertencentes às interfaces criadas no GaCIV estão diretamente ligados a suas aplicações,
facilitando a sintaxe de interação “objeto-ação”. Segundo essa sintaxe, o usuário deve reconhecer
o objeto desejado e em seguida interagir com ele através de ações permitidas pelo sistema.
É importante ressaltar que muitos aspectos da criação de OOUI’s dependem do projeto de
desenvolvimento da aplicação. Um exemplo disso é as visões dos objetos a serem percebidas pelo
usuário. Nem todas as características de um objeto são importantes para a tarefa realizada pelo
usuário. As características relevantes devem ser identificadas em fases anteriores de
desenvolvimento (análise e projeto) e os resultados dessas fases devem ser refletidos na criação
da interface e da aplicação. Dessa forma deve-se atentar que apenas a utilização do GaCIV não
significa a implementação de uma OOUI.
4.3.2 GaCIV e Reengenharia
O ambiente GaCIV pode ser utilizado em processos de reengenharia de interfaces de
sistemas legados. O GaCIV dará apoio à fase de engenharia avante da nova interface a ser
implementada, substituindo a antiga interface por uma interface com RV, como visto na figura
4.4. O esquema apresentado na figura 4.4 é semelhante ao esquema de criação de interface,
mostrado na figura 4.1, porém, para que seja possível essa aplicação do GaCIV, é necessário que
se faça, anteriormente, uma análise do sistema legado buscando o entendimento das interfaces
existentes e a separação de todo o código referente à interface desse sistema. Essa fase
preparatória é necessária devido ao tratamento dado pelo GaCIV à independência de diálogo,
como visto anteriormente. Deve-se, portanto, preparar a aplicação para receber a nova interface
criada no GaCIV. Ao mesmo tempo, deve-se realizar outras atividades de engenharia reversa
buscando entendimento da aplicação para que a nova interface a ser desenvolvida seja
equivalente à anterior em relação aos aspectos de funcionalidade.
39
Devido à natureza modular da interface gerada pelo GaCIV (Assis & Silva, 2000b), é
desejável que a aplicação também possua essa característica para simplificar a associação da
interface criada no GaCIV à aplicação, permitindo identificar e isolar módulos da aplicação que
serão disponibilizadas por objetos distintos da interface.
Ambientem.nff
Ambiente1.nff
Objeto1.nff
Objeto2.nff
GaCIV
Aplicação Legada
Programa1.exe
Programa2.exe
Interface
legada
INTERBUILDER
BD GaCIV
Nova Aplicação.EXE
Programan.exe
Sistema
Programa1.exe
Interface
OO
com RV
Programa2.exe
Legenda:
consulta
geração
associação
Programan.exe
FIGURA 4.4 – O GaCIV e a reengenharia de interface
Objeton.nff
40
4.3.3 GaCIV e Reuso
Devido aos altos custos no desenvolvimento de novas interfaces, a prática de reuso desses
componentes resulta em relevante economia (Pressman, 1997). Os custos aumentam ainda mais
quando as interfaces desenvolvidas requerem o uso de RV, devido à complexidade envolvida na
criação de tais interfaces. O GaCIV possui características que possibilitam o reuso de interfaces
criadas com o uso deste. Objetos e ambientes criados para interfaces específicas são armazenadas
na base de dados do GaCIV e podem ser combinadas de novas maneiras para formar novos
gabaritos e possivelmente novas interfaces. A modularidade e independência das interfaces
criadas com o GaCIV facilitam o reuso das mesmas, permitindo que aplicações sejam
desenvolvidas independentes dos componentes de sua interface.
4.4 Considerações Finais
Os projetos com interfaces avançadas, envolvendo recursos 3D e RV, são geralmente
mais difíceis de se construir do que projetos envolvendo a geração anterior de interfaces (WIMP
GUI) (Constantine, 1995), porém representam grande avanço na interação humano computador
ao explorar fomas mais naturais e intuitivas de interação. Além disso, sistemas interativos
legados, podem ter o tempo de vida útil prolongado e melhoria de performance na interação com
o usuário se forem adaptados a essa nova tecnologia através da reengenharia de interface.
O ambiente GaCIV está sendo desenvolvido para apoiar tanto o processo de engenharia
avante de interfaces Pós-WIMP quanto à reengenharia de interfaces de sistemas legados,
diminuindo a complexidade desses processos ao facilitar a comunicação entre membros de uma
equipe de desenvolvimento de interfaces e possibilitando o reuso de interfaces de quarta geração.
41
Capítulo 5 - Estudo de Caso - O sistema da Oficina Mecânica
5.1 Considerações Iniciais
O objetivo principal deste estudo é verificar as facilidades e dificuldades encontradas no
processo de reengenharia de interfaces para RV assim como as vantagens obtidas com esse
processo, a partir de três versões de um mesmo sistema exemplo: procedural, segmentada
segundo o paradigma OO e efetivamente OO. Trata-se de um sistema real de uma oficina
mecânica que controla os serviços executados em veículos, bem como o controle de estoque das
peças utilizadas e de sua reposição. O usuário típico do sistema exemplo é o funcionário da
oficina.
Com o intuito de agregar melhorias na apresentação do sistema legado para o usuário,
facilitando o reconhecimento das funcionalidades disponíveis e aumentando o envolvimento do
usuário com as tarefas realizadas no sistema computacional, realizou-se neste trabalho a
reengenharia de interfaces para interfaces com RV, como será detalhado neste capítulo.
Este capítulo está estruturado da seguinte forma: a proposta para a reengenharia de
interfaces das três versões do sistema exemplo é detalhada na seção 5.2; na seção 5.3 são
analisadas algumas opções de métodos e modelos que podem ser aplicados na proposta de
reengenharia deste trabalho; na seção 5.4 é descrito o processo de criação do gabarito preliminar
de objetos 3D usado durante a reengenharia das interfaces das três versões do sistema; as
características de cada versão do sistema, detalhes de implementação e processos de reengenharia
realizados são apresentados nesse capítulo nas seções 5.5, 5.6 e 5.7; por fim, são apresentadas as
considerações finais na seção 5.8.
5.2 Proposta de processo de reengenharia deste trabalho
O processo de reengenharia aplicado neste trabalho tem seu foco nas camadas mais altas
de abstração das árvores de menus apresentadas pelas versões do sistema-exemplo, isto é, visa a
substituição ou reorganização dos menus de interface, nos quais o usuário navega para encontrar
e acessar as funcionalidades do sistema. Dessa forma, o objetivo é agregar usabilidade ao sistema
legado utilizando a tecnologia de RV para permitir maior envolvimento dos usuários com o
42
sistema e utilizar o poder de representação de gráficos 3D para a facilitar o reconhecimento das
funcionalidades do sistema na nova interface.
Na figura 5.1 tem-se uma visão geral do processo de reengenharia proposto para este
trabalho. Esse processo envolve, inicialmente, uma fase preparatória de recuperação e
representação da organização dos menus da interface legada, para compreensão da interface
existente. Utilizou-se, para a fase preparatória, a documentação existente dos sistemas, incluindo
manuais técnicos e manuais do usuário, e, principalmente, a execução do sistema legado. A
abordagem para a fase preparatória, ou de engenharia reversa, utilizada é semelhante à
apresentada em (Stroulia et al, 1999), comentada anteriormente no capítulo 3.
FIGURA 5.1 – Processo de Reengenharia para Interfaces com RV proposto neste trabalho
Essa abordagem de engenharia reversa é vantajosa na análise de sistemas legados que não
fazem grandes transformações e cálculos de dados internamente, baseando-se grande parte no
diálogo humano-computador e acesso à banco de dados.
Neste trabalho, para representar o mapa da interface do sistema foram utilizados
diagramas de caixas, apresentados no Apêndice E, onde cada caixa representa uma tela da
interface e as ligações entre elas indicam a possibilidade de navegação. As principais fontes de
informação para a criação dos diagramas foram a execução do sistema, os modelos de ciclo de
43
vida recuperados durante o processo engenharia reversa para a segmentação e mostrados no
Anexo II, e uma representação da interface encontrada na documentação do sistema legado
mostrada em parte no Anexo III. O diálogo humano-computador realizado durante a execução
das tarefas do usuário foi representado por cenários textuais, mostrados no Apêndice D,
recuperados através da execução do sistema. Esses modelos formam os “Modelos de Organização
dos Menus”, indicados na figura 5.1.1 como entradas para a fase de desenvolvimento das
interfaces 3D.
Na fase de desenvolvimento, esses modelos são analisados e reorganizados visando
melhorar a organização e representação das funcionalidades na interface com RV e
conseqüentemente o acesso a elas. A partir desses modelos, o sistema legado tem seus módulos
preparados para receber a nova interface e então as interfaces com RV são criadas e ligadas aos
módulos da aplicação.
O processo de reengenharia de interfaces aplicado nas três versões seguiu basicamente os
passos:
1- recuperação de informações sobre as interfaces originais através da execução do sistema
em questão e documentação existente;
2- criação preliminar de gabarito com objetos 3D;
3- análise e reformulação dos modelos de organização obtidos;
4- refinamento do gabarito com a busca ou criação de objetos específicos para o sistema em
questão;
5- preparação do aplicativo para receber nova interface;
6- criação e ligação da nova interface com RV utilizando o GaCIV.
Durante a fase preparatória, observou-se a necessidade de métodos para recuperação e
representação das interfaces legadas de forma que informações sobre a estrutura das árvores de
menus fossem registradas, permitindo que fossem visualizadas e analisadas em relação às tarefas
executadas pelo usuário. Com isso, o engenheiro de software tem a possibilidade de encontrar
problemas de organização que dificultam a navegação do usuário nas camadas de abstração mais
altas da árvore de menus, impedindo-o de reconhecer e encontrar as funcionalidades desejadas.
Para este trabalho, optou-se por diagramas de caixas para fazer a representação das árvores de
menus devido à facilidade de uso e suficiente poder de representação, entretanto outros modelos
44
de desenvolvimento de interfaces podem ser utilizados para esses propósitos. Alguns desses
modelos são apresentados na seção 5.3 deste capítulo.
O segundo passo do processo de reengenharia utilizado, a criação preliminar de gabarito com
objetos 3D, foi realizado apenas uma vez, gerando um único gabarito que foi refinado para cada
uma das versões do sistema. A criação desse gabarito é apresentada detalhadamente na seção 5.4
deste capítulo.
5.3 Modelos para a Reengenharia de Interfaces
O processo proposto por este trabalho requer modelos de representação para a fase
Preparatória, fase esta que corresponde a um processo de engenharia reversa da interface dos
sistemas. Esse processo visa a compreensão da organização dos menus na interface de cada
versão do sistema, e deve mapeá-los em modelos que servirão de base para reformulação e
desenvolvimento da nova interface com RV. A partir do estudo realizado sobre métodos e
metodologias de desenvolvimento de interfaces apresentado no capítulo 3, três modelos foram
analisados para possível utilização nesse processo: GOMS (Card & Newell, 1983), Statecharts
(Harel, 1987) e OVID (Roberts, 1998). A seguir serão apresentados os resultados obtidos.
5.3.1 GOMS
No contexto da reengenharia de interfaces para interfaces com RV como realizada neste
trabalho, o modelo gerado com a utilização do GOMS pode ser utilizado para identificar as
tarefas realizadas pelo usuário e com isso obter informações sobre o contexto ao qual estão
incluídas para representa-las na interface com RV. Analisando as tarefas realizadas pelo usuário
no sistema legado e representando-as com o modelo GOMS, pode-se identificar hierarquias de
tarefas e subtarefas que formarão hierarquias de classificação de funcionalidades na interface
final. Dessa forma os desenvolvedores da interface com RV podem identificar, por exemplo, que
para atingir o objetivo “Acessar o Menu de Consultas de Peças” , o usuário necessita realizar o
objetivo “Acessar o Menu de Consultas”. Com isso o desenvolvedor poderá criar uma hierarquia
de objetos 3D refletindo essa situação.
Apesar da capacidade de representação do GOMS possibilitar sua aplicação no
mapeamento da interface, a visualização de modelos gráficos permite maior facilidade de
visualização da estrutura geral da interface. Outra desvantagem do GOMS é apresentar apenas a
45
visão do usuário em relação ao diálogo humano-computador. Neste trabalho optou-se por
cenários textuais em linguagem natural, que, apesar de poder se tornar ambígua em alguns casos,
possui a flexibilidade necessária para representar o lado humano e o lado computacional do
diálogo humano-computador.
Outra aplicação do GOMS é avaliar o desempenho do usuário ao navegar pela interface
original e, a partir dos resultados obtidos, avaliar comparativamente o desempenho do usuário ao
interagir com a nova interface com RV.
A análise deve ser feita de acordo com o GOMS a um nível de abstração das interações do
usuário previamente estabelecida pelo projetista. Feito isso, deve-se associar o tempo previsto
(dados empíricos) para o modelo para que este possa avaliar quantitativamente (em unidades de
tempo) a performance da realização da tarefa por um usuário experiente.
Para o projetista, um dos maiores problemas está na obtenção de uma base de dados
empíricos para obter os parâmetros de tempo apropriados. Apesar de existir diversas bases de
dados para interfaces textuais e WIMP, não foi encontrado por este pesquisador base de dados
relativos às interfaces com RV.
5.3.2 Statecharts
Devido a sua capacidade de representação gráfica de hierarquias e transições de estados, o
Statechart é um modelo que permite o mapeamento de árvores de menus de interfaces,
facilitando a visualização e análise de sua organização. Os menus podem ser facilmente
representados como estados e a ligação entre eles, como transições. Além da organização dos
menus, Statecharts podem representar modelos de navegação na interface dos sistemas legados,
permitindo uma visão do comportamento da interface.
É possível a aplicação de Statecharts para representar o diálogo humano-computador,
entretanto existe a dificuldade de determinar quem é a fonte da ação que resulta na mudança de
estados do sistema. Sem essa representação o entendimento do diálogo fica prejudicado.
5.3.3 OVID
A metodologia OVID permite que a hierarquia de objetos de interface, ou “visões”, sejam
representadas na notação para diagrama de classes UML estendido. Entretanto a modelagem pode
46
se tornar confusa dependendo do tamanho do sistema e a quantidade de visões apresentadas por
ele. Quanto maior o sistema, mais difícil será a observação da organização da interface pois as
visões são representadas junto ao modelo de classes do domínio do sistema.
5.4 Criação do Gabarito preliminar de Objetos 3D para o Domínio do Sistema exemplo
Para criar as novas interfaces com RV no GaCIV e substituir as interfaces originais das
três versões do sistema, foi criado, previamente, um gabarito de objetos 3D relacionados à
oficina mecânica. Os objetos utilizados foram obtidos pela Internet em sites especializados na
produção de gráficos 3D tais como o site “3D Cafe” (www.3dcafe.com) que disponibilizam
gratuitamente modelos 3D aos seus usuários, ou construídos com a utilização do software World
Modeller® da Sense 8®.
O gabarito gerado, que serviu como base para as interfaces, está
ilustrado na figura 5.2.
FIGURA 5.2 – Gabarito preliminar para geração das interfaces com RV para o sistema exemplo.
Este gabarito foi desenvolvido inicialmente de forma intuitiva para servir de base às
interfaces avançadas das três versões do sistema exemplo. Esperava-se que o gabarito criado com
objetos associados intuitivamente ao contexto de uma oficina mecânica, tais como “Carro com
Defeito”, “Peças”, “Ferramentas” e “Balcão de Atendimento”, suprisse grande parte dos objetos
necessários para compor as interfaces. Foi observado posteriormente que os objetos agrupados de
forma intuitiva cobriram apenas algumas das funcionalidades e o gabarito precisou ser
47
complementado e reformulado de acordo com a versão do sistema, como será mostrado nas
seções seguintes. Segundo o ponto de vista deste pesquisador, a maioria dos objetos
acrescentados poderia ter sido incluída logo no início do processo, caso fosse possível um
levantamento de requisitos junto a usuários finais do sistema, simplificando também o trabalho
posterior de levantamento de dados do sistema através de sua execução. A realização de um
processo de desenvolvimento de software centrado no usuário para a criação da interface com
RV, com participação ativa do usuário nas fases iniciais do projeto, permitiria que o
desenvolvimento das interfaces com RV fosse mais rápido e eficiente, pois todo o gabarito
preliminar estaria de acordo com o modelo mental que o usuário faz de suas tarefas. A utilização
de processos de desenvolvimento de software centrados no usuário vem sendo discutida para uso
em diversos produtos, mas principalmente para sistemas computacionais, desde a década de 60
(Reich et al, 1995) e recomendada atualmente por corporações de grande porte como a IBM
(IBM, 2002) para criação de software com interfaces WIMP, e é recomendado para criação de
interfaces com RV em (Shamus & Harrison, 2001). Entretanto, deve ser considerado que a
participação de usuários do sistema legado nem sempre é possível, como mostrado em (Gulliksen
et al, 1999) e como ocorrido neste trabalho, devido a limitações de tempo.
Foi percebido também que o gabarito pode ser usado como protótipo para avaliação e
criação da interface final. Os gabaritos criados com apoio do GaCIV possuem a maior parte da
interatividade da interface, só não executam aplicações, e permitem o reposicionamento dos
objetos, facilitando sua compreensão e refinamento segundo a avaliação do usuário. A utilização
de protótipos e a presença de usuários durante a avaliação desses protótipos, como é
recomendado em processos de desenvolvimento de software centrados no usuário (Norman,
1998) (IBM 2002), pode, segundo o ponto de vista deste pesquisador, facilitar o teste e validação
da interface com RV antes da fase final de desenvolvimento, isto é, preparação dos módulos da
aplicação e ligação com a interface com RV. Esses aspectos não foram desenvolvidos neste
trabalho pois não é o foco da proposta, limitada principalmente por recursos humanos e de tempo.
Outra dificuldade encontrada foi a aquisição de objetos 3D. Nem todos os objetos necessários
foram encontrados a disposição na Internet e foi necessário desenvolvimento em software gráfico
3D para a representação de funcionalidades do sistema exemplo. Este pesquisador reconhece que
a participação de especialistas na área de comunicação visual e design 3D formando uma equipe
multidisciplinar seria ideal para o desenvolvimento do trabalho, resultando em objetos com
48
maior capacidade de representação para a interface com RV. A formação de equipes
multidisciplinares é recomendada para desenvolvimento de sistemas interativos com interfaces
convencionais (Norman, 1998), isto é, textuais e WIMP, e, como constatado neste trabalho, é de
vital importância para interfaces com RV devido a sua inerente complexidade de
desenvolvimento, porém enorme potencial de representação.
5.5 Sistema legado
A versão legada do sistema exemplo é na verdade o sistema original do qual foram
obtidas as versões segmentada e OO para a possibilidade da realização do trabalho proposto, isto
é, análise do processo de reengenharia para interfaces com RV aplicada nas diferentes versões.
5.5.1 Características de implementação
O sistema exemplo utilizado neste estudo é o mesmo apresentado em (Penteado et al,
1998), que exibiu o processo de engenharia reversa e segmentação de um sistema legado. Ele foi
originalmente desenvolvido em Clipper 5.0, com aproximadamente 20K linhas de código e 25
tabelas do tipo “dbf” relacionadas por chaves estrangeiras.
O estilo da interface do sistema legado está ilustrado na figura 5.3. É uma interface textual
onde a interação com o usuário é realizada através do teclado e de um monitor comum. O usuário
pode selecionar opções ou entrar diretamente com dados necessários durante o diálogo humanocomputador e visualiza-los em forma de texto monocromático.
FIGURA 5.3 – Estilo de interface textual utilizado pelo sistema legado
O sistema legado apresenta uma estrutura de árvore de menus de interface pouco
profunda, isto é, a partir das diversas opções apresentadas na tela principal pode-se, em geral,
49
acessar diretamente uma operação do sistema, como mostra a figura 5.4. A interface reflete a
estrutura monolítica do código da aplicação.
FIGURA 5.4 – Estrutura da árvore de menus do sistema legado
Apesar de parecer uma estrutura simples que permite rápido acesso às funcionalidades do
sistema, a estrutura apresentada na figura 5.4 falha em apresentar todas as funcionalidades no
menu principal de forma clara. Além disso, muitas funcionalidades distintas estão ligadas umas
às outras. Detalhes sobre a influência da estruturação do código na interface podem ser vistas no
Capítulo 6, onde os sistemas são analisados quanto a sua usabilidade.
5.5.2 O processo de reengenharia de interfaces com RV para o sistema legado
O sistema legado foi preparado para receber a interface com RV no nível mais alto de
abstração possível. Dessa forma, o usuário deve, através de uma interface com RV, acessar o
menu principal do sistema legado e, a partir de então, trabalhar com a interface legada.
Como o sistema legado foi desenvolvido em um único módulo de programação, não
existe a possibilidade, dentro da proposta do trabalho, de gerar interfaces com RV para as
diversas opções de menu. Assim, um único objeto da interface avançada leva ao menu principal
da aplicação. O usuário acessa todas as funções da aplicação através do menu original da
aplicação ilustrado na figura 5.3. Isso, em uma análise preliminar, mostra a limitação do processo
de reengenharia para essa versão do sistema.
Para representar o sistema legado na nova interface utilizou-se o objeto “Computador” figura 5.5 - que foi adicionado ao gabarito original e este objeto foi ligado ao aplicativo préexistente.
50
FIGURA 5.5 – Objeto computador no menu principal do sistema legado com interface com RV
A adição posterior do objeto computador ocorreu porque durante a construção do gabarito
inicial não foi prevista a necessidade de objetos relativos a metáforas computacionais.
5.6 Sistema segmentado
A versão segmentada do sistema foi obtida através de engenharia reversa e reengenharia
anteriores ao início das atividades deste projeto (Penteado et al, 1998) como será comentada na
próxima seção 5.6.2. O sistema segmentado, ainda implementado em Clipper, apresenta o mesmo
estilo de interface textual vista no sistema legado.
5.6.1 Características de implementação
Ao contrário do sistema legado, o sistema segmentado apresenta uma estrutura profunda
de árvore de menus de interface, favorecida pela estrutura modular do código da aplicação como
pode ser visto na figura 5.6.
Cada módulo de funcionalidade pode ser compilado separadamente e executado
independentemente dos outros módulos. Essa estruturação permite separar conjuntos de
funcionalidades e representa-las sob forma de diferentes objetos 3D na interface avançada.
51
FIGURA 5.6 – Estrutura da árvore de menus da interface do sistema segmentado
Como pode ser visto na figura 5.6, a árvore de menus da interface apresenta diversas
ramificações que representam agrupamentos de funcionalidades seguindo um critério de
classificação. É importante notar que, apesar de aumentar a carga cognitiva no esforço de
navegação do usuário, essa estrutura favorece o reconhecimento de funcionalidades se a
classificação delas estiver de acordo com o modelo mental do usuário.
5.6.2 O processo de reengenharia do sistema segmentado
A segmentação a qual o sistema legado foi submetido para se obter o sistema segmentado
consiste no processo de reengenharia com mudança de paradigma de desenvolvimento, para o
orientado a objetos, mas preservando a linguagem de implementação original.
A abordagem FUSION/RE foi utilizada para a realização da engenharia reversa do
sistema legado. Essa abordagem é utilizada para a recuperação dos modelos orientados a objetos
da fase de análise, propostos no método FUSION (Coleman et al, 1994), a partir de sistemas que
foram desenvolvidos sem esse paradigma.
No primeiro passo um modelo de objetos é elaborado a partir das estruturas de dados
existentes no sistema legado; esse modelo é pseudo-orientado a objetos. Em seguida, refina-se
esse modelo para que um modelo de classes seja obtido e a partir desses sejam elaborados os
modelos de ciclo de vida e de operações. As anomalias existentes no código legado são indicadas
pela classificação dos procedimentos que compõem o código legado. Essas anomalias referem-se
a um procedimento consultar e/ou alterar mais do que uma estrutura de dados; violando o
princípio de encapsulamento de dados na orientação a objetos. Uma tabela relacionando os
52
procedimentos com os métodos, elementos de dados com os atributos finaliza o processo de
engenharia reversa.
Após a realização do processo de engenharia reversa descrito acima, pode-se optar por
não trocar a linguagem original de programação do sistema legado, mas inserir características OO
que ele suporte. Dessa forma, o código legado, escrito em linguagem procedural é adaptado com
características de orientação a objetos. Os experimentos realizados mostraram que o código fica
melhor organizado, facilitando a manutenção/expansão do sistema legado, bem como a
reutilização dos métodos também pode ser comprovada.
Detalhes desse processo são encontrados no Relatório Técnico Científico “Módulo RSOO
– Reengenharia de Software Orientada a Objetos” (Sakata, 1998), no Relatório Técnico
“Detalhamento do Passo de Abstração do Modelo de Análise do Método FUSION RE” (Braga &
Masiero, 1998) e em (Penteado, 1996).
5.6.3 O processo de reengenharia de interfaces com RV para o sistema segmentado
No processo de reengenharia de interfaces do sistema segmentado, além da documentação
citada na seção 5.6.2, foram analisados o código - fonte do sistema e a execução do mesmo para
recuperação de dados sobre o sistema. Utilizou-se cenários textuais e diagramas de caixas,
mostrados nos Apêndices D e E respectivamente, no estilo dos diagramas apresentados nas
figuras 5.4 e 5.6, para representar a estrutura da interface e, conseqüentemente, como as
funcionalidades podem ser acessadas no sistema segmentado. Através dos conhecimentos
adquiridos com esse estudo foi possível preparar o sistema segmentado para receber a nova
interface com recursos de RV a ser gerada com auxílio do GaCIV.
A estrutura apresentada na figura 5.6 permite pelo menos duas maneiras de se realizar a
reengenharia de interface utilizando o GaCIV: substituindo os módulos no nível mais alto de
abstração ou re-agrupando as funcionalidades (módulos de abstração mais baixos). Optou-se pela
primeira, de forma que a reengenharia de interfaces mantivesse o critério de classificação das
funcionalidades utilizado originalmente. A escolha pela primeira opção foi feita com base na
idéia de que a classificação original está intimamente ligada ao paradigma de desenvolvimento e
implementação e, dessa forma, é possível avaliar o impacto do paradigma na interface com RV
gerada na reengenharia de interfaces.
53
A segunda opção permite a classificação das funcionalidades seguindo novos critérios,
podendo modificar o modelo de apresentação do sistema para o usuário. Observações sobre essa
opção são comentadas no Capítulo 7.
A aplicação original foi compilada a partir de um arquivo “batch” de nome
“CompSist.bat” que, por sua vez, compila e faz a ligação de todos os módulos do sistema criando
um único arquivo executável de nome “Sistema.exe”. A execução desse arquivo apresenta
interfaces semelhantes ao estilo de interação e apresentação.
A preparação do sistema segmentado resultou na criação de diversos arquivos “batch” que
compilassem apenas os módulos necessários para cada atividade distinta do sistema. A partir
desses arquivos, foram gerados seus respectivos arquivos “.exe”. Um exemplo é o arquivo
“CompConsCli.bat” que gera o arquivo “ConsCli.exe” e corresponde à atividade de consulta aos
dados de uma peça cadastrada no banco de dados do sistema como ilustra a figura 5.7.
Como comentado anteriormente, percebeu-se a possibilidade de criação de módulos de aplicação
em vários níveis de abstração, isto é, há a possibilidade de criar módulos no nível mais baixo de
abstração com o qual as atividades são acessadas diretamente e separadamente de outras (como é
o caso de “ConsCli.exe” ilustrada na figura 5.7) ou criar módulos em níveis intermediários de
abstração que apresentam um conjunto de atividades relacionadas, como pode ser visto na figura
5.8, que ilustra a execução do módulo de aplicação “Consulta.exe” criado a partir do sistema
segmentado.
FIGURA
5.7 –
Execução
do
módulo
de
aplicação
“ConsCli.
exe”
gerado a
partir da
versão
segmentada do sistema exemplo
54
FIGURA 5.8 – Execução do módulo de aplicação “Consulta.exe” gerado a partir da versão
segmentada do sistema exemplo
Foram gerados 70 módulos para o sistema segmentado, sendo 63 módulos em um baixo
nível de abstração, com cerca de 510 linhas de código cada módulo, e 7 módulos com cerca de
5000 linhas cada, em um nível de abstração alto. Com os módulos da aplicação gerados, o
sistema ficou preparado para receber a nova interface a ser criada com auxílio da ferramenta
GaCIV. Além da motivação relacionada à análise da influência do paradigma de
desenvolvimento na geração de interfaces com RV apresentada anteriormente, optou-se em
desenvolver a interface com RV através dos sete módulos de nível mais alto, como mostra o
diagrama da figura 5.9, com intuito de se obter resultados comparativos, lembrando que a
reengenharia da interface do sistema legado só foi possível nesse nível de abstração.
FIGURA 5.9 – Módulos do sistema segmentado na estrutura da árvore de menus
55
O diagrama da figura 5.9 localiza os sete módulos na estrutura da árvore de menus do
sistema segmentado. Os níveis de profundidade da árvore da estrutura da interface do sistema
segmentado estão numerados de forma que quanto mais alto a numeração for, mais baixo é o
nível de abstração da interface. Os sete módulos utilizados foram criados com base nos menus do
segundo nível de profundidade da estrutura e dão acesso às funcionalidades dos níveis mais
baixos, como mostrado no Anexo III. Por exemplo, o módulo Consulta, quando executado, dá
acesso às funcionalidades de consulta ao cliente (módulo “Conscli.exe”, visto na figura 5.7),
consulta a peças, consulta a componentes etc. A tabela 5.1 relaciona os menus originais, o nome
dos módulos e os nomes reais utilizados na implementação.
TABELA 5.1 – Associação entre menus originais, nome dos módulos criados e arquivos de
implementação dos módulos criados para o sistema segmentado
Menus Originais
Nome do Módulo
Implementação
Menu de Lançamentos
Lançamentos
Lancamen.exe
Menu de Relatórios
Relatórios
Relatorios.exe
Menu de Consultas
Consultas
Consulta.exe
Menu de Manutenção de Arquivos
Manutenção de Arquivos
Arquivo.exe
Menu de Manutenção de Tabelas
Manutenção de Tabelas
Tabela.exe
Menu de Impressos
Impressos
Impressa.exe
Menu de Indexação
Indexação
Index.exe
A criação da interface com RV para o sistema segmentado também se baseou no gabarito
gerado em atividades anteriores, porém, devido às características do sistema segmentado,
mostrou-se necessário a inclusão de novos objetos 3D. Durante o processo de reengenharia da
interface, percebeu-se novamente a necessidade de objetos que não estariam relacionados a uma
oficina mecânica, mas que abstraíssem atividades relacionadas ao sistema computacional. Dessa
maneira foram incluídos objetos para representar, por exemplo, consulta, impressão e
manutenção de arquivos. Para acessar os impressos o usuário seleciona o objeto “Impressora”,
localizado no “Balcão de atendimento”, ilustrado na figura 5.10.
56
FIGURA 5.10 – Objeto 3D “Impressora” ligado ao módulo “Impressos” do sistema segmentado
O objeto “Arquivo”, ilustrado na figura 5.11, dá acesso às funções de manutenção da
base de dados.
FIGURA 5.11 – Objeto 3D “Arquivo” ligado ao módulo “Manutenção de Arquivos” do sistema
segmentado
Os objetos da interface com RV, quando selecionados, executam módulos da versão
segmentada do sistema exemplo, isto é, a partir deles, o usuário acessa a interface original do
sistema segmentado, como visto nas figuras 5.10 e 5.11.
5.7 Sistema Orientado a Objetos
O sistema OO foi desenvolvido dentro do escopo desta pesquisa, com o objetivo de se
obter três versões de um mesmo sistema para serem analisadas comparativamente quanto ao
processo de reengenharia de interfaces com RV.
57
5.7.1 Características de implementação
O sistema OO foi desenvolvido na linguagem Java® (Java, 2002) utilizando o ambiente
visual JBuilder® (JBuilder, 2002) como apoio e o sistema de banco de dados Interbase®
(Interbase, 2002) para implementação da base de dados. Foram implementadas 83 classes, sendo
67 classes para a interface, 14 classes relacionadas às classes do domínio do sistema e 2 classes
específicas para implementação.
A versão final da interface do sistema OO foi implementada seguindo o estilo de interação
OO utilizando recursos WIMP, como ilustrado na figura 5.12.
FIGURA 5.12 – Interface da versão OO do sistema exemplo
Devido à modularização possível com a utilização do paradigma OO, a estrutura da árvore
de menus na interface apresentou-se profunda de forma semelhante à do sistema segmentado,
como pode ser visto na figura 5.13.
58
FIGURA 5.13 – Árvore de menus da interface do sistema OO
Na interface do sistema OO os objetos são apresentados como ícones gráficos 2D no
menu principal. A partir de cada um deles é possível acessar seus métodos de interação que
correspondem a funcionalidades do sistema, como mostra a figura 5.13.
Apesar da semelhança estrutural, a organização das funcionalidades na interface seguindo
o estilo de interação OO não pode ser mudada, pois essas funcionalidades estão organizadas de
forma a atender especificamente objetos que permitem a aplicação delas, enquanto na interface
OO a classificação das funcionalidades segue uma hierarquia criada pelo projetista, sem
quaisquer ligações com o tipo de dados que as funcionalidades acessam.
5.7.2 O processo de reengenharia do sistema orientado a objetos
O desenvolvimento da versão OO do sistema foi resultado de um processo de
reengenharia do sistema exemplo legado visando a mudança de paradigma de implementação,
linguagem de implementação e mudança de paradigma de interação da interface funcional e
textual para uma interface OO baseada em widgets WIMP.
Os modelos de projeto criados para o processo de segmentação foram analisados e
reconstruídos em UML para a reengenharia com mudança de linguagem de programação para
uma linguagem OO (Java®). O modelo de classes utilizado, mostrado no Apêndice A, foi obtido
a partir do modelo recuperado no processo de engenharia reversa usando FUSION RE, mostrado
no Anexo I. A partir da documentação e execução do sistema legado, foram gerados os modelos
de use case, mostrados no Apêndice B, e os diagramas de seqüência para as funcionalidades do
sistema, mostrados no Apêndice C.
59
Todas as funcionalidades apresentadas pelo sistema segmentado foram implementadas.
Duas versões de interface, com estilos diferentes de interação, foram geradas utilizando recursos
WIMP. A primeira versão possui características funcionais de interação de interfaces, isto é, o
usuário escolhe a função através de uma estrutura de menus para realizar suas tarefas, como
ilustrada na figura 5.14.
FIGURA 5.14 – Interface funcional para a versão OO do sistema exemplo.
Após a implementação, verificou-se que a interface funcional não expressava de forma
adequada, considerando o ponto de vista deste pesquisador, o paradigma de orientação a objetos
(OOUI). Por esse motivo, optou-se por uma segunda versão do sistema com interfaces icônicas.
A segunda versão, mostrada nas figuras 5.15, 5.16 e 5.17, segue o estilo OOUI de maneira
mais adequada, tendo os objetos do domínio do sistema representados por ícones que podem ser
organizados de acordo com a preferência do usuário. A organização dos objetos na interface pode
ser modificada através da ação “arrastar e soltar”. Nessa interface, como em qualquer OOUI, o
usuário escolhe o objeto da interface, e em seguida utiliza os métodos oferecidos por ele para
interagir com o objeto. O usuário deve clicar com o botão direito do mouse e obter um menu
popup com os métodos apropriados para a interação. Cada um dos ícones–objetos apresenta sua
identificação quando o cursor do mouse é posicionado neles (hint), ilustrado na figura 5.15.
60
FIGURA 5.15 – Hint do objeto “Cliente” na OOUI do sistema OO
A figura 5.16 apresenta uma nova organização dos ícones realizada através da ação
“arrastar e soltar”.
FIGURA 5.16 – Ícones reorganizados pelo usuário na OOUI do sistema OO
A interação com os objetos da interface á exemplificada na figura 5.17, onde é mostrado o
menu popup obtido ao se pressionar o botão direito do mouse no ícone que representa “Cliente”.
61
FIGURA 5.17 – Menu popup com métodos para interação com o objeto “Cliente” da interface do
sistema OO.
Idealmente, a OOUI deveria representar graficamente as instâncias criadas, como por
exemplo, inclusão de novo cliente em forma de um ícone semelhante ao ícone do objeto
“Cliente”. Entretanto, no ponto de vista deste pesquisador, isso causaria uma poluição visual na
interface, dificultando a identificação dos objetos com os quais o usuário está trabalhando.
5.7.3 O processo de reengenharia de interfaces com rv para o sistema orientado a objetos
Assim como realizado nas outras versões do sistema exemplo, utilizou-se o gabarito
previamente criado para a geração da interface avançada para realizar essa atividade. Apesar de
ter um maior aproveitamento dos objetos existentes, novos objetos 3D foram adicionados para
este processo como, por exemplo, o objeto “Caminhão de entrega” que representa o objeto
“Fornecedor” do domínio do sistema, ilustrado na figura 5.18, e o objeto 3D que representa o
objeto “Cliente” do sistema, ilustrado na figura 5.19.
62
FIGURA 5.18 – Objeto da interface avançada para representar o objeto “Fornecedor” da interface
do sistema OO
FIGURA 5.19 – Objeto da interface avançada do sistema OO para representar o objeto “Cliente”
Ao selecionar esses objetos na interface com RV, um menu com os métodos de interação
para o respectivo objeto é apresentado ao usuário, de acordo com os princípios do paradigma de
interação OO, ilustrado na figura 5.20.
63
FIGURA 5.20 – Opções de métodos para interagir com objeto “Cliente” do sistema OO com
recursos de RV
Observou-se, no processo de reengenharia da interface do sistema OO, que os objetos da
interface com RV tornaram-se versões 3D dos ícones da interface WIMP e foi necessária a
criação de uma camada de interface WIMP composta por botões para acessar as funcionalidades
de cada objeto. Essa camada equivale ao menu popup da interface original do sistema OO.
5.8 Considerações Finais
Neste capítulo foram apresentados os processos de reengenharia aplicado às interfaces das
três versões do sistema exemplo, assim como detalhes de implementação de cada um deles e
como foram obtidos.
Com as interfaces 3D criadas nos processos de reengenharia apoiados pelo GaCIV é
possível analisa-las comparativamente e obter importantes conclusões em relação à influência do
paradigma de desenvolvimento do sistema na usabilidade da interface resultante, além de
diretivas para o desenvolvimento de processos dessa natureza, como será visto no Capítulo 6 e 7.
64
Capítulo 6 – Análise dos Resultados Obtidos
6.1 Considerações Iniciais
Apesar de toda a extensa pesquisa realizada no campo de RV e em usabilidade, tendo
(Bowman et al, 2001a) (Bowman et al, 2001b) (Gabbard, 1997) (Kaur, 1998) (Gabbard e Hix,
2001) (Greenhalgh et al, 1997) (Nielsen, 1993) como trabalhos mais representativos, ainda há
pouca proximidade entre as duas áreas. Existem diversos métodos para avaliação de usabilidade
de aplicações interativas, porém esses métodos são limitados quando se trata de avaliação de
ambientes virtuais. Há necessidade de trabalhos que associem usabilidade e RV abrangendo as
complexas interdependências entre usuários, tarefas, mecanismos de entrada, mecanismos de
saída, etc, existentes em um ambiente de RV (Gabbard, 1997).
O teste de usabilidade de interfaces com RV imersiva junto ao usuário, por exemplo, pode
apresentar diversas dificuldades tais como a dificuldade de compartilhar uma mesma experiência
de interação entre o usuário e o avaliador e obter informações úteis a partir dela. Possíveis
problemas dessa natureza, entretanto, devem servir como estímulo ao teste de interfaces com RV
junto ao usuário, pois indicam a necessidade de treinamento especial para avaliadores e, até
mesmo, criação de novas ferramentas e processos para o teste de usabilidade nesse ambiente
(Nielsen, 1993).
A complexidade de testes com participação de usuários sugere o uso de um método de
avaliação heurística baseado em um conjunto de heurísticas de usabilidade. Atualmente poucas
abordagens de heurísticas de usabilidade específicas para interfaces com RV podem
ser
encontradas na literatura. Dois exemplos significativos são encontrados em (Kaur, 1998) e em
(Gabbard, 1997) que é estendida para realidade aumentada em (Gabbard & Hix, 2001). Essas
limitações dificultam a tarefa do engenheiro de software que necessita garantir a usabilidade da
interface com RV gerada, tanto na engenharia avante quanto na reengenharia de interfaces de
sistemas legados.
Neste capítulo é apresentada uma análise comparativa dos resultados obtidos a partir dos
processos de reengenharia de interface aplicados. Os critérios de usabilidade utilizados nas
avaliações heurísticas das interfaces WIMP e textuais são apresentados na seção 6.2. São
apresentadas análises de usabilidade das interfaces originais das três versões do sistema exemplo
65
nas seções 6.3, 6.4 e 6.5; os critérios de usabilidade utilizados para analisar interfaces com RV
são mostrados em 6.6; uma comparação entre interfaces originais e interfaces avançadas de cada
versão na seção 6.7, e, uma análise comparativa entre os resultados obtidos das três versões
também na seção 6.7. Na seção 6.8 são apresentadas algumas considerações finais.
6.2 Critérios de usabilidade para sistemas textuais e WIMP
Durante o estudo de caso, as interfaces legadas e as interfaces geradas pelos processos de
reengenharia foram analisadas utilizando heurísticas de usabilidade. Para as textuais e WIMP
utilizou-se as seguintes diretivas, revisadas por Nielsen (1993) a partir das originais de Nielsen e
Molich (1990):
1) Visibilidade do estado do sistema: os sistemas devem sempre manter o usuário
informado sobre o que ocorre, através de feedback em tempo razoável;
2) Concordância entre o sistema e o mundo real: o sistema deve usar linguagem familiar
ao usuário com conceitos familiares ao usuário ao invés de termos ligados ao sistema.
Seguir convenções do mundo real, fazendo a informação aparecer de forma natural e
em ordem lógica;
3) Controle e liberdade do usuário: usuários geralmente escolhem tarefas por engano das
quais ele deve poder sair imediatamente sem que seja forçado a passar por um diálogo
extenso desnecessário. Deve haver também apoio ao “desfazer” e “refazer”;
4) Consistência e padrões: usuários não devem se preocupar se palavras, situações e
ações diferentes possuem o mesmo significado;
5) Prevenção de erros: é melhor evitar erros do que corrigi-los;
6) Reconhecer, não relembrar: tornar objetos, ações e opções visíveis. O usuário não
deve ter que se lembrar de uma parte da interface para a outra;
7) Eficiência de uso e reconhecimento: oferecer atalhos para melhorar a performance de
usuários experientes;
8) Estética e design: diálogos não devem conter informações que não sejam relevantes ou
raramente usadas;
66
9) Ajuda para reconhecimento, diagnóstico e recuperação de erros: mensagens de erros
devem ser expressas em linguagem simples, sem usar códigos, indicando
precisamente o problema e sugerindo soluções;
10) Ajuda e documentação: mesmo que o sistema seja bem utilizado sem documentação, é
importante que haja documentação e ajuda para o usuário.
6.3 Análise da interface do Sistema Legado
A estrutura da árvore de menus da interface do sistema legado é representada na figura
6.1.
FIGURA 6.1 – Árvore de menus do sistema legado
Nota-se nesse diagrama que a árvore de menus é pouco profunda, com praticamente
apenas um nível de menu para se ter o acesso às funcionalidades. Apesar de aparentemente
simplificar a navegação do usuário, esse tipo de estrutura compromete a organização das
funcionalidades oferecidas pelo sistema. No sistema exemplo, algumas funções independentes
estão misturadas sob um mesmo rótulo na forma de sub-tarefas, como acontece com a inclusão de
dados de um cliente no banco de dados que está associado a “Lançamento da 1a Parte da Ordem
de Serviço”, mostrado na figura 6.2.
67
FIGURA 6.2 – Tela de Lançamento da 1a Parte da Ordem de Serviço do sistema legado
Para que o usuário possa cadastrar um cliente, ele deve selecionar a função “Lançamento
a
da 1 Parte da Ordem de Serviço” e digitar “99999” no espaço dedicado ao código do cliente.
Essa organização não natural das funcionalidades gera carga cognitiva desnecessária para o
usuário ou mesmo desorientação. Além disso, a orientação do usuário fica prejudicada quando se
passa de uma sub-tarefa para outra dentro de uma mesma tarefa. Para cumprir a tarefa
“Lançamento da 1a Parte da Ordem de Serviço” o usuário deve cumprir uma série de sub-tarefas
como “Selecionar Cliente”, “Verificar Dados do Cliente”, “Selecionar Veículo do Cliente”,
“Verificar Veículo do Cliente” e finalmente descrever os serviços a serem executados. A figura
6.2 mostra a terceira tela da interface para a tarefa “Lançamento da 1a Parte da Ordem de
Serviço” e nela já há poucos indícios de qual tarefa o usuário está realizando.
Outro fator que afeta a navegação do usuário é a inconsistência de rótulos e de comandos
para cancelar ações. Durante a navegação na interface do sistema são encontrados os rótulos
“Abertura da Ordem de Serviço”, “Entrada Ordem de Serviço” e “Lançamento da 1a Parte da
Ordem de Serviço” com o mesmo significado. Em relação aos comandos de cancelamento, na
maior parte do sistema pode-se utilizar a tecla “ESC”, apesar de não estar especificado em lugar
algum qual é a função da tecla “ESC”. Entretanto em algumas sub-tarefas o cancelamento é feito
através de outros comandos, como “0”, na figura 6.2, e “A” na figura 6.3.
Devido a sua natureza textual o design é pobre, possuindo poucos elementos gráficos e
que pode se tornar cansativo após algum tempo de uso contínuo.
68
A hora e a data atual, dados não muito relevantes para a execução de tarefas do usuário, são
mostradas com destaque em todas as telas, podendo causar desvio de atenção e perda de
performance.
FIGURA 6.3 – Tela de verificação de “Veículos do Cliente”
O feedback ao usuário é dado em mensagens na parte inferior da tela e em mensagens de
erro em fundo vermelho como o exemplo mostrado na figura 6.4.
FIGURA 6.4 – Mensagem de erro do sistema legado
Percebe-se, ao analisar a mensagem ilustrada na figura 6.4, que o usuário não tem como
saber se o erro foi causado pelo sistema ou por suas ações. Além disso, as opções oferecidas para
o usuário não explicitam quais serão seus resultados, isto é, o usuário não tem como saber o que
acontece se ele escolher a opção “Default”, por exemplo. Com isso a recuperação a partir de um
erro fica comprometida.
O sistema ainda oferece listas de elementos selecionáveis para facilitar e evitar erros no
preenchimento de dados durante a execução das tarefas, como a lista de clientes na execução da
tarefa “Abertura da Ordem de Serviço” ilustrada na figura 6.5.
69
FIGURA 6.5 – Preenchimento de dados do cliente com seleção
Entretanto essa facilidade não é encontrada consistentemente em toda a interface, como
pode ser visto na figura 6.6, onde o usuário deve entrar com o nome do cliente a ser consultado.
FIGURA 6.6 – Preenchimento de dados do cliente sem seleção
6.4 Análise da Interface do Sistema Segmentado
A estrutura da árvore de menus da interface do sistema segmentado, representada na
figura 6.7, mostra-se um pouco mais profunda que a apresentada pelo sistema legado. Há duas ou
mais camadas de menus para que o usuário acesse a funcionalidade desejada. Essa organização
permite que funcionalidades independentes encontrem-se separadas e classificadas segundo
algum critério que satisfaça as necessidades do usuário. Por exemplo, as tarefas relacionadas a
consultas à base de dados, foram rotuladas como “Consultas”, como visto na figura 6.8, e dessa
70
forma acessadas a partir do menu principal. A reorganização das funcionalidades, facilitando o
reconhecimento pelo usuário e conseqüentemente melhorando a performance na realização de
tarefas, foi possível devido ao processo de segmentação ao qual o sistema legado foi submetido
em um trabalho anterior (Penteado, 1996).
Além da reorganização das funcionalidades, foram eliminadas as ambigüidades de rótulos
nas novas camadas de menus. Entretanto, as interfaces no nível mais baixo de abstração, que
ocorrem durante a execução das funcionalidades, não foram modificadas e, portanto, mantém as
características originais do sistema legado.
O feedback nos novos menus foi melhorado, mostrando mensagens que explicitam o
objetivo do menu em questão na parte inferior da tela, como pode ser visto na figura 6.8.
Apesar da sensível melhora na navegação causada pela reorganização das funcionalidades
em novos menus, os rótulos utilizados no menu principal estão mais ligados ao contexto
computacional do que ao contexto do domínio do sistema. Nesse menu encontram-se rótulos
como: “Consultas”, “Manutenção de Arquivos” e “Indexação”.
FIGURA 6.7- Estrutura de árvore de menus do sistema segmentado
71
FIGURA 6.8 – Menu de consultas do sistema segmentado
Além disso, nem todas as funções se beneficiaram com a nova organização dos menus. A
função consultar peças, por exemplo, possui mais de um critério de consulta, fazendo com que o
usuário tenha que navegar para outros menus, a partir do representado na figura 6.9, se quiser
tentar mais de uma opção de consulta.
FIGURA 6.9 – Menu de consultas a peças do sistema segmentado
Foi observado, durante as análises dos sistemas legado e segmentado, que sistemas
legados baseados em formulários e consultas a bancos de dados possuem um conjunto de tarefas
comuns que são aplicadas a diferentes tipos de dados. Essas operações são cadastrar ou inserir
dados no banco de dados, consultar dados, atualizar dados, excluir dados, imprimir relatórios.
Apesar disso, essas operações podem estar estruturadas de formas distintas, muitas vezes
72
confusas, na interface do sistema legado devido à desestruturação do código. Com isso, o usuário
acaba se perdendo ou tendo dificuldades para acessar as tarefas aplicáveis ao dado desejado.
6.5 Análise de Usabilidade da Interface do Sistema OO
A interface do sistema orientado a objetos baseia-se em widgets WIMP e segue o
paradigma de interação orientada a objetos (OOUI) ao invés do paradigma funcional usado
anteriormente, tendo os objetos do domínio do sistema representados por ícones gráficos que
podem ser reorganizados de acordo com a preferência do usuário. Os ícones substituem os menus
principais das versões anteriores do sistema.
Na figura 6.10 está representada a árvore de menus do sistema OO.
...
Funcionalidades do
Funcionalidades do
Funcionalidades do
objeto 1
objeto 2
objeto 3
FIGURA 6.10 – Árvore de menus do sistema OO
...
73
Semelhante ao que ocorre com a árvore de menus do sistema segmentado, duas camadas
de interface precisam ser navegadas pelo usuário para que sejam acessadas as funcionalidades do
sistema. A segunda camada corresponde aos menus popup de cada objeto da interface que
oferecem ao usuário listas de funcionalidades permitidas para interação com os objetos. Uma
grande diferença na mudança de estilo de interação é que o usuário em um estilo funcional pensa
na tarefa a ser realizada antes de escolher o dado que vai utilizar, ou seja, o objeto que sofrerá a
ação. No paradigma OO de interação, a ordem de raciocínio é inversa, pois o usuário escolhe
primeiro o dado (objeto) que vai ser utilizado, depois a ação que esse objeto sofrerá. Isso faz com
que, no estilo de interface OO, o usuário cometa menos erros, pois ele só pode realizar as tarefas
permitidas para aquele tipo de dado/objeto escolhido (Collins, 1995).
Para prevenir erros, a interface dispõe para o usuário caixas de itens selecionáveis para
preenchimento de dados requisitados pelo sistema, como mostra a caixa da figura 6.11, onde o
usuário escolhe o cliente a ser consultado.
FIGURA 6.11 – Caixa de itens selecionáveis para a funcionalidade “Consultar Cliente” do
sistema OO
O feedback ao usuário é dado através de janelas de alerta em casos de erros, ilustrado na
figura 6.12, e em dicas (hints) dadas ao repousar o cursor do mouse sobre algum item da interface
por um instante, visto na figura 6.13.
74
FIGURA 6.12 – Janela de alerta ao usuário no sistema OO
FIGURA 6.13 – Hint apresentado para campo “Categoria” do formulário de cadastro de clientes
no sistema OO
A utilização de widgets permitiu a solução para um problema de navegação encontrado na
versão anterior durante a execução da tarefa de consulta de peças. Através de “radio buttons” o
usuário pode mudar a opção de consulta a peças sem mudar de menu da interface, como é
mostrado na figura 6.14.
75
FIGURA 6.14 – Escolha de opção de consulta de peças no sistema OO
Ainda na figura 6.14, pode-se notar que apenas a opção escolhida pelo usuário apresentase disponível para uso, isto é, o radio button tem a função de habilitar a opção escolhida e
desabilitar todas as outras. A ambigüidade de comandos para cancelar uma ação foi eliminada
utilizando-se botões com o rótulo “Cancelar” em todos os menus.
6.6 Critérios de usabilidade para sistemas com interfaces com RV
Para analisar a usabilidade das interfaces com RV geradas com apoio do GaCIV foram
observadas as seguintes diretivas extraídas da taxonomia de Gabbard (1997) de acordo com a
aplicabilidade no sistema em questão. As tabelas de 6.1 a 6.7 apresentam o contexto das diretivas,
os rótulos pelos quais serão referenciadas no texto e a descrição da diretiva.
76
TABELA 6.1 – Diretivas para “Usuários em Ambientes Virtuais”
Usuários em Ambientes Virtuais
Rótulo
Diretiva de Usabilidade
Usuário1
Contar com a experiência do usuário
Usuário2
Contar com as aptidões técnicas do usuário (orientação, visualização espacial etc)
Usuário3
Apoiar tanto usuários destros quanto canhotos
Usuário4
Acomodar interação natural para usuários de várias idades
TABELA 6.2 – Diretivas para “Navegação e Locomoção”
Navegação e Locomoção
Rótulo
Diretiva de Usabilidade
Nav1
Considerar princípios organizacionais na construção do ambiente
Nav2
Quando apropriado, incluir rótulos espaciais, pontos de referência, e um horizonte
Nav3
Evitar navegação baseada em modo
TABELA 6.3 – Diretivas para “Seleção de Objeto”
Seleção de Objeto
Rótulo
Diretiva de Usabilidade
Seleção1
Usar manipulação direta para seleções baseadas em atributos espaciais (forma, local,
orientação)
Seleção2
Quando houver seleção de objetos distantes, exagerar o tamanho, aparência e inter –
distância de objetos
Seleção3
Seleção de objetos deve ser o mais óbvio e acessível possível
TABELA 6.4 – Diretiva para “Apresentação do Usuário e Representação”
Apresentação do Usuário e Representação
Rótulo
Diretiva de Usabilidade
Repres1
Prover ponto de vista egocêntrico quando usuários devem experimentar um forte
senso de presença
77
TABELA 6.5 – Diretiva para “Envolvimento Virtual e Configuração”
Envolvimento Virtual e Configuração
Rótulo
Diretiva de Usabilidade
Config1
Explorar experiências do mundo real, mapeando funcionalidades desejadas para itens
do dia a dia
TABELA 6.6 – Diretivas para “Mecanismos de Entrada em Geral”
Mecanismos de Entrada em Geral
Rótulo
Diretiva de Usabilidade
Entrada1
Eliminar graus-de-liberdade estranhos implementando apenas as dimensões que os
usuários percebem como relacionadas as suas tarefas
Entrada2
Segundo o ponto de vista do usuário, o dispositivo de saída deve ser consistente e
ligado cognitivamente a suas ações
Entrada3
Diminuir a carga cognitiva evitando dispositivos tais como joysticks e bastões
Entrada4
Evitar integração entre dispositivos de entrada tradicionais como teclados e mouses
e dispositivos de entrada 3D
TABELA 6.7 – Diretivas para “Sistema com Ambiente Virtual e Informação da Aplicação”
Sistema com Ambiente Virtual e Informação da Aplicação
Rótulo
Diretiva de Usabilidade
SisInfo1
Prestar atenção especial à organização da apresentação visual
As diretivas escolhidas e apresentadas anteriormente nas tabelas de 6.1 a 6.7 foram
escolhidas por abordarem aspectos de navegação em alto nível de abstração nas interfaces com
RV não-imersiva, além de abordar aspectos de dispositivos de entrada e saída para RV nãoimersiva, tecnologia utilizada neste trabalho.
6.7 Análise Comparativa dos processos de Reengenharia
Os processos de reengenharia de interfaces realizados visaram aumentar a usabilidade do
sistema ao incrementar o senso de envolvimento do usuário através da modificação significativa
de elementos de navegação e apresentação nos níveis mais altos de abstração da árvore de menus
78
do sistema exemplo. Dessa forma, a análise comparativa foi realizada visando principalmente o
impacto da reengenharia de interface para interface com RV nas características relacionadas à
navegação e apresentação das interfaces.
Analisando as interfaces geradas com o GaCIV durante os processos de reengenharia de
interfaces, em relação às características de usabilidade extraídas de (Gabbard, 1997) e citadas
anteriormente na seção 6.6, foram constatadas algumas características comuns às três versões do
sistema exemplo :
•
A utilização da RV não-imersiva mostrou-se positiva em relação à diretiva “Entrada2”,
pois o uso de monitores comuns para a apresentação dos gráficos 3D evita a necessidade
de treino para utilização de dispositivos especiais. Além disso, o usuário também entrará
em contato com menus 2D da aplicação, menus estes que são comprovadamente
eficientes em monitores simples.
•
Tendo como base as diretivas “Entrada3” e “Entrada4”, associando-as ao contexto da
mudança de interfaces puramente textuais para interfaces RV, conclui-se que o uso de
mecanismos avançados de entrada necessários para a navegação em um ambiente de RV
imersiva poderia aumentar o esforço cognitivo do usuário. As interfaces geradas neste
trabalho permitem que os usuários do sistema original continuem utilizando os mesmos
mecanismos de entradas aos quais ele já estava habituado, isto é, mouse e teclado.
•
Ainda em relação aos dispositivos de entrada, a opção por dispositivos 2D vai de acordo
com as diretivas “Usuário1”, “Usuário2”, “Usuário3” e “Usuário4”, pois são dispositivos
consolidados e populares aos quais a grande maioria dos usuários está familiarizada.
•
A seleção de objetos permitida pelo GaCIV é simples e intuitiva, pois se aproxima da
idéia de seleção no mundo real (Gabbard, 1997), como indicado em “Seleção1” e
“Seleção3”. Como os objetos podem ser selecionados independentemente da distância
entre ele e o usuário, evita-se a necessidade de excessiva locomoção do usuário dentro do
ambiente RV para acessar suas tarefas. Entretanto, para que isso ocorra os objetos
apresentados devem ter formas, cores, tamanho e posicionamento que os distinguam bem
um dos outros, como observado em “Seleção2”, cuidado este que foi tomado durante a
geração das interfaces.
•
Durante a reengenharia de interfaces textuais para interfaces com RV, notou-se que
realizar o mapeamento da navegação do usuário nas interfaces legadas, através de menus,
79
para objetos 3D da forma mais natural possível é fundamental para se obter uma interface
com usabilidade, como indica a diretiva “Config1”. Segundo essa diretiva, o ambiente
virtual no qual o usuário está imerso afeta a usabilidade ao transmitir um contexto para as
tarefas do usuário.
•
O ponto de vista egocêntrico, ou ponto de vista do usuário, nas interfaces com RV
geradas pelo GaCIV reforça a idéia de imersão que traz grande parte do ganho em
usabilidade ao optar por esse tipo de interface como indica a diretiva “Repres1”.
•
Apesar de ser possível a movimentação usando os seis graus de liberdade, propostos para
ambientes com RV, as interfaces do GaCIV não necessariamente exigem essa
movimentação. Os graus de liberdade utilizados durante a navegação do usuário
dependem do posicionamento dos objetos, que por sua vez dependem do contexto do
sistema. As diretivas “Entrada1” e “Nav1” devem ser considerada durante a construção
das interfaces, visando o melhor posicionamento dos objetos segundo o domínio do
sistema.
•
Apesar da interface resultante ser uma interface mista (parte 3D e parte 2D), como o
estilo de interação básico não muda (apontar e clicar), não há aumento significativo de
esforço cognitivo em relação a esse aspecto.
6.7.1 Sistema Legado
(a) Interface do Sistema Legado
(b) Interface com RV para o Sistema Legado
FIGURA 6.15 – Interfaces do Sistema Legado
80
O processo de reengenharia da interface do sistema legado que resultou na interface
apresentada na figura 6.15 (b) apresentou poucos benefícios, pois apenas acrescentou uma
camada de interface, o que aumentou o esforço necessário para o acesso das tarefas fornecidas
pelo sistema, como mostra a figura 6.16. Isto é, a interface apresentada na figura 6.15 (b) não
substitui o menu mostrado na figura 6.15 (a), colocando-se entre o usuário e suas tarefas como
mostra o diagrama de caixas da figura 6.16.
FIGURA 6.16 – Estruturas de interface para o sistema legado com interface com RV
6.7.2 Sistema Segmentado
Ao contrário da interface com RV para o sistema legado, a interface com RV para o
sistema segmentado - figura 6.17(a) - substitui o menu principal da interface original - figura
6.17(b) . As opções de funcionalidades que antes eram apresentadas em textos agora são
apresentadas por objetos gráficos 3D. Além de representarem individualmente opções de
funcionalidades, o conjunto dos objetos constitui um contexto para as funcionalidades, facilitando
a percepção e associação realizada pelo usuário.
81
(a) Interface do Sistema Segmentado
(b) Interface com RV para o Sistema
Segmentado
FIGURA 6.17– Interfaces do Sistema Segmentado
O agrupamento de objetos gerando contextos para tarefas relacionadas entre si é apoiado
pela diretiva “SisInfo1”, citada anteriormente. Com essa meta em vista, os objetos da interface do
sistema segmentado foram organizados de forma a sugerirem contextos para suas
funcionalidades, obviamente dentro de um contexto maior que é a “oficina mecânica”. Obteve-se
então três agrupamentos distintos dentro do mesmo ambiente representando três contextos
diferentes: “Escritório da Oficina”, “Compras e Vendas” e “Pátio de Oficina”. O contexto
“Escritório de Oficina” é ilustrado na figura 6.17(b) mostrando objetos relacionados a tarefas de
acesso a arquivos de dados e impressão de relatórios. O contexto “Compras e Vendas” é ilustrado
na figura 6.18.
82
FIGURA 6.18 – Contexto de “Compras e Vendas” na interface com RV do sistema segmentado
Na figura 6.18 são mostrados objetos que sugerem em seu conjunto uma transação
comercial envolvendo os produtos representados pelas caixas. A partir desses objetos é possível
acessar as funcionalidades relativas ao “Lançamento de Compras”, “Lançamento de Vendas” e
“Contas a Pagar e Receber”.
O contexto “Pátio de Oficina” é ilustrado pela figura 6.19.
FIGURA 6.19 – Contexto de “Pátio de Oficina” na interface com RV do sistema segmentado
83
Os objetos de “Pátio de Oficina” mostram um cliente e seu carro aparentemente com
problemas. Nesse contexto pode-se acessar a funcionalidade “Lançamento de Ordem de Serviço”.
A ligação semântica entre os objetos 3D e a funcionalidade do sistema está no fato de uma ordem
de serviço ser requisitado sempre por um cliente que necessita de algum serviço de manutenção
para seu veículo.
Como dito anteriormente, os diferentes contextos das funcionalidades podem ser
representadas a partir da organização e agrupamento dos objetos da interface. Entretanto a
representação de diferentes contextos em uma mesma interface, especialmente em um mesmo
ambiente de RV, implica na utilização de pistas ou rótulos para facilitar o reconhecimento destes
contextos, como indica a diretiva “Nav2”. Nesse sentido, procurou-se fazer dos próprios
conjuntos de objetos as pistas necessárias para reconhecimento dos contextos, destacando-se o
“balcão” e o “funcionário operando o computador” para representar o contexto “Escritório da
Oficina”, o “dinheiro” e a “mulher compradora” para representar o contexto “Compras e
Vendas”, e o objeto “carro com defeito” para representar o contexto “Pátio de Oficina”. Essa
solução para distinguir contextos foi escolhida visto que a separação dos contextos utilizando
obstáculos físicos no ambiente virtual, tais como paredes e portas,
dificultariam a navegação do
usuário impedindo-o de passar de um contexto ao outro rapidamente. Segundo a opção escolhida,
tudo que o usuário precisa fazer para mudar de contexto é girar alguns graus sobre o próprio eixo
Y.
O uso de rótulos textuais seria uma opção valiosa para facilitar a identificação das tarefas
representadas pelos objetos 3D, principalmente tarefas abstratas como “Consultar Arquivos”,
representada pelo objeto “Lupa”. Entretanto essa opção não pode ser utilizada por limitações do
ambiente GaCIV em sua versão atual.
Apesar de toda a preocupação em permitir um melhor acesso às funcionalidades, a
reengenharia da interface do sistema segmentado esbarrou em um problema recorrente do
processo de segmentação aplicado: a granularidade da modularização obtida. Na interface
original, várias funcionalidades distintas se encontram sob o rótulo “Lançamentos”. Dessa forma
os objetos 3D relativos a “Compras e Vendas” e a “Pátio de Oficina” ativam o menu
“Lançamentos” da interface original, mostrada na figura 6.20.
84
FIGURA 6.20 – Menu de lançamentos do sistema segmentado
A figura 6.20 mostra como diversas funcionalidades, distintas o bastante para serem
representadas separadamente, estão indevidamente agrupadas sob o mesmo rótulo “Lançamento”.
Isso resulta em uma classificação nada intuitiva ao usuário e conseqüentemente complexidade
maior para representação com objetos 3D relacionados ao cotidiano do usuário.
6.7.3 Sistema OO
Como ocorrido com a interface gerada para o sistema segmentado, a interface com RV
gerada para o sistema OO substitui o menu principal da interface original de forma a aprimorar a
apresentação das funcionalidades, tornando a interface mais envolvente para o usuário.
Na figura 6.21 estão ilustradas as interfaces original e com RV do sistema OO. No
sistema OO, é possível utilizar objetos que reflitam o domínio do sistema, como por exemplo
“Cliente”, “Empregado” ou “Peças”. Como o domínio do sistema está relacionado diretamente
com objetos do mundo real, há maior facilidade em representá-los na interface 3D. Dessa forma,
a interface avançada resultante do processo de reengenharia de interfaces aplicado no sistema OO
apresenta-se mais intuitiva e natural para o usuário de acordo com as diretivas “Usuário1” e
“Config1” citadas anteriormente na seção 6.6.
85
(a) Interface do Sistema OO
(b) Interface com RV do Sistema OO
FIGURA 6.21 – Interfaces para o Sistema OO
A utilização do paradigma OO de interação na interface do sistema OO permitiu a
necessidade de apenas dois contextos na interface: “Compras e Vendas” e “Pátio de Oficina”. Os
objetos representados na interface buscam representar objetos do domínio do sistema sendo que
as operações de manipulação dos dados desses objetos podem ser acessados à partir da seleção de
sua representação 3D. Na figura 6.22, é exemplificado como o usuário acessa a função “Novo”,
referente à tarefa “incluir cliente no banco de dados”, após ter selecionado a representação 3D do
cliente na interface com RV.
(a) Popup obtidos à partir dos ícones 2D
(b) Menu de opções obtido à partir de objetos 3D
FIGURA 6.22 – Ações permitidas para o objeto “Cliente”
86
Ao selecionar o objeto desejado, o usuário recebe as opções de funcionalidades permitidas
para aquele objeto em forma de um menu WIMP composto por botões, como mostrado na figura
6.22 (b). O menu de opções corresponde ao menu popup da interface original, visto na figura
6.22 (a). Com isso, eliminou-se a necessidade do contexto “Escritório de Oficina”, facilitando a
navegação do usuário. Os objetos da interface com RV do sistema OO concentram-se
principalmente no contexto “Pátio de Oficina” pois é o contexto mais intuitivo, segundo o ponto
de vista deste pesquisador, quando se trata de uma oficina mecânica.
O contexto de “Compras e Vendas” foi criado de forma semelhante ao ilustrado na figura
20 para representar compras e vendas de peças e funcionalidades relativas a finanças.
Apesar dos ganhos em qualidade na apresentação das funcionalidades na interface com
RV, alguns recursos existentes na interface WIMP, tais como possibilidade de personalização da
organização dos objetos da interface e o rótulo textual, existentes para os ícones, não puderam ser
reproduzidos na nova interface. Entretanto, se por um lado a reorganização dos objetos parece
interessante para que o usuário possa personalizar sua interface, aproximando objetos
relacionados a tarefas mais freqüentemente utilizadas, no caso da interface com RV a alteração da
organização dos objetos poderia descaracterizar os contextos criados para facilitar o
reconhecimento das tarefas. Além disso, a reorganização dos objetos em um ambiente virtual
implica em movimentação e rotação de objetos em um espaço de três dimensões, algo bem
menos trivial do que a movimentação de ícones 2D.
Em relação aos rótulos textuais, a organização dos objetos 3D em contextos procurou
compensar a impossibilidade de utilizá-los devido a limitações do ambiente GaCIV. Além disso,
era esperado que com o ganho no poder de representação obtido com objetos 3D não fosse
necessário a utilização de rótulos 3D.
6.7.4 Comparação entre os processos de reengenharia de interface: Sistema Legado vs.
Segmentado vs. OO
Com exceção da versão legada do sistema, a reengenharia da interface utilizando o
GaCIV como apoio automatizado das duas outras versões do sistema, segmentada e OO,
modificou significantemente a navegação e acesso às tarefas do usuário.
Nos processos de reengenharia das interfaces das versões do sistema exemplo, procurouse fazer o mínimo de alterações necessárias ao código existente. Assim, a reengenharia aplicada
87
ao sistema legado apresentou poucos benefícios, pois apenas acrescentou uma camada de
interface para acessar sua estrutura monolítica, o que aumentou o esforço cognitivo necessário
para interação e conseqüentemente para o acesso das tarefas fornecidas pelo sistema.
As interfaces com RV geradas para os sistemas segmentado e OO resultaram em maiores
benefícios para esses sistemas pois substituíram os menus principais dos dois. A principal
diferença entre a interfaces avançadas geradas para o sistema segmentado e o sistema OO é a
natureza dos objetos que as compõem. Para a interface do sistema segmentado, utilizam-se
objetos que abstraem tarefas a serem realizadas pelo usuário, como por exemplo “Consultar”. Já
no sistema OO, é possível utilizar objetos que refletem os objetos do domínio do sistema, como
por exemplo “Cliente” ou “Peças”. Em outras palavras, a interface avançada para o sistema
segmentado apresenta objetos que refletem, na sua maioria, abstrações ligadas ao sistema
computacional; enquanto que a interface avançada para o sistema orientado a objetos concentrase na representação de objetos do domínio do sistema, e, portanto, de maior significado para as
tarefas do usuário.
Essa diferença da natureza dos objetos, causada pela estruturação dos sistemas exemplos,
resultou em representações de contextos e quantidade de objetos diferentes. Para acessar as
funcionalidades do sistema segmentado, grande parte delas foi representada por objetos do
contexto “Escritório da Oficina”, que apresenta pouca ligação semântica com os outros contextos,
“Compras e Vendas” e “Pátio de Oficina”, da mesma interface.
Em contrapartida, a interface gerada para o sistema OO concentrou-se no contexto “Pátio
de Oficina”, tornando-se mais intuitiva, segundo o ponto de vista deste pesquisador.
Além da estruturação do sistema, o estilo de interação influenciou as interfaces com RV.
O usuário, em um estilo funcional (segmentado) pensa na tarefa a ser realizada antes de escolher
o dado que vai utilizar, ou seja, o objeto que sofrerá a ação. No outro estilo, OO, a ordem de
raciocínio é inversa, pois o usuário escolhe primeiro o dado (objeto) que vai ser utilizado, depois
a ação que esse objeto sofrerá. Isso faz com que, no estilo de interface OO, o usuário cometa
menos erros, pois ele só pode realizar as tarefas permitidas para aquele tipo de dado/objeto
escolhido.
Em relação ao processo de reengenharia de interfaces aplicado nas três versões do
sistema, observou-se que:
88
-
na versão OO do sistema o esforço para a reengenharia das interfaces é muito próximo do
despendido para o segmentado. Isso acontece, segundo ponto de vista deste pesquisador,
pela segmentação do sistema ter sido pautada pelo paradigma OO;
-
a vantagem apresentada pelo processo de reengenharia de interface aplicado no sistema
segmentado é que os objetos 3D obtidos para representar ações do usuário na interface
com RV, por não estarem ligados diretamente ao domínio do sistema, possuem a
possibilidade de ser reutilizados em interfaces de outros sistemas que sejam baseados em
ações de acesso a bancos de dados e impressão de documentos. Ressalta-se que grande
parte dos sistemas legados comerciais é baseada nessas ações.
É importante notar que os problemas de usabilidade encontrados nos níveis mais baixos
de abstração das interfaces originais não foram atingidos pela reengenharia de interface
aplicada.
Foi observado nos processos de reengenharia de interfaces aplicados que dois tipos
distintos de menus podem ser encontrados nas árvores de menus de sistemas interativos:
-
menus de classificação, que correspondem aos menus de mais alto nível de abstração,
utilizados pelo projetista para classificar as funcionalidades. Nesses menus, nenhum
processo computacional significativo é realizado. A tarefa do usuário é navegar por eles
em busca das funcionalidades desejadas. O código fonte desse tipo de menu pode ser
facilmente separado do código da aplicação pois não está relacionado a nenhum processo
de transformação de dados;
-
menus ou interfaces de acesso às funcionalidades. Esse tipo de interface está fortemente
ligado a funcionalidades do sistema, sendo necessário estudos cuidadosos para extração
de seu código do código da aplicação.
Como neste trabalho foi realizada apenas a reengenharia dos menus de classificação,
nenhum problema de usabilidade em níveis de menus de funcionalidades foi atingido.
6.7 Considerações finais
Neste capítulo foram analisadas as interfaces obtidas através da reengenharia das
interfaces das três versões do sistema exemplo. Na análise realizada comparou-se as interfaces
originais e interfaces com RV de cada uma das versões e, em seguida, comparou-se as interfaces
89
com RV das três versões. Com isso, foi possível elicitar problemas e soluções de usabilidade
adicionados pelas novas interfaces aos sistemas exemplos.
Ambos os sistemas, segmentado e OO, permitiram que suas funcionalidades fossem
reestruturadas na interface devido suas implementações modularizadas. A partir da análise
comparativa observou-se que o sistema OO obteve maiores benefícios com o processo de
reengenharia da interface seguido pelo sistema segmentado. O sistema legado, com sua estrutura
monolítica, não apresentou melhorias em usabilidade com a adição da interface com RV, pelo
contrário, dificultou o acesso às suas funções.
90
Capítulo 7 - Conclusões
7.1 Considerações iniciais
Um dos objetivos principais deste trabalho é verificar o apoio que o paradigma OO
oferece ao processo de reengenharia de interfaces para interfaces com RV, processo esse apoiado
pelo ambiente GaCIV. Também é apresentado aqui um conjunto de diretivas de reengenharia de
interfaces para interfaces com RV a partir da experiência obtida com o estudo de caso. Durante o
trabalho foram observados pontos que podem ser cruciais para a eficiência do processo de
reengenharia de interface tal qual foi realizada. Em relação a esses pontos, procurou-se diretivas
que pudessem auxiliar o engenheiro de software a lidar com eles. Nem todas as diretivas são
fáceis de seguir porque dependem do contexto em que serão aplicadas e, obviamente, do bom
senso da equipe envolvida com a reengenharia da interface. Entretanto, as diretivas apresentadas
aqui serão explicadas para simplificar o máximo possível seu uso.
Nesse capítulo são apresentadas algumas considerações sobre o escopo do trabalho na
seção 7.2, as conclusões do trabalho na seção 7.3 e possíveis trabalhos futuros resultantes desta
pesquisa na seção 7.4.
7.2 Considerações sobre o Escopo do Trabalho
Durante este trabalho procurou-se seguir a proposta inicial de realizar a reengenharia de
interfaces em sistemas que passaram anteriormente por reengenharia, sem alteração significativa
do código das interfaces originais. Com isso, a reengenharia de interfaces foi realizada de forma a
reorganizar os módulos das aplicações existentes, substituindo o nível mais alto de abstração de
menus por uma camada de interface utilizando RV. Apesar dos resultados esperados terem sido
obtidos, isto é, a confirmação do paradigma OO como paradigma de desenvolvimento que facilita
a integração de interfaces com RV com sistemas legados em um processo de reengenharia, e a
possibilidade de avaliar a influência dos paradigmas de desenvolvimento e implementação nesse
processo de reengenharia de interfaces, observou-se que outros resultados relevantes poderiam
ser obtidos se os sistemas exemplos sofressem uma nova fase de engenharia reversa de forma que
todo o código de suas interfaces fosse separado das aplicações, permitindo que a reengenharia de
91
interfaces atingisse um nível mais baixo de abstração. Esse processo de separação do código da
interface e do código da aplicação é recomendado por Moore (1996), como citado anteriormente,
desde que seja apoiado por ferramentas automatizadas. Essa atividade extrapola o escopo desta
pesquisa e não foi realizada devido a limitações de tempo.
Uma das maiores dificuldades encontradas neste trabalho, na fase de reengenharia de
interfaces para interfaces com RV, foi a elaboração de metáforas para composição do gabarito e,
posteriormente, das interfaces com RV. Alguns conceitos e objetos de natureza abstrata
apresentaram maior complexidade para ser representados com objetos 3D. É importante ressaltar
que uma metáfora de interface que represente um modelo de interação incorreto pode causar
dificuldades para o usuário (Rocha e Baranauskas, 2000).
Durante os processos de reengenharia de interface, percebeu-se que as dificuldades em
compor metáforas se devem ao aspecto multidisciplinar inerente ao desenvolvimento de
interfaces e a impossibilidade de formar uma equipe com tal característica para este trabalho
(Rocha e Baranauskas, 2000). Além da necessidade de especialistas da área de comunicação
visual, de design gráfico (CAD 3D), de lingüística e outras disciplinas relacionadas, a equipe de
desenvolvimento das interfaces de RV deveria incluir também representantes das diversas classes
de usuários finais do sistema. A participação de usuários durante o desenvolvimento permitiria a
obtenção de avaliação e
feedback nas fases de desenvolvimento dos gabaritos e,
conseqüentemente, a elicitação e correção de problemas de usabilidade antes do estágio final de
geração e ligação das interfaces aos aplicativos.
Buscou-se, dentro das limitações encontradas em relação ao cronograma e recursos
humanos, aplicar metáforas visando espelhar o mundo real na interface 3D, como utilizado pela
IBM (2000a).
Apesar das limitações citadas, este trabalho buscou atingir questões sobre uma prática não
abordada de forma específica na literatura atual, a reengenharia de interfaces para interfaces com
RV, oferecendo contribuições que podem se tornar pontos de partida para muitas outras pesquisas
neste assunto.
92
7.3 Principais Contribuições
As principais contribuições resultantes deste trabalho são, como esperado, a confirmação
do paradigma de orientação a objetos de desenvolvimento como apoio para a reengenharia de
interfaces para interfaces com RV, como é visto na seção 7.3.1. Outras contribuições, obtidas
durante a avaliação dos processos, são diretivas para a realização de reengenharia de interfaces
para interfaces com RV em um alto nível de abstração, tal qual realizada neste trabalho. As
diretivas foram obtidas através da constatação de dificuldades encontradas no estudo de caso,
busca de soluções e a análise dos resultados obtidos. Foram reunidas diretivas em relação ao
processo de reengenharia e relacionados à usabilidade das interfaces com RV geradas a partir
desse processo, como é mostrado na seção 7.3.2.
7.3.1 Conclusões esperadas segundo a proposta de trabalho
No esforço de criação de interfaces com RV baseadas em metáforas do mundo real, a
criação da interface com RV para o sistema legado não gerou maiores problemas, pois pareceu
óbvia a escolha de um “computador” ou “um funcionário utilizando um computador” para
representar todo o sistema computacional pré-existente. Entretanto, a interface de RV para o
sistema segmentado apresentou objetos de naturezas diversas, fugindo do contexto de um pátio
de oficina. A causa dessa disparidade entre os objetos é que a modularização do sistema
segmentado, apesar de pautada pelo paradigma OO, guarda muitas das características da
organização da interface funcional do sistema legado, forçando o uso de metáforas ligadas à
computação na composição da interface. Isso pode ser exemplificado com o uso de objetos
típicos de um escritório (“computador”, “impressora” e “arquivo”), o “carro quebrado” e o
contexto “Compras e Vendas” representada por um “cliente” e um “funcionário”.
Já o sistema OO, por ter sua interface também seguindo esse paradigma, facilitou a
representação do sistema na interface 3D com objetos quase que totalmente pertencentes ao
contexto de um pátio de oficina. Entretanto, alguns conceitos do sistema tornaram-se tão
abstratos que não permitiam representação clara com objetos 3D ligados ao mundo real. Como
exemplo podem ser citados “Tipos de veículos” e “Veículos de cliente”, dois objetos distintos do
domínio do sistema, porém de natureza muito semelhantes quando associados a um objeto 3D.
Para superar as dificuldades em representar conceitos abstratos com objetos 3D ligados ao mundo
93
real, foram utilizados objetos que representassem contextos ou “objetos-contextos”, como será
explicado a seguir.
Como “objetos-contextos” foram considerados algumas abstrações de mais alto nível que
pudessem agrupar vários objetos do sistema, em uma hierarquia de classificação, e ao mesmo
tempo ser passível de representação na interface com objetos 3D ligados ao mundo real.
O diagrama de classes da figura 7.1 apresenta três objetos-contextos, Peças, Cliente e
Fornecedor.
O bjet o-Con text o Peças
P eç a
Objeto-Contexto Cliente
Com ponente
Cliente
V eículo de Cliente
Objeto-Contexto Fornecedor
Fornecedor
Fabricante
FIGURA 7.1 – Objetos-contextos da interface com RV para o Sistema OO
Na figura 7.1, os objetos com rótulos iniciados por “Objeto-Contexto” correspondem aos
objetos 3D apresentados dentro do ambiente de RV que corresponde ao menu principal da
interface com RV. Os objetos ligados aos objetos-contextos pela relação de agregação
correspondem às representações dos objetos do domínio do sistema que compõem o objetocontexto, e podem ser representados de diversas formas na interface com RV formando uma
hierarquia de classificação de objetos.
Dessa forma “Veículos de Cliente” foi agrupado com o objeto do sistema “Cliente” e
acessados a partir de um mesmo objeto-contexto, “Objeto-Contexto Cliente”, representado por
um cliente na interface com RV. Assim, o usuário seleciona o objeto “Cliente” na interface,
representado por uma figura humanóide, e tem acesso a um menu onde pode escolher entre os
diversos aspectos daquele contexto, isto é, pode acessar os “Veículos de Cliente” ou o “Cliente”
94
propriamente dito. Da mesma forma foram agrupados os objetos de domínio do sistema “Peças” e
“Componentes”, no “Objeto-Contexto Peças”, e os objetos “Fornecedor” e “Fabricante”,
agrupados no “Objeto-Contexto Fornecedor” . Idealmente esses objetos-contextos deveriam ser
criados a partir de uma análise conjunta com o usuário do sistema para que correspondam da
melhor forma ao modelo mental que ele possui do sistema.
É interessante ressaltar que a idéia de objeto-contexto aplicada neste trabalho é
semelhante à idéia de “visões” utilizada na metodologia OVID (Roberts, 1998), como visto no
capítulo 3. Da mesma forma que as visões do OVID, os objetos-contextos representam os
aspectos dos objetos do sistema que devem ser apresentados aos usuários como objetos da
interface, de acordo com as tarefas que eles executam.
Outro ponto semelhante a ser ressaltado é que objetos-contextos agregam vários objetos
do domínio do sistema, assim como as “visões” que podem ser compostas por outras “visões”.
Quando implementada, essa relação de agregação permite que o usuário navegue de um objeto a
outro, pertencentes a um mesmo “contexto”, criando estruturas de interfaces semelhantes a uma
árvore de menus orientada a objetos.
Além disso, observou-se que, aplicando o paradigma de interação orientado a objetos
através da reengenharia de interfaces do sistema legado, pode-se obter uma organização da
interface de tal forma que o usuário se preocupe apenas em encontrar os dados com os quais quer
trabalhar, sem se preocupar com as ações, pois elas serão padrões e consistentes para cada tipo de
dado (Collins, 1995). Para tanto, é importante a reestruturação do código do sistema de forma a
isolar as tarefas para poderem ser agrupadas de acordo com o “objeto-dado” a que elas se
relacionam, utilizando métodos de separação do código da interface e aplicação (Moore, 1996),
segmentação ou mesmo de reengenharia de software orientada a objetos.
Com a reestruturação do código da aplicação realizada, o ganho na performance do
usuário será resultado de uma maior preocupação do engenheiro de software na organização e
representação da melhor forma possível, coerente com o mundo real, dos objetos da interface.
Em relação à organização da interface resultante, deve ser dada especial atenção às
hierarquias construídas pelo usuário em relação aos “objetos-dados” utilizados em suas tarefas.
Para um usuário, por exemplo, é conveniente classificar “Peças” como “Itens de ordem de
serviço” ao invés de “Partes do Veículo”. Quanto mais próximo do pensamento do usuário, mais
95
natural se tornará a interface (Nielsen, 1993), (Gabbard, 1997), (IBM. 2000a), (Rocha e
Baranauskas, 2000).
Outro modo de se reorganizar a interface é representar as ações como objetos da interface,
mesmo porque as ações dos diversos sistemas legados baseados em acesso a bancos de dados
terão como base as ações de consulta, cadastro, exclusão e alteração de dados, com poucas
variações, como visto no capítulo 6.
Quanto à representação das funcionalidades na interface, quanto mais fáceis de identificar,
maior o ganho para a performance do usuário em encontrar e realizar tarefas (Nielsen, 1993),
(Gabbard, 1997). Segundo o ponto de vista deste pesquisador, quanto mais fáceis de associar os
objetos 3D com o domínio do sistema, mais facilmente os usuários identificarão as
funcionalidades na interface obtendo, conseqüentemente, melhorias em sua performance na
utilização do sistema.
O problema em representar ações na interface é que os objetos podem fugir do contexto
do domínio do sistema. Porém, por se tratarem de ações mais genéricas suas representações
podem ser reutilizadas em outros sistemas, como foi percebido na reengenharia da interface do
sistema segmentado.
Portanto, devido aos resultados obtidos, pode-se inferir que a modularização do sistema,
facilitada pelo uso do paradigma OO de desenvolvimento e implementação, apresenta grandes
vantagens em relação aos outros paradigmas estudados quando o objetivo é realizar a
reengenharia de interfaces para interfaces com RV em um alto nível de abstração utilizando
metáforas do mundo real.
7.3.2 Diretivas para reengenharia de interfaces com RV
Nesta seção serão apresentadas as diretivas relacionadas ao processo de reengenharia de
interfaces para interfaces com RV, e relacionadas a aspectos de usabilidade durante esse
processo.
7.3.2.1 Diretivas para o processo de reengenharia de interfaces com RV
As diretivas encontradas em relação à reengenharia de interfaces são listadas e explicadas
a seguir:
96
1. Compor uma equipe multidisciplinar para realização da reengenharia de interfaces
para interfaces com RV. A formação de equipes multidisciplinares é recomendada para
desenvolvimento de sistemas interativos com interfaces convencionais (Norman, 1998),
(textuais e WIMP) e, como constatado neste trabalho, é de vital importância para
interfaces com RV devido a sua inerente complexidade de desenvolvimento, porém
enorme potencial de representação. A equipe de desenvolvimento das interfaces de RV
deve incluir integrantes da área de comunicação visual, de design gráfico (CAD 3D), de
lingüística entre outras disciplinas relacionadas, facilitando assim a criação de diversas
versões de objetos 3D durante o processo de criação da interface com RV, e avaliação
dessas versões junto ao usuário, em um processo de desenvolvimento centrado no usuário.
Como é recomendado de maneira geral em projetos centrados no usuário, é interessante o
uso de protótipos da interface para validação junto ao usuário com o intuito de evitar que
muitos problemas de usabilidade surjam após a implementação final da interface (IBM,
2002). Entretanto, enquanto interfaces 2D e textuais podem ser prototipadas utilizando
simplesmente papel e caneta, interfaces com RV envolvem tecnologias não triviais que na
maioria das vezes extrapolam as habilidades do engenheiro de software, tais como:
modelagem de objetos 3D, organização de objetos 3D no ambiente virtual para
representar metáforas do mundo real etc. Ao contrário de interfaces WIMP, que possuem
widgets e estilo de interações padronizados e de fácil implementação, os recursos de RV
para criação de interfaces ainda não estão definidos. Portanto, são necessários
especialistas para cobrir aspectos de hardware, animação gráfica, interação e apresentação
da interface com RV.
2. Para sistemas legados com problemas de usabilidade nas interfaces ligadas às
funcionalidades em sua interface original, procurar realizar um processo de
reengenharia no sistema, separando código de aplicação e interface, com o intuito de
reformular a interface. Como visto no capítulo 6, seção 6.7.4, as interfaces ligadas às
funcionalidades do sistema formam uma classe de interfaces que, por estar acoplada a
processos computacionais de transformação de dados, necessita de especial atenção para
compreensão e reformulação. Um processo de reengenharia de alto nível de abstração na
árvore de menus, como foi realizado, não será suficiente para resolver seus problemas de
usabilidade. O processo de reengenharia de interfaces como mostrado em (Merlo et al,
97
1993) e (Moore, 1996) comentado no capítulo 3, onde há a separação do código da
interface do código da aplicação com apoio automatizado, permite que o engenheiro de
software atinja os problemas mais graves de usabilidade do sistema.
3. Utilizar modelos de representação de alto nível de abstração para representar a
estrutura de organização das tarefas do usuário na interface legada. Os modelos para a
representação da árvore de menus da interface dos sistemas que irão passar por
reengenharia de interfaces para interfaces com RV devem ter poder de representação para
mapear a organização da interface original de forma independente da tecnologia utilizada
na implementação, permitindo facilidade de visualização. Isso é necessário porque
interfaces com RV se diferem radicalmente das interfaces WIMP e textuais, e todas as
informações sobre implementação dessas interfaces e modelos de interação, com exceção
das metáforas utilizadas, terão pouca utilidade durante a criação da nova interface com
RV. Além disso, é interessante recuperar e representar informações das tarefas realizadas
pelo usuário no sistema legado. Essas informações deverão ser analisadas, se possível
com a participação de usuários, e reformuladas para a geração da nova interface com RV.
No trabalho realizado, utilizou-se cenários textuais e diagramas de caixas para
representação das tarefas do usuário e estrutura das interfaces recuperadas a partir da
execução dos sistemas, como visto no capítulo 5.
4. Modularizar o máximo possível o código da aplicação. Com a aplicação
modularizada, é possível obter flexibilidade na implementação da interface e construção
de hierarquias de classificação correspondentes aos modelos mentais construídos pelo
usuário para identificar e realizar tarefas.
5. A reengenharia de interface para interface com RV pode ser mais eficiente se
realizada simultaneamente aos processos de reengenharia que resultarem na
modularização do sistema. Considerando que os processos de reengenharia – de interface
e sistema - sejam realizados paralelamente por duas equipes em constante comunicação, o
projeto da
modularização do sistema, realizado pela equipe de desenvolvimento da
aplicação, pode ser orientado à otimização da representação do sistema na interface. Da
mesma forma, a equipe de desenvolvimento da interface com RV pode constatar
problemas em apresentar conceitos abstratos utilizados pelos desenvolvedores do sistema,
98
ajudando a validar o modelo utilizado pela equipe de desenvolvimento da aplicação,
sugerindo alterações no modelo utilizado.
6. A busca de informações sobre usuários finais no processo de reengenharia de
interfaces para RV é vital para se obter ambientes virtuais que correspondam às suas
expectativas. Essa diretiva é de especial importância quando opta-se em utilizar metáforas
do mundo real para a interface com RV, pois é necessário conhecer as experiências do
usuário no seu cotidiano para que a interface resultante seja aceita pelos usuários. De
forma semelhante ao fato constatado no processo de engenharia avante de interfaces 2D
ou 3D, o resultado final da reengenharia de interfaces para interfaces com RV tal qual foi
realizado depende diretamente da análise de usuários finais conhecedores do sistema
legado ou da participação deles no processo. A aplicação de um processo de
desenvolvimento de software centrado no usuário para a fase de engenharia avante da
interface com RV, com participação ativa do usuário nas fases iniciais do projeto da
interface, permite que o desenvolvimento das interfaces com RV seja simplificado e fique
mais próximo do modelo mental que o usuário faz de suas tarefas. Um exemplo de PCU
aplicado ao desenvolvimento de interfaces com RV pode ser visto em (Shamus &
Harrison, 2001). Sem a participação do usuário, a equipe responsável pela reengenharia de
interface pode, no máximo, imaginar como seria a melhor representação 3D para a
interface legada. Apesar dessa constatação, em processos de reengenharia, a participação
direta do usuário pode ser impraticável devido à distância espaço/temporal da atual equipe
de desenvolvimento e os usuários do sistema original, como mostrado em (Gulliksen et al,
1999).
7.3.2.2 Diretivas de usabilidade para a reengenharia de interfaces com RV
Em relação à usabilidade, percebeu-se que os conjuntos de diretivas existentes para
ambientes de RV ainda falham em abordar certos aspectos da composição do ambientes 3D, tais
como:
-
completitude do contexto utilizado;
-
harmonia do ambiente;
-
fidelidade ao mundo real;
Algumas diretivas encontradas durante este trabalho podem simplificar o trabalho do
engenheiro de software nesse sentido:
99
1. Quando o acesso a uma funcionalidade for representado por idéias abstratas,
relacionadas a ações, por exemplo, evitar utilizar objetos que seja de difícil associação à
idéia que o usuário possui da funcionalidade. Pode parecer interessante utilizar um único
objeto para representar cada funcionalidade, evitando sobrecarga visual. Porém, nem
todas as funcionalidades são facilmente representáveis com um único objeto. É preferível
utilizar vários objetos criando um contexto que permita melhor reconhecimento da
funcionalidade por parte do usuário.
2. Quando vários objetos são utilizados para criar um contexto, todos os objetos devem
estar ligados à aplicação que representam. Se todos os objetos do mesmo contexto
estiverem devidamente conectados à mesma aplicação, o usuário não precisará procurar e
relembrar qual deles representa a ligação.
3.
Alguns objetos podem destoar do domínio representado pelo ambiente desde que
representem alguma metáfora familiar ao usuário. Apesar de ser desejável que a
interface se aproxime o máximo da experiência real do usuário para cumprir suas tarefas,
é bom lembrar que o projetista pode ter alguma liberdade para extrapolar os limites da
realidade. A interface é uma abstração da realidade que, seguindo o modelo mental do
usuário, pode criar atalhos impossíveis no mundo real. Na interface com RV criada para o
sistema segmentado, utilizou-se um objeto 3D “Lupa” posicionado à frente do objeto 3D
“Arquivo”, como visto na figura 7.2, representando a funcionalidade relativa a consultas
nos arquivos .
100
FIGURA 7.2 – Objeto “Lupa” representando a tarefa “Consultar Arquivo” na interface
com RV para o sistema segmentado
Aparentemente o objeto “Lupa” destoa do ambiente virtual, entretanto seu
posicionamento sugere a metáfora de busca em arquivos utilizada freqüentemente em
interfaces 2D WIMP, já familiar à maioria dos usuários.
4. Evitar objetos de significado ambíguo. Se necessário, criar uma hierarquia de
classificação para os objetos de natureza ambígua de forma que possam ser acessados na
interface a partir de outros objetos 3D que se destaquem pelos aspectos que os
distinguem. Por exemplo, ambos os objetos “Veículo de Cliente” e “Tipos de Veículos”
poderiam ser representados por veículos 3D, entretanto isso criaria confusão para o
usuário que dificilmente conseguiria distingui-los. Para distingui-los, pode-se representar
o objeto “Veículo de Cliente” classificado sob o contexto “Cliente”. Ao acessar o objeto
“Cliente”, o usuário escolhe com quais objetos deste contexto ele deseja interagir, entre
eles, o “Veículo de Cliente”.
5. Completar o ambiente com objetos que permita sua melhor adequação ao contexto
para tornar a interface mais agradável ao usuário, aumentando a sensação de imersão.
Não basta colocar no ambiente apenas objetos que dêem acesso às funcionalidades, pois
esses objetos devem estar ligados semanticamente entre si e ligados ao ambiente. Por
exemplo, o objeto “Impressora” que leva à funcionalidade de geração de impressos do
sistema segmentado utilizado nesta pesquisa, fica deslocado do ambiente se não for
101
colocado junto a um objeto “Computador” e um objeto “Funcionário”. Esses objetos
complementares dão significado e ligam o objeto impressora ao ambiente 3D, como
mostra a figura 7.3.
(a)
(b)
FIGURA 7.3 – Objetos complementares para a interface com RV para o sistema
segmentado
Na figura 7.3 (a) pode ser observada a interface com RV para o sistema segmentado em
sua primeira versão, apenas com objetos de acesso às funcionalidades. Como pode ser
visto na figura 7.3 (b), em uma versão posterior da mesma interface, com objetos
complementares os objetos de acesso às funcionalidades ficaram mais harmônicos em
relação ao ambiente e domínio.
6. Objetos utilizados para complementar o ambiente não devem possuir ligações com
funcionalidades do sistema. Os objetos complementares, como citado anteriormente,
servem apenas como parte do cenário do ambiente e devem ser usados apenas quando
necessários para evitar sobrecarga visual do ambiente e desorientação do usuário.
7.4 Trabalhos Futuros
Alguns trabalhos futuros puderam ser identificados como possíveis extensões para o
trabalho realizado e serão descritos a seguir:
1 – Quando utilizar interfaces com RV? Uma questão teórica recorrente durante todo o
trabalho é : “Quais aplicações devem ou não utilizar RV?”. A literatura atual não apresenta
respostas conclusivas para essa questão que se mostrou crucial para que seja possível responder
outra questão: “Quais sistemas legados devem obter maior ganho de qualidade com a
102
reengenharia para interfaces com RV?”. Dessa forma, um estudo para se obter respostas
completas e conclusivas a essas duas perguntas torna-se uma extensão desejável a este trabalho.
2 – Métodos e metodologias para reengenharia de interfaces com RV. Em relação a
métodos e metodologias para reengenharia de interfaces com RV, notou-se que poucas
abordagens existentes apresentam simplicidade de uso e aplicabilidade em processos de
reengenharia de interfaces. Existe uma necessidade de métodos para modelagem simples, rápida
e eficaz de estruturas de interfaces e diálogo humano-computador. Alguns métodos podem ser
observados em (Moore, 1996), porém todos eles apresentam alta complexidade na aplicação da
reengenharia de interfaces de alto nível de abstração. A pesquisa ou mesmo o desenvolvimento
de uma técnica de recuperação e representação abstrata de estruturas de interfaces e interação
humano-computador, para uso em processos de reengenharia de interfaces, especialmente para
interfaces com RV, pode cobrir algumas lacunas não abordadas neste trabalho.
3 – Usabilidade de interfaces mistas. Contribuições importantes em relação a questões de
usabilidade das interfaces mistas, isto é, interfaces legadas com uma camada de interface com
RV, geradas a partir do processo realizado neste trabalho, podem ser dadas a partir de testes de
usabilidade junto ao usuário. Testes dessa natureza precisam ser cuidadosamente planejados e
executados para que seus resultados levantem vantagens e desvantagens do uso desse processo de
reengenharia em sistemas legados visando melhorar a usabilidade e aumentar o tempo de vida
deles, tornando-se potencialmente uma das mais importantes extensões deste trabalho.
4 – Aprimorar o ambiente GaCIV. O uso do GaCIV, apesar de mostrar-se valioso como
suporte para a reengenharia de interfaces de sistemas legados, mostrou que esse ambiente ainda
pode ser aprimorado com possíveis novas funcionalidades tais como:
•
inclusão de hints ou rótulos textuais aos objetos da interface com RV para permitir um
melhor reconhecimento dos objetos por parte dos usuários;
•
possibilidade de interação entre objetos da interface, permitindo maior repertório de
interação humano-computador seguindo o paradigma OO (OOUI);
•
possibilidade de animação de objetos 3D, permitindo a representação de ações utilizando
poucos objetos;
•
facilidades para criação de hierarquias de classificação, isto é, árvores de menus em
interfaces com RV.
103
5 – Técnicas para criação de hierarquias de classificação em menus com RV. Quanto ao
uso de árvores de menus em interfaces com RV, outro estudo se faz necessário com o intuito de
verificar a melhor forma de implementa-la e as implicações na usabilidade da interface ao utilizalas.
104
Referências Bibliográficas
(Assis, 1999) ASSIS, A.F.S.R. Um Ambiente Computacional para Desenvolvimento de
Interfaces Utilizando Realidade Virtual. São Carlos: Departamento de Computação,
Fevereiro/2000. Monografia apresentada ao PPG-CC da UFSCar para exame de qualificação.
(Assis & Silva, 2000a) ASSIS, A.S.F.R., SILVA, J.C.A. Development of Interactive Systems
with Virtual Reality Based on User Centered Design. In: SCI 2000 - WORLD
MULTICONFERENCE ON SYSTEMICS, CYBERNETICS AND INFORMATICS, 4, 2000,
Estados Unidos. Proceedings... , julho/2000.
(Assis & Silva, 2000b) ASSIS, A.S.F.R., SILVA, J.C.A. Meeting the Challenge of Systems
Development with Virtual Interfaces. In: 2000 INTERNATIONAL CONFERENCE ON
INFORMATION SOCIETY IN THE 21ST CENTURY: EMERGING TECHNOLOGIES AND
NEW CHALLENGES (IS2000). Proceedings. Japão, Aizu-Wakamatsu, Fukushima. Novembro
5-8, 2000. p. 562-566.
(Bisbal et al, 1999) BISBAL, J., LAWLESS, D., WU, B., GRIMSON, J., Legacy Information
Systems: Issues and Directions. IEEE Software, vol.16, No. 5, pp. 103-111, Setembro/Outubro
1999.
(Bowman et al, 2001a) BOWMAN, D., KRUIJFF, E., LAVIOLA, J., POUPYREV, I. An
Introduction to 3D User Interface Design. Presence: Teleoperators and Virtual Environments,
vol. 10, no. 1, pp. 96-108, 2001.
(Bowman et al, 2001b) BOWMAN, D., JOHNSON, D., HODGES, L. Tested Evaluation of
Virtual
Environment
Interaction
Techniques.
Environments, vol. 10, no. 1, pp. 75-95, 2001.
Presence:
Teleoperators
and
Virtual
105
(Braga, 1990) BRAGA, R. T. V. – Documentação Técnica sobre o Sistema Legado,
Documentação de Trabalho,1990.
(Braga & Masiero, 1998)
BRAGA, R.T.V., MASIERO, P.C. Detalhamento do Passo de
Abstração do Modelo de Análise do Método Fusion/RE. Relatório Técnico, ICMSC-USP, São
Carlos, 1998.
(Card & Newell, 1983) CARD, S.M.T., NEWELL, A. The Psychology of Human-Computer
Interaction, Hillsdale, NJ, EUA: Lawrence Erlbaum Associates Publishers, 1983.
(Chikofsky & Cross, 1990) CHIKOFSKY, E.J., CROSS II, J.H. Reverse Engineering and Design
Recovery: A Taxonomy. IEEE Software, v.7, n.1, pp. 13-17, 1990.
(Cognetics, 1999) COGNETICS. LUCID, URL: http://www.cognetics.com/ lucid/index.html.
Consultado em julho/2001.
(Coleman et al, 1994) COLEMAN, D. et al. Object-Oriented Development: The Fusion
Method. Prentice Hall, 1994.
(Collins, 1995) COLLINS, D. Designing Object-Oriented User Interfaces. Estados Unidos:
The Benjamin/Cummings Publishing Company, Inc, 1995.
(Constantine, 1995) CONSTANTINE, L. Essential Modeling - Use Cases for User Interfaces.
ACM Interactions, vol 2, p. 34-46, abril 1995.
(Costa, 1997) COSTA, R.M. Um método de Engenharia Reversa para Auxiliar a
Manutenção de Software. Dissertação (Mestrado em Computação) – ICMSC, Universidade de
São Paulo. São Carlos, 1997.
106
(Dayton et al, 1998) DAYTON, T. et al. Bridging User Needs to Object Oriented GUI Prototype
via Task Object Design, User Interface Design – Bridging the Gap from User Requirements
to Design, Estados Unidos: CRC Press LLC, 1998.
(Feltrim et al, 1999) FELTRIM, V.D., FORTES, R.P.M., SILVA, W.F. Aspectos de Validação
do Método de Engenharia Reversa Fusion-RE/I aplicado a um Sistema Hipermídia. In:
SIMPÓSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE, 1999 Anais... FlorianópolisSC, Outubro/1999.
(Feltrim, 1998) FELTRIM, V.D. et al. Uma modelagem do domínio de Engenharia Reversa
de Software utilizando o método OOHDM. Notas do Instituto de Ciências Matemáticas de São
Carlos, Universidade de São Paulo – São Carlos, 1998.
(Gabbard et al, 2000) GABBARD, J.L. et al. Usability Design and Evaluation Guidelines for
Augmented
Reality
(AR)
Systems
URL:
http://www.sv.vt.edu/classes/ESM4714/Student_Proj/class00/gabbard/index.html. Consultado em
março/2002.
(Gabbard, 1997) GABBARD J. L., A Taxonomy of Usability Characteristics for Virtual
Environments, Dissertação
(Mestrado em Computação) - Departmento de Ciências da
Computação, Virginia Tech, 1997.
(Gabbard & Hix, 2001) GABBARD J. L., HIX D., Usability Design and Evaluation Guidelines
for
Augmented
Reality
(AR)
Systems,
http://www.sv.vt.edu/classes/
ESM4714/Student_Proj/class00/gabbard/index.html. Consultado em dezembro/2001.
(Gray & Boehm-Davis, 2000) GRAY, W. D. & BOEHM-DAVIS, D. A. GOMS
Tutorial/Workshop,
2000
IEA/HFES
CONFERENCE,
URL:
http://hfac.gmu.edu/~gray/pubs/papers/goms/goms-wdg_dab.htm. Consultado em fevereiro/2001.
107
(Greenhalgh et al, 1997) GREENHALGH, C.M., BULLOCK, A.N., TROMP, J. G., BENFORD,
S.D. Evaluating the Network and Usability Characteristics of Virtual Reality Conferencing, The
British Telecom Technology Journal (BTTJ), Special Issue on Shared Spaces, 15 (4),
October 1997. http://citeseer.nj.nec.com/greenhalgh97evaluating.html
(Gulliksen et al, 1998) GULLIKSEN, J. et al.
User Centered Design - Problems and
Possibilities: A Summary of the 1998 PDC and CSCW Workshop. SIGCHI Bulletin, v.31, n.2,
Abril/1998.
(Hannaford & Venema, 1995) HANNAFORD, B., VENEMA, S. Kinesthetic displays for remote
and virtual environments. In: _____. Virtual Environments and Advanced Interface Design.
Oxford University Press, 1995. pages 415-436.
(Harel, 1987) HAREL, D. Statecharts: A Visual Formalism to Complex Systems, Science of
Computer Programming, v.8, p. 231-274. 1987.
(Hincley et al, 1994) HINCKLEY, K., PAUSCH, R., GOBLE, J.C., KASSELL, N.F. (1994a).
Design hints for spatial input. In: ACM SYMPOSIUM ON USER INTERFACE SOFTWARE &
TECHNOLOGY, nro, 1994, Cidade. Proceedings… pages 213-222.
(Horrocks, 1999) HORROCKS, Ian. Constructing the User Interface with Statecharts,
Inglaterra: Addison Wesley Longman Limited, 1999.
(IBM. 2000a) IBM.
Design Principles for Tomorrow.
URL: http://www.ibm.com/ibm/
hci/designer/uiarch/prinpl3_noframes.html. Consultado em dezembro/2000.
(IBM, 2000b) IBM. OOUI Introduction. URL: http://www.ibm.com/ibm/hci/guidelines/
design/ooui_introduction.html. Consultado em dezembro/2000.
(IBM,
2001a)
IBM.
Ease-to-use,
URL:
ext.nsf/publish/558. Consultado em fevereiro/2001.
http://www-3.ibm.com/ibm/easy/eou_
108
(IBM,
2001b)
IBM.
Real
Things
design,
URL:
http://www-3.ibm.com/ibm/
easy/eou_ext.nsf/Publish/581. Consultado em fevereiro/2001.
(IBM,
2002)
IBM.
User-Centered
Design,
URL:
http://www-
3.ibm.com/ibm/easy/eou_ext.nsf/Publish /570PrintView. Consultado em janeiro/2002.
(Interbase, 2002) Interbase , URL: http://www.borland.com/interbase/index.html. Consultado
em março/2002.
(Java, 2002) Java, URL:http://java.sun.com/ Consultado em março/2002.
(JBuilder, 2002) JBuilder, URL:http://www.borland.com/jbuilder/index.html Consultado em
março/2002.
(Kaur, 1998) KAUR K. Designing virtual environments for usability. , Londres, Junho/1998.
Dissertação (PhD em Ciência da Computação) - Centre for HCI Design, City University.
(Kuhn & Muller, 1993) KUHN, S., MULLER, M.J. Participatory Design. Communications of
the ACM, v.36, n.4, p.25-28, junho/1993.
(Lucena & Liesenberg, 1999) LUCENA, F.N., LIESENBERG, H.K.E. Interfaces HomemComputador:
Uma
Primeira
Introdução.
Disponível
em
1997.
URL:
http://www.dcc.unicamp.br/proj-xchart/start/welcome.html. Consultado em abril/1999.
(Merlo et al, 1993) MERLO E., GIRARD J. F., KONTOGIANNIS K., PANANGADEN P., De
MORI R., Reverse Engineering of User Interfaces, Proceedings... First Working Conference on
Reverse Engineering, Baltimore, 1993 http://citeseer.nj.nec.com/merlo93reverse.html
(Merlo, 1995) MERLO, E. et al., Reengineering User Interfaces. IEEE Software, vol.12, no. 1,
pp 64-73, janeiro 1995.
109
(Myers, 1996) MYERS, B.A., A Brief History of Human Computer Interaction Technology,
Relatórios Técnicos CMU-CS-96-163 e CMU-HCII-96-103, Human Computer Interaction
Institute Technical Report, Estados Unidos: dezembro/1996.
(Moore, 1996) MOORE, M. A Survey of Representations for Recovering User Interface
Specifications in Reengineering, Relatório de Pesquisa GIT-CC-96-34, College of Computing,
Georgia Institute of Technology, 1996.
(Moore, 2002) MOORE, M., MORPH - User Interface Reengineering. Dissertação disponível
on-line, PhD em Ciência da Computação, Georgia Institute of Technology URL:
http://www.cis.gsu.edu/~mmoore/MORPH/dissertation/Dissertation.html.
Consultado
em
março/2002.
(Moran, 1981) MORAN, T. The Command Language Grammar: A Representation for the User
Interface of Interactive Computer Systems, International Journal of Man-Machine Studies,
vol. 15, nro. 1, pg. 3-50, 1981.
(Nielsen & Molich, 1990) NIELSEN, J., MOLICH, R. Heuristic evaluation of user interfaces. In:
ACM CONFERENCE HUMAN FACTORS IN COMPUTING SYSTEMS (CHI'90), 1990,
Seattle, WA, EUA Proceedings… 1-5 abril 1990, pg. 249-256.
(Nielsen, 1993) NIELSEN, J. Usability Engineering. Estados Unidos: AP Professional, 1993.
(Nielsen, 1998) NIELSEN, J. 2D is Better than 3D. Disponível em novembro/1998, URL:
http://www.useit.com/alertbox/981115.html, Consultado em julho 2002.
(Ning et al, 1994) NING, J.Q. et al. Automated Support for Legacy Code Understanding,
Communications of the ACM, v.37, n5, pp 50-57, maio/1994.
110
(Norman, 1998) NORMAN, D.A. Want Human-Centered Development? Reorganize the
Company. In:_____The Invisible Computer. MIT Press, 1998.
(Penteado, 1996) PENTEADO, R.A.D. Um Método para Engenharia Reversa Orientada a
Objetos. Dissertação (Doutorado em Física Computacional) – Instituto de Física de São Carlos,
Universidade de São Paulo. São Carlos, 237 p. 1996.
(Penteado et al, 1996) Penteado, R.; Germano, F.; Masiero, P. C. - An Overall Process Based on
Fusion to Reverse Engineering Legacy Code. In: Working Conference Reverse Engineering,
3, Monterey-California. Anais. IEEE, p. 179-188. 1996.
(Penteado et al, 1998) PENTEADO, R. et al Improving the Quality of Legacy Code by Reverse
Engineering. In: International Conference on Information Systems Analysis and Synthesis,
ISAS’98, 4, Orlando-Florida. p.364-370. 1998.
(Pressman, 1997) PRESSMAN, R. Software Engineering: A Pratitioner’s Approach. Estados
Unidos: McGraw-Hill, 1997.
(Reich et al, 1995)
REICH, Y., KONDA, S. L., LEVY, S. N., MONARCH, I. A., e
Subrahmanian, E. "Varieties and issues of participation and design." Design Studies,
http://citeseer.nj.nec.com/reich96varieties.html, Consultado em abril/2001.
(Reisner, 1981) REISNER, P. Formal Grammar and Human Factors Design of an Interactive
Graphics System, IEEE Transaction on Software Engineering, vol. SE-7, nro. 2, pg. 229-240,
1981.
(Roberts, 1998) ROBERTS, D. et al. Designing for the User with OVID: Bridging User
Interface Design and Software Engineering, Macmillan Technical Publishing, 1998.
111
(Rocha & Baranauskas, 2000) ROCHA, H.V., BARANAUSKAS, M.C.C. Design e Avaliação
de Interfaces Humano-Computador, São Paulo, Brasil: IME-USP, 2000.
(Sakata, 1998) SAKATA, T.C. Módulo RSOO – Reengenharia de Software Orientada a
Objetos, Relatório Técnico, Universidade Federal de São Carlos, Departamento de Computação.
(Shamus & Harrison, 2001) SHAMUS, P.S., HARRISON, M.D. User centred design and
implementation of virtual environments, International Journal of Human-Computer Studies,
Academic Press, 55(2), pp 109-114, August 2001
(Shneiderman, 1998)
SHNEIDERMAN, B.
Designing the User Interface: Strategies for
Effective Human-Computer Interaction. Estados Unidos: Addison-Wesley, 1998.
(Silva, 1998) SILVA, J.C.A. A Realidade Virtual e a Qualidade de Interfaces. In: WORKSHOP
DE QUALIDADE DE SOFTWARE – XII SIMPÓSIO BRASILEIRO DE ENGENHARIA DE
SOFTWARE, Maringá, 1998. Anais… Maringá-PR, 1998, p. 11-17.
(Silva, 1999) SILVA, J.C.A. Development of Virtual Interfaces Using Configurable Templates.
In: ICCIMA99 – 3RD INTERNATIONAL CONFERENCE ON COMPUTATIONAL
INTELLIGENCE AND MULTIMEDIA APPLICATIONS, NEW DELHI, INDIA, 23-26
SETEMBRO 1999. Proceedings… India, 1999, p. 354-358.
(Silva & Penteado, 2000) SILVA, J.C.A, PENTEADO, R.A.D. A Study of the Integration of
Reverse Engineering and Interfaces with Virtual Reality. In: SCI2000 and ISAS2000 – 4th
WORLD MULTICONFERENCE ON SYSTEMICS, CYBERNETICS AND INFORMATICS
AND THE 6TH INTERNATIONAL CONFERENCE ON INFORMATION SYSTEMS
ANALYSIS AND SYNTHESIS, Orlando, USA, July 23-26, 2000 Proceedings. USA, 2000, p.
112-117.
(Sneed, 1995) SNEED, H.M. Planning the Reengineering of the Legacy Systems In: IEEE
Software, nro volume, nro fasciculo, pp 24-34, janeiro 1995.
112
(Sneed, 2001) SNEED, H.M. Wrapping Legacy COBOL Programs behind an XML-Interface. In:
WORKING CONFERENCE ON REVERSE ENGINEERING, 2001. Proceedings... WCRE
2001, 2-5 outubro 2001, Suttgart, Alemanha. IEEE Computer Society.
(Soares et al, 2001a) SOARES, C.L. et al Metodologias para Desenvolvimento de Interfaces –
Análise Comparativa, Relatório Técnico, Universidade Federal de São Carlos, Departamento de
Computação.
(Stroulia et al, 1999) STROULIA, E., EL-RAMLY, M., KONG, L., SORENSON, P.,
MATICHUCK, B. Reverse engineering legacy interfaces: An interaction-driven approach. In 6TH
WORKING CONFERENCE ON REVERSE ENGINEERING (WCRE'99) Proceedings…
Local:
IEEE
Computer
Society,
1999,
pp
292--301.
http://citeseer.nj.nec.com/stroulia99reverse.html
(Tucker & Stirewalt, 1999) TUCKER K., STIREWALT K.,Model Based User-Interface
Reengineering,
Proceedings...
Working
Conference
on
Reverse
Engineering,1999,
http://citeseer.nj.nec.com/tucker99model.html
(Van Dam, 1997) VAN DAM, A. Post-WIMP User Interfaces. Communications of the ACM,
v.40, n.2, p.63-67, fevereiro/1997.
(Vanniamparampil et al, 1995) Vanniamparampil A. et al User interface reengineering: A
diagnostic approach, Relatório Técnico, University of Maryland, Department of Computer
Science, fevereiro/1995
(Wasserman et al, 1986) WASSERMAN, A.I. et al. Developing Interactive Information Systems
with the User Software Engineering Methodology.
Engineering, v.12, n.2, p.326-345, fevereiro/1986
IEEE Transactions on Software
113
(Weiss & Jessel, 1998) WEISS, P., JESSEL, A.S. Virtual Reality Applications to Work, URL:
http://www.infocommons.utoronto.ca/atrc/rd/library/
papers/weiss.html.
Consultado
em
agosto/2001.
(Willans & Harrison, 2001) WILLANS, J.S., HARRISON, M.D. Prototyping pre-implementation
designs of virtual environment behaviour. In: 8TH IFIP WORKING CONFERENCE ON
ENGINEERING FOR HUMAN-COMPUTER INTERACTION (ECHI'01), Toronto, Canada,
2001.
(Wood, 1998) WOOD, E. L. User Interface Design – Bridging the Gap from User Requirements
to Design, Estados Unidos: CRC Press LLC, 1998.
114
Apêndice A - Modelo de Classes para a Reengenharia.
Modelo de classes do sistema-exemplo gerado a partir do modelo Fusion recuperado no
processo de segmentação.
115
Figura A.1 – Diagrama de Classes do sistema exemplo
116
Apêndice B - Use Cases
Use Cases gerados para a re-implementação do sistema-exemplo em Java®.
Em todos os use cases mostrados a seguir, as possíveis mensagens de erros foram
substituídos por um fluxo com o nome “mensagem <número>”, onde o número varia de acordo
com o use case. Essa simplificação para facilitar visualização.
nom e do cliente
m ensagem 01
código, data
Funcionário
dados do cliente
cli ente c adastrado
Incluir C liente
(f rom U s e C as e View)
(f rom U s e C as e View)
< <us es >>
Verificar C liente
(f rom U s e C as e View)
Figura B.1 - “Incluir Cliente”
código do com ponente
m ensagem 02
código do com ponente
dados do com ponente
Func ioná rio
In cluir C om ponente
confirm ação
(f rom Us e C as e View)
(f rom U s e C as e View)
com ponen te cadastrad o
<<us es >>
Ve ri ficar C om p onen te
(f rom Us e C as e View)
Figura B.2 – “Incluir Componente”
117
nom e do em pregado
dados de cadastro do em pregado
m ensagem 03
In cluir Em preg ado
Fun cionário
em pregado cadastrado
(f rom U s e C as e View)
(f rom U s e C as e View)
<<u s es >>
Verificar Em preg ado
(f rom U s e C as e View)
Figura B.3 – “Incluir Empregado”
ab reviaçã o do fornec edor
dados de cadastro do fornecedor
m ensagem 04
In cluir Forn ecedo r
Fu ncion ário
(f rom U s e C a se View )
fornecedor cadastrado
(f rom U s e C as e View)
<<us es >>
Ve rifica r Fo rn ecedor
(f rom U s e C as e View)
Figura B.4 – “Incluir Fornecedor”
118
código da m ão-de-ob ra
m ensagem 05
dados de cadastro da m ão-de-ob ra
Funcionário
Incluir Mão-de-Obra
m ão-de-ob ra cadastrada
(f rom U s e C as e View)
(f rom U s e C ase V ie w)
<<us es >>
Verificar Mão-de-Obra
(f rom U s e C ase V ie w)
Figura B.5 – “Incluir Mão-de-Obra”
código do tipo de veículo
dados de cadastro do tipo de veiculo
m ensagem 06
Funcionário
(f rom U s e C as e View)
ti po de veículo c adastrado
Incluir Tipo de Veículo
(f rom U s e C as e View)
<<us es >>
Verificar Tipo de Veículo
(f rom U s e C as e View)
Figura B.6 – “Incluir Tipo de Veículo”
119
C ódigo da Pe ça
m ensagem 07
D ado s d e ca dastro da peça
In cluir Peça
Fu ncion ário
(f rom U s e C a se View )
(f rom U s e C as e View)
códigos de peças equ ivalentes
Ve r ific ar Peça
(f rom U s e C a se View )
Figura B.7 – “Incluir Peça”
ab reviatura de fab ricante
dados de cadastro do fab ricante
m ensagem 08
Funcionário
( fr om Us e C a se View )
fab ricante cadastrado
Incluir Fabricante
(f rom U s e C as e View)
<<us es >>
Verificar Fabr icante
(f rom U s e C as e View)
Figura B.8 – “Incluir Fabricante”
120
dados atualiz ados do cliente
m ensagem 09
Func ion ário
(f rom U s e C as e View)
Alterar C liente
cl iente atualiz ado
(f rom U s e C as e View)
<<us es >>
Selecionar C liente
(f rom U s e C as e View)
Figura B.9 – “Alterar Cliente”
121
dados atualiz ados do em pregado
m ensagem 10
Funcionário
Alte ra r Em pregado
e m pr egado atualiz ad o
(f r om Us e C a se View )
(f rom U s e C as e View)
<<us es >>
Selecionar Em pregado
(f r om Us e C a se View )
Figura B.10 – “Alterar Empregado”
dados atualiz ados do fornecedor
m ensagem 11
fornecedor atualiz ado
Funci onár io
( from U s e C ase V ie w)
Alterar Fornecedor
( from U s e C a se View )
<<us es >>
Selecionar Fornece dor
( from U s e C a se View )
Figura B.11 – “Alterar Fornecedor”
122
dados atualiz ados do com ponente
m ensagem 12
Funcionário
Alte rar C om p onente
com ponente atualiz ado
(f rom U s e C as e View)
(f rom U s e C as e View)
<<us es >>
Selec ion a r C ompo nente
(f rom U s e C as e View)
Figura B.12 – “Alterar Componente”
da dos atuali z ados da mão -de- ob ra
m ensagem 13
m ão-de-ob ra atualiz ada
Funcio nário
(f rom U s e C as e View)
Alterar Mão-de -Ob ra
(f ro m U s e C as e V ie w)
<<us es >>
Selecion ar Mão-de-Obra
(f ro m U s e C as e V ie w)
Figura B.13 – “Alterar Mão-de-Obra”
123
dados atualiz ados do tipo de veículo
m ensagem 14
Alterar Tipo de Veículo
Funcionário
(f rom U s e C as e View)
tipo de veículo atualiz ado
(f rom U s e C as e View)
<<us es >>
Selecionar Tipo de Veículo
(f rom U s e C as e View)
Figura B.14 – “Alterar Tipo de Veículo”
tipo de alteração
d ados atualiz ados da peça
m ensagem 15
Fun cionário
Alter ar Peça
peça atualiz ada
(f rom U s e C as e View)
(f rom U s e C as e View)
<<u s es >>
Selecio nar Peça
(f rom U s e C as e View)
Figura B.15 – “Alterar Peça”
124
dados atualiz ados do fab r ican te
me nsagem 16
Funcionário
fab ricante atualiz ado
Alterar Fabricante
(f rom U s e C as e View)
(f rom U s e C as e View)
<<us es >>
Selecionar Fabricante
(f rom U s e C as e View)
Figura B.16 – “Alterar Fabricante”
confirm a exclusão
m ensagem 17
clien te exc luído
Funcioná rio
(f rom U s e C as e View)
Excluir C liente
(f rom U s e C as e View)
< <uses >>
Seleciona r C liente
(f rom U s e C as e View)
Figura B.17 – “Excluir Cliente”
125
confirm a exclusão
m ensagem 18
em pregado excluído
Funcionário
Excluir Em pregado
( from Us e C a se Vie w)
(f rom U s e C as e View)
<<uses >>
Selecionar Em pr egado
( from Us e C a se Vie w)
Figura B.18 – “Excluir Empregado”
confirm a exclusão
m ensagem 19
fornecedor excluído
Funcionário
(f rom U s e C as e View)
Excluir Forn ecedor
(f rom U s e C as e View)
<<uses >>
Selecionar Fornecedor
(f rom U s e C as e View)
Figura B.19 – “Excluir Fornecedor”
126
confirm a exclusão
m ensagem 20
com ponente excluído
Excluir C om ponente
Funci onár io
(f rom U s e C as e View)
( fr om Us e C ase V ie w)
<<us es >>
Selecionar C om ponente
(f rom U s e C as e View)
Figura B.20 – “Excluir Componente”
con firm a e xclusão
me nsagem 21
m ão-de-ob ra excluída
Fu ncion ário
(f rom U s e C as e View)
Exclu ir Mã o-de -Ob ra
(f rom U s e C as e View)
<<us es >>
Seleciona r Mão -de-Obra
(f rom U s e C as e View)
Figura B.21 – “Excluir Mão-de-Obra”
127
confirm a exclusão
m ensagem 22
tipo de veículo excluído
Fun ci on ário
Exclu ir Tip o d e Ve ícu lo
(f rom U s e C as e View)
( from U s e C ase Vie w)
<<u s e s >>
Se le cio n a r Tipo d e Veículo
(f rom U s e C as e View)
Figura B.22 – “Excluir Tipo de Veículo”
co nfirm a exclusão
m ensa gem 2 3
peça excluída
Fun cionário
(f rom U s e C as e View)
Exclu ir Peça
(f rom U s e C as e View)
<<u s es >>
Sel eci onar Peça
(f rom U s e C as e View)
Figura B.23 – “Excluir Peça”
128
confirm a exclusão
m ensagem 24
fab ricante excluído
Excluir Fa bricante
Fun cioná rio
(f rom U s e C as e View)
(f rom U s e C as e View)
<<u ses > >
Sele cionar Fabrica nte
(f rom U s e C as e View)
Figura B.24 – “Excluir Fabricante”
dados atualiz ados do c liente
S elec ionar Cliente
(from U se Case View )
dados atualiz ados do veículo do cliente
A lterar Cliente
(from U s e Case View )
< < us es > >
< < ex tend> >
confirm a cliente
confirm a veíc ulo do cliente
A brir Ordem de S erviç o
F unc ionário
(from Us e Case V iew )
d ados do serviço a exec utar
mens agem 25
(from U se Case View )
< < us es > >
< <ex tend> >
oredem de serviço ab erta
Se lec ion ar V eíc ulo de
Cliente
(from U se Case View )
Figura B.25 – “Abrir Ordem de Serviço”
A lterar V eíc ulo de Cliente
(from U se Case View )
129
S el ec ionar Ordem de
S erviç o
dados de peç as utiliz adas
Dar baix a da P eç a
(from Us e C ase View )
(from U se C ase View )
dados de peç as c om pradas fora
<< us es > >
< < us es > >
dados d a mão-de-ob ra utiliz ada
dados de c ontas a rec eb er
m ens a gem 26
Func ionári o
Fec har Ordem de S erviç o
b aixa no es toque de peç as
< < ex tend> >
(from U se C ase View )
(from U se C ase View )
Lanç ar P eç a Com prada
Fora
lançam ento de peç as c om pradas fora
< < ex tend> >
< < us es > >
(from U se C ase View )
ordem de s erviç o fec hada
Cadas trar Contas a Rec eber
Calc ular M ão-de-Obra
Utiliz ada
(from U se C ase View )
(from Us e C ase View )
Figura B.26 – “Fechar Ordem de Serviço”
confirm a exclusão
m ensagem 27
or dem de ser viç o ex clu ída
Fun cionário
(f rom U s e C as e View)
Excluir Or dem de Serviço
(f rom U s e C as e View)
<<u s es >>
Selecio nar Ordem de Serviço
(f rom U s e C as e View)
Figura B.27 – “Excluir Ordem de Serviço”
130
da dos atua liz ados do veículo d o c liente
m ensagem 28
v eíc ulo do cl iente atualiz ado
Altera r Veículo de C lien te
Fu ncion ário
(f rom U s e C as e View)
(f rom U s e C a se View )
<<us es >>
Sele cion ar Ve íc ulo d e C lie nte
(f rom U s e C as e View)
Figura B.28 – “Alterar Veículo de Cliente”
dados da peça utiliz ada
m ensagem 29
b aixa da peça
D ar b aixa da Peça
Func ioná rio
(f rom U s e C as e View )
(f rom U s e C as e View)
Figura B.29 – “Dar Baixa de Peça”
d a d o s d a co mp ra
me n sa g e m 3 0
c o mpr a d e p eç a l an çad a
L a n ça r P e ça Co m p ra d a Fo ra
Fun ci o n ár i o
(from U se C ase View )
(from U se C ase View )
Figura B.30 – “Lançar Peça Comprada Fora”
131
dados da m ão-de-ob ra utiliz ada
m ensagem 31
m ão-de-ob ra calculada
C alcula r Mã o-de -Obra U tilizada
Fun cioná rio
( from U s e C a se View)
(f rom U s e C as e View)
Figura B.31 – “Calcular Mão-de-Obra Utilizada”
da dos das contas a rece b er
m ensagem 32
contas cadastradas
C ad as tra r C ontas a R e ce ber
Funci onár io
( f rom Us e C as e Vie w)
(f rom U s e C as e View)
Figura B.32 – “Cadastrar Contas a Receber”
Apêndice C – Diagramas de Sequência
Diagramas de Seqüência gerados para a implementação do sistema OO.
Nos diagramas de seqüência apresentados a seguir, as classes identificadas com nomes
indiciados pela palavra “Frame” são classes específicas de implementação da interface em
Java®.
132
:
Fram eIncluiC lientes
: Funcionário
:
Fram eVerific arC l iente
1: Pede nom e do cl iente
2: Inform a nom e do c liente
3: V erific arCliente(nom e)
4: Inform a código, data
5: Inform a dados de cadas tro do cliente
6: Pede confirm ação
7: Confirm aç ão
8 : Cad astraCli ent e(da dos de cadas tro do c lient e)
Figura C.1 – “Incluir Clientes”
: Clie nte
133
: Funci oná r io
:
F ram e In clu iC o m pon en te s
:
Fram e Ve r ifi carC om p on ente
: Com ponente
1: Ped e có digo d o co m pon ente
2: Informa c ódigo do c ompon ente
3: Ve rificarC om p on ente(có digo d o co m pon en te )
4: Inform a có digo d o com p on ente
5: Inform a da dos d e ca das tro d o com pon ente
6: Ped e co nfirm a ção
7: Confirmaç ão
8: Cadas tra Co mpone nte( dados de c adas tro do c om ponent e)
Figura C.2 – “Incluir Componente”
134
: Fram eVerificarEm pregado
: Funcionário
:
Fr am eInc lui Em pregad os
: E m pregado
1: Pe de n ome do emp regad o
2: Inform a nom e do em pregado
3: V erific arE m prega do(nom e do em pregado)
4: GerarCodigo()
5: GerarS enha()
6: Mos tra nom e do Em pregado e Senha
7: E ntra c om dados de c adas tro do em pregado
8: Pede confirm ação
9: Confirm a
10: C adas trarEm pregado(D ados de cadas tro do em pregado)
Figura C.3 – “Incluir Empregado”
135
: Funcionário
:
Fram eVerificarFabricante
:
Fram eIncluiFabricantes
: Fabric ante
1: Pede abreviatura de fabricante
2: Infor m a ab reviatura do fabri can e
3: V erific arFabric ante(abreviatura do fabric ante)
4: Ap res enta abr eviatu ra
5: Inform a dad os de c adas tro do fabric ante
6: Pede confi rm ação
7: Confirma
8: C adas trarFabricante(dados de cadas tro do fabricante)
Figura C.4 – “Incluir Fabricante”
136
: Fun cion ário
:
Fram eIncluiTipoD eVeiculo
: Fram eV erific arTi poD eV eiculo
:
Tip oD eVe iculo
1: Pede código do tipo de veículo
2: In forma c ódigo do tip o de veíc ulo
3: VerificarTipoD eVeiculo(código do tipo de veículo)
4: Pede dados de cadas tro do tipo de veículo
5: Inform a dados de cadas tro do tipo de veículo
6: Pede confirm acao
7: Confirm a
8 : C adas trarTip oD eVeic ulo (dados de cada s tro d o tipo de veículo)
Figura C.5 – “Incluir Tipo de Veículo”
137
: Funcionário
:
Fram eVerificarFornecedor
:
F ram eInclu iFor nece dores
: Fornec edor
1: Pede abreviatura do fornecedor
2: Fornece abreviatura do fornecedor
3: V erific arFornecedor(abreviatura do fornecedor)
4: Pede dados de cadas tro do fornecedor
5: Inform a dados de cadas tro do fornec edor
6: Pede confirm ação
7: Confirm a
8: C ada s tr arFo rnec edor(dados de cads tr o do forn ecedor)
Figura C.6 – “Incluir Fornecedor”
138
: Fu ncion ário
: Fram eInc luiM a oD eOb ra
:
Mao deOb ra D aOrdServico
1: Pede códig o d a Mã o-de-Obra
2: Iinfo rm a cód igo da Mão-de -Obra
3: Pede dad os d e cad as tro da Mão-d e-Obra
4: In form a dad os d e cad as tro da Mão-d e-Obra
5: Pede confirm ação
6: Confirm a
7: C ad as tra rMaoD e Obra(dad os de cad as tro da Mão -d e-Obra)
Figura C.7 – “Incluir Mão-de-Obra”
139
:
Fram eIncluiPecas
: Fun c ioná rio
: Pe c a
1: Pede dados de ca das tro da peça
2: Inform a d ados de cad as tro da p eça
3: Pede con firm ação
4: Confirm a
5: C adas trarPeca (dados de ca das tro da peça)
Figura C.8 – “Incluir Peça”
140
:
Fra m eSele cio n arC l ie n te
: F u nci oná r io
: Cliente
:
Fra m eD ad os C lie nte
1: Ap res en ta l is ta de c ódi gos e no mes de cl ien tes cad as trado s
2: E scolhe cliente da lista
3: DadosCliente(código do cliente es colhido)
4: Ap res e n ta d ado s ca d as trado s do cl ie n te
5: E ntra com dados atualiz ados do cliente
6: Atualiza rC liente(da do s atualiza do s do clie nte)
Figura C.9 – “Alterar Cliente”
: Fu ncioná rio
:
Fram e Se lecio narC liente
: Cliente
1: Apre s enta lis ta de códigos e n om es de clien tes cadas trados
2: Sele ciona clie nte da lis ta apres e ntad a
3: Exclu irC liente (c ód igo do cli en te s eleciona do)
Figura C.10 – “Excluir Cliente”
141
:
Fr ameSe lec ionar Fabr ic ante
: Func ioná rio
:
Fr ameD ados Fabricante
: Fabric ante
1: Ap res enta lis ta d e ab reviatura s de fabricantes cada s trados
2: Seleciona fabricante da lis ta apres entada
3: D ados Fabricante(abreviatura do fabricante s elecionado)
4: Apres enta dados do fabricante s elecionado
5: E ntra c o m dados atua li zados do fabric ante
6: AtualizarFabricante(dados atualizados do fabricante)
Figura C.11 – “Alterar Fabricante”
: Fu ncion ário
:
Fr ame Se lec ion arFabr icante
: Fabric ante
1: Ap re s en ta l is ta de a breviatu r as d e fabr ica ntes cad as trad os
2: Sele ciona fa b ricante d a li sta a pres e nta da
3: Excl uirFab r ic an te (abr e vi atura d o fa b ri can te s e lec ion ad o)
Figura C.12 – “Excluir Fabricante”
142
: Funcionário
:
Fram eSelecionarC om ponente
: Com ponen te
:
FrameD ado s C ompo nente
1: Apres enta lis ta de códigos dos com ponentes cadas trados
2: Seleciona com ponente da lis ta apres entada
3: DadosCom ponente(código do c om ponente selec ionado)
4: Apres enta dados do com ponente s elecionado
5: E ntra c om dados atualizados do com ponente
6: Atual izarC om pone nte( dados atual izados do com ponente)
Figura C.13 – “Alterar Componente”
: Funcionário
:
Fram eSelecionarC om ponente
: Com ponente
1: Apr es enta lis ta de cód igos dos com ponentes cadastra dos
2: Seleciona com ponente da lis ta apres entada
3 : Excl ui rC om ponente(c ódigo do com ponente s elecio nando)
Figura C.14 – “Excluir Componente”
143
:
Fram eSelecionarMaoD eObra
: Funci onár io
:
Fram eD ados MaoD eObra
:
Ma odeObraD aO rdServico
1: Apres enta lis ta de códigos , des crições e tipo das m ão-de-obra cadas tradas
2: Seleciona m ão-de -obra d a li sta apres entada
3: DadosM aoDeObra(c ódigo da m ão-de-obra s elecionada)
4: Apres enta dados da m ão-de-obra s elecionada
5: E ntra com dados atualizados da m ão-de-obra
6: Atual izarMa oDe Ob ra(dados atuali za dos da m ão-de-o bra)
Figura C.15 – “Alterar Mão-de-Obra”
: Func ion ário
:
Fram eSelecionarMa oD eObra
:
Maod eObr aD aO rd Se rvico
1: Apres enta lis ta de cód igos , de s criçõ es e tipo d as m ã o-de-obra ca das trad as
2: Selecio na m ã o-de-obra da lis ta ap re s entada
3: ExcluirMa oD eObra(código da m ão -d e-obra s elecionada)
Figura C.16 – “Excluir Mão-de-Obra”
144
: Funcionário
:
Fram eSelecionarTipoD eVeiculo
:
Fram eD ados TipoD eVeiculo
:
TipoDeV eiculo
1: Apres enta lis ta de códigos dos tipos de veículo cadas trados
2: Selec iona tip o de veíc ulo apres entado
3: D ados TipoD eVeiculo(código do tipo de veículo s elecionado)
4: Apres enta dados do tipo de veículo s elec ion ado
5: E ntra c om dados atualiz ados do tipo de veíc ulo
6: Atual izar Tip oD eVeic ulo (dado s atual izados do tipo de veícul o)
Figura C.17 – “Alterar Tipo de Veículo”
: Fu ncioná rio
:
Fram eSelecio narTipoD eVeiculo
:
TipoDeV eiculo
1: Apres en ta lis ta d e código s d os tipo s de ve ículo cadas trado s
2: Seleciona tip o de ve ícu lo apres en ta do
3: ExcluirTipoD eVeiculo(código d o tipo de veículo s elecion ado)
Figura C.18 – “Excluir Tipo de Veículo”
145
:
Fram eS elecionarP eca
: Funcionário
:
Fram eDados P eca
: P eca
1: Apres enta lis ta de código de barras das peças cadas tradas
2: Se lec iona peç a d a li s ta apres entada
3: Dados P eca(c ódigo de barras da peça selecionada)
4: Apres enta dados da peça s elecionada
5: E ntra com dados atualiz ados da peça
6: AtualizarPeca(dados atualizados da peça)
Figura C.19 – “Alterar Peça”
: Funci onár io
:
Fram eS elec io narP ec a
: Peca
1: Apres enta lis ta de código de barras das peças cadas tradas
2: Seleciona peça da lis ta apres entada
3: ExcluirPeca(código de barras da peça s elecionada)
Figura C.20 – “Excluir Peça”
146
:
Fram eSelecio narForne cedor
: Func ion á rio
:
Fram eD ado s Forne cedor
: Forneced or
1: Apres enta lis ta d e a brevia turas de forneced ores cadas trado s
2: Selecio na forne cedor da lis ta
3: DadosFornecedor(abreviatura do fornec edor selecionado)
4: Apres enta dad os do forne cedor s elecio nado
5: Entra com dado s at ualiz a dos do forne cedor
6: Atua lizarForneced or(d ados atualiza dos do fo rn ecedo r)
Figura C.21 – “Alterar Fornecedor”
: Fu nc ion á rio
:
Fram e Selecion arFornecedo r
: Fornec edor
1: Apres enta lis ta de abreviatu ra s de fo rn ecedores cadas trados
2: Seleciona forneced or da lis ta
3: ExcluirFornecedo r(ab re via tura do fornecedo r s elecionad o)
Figura C.22 – “Excluir Fornecedor”
147
: Funcionário
:
Fram eSelecionarEm pregado
: E mpregado
:
Fram eD ados Em preg ado
1: Apr es enta li sta de códigos e nom es d e em pr egados cada s trados
2: Seleciona em pregado da lis ta apres entada
3 : Da dos E mpregado( códi go do e mpr egado selec io nado)
4: Apres enta dados do em pregado s elecionado
5: E ntra c om dados atualizados do em pregado
6: AtualizarEm pregado(dados atualizados do em pregado)
Frame C.23 – “Alterar Empregado”
: Funcionário
:
Fram eSelecionarEm pregado
: E m pregado
1: Apres enta lis ta de códigos e nom es de em pregados cadas trados
2 : Selec iona em preg ado d a l is ta apre s enta da
3: ExcluirEm pregado(código do em pregado s elecionado)
Figura C.24 – “Excluir Empregado”
148
: Funcionário
:
Fram eSe leciona rEm preg ado
:
Fram eD ados Em pregado
: E m pregado
1: Apres enta lis ta de códigos e nom es de em pregados cadas trados
2: Seleciona em pregado da lis ta apres entada
3: Dados E m pregado(código do em pregado selecionado)
4: Apres en ta dados do em pregado s elecionado
Figura C.25 – “Consultar Empregado”
: Funcionário
:
Fram eSe leciona rEm preg ado
:
Fram eD ados Em pregado
: E m pregado
1: Apres enta lis ta de códigos e nom es de em pregados cadas trados
2: Seleciona em pregado da lis ta apres entada
3: Dados E m pregado(código do em pregado selecionado)
4: Apres en ta dados do em pregado s elecionado
Figura C.26 – “Consultar Componente”
149
:
Fram eSe lecionarC liente
: Cliente
:
Fram eD ados C liente
: F unci oná rio
1: Apresenta lista de códigos e nomes de clientes cadastrados
2: E scolhe cliente da lista
3: DadosCliente(c ódigo do cliente escolhido)
4: Apr es enta dados cadas trad os d o cl iente
Figura C.27 – “Consultar Cliente”
: Funcionário
:
Fram eS elecionarP eca
:
Fram eDados P eca
1: Pede letra inicial do nom e da peça
2: E ntra com letra inic ial
3: Dados P eca(letra inic ial do nom e da peç a)
4: Ap res enta dados da peça
Figura C.28 – “Consultar Peça pela Letra Inicial”
: P eca
150
: Fu n cio n ário
:
Fram eS elecionarP eca
:
Fram eDadosP eca
: P eca
1 : Pe d e có d ig o do fa b rica n te da p e ça
2: E ntra com código
3: DadosP eca(código do fabricante da peça)
4 : Ap res e n ta dado s d a peça
Figura C.29 – “Consultar Peça pelo Fabricante”
: Funcionário
:
Fram eS elecionarP eca
:
Fram eDados P eca
1: Pede código de barras da peça
2: Entra com código de barras
3: Dados P eca(c ódigo de barras da peça)
4: Ap res enta dados da peça
Figura C.30 – “Consultar Peça pelo Código de Barras”
: P eca
151
:
Fram eSelecionarForn ece dor
: Funcion ário
:
F ram eD ados Forne ced or
: Forn ec edor
1 : Apre s e nta lis ta de ab reviatura s de fo rnecedor es cadas tra dos
2: Sel e ciona for neced or d a li s ta
3: DadosFornecedor(abreviatura do fornecedor s elecionado)
4: Apre s enta dado s do fornecedo r s elecio nado
Figura C.31 – “Consultar Fornecedor”
: Fu nci onário
:
Fram eS elec iona rO DS
:
Ordem D eSe rvico
1: Apres enta lis ta de Ordens de Serviço
2: Seleciona Ord em de Serviço da lis ta a pres en tada
3: Excl u irO D S(cód igo d a Orde m de Serviço s ele cionad a)
Figura C.32 – “Excluir Ordem de Serviço”
152
: Funcionário
:
Fr ameSelecionar OD S
:
Fram eD ados Ordem D eServico
:
Or dem D eServico
1: Apres enta lis ta de Ordens de Serviço
2: Seleciona Ordem de Serviço da lis ta apres entada
3: DadosODS (código da Ordem de S erviço selecionada)
4: Apres enta dados da Ordem de Serviço
Figura C.33 – “Consultar Ordem de Serviço”
153
Figura C.34 – “Abrir Ordem de Serviço” – 1a parte
154
Figura C.35 – “Abrir Ordem de Serviço” – 2a parte
155
Apêndice D - Cenários Textuais
Os cenários apresentados neste apêndice foram obtidos através da execução do sistema
legado e visam representar o diálogo humano-computador realizado durante a execução das
tarefas do usuário. A letra “S” indica ação do sistema enquanto a letra “U” representa ação do
usuário. As ações estão agrupadas em “telas” que correspondem às telas navegadas pelo usuário
durante a execução de sua tarefa.
Lançamento da Ordem de Serviço (Primeira Parte – Abrir Ordem de Serviço)
1a tela
U → código do cliente (sistema oferece opção)
S → data de entrada (atual), número da ordem de serviço
S → dados do cliente (todos os atributos)
U → modifica dados conforme necessário
S → pede confirmação dos dados
U → entra como confirmação dos dados
S → mostra dados dos veículos do cliente
S → pede confirmação
U →entra com confirmação
S → pergunta se serviços serão executados
U → responde “N” (não) → sai da opção
U → responde “S” (sim)
S → mostra dados do veículo (permite alterações)
S → pede confirmação
U → confirma
S → pede dados dos serviços a executar (descrição, orçamento, data e horas)
S → cadastra primeira parte
S → pede confirmação para imprimir
156
Lançamento de Ordem de Serviço (Segunda parte - Fechar Ordem de Serviço)
1a tela
S → exibe lista de ordens de serviço abertas
U → escolhe ordem de serviço aberta
2a tela
S → exibe número da Ordem de Serviço
S → exibe nome do cliente, tipo e marca do veículo
U → entra com data de saída de peças
U → entra com códigos de barras das peças
S → apresenta dados da peça
U → entra com quantidade, preço unitário e baixa no estoque (S/N)
S → pede confirmação da baixa
U → entra com código do empregado que vendeu, utilizando ou não lista de
opções
U → Pode cadastrar várias peças até digitar <99999>
3a tela
S → existem peças adquiridas fora (S/N)
S → exibe lista de peças
U → escolhe
4a tela
S → exibe dados da peça
U → altera dados / entra com quantidade e código da peça
S → exibe valor da peça e preço unitário de venda
U → altera preço de venda
U → entra com local de aquisição
S → pede confirmação de lançamento
U → pode lançar várias peças adquiridas fora
Lançamento
de
peças
adquiridas
fora
Cálculo da Mão-de-Obra utilizada (continuação da segunda parte ODS)
5a tela
(repete)
U → escolhe tipo Mão-de-Obra, várias vezes
U → digita “qq”, termina
U → entra com valor
U → entra com código do empregado
6a tela
S → apresenta valor total da ordem de serviço
U → entra com desconto e despesas extras
S → soma desconto e despesas ao valor e apresenta novo valor
U → entra com condições de pagamento
7a tela
S → cadastra contas a receber (usuário confirma cadastro de contas a receber)
157
Contas a Receber
S → apresenta número de parcelas, data de vencimento, valor, moeda e número
doc/cheq
U → entra com banco
S → cadastra conta a receber
Inclusão de Venda de Peça
1a tela
a
1 tela
(repete
várias
vezes)
2a tela
S → apresenta numero de venda e data (editável)
U → entra com código do cliente (sistema oferece lista)
S → apresenta nome do cliente
U → entra com condições de pagamento
U → entra com número da nota fiscal
S → confirma baixa no estoque
U → entra com código de barras
S → apresenta descrição, quantidade e preço unitário
U → altera quantidade e preço unitário
U → entra com desconto
S → apresenta preço unitário
S → apresenta preço total
S → apresenta número de venda, data , código do cliente, nome do cliente,
condições de pagamento, número da nota fiscal e total de vendas
U → entra com descontos e despesas extras
S → apresenta total geral
158
Eliminação da Ordem de Serviço
1a tela
S → exibe lista de ordem de serviço
U → escolhe ordem de serviço
2ª tela
S → exibe data de entrada, código e nome do cliente, tipo do veículo, valor da
Ordem de Serviço, marca
S → pede confirmação
U → confirma
S → elimina ordem de serviço
Consulta Ordem de Serviço Completa
1a tela
S → exibe lista de ordem de serviço (número da ordem de serviço, nome cliente,
data de entrada)
U → escolhe ordem de serviço
2ª tela
S → exibe dados da ordem de serviço, do veículo e do cliente
Consulta de Fornecedores
1a tela
S → exibe lista de nome de fornecedores abreviado e nome fantasia
U → escolhe fornecedor pelo nome abreviado
2ª tela
S → exibe dados do fornecedor
Consulta de Peças
1a tela
S → pergunta qual o tipo de consulta (letra inicial, fabricante, código de barras,
código original, equivalência, estatísticas de custos)
Consulta pela Letra Inicial
1a tela
S → pede nome (descrição da peça)
2a tela
S → mostra dados da peça (código e descrição)
159
U → entra com código da peça
S → apresenta dados da peça
Consulta pelo Fabricante
1a tela
U → entra com o id do fabricante ou código
S → apresenta dados do fabricante
Consulta pelo Código de Barras
1a tela
S → pede código de barras
U→ entra com código de barras
2a tela
S → apresenta todas as características de peças
Consulta por Estatística de Custo
1a tela
S → pede código original da peça a ser consultada
U → entra com código original
S → apresenta custo médio/mínimo/máximo/atual ou data da última compra
(depende da ordem de serviço)
Consulta por Código Original de Peças
1a tela
S → pede código original da peça
U → entra com código original da peça
2a tela
S → apresenta dados da peça
160
Consulta a Empregados
1a tela
S → exibe lista com código e nome dos empregados
U → escolhe um empregado
2a tela
S → apresenta dados do empregado
Consulta a Cliente
1a tela
U → entra com nome do cliente
2a tela
S → mostra lista de nomes e códigos
U → entra com código
3a tela
S → apresenta dados do cliente
Manutenção de Tabelas
Sugestão de Preços
1a tela
U → entra com valor de trabalho, preço para a carga rápida, preço para carga lenta
e valor para hora trabalhada
S → pede confirmação
Eliminação de Fornecedor
1a tela
U → entra com abreviação de fornecedor
S → verifica existência de fornecedor
2a tela
S → exibe dados de fornecedor
S → pede confirmação
U → confirma
S → elimina fornecedor
161
Modificação de Empregados
1a tela
S → exibe lista de código/nome de empregados
U → escolhe empregado
2a tela
S → exibe dados do empregado
U → modifica nome
U → modifica outros dados
S → pede confirmação
S → grava/abandona
Eliminação de Empregados
1a tela
S → exibe lista de código/nome de empregados
U → escolhe empregado
2a tela
S → exibe dados do empregado
S → pede confirmação
U → confirma
S → elimina fornecedor
Modificação Parcial de Peças
1a tela
U → entra com código de barras
S → verifica existência
2a tela
S → exibe dados da peça
U → altera dados da peça (menos o código, peças equivalentes e veículos)
S → pede confirmação
S → grava/abandona
Modificação do Fornecedor
1a tela
U → entra com abreviação de fornecedor
S → verifica existência
2a tela
S → exibe dados para modificação
U → altera dados
S → pede confirmação
162
S → grava/abandona
2a tela
S → oferece opções de “ramos”
U → escolhe ramos
U → digita fim
S → grava/abandona
Modificação Total de Peças
1a tela
U → entra com código de barras
2a tela
S → exibe dados para modificação
S → pede alteração do código
U → entra com código
S → libera outros campos (menos o código)
U → altera dados
S → pede código de peças equivalentes
U → informa código de peças equivalentes
S → pergunta se há mais alguma modificação
S → grava/abandona
3a tela
S → informa código da peça e veículos a que se adaptam
U → altera veículos
S → grava/abandona
Eliminação de Peças
1a tela
U → entra com código de barras
S → verifica existência
2a tela
S → exibe dados de fornecedor
U → confirma eliminação
163
Eliminação de Mão de Obra
1a tela
S → oferece lista
U → escolhe mão de obra
2a tela
S → exibe dados da mão de obra
S → pede confirmação
U → confirma
S → elimina
Modificação de Tipo de Veículo
1a tela
U → entra com código de tipo de veículo
S → verifica existência
2a tela
S → exibe dados
U → altera dados (menos o código)
S → pede confirmação
S → grava/abandona
Eliminação de Veículo
1a tela
U → entra com código de veículo
S → verifica existência
2a tela
S → exibe dados do veículo
S → pede confirmação
U → confirma
S → elimina veículo
164
Modificação de Componentes
1a tela
U → entra com código do componente
S → verifica existência
2a tela
S → exibe dados para modificação
U → altera dados (menos o código)
S → pede confirmação
S → grava/abandona
3a tela
S → exibe código
U → entra com veículos adaptáveis
S → pede confirmação
S → grava/abandona
Eliminação de Componentes
1a tela
U → entra com código do componente
S → verifica existência
2a tela
S → exibe dados (menos veículo )
S → pede confirmação
U → confirma
S → elimina componente
Modificação de Mão-de-Obra
2a tela
S → exibe lista
U → escolhe da lista
3a tela
S → exibe dados
U → modifica dados (menos o código)
S → pede confirmação
S → grava/abandona
165
Modificação de Clientes
1a tela
S → oferece lista (código e nome) de clientes
U → entra com código do cliente
S → verifica existência
2a tela
U → altera dados (menos código e nome)
S → pede confirmação
S → grava/abandona
Eliminação de Clientes
1a tela
U → entra com código do cliente
S → verifica existência
2a tela
S → exibe código e nome do cliente
S → pede confirmação
U → confirma
S → elimina cliente
Modificação de Fabricante
1a tela
U → entra com abreviação do fabricante
S → verifica existência
2a tela
U → altera dados (menos abreviação)
S → pede confirmação
U → confirma
S → grava/abandona
Eliminação de Fabricante
1a tela
U → entra com abreviação do fabricante
S → verifica existência
2a tela
S → exibe dados do fabricante
S → pede confirmação
U → confirma
S → elimina fabricante
166
Inserção de Clientes
1a tela
S → pede nome do cliente
U → informa nome do cliente
S → verifica se cliente não existe (senão informa erro)
2a tela
S → indica código e data
U → entra com dados do cliente
S → pede confirmação
U → confirma
S → insere cliente
Inserção de Componentes
1a tela
S → pede código do componente
U → informa código do componente
S → verifica se componente não existe (senão informa erro)
2a tela
S → informa código do componente
U → entra com dados do componente
S → pede confirmação
U → confirma
S → insere componente
167
Inserção de Mão de Obra
1a tela
S → informa código da mão de obra
U → entra com dados da mão de obra
S → pede confirmação
U → confirma
S → insere mão de obra
Inserção Veículos
1a tela
S → informa código do veículo
S → pede marca, tipo e grupo do veículo
U → informa marca, tipo e grupo do veículo
S → pede confirmação
S → grava/abandona
Inserção de Fornecedores
1a tela
S → pede abreviatura do fornecedor
U → informa abreviatura do fornecedor
S → verifica se fornecedor não existe (senão informa erro)
2a tela
S → informa abreviatura e código fornecedor
U → entra com dados do fornecedor
S → pede confirmação
S → grava/abandona
3a tela
S → informa abreviatura e nome fantasia
U → seleciona ramo do fornecedor
168
Inserção de Empregados
1a tela
S → pede nome do empregado
U → informa nome do empregado
S → verifica se empregado não existe (senão informa erro)
2a tela
S → gera e mostra código do empregado
S → mostra nome do empregado e senha
U → entra com dados do empregado
S → pede confirmação
U → confirma
S → insere empregado
Inserção de Fabricantes
1a tela
S → pede abreviatura do fabricante
U → informa abreviatura do fabricante
S → verifica se fabricante não existe (senão informa erro)
2a tela
S → mostra abreviatura
U → entra com nome e código do fabricante
S → pede confirmação
U → confirma
S → insere fabricante
169
Apêndice E - Diagramas de Caixas
Os diagramas de caixas aqui apresentados representam os níveis mais abstratos das
árvores de menus das interfaces dos sistemas legado, segmentado e OO, antes e depois do
processo de reengenharia para interfaces com RV.
Figura E.1 – Diagrama para a árvore de menus originais do sistema legado
Figura E.2 – Diagrama para a árvore de menus do sistema legado com interface com RV
170
Figura E.3 – Diagrama para a árvore de menus originais do sistema segmentado
Figura E.4 – Diagrama para a árvore de menus do sistema segmentado com interface com RV
171
Figura E.5 – Diagrama para a árvore de menus originais do sistema OO
Figura E.6 – Diagrama para a árvore de menus do sistema OO com interface com RV
172
Anexo I – Modelo de Classes Original
Modelo de classes recuperado na fase de engenharia reversa para a segmentação aplicada no
sistema legado.
O modelo apresentado a seguir foi usado como base para o modelo de classes mostrado
no Apêndice A e foi obtido no processo de segmentação mostrado em (Penteado, 1998).
173
Figura I.1 – Modelo de classes obtido no processo de segmentação do sistema legado
174
Anexo II – Modelo de Ciclo de Vida
Modelo de ciclo de vidas do sistema exemplo
O modelo apresentado a seguir foi obtido no processo de segmentação mostrado em
(Penteado, 1998) e utilizado para compreender as tarefas do usuário durante a reengenharia para a
linguagem Java® e durante a reengenharia de interface para interfaces com RV.
Figura II.1 – Ciclo de vida do sistema legado
175
Anexo III – Mapa de Menus
Mapa parcial de menus
Neste anexo é apresentado o mapa de menus das camadas de abstração mais alta da árvore
de menus do sistema-exemplo, apresentada em sua documentação técnica (Braga, 1990).
176
Figura III.1 – Primeira parte do mapa de menus
177
Figura III.2 – Segunda parte do mapa de menus
178
Figura III.3 – Terceira parte do mapa de menus
179
Figura III.4 – Quarta parte do mapa de menus
180