Manutenção e Documentação do Portal Corporativo da 6ª Região da PMMG
DANIELA DE SOUZA MACHADO1
HEITOR AUGUSTUS XAVIER COSTA2
UFLA - Universidade Federal de Lavras
DCC - Departamento de Ciência da Computação
Cx. Postal 37 - CEP 37200-000 Lavras (MG)
1
[email protected]
2
[email protected]
Resumo. A necessidade de realizar a manutenção de um produto de software é motivada
principalmente por alguma insatisfação dos usuários com a sua utilização e, consequentemente, pela
falha em sua usabilidade. Porém, o processo de manutenção de produtos de software muitas vezes
torna-se complexo, quando a sua modelagem e a sua documentação não existem ou foram mal
elaboradas. Assim, neste trabalho foram realizadas a manutenção e documentação do Portal
Corporativo da 6ª Região da Polícia Militar de Minas Gerais onde foram aplicados os conceitos de
engenharia reversa de software e reegenharia de software e a modelagem UWE (UML-based Web
Engineering).
Palavras-Chave: Portal Corporativo, Manutenção de Produtos de Software, Engenharia Reversa,
Reegenharia, Modelagem UWE e Usabilidade.
1 Introdução
mantido, sendo, porém, de grande utilidade, ele deve
ser reconstruído. Partindo-se do produto de software
Segundo [OSBORNE & CHIKOFSKY (1990)], a
existente (via código-fonte, interface ou ambiente), é
variedade de problemas que envolvem a manutenção
abstraída sua funcionalidade e são construídos o seu
de produtos software cresce constantemente, sendo
modelo de análise e o seu modelo de projeto. Esse
que as soluções não acompanham essa evolução.
processo é denominado engenharia reversa.
Esses problemas são resultantes de código-fonte e
Sob esta ótica, foi constatada a necessidade
documentação mal elaborados, além da falta de
de realizar a manutenção do Portal Corporativo da 6ª
compreensão do produto de software.
Região da Polícia Militar de Minas Gerais (6ª RPM).
Além das correções de erros (manutenção
Esse produto de software, conforme citado em
corretiva), as mudanças mais comuns que os
[LEMOS (2003)], tem possibilitado um melhor
produtos de software sofrem são migrações para
gerenciamento
novas plataformas, ajustes para mudanças de
ocasionando a integração de toda a organização a
tecnologia de hardware ou sistema operacional
uma base única de conhecimento, acessível através
(manutenção adaptativa) e extensões em sua
de um browser.
funcionalidade para atender os usuários (manutenção
perfectiva).
Quando o produto de software não é fácil de ser
de
dados
e
de
informações
Sendo assim, para que estas informações
continuem satisfazendo as necessidades dos usuários,
é essencial que algumas alterações e adições sejam
realizadas na funcionalidade deste produto de
As atividades de manutenção são classificadas
software. Principalmente no que se refere ao
geralmente em quatro categorias [CAPRETZ &
dinamismo do conteúdo das páginas que compõem o
CAPRETZ (1996)]:
Portal. Pois, uma vez presente este dinamismo, não
1. Manutenção
no
produto
possibilitando até mesmo usuários leigos realizar
comportamento funcional, resultante de uma
operações como: inclusão, alteração e remoção de
mudança
informações. Há também a necessidade de modificar
requisitos;
a interface com o usuário, para que características de
2. Manutenção
estejam presentes
no
produto
de
intenção
alterando
original
Adaptativa:
seu
ou
nos
alteração
do
produto de software em resposta a uma
software.
modificação no ambiente dos dados (formatos
Desta forma, este trabalho surge com o intuito de
de entrada e saída) ou no ambiente de
realizar a modelagem, documentando o produto de
processamento (hardware ou software);
software existente, além de adaptá-lo às novas
3. Manutenção Corretiva: correção de erros
necessidades dos usuários. Para isso, os conceitos de
engenharia
na
software,
acréscimo
há necessidade de alterar o código-fonte da página,
usabilidade
de
Perfectiva:
reversa
reengenharia
de
(backward
software,
engineering)
bem
como
que causam saída incorreta ou finalização
e
anormal do produto de software;
um
4. Manutenção Preventiva: atualização do
subconjunto de artefatos de software do padrão de
sistema de software para antecipar problemas
modelagem UML based Web Engineering (UWE),
futuros; isto envolve melhorar a qualidade do
são utilizados.
produto de software e a sua documentação, ou
2 Manutenção de Produtos de Software
outros fatores de qualidade de software.
Conforme citado em [CAPRETZ & CAPRETZ
Modificações nesta atividade não afetam o
(1996)], a manutenção de produtos de software
comportamento funcional do produto de
consiste de uma série de atividades requeridas para
software.
mantê-lo funcional após aceito e colocado em
Pode-se dizer que a manutenção de software é
operação.
A preocupação atual sobre a manutenção é
um
processo
de
mudança
para
garantir
a
devida ao reconhecimento de que esta é a fase mais
sobrevivência do produto de software. No entanto,
cara do ciclo de vida1 de um produto de software.
segundo [SCHNEIDEWIND (1987)], o processo de
Além disso, a qualidade de reparos e atualizações no
manutenção é bastante árduo devido a 3 fatores, a
código-fonte é
saber:
freqüentemente
pobre e pode
comprometer a confiabilidade e o desempenho do
produto de software.
• Não existem ainda formas eficazes de
acompanhar os produtos de software gerados
e o processo de sua geração na manutenção;
1
Amplo conjunto de estágios da engenharia de software
que abrange: análise de requisitos, projeto, implementação,
teste e manutenção de um produto de software
[PRESSMAN (2001)].
• Falta
de
ferramentas
apropriadas
para
identificação de conseqüências que uma
manutenção pode acarretar;
• Ausência ou pouco envolvimento das equipes
3 Engenharia Reversa
de manutenção durante o processo de
Muitas vezes, o engenheiro de software diante da
desenvolvimento do produto de software.
manutenção do produto de software encontra uma
documentação informal e incompleta, que não o
Para
que
as
técnicas
de
manutenção
reflete, tornando impossível o gerenciamento do
(especificamente engenharia reversa e reengenharia)
processo de manutenção [SALEH & BOUJARWAH,
sejam descritas de forma simplificada, são tomadas
(1996)]. Neste caso, a Engenharia Reversa, com o
como base apenas três fases do processo de
propósito de recuperar as informações de projeto
desenvolvimento, com níveis de abstração bem
perdidas durante a fase de implementação e de
diferenciados (conforme a Figura 2.1), a saber:
documentar o seu real estado, pode auxiliar este
• Requisitos: especificação do problema a ser
resolvido, incluindo objetivos, restrições e
regras de negociação (o quê);
codificação,
O processo inverso à engenharia progressiva,
caracterizado pelas atividades retroativas do ciclo de
• Projeto: especificação da solução (como);
• Implementação:
processo de gerenciamento.
teste
vida, que partem de um baixo nível de abstração para
e
adaptação ao sistema operacional (realização).
um alto nível de abstração, é conhecido como
engenharia
reversa
[CHIKOFSKY
&
CROSS
(1990)].
Para [PRESSMAN (2001)], a engenharia reversa
de software é um processo de recuperação de
projeto, consistindo em analisar um programa, na
tentativa de criar uma representação, em um nível de
abstração mais alto que o código fonte.
A engenharia reversa é de grande importância na
manutenção de produtos de software, facilitando
também sua futura reengenharia. Unindo-se ao
entendimento de produtos de software, a engenharia
reversa produz resultados muito úteis ao engenheiro
de software responsável por alterações, reuso e
evolução do produto de software.
Figura 1: Relacionamentos no Ciclo de
Desenvolvimento de Software
Na Figura 1, com exceção da engenharia
progressiva, as demais transições entre as fases de
desenvolvimento são tecnologias utilizadas na
manutenção de produtos de software[CHIKOFSKY
& CROSS (1990)].
4 Reengenharia
Segundo [PRESSMAN (2001)], a reengenharia,
também chamada de recuperação ou renovação,
recupera informações de projeto de um produto de
software existente e usa essas informações para
alterá-lo ou reconstituí-lo, preservando as funções
existentes, ao mesmo tempo em que adiciona nova
funcionalidade, em um esforço para melhorar sua
visualização, construção e documentação de sistemas
qualidade global.
de software [BOOCH (1998)]. Entretanto, sua
O processo de reengenharia é constituído de duas
sustentação para aplicações da Web é considerada
fases distintas. Na primeira, o produto de software
insuficiente. Não há, por exemplo, nenhum “padrão”
objeto de reconstrução é “desmontado”, visando seu
de elementos de modelo que representam um menu
entendimento. Na segunda, o produto de software é
ou um índice definido, nem elementos que
reconstruído, na forma desejada, a partir do resultado
representam trajetos da navegação entre locais
da primeira fase, sendo incluídos os ajustes que se
diferentes da Web.
Uma solução possível é estender a UML. De fato,
fizerem necessários.
O processo de Reengenharia pode ser traduzido
a UML é definida como auto-extensível, isto é, os
mecanismos de extensão são definidos na própria
como [JACOBSON & LINDSTRÖM (1991)]:
UML. Com seus mecanismos de extensão, as
Reengenharia = Engenharia + ∆ Engenharia
Reversa
Progressiva
onde
soluções específicas para situações específicas, tais
como sistemas de tempo real ou aplicações Web,
podem ser desenvolvidas. Tais extensões são
pode ser de dois tipos:
•
Alterações parciais de funcionalidade:
chamadas Perfil e são padronizadas pelo Object
ocorrem devido a mudanças nos negócios
Management Group (OMG), http://www.omg.org/.
Um destes perfis para modelagem de aplicações
ou a necessidade do usuário;
•
Alterações de implementação: ocorrem
Web é a UML-based Web Engineering (UWE)
devido
proposta por [KOCH (2002)].
a
alterações
no
ambiente
de
operação do software e/ou linguagem de
A UWE introduz uma abordagem sobre a
sistema
modelagem incluindo três modelos, cada um focando
operacional, portabilidade, linguagens, etc.).
um aspecto central das aplicações Web: conteúdo,
implementação
(protocolos,
navegação e apresentação.
5 UWE
No Modelo Conceitual, as classes e os objetos
A Web tornou-se parte de nossa vida diária. Há cada
participantes do sistema e as relações entre eles são
vez mais aplicações da Web no nosso dia a dia e as
modeladas. Elementos do modelo usados no modelo
aplicações estão se tornando maiores. Entretanto,
conceitual são: Classes Conceituais, Pacotes e
modelar aplicações da Web é ainda uma disciplina
Associações. Pacotes e Associações são como na
nova, os métodos e as linguagens existentes,
UML não estendida. Classe Conceitual é uma
especialmente a UML, não suportam adequadamente
subclasse da classe por adição de um atributo, se a
a modelagem Web.
navegação é relevante ou não. Isto indica se esta
A aproximação UML-based Web Engineering
(UWE) tenta resolver este problema introduzindo
uma
extensão
ao
UML
(Unified
classe conceitual é relevante para o modelo de
navegação.
Modeling
No Modelo de Navegação, a estrutura de
Language), usando os seus mecanismos de extensão.
navegação da aplicação Web é modelada. Para cada
A Unified Modeling Language (UML) é uma
classe conceitual relevante para a navegação no
linguagem popular, padronizada para especificação,
modelo conceitual, existe uma classe de navegação
adicionada para este modelo. Associações entre
6.1 Design
classes de navegação são adicionadas se suas classes
Embora a tecnologia de portais corporativos seja
conceituais são conectadas umas com as outras por
recente, vários são os benefícios apontados por
associações no modelo conceitual. Uma associação
fornecedores e consultores de informática associados
deve ser adicionada para representar os caminhos de
a sua aplicação nas instituições. Porém, para
navegação de uma classe de navegação para outra.
conseguir concretizar esse benefício, é fundamental
Além disso, acessos primitivos são adicionados para
que o projeto do Portal Corporativo leve em
modelar as possibilidades para o usuário poder
consideração a interação dos usuários com sua
navegar na aplicação. Elemento de navegação é a
interface. Sua capacidade de facilitar o acesso dos
forma genérica da classe de navegação. Cada
usuários às informações e aos meios de comunicação
elemento de navegação representa um nó da
corporativa está intrinsecamente relacionada à
navegação Web.
facilidade
de
uso,
satisfação
do
usuário,
No Modelo de Apresentação, a estrutura de
aprendizagem, capacidade de memorização, isto é, à
apresentação da aplicação Web é modelada. Para
usabilidade de sua interface. Baseado nisso, foi feito
cada
o re-design das páginas de tal maneira que facilitasse
elemento
apresentável
no
modelo
de
apresentação, existe uma classe de apresentação
a utilização do Portal pelo usuário.
adicionada ao Modelo de Apresentação. O Modelo
A falta de uso de padrões, inconsistências de
de Apresentação é a representação de onde e como
hiperlinks e redundância de páginas foram os fatores
os objetos da navegação e os acessos primitivos
motivadores que levaram a adoção de um novo
serão apresentados para o usuário.
modelo para as páginas que compõem o Portal. O
modelo aplicado no design do Portal Corporativo foi
6 Resultados
O Portal Corporativo da 6ª RPM foi desenvolvido
com o intuito de integrar as informações e todo o
pessoal que o compõe. A manutenção e a
documentação do Portal realizadas neste trabalho
visaram satisfazer as necessidades apontadas pelos
usuários do produto de software e possibilitar sua
melhor utilização dentro da instituição e pelo público
em geral, através de serviços oferecidos pela Polícia
Militar de Minas Gerais. Através deste trabalho foi
possível reestruturar o produto de software, seu
design, incluir funções para tratar as novas
informações
disponibilizadas
pelo
produto
de
software e gerar uma documentação abrangente do
Portal.
a utilização de quadros (frames), este modelo tem
como característica a divisão da página em quadros
independentes, garantindo assim menor redundância
de páginas e maior velocidade ao carrega-las,
diminuindo, assim o tráfego de dados na rede. Uma
vez que as operações efetuadas afetarão somente
algum(s) quadro(s) da página, ou seja, não será
necessário carregar novamente a página toda, mas
apenas porções dela.
As cores presentes no design foram escolhidas de
modo a manter o padrão com o Portal Corporativo da
Polícia Militar de Belo Horizonte e as fontes dos
textos foram cuidadosamente selecionadas de modo
a facilitar a visualização pelo usuário. Um exemplo
de uma página desenvolvida com a utilização de
quadros pode ser visualizado na figura 2.
apresentava alguns dados redundantes e outros que
antes não estavam presentes na base de dados, mas
que seriam fundamentais para a realização desta
tarefa.
Depois
de
finalizada
esta
fase,
foram
reestruturados os códigos de todas as páginas que
compõem o Portal, de forma a fazer com que
acessassem a nova base de dados. No momento da
fase
de
reestruturação,
foram
desenvolvidos
mecanismos para permitir o dinamismo do conteúdo
das páginas de forma a prever futuras alterações
Figura 2: Página para realizar cadastro/manutenção de
Ocorrências.
sobre os dados. Um exemplo de mecanismo adotado
nas páginas é a atribuição de conteúdo dinâmico a
6.2 Nova Funcionalidade
componentes da página denominados lists e menus,
O objetivo central da manutenção e documentação
ou seja, os valores que preenchem estes componentes
do Portal Corporativo da 6ª RPM pode ser descrito
são obtidos através de consultas na base de dados.
como: criar mecanismos para fornecer maior
Uma
importante
função
do
Portal
é
a
dinamismo às informações presentes no Portal,
possibilidade de alterar a hierarquia das unidades que
incluir funções para tratar as novas informações
compõem a Sexta Região da Polícia Militar de Minas
disponibilizadas pelo produto de software e gerar
Gerais. Esta hierarquia é definida da seguinte forma:
uma documentação abrangente do Portal.
no nível mais alto estão as Regiões da Polícia Militar
A nova funcionalidade do Portal permite a
(RPM), logo abaixo as Unidades Operacionais
manipulação de informações que anteriormente não
(UEOP)
eram tratadas pelo produto de software. Estas
Companhias da Polícia Militar Independentes, em
informações foram apontadas pelos usuários como
seguida Companhias da Polícia Militar, abaixo os
importante para o conhecimento e sua manipulação
Pelotões da Polícia Militar, Destacamentos e Sub-
pelos membros da corporação. Portanto, a nova
destacamentos.
–
Batalhões
da
Polícia
Militar
e
funcionalidade permite a realização dos seguintes
Devido a esta estrutura ser passível de alterações
cadastros e/ou manutenção: arquivos para download
ao longo do tempo, ou seja, uma Companhia PM
através do Portal, enquetes, links úteis, Companhia
pode vir a tornar-se uma Unidade Operacional e, por
PM, Pelotão PM, controle de mensagens a serem
sua vez, conter suas próprias Companhias PM,
exibidas no fórum de discussão, controle de
Pelotões PM e Grupos PM que antes eram
mensagens a serem exibidas do mural de recados e
subordinados a outra Unidade Operacional, foi
organograma estrutural da 6ª RPM.
necessária a criação de mecanismos que tratassem
Para que fosse possível tornar dinâmico o
estas possíveis modificações.
conteúdo das páginas, houve a necessidade de criar
A partir disto, será possível, após uma mudança
uma nova base de dados. Uma vez que o banco de
da hierarquia, cadastrar novas informações seguindo
dados
utilizado
anteriormente
à
manutenção
a atual disposição da estrutura assim como manter os
dados cadastrados anteriormente.
6.3 Modelagem do Produto de Software
Um exemplo de diagrama de caso de uso de um
subsistema do Portal Corporativo é apresentado na
figura 4.
A partir da aplicação de engenharia reversa
apresentada no Capítulo 3 (Engenharia Reversa de
Software), foi possível recuperar as informações do
projeto e documentar o real estado do Portal, através
Adm. Recursos
Humanos
(f rom Grupos e Usuarios)
da construção do modelo de casos de uso (use cases)
Manutenção do Cadas tro de
Us uários
do produto de software.
Neste trabalho, foi adotado um padrão para este
modelo o qual é representado apenas por um caso de
(f rom Usuários)
Adm. Total
(f rom Administração do Portal)
uso que abrange cada subsistema do Portal. Portanto,
cada caso de uso abrangerá informações sobre todas
Figura 4: Diagrama de Caso de Uso do Subsistema
Usuários
as operações que podem ser realizadas em cada
De acordo com [KOCH (2001)], os principais
subsistema, estas operações são: cadastrar novas
elementos utilizados no modelo conceitual são as
informações, alterar os dados, listar as informações
classes e as associações entre elas. Graficamente, as
cadastradas e removê-las. Este padrão foi adotado
classes são representadas como na notação UML, ou
devido ao grande número de casos de usos existentes
seja, são descritas por um nome, atributos e métodos.
e para que pudesse obter um conhecimento geral do
O Portal Corporativo da 6ª RPM possui inúmeras
produto de software, porém de forma resumida.
Os subsistemas presentes no Portal podem ser
visualizados na figura 3. Este diagrama apresenta
classes cada qual pertencendo a um subsistema. Um
exemplo de modelo conceitual do subsistema
Usuários é apresentado na figura 5.
todos os subsistemas do produto de software, bem
como a relação entre eles.
Usuários
Nome: String
Sexo: String
CPF: String
RG: String
Data de Nascimento: String
E-mail: String
Cargo: String
Login: String
Senha: String
Graduação: Posto ou Graduação
Especialização: Especialização
UEOP: Unidade Operacional
Figura 5: Modelo Conceitual do subsistema Usuários
Figura 3: Diagrama dos subsistemas do Portal
Corporativo da 6ª RPM
de
O diagrama de apresentação do subsistema
a
Usuários é mostrado na Figura 7. Segundo [KOCH
construção de dois modelos de navegação: o espaço
(2002)], este diagrama é semelhante à interface vista
do modelo de navegação e a estrutura do modelo de
pelo usuário. Além disso, não é necessário colocar
navegação.
em uma classe de apresentação os atributos e as
Segundo
navegação
[KOCH
de
(2002)],
aplicações Web
o
modelo
compreende
Um exemplo de espaço do modelo de navegação,
apresentado na Figura 6, inclui as classes do
operações desta classe. A letra “P” ao lado de cada
componente representa uma classe de apresentação.
subsistema Usuários e os objetos que podem ser
visitados durante a navegação. Os principais
elementos para este modelo são: as páginas
principais de cada seção e o módulo administrador
P
Internet do Portal Corporativo da 6ª RPM
P
Intranet do Portal Corporativo da 6ª RPM
do sistema, chamada de classes de navegação e a
P Administração do Portal Corporativo da 6ª RPM
direção da navegabilidade, ou seja, a direção do
caminho das classes de navegação para as demais
classes
do
subsistema,
sem
incluir
P
páginas
Menu de subsistemas
19
adicionais.
P
<< classe de navegação >>
Internet do Portal Corporativo da 6ª RPM
Grupos e Usuários
P Menu Usuários
<< classe de navegação >>
Intranet do Portal Corporativo da 6ª RPM
P Menu Grupos
P Cadastrar Usuário
<< classe de navegação >>
Administração do Portal Corporativo da 6ª
RPM
<< classe de navegação >>
Grupos e Usuários
P
Alterar Usuário
P
Listar Usuários
P
Remover Usuário
P
Consulta Usuário
Usuários
Nome: String
Sexo: String
CPF: String
RG: String
Data de Nascimento: String
E-mail: String
Cargo: String
Login: String
Senha: String
Graduação: Posto ou Graduação
Especialização: Especialização Unidade
Operacional: Unidade Operacional
P
Figura 7: Modelo de Apresentação do subsistema
Usuários
7 Conclusão
Um forte motivo para a mudança em um produto de
software se refere às suas falhas de usabilidade e
falta
Figura 6: Espaço do Modelo de Navegação do
subsistema Usuários
Usuários
de
funcionalidade
que
trate
todas
as
informações importantes para a organização. Essa
mudança pode ser realizada através da reengenharia
de software e, para o sucesso dessa reengenharia,
esta deve ser precedida de um planejamento [SILVA
& DÍSCOLA (2003)].
Segundo o mesmo autor, o planejamento da
reengenharia
deve
estabelecer
justificativas
e
objetivos para a mudança no produto de software,
determinar as atividades necessárias na reengenharia
e estudar a sua viabilidade como forma de mudança
do
produto
organização.
de
software
Nota-se
que
existente
os
em
uma
processos
de
planejamento de reengenharia existentes mencionam
a necessidade de conhecer os objetivos e causas para
a mudança, e os desejos e objetivos dos usuários para
responder perguntas sobre quais requisitos estão com
problema, quais mudanças devem ser realizadas e o
que os usuários esperam do produto de software.
A manutenção realizada no produto de software
Portal Corporativo da 6ª RPM forneceu nova
funcionalidade e o reestruturou de forma a atender
aos requisitos levantados durante o planejamento da
reengenharia. Através deste trabalho foi possível
proporcionar um avanço na comunicação dentro da
corporação, a fim de afetar positivamente os
processos de geração, difusão e armazenamento de
conhecimento da Polícia Militar de Minas Gerais.
A partir da aplicação da engenharia reversa, foi
possível recuperar informações de projeto perdidas
durante a fase de desenvolvimento e documentar o
real estado do produto de software. A documentação
gerada irá auxiliar futuros processos de manutenção,
além de ficar mais simples continuar a sua
construção.
8 Referências Bibliográficas
[OSBORNE & CHIKOFSKY (1990)] Osborne, W.
M. & Chikofsky, E. J. Fitting Pieces to the
Maintenance Puzzle. IEEE Software, v. 7, n. 1,
1990, p. 11-12.
[LEMOS (2003)] Lemos, Renato A. Estudo de
Conceitos e Características do Portal
Corporativo da 6ª RPM: Um Estudo Preliminar.
Lavras, UFLA, 2003. Monografia (graduação).
[CAPRETZ & CAPRETZ (1996)] Capretz, Luiz F.
& Capretz, Miriam A. M. Object-Oriented
Software: Design and Maintenance. University
of Pittsburgh, USA. Series Editor S K Chang:
Series on Software Engineering and Knowledge
Engineering, Vol. 6, 1996.
[PRESSMAN (2001)] Pressan, Roger. S. Engenharia
de Software. São Paulo, Makron Books, 5ª Ed.,
2001.
[SCHNEIDEWIND (1987)] Schneidewind, N. F .
Introduction to the Special Section on Software
Maintenance.
The
State
of
Software
Maintenance. IEEE Transactions on Software
Engineering, 1987. pp.303-310.
[CHIKOFSKY & CROSS (1990)] Chikofsky, E. J.
& Cross II, J. H. Reverse Engineering and
Design Recovery: A Taxonomy. IEEE Software,
v. 7, n. 1, 1990, p. 13-17.
[SALEH & BOUJARWAH (1996)] Saleh, K. &
Boujarwah, A. Communications Software
Reverse Engineering: A Semi Autmatic
Approach.
Information
and
Software
Technology, Oxford, n.38, p.379-390, 1996.
[JACOBSON & LINDSTRÖM (1991)] Jacobson, I.
& Lindström, F. Reengineering of old systems
to an object-oriented architecture. SIGPLAN
Notices, v. 26, n. 11, 1991, p. 340-350.
[BOOCH (1998)] Booch, G.; Rumbaugh, J. &
Jacobson, I. The Unified Modeling Language
User Guide, ADDISON-WESLEY, 1998.
[KOCH (2001)] Koch, Nora Parcus. Software
Engineering for Adaptive Hypermedia Systems.
München:
Ludwig-Maximilians-Universität
München, 2001.
[KOCH (2002)] Koch, Nora Parcus. CASE Support
For Modeling Web Applications. München:
Ludwig-Maximilians-Universität
München,
2002.