Ideas Main

IDEAS 2004
7 Workshop Iberoamericano
de Ingeniera de Requisitos y Ambientes Software
Arequipa, Per
3 a 7 de Mayo de 2004
Memorias
Editores
Olsina, Luis
Cuadros-Vargas, Ernesto
Vasconcelos, Alexandre
Memorias de 7
Workshop Iberoamericano de
Ingeniera de Requisitos y Ambientes Software
IDEAS-2004
Prohibida la reproduccin total o parcial de esta obra, por cualquier

medio, sin la autorizacin de sus editores.
Libro ISBN: 9972-9876-1-2

Deposito Legal 0401012004-2242
PRLOGO
Este volumen contiene los artculos aceptados y presentados en el VII Workshop

Iberoamericano de Ingeniera de Requisitos y Ambientes Software (IDEAS 2004) celebrado en
Arequipa, Per, del 3 al 7 de Mayo de 2004.
El workshop IDEAS'2004 ya se ha consolidado como un foro cientfico de discusin y

encuentro de reconocido prestigio para el intercambio de conocimientos y experiencias entre los
principales investigadores de la Ingeniera de Software e Ingeniera Web en el mbito
Iberoamericano. El presente evento es la continuidad de la labor iniciada en IDEAS98, celebrada
en Torres (Brasil), IDEAS99 en San Jos (Costa Rica), IDEAS00 en Cancn (Mxico),
IDEAS01 en Heredia (Costa Rica), IDEAS02 en La Habana (Cuba), e IDEAS03 en Asuncin
(Paraguay). Por ello queremos agradecer especialmente a los miembros del Comit de Programa
por su excelente y desinteresado trabajo, necesario para renovar la calidad y prestigio ganado.
Tambin nuestro sincero agradecimiento a todos los autores que aportaron sus contribuciones por
haber seleccionado a IDEAS como evento de confianza.
En la presente convocatoria se han recibido 77 artculos de calidad cientfica para su

evaluacin. Cada trabajo ha sido evaluado por al menos 2 revisores y se ha contemplado la
resolucin de divergencias, que por cierto han sido muy pocas. Con el fin de mantener la tradicin
de no desarrollar sesiones paralelas y, principalmente, de mantener el nivel de calidad establecido
por el Comit de Conduccin, se decidi aceptar un total de 26 artculos largos y 13 artculos
cortos, por estricto orden de mrito.
Adems de la sesiones tcnicas, el Workshop IDEAS (http://www.spc.org.pe/ideas2004/), ha

estado precedido por 5 mini-tutoriales dictados por reconocidos investigadores de diversas reas y
pases. Confiamos que todo el Programa resultante sea til y despierte el inters de las nuevas
generaciones de investigadores y profesionales del rea.
A todos los autores, revisores, organizadores, editores y colaboradores en general, francamente,

muchas gracias! Y les damos la bienvenida a esta histrica y bella ciudad de Arequipa, desendoles
una productiva estancia!
Luis Olsina Alexandre Vasconcelos Ernesto Cuadros-Vargas

Pte. del Comit de Programa Co-Pte. del Comit de Programa Pdte. del Comit Organizador
Comit de Programa
Presidencia
Luis Olsina (U. Nacional de La Pampa, Argentina)
Co-Presidencia
Alexandre Vasconcelos (U. F. de Pernambuco, Brasil)
Miembros
Ana Cristina Rouiller (U. F. de Lavras, Brasil)
Antonio Brogi (U. de Pisa, Italia)
Antonio Vallecillo (U. de Mlaga, Espaa)
Carlos Heuser (UFRGS, Brasil)
Cecilia Bastarrica (U. de Chile, Chile)
Claudia Pons (U. Nacional de La Plata, Argentina)
Daniel Germn (U. de Victoria, Canad)
Daniel Riesco (U. Nacional de San Luis, Argentina)
Ernesto Cuadros-Vargas (SPC, Per)
Ernesto Pimentel (U. de Mlaga, Espaa)
Esperanza Marcos (U. Rey Juan Carlos, Espaa)
Francisco Pinheiro (U. de Brasilia, Brasil)
Francisco Ruiz (U. Castilla-La Mancha, Espaa)
Gastn Mousques (U. ORT, Uruguay)
Gustavo Rossi (U. Nacional de La Plata, Argentina)
Isidro Ramos (U.Politcnica de Valencia, Espaa)
Jaelson Castro (U. F. de Pernambuco, Brasil)
Joao Falcao e Cunha (U. do Porto, Portugal)
Jorge Fernandes (U. F. Rio Grande do Norte, Brasil)
Julio C. Leite (PUC-Rio, Brasil)
Luca Cernuzzi (U. Catlica de Asuncin, Paraguay)
Mario Barbacci (U. Carnegie Mellon, SEI, US)
Mario Piattini (U. Castilla-La Mancha, Espaa)
Mauricio Marn (U. de Magallanes, Chile)
Miguel Katrib (U. de La Habana, Cuba)
Miguel Toro (U. de Sevilla, Espaa)
Nora Koch (U. de Munich, Alemania)
scar Pastor (U. Politcnica de Valencia, Espaa)
Pere Botella (U. Politcnica de Catalunya, Espaa)
Raul Monge (UTFSM, Valparaiso, Chile)
Revisores Adicionales
Flavia Linhalis (U. San Pablo, Brasil)
Jose Antonio Camacho Guerrero (U. San Pablo, Brasil)
Vicente Pelechano (U. Politcnica de Valencia, Espaa)
Juan Sanchez(U. Politcnica de Valencia, Espaa)
Joan Fons (U. Politcnica de Valencia, Espaa)
Manoli Albert (U. Politcnica de Valencia, Espaa)
Pedro Valderas (U. Politcnica de Valencia, Espaa)
Marta Ruiz (U. Politcnica de Valencia, Espaa)
Mara Jos Escalona, (U. de Sevilla, Espaa)
M de los A. Martn (U. Nacional de La Pampa, Argentina)
Guillermo Covella (U. Nacional de La Pampa, Argentina)
Paloma Cceres (U. Rey Juan Carlos, Espaa)
Jose M Cavero (U. Rey Juan Carlos, Espaa)
Beln Vela (U. Rey Juan Carlos, Espaa)
Amador Durn (U. de Sevilla, Espaa)
Bruno Glez. Baixauli (U. de Valladolid, Espaa)
Marta Blaquier, (U. de la Habana)
Marcello Visconti (U. Tcnica Federico Santa Mara, Chile)
Hernn Astudillo (U. Tcnica Federico Santa Mara, Chile)
Henriqueta Nvoa (U. do Porto, Portugal)
Jorge Pinho de Sousa (U. do Porto, Portugal)
Miguel Gonalves (U. do Porto, Portugal)
Lucia R. D. Bastos (U. F. de Pernambuco, Brasil)
Carla T. L. L. Silva (U. F. de Pernambuco, Brasil)
Comit de Conduccin
Ernesto Pimentel (U. de Mlaga, Espaa)
Luca Cernuzzi (U. Catlica. de Asuncin, Paraguay)
Mario Piattini (U. Castilla-La Mancha, Espaa)
Miguel Katrib (U. de La Habana, Cuba)
scar Pastor (U. Politcnica de Valencia, Espaa)
Comit de Organizacin
Presidencia
Ernesto Cuadros-Vargas (SPC, Per)
Co-Presidencia
Percy Huertas Niquen
Miembros
Hector Velarde
Guillermo Caldern
Luis Diaz Basurco
Eduardo Tejada Gamero
Nelly Condori-Fernndez
Joan Fons
Juan Carlos Gutierrez Cceres
Nicols C. A. Antezana Abarca
Gustavo Salazar
Guillermo Paredes
Nestor J. Linares
Jordan Start Rosas Zegarra
Alberto Borda Daz
Oscar Guillermo Arce Abarca
Mauricio Lpez Beln
Organizacin
Sociedad Peruana de Computacin (SPC) http://www.spc.org.pe
Universidad Nacional de San Agustn http://www.unsa.edu.pe
Auspicios
Universidad Catlica de Santa Mara http://www.ucsm.edu.pe
Universidad Catlica San Pablo http://www.ucsp.edu.pe
Sociedad Peruana de Computacin (SPC) http://www.spc.org.pe
CYTED http://www.cyted.org
Centro Latinoamericano de Estudios en Informtica (CLEI) http://www.clei.cl
Colaboradores
GUPAC del Per S.A.C. http://www.gupac.com.pe
Indice general
1. Prologo 3
2. Comite de Programa 4
3. Comite de Organizacion 5
T1 Programacion en la web con la tecnologa .NET
Miguel Katrib . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Tutoriales 4
T2 Desarrollo de Aplicaciones Distribudas con J2EE
Raul Monge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
T3 Adequando o RUP e o XP para o desenvolvimento de aplicacoes WEB
Alexandre Marcos Lins de Vasconcelos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
T4 Criterios y Metodos para Evaluar Calidad en Aplicaciones Web
Luis Olsina . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
T5 From conceptual modeling to the semantic web: an Object-Oriented Approach
Oscar Pastor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
T6 Similarity Information Retrieval
Ernesto Cuadros-Vargas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Lista de Artculos 10
3.1. Utilizacion de Tecnicas Basadas en la Logica Borrosa para Predecir el Tiempo
de Entendimiento de los Diagramas de Estados UML
Jose A. Cruz-Lemus; Marcela Genero; Jose A. Olivas; Francisco P. Romero; Mario Piat-
tini; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2. Sistematizacao da Integracao de Servicos na Web
Joel da Silva; Valeria C. Times; Roberto S. M. Barros; . . . . . . . . . . . . . . . . . . . 22
3.3. Componentes de Software para a Construcao de Ambientes de Simulacao de
Redes de Computadores - Implementacao e Validacao
Flavio Goncalves da Rocha; Maria Izabel Cavalcanti Cabral; . . . . . . . . . . . . . . . . 28
3.4. Experimento con Profesionales para Evaluar la Calidad de los Modelos de
Procesos Software
Felix Garca; Francisco Ruiz; Mario Piattini; . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.5. Apoio a Documentacao em um Ambiente de Desenvolvimento de Software
Andrea O. Soares; Vanessa B. Nunes; Ricardo A. Falbo; . . . . . . . . . . . . . . . . . . . 50
3.6. Modelagem Organizacional Utilizando Ontologias e Padroes de Analise
Renata I. Cota; Credine S. Menezes; Ricardo A. Falbo; . . . . . . . . . . . . . . . . . . . 56
3.7. Analise do Tempo de Navegacao na Composicao de um Modelo para Hiperm-
dia Adaptativa
Jacques N. C. Schreiber; Rolf Molz; Joao C. Furtado; Raul Sidnei Wazlawick; Silvio Etges;
Thiago Holanda; Janice Deters; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.8. An Ontology-based Environment to Data Integration
Agustina Buccella; Alejandra Cechich; Nieves Brisaboa; . . . . . . . . . . . . . . . . . . . 79
3.9. Proceso de Medicion de Funcionalidad en la Elicitacion de Requerimientos
Mabel Bertolami; Alejandro Oliveros; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.10. ArgoCASEGEO - Uma Ferramenta CASE de Codigo-aberto para o Modelo
UML-GeoFrame
Jugurta Lisboa Filho; Maurcio Fidelis Rodrigues Junior; Jaudete Daltio; . . . . . . . . . 103
1
2 IDEAS2004 Arequipa Peru
3.11. Una Experiencia en la Validacion Teorica de Metricas de Software

Nelly Condori-Fernandez; Silvia Abrahao; Oscar Pastor; . . . . . . . . . . . . . . . . . . 114
3.12. Del Modelo de Casos de Uso al Modelo de Navegacion
Paloma Caceres; Valeria de Castro; Esperanza Marcos; Cesar Acuna; . . . . . . . . . . . 124
3.13. Estimacion y Planificacion de Proyectos Software con Ciclo de Vida Iterativo-
Incremental y empleo de Casos de Uso
Jose Antonio Pow-Sang Portillo; Ricardo Imbert Paredes; . . . . . . . . . . . . . . . . . . 136
3.14. Composicion y Coordinacion de Componentes mediante Conectores y WebSer-
vices
Miguel Katrib; Jose Luis Pastrana; Ernesto Pimentel; . . . . . . . . . . . . . . . . . . . . 142
3.15. An Academic Web-based Agenda and Its Engineering Process
Renata Fortes; Andre Freire; Victor Vieira; Debora Paiva; . . . . . . . . . . . . . . . . . 151
3.16. Generacion Automatica de Aplicaciones basadas en Componentes a partir de
Bases de Datos
Ignacio Garca; Macario Polo; Mario Piattini; . . . . . . . . . . . . . . . . . . . . . . . . 157
3.17. Elicitacao de Requisitos para o Desenvolvimento de uma Ferramenta de Apoio
a Metodologia de Elicitacao de Requisitos de Software Baseada na Teoria da
Atividade (META)
Simone Franceto; Luiz Eduardo Galvao Martins; . . . . . . . . . . . . . . . . . . . . . . . 169
3.18. Integrando BON con Alloy
Pablo Castro; Gabriel Baum; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
3.19. Measuring Component Adaptation
Antonio Brogi; Carlos Canal; Ernesto Pimentel; . . . . . . . . . . . . . . . . . . . . . . . 182
3.20. Analisis de Restricciones de Integridad en el Nivel Conceptual
M.A. Pastor; M. Celma-Gimenez; L. Mota-Herranz; . . . . . . . . . . . . . . . . . . . . . 194
3.21. Experiencias no Desenvolvimento e Integracao de um Gerenciador de Alertas
para Ambientes de Ensino a Distancia na Internet
Daniela Leal Musa; Gustavo de Abreu Sisson; Jose Palazzo Moreira de Oliveira; . . . . . 206
3.22. On Evolution of XML Workflow Schemata
Fabio Zschornack; Nina Edelweiss; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
3.23. Desarrollo de Sistemas Domoticos Guiado por Modelos
Javier Munoz; Joan Fons; Vicente Pelechano; Oscar Pastor; . . . . . . . . . . . . . . . . 228
3.24. BMW - A Systematic Process for Business Modelling Activity
Ana Alice do N. S. Monteiro; Alexandre Marcos Lins de Vasconcelos; . . . . . . . . . . . 234
3.25. Un Framework para la Implementacion de Relaciones de Asociacion Agrega-
cion y Composicion en UML
Marta Ruiz; Manoli Albert; Victoria Torres; Vicente Pelechano; . . . . . . . . . . . . . . 245
3.26. Gerencia de Conhecimento na Engenharia de Requisitos
Denise F. Togneri; Ricardo de A. Falbo; Credine S. de Menezes; Bernardo S. Wernesback;
Diogo Q. de Almeida; Marina F. Cortes; . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
3.27. Metodos Heursticos para el Analisis de Clasificacion en Sitios E-Commerce
Beatriz Bernabe Loranca; Luis Olsina; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
3.28. Una Aproximacion Lingustica de Ingeniera de Requisitos para OO-Method
Isabel Daz; Oscar Pastor; Lidia Moreno; Alfredo Matteo; . . . . . . . . . . . . . . . . . . 270
3.29. ArcADe: Um Modelo de Processo para Analise e Projeto Baseado em Arqui-
tetura de Software
Marco Antonio Fagundes de Moraes; Alexandre Marcos Lins de Vasconcelos; . . . . . . . 282
3.30. Metaprogramming in .Net
Miguel Katrib; Mario del Valle; Iskander Sierra; Thaizel Fuentes; . . . . . . . . . . . . . 294
3.31. Integrando Gestao do Conhecimento e Modelagem Organizacional
Francisco dos Santos Carvalho; Jaelson F. B. Castro; . . . . . . . . . . . . . . . . . . . . 308
3.32. Ferramenta de Inspecao de Requisitos de Software em Ambiente Web
Gustavo A. Gonzalez Briones; Tereza Goncalves Kirner; . . . . . . . . . . . . . . . . . . 320
3.33. Adaptacao de um Processo de Desenvolvimento para Fabricas de Software
Distribudas
Helena M. Marques; Rodrigo T. Ramos; Ismenia G. L. Silva; . . . . . . . . . . . . . . . . 326
3.34. Un Metamodelo para Catalysis basado en el Metamodelo de UML
Gabriela A. Perez; Roxana S. Giandini; Claudia F. Pons; . . . . . . . . . . . . . . . . . . 337
3.35. GOS: Especificacao de um Mecanismo de Busca e Recuperacao de Componen-
tes
Alessandreia de Oliveira; Regina M.M. Braga; Fernanda Campos; Marta Mattoso; . . . . 349
IDEAS2004 Arequipa Peru 3
3.36. Propuesta de un Proceso para el Analisis de una Lnea de Productos dentro

del Contexto del Proceso ARCA-LP
Julio Ariel Hurtado Alegra; Juan Carlos Vidal Rojas; . . . . . . . . . . . . . . . . . . . . 360
3.37. Aplicacion de una Metodologa de Ingeniera de Requisitos a un Caso Real
Alberto Restrepo; Monica Henao; Raquel Anaya; . . . . . . . . . . . . . . . . . . . . . . . 366
3.38. Functional Entity-Relationship Modeling
Simone Santini; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
3.39. Propuestas para Generacion de Codigo y Diseno de una Herramienta CASE
Usando Tecnicas de Bootstrapping
Jorge Jmenez C.; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Lista de Autores 391
Artculos por pas 395

Tutorial: Programacion en la web con la tecnologa .NET

Ponente: Dr. Miguel Katrib
e-mail: mkm@matcom.uh.cu
Universidad de la Habana Cuba
Resumen
De los mainframes a los WEB Services. Que son los WEB Services? Que aporta .NET para el des-
arrollo de WEB Services? Que es ASP .NET? El .NET Framework. Fortalezas de .NET para desarrollar
componentes de software para la WEB. Estructura de una componente .NET. Seguridad de componentes.
El Common Language Runtine. Que es ejecucion bajo codigo administrado? Programacion en .NET. El
sistema de tipos en .NET. Metadatos y Metaprogramacion.
Biografa
Profesor Titular del Dpto. de Ciencia de la Computacion de la Universidad de la Habana y jefe del
grupo de investigacion en programacion y tecnologas orientadas a objeto de la Facultad de Matematica
y Computacion de la Universidad de la Habana. VicePresidente de la Sociedad Cubana de Matematica y
Computacion y miembro del tribunal nacional de doctorado en Matematica y Computacion de la Repu-
blica de Cuba. Autor de tres libros de texto en lenguajes y tecnologas de programacion y de numerosos
artculos publicados en revistas y proceedings de eventos nacionales e internacionales. Miembro del Comi-
te de Programa de varios eventos internacionales. Conferencista e investigador invitado de universidades
de Espana, Italia y Latinoamerica. Sus areas actuales de interes son los lenguajes y metodologas de
programacion, la tecnologa orientada a objetos, ingeniera del software, integracion del modelo orientado
a objetos y los sistemas concurrentes y distribuidos, programacion para el WEB.
Tutorial: Desarrollo de Aplicaciones Distribudas con J2EE

Ponente: Dr. Raul Monge
e-mail: rmonge@inf.utfsm.cl
Universidad Tecnica Federico Santa Mara, UTFSM Chile
Resumen
Los sistemas de informacion y las aplicaciones informaticas de las organizaciones, especialmente con el
espectacular desarrollo de Internet y de las redes de comunicacion, estan actualmente evolucionando hacia
una mayor integracion y capacidad de interaccion. En esta perspectiva, los avances en la investigacion en
el area de los sistemas distribuidos de computacion en las ultimas dos decadas han sido decisivos para la
maduracion de nuevas tecnologas que faciliten la distribucion y la interoperabilidad de aplicaciones. Una
de las tecnologas emblematicas es Java 2 Enterprise Edition (J2EE) de Sun Microsystems, que ha definido
estandares para el rapido desarrollo de una industria de software orientada a dar soluciones tecnicas a
las organizaciones en el problema del desarrollo de sistemas de software que deben ser desplegados en
ambientes distribuidos.
El objetivo de esta conferencia es entregar una vision tecnica sobre el rol y los componentes que
involucra la tecnologa J2EE en el desarrollo de aplicaciones empresariales distribuidas.
Biografa
Raul Monge es Doctor en Ingeniera de la Universitat Erlangen-Nurnberg (Alemania) y Ingeniero Civil
Electronico de la Universidad Tecnica Federico Santa Mara, UTFSM (Chile). Actualmente es academico
de jornada completa en el Departamento de Informatica de la UTFSM, donde es su actual Director. Es
miembro de la Sociedad Chilena de Ciencia de la Computacion, ACM e IEEE. Participo en el proyecto
Iberoamericano CYTED-WEST. Ha sido invitado y conferencista en diversos pases tales como Alemania,
Espana, Argentina, Colombia y Paraguay. A fines de los anos 80 participo en un proyecto aleman sobre
el desarrollo de tecnicas, metodos y herramientas para el desarrollo de sistemas operativos distribuidos.
Su area de interes son los sistemas distribuidos, tanto del punto de vista de los algoritmos como tambien
las tecnicas, metodos y arquitecturas necesarias para el desarrollo de servicios y aplicaciones distribuidas.
Tutorial: Adequando o RUP e o XP para o desenvolvimento de

aplicacoes WEB
Ponente: Dr. Alexandre Marcos Lins de Vasconcelos
e-mail: amlv@cin.ufpe.br
Centro de Informatica da Universidade Federal de Pernambuco
Brasil
Resumen
Existem atualmente diversas metodologias de desenvolvimento de software, e entre elas destacam-
se o RUP (Rational Unified Process) e o XP (eXtremme Programming). Ambas sao metodologias de
proposito geral e, portanto, precisam ser adequadas a uma organizacao ou a um domnio especfico,
antes que possam ser utilizadas. Neste sentido, nenhuma das duas metodologias foram concebidas para
tratar especificamente de todos os aspectos relativos ao desenvolvimento de aplicacoes Web. Por exemplo,
nenhuma das duas da enfase ao projeto visual e navegacional das interfaces graficas.
O objetivo deste seminario e discutir os principais problemas encontrados em ambas as metodologias
no que diz respeito ao desenvolvimento de aplicacoes Web e, com base nestes problemas, apresentar uma
adaptacao para cada uma das metodologias, buscando solucionar os problemas encontrados.
Biografa
Graduado em Ciencia da Computacao pela Universidade Federal de Pernambuco em 1987. Mestre
em Ciencia da Computacao pela Universidade Federal de Pernambuco em 1989. Doutor em Ciencia da
Computacao pela University of York, Inglaterra, 1993. Prof. Adjunto do Centro de Informatica da Univer-
sidade Federal de Pernambuco desde 1995. Consultor em Processos e Qualidade de Software pela Quality
Software Processes desde 1999. Ja foi Programador/Analista de Sistemas do Nucleo de Processamento
de Dados da Universidade Federal de Pernambuco entre 1985 e 1989 e entre 1993 e 1995.
Tutorial: Criterios y Metodos para Evaluar Calidad en

Aplicaciones Web
Ponente: Dr. Luis Olsina
e-mail: olsinal@ing.unlpam.edu.ar
Universidad Nacional de La Pampa Argentina
Resumen
Los desarrollos Web son cada vez mas complejos y, ademas, estan creciendo rapidamente, entre ellos
las aplicaciones de software centrados en la Web. Este tipo de sitios y aplicaciones Web (WebApps) puede
ser un sistema de publicacion de catalogos con logica de comercio electronico (e-commerce), o un sistema
de ensenanza y aprendizaje colaborativo (e-learning), entre otros, proveyendo funcionalidad que esta
mas cercana a una implementacion de software cliente/servidor tradicional que a un sitio Web estatico
orientado a la documentacion. Sin embargo, procesos y metodologas de evaluacion y aseguramiento de
calidad que promuevan la comprension y la mejora de la calidad de las WebApps, no estan acompanando
este rapido crecimiento observado. El objetivo de esta conferencia consiste en ilustrar un conjunto de
criterios, metodos y estrategias de evaluacion que contribuyan a determinar y mejorar la calidad de las
WebApps para diversos dominios.
Biografa
Luis Olsina, es Doctor en Ciencias (Area Ingeniera de Software en la Web), por la UNLP, Argentina,
Magister en Ingeniera de Software (UNLP), Licenciado en Sistemas de Informacion, UNLu y Analista
Programador por UNLPam. Es director de proyectos de I+D, e investigador en el area de Evaluacion y
Metricas Web, y participa en el proyecto Iberoamericano CYTED-WEST. Es autor de la metodologa
Web QEM. Ha publicado mas de 40 papers en journals y actas de congresos nacionales e internacionales.
Ha dictado conferencias y cursos sobre el area en diversos pases. Ha participado como chair en Congresos
y Workshops Internacionales como WE en ICSE 2002, IWWOST en ECOOP02, ICWE03 y regionales
como ICWE02, entre otros. Luis Olsina es miembro de la IEEE, de la IEEE Computer Society y SADIO.
Tutorial: From conceptual modeling to the semantic web: an

Object-Oriented Approach
Ponente: Dr. Oscar Pastor
e-mail: opastor@dsic.upv.es
Universidad Politecnica de Valencia Espana
Resumen
Para construir una Aplicacion Web correcta, es necesario representar adecuadamente los requisitos del
cliente, incluyendo aquellos especficos de ambientes Web. El proceso de captura de requisitos debe de con-
ducir a la obtencion de un Esquema Conceptual en el quede especificado de forma precisa no solo estatica
y dinamica (aspectos presentes en el modelado de aplicaciones convencionales), sino tambien navegacion,
presentacion, personalizacion, etc (aspectos propios de aplicaciones hipermediales) En consecuencia, un
Esquema Conceptual para una Aplicacion Web debe de incluir en su expresividad de una forma homo-
genea todas esas primitivas conceptuales especficas de un ambiente web, que no estan presentes en los
enfoques convencionales de modelado conceptual. Estos patrones conceptuales seran analizados en esta
charla, a la vez que se estudiara como usarlos adecuadamente en un proceso de produccion de software
moderno que satisfaga las restricciones de calidad exigibles a todo producto software. Finalmente, se de-
fendera la idea central de que la generacion de Aplicaciones Web a partir de Esquemas Conceptuales en
un marco orientado a objetos permite abordar metodologicamente los problemas asociados al uso correcto
de la nocion de Web Semantica.
Biografa
Prof. Dr. Oscar Pastor. He holds the chair of Computation and Information Systems, at the Valencia
University of Technology (Spain). PhD in 1992, and Former researcher in HP Labs, he is currently full
professor at the Valencia University of Technology. Author of over 100 research papers in conference
proceedings, journals and books, received numerous research grants from public institutions and private
industry. Research activities focus on web engineering, object-oriented conceptual modelling, requirements
engineering, information systems and model-based software production. Leader of the project, undertaken
since 1996 by the Valencia University of Technology and CONSOFT S.A., that has originated an advanced
Model Driven Development tool that produces a final software product starting from a Conceptual Schema
where the system requirements are captured. Within this tool scope, he is responsible of the research
team working from the University on the improvement of the underlying framework, focusing on Business
Process Modeling, Web Technologies and how to use properly Software and Arquitectural Patterns to go
from the problem space to the solution space in an automated way.
Tutorial: Similarity Information Retrieval

Ponente: Dr. Ernesto Cuadros-Vargas
e-mail: ecuadros@spc.org.pe
Universidad Nacional de San Agustn Peru
Resumen
Similarity Information Retrieval (SIR) is a complex process that usually involves large and complex
Data Bases. Two groups of techniques are widely used for it, Self-Organizing Maps (SOM) and Spatial
Access Methods (SAM) and Metric Access Methods (MAM).
However, both groups of techniques present important drawbacks. Most of SOM make intensive use
of sequential comparison to find winner units. On the other hand, Access Methods do not take advantage
of knowledge generated by previous queries.
In order to overcome these problems, two novel techniques are presented to improve the SIR process.
Firstly, SOM was used jointly with SAM and MAM in order to improve SOM based systems, producing
two new families of techniques named SAMSOM and MAMSOM respectively.
Secondly, SAM and MAM themselves were improved by the creation of PMAM, a plug-in module
which is useful to take advantage of knowledge acquired by previous queries in order to speed up following
queries. The combination of PMAM jointly with SAM and MAM produced MAE+ and MAM+ families
of Access Methods.
As the main result, SAM-SOM and MAM-SOM families outperform considerably traditional SOM
based systems which normally need a long time for training.
Additionally, MAE+ and MAM+ families are capable of reducing gradually the number of operations
needed to answer a query, as new queries are introduced. This is possible because PMAM allows them to
take advantage of knowledge generated by successive queries.
Biografa
Prof. Dr. Ernesto Cuadros-Vargas received his PhD in Computer Science at the University of Sao
Paulo-Brazil. He is a founder member of Peruvian Computer Society (SPC) and he is currently President
of this organization. As part of his PhD studies Prof. Cuadros-Vargas has worked in common projects
with the Carnegie Mellon University-USA and the Technischen Universitat Berlin-Germany in 2001 and
2002 respectively. He is also representant of Peru at the Latinamerican Conference in Informatics (CLEI).
His main research areas are Similarity Information Retrieval, Access Methods and Neural Networks.
Utilizacin de Tcnicas Basadas en la Lgica Borrosa para Predecir

el Tiempo de Entendimiento de los Diagramas de Estados UML
Jos A. Cruz-Lemus, Marcela Genero, Jos A. Olivas,

Francisco P. Romero y Mario Piattini
Departamento de Informtica, Universidad de Castilla-La Mancha

Paseo de la Universidad, 4, 13071, Ciudad Real (Espaa)
{JoseAntonio.Cruz, Marcela.Genero, JoseAngel.Olivas, Mario.Piattini}@uclm.es
fpromero@soluziona.com
Resumen
En este trabajo se presenta una aplicacin de la lgica borrosa en el mbito de la prediccin en la
Ingeniera del Software. Concretamente se ha utilizado el Descubrimiento de Conocimiento Prototpico
Borroso para caracterizar los diagramas de estados UML de acuerdo a su facilidad de entendimiento,
partiendo de su complejidad estructural y tamao, expresadas mediante mtricas, y los Prototipos
Deformables Borrosos para obtener un modelo de prediccin del tiempo de entendimiento de los
diagramas de estados UML. El modelo obtenido es vlido en cierta medida- ya que el 75% de los
valores estimados tienen al menos un 70% de exactitud, aunque es necesario validarlo con datos
referentes a proyectos reales.
1. Introduccin.
En la Ingeniera del Software es bien sabido que las caractersticas que hacen a la calidad de los
sistemas orientados a objetos (OO), como la mantenibilidad, debe ser garantizada desde las etapas
iniciales de su ciclo de vida, centrndonos en lo modelos obtenidos en dichas etapas, ms an teniendo en
cuenta el gran auge que ha tenido en estos ltimos aos el desarrollo orientado a modelos (Model-Driven
Developement) [1] y la arquitectura basada en modelos (Model-Driven Architecture (MDA)) [19].
Utilizando UML en el desarrollo OO, se realizan una serie de diagramas que cubren tanto aspectos
estticos (diagramas de clases) como dinmicos (diagramas de casos de uso, diagramas de estados, etc.).
Para evaluar la calidad de tales diagramas de manera objetiva es necesario contar con medidas
cuantitativas que eviten sesgos en el proceso de evaluacin.
Existen varios trabajos sobre la medicin de la calidad de los diagramas de clases UML y de los
diagramas de casos de uso [15]. Sin embargo, apenas hay unas pocas referencias en la bibliografa sobre
mtricas para los diagramas de comportamiento, tales como los diagramas d estados, los diagramas de
secuencia, los diagramas de actividad, etc. Una de las primeras aproximaciones hacia la definicin de
mtricas para diagramas de comportamiento aparece en [11], donde se definen y aplican mtricas para
diagramas desarrollados con OMT (Object Modelling Technique) [22]. En [26] se definen medidas de
complejidad para modelos conceptuales OO dirigidos por eventos. As mismo, [9] y [26] sealan que la
definicin de mtricas para diagramas que capturen los aspectos dinmicos de los sistemas OO es un rea
relevante, un tanto descuidada en el mbito de la medicin del software. Este hecho nos motiv a definir
mtricas para los diagramas de comportamiento UML, comenzando con los diagramas de estados [20]. La
Tabla 1 muestra brevemente la definicin de cada una de dichas mtricas.
Tabla 1. Mtricas para diagramas de estados UML

Mtrica Definicin
NEntryA El nmero total de acciones de entrada, i.e., las acciones que se ejecutan cada
vez que se entra en un estado.
NExitA El nmero total de acciones de salida, i.e., las acciones que se ejecutan cada
vez que se sale de un estado.
NA El nmero total de actividades (do/activity) del diagrama.
Tamao NSS El nmero total de estados sencillos, considerando tambin los subestados
dentro de un estado compuesto.
NCS El nmero total de estados compuestos, i.e., aquellos que tienen subestados
anidados.
NE El nmero total de eventos.
NG El nmero total de condiciones de guarda.
NT El nmero total de transiciones considerando aquellas en la que el estado
origen es distinto al estado destino, las transacciones final e inicial, las auto-
Complejidad transacciones (el estado origen y el destino son el mismo) y las transacciones
estructural internas (aquellas que responden a un evento sin dejar el estado).
CC Complejidad Ciclomtica de McCabe [18] 1, definida como
|NSS-NT|+2
Nuestro enfoque sobre cmo la complejidad estructural y el tamao como atributos internos de los
diagramas de estados est potencialmente relacionada con su facilidad de entendimiento
(understandability) surgi a partir de trabajos similares realizados en el campo de la Ingeniera del
Software Emprica [8][16], en los cules esta propiedad se mostr como uno de los mayores
determinantes de caractersticas externas de la calidad, como la facilidad de entendimiento y de
mantenimiento.
Las mtricas presentadas en la Tabla 1 fueron validadas tericamente utilizando el marco basado en
propiedades de Briand et al. [6], obteniendo que las mtricas NEntryA, NExitA, NA, NSS, NCS, NE y
NG son mtricas de tamao y las mtricas NT y CC son mtricas de complejidad.
Como es bien sabido en el campo de la medicin del software, para que las mtricas que miden
atributos internos (tamao, complejidad, etc.) sean tiles, es necesario que sirvan para predecir algn
atributo externo de la calidad, como la facilidad de entendimiento.
Mediante un experimento controlado y su rplica [21] (que se detalla en la seccin 2), se ha encontrado
que de las mtricas que se haban propuesto para diagramas de estados UML, parecen estar fuertemente
correlacionadas con el tiempo de entendimiento de los mismos, las mtricas Nmero de Actividades
(NA), Nmero de Estados Simples (NSS), Nmero de Guardas (NG) y Nmero de Transiciones (NT).
Esto nos llev a pensar en la construccin de un modelo de prediccin de la facilidad de entendimiento de
diagramas de estados UML basado en los valores de estas mtricas. Para la construccin del modelo de
prediccin se han usado todas las mtricas, ya que se considera demasiado prematuro descartar alguna de
ellas.
Viendo los alentadores resultados obtenidos al aplicar el proceso de Descubrimiento de Conocimiento

Prototpico Borroso (DCPB) y Prototipos Deformables Borrosos para la construccin de modelos de
prediccin aplicados a diferentes dominios [24][13][14], se decidi usarlos para nuestro propsito. Para
no extendernos en demasa, no se explicarn en profundidad todos los pasos del proceso de prediccin,
aunque pueden encontrarse ms detalles en [23].
En nuestro caso, los principales objetivos del proceso de prediccin son:
1. La bsqueda y extraccin automtica de prototipos borrosos que caractericen los diagramas de

estados UML a travs de su facilidad de entendimiento, expresada a travs de la complejidad
estructural y el tamao de dichos diagramas. Esto se llevar a cabo mediante el proceso de
Descubrimiento de Conocimiento Prototpico Borroso (DCPB).
1A pesar de que el Nmero Ciclomtico de McCabe se defini para calcular la complejidad del cdigo, lo hemos adaptado para
medir la complejidad estructural de diagramas de estados en UML.
2. La obtencin de un modelo de prediccin del tiempo de entendimiento de los diagramas de estados

UML, llevando a cabo la deformacin de los prototipos borrosos previamente definidos.
El DCPB es una ampliacin del proceso clsico de KDD [12] que presenta como novedades la
incorporacin de conocimiento en diferentes puntos mediante decisiones del usuario o del experto y un
resultado preparado para generar unos prototipos conceptuales denominados Prototipos Deformables
Borrosos, basados en la idea de Categoras Prototpicas Borrosas [23][28]. La utilizacin de la Lgica
Borrosa permite conseguir estos resultados de forma ms comprensible y til para el posterior uso en la
prediccin; con ello, se permite evaluar situaciones nuevas a partir de dichos prototipos, establecer
predicciones en cuanto a situaciones reales y tambin tomar decisiones a partir de dichas predicciones.
Adems se utilizan otras tcnicas como el clustering borroso y las funciones de agregacin [10],
facilitando la generacin de modelos estructurados, significativos y fcilmente actualizables.
Los datos utilizados para la obtencin del modelo de prediccin se obtienen a partir de un experimento
controlado realizado con profesores y alumnos de la Ingeniera Informtica de la Universidad de Castilla-
La Mancha. Para validar dicho modelo se utilizan los datos obtenidos en una rplica de dicho
experimento realizado con otro grupo de alumnos.
Este trabajo est organizado de la siguiente manera: en la seccin 2 se presentan las fuentes de datos
que son los datos obtenidos en un experimento controlado y su rplica. A continuacin, en la seccin 3 se
describen las distintas etapas seguidas para obtener el modelo de prediccin, que consisten en el proceso
DCPB, el proceso de prediccin propiamente dicho y la validacin de dicho modelo. Finalmente, en la
seccin 4, se presentan las conclusiones y las lneas de investigacin que surgen a partir de ste trabajo.
2. Fuentes de datos
En esta seccin se describen un experimento controlado y su rplica, que se realizaron teniendo en

cuenta algunos consejos suministrados por expertos en la Ingeniera del Software Emprica
[7][17][25][27]. Los datos obtenidos en el experimento se utilizarn para definir los prototipos borrosos
del tiempo de entendimiento de los diagramas de estados UML y a partir de dichos prototipos construir un
modelo de prediccin del tiempo de entendimiento de los diagramas de estados UML (ver seccin 3).
Para validar dicho modelo se utilizarn los datos obtenidos en la rplica.
2.1. Primer experimento
2.1.1. Definicin del experimento
Utilizando la plantilla para definicin de objetivos que presenta el mtodo GQM (Goal-Question-
Metric) [2], el objetivo del experimento es el que detalla la Tabla 2
Tabla 2. Objetivo del experimento segn GQM

Analizar las mtricas de complejidad para diagramas de estados en UML
Con el propsito de evaluar
Con respecto a la capacidad de ser empleadas como indicadores de la facilidad de
entendimiento de los diagramas de estados en UML
Desde el punto de vista de los diseadores de SOO
En el contexto de estudiantes en el ltimo ao de la Ingeniera Informtica y profesores del rea
de Ingeniera del Software en el Departamento de Informtica en la
Universidad de Castilla-La Mancha
2.1.2. Planificacin
La planificacin incluye las siguientes actividades:
Seleccin del contexto. El contexto del experimento es un grupo relacionado con el rea de
Ingeniera del Software de la universidad, y por tanto el experimento se desarrolla en un ambiente
no industrial. Los sujetos son 11 estudiantes y 8 profesores. Los estudiantes estn matriculados en
ltimo curso de la Ingeniera Informtica en la Universidad de Castilla-La Mancha. Todos los
profesores pertenecen al rea de Ingeniera del Software. El experimento es especfico ya que se

centra en mtricas para capturar la complejidad de los diagramas de estados en UML. El
experimento se refiere a un problema real, es decir, qu indicadores pueden utilizarse para evaluar la
facilidad de entendimiento de los diagramas de estados en UML.
Seleccin de los sujetos. Se eligen los sujetos por conveniencia; son estudiantes y profesores con
suficiente experiencia en el diseo y desarrollo de sistemas orientados a objetos con UML.
Seleccin de las variables. La variable independiente es la complejidad de los diagramas de estados
en UML. La variable dependiente es la facilidad de entendimiento de los mismos.
Instrumentacin. Los objetos usados en el experimento son 20 diagramas de estados UML. La
variable independiente, se mide a travs de las mtricas presentadas en la Tabla 1. La variable
dependiente, se evala a partir del tiempo que cada sujeto emplea en contestar el cuestionario
asociado a cada diagrama (al que se denomina tiempo de entendimiento). Suponiendo que un
diagrama de estados es ms comprensible cuanto menor sea su tiempo de entendimiento.
Formulacin de hiptesis. Con el experimento se pretenden evaluar las siguientes hiptesis:
Hiptesis nula, H0: No existe correlacin significativa entre la complejidad estructural, el tamao
de los diagramas de estados en UML y el tiempo de entendimiento.
Hiptesis alternativa, H1: Existe correlacin significativa entre la complejidad estructural, el
tamao de los diagramas de estados en UML y el tiempo de entendimiento.
Diseo del experimento. Se elige un diseo intra-sujetos para el experimento, es decir, todos los
sujetos tienen que resolver todas las tareas propuestas en todos los cuestionarios. Los cuestionarios
se entregaron en distinto orden a cada sujeto y se recalc que deberan de resolverlos segn orden en
el que se le entregaba, para evitar efectos de aprendizaje.
2.1.3. Operacin
En esta fase se recogen los resultados, e incluye las siguientes actividades:
Preparacin. Cuando se hizo el experimento todos los estudiantes haban cursado 2 asignaturas de
Ingeniera del Software, en las que aprendieron en profundidad cmo construir sistemas OO con UML.
Los profesores tienen como mnimo 3 aos de experiencia en el diseo y desarrollo de sistemas OO
OO. Adems todos los sujetos recibieron una sesin intensiva de entrenamiento, previa a la realizacin
del experimento. Sin embargo ninguno conoca los aspectos que se trataban de estudiar, ni las hiptesis
establecidas. Se prepar el material que se entreg a los sujetos, consistente en un gua explicando la
notacin de los diagramas de estados en UML, y los 20 diagramas. Los diagramas se referan a
diversos universos de discurso, pero eran lo suficientemente generales como para ser fcilmente
comprendidos por los sujetos. La complejidad de cada diagrama es diferente ya que, como se puede
ver en la Tabla 3, se trat de cubrir un amplio rango de los valores de las mtricas. Cada diagrama iba
acompaado de un test que inclua un cuestionario para evaluar si los sujetos realmente entendan el
contenido de cada diagrama de estados UML. Cada cuestionario contena cuatro preguntas
conceptualmente similares y escritas en el mismo orden, y cada sujeto tena que anotar la hora a la que
comenzaba a responder el cuestionario y la hora a la que finalizaba. La diferencia entre esas dos
anotaciones es lo que se llama tiempo de entendimiento y se expresa en segundos.
Tabla 3. Valores de las mtricas para cada diagrama de estados UML usado en el experimento
Diagrama NEntryA NExitA NA NSS NCS NT NE NG McCabe

1 1 1 0 3 0 7 6 2 5
2 1 0 3 4 0 7 6 0 4
3 2 0 2 4 1 7 4 3 1
4 0 0 2 4 0 11 11 2 7
5 3 2 2 4 0 13 11 0 9
6 6 6 0 6 1 13 12 1 5
7 1 0 1 5 2 11 6 3 2
8 1 0 3 5 0 13 12 4 9
9 0 1 4 5 0 10 7 1 7
10 2 1 0 4 0 6 6 0 4
11 1 2 1 6 3 17 12 0 3
12 1 1 1 3 0 5 5 2 3
13 2 1 0 2 0 4 4 0 2
Diagrama NEntryA NExitA NA NSS NCS NT NE NG McCabe

14 1 1 2 3 0 8 8 0 5
15 1 0 4 9 1 13 11 4 3
16 0 0 5 9 0 24 22 1 16
17 2 0 1 5 1 8 6 2 2
18 2 0 1 12 0 24 23 2 13
19 0 1 0 2 0 6 5 0 4
20 0 0 0 5 1 12 11 0 7
Ejecucin. Se entreg a los sujetos el material descrito en el prrafo anterior y se les explic la manera
de proceder para realizar el experimento, esto es, cada sujeto tena que resolver el cuestionario por s
mismo y dispona de tiempo ilimitado. Se indic que disponan de un plazo de una semana, tras el cual
deberan entregar los cuestionarios resueltos. Pasados los 7 das se recogieron todos los cuestionarios
con las respuestas a las preguntas y los tiempos de entendimiento de cada diagrama. Somos
conscientes de que esto puede haber sesgado los resultados porque los sujetos no fueron supervisados,
hecho que se trat de mejorar en la rplica.
Validacin de datos. Se comprobaron todos los cuestionarios para ver si eran vlidos, y se descartaron
6 cuestionarios ya que su nivel de correccin (numero de preguntas contestadas bien/nmero de
preguntas contestadas) y completitud (numero de preguntas contestadas bien/nmero de preguntas
totales) era menor que 0,9.
2.2. Rplica del experimento

Las diferencias ms importantes entre el experimento y su rplica son:
Los sujetos fueron 24 estudiantes del tercer ao de la Ingeniera Informtica, que slo haban cursado
una asignatura de Ingeniera del Software, en la que aprendieron a disear software OO utilizando
UML. Esto significa que la experiencia de los sujetos es menor.
Los sujetos tenan que completar los tests solos y en no ms de dos horas. Cualquier duda podra ser
resuelta por la persona que coordinaba el experimento, lo que contribuy a controlar el plagio entre
los sujetos.
Se descartaron 55 diagramas porque su nivel de correccin y completitud eran menores que 0,9.
Como se mencion anteriormente los datos obtenidos en esta rplica se utilizarn para evaluar la
precisin del modelo de prediccin obtenido (ver seccin 3.5).
3. Construccin del modelo de prediccin del tiempo de entendimiento de los

diagramas de estados UML
Para construir el modelo de prediccin (utilizando los datos obtenidos en el experimento que se
describe en la seccin 2.1.) se llevaron a cabo dos procesos principales:
1. Proceso DCPB
- Transformacin de los datos
- Obtencin de prototipos utilizando tcnicas de clustering
- Definicin paramtrica de los prototipos
- Representacin borrosa de los prototipos
2. Proceso de prediccin
- Deformacin de los prototipos borrosos para predecir el tiempo de entendimiento de los
diagramas de estados UML.
- Validacin del modelo de prediccin
A continuacin se describe cmo se han llevado a cabo cada una de las etapas mencionadas
previamente.
3.1. Transformacin de los datos

Primeramente, fue necesario transformar los datos para que fueran vlidos para el proceso DCPB. Por
un lado, se obtuvo la tabla con los valores de las mtricas para diagramas de estados (ver Tabla 3). Por
otro, se obtuvo el tiempo de entendimiento para cada diagrama y cada sujeto. A partir de estos tiempos, se
obtuvieron los tiempos mnimo (TEMin), promedio (TEAvg) y mximo (TEMax) para cada diagrama
(ver Tabla 4).
Tabla 4. Tiempos obtenidos (en segundos) en el proceso de transformacin
Diagrama TEAvg TEMin TEMax Diagrama TEAvg TEMin TEMax

1 110,00 15 420 11 153,16 85 360
2 95,00 30 170 12 86,37 50 180
3 191,94 61 360 13 88,05 35 300
4 163,39 69 405 14 136,05 44 360
5 129,50 30 215 15 152,22 85 420
6 124,56 58 310 16 140,05 50 300
7 154,05 72 300 17 108,63 59 195
8 140,00 50 360 18 154,89 65 265
9 131,79 70 240 19 84,26 40 180
10 85,21 50 180 20 85,84 42 140
De esta manera se obtuvo una tabla con 20 filas y 4 columnas, asociada a la tabla que contiene los
valores de las mtricas para cada diagrama (ver Tabla 3).
3.2. Obtencin de los prototipos usando tcnicas de clustering

Con el objetivo de detectar las relaciones entre los diagramas de estados para ser capaces
posteriormente de determinar si tienen un tiempo de entendimiento bajo, medio o alto, se realiza un
proceso de clustering jerrquico (segn la tcnica de Emparrillados (Repertory Grids') [3]).
Se construy una matriz de similitud de 20 x 20 elementos cuyos valores en la diagonal representan los
grados de similitud entre los diagramas. Convirtiendo estos valores en porcentajes y desencadenando el
algoritmo de clustering jerrquico, se obtuvieron los resultados que se muestran en el dendrograma de la
Figura 1.
0%
34%
39%
45%
62%
A M B
67%
78%
84%
89%
100%
6 20 11 18 3 17 7 15 1 12 14 2 4 8 16 5 9 10 13 19
Figura 1. Resultados del clustering: (B: tiempo bajo de entendimiento,

M: tiempo medio de entendimiento, A: tiempo alto de entendimiento)
Una vez obtenidos los resultados del clustering, y con el conocimiento heurstico previo de tener tres
prototipos, se realiza un corte a una similitud inferior a un 55%. Con lo cual los diagramas se agrupan en
tres prototipos de acuerdo a los valores de las mtricas que reflejan su complejidad estructural y tamao,
como muestra la Tabla 5.
Tabla 5. Diagramas agrupados segn el prototipo al que pertenecen

Prototipos Diagramas
B: Tiempo Bajo de Entendimiento 10,13,19
M: Tiempo Medio de Entendimiento 1,2,4,5,8,9, 12,14,16
A: Tiempo Alto de Entendimiento 3,6,7,11,15,17,18,20
3.2. Definicin paramtrica de los prototipos

Considerando los prototipos de datos encontrados en la seccin anterior y sus valores de tiempos de
entendimiento mostrados en la Tabla 5, se obtuvo la definicin paramtrica de los prototipos, como
muestra la Tabla 6.
Tabla 6.Definicin paramtrica de los prototipos

A: T Alto de Entendimiento M: T Medio de Entendimiento B: T Bajo de Entendimiento
Medio 2 min. 15 seg. Medio 2 min. 5 seg. Medio 1 min. 25 seg.
Mximo 7 min. Mximo 7 min. Mximo 6 min.
Mnimo 42 seg. Mnimo 15 seg. Mnimo 35 seg.
3.3. Representacin borrosa de los prototipos

Los tres prototipos han sido representados como nmeros borrosos, los cuales permitirn obtener un
grado de pertenencia (entre 0 y 1) de un nuevo diagrama de estados con cada uno de ellos (ver
Figura 2).
Figura 2. Representacin borrosa de los prototipos
La utilizacin de nmeros borrosos triangulares permite que para la representacin de los mismos sea
nicamente necesario conocer su centro (ver Tabla 7) y el tamao de la base del tringulo (denominado a
y b en la Tabla 7).
Tabla 7. Definicin borrosa de los prototipos

Prototipos Diagramas a Centro b
B: Tiempo Bajo de Mantenimiento 10,13,19 0 0.08 0.74
M: Tiempo Medio de Mantenimiento 1,2,4,5,8,9,12,14,16 0 0.26 0.92
A: Tiempo Alto de Mantenimiento 3,6,7,11,15,17,18,20 0 0.34 1
La definicin formal de los prototipos en forma de nmeros borrosos se obtiene mediante la

x n x min
normalizacin, realizada de la siguiente manera x n =
'
, y la agregacin mediante la media
x max x min
de los datos de los valores de las mtricas.
3.4. Deformacin de los prototipos borrosos para predecir el tiempo de entendimiento de

los diagrama de estados UML
En esta seccin se muestra cmo predecir el tiempo de entendimiento para un nuevo diagrama de
estados. La idea general es que dados los valores de las mtricas de un nuevo diagrama de estados, las
definiciones paramtricas de los prototipos que tienen un grado de pertenencia distinto de cero, se adaptan
o deforman para predecir el tiempo de entendimiento de este nuevo diagrama de estados.
El proceso a llevar a cabo es el que sigue:
1. Normalizar los valores medidos por medio del ndice de normalizacin asociado al modelo de
prediccin obtenido. Se usa la misma frmula que en la definicin de los nmeros borrosos y con
los mismos coeficientes de mnimo y mximo.
2. Calcular la media de los valores previamente normalizados (a este valor se le llama X).
3. A partir del valor X se obtienes los grados de pertenencia a los prototipos representados por medio
de nmeros borrosos, de la siguiente manera:
X a pi
X > centrepi pi =
centrepi a pi
c pi X
X >= centrepi pi =
c pi centrepi
4. Para obtener el valor estimado del tiempo de entendimiento de un nuevo diagrama de estados, los
prototipos borrosos se deforman para considerar el grado de afinidad con todos los prototipos.
Aplicando el concepto de Prototipos Deformables Borrosos, definido en [23], la caracterizacin del
nuevo diagrama de estados propuesto puede describirse mediante la siguiente combinacin lineal:
Creal ( w1...wn ) =| pi (v1...vn ) |
Donde:
Creal Caso real propuesto.
(w1... wn) Parmetros que describen el caso real propuesto.
pi Grados de pertenencia con los Prototipos Deformables Borrosos distintos de 0.
(v1... vn) Parmetros de estos Prototipos Deformables Borrosos.
Utilizando los datos obtenidos en la rplica (ver seccin 2.2) se deforma el modelo de prediccin
para predecir el tiempo de entendimiento.
Se toma como caso de partida el diagrama n 16. Los valores de las mtricas para este diagrama se
muestran en la Tabla 8.
Tabla 8. Valores de las mtricas del diagrama 16
NEntryA NExitA NA NSS NCS NT NE NG McCABE

0 0 5 9 0 21 22 1 16
1. Primero se normalizan los valores de las mtricas, obteniendo los valores mostrados en la Tabla 9.
Tabla 9. Valores normalizados de las mtricas del diagrama 16

NEntryA NExitA NA NSS NCS NT NE NG McCABE
0 0 1 0,7 0 1 0,95 0,3 1
2. La media de los valores normalizados es X = 0.53.

3. Despus se calcula el valor de las afinidades a los prototipos, como se muestra en la Tabla 10.
Tabla 10. Valor de las afinidades de los prototipos

Prototipos Afinidades
Tiempo Bajo de Entendimiento 0
Tiempo Medio de Entendimiento 0.591
Tiempo Alto de Entendimiento 0.712
4. Y finalmente se calcula el tiempo medio correspondiente (Media Estimada) a la prediccin

realizando la combinacin lineal modificada de los dos prototipos ms afines explicada
anteriormente (ver Tabla 11).
Tabla 11. Combinacin lineal para el clculo de tiempos medios2

Media 2 min. 5 seg. 2 min. 15 sec. 2 min. 2 seg.
Mximo 0,591 / 2 7 min. + 0,712 7 min. = 7 min. 5 seg.
Mnimo 15 seg. 42 seg. 34 seg.
De esta manera se obtuvo la prediccin del tiempo de entendimiento para el diagrama 16. El resultado
de aplicar la deformacin de los prototipos a todos los diagramas se muestra en la Tabla 12.
Tabla 12. Datos de la validacin del modelo de prediccin
DIAGRAMA X Af (B) Af (M) Af (A) Valor Estimado Valor Real MRE

1 0,15 0,894 0,577 0,441 116,38 110,00 0,058
2 0,14 0,909 0,538 0,412 114,925 95,00 0,210
3 0,18 0,848 0,692 0,529 120,52 191,94 0,372
4 0,16 0,879 0,615 0,471 117,765 163,39 0,279
5 0,24 0,758 0,923 0,706 162,75 129,50 0,257
6 0,41 0,5 0,773 0,894 156,41 124,56 0,256
7 0,23 0,773 0,885 0,676 158,9375 154,05 0,032
8 0,34 0,606 0,879 1 177,875 140,00 0,271
9 0,23 0,773 0,885 0,676 158,9375 131,79 0,206
10 0,11 0,955 0,423 0,324 110,785 85,21 0,300
11 0,34 0,606 0,879 1 177,875 153,16 0,161
12 0,12 0,939 0,462 0,353 112,155 86,37 0,299
13 0,06 0,75 0,231 0,176 79,92 88,05 0,092
14 0,1 0,97 0,385 0,294 109,4 136,05 0,196
15 0,39 0,53 0,803 0,924 162,485 152,22 0,067
16 0,53 0,318 0,591 0,712 122,205 140,05 0,127
17 0,18 0,848 0,692 0,529 120,52 108,63 0,109
18 0,51 0,348 0,621 0,742 125,555 154,89 0,189
19 0,05 0,625 0,192 0,147 66,565 84,26 0,210
20 0,16 0,879 0,615 0,471 117,765 85,84 0,372
3.5 Validacin del modelo de prediccin
Las tcnicas ms utilizadas para la evaluar la exactitud de los modelos de prediccin son las siguientes
[20]:
Magnitud del Error Relativo (MRE).

Media de la Magnitud del Error Relativo (MMRE).
Mediana de la Magnitud del Error Relativo (MdMRE).
Prediccin a nivel n (Pred(n)).
2 En este caso dado que la suma de los grados de pertenencia es mayor que 1, utilizando heursticas provistas por el
experto, dividimos el grado de pertenencia del segundo prototipo ms afn por 2.
MRE se define como:

TiempoReal DeEntendimiento TiempoDeEntendimientoPredecido
MRE i =
TiempoReal DeEntendimiento
Donde i representa cada observacin para la cual se predice el tiempo de mantenimiento.
MMRE se calcula como la media de todos los MREs:

1 i =n TiempoReal DeEntendim iento TiempoDeEn tendimient oPredecido
MMRE =
n i 01 TiempoReal DeEntendim iento
La media tiene en cuenta el valor numrico de cada observacin en la distribucin de los datos, y es
sensitiva a valores individuales de prediccin con valor de MRE muy alto. Por ello, otra eleccin es usar
la mediana, que tambin es una medida de la tendencia central, pero menos sensible a valores extremos.
La mediana de los valores de MRE para i observaciones se denomina MdMRE.
Otro indicador comnmente usado es la Prediccin a nivel n, tambin conocido como Pred(n). Mide el
porcentaje de estimaciones que estn dentro de un n% de los valores reales. Segn algunas sugerencias
[20], 25% es un valor recomendable para n. Lo que significa que un buen modelo de prediccin tendr
una precisin del 75%.
Los valores de MRE obtenidos para cada diagrama se muestran en la Tabla 12. La magnitud media del
error en este experimento (MMRE) es 0.20. El valor de la mediana (MdMRE) es 0.20. El valor obtenido
para Pred(25%) es un 70%, lo que nos indica que un 75% de los valores obtenidos, posee una exactitud de
al menos el 70%.
En el grfico mostrado en la Figura 3 se pueden observar los valores medios procedentes de la

prediccin y los valores medios reales.
250
200
150 Real
100 Prediccin
50
0
1 3 5 7 9 11 13 15 17 19
Figura 3. Valores de la prediccin vs. valores reales
4. Conclusiones
En la Ingeniera del Software es ampliamente reconocido que las propiedades estructurales de los
diagramas estticos y dinmicos de UML pueden tener una gran influencia en la calidad del producto
software que finalmente se entrega. Por esa razn, la existencia de mtricas es crucial, ya que permiten
evaluar las propiedades estructurales de una manera cuantitativa y objetiva.
Con la hiptesis de que el tamao y la complejidad estructural de los diagramas de estados UML
pueden influenciar la facilidad de entendimiento (y por ende la facilidad de mantenimiento) de los
mismos, se defini un conjunto de mtricas [21].
La realizacin de un experimento controlado y su posterior rplica nos llev a la conclusin de que las
mtricas que cuentan el nmero de actividades (NA), el nmero de estados simples (NSS), el nmero de
guardas (NG) y el nmero de transiciones (NT) estn altamente correlacionadas con la facilidad de
entendimiento de los diagramas de estados UML.
As pues, el siguiente paso consista en la obtencin de un modelo de prediccin capaz de determinar a

priori el esfuerzo de entendimiento que supone cualquier diagrama de estados UML, en funcin de los
valores asociados a las mtricas previamente definidas.
En este trabajo se ha detallado la obtencin de dicho modelo de prediccin, basado en la utilizacin del
proceso denominado Descubrimiento de Conocimiento Prototpico Borroso (DCPB) y de los Prototipos
Deformables Borrosos. Validando el modelo de prediccin se lleg a la conclusin de que en cierta
medida- es un buen modelo, ya que ya que el 75% de los valores estimados del tiempo de
entendimiento tienen al menos un 70% de exactitud. Somos conscientes de que, como ocurre con la
mayora de modelos de prediccin, el modelo obtenido no es generalizable para cualquier diagrama, ya
que el modelo es dependiente de los datos que se utilizan para su construccin. De todas maneras, si una
empresa guarda en una base de datos los valores de las mtricas de los diagramas que va construyendo en
distintos proyectos, podra construir como demostramos en este artculo, un modelo ad hoc y de utilidad
para su empresa.
Los resultados obtenidos nos hacen pensar que las mtricas propuestas podran servir como
indicadores de la facilidad de entendimiento de los diagramas de estados UML, lo que ser de gran
utilidad a la hora de mantener tales diagramas. Tambin dichas mtricas pueden servir a los diseadores
para comparar distintas alternativas de diseo.
Aunque los resultados son alentadores, somos conscientes de que se debe mejorar nuestro es estudio en
dos sentidos:
1) Con respecto a los datos utilizados

2) Con respecto a la tcnica utilizada para construir el modelo de prediccin
Por ello, por un lado debemos replicar el experimento con profesionales y adems ver la utilidad de las
mtricas en proyectos reales. Tambin considerar, en la experimentacin futura, no slo la facilidad de
entendimiento, sino otras caractersticas que influyen en el mantenimiento, como la facilidad de anlisis y
modificacin. En lo que se refiere al modelo de prediccin, existen ciertos aspectos que mejorar. La
utilizacin de algoritmos como el Fuzzy C-Means [4], las Redes de Kohonen Borrosas [5] o algoritmos de
soft-clustering en general, permitiran incrementar la potencia en la resolucin de problemas. Estos
algoritmos podran hacer que el clustering y la construccin del modelo de prediccin se pudieran realizar
de una sola vez, tomando las decisiones sobre el nmero de prototipos antes de su realizacin. Adems la
potencia que aportan estos algoritmos posibilita una mejor manipulacin de grandes volmenes de datos.
Agradecimientos
Este trabajo de investigacin es parte del proyecto MESSENGER (PCC-03-003-1) financiado por la
Consejera de Ciencia y Tecnologa de la Junta de Comunidades de Castilla - La Mancha y del proyecto
CALIPO, financiado por la Direccin General de Investigacin del Ministerio de Ciencia y Tecnologa
(TIC2003-07804-C05-03)
Referencias
[1] Atkinson C. and Khne T. (2003). Model-Driven Development: A Metamodeling Foundation. IEEE Software
20(5), 36- 41.
[2] Basili, V. R., Caldiera, G. y Rombach, H. D. (1994). Goal Question Metric Paradigm. Encyclopedia of
Software Engineering, vol. 1. John Wiley & Sons, 528-532.
[3] Bell R. (1990). Analytic Issues in the Use of Repertory Grid Technique. Advances in Personal Construct
Psychology 1, pp. 25-48.
[4] Bezdek J., Hathaway R., Sabin M., Tucker W. (1987). Convergence Theory for Fuzzy c-Means
Counterexamples and Repairs. IEEE Trans Syst., Man and Cybern. SMC-17 (5), pp. 873 - 877.
[5] Bezdek J., Tsao E., Pal N. (1992). Fuzzy Kohonen Clustering Net-works. IEEE International Conference on
Fuzzy Systems. San Diego, pp. 1035-1043.
[6] Briand, L., Morasca, S., Basili, V. (1996) Property-based software engineering measurement. IEEE
Transactions on Software Engineering, 22 (1) pp. 68-85
[7] Briand L., Arisholm S., Counsell F., Houdek F., Thvenod-Fosse P. (1999). Empirical Studies of Object-
Oriented Artifacts, Methods, and Processes: State of the Art and Future Directions. Empirical Software
Engineering, 4(4), pp. 387-404.
[8] Briand L., Bunse C., Daly J. (2001). A Controlled Experiment for evaluating Quality Guidelines on the
Maintainability of Object-Oriented Designs. IEEE Transactions on Software Engineering, 27(6), pp. 513-530.
[9] Brito e Abreu F., Zuse H., Sahraoui H. and Melo W. (1999). Quantitative Approaches in Object-Oriented
Software Engineering. ECOOP99 Workshops, LNCS 1743, A. Moreira and S. Demeyer (eds). Springer-Verlag.
pp. 326-337.
[10] Castro J., Trillas E., Zurita J. (1998). Non-monotonic Fuzzy Reasoning. Fuzzy Sets and Systems 94, North
Holland, pp. 217 - 225.
[11] Derr, K. (1995). Applying OMT. SIGS Books, Prentice Hall. New York.
[12] Fayyad U., Piatetsky-Shapiro G., Smyth P. (1996). The KDD Process for Extracting Useful Knowledge from
Volumes of Data. Communications of the ACM, 39(11), pp. 27 - 34.
[13] Genero M., Olivas J., Piattini M., and Romero F. (2001). Using metrics to predict OO information systems
maintainability, CAISE 2001, Lecture Notes in Computer Science, 2068, Interlaken, Switzerland, 388-401.
[14] Genero M., Piattini M., Calero C. (2002). An study to validate metrics for class diagrams. Jornadas
Iberoamericanas de Ingeniera de Requisitos y Ambientes de Software (IDEAS2002), La Habana (Cuba), pp. 226-
235.
[15] Genero M., Piattini M. and Calero M. (Eds.) Metrics For Software Conceptual Models. Imperial College Press,
UK, 2004.
[16] Harrison R., Counsell S., Nithi R. (2000). Experimental Assessment of the Effect of Inheritance on the
Maintainability of Object-Oriented Systems, The Journal of Systems and Software, 52, 173-179.
[17] Kitchenham B., Pflegger S., Pickard L., Jones P., Hoaglin D., El-Emam K. y Rosenberg J. (2002). Preliminary
Guidelines for Empirical Research in Software Engineering. IEEE Transactions of Software Engineering 28(8),
pp. 721-734.
[18] McCabe, T. (1976). A Complexity Measure. IEEE Transactions on Software Engineering. Vol. 2. N4, pp.
308-320.
[19] MDA- The OMG Model Driven Architecture (2002). Available: http://www.omg.org./mda/, August 1st, 2002.
[20] Mendes E., Watson I., Triggs C., Mosley N. y Counsell S. (2002). A comparison of development effort
estimation techniques for web hypermedia applications. Eight IEEE Symposium of Software Metrics
(METRICS02). IEEE Computer Society Press.
[21] Miranda D., Genero M. y Piattini M. (2003). Empirical validation of metrics for UML statechart diagrams.
Fifth International Conference on Enterprise Information Systems (ICEIS 03), 1, pp. 87-95.
[22] Object Management Group (2001). UML Revision Task Force. OMG Unified Modeling Language Specification,
v. 1.4, document formal/01-09-67.
[23] Olivas J. (2000). Contribucin al Estudio Experimental de la Prediccin basada en Categoras Deformables
Borrosas, Tesis Doctoral, Universidad de Castilla La Mancha, Espaa.
[24] Olivas J., Romero F. (2000). FPKD. Fuzzy Prototypical Knowledge Discovery. Application to Forest Fire
Prediction. Proceedings of the SEKE'2000, Knowledge Systems Institute, Chicago, Ill. USA, pp. 47 - 54.
[25] Perry D., Porter A., Votta L. (2000). Empirical Studies of Software Engineering: A Roadmap. Future of
Software Engineering. Ed:Anthony Finkelstein, ACM, pp. 345-355.
[26] Poels, G. and Dedene, G. (2000). Measures for Assessing Dynamic Complexity Aspects of Object-Oriented
Conceptual Schemes. Proceedings of 19th International Conference on Conceptual Modelling (ER 2000), pp.
499-512.
[27] Wohlin C., Runeson P., Hst M., Ohlson M., Regnell B., Wessln A. (2000). Experimentation in Software
Engineering: An Introduction, Kluwer Academic Publishers.
[28] Zadeh, L. A. (1982). A note on prototype set theory and fuzzy sets. Cognition 12, pp. 291- 297.
Sistematizao da Integrao de Servios na Web
J. Silva, V. C. Times, R. S. M. Barros

Centro de Informtica - Universidade Federal do Pernambuco (UFPE)
Caixa Postal: 7851, CEP:50732-970 - Recife - PE - Brasil
{js,vct,roberto}@cin.ufpe.br
Abstract
Service integration over the Web is not an easy task, as these services are supposed to work in a synchronized manner
to gain satisfactory results. This process implies in the development of a software module that takes into account the users
needs, some integration requirements and many other aspects related to the traditional software development process.
Considering the importance of the service integration process systematization, we propose in this paper a means of
systematizing the life cycle of service integration over the Web. Finally, a case study, regarding to analytical and
geographical services integration on the Web, is presented to validate the proposed ideas.
1. Introduo
Um dos grandes desafios enfrentados pela comunidade de pesquisa em Tecnologia da Informao a integrao de
servios [9]. Existem atualmente inmeros servios, que muitas vezes precisam interagir a fim de produzir determinado
resultado. A Internet pode ser vista como um ambiente dinmico com uma grande coleo heterognea de servios e
arquiteturas. Com o aumento da quantidade de servios para armazenamento, anlise e manipulao de informaes, a
integrao e o reuso desses servios seria muito proveitoso. Pode-se dizer que a integrao de servios uma tarefa
complexa [8] pois, quando pretendemos integrar servios, temos que levar em conta que eles precisaro trabalhar em
conjunto, de forma sincronizada, por um determinado perodo de tempo, a fim de processar uma requisio que lhes foi
enviada e apresentar o resultado desse processamento. Dentre as dificuldades enfrentadas na integrao de servios,
podemos citar: (1) a falta de informaes suficientes de algum dos servios, por conta de uma descrio inicial do servio
incompleta e em algumas vezes inexistente; (2) componentes da integrao que no se comportam de acordo com a
expectativa inicial; (3) o surgimento de novos componentes, provendo novas oportunidades para o sistema.
Com base no Modelo Cascata [19, 26, 14] de desenvolvimento de software, e com intuito de sistematizar o ciclo de
vida do processo de integrao de servios na Web, tomamos como ponto de partida alguns pontos apresentados em [8],
sugerimos uma especializao do modelo cascata para ser utilizado no processo de integrao de servios na Web. Essa
especializao contempla uma srie de etapas, com atividades predefinidas, visando sistematizar o processo de integrao,
e podendo ser utilizado como um guia durante todo ciclo de vida do processo de integrao de servios na Web.
Vale salientar que poderiam ser utilizados outros modelos ao invs do cascata, para sistematizar o ciclo de vida do
processo de integrao de servios na Web, tais como o espiral, o evolucionrio, entre outros [19, 26]. No entanto, optou-
se por pelo modelo cascata pelo fato de que nele, o progresso pode ser medido, sendo que os artefatos produzidos em cada
fase so evidncias tangveis desse progresso, sem falar que a documentao produzida durante o processo poder ser
muito til no caso da necessidade de evoluo do sistema. Alm disso, nesse modelo, as transies entre fases podem ser
consideradas como pontos de checagem do projeto, possibilitando assim uma melhor visibilidade do processo, o que no
acontece em modelos como o evolucionrio. Modelos do tipo iterativo e incremental so mais indicados para casos em
que os requisitos no so bem conhecidos, sendo necessrio que o usurio interaja com o sistema para que sejam
descobertas suas verdadeiras necessidades.
O restante do presente documento est estruturado da seguinte maneira: na seo 2, so apresentados alguns tpicos
relativos ao ciclo de vida da integrao de servios na Web; na seo 3, so apresentados brevemente, alguns itens
relativos ao estudo de caso realizado para validar as idias apresentadas; finalmente, na seo 4, so tecidas algumas
concluses a respeito dos assuntos abordados neste trabalho.
2. O ciclo de vida da integrao de servios na Web

A especializao do modelo cascata, proposta neste trabalho, pode ser visualizada na Figura 1. Esta especializao
conta com um conjunto de fases e atividades que tm como objetivo guiar um processo de integrao de servios na Web.
Em cada fase, so propostas atividades, sendo que a realizao das mesmas resulta na produo de artefatos que serviro
como entrada para as fases posteriores.
Em um processo de integrao de servios, consideramos que o marco inicial o surgimento de uma ou mais
necessidades por parte dos usurios de um ou mais servios. Digamos que esses usurios, queiram que os servios
disponibilizados a eles, passem a desempenhar determinada tarefa de forma integrada, processando uma requisio de
forma sincronizada e retornando o resultado em tempo hbil. Uma vez identificada a necessidade de uma integrao de
servios, e feita a opo por desencadear um processo que possibilite essa integrao, uma seqncia de fases contendo
uma determinada quantidade de atividades precisa ser seguida. A seguir, estas fases, atividades e artefatos gerados so
descritos com maiores detalhes a fim de possibilitar um melhor entendimento do contedo apresentado na Figura 1.
Na Figura 1, as fases de um processo de integrao de servios na Web so representadas por retngulos. Em cada
fase, so desempenhadas atividades que produziro artefatos a serem utilizados nas fases posteriores. As setas espessas
representam a transio para uma prxima fase, e tambm eventuais entradas de uma dada fase. As setas menos salientes
representam o principal artefato produzido em cada fase. O retorno para uma fase anterior representado por uma seta
pontilhada. Como relata [26], a necessidade de retornar a uma fase anterior justificada pelo fato de que, na prtica, o
processo de desenvolvimento de software no pode ser considerado como um simples modelo linear, pois envolve uma
seqncia de iteraes de atividades de desenvolvimento. Normalmente, na fase de projeto podem ser identificados
problemas com os requisitos, e durante a implementao podem ser identificados problemas relacionados fase de
projeto, e assim por diante.
Figura 1: Modelo de ciclo de vida para o processo integrao de servios na Web.

2.1. FASE I Anlise Inicial

Nessa primeira fase da seqncia, realizada uma anlise inicial, que deve levar em considerao as necessidades do
usurio. As atividades existentes nesta fase so a definio do problema, o estudo de viabilidade e a minimizao do
escopo.
A atividade de Definio do Problema visa analisar as necessidades do usurio e a realidade do ambiente em
considerao, a fim de fornecer uma descrio detalhada do problema que se deseja resolver com a integrao. O Estudo
de Viabilidade objetiva analisar se os servios realmente podem ser integrados. Como relatado em [19], um estudo de
viabilidade contempla aspectos econmicos, tcnicos e legais. Por sua vez, a Minimizao do Escopo objetiva definir o
quanto do problema ser resolvido. Visto que o escopo influencia na durao de um projeto, eles esto ligados e, uma vez
que o escopo minimizado, o tempo e conseqentemente o custo so reduzidos. Ento, a minimizao do escopo
incrementa as chances de sucesso de um projeto [10].
2.2. FASE II Descrio dos Servios a serem Integrados
Esta segunda fase da seqncia inclui atividades que visam produzir uma descrio detalhada dos servios a serem
integrados, a fim de possibilitar um maior conhecimento de seu comportamento, suas operaes e restries. Partindo do
princpio de que queremos integrar dois ou mais servios, precisamos saber, com grande quantidade de detalhes, como
funcionam estes servios. Nada melhor para resolver isso que produzir uma documentao contendo, detalhadamente, a
descrio de cada servio em questo. Essa descrio ser uma entrada indispensvel para a fase de planejamento, que
onde ser elaborado um modelo para a integrao, o qual ser implementado nas fases posteriores.
2.3. FASE III - Elicitao de Requisitos
Nesta fase, so desempenhadas atividades relacionadas ao processo de elicitao de requisitos da integrao. Visto que
um bom levantamento de requisitos pode evitar trabalho extra, desperdcio de tempo e recursos [25], importante dar
uma ateno especial a essa fase. Ao final dessa fase, temos em mos dois importantes artefatos: o documento contendo a
descrio dos servios em questo (produzido na fase anterior) e o documento de requisitos. Ambos so peas chave para
a construo do modelo de integrao. Eles serviro de entrada para a prxima fase da seqncia, a fase de projeto.
2.4. FASE IV Projeto
A fase de Projeto pode ser considerada como o principal elemento do processo de integrao. neste ponto que, de
posse da descrio das operaes e comportamento dos servios, dos requisitos da integrao, e de todo conhecimento
adquirido nas fases anteriores, ser elaborado o modelo de integrao. Nessa fase, atividades como reviso cuidadosa da
descrio dos servios e dos requisitos da integrao so indispensveis. Uma outra atividade importante da fase de
projeto a anlise do mundo externo, ou seja, de acordo com a realidade onde esto contidos os servios em questo,
deve-se analisar que tecnologias esto disponveis e podero ser teis no processo de integrao.
O modelo de integrao determinar que sincronismo dever existir entre os servios no momento da execuo de
uma requisio, e que correspondncias existem entre as operaes de cada sistema. Em resumo, o modelo dever
expressar da maneira mais clara e objetiva possvel todos os aspectos da integrao.
2.5. FASE V Implementao
A fase de implementao recebe como entrada principal o modelo de integrao. Na fase anterior, o modelo de
integrao foi elaborado aps ter sido realizado um estudo das tecnologias disponveis para a implementao. Nessa fase,
o modelo ser implementado de acordo com tais tecnologias. No caso de serem encontradas inconsistncias no modelo
durante a fase de implementao, pode haver a necessidade de um replanejamento. Quando isso acontecer, deve-se voltar
fase de projeto, o que resultar em uma nova verso do modelo de integrao j com as inconsistncias eliminadas.
2.6. FASE VI Testes e Validao
Na fase de testes e validao, onde ser verificado se houve realmente a integrao dos servios. Esta fase recebe
como entrada o mecanismo de integrao que foi implementado a partir do modelo de integrao e tambm o documento
contendo os requisitos da integrao. Normalmente, na fase de testes, so executadas atividades de verificao e
validao. Embora estas expresses paream ser sinnimas, elas so distintas. Atividades de verificao checam se o
produto que foi construdo foi ao encontro dos requisitos. Por outro lado, as atividades de validao checam se as
funcionalidades do produto so realmente as que o cliente necessita [26].
2.7. FASE VII Manuteno

A fase de manuteno do processo de integrao de servios na Web semelhante do processo de desenvolvimento
de software tradicional. Esta fase se inicia com a colocao do software, ou mdulo de software, em funcionamento.
Como afirma [19], podemos estar cientes que, aps o software comear a operar na prtica, surgir a necessidade de
modificaes. Isso se deve identificao de erros no tratados nas fases anteriores, mudana no ambiente externo (e.g.
sistema operacional, dispositivo ou perifrico), ou ainda por aspectos relacionados evoluo do software, que consiste
no acrscimo de funcionalidades, melhorias no desempenho, entre outras.
3. Estudo de Caso
Com o intuito de validar a sistematizao do ciclo de vida da integrao de servios na Web, descrita anteriormente,
tomamos como exemplo a integrao de dois servios: 1) o primeiro o XMLA [22], que permite a recuperao de dados
analticos [1] de bases de dados multidimensionais, 2) o segundo o WFS [27], que possibilita a consulta de dados
espaciais [12, 15] em bases de dados geogrficas. A principal justificativa para a integrao do processamento analtico e
geogrfico est na sua utilizao para auxiliar o processo de tomada de decises, disponibilizando em um nico ambiente,
todo poder de anlise pertinente a estes dois tipos de processamentos. Os Sistemas de Suporte Deciso [2] possibilitam o
gerenciamento e a anlise, de forma eficiente e consistente, de grandes bases de dados, permitindo a extrao de
informaes que auxiliem a compreender o comportamento do negcio de uma organizao.
O resultado do estudo de viabilidade para o presente estudo de caso, mostra que os dois servios podem ser integrados,
uma vez que ambos possuem interfaces bem definidas e possibilitam a utilizao de tecnologias emergentes como Web
Services [28] e XML [30].
O servio analtico utilizado foi o XML For Analysis (XMLA) [31, 22]. Trata-se de uma API XML (Extensible
Markup Language) [30], baseada em SOAP (Simple Object Access Protocol) [24], criada atravs de uma iniciativa das
empresas Microsoft Corporation [16] e Hyperion Solutions Corporation [7], com o intuito de proporcionar um acesso
aberto a banco de dados multidimensionais. Este acesso padronizado possibilita a padronizao de interaes entre
aplicaes cliente e servidores de dados OLAP (OnLine Analytical Processing) [1] atravs da Internet. A implementao
do XML For Analysis geralmente feita baseando-se na arquitetura dos Web Services [28], e a descrio desse servio
pode ser realizada em WSDL [29]. O Servio XMLA disponibiliza os mtodos Discover e Execute, atravs dos quais
possvel ter acesso a metadados e aos dados armazenados em uma base multidimensional. Estes mtodos so invocados
usando o protocolo SOAP [24] e, dessa forma, as entradas e sadas esto no formato XML.
Quanto ao servio geogrfico foi utilizado o Web Feature Service (WFS), o qual implementado a partir do
documento OpenGIS Web Feature Service Implementation Specification [27], criado pelo Open GIS Consortium
(OGC) [17], que prope interfaces para descrio de operaes que manipulam feies geogrficas em um ambiente
distribudo por meio do protocolo HTTP. Entende-se por feies geogrficas (features), objetos geogrficos que podem
conter no mnimo uma propriedade geomtrica e uma ou mais propriedades descritivas. Operaes para manipulao de
dados incluem habilidades para criar, apagar, alterar, obter ou pesquisar feies baseadas em restries espaciais (e.g.
adjacncia e distncia) e no espaciais (e.g. faixa etria = 1 e sexo = M). Um servio WFS possibilita que aplicaes
cliente, atravs de requisies HTTP [6], obtenham dados espaciais codificados em GML [4]. A recuperao de dados e
metadados armazenados em uma base de dados geogrficos se faz possvel atravs da utilizao das operaes
GetCapabilities, DescribeFeatureType e GetFeature do WFS. Em [3] so descritos alguns tipos de operadores espaciais,
lgicos, aritmticos e de comparao, que podem ser utilizados em uma requisio feita ao WFS. Alguns servios WFS
tambm implementam as operaes Transaction e LockFeature, utilizadas para alterar e incluir dados, no entanto, para
este estudo de caso estas no sero consideradas.
Na fase de elicitao de requisitos, foi convencionado que o mecanismo de integrao deveria disponibilizar operaes
que possibilitassem o acesso tanto a dados analticos, atravs do servio XMLA, quanto a dados geogrficos por meio do
WFS. Uma requisio poder ser basicamente de trs tipos: 1) consulta somente analtica, onde o mecanismo XMLA
acionado para processar os parmetros da consulta e em seguida retornar o resultado; 2) requisio somente geogrfica,
onde somente uma consulta atravs do WFS realizada; 3) uma requisio contendo parmetros analticos e geogrficos,
onde o mecanismo de integrao tem sua maior carga de processamento, pois necessrio acessar ambos os servios,
integrar os resultados e em seguida retornar o resultado da integrao.
3.1. Projetando o modelo de integrao dos servios analticos e geogrficos
Nessa fase, foi realizado um estudo das tecnologias que poderiam ser utilizadas no processo de integrao dos servios
XMLA e WFS. Foi identificado que a utilizao de padres como XML, XML Schema [23], XSLT [21] e Web Services
[28] traria grandes facilidades durante a fase de implementao do mecanismo de integrao, onde um Web Service
denominado GMLA-WS (GML For Analysis Web Service) seria responsvel pela implementao do modelo de
integrao. A figura 2 descreve, em um alto nvel de abstrao, os principais componentes dessa integrao.
O GMLA-WS disponibiliza um mtodo que permite a um Web Service cliente enviar requisies para os servios
XMLA e WFS. A comunicao entre o GMLA-WS e o XMLA feita conforme o padro dos Web Services, ou seja,
atravs do envio e recebimento de informaes codificadas em um envelope SOAP. Por outro lado, a comunicao entre
o GMLA-WS e o servio WFS ocorre atravs do envio e recebimento de requisies HTTP, sem a utilizao do
protocolo SOAP, devido ao WFS no operar conforme o padro dos Web Services.
Figura 2 Componentes da Integrao dos servios XMLA e WFS.

3.2. Implementao do mecanismo para integrao dos servios XMLA e WFS
Tendo os dados analticos e geogrficos armazenados em um Data Warehouse Geogrfico (DWG), cujo esquema
conceitual definido em [20], os servios WFS e XMLA fazem acesso a esses dados de acordo com as requisies
enviadas por um Web Service cliente. Uma fonte de metadados, implementada de acordo com a especificao MOF
(MetaObject Facility) [13], disponibiliza ao GMLA-WS informaes sobre os dados analticos e geogrficos
armazenados no DWG, bem como as relaes existentes entre dados analticos e geogrficos. Essas informaes sero
teis no momento do processamento das requisies.
O mecanismo de integrao foi implementando de acordo com o padro dos Web Services. Dessa forma, o GMLA-
WS recebe as requisies no formato SOAP [24] e envia consultas aos servios XMLA e WFS. Estes ltimos, acessam o
DWG para obterem os dados que satisfazem os parmetros da requisio. Os resultados dos dois servios so processados
pelo GMLA-WS, que atravs da aplicao de transformaes XSLT gera o documento contendo os dados integrados. O
documento gerado ento validado com o XML Schema denominado GMLA Schema [5], o qual responsvel por
definir a estrutura do documento resultante da integrao. Aps a validao, o resultado da integrao codificado em um
envelope SOAP e enviado ao cliente.
Neste estudo de caso, o Web Service cliente que envia as requisies para o servio GMLA, e conseqentemente
processa as respostas, foi implementado na linguagem JAVA [18]. Mas considerando que o GMLA-WS disponibiliza a
interface do servio descrita em WSDL, a implementao dos Web Services clientes independente de linguagem ou
plataforma. O mdulo responsvel pela visualizao grfica dos resultados possui uma interface grfica que possibilita
que os parmetros de uma requisio sejam codificados em um envelope SOAP e em seguida, enviados ao GMLA-WS.
Assim que a resposta for recebida, o mdulo capaz de demonstrar graficamente os dados contidos no documento
resultante da consulta. Para representar graficamente os dados geogrficos foi utilizada a tecnologia SVG [11], e para os
dados analticos foi utilizado HTML.
4. Concluso
A sistematizao do ciclo de vida da integrao de servios na Web, aqui proposta, tem como objetivo sistematizar
este processo de integrao, visto que existe um alto grau de dificuldade nesse tipo de atividade. Cada fase proposta nesta
sistematizao, possui determinadas atividades que produzem artefatos importantes para o processo de integrao dos
servios. possvel que durante o processo de integrao, seja necessrio repetir algumas dessas fases a fim de melhorar
os resultados obtidos. Mas, como em todo desenvolvimento cclico, somente a primeira passagem por cada fase ir
requerer mais tempo. No momento em que se faz necessrio retornar a uma determinada fase, j se ter o conhecimento
adquirido anteriormente, o que far com que o tempo gasto dessa vez seja menor que anteriormente.
As idias apresentadas neste trabalho puderam ser aplicadas a um caso de integrao de servios na Web, obtendo
resultados satisfatrios no desenvolvimento do mecanismo de integrao entre os servios XMLA e WFS. Dessa forma,
possvel que a sistematizao aqui proposta possa ser aplicada a outros casos de integrao de servios na Web, tais como
servios de validao de cartes de crdito, reservas de passagens, hotis e carros, entre outros.
5. Referncias Bibliogrficas
[1] S. Chaudhuri, U. Dayal. Decision support, Data warehouse, and OLAP, in Tutorials of the Twenty-Second International Conf. On
Very Large Data Base, Bombay, pages 295-306, 1996.
[2] Daniel J. Power, Decision Support Systems Web Tour, Editor SSResources.COM http://www.dssresources.com/tour/dsstour.html -
[3] OpenGIS Filter Encoding Implementation Specification, http://www.opengis.org/techno/specs/02-059.pdf
[4] OpenGIS Geography Markup Language (GML) 2.0 Implementation Specification, Open GIS Consortium Inc.
http://www.opengis.org/techno/documents/02-023r4.pdf (ltimo acesso dezembro de 2003)
[5] Robson N. F. et. al. GMLA: A XML Schema for Integration and Exchange of Multidimensional-Geographical Data, GEOINFO
2003, http://www.geoinfo.info/Anais/geoinfo2003-48.pdf (ltimo acesso em dezembro de 2003)
[6] Hypertext Transfer Protocol - http://www.w3.org/Protocols/ (ltimo acesso em dezembro de 2003)
[7] Hyperion Solutions Corporation - http://ww.hyperion.com (ltimo acesso em dezembro de 2003)
[8] Ion Constantinescu et. al., Abstract Behavior Representations for Service Integration, Artificial Intelligence Laboratory, Swiss
Federal Institute of Technology, IN (Ecublens), CH-1015 Lausanne, Switzerland.
[9] Ion Constantinescu, Planning and Execution for Dynamic Service Integration In Open Environments Thesis Proposal, Artificial
Intelligence Laboratory, Swiss Federal Institute of Technology, IN (Ecublens), CH-1015 Lausanne, Switzerland.
[10] Johnson, J. H. Micro Projects Cause Constant Change , Standish Group 2001 -
http://www.xp2001.org/xp2001/conference/papers/Chapter30-Johnson.pdf (ltimo acesso em julho de 2003).
[11] Scalable Vector Graphics (SVG). http://www.w3.org/Graphics/SVG/, W3C Recommendation, (ltimo acesso em novembro de 2003)
[12] Keith C. Clarke. Getting Started with Geographic Information Systems, Prentice Hall, USA, 1997.
[13] OMG - Object Management Group. MetaObject Facility (MOF) Specification 1.4. Especificao, 2002.
[14] John A. McDermind. Software Engineers Reference Book. Butterworth-Heinemann, 1991.
[15] Michael N. Demers. Fundamentals of Geographic Information Systems, Wiley, USA, 1997.
[16] Microsoft Corporation www.microsoft.com (ltimo acesso em dezembro de 2003)
[17] Open GIS Consortium Inc., http://www.opengis.org/ (ltimo acesso em dezembro de 2003)
[18] Sun Microsystems. Pgina Internet Oficial da Linguagem Java, 2003 (http://java.sun.com/) (ltimo acesso em dezembro de 2003)
[19] Roger S. Pressman. Engenharia de Software. Makron Books, So Paulo Brasil, 1995.
[20]Robson do Nascimento Fidalgo, Definio de uma Infra-estrutura Bsica para Integrao de Dados Multidimensionais e
Geogrficos em um Ambiente de Data Warehouse. Qualificao e Proposta de Tese de Doutorado. CIN-UFPE, Julho de 2003.
[21] World Wide Web Consortium, XSL Transformations (XSLT), http://www.w3.org/TR/xslt (ltimo acesso em dezembro de 2003)
[22] XML For Analysis Specification, Version 1.1, Microsoft Corporation & Hyperion Solutions Corporation, Novembro de 2002.
[23] World Wide Web Consortium, XML Schema http://www.w3.org/XML/Schema (ltimo acesso em dezembro de 2003)
[24] World Wide Web Consortium, SOAP, http://www.w3c.org/TR/soap12-part0/ (ltimo acesso em dezembro de 2003)
[25] Gerald Kotonya e Ian Somerville, Requirements Engineering Process and Techniques. 1998.
[26] Ian Somerville. Software Engineering. 4th ed. Addison-Wesley, 1992.
[27] OpenGIS Web Feature Service Implementation Specification, Open GIS Consortium Inc. 19-September-2002, Version: 1.0.0.
[28] World Wide Web Consortium. Web Services , http://www.w3.org/2002/ws/ (ltimo acesso em dezembro de 2003).
[29] World Wide Web Consortium. Web Services Description Language (WSDL), http://www.w3.org/TR/2001/NOTE-wsdl-20010315
[30] World Wide Web Consortium. eXtensible Markup Language. http://www.w3.org/XML/ (ltimo acesso em dezembro de 2003).
[31] XML For Analysis Home Page, http://www.xmla.org (ltimo acesso em dezembro de 2003).
Componentes de Software para a Construo de Ambientes de Simulao

de Redes de Computadores Implementao e Validao
Flvio Gonalves da Rocha e Maria Izabel Cavalcanti Cabral

Programa de Ps-Graduao em Informtica
Universidade Federal de Campina Grande (UFCG)
Av. Aprgio Veloso, 882 58.109-970 Campina Grande PB Brazil
fgrocha@chesf.gov.br, izabel@dsc.ufcg.edu.br
Resumo
Nesse artigo apresentam-se componentes de software para a construo de ferramentas de simulao
voltadas para modelar e avaliar o desempenho de sistemas de redes de computadores. Esses componentes
representam: (i) as funcionalidades bsicas de simuladores orientados a eventos, i.e., escalonadores de
eventos, relgio simulado, geradores de valores aleatrios e coletores de medidas de desempenho, e (ii)
elementos essenciais construo de modelos de redes TCP/IP. Apresenta-se tambm, como estudo de caso,
um simulador de redes TCP/IP construdo reutilizando os componentes mencionados.
1. Introduo.
Estudos e anlises de sistemas de comunicao de dados podem ser complexos devidos, em geral, a grande
quantidade de recursos a ser considerada e ao relacionamento dinmico que esses recursos apresentam. Nesse
contexto, ferramentas de simulao orientada a eventos apresentam-se como uma alternativa para facilitar
estudos e anlises desses sistemas. A reutilizao de software na construo dessas ferramentas impe-se,
principalmente, devido evoluo das tecnologias das comunicaes que exige constantemente novos estudos
e anlise de seus desempenhos.
Entre as formas de reutilizao de software, ressalta-se o uso de componentes, que so objetos inteiros j
instanciados que podem ser conectados a uma aplicao qualquer [1]. A composio das aplicaes feita
utilizando ferramentas grficas que permitem configurar e conectar os componentes necessrios aplicao de
forma visual.
Este artigo apresenta componentes de software que visam a construo facilitada de ambientes de
simulao voltados para sistemas computacionais e de comunicao de dados, em particular redes de
computadores TCP/IP, explorando a reutilizao de software. Dois tipos de componentes so especificados e
implementados: os que permitem a construo de ambientes de simulao orientados a eventos (relgio
simulado, lista de eventos, geradores de valores aleatrios, controle da simulao, entre outros) e os
componentes que representam elementos essenciais de uma rede de computadores TCP/IP (fontes de pacotes,
hosts, enlaces e roteadores). Como estudo de caso, para validar os componentes implementados, um ambiente
de simulao de redes TCP/IP foi construdo e modelos dessas redes foram simulados.
O usurio dos componentes o desenvolvedor de ambientes de simulao. Este, atravs de uma ferramenta
visual, pode construir um ambiente de simulao simplesmente configurando e conectando os componentes
atravs de suas interfaces. Os componentes voltados para a construo de ambientes de simulao podem ser
reutilizados na construo de qualquer ambiente orientado a eventos que se aplique a modelos que apresentam
conteno de recursos, tais como aqueles que representam sistemas de computao e sistemas de comunicao
de dados.
O restante deste artigo organizado da seguinte forma: a seo 2 apresenta a metodologia de

desenvolvimento dos componentes empregada. Nessa seo apresentam-se, brevemente, aspectos referentes
ao levantamento de requisitos e s fases de anlise e projeto. Em seguida so apresentados aspectos relevantes
s fases de implementao e de teste dos componentes. A seo 3 apresenta uma breve descrio dos
exemplos numricos que validaram o simulador de rede TCP/IP (estudo de caso), construdo com os
componentes propostos. A seo 4 ressalta as caractersticas do ambiente de simulao implementado. A
seo 5 apresenta a concluso do trabalho.
2. Metodologia de desenvolvimento.
O processo de desenvolvimento adotado incremental baseado em Larman [2]. Na especificao foi usada
a Linguagem de Modelagem Unificada (Unified Modeling Language - UML) [3]. Na implementao foi
escolhido o modelo de componentes JavaBeans [4], que so componentes de software independentes de
plataforma e portveis, tirando proveito das vantagens da linguagem Java [5]. Todos os documentos gerados
relacionados s fases de desenvolvimento encontram-se em [6].
2.1.Contexto dos componentes.
Resumidamente, para entender as funcionalidades de uma simulao orientada a eventos, observa-se que
esta engloba trs fases bsicas: inicializao, execuo e finalizao. A fase de inicializao constitui-se na
construo e configurao do modelo a ser simulado (no escopo deste artigo, um modelo de rede TCP/IP) e na
configurao dos parmetros de entrada da simulao (por exemplo, tempos de incio e de finalizao da
simulao). A fase de execuo constitui-se na execuo do algoritmo de simulao. Nessa etapa, eventos so
gerados, armazenados em uma lista de eventos, em ordem cronolgica de ocorrncia, e escalonados segundo a
disciplina de escalonamento First In First Out FIFO. Aps o escalonamento de um evento, procedimentos
referentes s aes pertinentes ocorrncia deste evento, tais como atualizao do relgio da simulao,
coleta de dados para o clculo de medidas de desempenho, e aes que podem gerar outros eventos, so
executadas. A fase de finalizao constitui-se no clculo das medidas de desempenho de interesse e na
apresentao dos resultados.
Os componentes apresentados neste artigo so organizados em duas classes: (i) os componentes voltados
para a construo de ambientes de simulao, e (ii) os que representam os elementos essenciais de uma rede
TCP/IP. Os componentes (i) representam entidades essenciais ao funcionamento bsico de uma simulao
orientada a eventos, tais como o relgio simulado, o escalonador de eventos, geradores de valores aleatrios,
controle da simulao, coletores de dados (depsitos), entre outros mais adiante apresentados. Os
componentes (ii) representam elementos essenciais de uma rede de computadores TCP/IP (fontes de pacotes,
hosts, enlaces e roteadores ).
2.1.1. Levantamento de requisitos e fase de anlise.
Na etapa de levantamento dos requisitos foi feita a descrio do sistema, a identificao das suas metas, dos
clientes, dos objetivos, dos requisitos funcionais (o que o sistema deve fazer) e dos no funcionais
(caractersticas ou dimenses do sistema). Seguindo o processo de desenvolvimento adotado chegou-se
construo dos Use Cases que so documentos narrativos que descrevem os processos que se encontram no
domnio do problema. Aps a fase de levantamento de requisitos, passou-se fase de anlise. O modelo
conceitual foi considerado o principal artefato obtido nessa fase uma vez que representa os conceitos do
domnio do problema e os seus relacionamentos.
2.1.2. Fase de projeto.
2.1.2.1. Projeto arquitetural ou projeto de alto nvel.
Um dos artefatos gerados nessa fase do processo de desenvolvimento foi o projeto arquitetural. A sua
representao foi feita atravs de uma arquitetura de trs camadas que so: (i) Camada de Apresentao:
define a interface com o usurio; (ii) Camada de Aplicao: define as tarefas e regras que governam o
processo, e (iii) Camada de Dados: consiste nos mecanismos de armazenamento persistente. Este trabalho est
focado apenas na camada da lgica da aplicao.
2.1.2.2. Projeto detalhado ou projeto de baixo nvel.
O projeto detalhado seguiu o projeto arquitetural visando identificar os componentes individuais que
compem o sistema. A tabela 1 apresenta a relao dos 16 componentes projetados.
Tabela 1. Componentes.
Nome Descrio
Relgio Armazena o tempo simulado.
Deposito Permite o descarte de entidades durante a simulao e a coleta de

estatsticas (por exemplo, o nmero de pacotes descartados durante a
simulao).
Modelo Contm os elementos do sistema modelado (no caso, elementos de
uma rede TCP/IP) e as rotas ativas do mesmo.
GeradorExponencial Responsvel pela gerao de amostras de uma funo de distribuio
de probabilidade exponencial com valor mdio fornecido pelo usurio.
Simulador Representa a interface entre os componentes da lgica da aplicao e a
interface do simulador.
Simulacao Gera o evento que inicializa os demais componentes, controla a
execuo do componente ControlaSimulacao e obtm os resultados da
simulao.
ControlaSimulacao Responsvel pela execuo da simulao (escalonamento de eventos,
avano do tempo, etc.).
VerificadorConsistencia Verifica a consistncia do modelo antes da execuo da simulao.
TabelaRoteamento Armazena informaes de rotas referentes aos pacotes que chegam aos
roteadores.
ListaEventos Armazena os eventos que vo ser escalonados em ordem cronolgica
de ocorrncia durante a simulao.
ProcessadorMedidasDesempenho Faz os clculos das medidas desempenho.
Fonte Representa as fontes do modelo (geradoras de pacotes).
Host Representa os hosts (origem e destino) do modelo.
Enlace Representa os enlaces do modelo.
Roteador Representa os roteadores do modelo.
Sorvedouro Representa os sorvedouros do modelo (eliminam pacotes).

Durante esta fase foram gerados diagramas de colaborao que servem para mostrar como os componentes
devem se comunicar de maneira a atender os requisitos especificados. Para proporcionar melhor compreenso
dos diagramas de colaborao apresentados nesta seo, faz-se necessrio uma descrio detalhada da
topologia dos modelos de redes TCP/IP que sero executados no ambiente de simulao. Um exemplo mais
simples mostrado na Figura 1.
Enlace1 Enlace2
Host Origem Roteador Host Destino
Figura 1. Exemplo de uma topologia com 1 roteador.
Com o intuito de possibilitar um modelo de sistemas de redes TCP/IP mais completo foram acrescidos
novos componentes para representar determinados aspectos dessa arquitetura. A camada de transporte do host
origem abstrada atravs do componente Fonte que tem por funo gerar mensagens que so enviadas
camada IP. No host destino, a camada de transporte representada atravs do elemento Sorvedouro que ao
contrrio do componente Fonte, recebe pacotes da camada IP. A Figura 2 mostra esses relacionamentos em
um modelo de rede com apenas um roteador. Um roteador foi modelado com funcionalidades voltadas apenas
para as funes essenciais que permitem roteamento unicast e multicast.
Fonte Sorvedouro
Interface Enlace Enlace Interface
Roteador
Host Origem Host Destino
Mquina Origem Mquina Destino

Figura 2. Exemplo de um modelo de rede.
a) Diagramas de colaborao.
Antes da apresentao dos diagramas de colaborao escolhidos como exemplos neste artigo, ilustrados nas
Figuras 3, 4 e 5, faz-se necessrio mencionar que os componentes do ambiente (lista de eventos, relgio, etc)
j foram instanciados, configurados e conectados atravs de eventos.
O diagrama de colaborao da Figura 3 (construo do modelo) mostra que, para cada componente
instanciado pelo usurio para construir o modelo de uma rede TCP/IP, so gerados dois eventos: (1) o
InsereElementoModelagemEvent e (2) o CadastraEvent. O primeiro faz com que o componente Modelo
armazene o novo elemento de rede ao passo que o segundo faz a ligao deste novo componente aos
componentes do ambiente. Este procedimento de cadastro tardio em tempo de execuo do ambiente de
simulao faz-se necessrio porque o ambiente no sabe quais so os componentes do modelo com quem ele
ir interagir. A soluo para isto foi dotar cada componente que tenha de interagir com os elementos da rede,
com mtodos que sejam capazes de fazer este cadastro de forma transparente ao usurio do sistema.
Uma vez construdo e configurado, o modelo j pode ser executado. Imediatamente, aps a inicializao
dos componentes, a execuo da simulao prossegue acionando as fontes do modelo. Em virtude do tamanho
e da complexidade do diagrama que apresenta as interaes necessrias execuo da simulao, o mesmo foi
dividido em dois diagramas que so mostrados nas Figuras 4 e 5. Alguns elementos esto repetidos a fim de
auxiliar a compreenso de cada uma dos diagramas.
insereElemento(IElementoModelagem) 1: InsereElementoModelagemEvent
:Interface :Simulador :Modelo
Ambiente
2: CadastraEvent
:Simulacao :Tabela :ProcessadorMedidas :Gerador :Controla :Lista :Deposito

Roteamento Desempenho Exponencial Simulacao Eventos
Figura 3. Construo do modelo insero e cadastro de componentes.
:In terface
A m b iente
execu ta(tem po Inic al, tem poFim )
13: R etorn aRe logio Tem po E vent

1: Incia liza S im ulac aoE ve nt
:S im ulado r :P ro cess adorM edidas :R elogio :Ho st
D esem p enho Orig em
2: In cializaS im ulac aoE ven t 1 1: A tualizaR elo gioE vent :Ho st

De stino
12: R etorna RelogioTem poE vent
:E nlace
3 : E xec utaC ontrolaS im ula caoE vent

14: Tem poC orren teR elogioE vent
:S im ulac ao :C ontro la :R otead or
S im ulac ao
1 5: O bterP roxim oN oE ven t
4: E xec utaFon teE ve nt
10 : R etornaE ventoE vent
1 6: R etorna P roxim o NoE vent
:Tabela
9: E sc alonaL ista E vento E vent 5: [is P rim eiraE xecu caoFon te] O bterR otaE vent R oteam e nto
:L ista 8: Che gadaP ac oteE vent :Fon te

E ventos 5.1 : R etornaR otaE vent
7: R etorna Dad osG eradorE vent 6: [D istP rob abilidadeFo nteE xp onenc ial] O bterD ado sG eradorE xponnec ial
[D istP rob abilidadeP ac oteE xp onenc ial] O bte rD ad osG eradorE xponen cial
:G erador
E xpone ncia l
Figura 4: Diagrama de colaborao para a operao de sistema executa( ) primeira parte.

:Enlace
:Host
Destino
17.a: [ChegadaPacoteEvent] RecebePacoteEvent

:Fonte :Controla 17.b: [FimServicoEvent] transmiteEvent :Sorvedouro
Simulacao
:Host
Origem
18 [tempoFinal] ExecutaFimSimulacaoEvent
19: ObterResultadoSimulacaoEvent
:Simulador :Simulacao :ProcessadorMedidas
Desempenho
21: FimSimulacaoEvent 20: RetornaResultadoSimulacaoEvent
Figura 5. Diagrama de colaborao para a operao de sistema executa( ) segunda parte.
b) Diagramas de classes.
Finalmente, dos diagramas de interao (colaborao) e do modelo conceitual foram definidos os

diagramas de classes que representam os componentes. Cada componente visto como uma classe, dentro dos
conceitos da linguagem UML [7].
Apresenta-se como exemplo o diagrama de classe do componente ListaEventos que armazena os eventos
que vo ser escalonados em ordem cronolgica de ocorrncia durante a simulao.
<<Interface>> ListaEventos
CadastraListener
colecaoEventos : Lista
cadastra() proximoEvento : IEvento
eventoCorrente : IEvento
numeroEventos : int
retornaEventoListeners : Vector
<<Interface>> statusListaEventosListeners : Vector
DescadastraListener
<<Interface>>
descadastra() getNumeroEventos() ElementoLista
IEvento
setNumeroEventos()
getProximoEvento()
0..*
<<Interface>> setProximoEvento()
InicializaListener getEventoCorrente() 1
setEventoCorrente()
inicializa() Lista
criaLista()
atualizaListaEvento()
removeEvento()
<<Interface>>
inicializa()
FimServicoListener
cadastra() <<Interface>>
atualizaListaEvento() descadastra() FimSimulacaoListener
escalonaEvento()
fireRetornaEvento()
atualizaListaEvento()
fireStatusListaEventos()
addRetornaEventoListener()
removeRetornaEventoLestener()
<<Interface>> addStatusListaEventosListener()
<<Interface>>
EscalonaListaEventosListener removeStatusListaEventosListener()
ChegadaPacoteListener
writeObject()
escalonaEvento() atualizaListaEvento()
readObject()
Figura 6. Componente ListaEventos.

importante observar que o diagrama de classes apresentado nesta seo no mostra todos os
relacionamentos que os componentes ou classes exigem. Isto se deve ao fato de evitar uma complexidade
exagerada na apresentao desse diagrama. Todos os diagramas produzidos so apresentados em [6].
2.2. Fase de implementao.
A linguagem de programao escolhida para a implementao dos componentes foi Java. Esta portvel e
possui uma extensa biblioteca de classes padro, possibilitando, assim, um ambiente de execuo
independente de plataforma que permite que a aplicao seja criada uma vez e rodada em qualquer lugar
favorecendo a reutilizao de software.
Para essa implementao foi escolhido o modelo de componentes JavaBeans [4] uma vez que os nossos
componentes se comunicam atravs de eventos e no sero executados em um servidor. Eles so componentes
de software independentes de plataforma e portveis uma vez que tiram proveito das vantagens que a
linguagem Java oferece [5]. JavaBeans ou simplesmente Beans foram criados para possibilitar o
desenvolvimento rpido de aplicaes em Java montando componentes predefinidos atravs de uma
ferramenta visual.
A comunicao dos componentes feita atravs de eventos de acordo com o modelo de eventos 1.1 de
Java [4]. Esse modelo baseado no conceito de classes ouvintes de eventos ou event listeners e fonte de
eventos ou event source. Listeners so objetos interessados em receber mensagens (eventos). Sources so
objetos que geram as mensagens (eventos). Esse modelo descrito pelo padro Observer [8].
Foram implementadas duas classes de eventos: (i) os eventos relacionados com a dinmica da simulao
que sero armazenados na lista de eventos: ChegadaPacoteEvent, FimServicoEvent e FimSimulacaoEvent; e
(ii) os eventos provenientes da comunicao entre os componentes tais como StatusListaEventosEvent e
RetornaEventoEvent. As classes de eventos criadas para fornecer as interaes entre os componentes tais
como o ExecutaFonteEvent, CadastraEvent, bem como as classes que representam as interfaces dos
respectivos eventos so mostradas com detalhes em [6].
Um aspecto importante a ser enfatizado que os componentes implementados podem ser usados em duas
fases diferentes. Na primeira fase, o programador constri de forma visual um ambiente de simulao atravs
dos componentes voltados ao ambiente simplesmente configurando-os e ligando-os atravs de eventos. Com
o ambiente pronto, passa-se a segunda fase que consiste em usar os componentes da rede TCP/IP para montar
o modelo de rede que ser executado. Dessa forma, a ferramenta de simulao construda se comportar como
uma ferramenta visual fornecendo meios para que os componentes do modelo sejam investigados atravs de
introspeco [9], configurados e inseridos no modelo. Nessa ltima fase, o usurio alvo no o montador de
componentes, visto na primeira fase, e sim o especialista em redes.
Para o desenvolvimento dos componentes foi utilizado o software Jbuilder da Borland [10]. Esse software
tambm foi utilizado para a realizao das tarefas pertinentes primeira fase acima citada, ou seja, a
configurao e ligao dos componentes com o intuito de criar um ambiente de simulao. Na segunda fase,
a construo do modelo de rede TCP/IP pode ser viabilizada atravs da ferramenta de simulao criada com o
uso dos componentes do ambiente. medida que os componentes foram implementados testes foram
realizados. Para viabilizar esses testes foi usada a ferramenta de testes Junit [11].
2.2.1. Implementao de um ambiente de simulao de redes TCP/IP.
Conforme j mencionado, alm da implementao dos componentes, investiu-se na construo de um

ambiente de simulao como forma de testar a integrao dos componentes e validar suas implementaes. A
fase correspondente implementao desse ambiente de simulao foi feita de forma simples atravs da
criao de uma classe Java chamada Ambiente.java que permite interligar os componentes. A Figura 7mostra
um trecho de cdigo dessa classe.

public class Ambiente{
//Instanciao dos componentes do ambiente de simulao

Simulador simulador1 = new Simulador();
Simulacao simulacao1 = new Simulacao();
VerificadorConsistencia verificadorConsistencia1 = new VerificadorConsistencia();
TabelaRoteamento tabelaRoteamento1 = new TabelaRoteamento();
Modelo modelo1 = new Modelo();
Deposito deposito1 = new Deposito();
Relogio relogio1 = new Relogio();
GeradorExponencial geradorExponencial1 = new GeradorExponencial();
ListaEventos listaEventos1 = new ListaEventos();
ProcessadorMedidasDesempenho processadorMedidasDesempenho1 = new
ProcessadorMedidasDesempenho();
ControlaSimulacao controlaSimulacao1 = new ControlaSimulacao();
...
private void jbInit() throws Exception {
//Cadastro dos Componentes
//SIMULADOR
//Cadastro para o evento CadastraEvent
simulador1.addCadastraListener( simulacao1 );
simulador1.addCadastraListener( tabelaRoteamento1 );
simulador1.addCadastraListener( processadorMedidasDesempenho1 );
simulador1.addCadastraListener( geradorExponencial1 );
simulador1.addCadastraListener( controlaSimulacao1 );
simulador1.addCadastraListener( listaEventos1 );
simulador1.addCadastraListener( deposito1 );
Figura 7: Trecho de cdigo da classe Ambiente.java.
Nessa figura vemos que os componentes do ambiente so instanciados normalmente com um new de Java
(feito pelo Jbuilder no momento da instanciao do componente). Pode-se observar que no foi preciso
configurar nenhum componente com valores iniciais, uma vez que isto ocorre de forma automtica quando o
ambiente esta executando um modelo.
Com o ambiente de simulao implementado atravs da classe Ambiente.java, mostrada na Figura 7 temos
um ambiente de simulao quase pronto, necessitando apenas dos valores iniciais para realizar a sua
execuo. Isto feito por meio de uma interface grfica que no caso no faz parte do escopo do presente
trabalho. No entanto, como forma de viabilizar estudos de simulao foi criada a classe
InterfaceAmbiente.java que interage com o componente Simulador realizando as aes de uma interface para
o ambiente.
Um trecho do cdigo dessa classe mostrado na Figura 8 Essa figura mostra o mtodo jbInit() que
apresenta os mtodos construcaodoModelo(), execuodaSimulacao() e apresentacaodosResultados() que
correspondem s fases clssicas de um processo de simulao: inicializao, execuo e finalizao,
respectivamente.
...
public class InterfaceAmbiente {
...
//Instanciao da clase Ambiente que representa o nosso simulador
Ambiente ambiente = new Ambiente();
//Instanciao pelo usurio dos componentes do modelo

Fonte fonte1 = new Fonte();
Roteador roteador2 = new Roteador();
...
public void construcaodoModelo(){
//Insero dos elementos da rede no componente Modelo do ambiente

ambiente.simulador1.insereElemento( fonte1 );
ambiente.simulador1.insereElemento( sorvedouro1 );
...
//Construo e insero da rota no elemento tabelaRoteamento
ambiente.simulador1.insereRota( fonte1.getId(), 1, 1, this.criaRota() );
...
//Configurao dos componentes
//FONTE
fonte1.setTempoPrimeiraCriacao( 0 );
fonte1.setDistribuicaoProbabilidadeFonte( 1 );
fonte1.setNumeroMaximoPacotes(2000 );
fonte1.setDistribuicaoProbabilidadePacote( 1000 );
...
//Mtodo que executa a simulao
public void execucaodaSimulacao(){
ambiente.simulador1.executa( 0, tempoFim, numeroReplicacao );
}
...
//Mtodo principal da classe InterfaceDoAmbiente.java
private void jbInit() throws Exception {
this.construcaodoModelo();
this.execucaodaSimulacao();
this.apresentacaodosResultados();
}
...
Figura 8 Trecho de cdigo da classe InterfaceAmbiente.java.
No total foram 130 classes implementadas, correspondendo a 65 classes de eventos e 65 interfaces. A

Tabela 2 apresenta um resumo dos resultados da implementao.
Tabela 2. Resumo dos resultados da implementao (linhas de cdigo produzidas e

quantidade de classes implementadas).
Descrio Quantidade Linhas de Cdigo

Componentes implementados 16 4649
Classes Concretas 10 1481
Classes Abstratas 2 316
Interfaces 2 38
Classes de eventos do tipo 65
NomeDoEventoEvent 3053
Interfaces do tipo 65
NomeDoEventoListener
Classes de testes 4 350
Total 160 9987
3. Exemplos numricos.
Os modelos escolhidos como exemplos para validar o ambiente de simulao construdo englobam
componentes que representam elementos de uma rede TCP/IP (fontes, hosts, enlaces, roteadores e
sorvedouros) foram de dois tipos, assim classificados: determinsticos e estocsticos. Para o primeiro tipo,
foram atribudos valores fixos para os parmetros de entrada dos elementos de modelagem tais como: tamanho
do pacote, tempos de servio dos hosts e dos roteadores, capacidades dos enlaces, etc. Nos modelos
estocsticos foram atribudos aos parmetros de entrada do modelo valores de amostras obtidos de uma funo
de distribuio de probabilidade exponencial. Conforme mencionado na seo anterior, cada modelo foi
construdos atravs de uma classe Java chamada InterfaceAmbiente.java que representa a interface do
ambiente.
Para fins de validao, os modelos simulados no ambiente de simulao construdo foram tambm
simulados no ambiente de simulao Arena [12]. Os resultados obtidos da simulao de modelos
determinsticos no ambiente de simulao foram idnticos aos resultados obtidos da simulao do mesmo
modelo no ambiente Arena. No caso dos modelos estocsticos foi observado que a diferena entre os
resultados (desvio) foi muito pequena, validando o ambiente de simulao implementado. Tais resultados so
apresentados em [6].
4. Caractersticas do ambiente de simulao implementado.

Para comparao com outros artefatos de software, ressaltamos que ambientes de simulao tais como
NIST [13] e NS [14] so ambientes de simulao extensveis, que permitem a construo de modelos de
sistemas de comunicao de dados. Os componentes de software ora apresentados so artefatos de software
para facilitar a construo de ambientes de simulao, podendo ser utilizados na construo de qualquer
ambiente de simulao de modelos de sistemas de comunicao de dados. Nesse trabalho, investiu-se na
construo de um simulador de redes TCP/IP, como estudo de caso, reutilizando os componentes propostos.
Para isso, componentes necessrios construo de um modelo de redes TCP/IP tambm foram especificados
e implementados. De forma similar, componentes que representem outras tecnologias (ATM, sem fio, etc.)
podem ser especificados e implementados viabilizando a construo de ambientes de simulao voltados para
essas tecnologias, de forma rpida e simples, explorando os benefcios da reutilizao de componentes.
O ambiente de simulao construdo como estudo de caso, voltado para redes TCP/IP, com os
componentes propostos apresentam facilidades, dentre elas merecem destaque:
O ambiente de simulao fornece meios para que uma rota possa estar ativa ou no. Quando ativa,
pacotes so gerados e transitam pela rota. Esta facilidade permite definir um conjunto de rotas
(ativas ou no) para um modelo sem a necessidade de remover as rotas inativas.
Quanto ao tamanho dos pacotes, o ambiente de simulao permite duas abordagens: (1) a fonte
gera pacotes de um mesmo tamanho que fica inalterado durante o deslocamento do mesmo
atravs dos elementos da rede que pertencem a sua rota, ou (2) ela gera pacotes cujos tamanhos
podem ser recalculados nesses elementos. No segundo caso, temos duas opes para cada pacote
gerado: (a) o seu tamanho (atribudo conforme valor de uma funo de distribuio de
probabilidade) permanece inalterado em toda a sua rota e, (b) o seu tamanho pode ser alterado em
qualquer elemento de sua de sua rota, conforme valor de uma funo de distribuio de
probabilidade. Esta opo pode viabilizar a comparao de resultados de modelos simulados no
ambiente em validao, com estudos analticos desses modelos.
Entre as medidas de desempenho que podem ser obtidas, ressaltamos: fator de utilizao dos
elementos do modelo, nmero de pacotes transmitidos por unidade de tempo (vazo), atraso
mdio dos pacotes no sistema, tempo mdio de transmisso nos meios de comunicao, atrasos
mdio de pacotes nas filas, nmero de pacotes descartados, nmero mdio de pacotes em fila.
Informaes sobre o estado em que um componente se encontra (livre, ocupado, congestionado
ou inativo) tambm podem ser obtidas.
O ambiente permite que um mesmo modelo possa ser simulado mais de uma vez, apresentando
amostras de medidas de desempenho para cada simulao realizada.
A simulao acionada por eventos. Os eventos so escalonados (processados) segundo sua
ordem cronolgica de ocorrncia.
Toda a dinmica da simulao feita pelo armazenamento no componente ListaEventos de
apenas trs tipos de eventos: ChegadaPacoteEvent, FimServicoEvent e FimSimulacaoEvent. Os
eventos RecebePacoteEvent e TransmiteEvent tambm so necessrios dinmica da simulao,
no entanto, no so armazenados na lista de eventos. Os demais eventos so usados para prover
comunicao entre os componentes como a arquitetura JavaBeans estabelece
(ExecutaFonteEvent, InicializaEvent etc).
O ambiente pode simular modelos de outros tipos de redes (ATM, sem fio etc) bastando que sejam
implementados os componentes que simulam as funcionalidades destas redes.
Permite a criao de rotas multicast.
5. Concluso.
Esse trabalho apresentou componentes de software que permitem a construo facilitada de ferramentas de
simulao atravs da reutilizao de software. Os componentes fornecem o funcionamento bsico de uma
simulao orientada a eventos, tais como controle do relgio simulado, geradores de valores aleatrios e
escalonamento de eventos. Esses componentes podem ser reutilizados na construo de quaisquer ferramentas
de simulao orientadas a eventos, independentemente do tipo de modelo a ser simulado, seja este
representando um sistema de redes de computadores, um sistema de comunicao de dados especfico ou
outro sistema discreto que apresente conteno de recursos. Como estudo de caso, na validao da
especificao proposta, os componentes foram implementados tendo como cenrio uma rede TCP/IP. Para
permitir isso, componentes que representam elementos de uma rede TCP/IP foram tambm projetados e
implementados. Ressalta-se que o ambiente pode simular modelos de outros tipos de redes (ATM, sem fio etc)
bastando que sejam implementados os componentes que representam as funcionalidades destas redes. Esse
trabalho est sendo continuado estendendo seus componentes para atender a modelagem de redes com
tecnologia sem fio e tambm investindo na construo de uma interface grfica para facilitar a construo de
novas ferramentas de simulao e a submisso dos modelos a serem simulados.
Referncias bibliogrficas.
[1] Szyperski, Clemens, Component Software Beyond Object-Oriented Programming, Addison-Wesley, 1999.
[2] Larman, C., Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design, Prentice
Hall, 1998.
[3] Rumbaugh, J., Booch, G., Jacobson, I., The Unified Modeling Language Reference Manual, Addison-Wesley,
1999.
[4] Sun Microsystems Inc; Java Beans Specification, 1999. Disponvel em http://www.sun.com/beans.
[5] Eckel, Bruce, Thinking in Java, 2a edio, Revision 12, New Jersey, Prentice-Hall, 1978.
[6] Rocha, Flvio Gonalves e Cabral, Maria Izabel Cavalcanti; Implementao e Validao de Componentes para a
Construo de Ambientes de Simulao de Redes TCP/IP. Dissertao de Mestrado, UFCG, 2002.
[7] Lula, Juliana C.L.A., Especificao de Componentes para um Ambiente de Simulao de Redes TCP/IP,
Dissertao de Mestrado, UFPB, 2001.
[8] GAMMA, Erich, HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Design Patterns: Elements of Reusable
Software. ISBN 0-201-63361-2, Addison-Wesley, 1994.
[9] Deitel, H. M., Deitel, P.J, JavaTM Como Programar, 3a edio, Porto Alegre, Bookman, 2001.
[10] Borland, Building Applications with JBuilder, 2002, disponvel em http://www.borland.com/techpubs/jbuilder
[11] Beck, K., Gamma, E., Test Infected: Programmers Love Writing Tests, 1998. Disponvel em:
http://www.junit.org.
[12] Kelton, W. D. et al.; Simulation with ARENA, McGraw-Hill, 1998.
[13] Golmie, Nada; Koenig, Alfred and Su, David; The NIST ATM Network Simulator Operation and
Programming, National Institute of Standards and Technology, August 1995.
[14] NS, Network Simulator; disponvel em http://www.mash.cs.berkeley.edu/ns, 1998.

! "
#$%&#' ( )*
+ , , , -. ,
/ 0 1
2 / ,3 0 4
5 5 / 5 6 !
0 ! 5 ,
/ 5
0, 6 1
! 2 ! / ,
/
6 7 1 2
, 62 ! 2 6 68
6 9 6 5 6 ,'
1 ! 6 6 ,
! " " #$%& " " '#$(& ')* $++,- #$$&

" " '. " " ' /
""'
0
1 1
#%& 2
#$+& 3
!
' 4 )
5 6 !
#$7& 8 #(& #9&
! 4
1 ! 1
! 4
:
! 1
0 7
4 ;
0
1 4
! 1
4 !
. /
2
#-& ; $
. 6 / !
3 4
2
04 4
. /
A trib u to s d e C a lid a d E x te rn a
a fe c ta
a fe c ta F u n c io n a lid a d F ia b ilid a d
a fe c ta a fe c ta
P ro p ie d a d e s C o m p le jid a d
E n te n d ib ilid a d
E s tru c tu ra le s C o g n itiv a
M a n te n ib ilid a d U s a b ilid a d
in d ic a
E fic ie n c ia P o rta b ilid a d
! "
2 1 4 )3!" #$9&
4 ! )3!"
< =.
* < =( ! *
< =./ : *0 1
:
8 " )
$ ) 4 7
8 ! ; :0 > 3 3
? 2 1 #9&
#"
$
%&' ( 85
% #' ( 85
% ' ( 85
%$ # ' ( 8
%$ #) ' ( 8
%$ #' ( 85 3 ?
;< = . / = ;< = . / + ;< => . /
%$ &' ( 85
%*&' ( 8 0
; . /
;' . /=
;< . /
$ # ' ( 3 3 ?
;< = . /
< = . /=
;< = . /
$ #) ' ( 3 3 ?
;< => . /
< => . /=
;< = . /
#&' ( 3 3 ?
; =. /
= . /=
; . /
&' ( 3 > 3
; . /
. /=
; . /
! ; @ 3
A > #$@& )3!"
( * A" 2 A" 2 .
/ 0
)3!"
L is t a d e
M o d e lo d e l
C a r a c t e r s t ic a s
D o m in io
M o d e lo d e
C asos de U so
E n c o n tra r
A c to re s y
C asos de E s tru c tu ra r
U so e l M o d e lo d e
A n a li s t a d e C asos de
S is t e m a s U so
R e q u is it o s
A d ic io n a le s N o P asos
G lo s a r io
D e s c r ip c i n d e
la A r q u i te c t u r a P r io riz a r
C asos
A rq u ite c to de Uso
D e ta lla r
u n C aso
E s p e c if ic a d o r
de Uso C aso de U so
de C asos de U so d e t a lla d o
P r o t o t ip a r la
In te r f a z d e
U s u a r io
D is e a d o r d e l P r o t o t ip o d e
In t e r f a z d e U s u a r io In te r f a z d e u s u a r io
+
; @ .
A" 2/
2
1 @
#" ,
%& % # % %$ # %$ #) %$ # %$ & %*& $ # $ #) #& &

+ ( - $7 B $9 - $ @+ ,B( ,7@ $B ,(
- , .
1
4 ! 4
1 3 6
#@,&#$-&#+& #B& 3
#@,&
#$,&
4 . /
C4 . 4 4 /
0 1 .80 83? 8 3?' 8 3?*
8 3? 8 30/
5 3
!
- $
A DE" #$&
:
& / 0"
* 0!
$ 02
:' )
2 :
!
8
. / 2
'1
! 4
1
2 4
. 7 +/ !
3 1
4
+ 2 2 4
.A" 2 / 4
" 2 +
2 4 :
" "
2 $(
4 4 2
1 @ 2
. /
4 .
/ 8
1 E
:
F 2 3 24 : 8 1
F 2 & 32 :G 4
1
F 2 3 24 : 8 1
F 2 & 32 :G 4
1
$ 5 ? 2
--)
! :
)
8 4 1 4
!
! 4
2
1 7
#" - ,
%& % # % %$ # %$ #) %$ # %$ & %*& $ # $ #) #& &

B B 7 + B $$ B $ ,,, ,-++ ,+-+ $ ,,, ,+,,
+ B - + + $, - $ @+, ,+,, ,+,, $ @,, ,(,,
- @ $7 @ $@ 7 $+ $ @ ,,, ,(,, ,@,, B +,, $ ,,,
6 9 @+ 9 @+ @$ -B $$ ,($( ,+-7 ,-+% @ %%( $ ,,,
7 + B - + + $, ( ,B@+ ,+,, ,+,, $ @,, ,(,,
8 - $$ - $- 9 @7 7 $ 777 ,B,9 ,79$ @ %+, $ ,,,
9 ( $% $ $+ $$ @B 9 ,((9 ,+%% ,-@7 @ $@+ ,$@+
: + ( - $7 + $( - $ @+, ,%@@ ,@%( $ B,, ,(,,
; % $@ $ $@ $$ @7 B $ $B% ,+@@ ,-%( $ %$- ,$-7
4 @- 7% $, %@ -, $$@ @- $ ,,, ,B-7 ,7+% $ +-@ ,-$%
% $@ + $@ $$ @7 B $ $B% ,+@@ ,-%( $ %$- ,%$-
@ ( 7 B - $, $ @ ,,, ,B,, ,-,, - ,,, $ +,,
- 7 B $ ( 7 $$ - ,%+, ,%@% ,@%7 @ ,,, ,777
6 7 + % + 7 ( @ $ +,, ,B@+ ,7%+ $ BB% @ 777
7 - 9 $ 9 % $B B ,BB% ,+B7 ,-7( @ @+, ,@+,
8 ( B - 9 9 $( % $ $-7 ,+,, ,+,, ,%+, ,+,,
9 - @- $ @, $$ 7$ 7 $ 777 ,B-+ ,7++ B ,,, ,@+,
: + @$ 7 @$ $$ 7@ - $ @+, ,B+B ,7-- - @,, ,B,,
4 . 1 0/ :
4 4
@ 3
4 2
2
6
+ ) 6
0
>
, A 4
4
3 @9
-6 & <
7@ !
1
3 H F)
4 1
) I ,,+
9+J 1
. -/ )
#" 6 * ! "
! "
# " # "
80." 3/ 43846 I,,,( ,$%$ I,-9B
83?." 3/ 438;6 3I,,,$ ,7B- I,$7(
8>3." 3/ ,@$$ I ,-,@ ,7-( I,$+%
8 3?' ." 3/ 43964 I,,,, ,7(7 I,$$%
8 3?* ." 3/ 43969 I,,,, ,@$@ I,79(
8 3?." 3/ 4399 I,,,, ,77( I,$%,
8 30." 3/ 437 ; I,,@- ,,B, I,($-
8 0." 3/ F,@%+ I,@B9 ,$+$ I,+-9
> 3?' ." 3/ ,$-@ I,+%7 ,7@- I,$9,
> 3?* ." 3/ F,$-@ I,+%7 F,7@- I,$9,
>3?0." 3/ ,$+, I,++- ,$$% I,B--
>>30." 3/ F,7,- I,@@, ,$,$ I,B9$
3 6 $( I,,+ ) ,-B(- #@$& G, G,

0 - .
G, /
80 83? 8 3?' 8 3?* 8 3? 8 30
,-B(- 2 1 8>3 8 0 > 3?' > 3?* >3?0
>
)
G, 1
4 !
1
-7 /
& / / A 4
6 .+@@ $( @9 /
4 1 F 1 #7& 3
& / / 2
& / / ! +
6 2
3
2
/+ )
!
4 3
4
4
>
& / / ) 4
#$B& :
F " !
4
4
F ) !
F ! ! 4
!
7 * !# " +
! 4
1
! 1
#$+& !
1
L
4
1 80 83? 8 3?' 8 3?*

8 30 8 1 8>3 8 0
> 3?' > 3?* >3?0 >>30
!
) 1
3
0 . /
!
0
4 1
4 :
1 #@& !
6
:8 0 8>3
2

!
1
&
! " 0) D '
" ? 4 .?' @,,7F,@%7%F ,@F,@/ ? 1
'1 )0
& &
" ( .; @/
(* 0
0 . : : /:MMMMMMMMMMMMM
$ N3 ! A * = O
@ N3 * = / = O
7 N! ' <
* = O
- N! ' ' O
+ N / = '
< O
( / > 0
$ 2 $ * = < 0 1
@ ) $ * = * =
5 / =
7 ? & !* = * "
* > ?$ <
' ? 0 < '
! / * =
- ) D K * "
* > ?$
#$&K P > G <? ?0" ! : F =

= / 4 4 $-.B/ $9(( %@(F%7(
#@& K P ; ) ; 2 <P H ; ! =
= / 4 4 @+.-/ $999 -7+F-7%
#7& 2 P H ! ! ) " <?

=? > ')!>8F9+F,7 ' ) ! > 8 Q $99+
#-& 2 P R SC G 0 2 < ' E ; * F

* : ' ) = = 7 ;8@A8B@ /
4 4 7; / : $99(
#+&2 P ) 0 ; ; G Q 3 ?1 F; <! ) * F
* 0 " 3 :) 0 ; = /
4 4 -.-/ $999 7(%F-,-
#B& " 3 " D <! K ' )

? = ' / = 7 45 K -7 8T$+ .@,,$/
#%& 8 ; <" ) 3 ' = / ! 9

4G " * !S P 2. / ) @,,$ 7-F++
#(&; D 4 ; > R " 3 <' " " "

3 ) =C 6 4 1 5 6 /
(< DB%%$* 0 .3 / 7F+ " @,,7
#9&; D 4 ;> R " 3 <' " ! '

) 3 = @7 E :7 / = 7 45( E =F@* 2 8
) G Q .; / $F@ ) .@,,7/
#$,&; D 4 ; > " 3 <" 3 ) =G C 4

/ 5H < 0 R ! 3 8 P RD . / 0
.! 6 / $@F$- 8 @,,7 7,7F7$-
#$$&')*U'! :')* '! $++,- ?>@:$99( @: 0

$99(
#$@&R 'P D > R =7 / < ! 0 S

$999
#$7&" " <" 3 ) ? = C 5 / -9.$/

$999
#$-&3 3 0 K 2 ! ) ) !F :0 > ;
) ! ! :0 ; Q 0 " .@,,,/ 7-+F7++
#$+& ) 2 3 <' 3 " =' / 0 " . /

2 ' ? 3 $99B +7F%-
#$B& ) P 0 ! 0 ? " R 0 H ! H " K Q

< > ! ) ! = 4 7 B%%B
5 / 4 4( F%B*
#$%&) ! ' .)!'/ ? " " :D '

) 3 $99+ ' :UU U U
#$(&) ! ' .)!'/ " " ' . " " ')" / $$

" @,,@ ' :UU U U
#$9& ) 3 ! " ) L $, *
" D 8 .@,,@/ 0 :UU U F U O U,@F,+F,7
#@,&S > 3 GV " * " > P S 1 0 /

4 49 H 0 3 @,,,
#@$& :UU Q QU> ) U" M

Apoio Documentao em um Ambiente de Desenvolvimento de

Software
Vanessa B. Nunes, Andrea O. Soares, Ricardo A. Falbo

Mestrado em Informtica, Universidade Federal do Esprito Santo
Av. Fernando Ferrari, CEP 29060-900, Vitria - ES Brasil
falbo@inf.ufes.br
Abstract
Documentation is a time-consuming task that is performed through the whole software process. However,
many times, it is neglected, due to several problems. In fact, software tools to support documentation tasks
are very important. In this paper, we present the approach defined to deal with documentation integration in
ODE, an ontology-based software development environment. This approach includes defining an ontology of
software artifact and a software tool that supports documentation in ODE, called XMLDoc. XMLDoc was
developed based on the software artifact ontology and uses XML to describe document contents.
1. Introduo.
Um aspecto essencial para a qualidade de um sistema de software a sua documentao. Artefatos de

software so peas fundamentais em um processo de desenvolvimento. Eles so produzidos e consumidos por
atividades do processo e, assim, esto presentes em todo o ciclo de vida de desenvolvimento de software.
Entretanto, muitas vezes, a documentao negligenciada em decorrncia de fatores como falta de uma
poltica organizacional que valorize essa tarefa, falta de ferramentas para apoiar a documentao e prazos
exguos, o que faz com que desenvolvedores optem por deixar a documentao em segundo plano.
Ferramentas provendo facilidades de documentao permitem agilizar o desenvolvimento de software,

realizando algumas tarefas automaticamente, e permitem que modificaes sejam mais facilmente realizadas,
simplificando a tarefa de manuteno. Entretanto, difcil encontrar ferramentas nas quais a documentao
possa ser feita de forma integrada, customizada e consistente. A maioria das ferramentas no oferece um bom
suporte documentao, de forma que o desenvolvedor se v, muitas vezes, usando um proces sador de texto
para documentar atividades do processo de software.
Este artigo discute como a documentao integrada ao processo de software no contexto do ambiente
ODE (Ontology-based software Development Environment) [1]. ODE um ambiente de desenvolvimento de
software (ADS) baseado em ontologias, isto , sua infra-estrutura fundamentada em ontologias de
engenharia de software. A padronizao de conceitos provida por uma ontologia permite que a comunicao
entre as ferramentas que compem o ambiente seja aprimorada [1]. Dentre as ontologias que compem a base
ontolgica de ODE, duas delas merecem destaque no contexto deste trabalho: a ontologia de processo de
software [2] e a ontologia de artefato de software. Essas ontologias, que esto integradas, definem os
principais conceitos relacionados a artefatos de software e formam a base para a integrao da documentao
em ODE. De fato, a ontologia de artefato desenvolvida subdividida em ontologias mais especficas, a saber:
ontologia de documento, ontologia de diagrama e ontologia de artefato de cdigo. A ontologia de documento
considera o fato de documentos normalmente no se apresentam apenas constitudos de descries textuais
contnuas e sim atravs de uma estrutura bem definida, composta por sees . Assim, ela trata, tambm, de
aspectos relacionados a padres organizacionais para a produo de documentos. A ontologia de diagrama
tem por base o meta-modelo da UML e descreve os principais elementos que constituem um diagrama.
Finalmente, a ontologia de artefatos de cdigo considera as peculiaridades deste tipo de artefato de software,
incluindo as linguagens de programao utilizadas para sua elaborao. Devido s limitaes de espao, neste
artigo discutida apenas a ontologia de documentos de software.
Com base na ontologia de documentos, foi desenvolvida XMLDoc, uma ferramenta de apoio
documentao em ODE. XMLDoc visa prover apoio documentao de forma nica e consistente em todo o
ambiente, de modo a garantir uma apresentao integrada, usando XML. XMLDoc gera os documentos com
base nos dados do repositrio central de ODE, favorecendo sua atualizao e consistncia. Alm disso,
oferece funcionalidades para apoiar a definio de modelos de documento, o que permite padronizao,
atravs da definio da estrutura de tipos de documento. Atravs da associao dos modelos de documento a
folhas de estilo, busca-se garantir integrao de apresentao.
Este artigo est estruturado da seguinte forma. A seo 2 discute brevemente o tema documentao e sua
relao com ADSs. A seo 3 apresenta brevemente o ambiente ODE e a ontologia de documentos de
software utilizada pelo ambiente. Na seo 4, apresentada XMLDoc, a ferramenta de apoio documentao
de ODE. A seo 5 discute trabalhos correlatos e apresenta as concluses desse trabalho.
2. Documentao e Ambientes de Desenvolvimento de Software.
A documentao de software uma atividade essencial no processo de desenvolvimento de software.

atravs dela que a evoluo do software registrada para que sejam criadas as bases necessrias para as
etapas posteriores do processo de software, incluindo treinamento, utilizao e manuteno de software [3].
Muitos tipos de documentos so produzidos ao longo do processo de software, tais como propostas, planos de
projeto, especificaes de requisitos e de projeto, dentre outros. Assim, comum uma organizao gastar de
20 a 30% de todo o esforo de desenvolvimento na elaborao de documentos [4]. Os documentos, por sua
vez, tm de apresentar qualidade, para que atividades de avaliao e manuteno possam ser realizadas com
sucesso [3]. Entretanto, diversos fatores, como prazos apertados, altos custos, impreciso e dificuldade na
manipulao de documentos, podem comprometer o processo de documentao, levando a documentos
incompletos, desatuali zados e inconsistentes. De fato, deve-se considerar que a elaborao de uma
documentao de qualidade to importante quanto a qualidade do software em si [3].
Neste contexto, importante o uso de ferramentas para apoiar o processo de documentao de software.
Tais ferramentas, idealmente, deveriam apoiar todas as atividades do processo de software, j que todas elas
envolvem algum tipo de documentao. Dentre as ferramentas de documentao mais utilizadas, destacam-se
os editores de textos e os editores de hipertextos. Outras ferramentas incluem extratores de documentao,
que extraem documentos de outros artefatos, tal como cdigo, e compositores de documentao, que geram
documentos a partir, por exemplo, de modelos construdos em uma ferramenta CASE de modelagem.
Um problema bastante comum no uso de ferramentas de documentao o pouco suporte oferecido ao

processo de documentao em si, incluindo a identificao dos documentos e suas relaes com as atividades
do processo e padres organizacionais, o projeto da estrutura dos documentos, incluindo a definio de
modelos de documento, e a prpria elaborao de documentos. Ferramentas de documentao integradas a um
Ambiente de Desenvolvimento de Software (ADS), contudo, podem atenuar alguns desses problemas. Um
ADS pode ser visto como um conjunto de ferramentas integradas que facilitam a realizao de atividades da
engenharia de software, apoiando todo o ciclo de vida do produto de software desenvolvido [5]. Um ADS
deve suportar a definio de processos de software e se utilizar desta definio para estabelecer uma ligao
explcita entre as ferramentas do ambiente e os processos definidos, incluindo as atividades do processo e os
artefatos gerados e consumidos por elas. Assim, natural pensar a integrao da documentao em um ADS.
Em um ADS, a identificao da documentao necessria e a relao dos artefatos com outros ativos do
processo de software, principalmente atividades, ferramentas e procedimentos, so tratadas na prpria
definio do processo no ambiente, cabendo ferramenta de documentao tratar aspectos mais especficos
do processo de documentao, tais como a definio de padres para a elaborao de documentos e o apoio
elaborao em si dos documentos a partir desses padres. Esta a abordagem do ambiente ODE.
3. ODE: Um Ambiente de Desenvolvimento de Software Baseado em Ontologias.

ODE (Ontology-based software Development Environment) [1] um ADS Centrado em Processo, que tem
sua fundamentao baseada em ontologias. A premissa do projeto de ODE a seguinte: se as ferramentas de
um ADS so construdas baseadas em ontologias, a integrao dessas ferramentas pode ser facilitada, pois os
conceitos envolvidos esto bem definidos nas ontologias. Essa uma das principais caractersticas que
distingue ODE de outros ADSs: sua base ontolgica.
Uma ontologia um artefato de engenharia, constitudo por um vocabulrio especfico usado para
descrever uma certa realidade, mais um conjunto de suposies explcitas referentes ao significado pretendido
para os termos usados no vocabulrio. Esse conjunto de suposies tem, usualmente, a forma de uma teoria
lgica de primeira ordem, onde os termos do vocabulrio aparecem como nomes de predicados unrios ou
binrios, respectivamente chamados de conceitos e relaes. No caso mais simples, uma ontologia descreve
uma hierarquia de conceitos relacionados (taxonomia); em casos mais complexos, axiomas so adicionados
para expressar outros relacionamentos entre conceitos e para restringir a interpretao pretendida [6].
A arquitetura de ODE reflete sua base ontolgica, sendo composta por dois nveis: o Nvel Base e o Meta-
Nvel. O nvel base define as classes que controlam as tarefas realizadas no ambiente e suas ferramentas. O
meta-nvel, ou pacote Conhecimento, define as classes que descrevem o conhecimento sobre os objetos do
nvel base. As classes do pacote Conhecimento so derivadas diretamente de ontologias e seus objetos podem
ser vistos como itens de instanciao de uma ontologia. Elas constituem o conhecimento do ambiente, que
pode ser utilizado por todas as ferramentas que o compem [7].
No contexto da integrao da documentao em ODE, as ontologias de processo de software [2] e de

artefato de software desempenham um importante papel. A primeira define os principais conceitos
relacionados a processos de software e a base para a integrao de processo em ODE [7]. A segunda, por
sua vez, define os principais aspectos relacionados documentao de software e a base para a integrao
da documentao em ODE. Uma vez que um artefato um ativo do processo de software, este conceito est
presente tanto na ontologia de processo de software [2] quanto na ontologia de artefatos de software. De fato,
a ontologia de artefato foi construda integrada de processo.
O principal objetivo de uma ontologia de artefato de software favorecer o compartilhamento e o reuso

dos diversos artefatos produzidos em um processo de software. Deve-se observar, no entanto, que no
razovel construir uma ontologia nica para artefatos de software, uma vez que, para cada tipo de artefato
(documento, diagrama, artefato de cdigo, componente de software, dentre outros), pode-se vislumbrar
caractersticas diferentes. Desta forma, partindo-se da ontologia de processo de software desenvolvida em [2],
que define aspectos relacionados a artefatos de forma geral, foram desenvolvidas ontologias especficas para
alguns tipos de artefatos, a saber, documento, diagrama e artefato de cdigo. Devido a limitaes de espao, a
seguir apresentada apenas a ontologia de documentos. Essa ontologia foi desenvolvida usando a abordagem
sistemtica para construo de ontologias descrita em [2], que preconiza o uso de LINGO como linguagem de
modelagem de ontologias e lgica de primeira ordem para a sua formalizao. A figura 1 mostra a notao
principal de LINGO, juntamente com os axiomas impostos pela notao Todo-Parte
propriedade
relao
conceito
(A1) x parte(x,x)
Super-tipo Todo (A2) x,y parte(y,x) todo(x,y)
(A3) x,y parte(y,x) parte(x,y)
(A4) x,y,z parte(z,y) parte(y,x) parte(z,x)
(A5) x,y disjunto(x,y) z parte(z,x) parte(z,y)
Sub-tipo 1 Sub-tipo N Parte 1 Parte N (A6) x atomico(x) y parte(y,x)
Figura 1 Parte da Notao de LINGO e Axiomas Impostos pela Relao Todo-Parte.
Para tratar os aspectos envolvidos na documentao de software, a ontologia de documentos deve ser capaz
de responder s seguintes questes de competncia:
1. A quais documentos um roteiro se aplica?
2. Qual a estrutura definida por um modelo de documento?
3. Qual a estrutura de um documento?
4. Um documento est aderente a um modelo de documento?
A figura 2 mostra o modelo em LINGO da ontologia de documento. Nesse modelo, os conceitos Artefato,
Procedimento e Roteiro foram importados da ontologia de processo de software, indicando a integrao entre
essas ontologias. Vale observar, ainda, que as notaes todo-parte preenchidas indicam composio, enquanto
as no preenchidas indicam agregao. Os axiomas da figura 1, porm, aplicam-se a todas as relaes todo-
parte.
sub-artefato Procedimento
dependncia
Artefato
Roteiro
Documento aplicao
Modelo de
Documento
1,1
0,1 Seo modelo opcional

1,1
sub-seo
sub-seo
0,1 Modelo de
correspondncia Seo
Figura 2 A Ontologia de Documentos de Software.
Documentos so artefatos de software no passveis de execuo, constitudos tipicamente de declaraes

textuais, normalmente associados a padres organizacionais (roteiros) que definem a forma como eles devem
ser produzidos. Exemplos de documentos incluem: documento de especificao de requisitos, plano de
projeto, plano de qualidade, relatrio de avaliao da qualidade, entre outros.
A relao de dependncia entre artefatos transitiva, ou seja, se um artefato a1 depende de um artefato a2

e este depende de um terceiro artefato a3, ento o primeiro (a1) depende do terceiro (a3):
( a1, a2, a3) (dependencia(a1, a2) dependencia(a2, a3) dependencia(a1, a3))
importante destacar, ainda, que se um artefato a1, parte do artefato a2, depende de outro artefato a3,
ento a2 tambm dependem de a3. Alm disso, um artefato-todo depende sempre de suas partes.
( a1, a2, a3) (subartefato(a1, a2) dependencia(a1, a3) dependencia(a2, a3))
( a1, a2) (subartefato(a1, a2) dependencia(a2, a1))
Documentos normalmente no se apresentam apenas constitudos de descries textuais contnuas e sim

atravs de uma estrutura bem definida, composta por sees. Sees, por sua vez, so tipicamente constitudas
de declaraes textuais, de outras sees e/ou de outros artefatos. importante destacar que, se uma seo
pertence a um determinado documento, suas sub-sees tambm pertencem a tal documento.
( s1, s2, d) (partedoc(s1, d) subseo(s2, s1) partedoc(s2, d))
Se um artefato compe uma seo de um documento, ento ele um sub-artefato desse documento.
( s, d, a) (partedoc(s, d) partesec(a, s) subartefato(a, d))
Alm disso, se um artefato compe uma seo, ele tambm compe as super-sees dessa seo.
( a, s1, s2) (partesec(a, s1) subseco(s1, s2) partesec(a, s2))
Roteiros so utilizados como diretrizes para a elaborao de documentos, provendo padronizao e

facilitando a interpretao de tais documentos. Um modelo de documento um tipo especial de roteiro que
estabelece a estrutura de um documento e instrues para sua elaborao. Modelos de documentos so
compostos de modelos de seo, que definem instrues para a elaborao de sees de documentos aderentes
ao respectivo modelo de documento. Um modelo de seo pode ser opcional ou obrigatrio. Um modelo de
seo opcional aquele que no necessita de uma seo correspondente nos documentos que aplicam o
modelo de documento ao qual pertence, enquanto um modelo de seo obrigatrio necessita de uma seo
correspondente para ele. Da mesma forma que as sees, um modelo de seo pode ser decomposto em outros
modelos de sees.
Apesar dos modelos de documentos serem roteiros que estabelecem a estrutura de um documento e
instrues para sua elaborao, nada garante que um documento criado com base em um determinado modelo
de documento esteja aderente a ele. Para que um documento esteja aderente a um modelo de documento, deve
possuir uma seo correspondente para cada modelo de seo obrigatria do modelo de documento.
( d, md) aderente(d, md) (( ms)( partemodelo(ms, md) opcional(ms))
(( s) (partedoc(s, d) correspondencia(s, ms))
4. XMLDoc: A Ferramenta de Apoio Documentao de ODE.
A documentao uma atividade de apoio que ocorre ao longo de todo o processo de software. De fato,
todas as atividades do processo de software so documentadas de alguma forma. Assim sendo, o objetivo
principal de XMLDoc fornecer um meio padronizado de documentao para o ambiente ODE, de modo que
no haja necessidade de cada ferramenta isoladamente ter de oferecer alguma funcionalidade de
documentao especfica para a atividade por ela apoiada.
Alguns dos principais requisitos de XMLDoc incluem: (i) Os desenvolvedores devem ter acesso a
documentos atualizados e consistentes; (ii) Deve-se utilizar modelos para estabelecer como os documentos
devem ser elaborados, de forma a auxiliar os desenvolvedores na realizao dessa atividade e assegurar que
questes importantes sejam sempre tratadas; (iii) Documentos e diagramas devem ser consistentes entre si.
Uma tecnologia que tem merecido destaque neste contexto a tecnologia XML (eXtensible Markup
Language - Linguagem de Marcao Extensvel). XML promete ser um padro de nvel intermedirio que
pode permitir a criao de ferramentas de software mais flexveis e reusveis, resolvendo diversos problemas
de integrao entre ferramentas [5], dentre eles os problemas de integrao de documentao.
Usando a tecnologia XML, XMLDoc gera os documentos sempre com base nos dados do repositrio
central, favorecendo a atualizao e a consistncia do documento. A criao de documentos dinmica, ou
seja, um documento s efetivamente gerado no instante em que solicitada a exibio do mesmo. Esta
caracterstica importante, pois garante que o documento est sempre atualizado. Alm disso, XMLDoc
permite cadastrar modelos de documento. Estes modelos so a base para a padronizao da documentao,
atravs da definio da estrutura dos diversos tipos de documentos, e, atravs da associao destes modelos a
uma folha de estilo, favorecem integrao de apresentao. Assim, possvel apoiar a elaborao de
documentos a partir dos modelos de documento definidos, facilitando a realizao desta atividade.
A figura 3 mostra as principais classes de domnio de XMLDoc. Vale ressaltar que a arquitetura em dois
nveis de ODE preservada, ou seja, as classes do pacote Documentao dizem respeito aos documentos
produzidos em um projeto de software especfico. As classes do pacote Conhecimento mostradas referem-se
ao conhecimento sobre os artefatos e procedimentos, estes ltimos especializados para tratar modelos de
documentos e sua estrutura. Em ambos os casos, fcil perceber que esses modelos foram construdos com
base na ontologia de artefato de software, tendo sido adicionados alguns atributos e associaes, especficos
para tratar requisitos de XMLDoc, tais como o atributo folhaEstilo em ModeloDocumento e os atributos
ordem e instrues em ModeloSeo.
5. Concluso.
Existem muitas ferramentas de apoio documentao disponveis, inclusive comercialmente. Pressman [4]
no site de seu livro (www.mhhe.com/engcs/compsci/pressman/ole_linkedcontent/casetools.html) aponta para
diversas delas, tais como JVision, Cradle, SoDA e DocExpress. Analisando essas e outras ferramentas, pode-
se notar que, do ponto de vista de elaborao de documentos, XMLDoc no apresenta nenhuma
funcionalidade nova, apenas procura disponibilizar aquelas que foram consideradas as mais importantes.
ConhecimentoProcedimento ModeloDocumento
(from Conhecimento) (from Conhecimento) 0..* Documento
folhaEstilo (from Documentao)
1
1
1
1..*
ConhecimentoRoteiro 0..*
ModeloSecao
(from Conhecimento) (from Conhecimento) Secao
0..1 titulo (from Documentao)
1 0..* 0..1
ordem corpoTexto
0..*
opcional titulo
instrucoes
0..* 0..*
0..*
0..* +subseo
+subseo +corpo
aplica-se a 0..1 +corpo 0..1
Artefato
ConhecimentoArtefato
0..1 1 0..* (from Controle)
(from Conhecimento)
nome
tipo
0..* descricao
0..*
0..*
+subartefato 0..*
+subartefato
Figura 3 Modelo de Classes de XMLDoc.
As caractersticas marcantes de XMLDoc so: (i) ser baseada em uma ontologia (ii) estar integrada a um
ADS e, por conseguinte, se utilizar de toda a funcionalidade de controle de processos de software disponvel
no ambiente. Deste modo, a identificao dos documentos e suas relaes com as atividades do processo e
padres organizacionais estabelecida na definio de processos de ODE [7].
5. Agradecimentos .
Os autores agradecem ao CNPq pelo apoio financeiro a este trabalho.
6. Referncias.
[1] R.A. Falbo, A.C.C. Natali, P.G. Mian, G. Bertollo, F.B. Ruy. ODE: Ontology-based software Development
Environment, IX Congreso Argentino de Ciencias de la Computacin, La Plata, Argentina, 2003, pp 931-940.
[2] R.A. Falbo, A.R.C. da Rocha, C.S. M enezes, A Systematic Approach for Building Ontologies. In: Proceedings of
the 6th Ibero-American Conference on Artificial Intelligence, Lisbon, Portugal, 1998.
[3] R. Sanches, Documentao de Software, In: Qualidade de Software: Teoria e Prtica, Prentice Hall, So Paulo,
2001, pp 54-59.
[4] R.S. Pressman. Engenharia de Software, 5a edio, McGraw -Hill, Rio de Janeiro, 2002.
[5] Harrison, W.; Ossher, H.; Tarr, P. Software Engineering Tools and Environments: A Roadmap, In: Proc. of The
Future of Software Engineering, ICSE2000, Limerick, Ireland, 2000.
[6] N. Guarino, Formal Ontology and Information Systems. In: Proceedings of the First Int. Conference on Formal
Ontology in Information Systems, Trento, Italy, June 1998.
[7] F.B. Ruy, G. Bertollo, R.A. Falbo, Apoio Baseado em Conhecimento Integrao de Processos em ODE, In:
Proc. 3rd JIISIC2003, Valdivia, Chile, 2003.
Modelagem Organizacional Utilizando Ontologias e Padres de Anlise
Renata I. Cota, Credin S. Menezes, Ricardo A. Falbo

Mestrado em Informtica, Universidade Federal do Esprito Santo
Av. Fernando Ferrari, CEP 29060-900, Vitria - ES Brasil
{credine, falbo}@inf.ufes.br
Abstract
The development of integrated information systems for corporations leads, generally, to great investments
of resources and long stated periods of development, as much when the development is in-house, as in the
case of the purchase of an integrated solution of some supplier of Enterprise Resource Planning systems. We
consider a new approach based on the customization of a generic conceptual model for corporations to
produce an enterprise model, followed by a mapping to an enterprise logical infrastructure. The conceptual
model uses ontologies and the logical infrastructure uses analysis patterns. Thus, it is possible, first, to make
a formal description of the common concepts using ontology, and then its refinement to analysis patterns, so
that, in the case of modeling a specific corporation, these models can be used and extended to deal with
specific enterprises issues.
1. Introduo.
As organizaes tm reconhecido a grande importncia dos Sistemas de Gesto Empresarial (Enterprise
Resource Planning ERP), capazes de integrar todas as aplicaes de uma corporao. Tais sistemas
favorecem transaes mais rpidas, permitem um melhor gerenciamento financeiro, apiam o
compartilhamento de dados e permitem um mapeamento dos processos-chave, regras de deciso e estruturas
de informao, tornando mais explcito o conhecimento dos processos tticos dentro da corporao.
Contudo, diversos problemas tcnicos e organizacionais podem ser apontados na adoo desses sistemas,
tais como [1]: o alto custo e a demanda elevada de tempo, devido inerente complexidade de uma
corporao, e a necessidade de reestruturao da organizao, uma vez que, de maneira geral, as corporaes
precisam se adaptar s prticas de negcios embutidas nos modelos de referncia de tais sistemas. Podemos
observar, ainda, que na prtica corrente no h a construo de um modelo das empresas e sim uma
adequao das empresas ao software ERP utilizado.
Pelo fato dos processos de negcios serem muito complexos, a modelagem conceitual um meio de tratar
a complexidade da realidade, ajudando a entender melhor os processos do negcio e a procurar a melhor
forma de dar suporte de software necessrio. Entretanto, no levantamento de requisitos e definio de um
modelo conceitual do sistema, leva-se muito tempo, pois h grande dificuldade de se compartilhar o
conhecimento entre os engenheiros de software e os especialistas do negcio. A falta de uma terminologia
comum pode levar a interpretaes erradas e pode-se ter muita dificuldade para se chegar a uma definio
precisa do problema a ser tratado.
necessrio, pois, que sejam estudadas novas abordagens de modelagem conceitual, permitindo que se
diminua o tempo que gasto no levantamento de requisitos e que seja facilitada a anlise dos processos de
uma corporao.
Neste trabalho proposta uma abordagem para apoiar a modelagem conceitual utilizando ontologias e
padres de anlise. Ontologias so usadas para definir os conceitos comuns e a seguir prope-se o
refinamento dessas ontologias em padres de anlise para apoiar mais diretamente a atividade de
especificao de requisitos. A seo 2 discute ontologias e padres de anlise, procurando apontar diferenas,
similaridades e aspectos complementares. A seo 3 trata de como a modelagem conceitual pode ser apoiada
pelo uso conjunto de ontologias e padres de anlise. A seo 4 define uma infra-estrutura de apoio
modelagem conceitual de corporaes, apresentando uma ontologia de corporaes, alguns padres de anlise
e uma ferramenta de apoio modelagem conceitual de corporaes usando ontologias e padres de anlise.
Na seo 5, so discutidos trabalhos correlatos. Finalmente, a seo 6 apresenta as concluses desse trabalho.
2. Ontologias e Padres de Anlise.
crescente o uso de ontologias para estabelecer uma linguagem comum para o compartilhamento e a
reutilizao do conhecimento sobre domnios de aplicao durante o desenvolvimento de software. Neste
contexto, um importante objetivo das ontologias tornar explcito o significado dos conceitos para melhorar a
comunicao.
Uma ontologia define um vocabulrio especfico usado para descrever uma certa realidade, mais um
conjunto de decises explcitas fixando de forma rigorosa o significado pretendido para o vocabulrio. Uma
ontologia envolve, ento, um vocabulrio de representao que captura os conceitos e relaes em algum
domnio e um conjunto de axiomas, que restringem a sua interpretao [2].
Segundo Uschold et al. [3], ontologia o termo usado para se referir ao entendimento compartilhado em
algum domnio de interesse, o qual pode ser usado como uma infra-estrutura unificada para resolver
problemas, evitando a redescoberta de resultados equivalentes. Por exemplo, a definio de uma ontologia
para corporaes possibilita que conceitos j estabelecidos e que so comuns a corporaes diferentes possam
ser aplicados no desenvolvimento de sistemas em vrias corporaes. Isso diminui o tempo que se leva no
levantamento de requisitos, pois, para uma corporao especfica, usada uma especializao da ontologia
mais geral, na qual os conceitos comuns j esto definidos e podem ser utilizados, prosseguindo no
levantamento de conceitos particulares da corporao especfica.
Gruninger et al. [4] identificam trs principais categorias no espao de aplicaes de ontologias: (i)
comunicao, (ii) inferncia computacional e (iii) reutilizao e organizao do conhecimento.
Quanto aplicao para comunicao, ontologias permitem compartilhar conhecimento e facilitam a

comunicao entre pessoas com diferentes vises e pontos de vista, sem se fixar no contexto particular de
cada um. Usando ontologias, pode-se construir um modelo normativo do sistema, permitindo identificar
explicitamente as conexes entre os diferentes modelos do sistema. So estabelecidas definies sem
ambigidade para os termos usados em um sistema de software, integrando diferentes perspectivas dos
usurios. Pessoas de posies diferentes na organizao tm viso diferente do que a organizao faz, dos
objetivos e de como alcanar esses objetivos. Usando ontologias, a integrao pode ser alcanada, levando as
pessoas a chegarem a um acordo [4].
No que se refere inferncia computacional, ontologias facilitam a captura e representao do

conhecimento em nveis mais abstratos. Ontologias oferecem o esqueleto do conhecimento e uma infra-
estrutura para integrar bases de conhecimento no nvel de conhecimento, independente de uma
implementao particular [5].
Finalmente, do ponto de vista da reutilizao e organizao do conhecimento, ontologias podem ser usadas
para estruturar ou organizar bibliotecas ou repositrios e planejar e dominar a informao [4].
Segundo Sowa [6], a escolha de categorias ontolgicas o primeiro passo no desenvolvimento de qualquer
s istema computacional. No importa como as chamemos, classes, relaes, tipos ou qualquer outro nome
adotado por uma subrea especfica da computao. A seleo dessas categorias que determina os limites de
uma aplicao especfica ou mesmo de uma famlia de aplicaes. Qualquer incompleteza, distoro ou
restrio embutida em nossa escolha inevitavelmente limitar a generalidade dos artefatos computacionais
resultantes.
Ontologias tm grande importncia na era das organizaes baseadas em conhecimento [7]. Entre as
pessoas que adotam uma ontologia, seus termos so usados para perguntar e responder questes, fazer
asseres, oferecer lembranas, descrever prticas e discutir investigaes pertinentes conduta do
gerenciamento do conhecimento. Na construo e aplicao de ontologias, importante deixar claros dois

pontos importantes [7]: de um lado est a definio da prpria ontologia, os conceitos usados no domnio e
suas relaes; do outro lado, esto os fatos descritos por ela. Esses fatos no fazem parte da ontologia, mas
so por ela estruturados. Assim, uma ontologia deve descrever aspectos gerais, vlidos para quaisquer
sistemas no mesmo domnio, contendo apenas elementos essenciais. A adio de detalhes em uma ontologia a
torna mais especfica e, portanto, menos reutilizvel. Idealmente, a ontologia deve ser mantida to simples e
ampla quanto possvel.
Padres de software (software patterns) tambm permitem o compartilhamento de uma conceituao,

atravs da definio e da representao explcita de um problema e da soluo adotada em determinado
contexto. Padres de software formalizam solues para problemas recorrentes no desenvolvimento de
software, com base na experincia de especialistas, permitindo que estas solues possam ser reutilizadas em
vrias outras situaes, por outros especialistas. Na engenharia de software, padres so usados para
descrever solues de sucesso para problemas de software comuns. Estes padres refletem a estrutura
conceitual das solues e podem ser aplicados vrias vezes na anlise, projeto e produo de aplicaes, em
um contexto particular [5]. O uso pelos engenheiros de software de solues j conhecidas e testadas ajuda a
aumentar o nvel de abstrao, a produtividade e a qualidade dos projetos nas vrias fases do desenvolvimento
de sistemas.
Fowler [8] define padro como uma idia que tem sido til em um contexto prtico particular e ser
provavelmente til em outros contextos. usado o termo idia pelo fato de um padro poder ser qualquer
coisa. Contexto prtico vem do fato de que os padres so desenvolvidos a partir de experincias prticas
de projetos reais. Os padres so freqentemente descobertos e no inventados. Isso verdade, por exemplo,
quanto a certos modelos de anlise, que se tornam padres de anlise somente quando descoberto que eles
podem ter uma utilidade comum. Quando um novo projeto desenvolvido, algumas idias novas podem
surgir e vir a ser padres no futuro, entretanto, isso depende de que venham a ser usadas novamente e
finalmente di entificadas como padres. Assim, padres so coisas que os desenvolvedores conhecem e
descobrem que podem ser teis em outros contextos. Com padres de software, apresentada uma
aproximao genrica para resolver um problema, mas eles tm que ser trabalhados e adaptados para casos
especficos.
Padres de software so geralmente pequenos e especficos o suficiente para que a comunidade possa
valid-los efetivamente. Pode-se dizer que um padro uma combinao de unidades significativas que
ocorrem em determinado contexto. O vocabulrio oferecido por esses padres ajuda a tornar claro o
pensamento, alm de aumentar o nvel de abstrao, possibilitando a discusso entre especialistas e novatos,
sendo uma unidade transfervel de conhecimento especializado. Estas solues j conhecidas e testadas so
mais facilmente instanciadas ou especializadas para compor a soluo completa para um projeto, aumentando
em muito a produtividade e qualidade.
H diversos tipos de padres de software, tais como padres de anlise, de projeto e de arquiteturas de
software. Sob a perspectiva deste trabalho, a classe dos padres de anlise a de maior interesse, uma vez que
estes capturam os objetos do domnio e seus inter-relacionamentos. Padres de anlise so definidos a partir
de modelos conceituais de aplicaes, que descrevem modelos de processos de negcios resultantes da fase de
anlise de requisitos do desenvolvimento de software.
Um padro de anlise um conjunto de classes e associaes que tem algum significado no contexto da
aplicao, isto , um modelo conceitual de uma parte da aplicao [9]. Para reutilizar um padro de anlise em
uma aplicao, preciso reinterpretar cada classe no padro como uma classe correspondente no novo
sistema. A estratgia a abstrao do modelo inicial, a partir do qual novos modelos podem ser
desenvolvidos. Por outro lado, um bom modelo de anlise de um subsistema de um sistema complexo pode
ser abstrado e tornar-se um padro de anlise que pode ser usado em outras aplicaes.
Uma aplicao de padres de software a utilizao de frameworks, contendo um certo nmero de padres
de software implementados dentro deles, podendo conter uma implementao bsica ou algumas
especificaes da interface, ajudando a encapsular descries e decises-chave da arquitetura de software,
podendo ser implementados depois por um componente ou at mesmo atravs de vrios componentes, o que
facilita o gerenciamento da complexidade atravs desses componentes reusveis [10].
Estudando ontologias e padres de software, possvel observar que ambos podem ser associados de
forma a contribuir para a modelagem de sistemas computacionais. Ontologias, em um nvel de abstrao mais
alto, estabelecem uma terminologia comum e no-ambgua para o domnio em questo; padres de software,
j no nvel de engenharia de software, embutem solues de modelagem j testadas. Juntos, ontologias e
padres de anlise podem ser usados tanto para descrever o domnio para o qual ser desenvolvido um
sistema como tambm para descrever o sistema propriamente dito. Tendo uma ontologia definida para um
dado domnio e alguns padres de anlise que utilizam a mesma terminologia, dado um importante passo
frente na especificao de requisitos do sistema, cabendo aos engenheiros de software capturar situaes mais
especficas do projeto em que estiverem trabalhando, especializando a ontologia e adaptando os padres de
anlise.
3. Utilizando Ontologias e Padres de Anlise na Modelagem Conceitual de Sistemas .
Diferente de ontologias, padres de anlise esto em um nvel de abstrao mais baixo, descrevendo
conceitos e relacionamentos de acordo com a viso da rea de engenharia de software. Parte-se da modelagem
de sistemas, na rea de engenharia de software, para se chegar a esses padres . Padres de anlise ajudam-nos
a pensar sobre software no nvel de sistema, oferecendo uma viso mais abrangente do software. Tm-se
classes e relacionamentos definidos, que embutem regras do negcio e estes so combinados de acordo com a
necessidade da empresa ou projeto de software.
Tendo em vista as estreitas relaes entre essas duas reas de estudo, possvel buscar obter os benefcios
do uso de ontologias e padres de anlise na modelagem conceitual.
Deve-se observar que tanto ontologias quanto padres de anlise pretendem compartilhar conhecimento e
conseguir reutilizao, embora uma ontologia seja mais genrica e um padro de anlise concentre-se somente
em problemas de engenharia de software. Ou seja, uma ontologia captura a estrutura conceitual intrnseca ao
domnio tratado, enquanto padres de anlise capturam a estrutura conceitual intrnseca a um campo
especfico, o campo das solues para problemas comuns em engenharia de software. Uma ontologia,
permitindo um entendimento completo do domnio que ela representa e oferecendo uma terminologia comum
ao domnio, sem ambigidades, facilita a comunicao entre especialistas do domnio e engenheiros de
software, especialmente na fase de anlise de requisitos. Um padro de anlise, especificamente, visa tornar
mais rpida esta mesma fase, pois j apresenta modelos definidos para determinados contextos, que j foram
testados e adotados em outros projetos, facilitando o trabalho do engenheiro de software que, de posse de um
padro, precisa observar no sistema especfico o que necessrio acrescentar a esse padro ou como combinar
esse padro com outros para obter um modelo completo do domnio.
Ambos, ontologia e padres de anlise especificam o conhecimento sobre um domnio, embora enfatizem
aspectos diferentes. Uma ontologia enfatiza conceitos, relaes e restries, enquanto um padro de anlise
enfatiza como modelar uma poro de conhecimento, atravs de uma soluo de modelagem j usada em
outros projetos com sucesso. Podem enfatizar aspectos diferentes, mas ambos focalizam armaduras e
esqueletos [5], atravs de modelos usados para representar o conhecimento ou da formalizao da
terminologia, como nas ontologias.
Pode-se acrescentar que cada campo sempre requer alguma adaptao para se encaixar em um contexto
particular. Por exemplo, uma ontologia para corporaes define um bom conhecimento sobre o domnio de
corporaes em geral, porm, ao se deparar com um sub-domnio, um tipo particular de corporao, torna-se
necessrio especializar essa ontologia, acrescentando novos termos e relaes que dizem respeito quele sub-
domnio. O mesmo ocorre com um padro de anlise. Um padro que representa, por exemplo, negociaes
contratuais, precisa ser adaptado para um caso de negociao contratual mais especfico.
Usar ontologias e padres de anlise para a modelagem conceitual de sistemas abre espao para uma viso
mais abrangente do domnio tratado, levando a um melhor entendimento desse domnio. Isso pode diminuir o
tempo gasto na especificao de requisitos, pois os engenheiros de software j tm uma fonte preliminar para
aprender sobre o domnio que estabelece uma terminologia comum aos especialistas do negcio. Padres de
anlise oferecem uma viso de pores do domnio, com conceitos e relacionamentos combinados e
arranjados de modo a atender a rea de desenvolvimento de software. Usando ontologias e padres de anlise,
possvel avanar no sentido de facilitar a especificao de um sistema, mesmo que ambos, ontologias e
padres de anlise, precisem ser especializados.
Podemos agrupar uma coleo de padres de anlise conhecidos para formar uma infra -estrutura lgica
para a especificao de sistemas. Assim, podemos comear o trabalho de especificao de requisitos pela
particularizao de uma ontologia e, partindo-se desta, por um processo de escolha de padres mais
adequados, chegar especificao do sistema.
A construo desta infra-estrutura pode requerer uma atitude inversa com respeito definio de padres
de anlise. Na abordagem usual, os engenheiros de software propem padres de anlise a partir da prpria
experincia e da observao de solues j adotadas que se repetem em vrios projetos. O processo agora
pode requerer um caminho complementar, partindo de uma ontologia e da observao de padres de anlise
correlacionados existentes. Quando os padres encontrados no so suficientes para um refinamento completo
da ontologia, necessrio adaptar esses padres de anlise ou propor novos modelos capazes de viabilizar o
mapeamento do nvel de ontologia para o nvel de padro de anlise. Os novos modelos propostos podem ser
um ponto de partida para a definio de futuros padres de anlise. Se comprovada a sua utilidade atravs do
uso, novos padres podem ser estabelecidos.
4. Modelagem de Corporaes.
O desenvolvimento de sistemas de informao integrados para corporaes leva, geralmente, a grandes
investimentos e longos prazos, tanto no caso da prpria corporao desenvolver os seus prprios sistemas,
quanto no caso de optar por comprar uma soluo integrada de algum fornecedor de software Sistemas de
Gesto Integrada (ERP Enterprise Resource Planning).
Cada corporao tem um tipo de negcio e caractersticas prprias, sendo um domnio grande e complexo.
Assim, no caso de organizaes que optam por desenvolver seus prprios sistemas, observa-se uma grande
necessidade de criar novas abordagens de modelagem, que facilitem, principalmente, a fase de levantamento e
especificao de requisitos de um sistema, que uma fase bastante demorada no projeto de um sistema, na
qual so envolvidos, tambm, altos custos, devido necessidade de contratar especialistas nesse tipo de
projeto e envolver usurios especialistas no domnio, que so deslocados das suas atividades normais na
corporao.
No caso da compra de um sistema ERP, em geral, torna-se necessrio fazer uma reestruturao dos
processos de negcios da corporao para que esta possa se adequar ao sistema do fornecedor especfico.
Empresas fornecedoras de sistemas ERP calculam que os clientes gastam de trs a sete vezes o valor da
licena do software na implantao do sistema e servios associados [1]. Pode ser preciso fazer adaptaes no
nvel organizacional, de sistema e de software, levando a comprometimentos difceis e complexos. H uma
diferena entre os requisitos de informao da corporao e a soluo proposta pelo sistema ERP de
determinado fornecedor. Os profissionais que trabalham implantando sistemas ERP tm conhecimento das
opes, parmetros e capacidades do pacote ERP que comercializado. Isto no garante que esse
conhecimento seja suficiente para entender os requisitos sob a perspectiva da corporao. Leva-se muito mais
tempo no levantamento dos requisitos da corporao do que realmente implantando a soluo ERP. A soluo
implantada, na maioria das vezes, atende as capacidades e opes do sistema ERP do fornecedor, mais do que
os requisitos de informao da corporao. Muitas vezes, as ferramentas de modelagem usadas pelos sistemas
ERP so apenas para solucionar opes e ativar parmetros. necessrio um estudo no sentido de suporte a
ferramentas de modelagem ERP, permitindo uma integrao dos requisitos da corporao com os modelos de
referncia oferecidos [1]. Pelo fato dos processos de negcios serem muito complexos, o uso de modelos
ajuda a reduzir a complexidade da realidade, entender melhor os processos do negcio e procurar dar o
suporte de software que necessrio. Assim, mesmo no caso de sistemas ERP, importante que surjam novas
abordagens de modelagem de corporaes, permitindo que se diminua o tempo que se leva no levantamento
dos requisitos e seja facilitada a anlise dos processos da corporao. Isso permite diminuir os custos de
implantao de um sistema ERP e obter uma melhor adequao do sistema corporao.
O mais grave na adoo de um sistema ERP a no produo de um modelo da empresa independente da

sua materializao num software especifico, ou seja, como cada sistema ERP tem seu prprio modelo de
referncia, a viso do que seja a empresa fica da para frente dependente deste modelo. Buscamos, portanto a
definio de um modelo de referncia para sistemas ERP que seja independente de um software particular. A
princpio, sugerimos que isso possa ser obtido pela escolha de uma coleo adequada de padres de anlise.
Alm disso, entendemos que a melhor maneira de modelar uma empresa no seja partindo de uma viso
computacional e sim de uma concepo genrica de empresas, a partir da qual, por identificao de
particularidades, poderemos obter um modelo da empre sa. Partindo do modelo conceitual da empresa,
poderemos tomar novas decises e chegar a um modelo computacional baseado no modelo de referncia.
Esta seo apresenta uma abordagem de modelagem de corporaes, que procura, primeiro, formalizar
conceitos comuns a corporaes atravs de uma ontologia e, aps, o refinamento dessa ontologia em padres
de anlise, para que, no caso de modelagem de uma corporao especfica, esses modelos possam ser
aproveitados e estendidos para tratar aspectos especficos de uma determinada corporao.
Para a construo da ontologia de corporaes, optou-se por utilizar conceitos de ontologias existentes na
literatura, agrupando-os em uma ontologia mais abrangente, capaz de modelar corporaes de vrios tipos.
Tendo uma ontologia como base, corporaes passam a ter uma linguagem na qual o seu conhecimento pode
ser expresso, facilitando a comunicao entre as unidades organizacionais, que precisam ter um alto nvel de
integrao e, principalmente, facilitando a comunicao entre os engenheiros de software e especialistas do
negcio na elaborao de uma especificao de requisitos.
Da mesma forma, os padres de anlise foram buscados na literatura, principalmente em [8]. Entretanto,
como no foram encontrados padres de anlise capazes de contemplar toda a Ontologia de Corporaes, para
algumas de suas partes foi feita uma derivao da ontologia para modelos de classes, criando-se, assim,
alguns modelos de objetos, que podem vir a ser padres de anlise aps a comprovao do seu uso em alguns
projetos.
4.1. Uma Ontologia de Corporaes.
A Ontologia de Corporaes proposta neste trabalho foi construda a partir das ontologias do projeto
TOVE [11] e Enterprise Ontology [12], escolhidas por serem oriundas de grandes projetos que procuram
descrever de forma bastante abrangente corporaes em geral. A partir dessas duas ontologias, foi produzida
uma nova ontologia, reunindo os conceitos comuns e tambm alguns dos conceitos especficos de cada uma
delas, de forma a obter um modelo amplo, para atender a qualquer tipo de corporao. A escolha desses
conceitos foi baseada nas seguintes questes de competncia:
1. Quais os objetivos de uma organizao?
2. Que metas compem um objetivo?
3. Quais so as metas de um determinado projeto?
4. Qual o plano definido para um determinado projeto da organizao?
5. Que unidade da organizao responsvel pelo estabelecimento de um determinado plano?
6. Quais so as atividades que compem determinado plano?
7. Qual a ordem de precedncia entre as atividades de um plano?
8. Como atividades podem ser combinadas para formar uma nova atividade?
9. Que recursos uma atividade pode utilizar?
10. Qual a natureza de um recurso?
11. Com quais atividades um determinado recurso est comprometido em um dado momento?
12. Que bens uma atividade produz/consome? Em que quantidade?
13. Qual a natureza de um bem?
14. Quais so as negociaes contratuais existentes envolvendo um determinado bem?
15. Quais so as partes envolvidas em um contrato?
16. Qual a estrutura da corporao? Como ela decomposta em unidades?
17. Quais so os membros de uma particular unidade da organizao?
18. Que recurso humano gerencia uma determinada unidade da organizao?
19. Que cargos existem na corporao?
20. Que cargo ocupa um determinado recurso humano?

21. Que atividades deve um cargo particular executar?
22. Quais as competncias necessrias para ocupar um determinado cargo?
23. Qual a capacitao de um determinado recurso humano, isto , quais so as suas competncias?
A representao grfica da ontologia proposta foi realizada em LINGO (LINguagem Grfica para
descrever Ontologias) [13]. A escolha teve como critrio central a adoo de uma linguagem grfica com
semntica precisa e o mais isenta possvel de compromissos ontolgicos. A figura 1 mostra as notaes de
LINGO utilizadas neste trabalho, bem como a sua semntica, apresentada atravs de axiomas. Em LINGO a
anotao de cardinalidade precisamente o contrrio da UML, como descreve o axioma de cardinalidade da
figura 1. Alm disso, cardinalidades 0,n no so mostradas em LINGO, tendo em vista que no impem
nenhuma restrio e, portanto, no requerem axiomas.
propriedade Supertipo Todo

1,n
Conceito1 relao Conceito2
Subtipo 1 Subtipo N Parte 1 Parte N
Cardinalidade: c2, c1 relao(c1,c2)
Sub-tipo: x,y,z subtipo(z,y) subtipo(y,x) subtipo(z,x)
Todo-Parte:
x parteDe(x,x) x,y,z parteDe(z,y) parteDe(y,x) parteDe(z,x)
x,y parteDe(y,x) todoDe(x,y) x,y disjunto(x,y) z parteDe(z,x) parteDe(z,y)
x,y parteDe(y,x) parteDe(x,y) x atomico(x) y parteDe(y,x)
Figura 1 Parte da Notao de LINGO e seus respectivos Axiomas.
A figura 2 apresenta o modelo LINGO resultante para a Ontologia de Corporaes. Maiores detalhes sobre
esse modelo, tal como seu correspondente dicionrio de termos, podem ser encontrados em [14]. Na
modelagem de corporaes, necessrio definir as atividades executadas dentro de uma corporao e as
restries para seus planos, tal como as dependncias entre suas atividades. Os planos caracterizam o conjunto
de metas e objetivos a serem alcanados. Planos devem ser construdos por meio da combinao de
atividades. A complexidade do planejamento e da programao de projetos determinada pelo grau em que as
atividades competem por recursos. Toda atividade requer que recursos estejam disponveis no momento da
sua execuo. Alm disso, atividades consomem e produzem bens. Assim, a elaborao de planos depende da
habilidade de raciocinar sobre a disponibilidade de recursos e bens. As organizaes so subdivididas em
unidades organizacionais, onde so lotados recursos humanos. importante conhecer a capacitao dos
membros da organizao, definindo suas competncias e os cargos por eles ocupados. necessrio saber,
ainda, que atividades podem ser executadas por determinado cargo. Grupos estabelecem contratos, nos quais
h transaes valoradas com bens.
Alm dos axiomas impostos pela notao de LINGO (axiomas epistemolgicos [13]), outros axiomas
precisam ser descritos para a ontologia de corporaes. A formalizao pode ser feita usando uma linguagem
de primeira ordem [13]. A seguir, so apresentados alguns deles.
Um recurso humano s pode ser utilizado em uma atividade se ele ocupa um cargo que
responsvel pela execuo desta atividade.
(rh,a) utilizao(a,rh) c ocupao(rh,c) execuo(c,a)
Um recurso humano s pode gerenciar uma unidade organizacional se estiver lotado nesta unidade
organizacional.
(rh, uo) gerncia(rh,uo) lotao(rh,uo)
Se uma atividade a1 depende de uma atividade a2 que por sua vez depende de a3, ento a1 depende
de a3 (transitividade).
(a1, a2, a3) dependncia(a1,a2) dependncia(a2,a3) dependncia(a1,a3)
Plano definio Projeto obteno Meta Objetivo

0,1 1,1 1,n
1,n qtde 1,1

1,n produo 1,n
ps-atividade qtde qtde valor
1,1 qtde 1,n
Bem transao Contrato
dependncia Atividade consumo
sub-atividade 1,1
1,1
pr-atividade
contratado contratante
1,n
Recurso
utilizao
execuo
1,n 1,n
Parte 1,n
Cargo ocupao 1,n
Recurso Produto Servio
Humano
capacitao
gerncia lotao
perfil
Competncia Unidade
1,n Organizacional
Figura 2 Ontologia de Corporaes escrita em LINGO.
4.2. Padres de Anlise para a Modelagem de Corporaes.
Visando estabelecer um catlogo de padres teis para a modelagem de corporaes que se comprometam
com a ontologia apresentada anteriormente, alguns padres de anlise foram selecionados na literatura e
posteriormente adaptados para ficarem em conformidade com a ontologia, principalmente para adequao ao
vocabulrio da ontologia. Entretanto, no foram encontrados padres de anlise capazes de contemplar toda a
Ontologia de Corporaes. Assim, para algumas de suas partes, foi feita uma derivao da ontologia para
modelos de classes, criando-se alguns modelos de objetos.
Com base na seleo e adaptao de alguns padres propostos por Fowler [8], chegou-se ao seguinte
conjunto de padres de anlise para a modelagem de corporaes:
Parte : dado que pessoas, organizaes e unidades organizacionais tm algumas responsabilidades
comuns, este padro cria um supertipo Parte, reunindo propriedades comuns a ambas. Este padro
baseado no padro Party [8].
Hierarquia Organizacional : tem a finalidade de representar estruturas hierrquicas organizacionais
simples. baseado no padro Organizacional Hierarquies [8].
Estrutura Organizacional: serve para tratar estruturas organizacionais mais complexas, nas quais
uma unidade organizacional est subordinada a diversas unidades organizacionais. baseado no
padro Organization Structure [8].
Contrato: usado para descrever vrios tipos de negcio. Baseia-se no padro Contract [8].
Alm dos padres adaptados, alguns modelos de objetos foram propostos para contemplar partes da
ontologia ainda no tratadas, a saber:
Planejamento: estabelece as atividades que compem um plano para um projeto e as restries entre
suas atividades (precedncia e decomposio).
Alocao de Recursos: tra ta da alocao de recursos e bens a serem utilizados na realizao de uma
atividade.
Lotao: trata da lotao de recursos humanos em unidades organizacionais.
Cargos e Salrios: trata da ocupao de cargos por recursos humanos.
Capacitao Profissional : trata das competncias necessrias para se ocupar um cargo, bem como
da capacitao de recursos humanos.
Por limitaes de espao, no possvel apresentar todos os padres de anlise adaptados e os modelos
propostos, que podem ser encontrados em [14]. A seguir, so discutidos apenas o padro de anlise Contrato
e o modelo Lotao.
O Padro Contrato
baseado no padro Contract proposto em [8], apresentado na figura 3, transcrito para a UML, tendo em
vista que Fowler utiliza uma notao prpria. O padro Contract descreve o tipo de negcio financeiro mais
simples, que envolve comprar um instrumento de uma outra parte. Este instrumento pode ser um estoque, uma
mercadoria, uma troca de ttulos ou valores estrangeiros ou algum outro item de comrcio comum. O padro
Contract representa um Contrato, que algum tipo de negcio entre Partes (contratante e contratada),
envolvendo alguma quantidade de um Instrumento.
0..n
+contratada 1
Contrato
Parte
quantidade 0..n Instrumento
0..n preo 1
+contratante 1
Compra Venda
Figura 3 O padro Contract proposto em [8].
Tomando por base o modelo da ontologia apresentado na figura 2, possvel notar que o padro Contract
no est em conformidade com a ontologia. Sendo assim, foram feitas algumas adaptaes, chegando-se ao
modelo apresentado na figura 4. Para que fosse adotada a mesma terminologia usada na Ontologia de
Corporaes, foi feita uma adaptao no padro da figura 3, utilizando o termo Bem ao invs de
Instrumento. De fato, instrumento pode ser visto como o papel que um bem desempenha em uma transao
contratual. Partindo do princpio que um contrato pode ser feito para vrios bens diferentes, envolvendo suas
respectivas quantidades e valores, como descrito na ontologia, foi feita outra adaptao no padro da figura 3,
acrescentando a classe Transao com os atributos quantidade e valor .
Assim, o padro Contrato resultante representa um Contrato que feito entre Partes (contratante e
contratada), envolvendo uma ou vrias Transaes , alm da data em que foi feita a negociao. Cada
Transao envolve alguma quantidade de um Bem (que pode ser um Produto ou um Servio) e um valor
acordado entre as partes. Considera-se aqui que um Contrato abrange vrios tipos de negcio, como por
exemplo: Compra e Venda, Aluguel, Prestao de Servios e Emprstimo. A hierarquia de Parte representa,
na realidade, o padro Parte proposto.
+contratante 1
0..n
Parte +instrumento
Transao
endereo Contrato
+contratada 1..n quantidade 0..n Bem
telefone data
1 1 valor 1
email
Aluguel Emprstimo Servio Produto

Pessoa Organizao
CompraVenda PrestaoServio
UnidadeOrganizacional
Figura 4 O padro Contrato.
O Modelo Lotao
O modelo Lotao, mostrado na figura 5, permite estabelecer as relaes de lotao e gerncia entre
recursos humanos e unidades organizacionais, registrando os respectivos histricos. Em uma corporao,
recursos humanos so lotados em unidades organizacionais, onde exercem suas funes. Uma unidade
organizacional em funcionamento poder lotar vrios recursos humanos. Durante o tempo em que permanecer
na corporao, um recurso humano pode mudar de lotao, sendo, portanto, necessrio registrar o perodo em
que esteve em cada unidade organizacional. Cada unidade organizacional gerenciada por um recurso
humano. Pode ocorrer do gerente de uma unidade organizacional mudar e, para isso, so registrados os
perodos em que cada unidade organizacional foi gerenciada por um recurso humano. Contudo, em um dado
momento, uma unidade organizacional gerenciada por somente um gerente. Regras para designao de
gerentes podem ser estabelecidas atravs da operao gerenteValido() da classe Gerencia, tal como: um
recurso humano s pode gerenciar uma unidade organizacional se estiver lotado nesta unidade organizacional
ou em uma de suas subordinadas (sub-unidade).
0..n RecursoHumano 0..n
+gerente
obterLotacaoAtual()
Gerencia Lotacao
dtInicio dtInicio
dtFim dtFim
gerenteValido()
0..n UnidadeOrganizacional 1..n
obterGerenteAtual()
0..n
0..1
+subUnidade
Figura 5 O modelo Lotao.

Em Lotacao est o histrico de todas as unidades organizacionais em que o recurso humano esteve lotado
durante um perodo de tempo, sendo que a lotao atual se caracteriza pelo fato de no ter uma data fim de
lotao definida. Em Gerencia est o histrico de todos os gerentes de uma unidade organizacional, sendo
que, para saber qual o gerente atual, tem-se a gerncia com data fim ainda no definida.
4.3. Ontologias e Padres de Anlise na Modelagem de Corporaes.
O uso conjunto de ontologias e padres de anlise pode abrir espao para uma nova estratgia para a
definio de padres de anlise. Conforme anteriormente mencionado, padres de anlise so descobertos,
com base em experincias passadas e solues de sucesso para problemas comuns na especificao de
requisitos. Contudo, adotando a estratgia de se definir modelos de objetos com base em uma ontologia e a
partir da aplicao sucessiva desses modelos no desenvolvimento de sistemas para um determinado domnio
de aplicao, pode se chegar tambm a padres. Este foi precisamente o caso do modelo Planejamento, que
j foi utilizado com sucesso em diversos sistemas e j pode ser considerado um padro. Acreditamos que os
demais modelos, tal como o modelo Lotao apresentado anteriormente, tambm possam vir a ser
considerados padres de anlise no futuro.
Finalmente, vale ressaltar que duas estratgias diferentes podem ser adotadas no uso conjunto de
ontologias e padres de anlise na modelagem de corporaes. Primeiro, pode-se utilizar diretamente a
ontologia de corporaes e os padres de anlise correspondentes para desenvolver sistemas de gesto
empresarial para uma organizao especfica. Segundo, ambos modelos (ontologias e padres de anlise)
podem ser especializados para um sub-domnio, por exemplo, organizaes hospitalares, fazendo-se algumas
adaptaes. Esses modelos especializados, por sua vez, podem ser utilizados no desenvolvimento de um
sistema para um hospital especfico.
5. Trabalhos Correlatos.
Conforme mencionado ao longo deste trabalho, h diversas iniciativas usando ontologias [11] [12] e
padres de anlise [8] para apoiar a modelagem de corporaes, mas de forma isolada. No foram
encontrados na literatura estudos de uso conjunto de ontologias e padres de anlise para este propsito.
Contudo, h alguns trabalhos que tratam ontologias e padres de anlise ou modelos de objetos como
abordagens complementares.
Devedzic [5] aponta a sobreposio entre os conceitos de ontologias e padres de software e sua
complementaridade. Para ele, ambos tm como propsito o compartilhamento e o reuso de conhecimento,
ainda que ontologias sejam bem gerais, enquanto padres de software concentram-se apenas em problemas de
engenharia de software. Sua proposta, contudo, est centrada no uso de padres de software como fonte de
conhecimento durante o processo de desenvolvimento de ontologias. Segundo ele, padres de software podem
ser usados durante os primeiros estgios desse processo, como idias iniciais . Nossa posio se distancia
desta, na medida em que entendemos padres de anlise como constituintes de um modelo computacional de
empresas, enquanto que a modelagem via ontologias se apia em uma viso de empresas independente de
qualquer modelo computacional. Entendemos que o trabalho de especificao de requisitos pode ser tratado
como um esforo de, primeiro, particularizar uma ontologia genrica e depois mapear essa ontologia
particular para um modelo de referncia baseado em padres de anlise.
Guizzardi et al. [15] apresentam uma abordagem ontolgica para a engenharia de domnio que guarda certa
relao com o presente trabalho, uma vez que os autores propem uma abordagem para derivar frameworks
de objetos a partir de ontologias. De fato, esta abordagem pode ser utilizada para derivar frameworks, quando
no forem encontrados padres de anlise capazes de contemplar todo o modelo de uma ontologia.
6. Concluses.
Observa-se que o uso de ontologias e padres de anlise contribui muito para o compartilhamento e a
reutilizao. A contribuio pode ser ainda maior, caso sejam associados, pois, alm de facilitar o
entendimento do domnio permitindo que os engenheiros de software e especialistas do negcio conversem
usando a mesma lngua, possvel reduzir o tempo gasto em levantamento de requisitos e acelerar o
processo de anlise. Contudo, necessrio aplicar a abordagem proposta para corroborar essa hiptese. Isto
est sendo feito no contexto de um ambiente de desenvolvimento de software e os resultados obtidos at ento
apontam nessa direo.
Uma vez concluda a aplicao da proposta em casos reais, outros trabalhos devem vir a ser realizados no
sentido de um aprofundamento das pesquisas nesta abordagem. No momento j possvel vislumbrar a
explorao de trs frentes de trabalho. A primeira delas visa um estudo mais aprofundado de padres de
anlise, definio de elementos de articulao entre eles, com vistas produo de um modelo de referncia
para Sistema ERP, independentes de uma particular implementao. Como conseqncia direta, espera -se
obter uma especificao rigorosa para a classe de software denominada Sistemas ERP. Uma segunda frente
a de definio de uma metodologia para especificao de requisitos funcionais de Sistemas de Informao
Gerencial baseada em especializao de ontologias e refinamento para modelos de referncia. Metodologias,
para que sejam implantadas, dependem fortemente de ferramentas de suporte. Assim, a terceira frente de
trabalho consiste na definio e desenvolvimento de uma ferramenta baseada no conhecimento para facilitar o
emprego da metodologia. central nesta ferramenta que se possa capturar decises de modelagem para
reutilizao em novos projetos, em uma abordagem de gerncia de conhecimento.
7. Agradecimentos .
Os autores agradecem ao CNPq pelo apoio financeiro a este trabalho.
8. Referncias .
[1] A.W. Sheer, F. Habermann, Making ERP a Success Using Business Models to Achieve Positive Results.
Communications of the ACM, April 2000.
[2] N. Guarino, Formal Ontology and Information Systems. In: Proceedings of the First Int. Conference on Formal
Ontology in Information Systems, Trento, Italy, June 1998.
[3] M. Uschold, M. Gruninger, Ontologies: Principles, Methods and Applications. The Knowledge Engineering
Review, Vol. 11:2, pp 93-136, 1996.
[4] M. Gruninger, J. Lee, Ontology: Applications and Design. Communications of the ACM, vol. 45, no. 2,
February 2002.
[5] V. Devedzic, Ontologies: Borrowing from Software Patterns. Intelligence, Fall 1999.
[6] J.F. Sowa, Knowledge Representation Logical, Philosophical and Computational Foundations, Brooks/Cole,
USA, 2000.
[7] C. H. Holsapple, K. D. Joshi, A Collaborative Approach to Ontology Design. Communications of the ACM, vol.
45, no. 2, February 2002.
[8] M. Fowler, Analysis Patterns: Reusable Objects Models. Addison-Wesley Professional Computing Series, 1997.
[9] E.B. Fernandez, Building Systems Using Analysis Patterns". Communications of the ACM, 1998.
[10] G. Larsen, Designing Component-based Frameworks using Patterns in the UML. Communications of the ACM,
vol. 42, October 1999.
[11] M. Fox, M. Barbuceanu, M. Gruninger, An Organization Ontology for Enterprise Modeling. Preliminary
Concepts for Linking Structure and Behavior. In: Proceedings of the Fourth Workshop on Enabling Technologies -
Infrastructures for Collaborative Enterprises, West Virginia University, 1995.
[12] M. Uschold, M. King, M. Stuart, Y. Zorgios, The Enterprise Ontology. AIAI, University of Edinburgh, 1996.
[13] R. A. Falbo, Integrao de Conhecimento em um Ambiente de Desenvolvimento de Software, COPPE/UFRJ,
D.Sc., Engenharia de Sistemas e Computao, Rio de Janeiro, 1998.
[14] R. I. Cota, Um Estudo sobre o Uso de Ontologias e Padres de Anlise na Modelagem de Sistemas de Gesto
Empresarial, Dissertao de Mestrado em Informtica, Universidade Federal do Esprito Santo, 2003.
[15] G. Guizzardi, R.A. Falbo, J.G., Pereira Filho, Using Objects and Patterns to Implement Domain Ontologies,
Journal of the Brazilian Computer Society, vol. 1, no. 8, July 2002.
Anlise do Tempo de Navegao na Composio de um Modelo para

Hipermdia Adaptativa
Jacques N. C. Schreiber Raul Sidnei Wazlawick raul@inf.ufsc.br

jacques@unisc.br Silvio Etges etges@inf.ufsc.br
Rolf Molz rolf@unisc.br Thiago Holanda tholanda@inf.ufsc.br
Joo C. Furtado jcarlosf@unisc.br Janice Deters Janice@inf.ufsc.br
GPSPI Grupo de Pesquisa em Sistemas e LSC Lab. de Sistemas de Conhecimento
Processos Industriais Projeto LAIN Links Adaptativos na Internet
UNISC Universidade de Santa Cruz do UFSC-CTC-INE-LSC www.inf.ufsc.br
Sul - www.unisc.br Cx. P. 476, 88040-900, Florianpolis-SC
Av. Independncia, 2293 Brasil
CEP 96815-900
Santa Cruz do Sul Brasil
Resumo
Este artigo compara a qualidade da previso de navegao de dois grupos de usurios distintos. No
primeiro grupo, o tempo de permanncia nas pginas navegadas considerado, no segundo grupo, esse
tempo desconsiderado. A fim de viabilizar este comparativo, este artigo apresenta um modelo de hipermdia
adaptativa (HA) capaz de sugerir links a partir da observao do comportamento navegacional (CN) dos
usurios. O CN aqui interpretado como: os caminhos escolhidos pelo usurio no site e o tempo de
permanncia em cada pgina acessada. O modelo de HA proposto composto por uma rede bayesiana (RB)
e por uma funo geradora de evidncias para essa RB. A topologia da RB foi projetada com a finalidade de
representar o histrico de navegao dos usurios e a funo geradora de evidncias utiliza o tempo de
permanncia na pgina com o objetivo de compor evidncias mais representativas das aes do usurio
durante a navegao. O resultado foi um mecanismo de adaptao com a capacidade de recomendar links
adequados aos usurios.
Com o objetivo de verificar a hiptese de que ocorre uma melhor adaptao quando o tempo
considerado, implementou-se um sistema de HA denominado ALAIN (Ambiente de Links Adaptativos na
Internet). O ALAIN possui dois modelos distintos de usurio. O primeiro integrou o tempo e o histrico de
navegao na composio do modelo, o segundo considerou apenas o histrico de navegao.
Os usurios tiveram o seu comportamento navegacional monitorado e os resultados obtidos comprovaram
a hiptese desta pesquisa.
As atividades relatadas neste artigo cumprem parte dos objetivos do projeto LAIN1 Links Adaptativos na
Internet.
1. Introduo
Nesses catorze anos desde a concepo da Web, vivenciou-se a evoluo das aplicaes. Inicialmente
tinha-se apenas a informao estruturada sob a forma de textos (pginas Web) e links fazendo as conexes
entre esses textos. No decorrer dos anos, a Web evoluiu permitindo a incluso de mdias alternativas (som,
imagens, animaes, filmes, etc). Nos dias atuais, a interao com BDs incrementou a interatividade e as
possibilidades de aplicao cresceram muito (EAD, comrcio eletrnico, servios, etc). Entretanto, uma
caracterstica inicial permanece: no contexto de um hipertexto, pode-se destacar dois papeis: o autor do
hipertexto e o leitor ou usurio do hipertexto. Exercendo o seu papel, o autor constri o hipertexto definindo o
contedo das pginas e a vinculao entre essas pginas. Sob a tica do autor a forma como est organizada
1
Projeto financiado pelo CNPQ, processo no. 552261/2002-5
aquela informao a ideal. No outro lado, encontram-se os usurios, pessoas com interesses distintos,
histria de vida distinta, conhecimento prvio distinto. Ou seja, cada leitor um ser nico.
Considere a figura 1, uma representao grfica de um site. Os crculos representam as pginas e as setas,
indicam a existncia e a direo dos links entre as pginas. Esta estrutura hipottica foi concebida pelo autor
que pr-definiu o contedo e vinculao entre os diversos assuntos constantes no site. Todo esse trabalho
refletiu as convices do autor no sentido de expor o contedo da melhor forma possvel, com um objetivo
especfico e direcionado a um perfil idealizado de possveis usurios, leitores.
Figura 1 Estrutura de um site
Paralelamente estrutura pr-definida, uma estrutura virtual produzida pela navegao dos usurios,
pois cada um escolhe o prprio caminho dentre os disponveis. Essa re-estruturao virtual decorre de uma
percepo associativa dos usurios, buscando informaes que atendam os seus interesses. Segundo Palazzo
[1], o conhecimento produzido na Web pelo processo de navegao no registrado sistematicamente, no
entanto poderia ser empregado na construo de modelos de aprendizado associativo, onde a Web a
metfora de uma memria associativa de grandes dimenses. A figura 2 apresenta um exemplo de uma
possvel re-estruturao virtual produzida pelos usurios deste site hipottico. As navegaes ocorridas esto
destacadas pelas setas em linha tracejada.
Figura 2- Estrutura Virtual
A percepo dessa realidade desencadeou a investigao de possibilidades de aproveitar a estruturao

virtual para criar um mecanismo de estruturao automtica. A idia que a estrutura do site reflita a estrutura
virtual gerada pelas navegaes ocorridas no site. Aps o estudo das possibilidades de aproveitamento da re-
estruturao virtual, foi concebida uma hiptese investigativa: A qualidade da nova estrutura melhora
quando o tempo de permanncia na pginas considerado?
A fim de viabilizar a comprovao dessa hiptese foi implementado um sistema de links adaptativos,
denominado ALAIN (Ambiente de Links Adaptativos na INternet). O ALAIN um sistema de Hipermdia
Adaptativa (SHA) composto por uma rede bayesiana (RB) e por uma funo geradora de evidncias para essa
RB. A RB foi projetada para operar como mecanismo de adaptao do sistema e com esta finalidade, a
topologia da RB foi estruturada visando uma funcionalidade especfica: recomendar os caminhos mais
adequados de navegao. Compreende-se como caminhos mais adequados uma estrutura de links de
hipertexto que facilite a navegao do usurio, considerando o seu conhecimento prvio do assunto e
respeitando os seus desejos e necessidades. J a funo geradora de evidncias foi projetada com o objetivo
de mapear o tempo de navegao dos usurios em indicadores personalizados da relevncia das pginas do
site. Essa funo produz uma evidncia para a RB baseada no tempo de permanncia efetiva (produzido pelo
usurio) com relao ao tempo esperado (idealizado pelo autor).
Este trabalho apresenta os resultados de um estudo que verificou a aplicabilidade do fator tempo na
capacidade de previso do mecanismo de adaptao proposto.
Este artigo dividido em oito sees. As sees dois e trs apresentam a fundamentao terica das reas
correlatas bem como os trabalhos relacionados. A seo quatro detalha o modelo bayesiano implementado, a
seo cinco apresenta o ambiente adaptativo implementado. As sees seis e sete descrevem os resultados
obtidos e ao final, na seo oito, as concluses so apresentadas.
2. Hipermdia Adaptativa
Caracteriza como um SHA todo sistema de hipertexto/hipermdia que de alguma forma capture
informaes dos seus usurios, armazene essas informaes ou uma representao dela e posteriormente
utilize essa informao para provocar alteraes no contedo ou estrutura do hipertexto ou hipermdia. O
ponto chave de um SHA a existncia de um modelo de usurio e a capacidade de adaptar a sua interface em
funo das informaes contidas nesse modelo.
A literatura destaca [2,3,4] que o aspecto mais crtico em um Sistema de Hipermdia Adaptativa (SHA) o
modelo do usurio, uma representao dos objetivos, necessidades e desejos deste usurio. O princpio que
usurios com modelos diferentes estaro interessados em peas de informao diferentes dentre as
apresentadas em uma pgina hipermdia ou podero navegar atravs de diferentes links no sistema. O
mecanismo de adaptao deve propor informao e/ou links de navegao ajustados aos respectivos modelos.
A modelagem do usurio torna-se ainda mais complexa quando o objetivo obter o perfil do usurio sem a
necessidade de interveno ativa e consciente deste usurio na construo do modelo, este processo
denominado modelagem automtica.
O ALAIN um SHA que possibilita a modelagem automtica utilizando as informaes implcitas no
comportamento navegacional dos usurios. O comportamento navegacional aqui interpretado como: os
caminhos escolhidos pelo usurio no stio e o tempo de permanncia em cada pgina acessada. Os links
sugeridos pelo mecanismo de adaptao refletem o modelo do usurio gerado pelo processo de modelagem
automtica, viabilizado a partir do modelo proposto.
O processo de adaptao explicado atravs da figura 3 que apresenta uma arquitetura genrica de um
SHA. O ciclo de adaptao inicia com a monitorao do usurio atravs da interface. Os dados originados da
monitorao, obedecidos s regras de modelagem estabelecidas pelo SHA, originam o modelo do usurio. A
partir do modelo e utilizando regras de adaptao obtm-se um efeito adaptativo, que permitir uma
adaptao da interface, re-iniciando o ciclo.
Prov Adaptao Interface
Regras de Modelagem Dados do

usurio
SHA Modelo do Usurio
Regras de Adaptao
Efeito Adaptativo
Figura 3 Arquitetura Genrica de um SHA

3. Concepo do ALAIN
A concepo do ALAIN obedeceu a uma premissa: o modelo deveria suportar a modelagem automtica
utilizando unicamente dois dados, o histrico de navegao e o tempo de permanncia em cada pgina.
Para isso, duas abordagens poderiam ser utilizadas: o raciocnio Lgico e o Raciocnio Probabilstico.
O raciocnio Lgico pondera sobre o conhecimento prvio sobre o problema e a partir dessa base de
conhecimento infere concluses, o problema que no contexto pretendido no havia base de conhecimento
prvio. J o raciocnio Probabilstico demonstrou-se adequado ao contexto, pois a varivel tempo de
permanncia um componente incerto, pois determinar se o tempo de permanncia numa pgina foi pouco,
suficiente ou demasiado uma tarefa ainda em aberto. Optou-se pela utilizao de uma Rede Bayesiana,
porque esse tipo de rede agrega a teoria dos grafos para estabelecer relaes entre as variveis do problema
(pginas navegadas) e o componente probabilstico permitiu mapear o tempo de permanncia em nveis de
confiabilidade das evidncias geradas pela navegao dos usurios.
3.1 Redes Bayesianas
Uma rede Bayesiana captura relaes (as quais podem ser incertas, estocsticas ou imprecisas) entre um
conjunto de variveis que so relevantes para algum problema. Essas relaes podem ser relevantes porque
sero observveis ou porque seu valor necessrio para tomar alguma ao ou relatar algum resultado ou
porque elas so intermedirias e ajudam a expressar relacionamentos entre as demais variveis.
Quando a rede Bayesiana construda, um nodo usado para cada varivel. Os nodos so ento
conectados com ligaes (links) direcionados. Se existir um link a partir do nodo A at o nodo B, ento o
nodo A chamado de pai e o nodo B de filho (obviamente o nodo B pode ser pai de outro nodo). Um
link de A para B indica que A causa B, que A parcialmente causa ou predispe B, que B uma observao
imperfeita de A, que A e B so funcionalmente relacionados ou que A e B so estatisticamente
correlacionados. A etapa final do projeto de uma rede Bayesiana inclui relaes probabilsticas que so
fornecidas para cada nodo, os quais expressam probabilidades daquele nodo assumir cada um dos seus
valores, condicionado aos valores dos nodos pais. Alguns nodos podem ter relaes determinsticas, o que
significa que o valor de um nodo dado como funo direta dos valores dos nodos pais.
Aps a construo da rede Bayesiana ela pode ser aplicada a um caso particular. Para cada varivel que se
conhea o valor, d-se entrada deste valor em um nodo como uma evidncia. Efetua-se ento a inferncia
probabilstica para encontrar crenas para todas as outras variveis.
Dependendo da estrutura da rede e quais nodos recebem evidncias ou mostram crenas, possvel
calcular-se valores para diagnstico, predio, classificao, lgica, clculos aritmticos ou uma combinao
desses para atingir a inferncia probabilstica. As crenas calculadas so chamadas de probabilidades a
posteriori (sendo que as probabilidades a priori so aquelas existentes antes de qualquer evidncia tenha sido
apresentada a rede). A inferncia probabilstica utilizando-se uma rede Bayesiana chamada de atualizao
de crenas. A inferncia probabilstica somente resulta em um conjunto de crenas para cada nodo, a
estrutura da rede em si no alterada. Se as evidncias que foram dadas como entrada so exemplos
verdadeiros, elas podero dar alguma indicao de casos que sero vistos no futuro, pode-se pensar que elas
mudam a base de conhecimento em parte e que na prxima vez que a rede for utilizada, as suas
probabilidades condicionais refletiro mais precisamente o mundo real.
Uma RB possui as seguintes vantagens:
a) permite representar e manipular a incerteza com base em princpios matemticos fundamentados,

b) modela o conhecimento do especialista do domnio de uma forma intuitiva e
c) nico formalismo que permite realizar qualquer um dos tipos possveis de inferncia probabilstica ou
seja causal, diagnstico, intercausal ou misto.
3.1.1 Trabalhos Relacionados
As RB so aplicadas em diversas reas: sistemas de avaliao mdica, sistemas de previso climtica,

sistemas de anlise de crdito, etc [5]. Essa seo apresenta trs propostas utilizando RB aplicadas predio
e respectivos resultados obtidos.
No artigo Towards a Bayesian Model for Keyhole Plan Recognition in Large Domains os autores [6]
propem uma rede bayesiana representando caractersticas do domnio com a finalidade de identificar planos
e objetivos dos usurios. O domnio um adventure game com 4700 locais, 7200 aes possveis e 20
diferentes metas. O objetivo do mecanismo de predio determinar a meta que o usurio est tentando
atingir, e ento predizer qual ao este usurio executar no prximo movimento e em qual localizao ele
estar. Para isso, a cada ao do jogador, o sistema atualiza a probabilidade do jogador estar tentando atingir
cada um dos objetivos possveis e emite um ranking desses objetivos.
Os resultados obtidos mostram a percentagem de objetivos corretamente previstos em diferentes estgios
do jogo. Por exemplo, quando 80% das etapas do jogo estavam completadas, o sistema estava prevendo
corretamente o objetivo em 74% dos casos, ou seja, o objetivo previsto estava no topo do ranking. O objetivo
estava no segundo lugar do ranking em 81,41% dos casos e em terceiro lugar em 84,13% dos casos.
O segundo artigo [7] descreve trs algoritmos projetados para a tarefa de predizer tpicos adicionais ou
produtos que os usurios possam querer. Os mtodos empregados foram baseados nos algoritmos de:
correlao de coeficientes, clculo de similaridades de vetores e mtodos estatsticos Bayesianos. A avaliao
compara a preciso preditiva dos algoritmos aplicados em trs conjuntos de dados:
MS Web: este conj. de dados contm os registros de visitas individuais a vrias reas do site
da Microsoft.
Televiso: este conj. de dados contm os registros de audincia da tv a cabo Neilsen
EachMovie: nico conj. de dados que efetuada a coleta explcita das preferncias do
usurio. Contm dados do centro de pesquisa da Digital Equipaments
Aplicadas as mtricas de avaliao para os diversos algoritmos e conjunto de dados observou-se que as
redes Bayesianas e o algoritmos de correlao tiveram uma performance superior. As redes Bayesianas
tiveram resultados melhores quando a natureza da aplicao exigia uma lista ordenada, j os algoritmos de
correlao so mais eficientes quando um item apresentado por vez.
O terceiro artigo [8] apresenta o Andes, um tutor inteligente para o aprendizado de fsica. O Andes
utiliza um modelo probabilstico do aluno para apresentar dicas ao aluno quando este requisita ajuda do
sistema. O objetivo do Andes fornecer dicas personalizadas aos objetivos do aluno. O modelo do estudante
neste tutor utiliza uma rede bayesiana para proceder a uma avaliao probabilstica de trs tipos de
informao: (1) o conhecimento geral do aluno, (2) o conhecimento especfico do aluno sobre o problema
atual e (3) os planos que o aluno possa estar utilizando para resolver o problema.
O modelo bayesiano do aluno fornece estimativa probabilstica dos objetivos, crenas e conhecimento do
aluno. O Andes utiliza um framework para a modelagem do aluno, este framework realiza um reconhecimento
dos planos considerando duas informaes: a incerteza sobre esses planos e a incerteza sobre o estado do
conhecimento do aluno. Integrando essas informaes, o modelo capaz de executar trs funes:
reconhecimento dos planos, predio dos objetivos dos alunos e a taxao do conhecimento do aluno nos
demais tpicos do domnio. O framework usa uma rede bayesiana para representar e atualizar on-line o
modelo do aluno.
O Andes foi utilizado por estudantes num curso introdutrio de fsica na academia Naval dos EUA. Os
estudantes receberam um pr e ps-teste. Para avaliar o desempenho do sistema procedeu-se uma regresso
mltipla. Esta regresso forneceu uma relao linear entre o desempenho no ps-teste e o nmero de vezes
que os estudantes requisitaram ajuda do sistema. Os resultados mostraram uma tendncia a melhores
resultados no ps-teste sempre que o nmero de requisies de ajuda ao sistema aumentava.
4. O Modelo Probabilstico Implementado
No modelo implementado, o comportamento navegacional possibilita a incluso de informaes no

Modelo do Usurio (MU) que armazenado em uma Base de Modelos de Usurios (BMU). O MU comporta-
se como um filtro para a estrutura de navegao do ALAIN. O MU evolui ao longo da interao do usurio
com o sistema, tornando a adaptao mais precisa ao longo do tempo. O ALAIN possui trs elementos
fundamentais em uma arquitetura de SHA [9]: a interface, a BMU e a fonte de hipermdia (base de
hipermdia, Internet etc). Estes trs componentes atuam em estreita dependncia, conforme apresentado na
figura 4.
Figura 4 - Arquitetura genrica de um sistema de HA (extrado de [9])
Toda a interao do usurio com o sistema ocorre atravs da interface adaptativa (IA) que executa dois
processos de grande importncia: (a) a apresentao de contedos e links adaptados ao modelo do usurio e
(b) a coleta de informaes relevantes para mant-lo atualizado [9].
A lista dos links presentes na interface construda a partir das informaes sobre o usurio armazenadas
na BMU. Aps a identificao do usurio, o MU carregado, permitindo ao sistema construir a estrutura
bsica da interface, que ento preenchida com contedos selecionados da Fonte de Hipermdia (FH). O
Mecanismo de Adaptao (MA) composto por uma rede Bayesiana (RB) com uma topologia prpria e a
partir das informaes coletadas na interface adaptativa (IA), a RB fornece sugestes personalizadas de
navegao. Nesta seo, so apresentadas a topologia proposta para a RB e a funcionalidade do MA.
4.1 A Estrutura da Rede Proposta Parte Qualitativa
A rede foi implementada com quatro nodos, cada nodo representando quatro etapas do histrico de
navegao: EF_1, Atual, EP_1 e EP_2. Os nomes dos nodos so mnemnicos e descrevem:
a) EF_1: Estado futuro um representa o prximo passo de navegao;

b) Atual: Estado atual representa o momento atual da navegao;
c) EP_1: Estado passado um representa a pgina anteriormente visitada, mais especificamente o
ltimo passo antes do estado atual;
d) EP_2: Estado passado dois representa dois passos atrs no histrico de navegao .
A quantidade de pginas Web no site define a quantidade de estados de cada nodo da rede, numa relao
1x1. O prottipo desenvolvido possui sessenta e duas pginas, portanto, a rede Bayesiana subjacente possui
sessenta e dois estados possveis para cada um dos quatro nodos.
A figura 5 apresenta a topologia da rede e apresenta as relaes causais entre os nodos.
Atual
EP_1
EF_1
EP_2
Figura 5 Topologia da rede proposta
4.2 Tabelas de Probabilidade Condicional Parte Quantitativa
Para a rede Bayesiana estar completa, alm da parte estrutural deve existir uma relao (tabela)
armazenada para cada nodo da rede. Esta tabela expressa o valor daquele nodo com relao aos seus pais. Na
rede proposta, todos os nodos so probabilsticos, ento a tabela fornece uma probabilidade para cada estado
de um nodo filho com relao a uma possvel configurao dos valores (estados) dos nodos pais.
A rede proposta possui nodos representando quatro momentos da navegao; neste caso existiro quatro
tabelas com valores probabilsticos relacionados aos estados possveis do nodo pai. O prottipo possui
sessenta e dois estados possveis (pginas), portanto as tabelas resultantes possuem cada uma, um conjunto
com trs mil oitocentos e quarenta e quatro valores possveis (uma matriz quadrada com sessenta e duas
linhas).
4.3 A Varivel Tempo de Permanncia
No modelo proposto, o tempo de permanncia o parmetro considerado no momento da gerao de

evidncias para a rede. Para possibilitar a compreenso do mecanismo de gerao de evidncias a prxima
sub-seo explica a funo que calcula o grau de certeza da evidncia gerada a partir do tempo de navegao.
4.3.1 O Tempo de Permanncia como Grau de Relevncia
O clculo do grau de certeza da evidncia gerada a partir do tempo de navegao efetuado por meio de
uma funo especialmente projetada para este fim. O resultado desta funo um valor que ser utilizado
posteriormente no clculo da gerao da evidncia.
TPi
Seja a funo:
F evd =
TE i
Onde:
a) TPi o tempo de permanncia efetivo, ou seja, o tempo que o usurio permaneceu com a
pgina i ativa.
QIPi
b) TE i o tempo esperado de permanncia na pgina i, resultado da razo TE i =
PM
Onde:
b.1) QIPi significa Quantidade de Informao da Pgina i. Cada pgina do site possui o seu valor de
QIPi . contabilizado como informao todas as palavras significativas da pgina. Excluindo-se os
artigos, preposies, tags do html, etc.
b.2)
PM significa Palavras por Minuto, ou seja, quantidade de palavras lidas por minuto. um valor
emprico obtido atravs de observaes. O valor obtido foi 60 palavras por minuto.
O resultado gerado por F evd um grau de relevncia da pgina para aquele usurio. Exemplo: Um
usurio X acessou a pgina A e nela permaneceu por oito minutos. Para calcular o valor de F evd so
necessrios os seguintes dados:
TPi = 8 QIPi = 1080 PM = 60
QIPi 1080
TE i = = 60 = 18
PM
TPi 8
F evd = = 18 = 0,444
TEi
O resultado de 0,444 o grau de relevncia da pgina para o usurio X. Caso o resultado fosse um valor
acima de 1 (na prtica, um tempo de permanncia maior que o tempo esperado) o percentual de certeza da
evidncia seria arredondado para 100%. Se o tempo de permanncia for menor do que o tempo de
permanncia mnimo (por exemplo, quando a pgina acessada e logo em seguida ocorre a navegao para
outra pgina) nenhum valor de evidncia deve ser gerado para a associao entre esta pgina e as pginas
anterior e posterior a ela. Estipulou-se, empiricamente, como tempo de permanncia mnimo, dez por cento do
tempo esperado.
Por outro lado, se o valor de F evd ultrapassar 1 o percentual de certeza da evidncia ser sempre
mantido em 100%. Pois as limitaes impostas pelo protocolo HTTP dificultam a obteno de informaes
como: saber se a pgina acessada foi esquecida, minimizada, por exemplo, ou se o leitor est efetivamente
consultando a pgina, embora a ocorrncia destes eventos seja considerado rudo em termos da navegao
real, pois no perodo que o ALAIN foi testado esses eventos ocorreram com uma freqncia relativamente
menor do que as navegaes "boas".
5. O Sistema de Hipermdia Adaptativa - ALAIN
Esta seo apresenta o ALAIN Ambiente de Links Adaptativos na Internet. Trata-se de um sistema Web
adaptativo, implantado para propiciar um ambiente de teste e avaliao do modelo proposto. O sistema possui
navegao adaptativa, obtida a partir do monitoramento do comportamento navegacional dos usurios.
A funcionalidade do ALAIN ocorre da seguinte forma: medida que um usurio navega pelas pginas do
site, dois tipos de dados podero ser capturados: qual pgina foi acessada e quanto tempo este usurio
permaneceu na pgina. Estes dois dados compem o chamado comportamento navegacional do usurio.
O comportamento navegacional prov informaes para a rede Bayesiana, que interpreta essas informaes
como evidncias. O resultado do processamento dessas informaes pela RB um ranking de links ordenados
em ordem decrescente de probabilidade. Portanto, dado um histrico navegacional, com tempos de
permanncia associados, a RB infere um conjunto de enlaces apropriados, sugerindo-os ao usurio.
5.1 O Layout do Site

A interface do ALAIN foi organizada em dois frames. O primeiro (denominado Menu Principal) apresenta
uma lista de links e representa o componente adaptativo do sistema. O segundo quadro (denominado Corpo),
apresenta o contedo da pgina escolhida.
Menu Corpo
Principal
Figura 6 Layout do Site
O ALAIN foi concebido para apoiar atividades de acesso a informao e seus desdobramentos no processo
de aprendizagem. As pginas disponibilizadas no ALAIN versam sobre POO Programao Orientada a
Objetos. O contedo inerente as disciplinas ministradas nos cursos de graduao e ps-graduao em
Cincias da Computao na UFSC Universidade Federal de Santa Catarina.
O contedo e a estrutura inicial dos conceitos (seqncia instrucional) so definidos pelo autor/conteudista.
A partir do ordenamento dos contedos gera-se o conjunto inicial de probabilidades condicionais. Estas
probabilidades condicionais capacitam a rede Bayesiana a associar uma probabilidade a priori a cada
contedo disponibilizado. Os contedos com maior probabilidade so apresentados ao usurio no Menu
Principal. Portanto, a critrio da RB, os contedos mais relevantes so disponibilizados primeiro.
Posteriormente, medida que os usurios navegam pelo stio h um monitoramento das suas aes e estas
so parmetros de entrada para a rede Bayesiana. A rede gerar uma nova lista de links, mantendo itens
consonantes as necessidades dos usurios.
6. A Metodologia de Avaliao
A fim de comprovar a hiptese da pesquisa, foi criada uma metodologia de avaliao da qualidade dos
links sugeridos pelo mecanismo de adaptao (MA). Para viabilizar a avaliao foram criados dois modelos
de usurio: O Primeiro Modelo de Usurio - PMU considerou o tempo de permanncia na pgina e o histrico
de navegao, o Segundo Modelo de Usurio - SMU considerou apenas o histrico de navegao. A partir
desses dois modelos comparou-se o desempenho do sistema diante dessas duas classes.
Devido s restries de tamanho desse artigo apresentaremos apenas a funcionalidade da metodologia de
avaliao, omitindo a sua operacionalidade
A metodologia utiliza como diretriz a posio do link escolhido pelo usurio no ranking sugerido pelo MA.
Foi criada uma mtrica que a partir dos links escolhidos pelo usurio gerado um ndice de Qualidade (IQ).
O IQ ento avaliado sob trs critrios:
a) Evoluo do IQ: Ao observar o comportamento dos ndices de qualidade gerados aps a navegao
dos usurios, pode-se verificar se aps o procedimento de treinamento da RB ocorreu uma evoluo
nos valores do IQ. A semntica desse aspecto : caso ocorra uma evoluo do IQ, isto significa que a
RB est refletindo com preciso o comportamento coletivo dos usurios. As conseqncias so
previses mais acuradas, ou seja, ocorreu um incremento na qualidade das sugestes emitidas pela RB.
b) Qualidade do IQ: Sob este aspecto, a avaliao ocorre verificando-se o quo prximo do valor 1 esto
os IQs calculados. A semntica desse aspecto que quanto mais prximo de 1 o IQ estiver, melhor ter
sido a aceitao por parte dos usurios das previses emitidas pela RB.
c) Comparar IQs provenientes dos dois modelos de usurios. Este aspecto o mais relevante para a
comprovao da hiptese, pois efetuada uma comparao entre os IQs provenientes de dois modelos
de usurio considerados, o PMU e o SMU.
7. Resultados Obtidos
O conjunto de dados foi obtido aps trs meses de utilizao do ALAIN pelos usurios. Ao todo, oitenta e
oito usurios participaram do experimento, quarenta e quatro pertenciam ao PMU os demais ao SMU. Os
integrantes do PMU realizaram cento e duas sesses, j os integrantes do SMU realizaram cento e cinqenta e
duas sesses. Estipulou-se um momento no qual os registros do arquivo de log seriam coletados, denominado
ponto de verificao (PV). Estabeleceu-se a ocorrncia de dez sesses para deflagrar o PV.
A anlise inicial dos dados permitiu observar um fato interessante: a quantidade de sesses efetuada pelos
usurios pertencentes ao primeiro modelo de usurio (PMU) 33,33% menor que a quantidade de sesses
efetuadas pelos usurios provenientes do SMU. Este resultado um primeiro indicativo que a incluso do
tempo de navegao contribui na gerao de evidncias mais significativas. Com evidncias de melhor
qualidade, a RB emite previses mais acuradas. Com previses mais corretas, os usurios necessitariam de
uma quantidade menor de sesses para percorrer todo site, pois o melhor caminho seria apresentado ao
usurio. Esta uma concluso preliminar, a anlise dos dados sob os trs aspectos apresentados na seo 6,
permitiu concluses mais efetivas. A seguir os resultados so analisados sob os trs aspectos previstos:
Evoluo do IQ:
Ao avaliar-se o comportamento dos IQs dos usurios pertencentes ao PMU (que tm monitoramento do
histrico de navegao e tempo de permanncia em cada pgina), observou-se que aps uma instabilidade
inicial dos valores (do 1o ao 4o PV) ocorreu um crescimento e posterior estabilizao dos IQs com um valor
mdio de 0.67013.
Valores do I.Q.
1
0,9
Indice de Qualidade
0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
1 2 3 4 5 6 7 8 9 10
Pontos de Verificao
Valores do I.Q.
Figura 7 Evoluo dos IQs para usurios pertencentes ao PMU
J ao avaliar-se os dados provenientes do SMU observou-se uma grande variao nos valores obtidos nos
IQs. Apesar dos treinos, ao longo de nove pontos de verificao houve uma reduo acentuada nos valores
dos IQs. O desvio padro nos valores de IQ para o SMU quase trs vezes superior ao desvio padro nos
valores de IQ para o PMU.
Valores do I.Q.
1
Indice de Qualidade
0.9
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Pontos de Verificao
Valores do I.Q.
Figura 8 Evoluo dos IQs para usurios pertencentes ao SMU
Qualidade do IQ: Para avaliar este aspecto, efetuou-se a mdia dos valores dos IQs dos dois modelos PMU e
SMU. Os valores obtidos foram 0,6701 e 0,4778 respectivamente. Embora ambos valores no sejam prximos
do timo terico, a mdia dos IQs proveniente do PMU superior.
Comparativo entre os IQs provenientes dos dois modelos: o objetivo deste comparativo verificar se o
tempo de permanncia possibilita um melhor caminho dentro do espao de navegao. A hiptese que
evidncias mais significativas so geradas quando o tempo de permanncia em cada pgina parmetro no
processo de gerao de evidncias para a RB. A conseqncia de evidncias de melhor qualidade so
predies mais precisas. A nica diferena entre os dois modelos de usurio: PMU e SMU, que o primeiro
considera o tempo de permanncia em cada pgina. Portanto, esse comparativo essencial para verificar a
hiptese principal desta pesquisa.
Comparativo entre IQs
1
0,9
Indice de Qualidade
0,8
0,7
0,6
0,5
0,4
0,3
0,2
0,1
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Pontos de Verificao
Usurio PMU Usurio SMU
Figura 9 Evoluo dos IQs pertencentes a ambos modelos
A figura 9 apresenta o grfico comparativo entre os IQs dos modelos de usurio PMU e SMU. Observa-se
no grfico, a quantidade inferior de sesses dos usurios do tipo PMU, indicando que os usurios que tiveram
o tempo de permanncia considerado obtiveram 33,33% menos pontos de verificao que os usurios SMU.
Entretanto, nos dez primeiros pontos de verificao foi possvel comparar o desempenho dos dois modelos,
PMU e SMU, pois ambos possuam dados para estes pontos.
Os valores dos IQs do PMU foram superiores em nove dos dez pontos de verificao. Embora no quarto
PV tenha ocorrido uma aproximao dos valores, a superioridade do modelo PMU foi evidente nos demais
PV. Este fato indica predies de melhor qualidade quando as evidncias apresentadas a RB consideram o
tempo de permanncia.
8. Concluses
A anlise dos dados dos dois arquivos de log (uma para cada modelo de usurio PMU e SMU) teve o
objetivo de verificar a existncia de diferenas entre os dois modelos que pudessem confirmar a hiptese que
o tempo de permanncia nas pginas visitadas influi decisivamente na qualidade das predies feitas pela RB.
Para isso, trs aspectos foram avaliados: evoluo do IQ, qualidade do IQ e comparativo entre os IQs
provenientes do PMU e SMU.
Sob o primeiro aspecto, os resultados para os usurios do tipo PMU, demonstraram que a evoluo do IQ
foi crescente e estvel, por outro lado, os usurios do tipo SMU apresentaram resultados inconsistentes,
instveis. Para os dados provenientes do grupo SMU, constatou-se que a aceitao das sugestes feitas pela
RB diminuiu ao longo dos nove primeiros pontos de verificao, o IQ desse grupo decresceu muito,
evoluindo somente a partir do dcimo PV. O desempenho inferior da evoluo dos IQs provenientes do SMU
demonstrou predies de qualidade inferior da RB. Isto ocorreu porque as evidncias geradas apenas pelo
histrico de navegao dos usurios no refletiram com preciso o comportamento coletivo dos usurios ao
longo dos quinze PV.
Sob o segundo aspecto, a superioridade da mdia dos IQs dos usurios do tipo PMU evidente e indica
que as predies da RB foram aceitas pelos usurios com o modelo PMU, possivelmente porque os links
sugeridos foram ao encontro dos desejos desses usurios.
O terceiro aspecto considerado, comparou os IQs provenientes do PMU e SMU. A primeira observao a
ser destacada a quantidade inferior de sesses efetuadas pelos usurios do tipo PMU, indicando uma
necessidade menor de navegaes para atingir os objetivos individuais dos usurios. O segundo fato
observado foi a superioridade dos valores dos IQs do PMU na maioria dos PV.
Os resultados apresentados permitiu-nos concluir que o tempo de navegao uma varivel essencial na
constituio de evidncias para a RB, pois originou sugestes melhor aproveitadas pelos usurios.
7. Referncias
[1] PALAZZO, Luiz A. M.. Modelos Proativos para Hipermdia Adaptativa tese Universidade Federal do Rio
Grande do Sul, programa de Ps-Graduao em Computao. Porto Alegre, 1999.
[2] VASSILEVA, J.. A task-centered approach for user modeling in a hypermedia office documentation system .
User Models and User Adapted Interaction 6, 1996.
[3] BRUSILOVSKY, Peter. Methods and Techniques of Adaptive Hypermedia. User Modeling and User-Adapted
Interaction. Special issue on adaptive hypertext and hypermedia. Dordrecht, v.6, n. 2-3, p. 87-129, 1996
[4] CARMONA, C et al. An Adaptive Web-Base Tutorial of Agrarian Economy. Disponvel em:
www.lcc.uma.es/~eva/WASWBE/carmona.pdf. Acesso em: 20 de Janeiro de 2003.
[5] HRUSCHKA Jr.. Propagao de Evidncias em Redes Bayesianas Diagnstico de Doenas Pulmonares. Dissertao
de mestrado, UnB, 1997.
[6] ALBRECHT, D. et. al. Towards a Bayesian Model for Keyhole Plan Recognition in Large Domains. ITS2002,
LNCS 2363, pp365-375. Springer-Verlag, Berlin Heidelberg, 2002.
[7] BREESE, John s. et al, Empirical Analysis of Predictive Algorithms for Collaborative Filtering. Proceedings of
the Fourteenth Conference on Uncertainty in Artificial Intelligence, Madison, WI, July, 1998. Morgan Kaufmann
Publisher.
[8] GERTNER, A.S. et al. Procedural help in Andes: Generating hints using a Bayesian network student model. AAI1998
University of Pittsburgh, 1998.
[9] PALAZZO, Luiz A. M.. Sistemas de Hipermdia Adaptativa, Anais do XXII Congresso da Sociedade Brasileira de
Computao, pp.287-321, Florianpolis, 2002.
An Ontology-based Environment to Data Integration*
Agustina Buccella and Alejandra Cechich

Departamento de Ciencias de la Computacin
Universidad Nacional del Comahue, Neuqun, Argentina
{abuccell,,acechich}@uncoma.edu.ar
Nieves Rodrguez Brisaboa

Departamento de Computacin
Universidade de A Corua, Espaa
brisaboa@udc.es
Abstract
Data integration is one of the main problems we must face within a Federated System. To get a consistent
integration, a series of decisions should be made in a correct way. When users query a Federated System,
they should get a suitable semantic answer. Herein, the semantic heterogeneity makes this task difficult
because of its bearing problems on synonymous, generalization/specialization, etc.
Our proposal to deal with semantic heterogeneity problems is based on the use of ontologies and contexts,
which provide a higher degree of semantics to read and combine information sources. On the hand of the
ontologies, they provide the nouns and descriptions of the domain specific entities by using predicates. An
ontology provides a vocabulary to represent and communicate knowledge about the domain, and also a
number of relationships containing the vocabulary terms at a conceptual level. On the other hand, contexts
are useful tools to model concepts which are in conflict with one another. Concepts are true or false
according to the context it is in. In this paper, we briefly explain our architecture and method to solve
semantic heterogeneity. Then we describe a supporting tool that implements part of the method through web
interfaces. A component-based structure is introduced to show the basic functions of the tool.
1. Introduction.
Within the field of Federated Systems many problems are still waiting for some solution. Among them, we
address the problem of knowing the meaning of the concepts to create a common vocabulary among the
different information sources. For this, we apply two powerful tools: ontologies and contexts. Both provide
the semantic meaning needed by the integrated system. On the hand of the ontologies, they give the name and
the descriptions of the entities of specific domains using predicates that represent relationship between these
entities. An ontology provides a vocabulary to represent and communicate knowledge about the domain and a
set of relationship containing the term of the vocabulary at a conceptual level. According to [18] an ontology
is defined as a 5-tuple O =< C,R,F,I,A > in which C is a set of classes, R a set of relations, F a set of
functions, I a set of instances, and A a set of axioms. On the other hand, contexts are useful tools to model
concepts which are in conflict with one another. Concepts are true or false according to the context it is in,
that is, context determines the truth or falsity of a statement as well as its meaning. Therefore, the
combination of both tools might be used for data integration tasks because of their potential to describe the
semantic of information sources and to solve semantic heterogeneity problems.
In recent works [[1],[2],[3]] we have proposed a federated architecture based on a hybrid ontology
approach [19] with three main components: source ontologies, OCM (Ontology and Context Mapping) and
*
This work is partially supported by the CyTED (Ciencia y Tecnologa para el Desarrollo) project VII-J-RITOS2, and the UNComa
project 04/E048 (Modelado de Componentes Distribuidos Orientados a Objetos).
shared vocabulary. Lets briefly clarify these concepts. For each information source within the federated
system, one source ontology and a specific context is specified. Also, a set of contexts is defined within each
ontology describing the different roles of one database. For example, the use cases of a UML specification [5]
might be the source to obtain some of the contexts. Each context contains a series of concepts that might be
classes, subclasses, relationships, instances and axioms. The second component, OCM, deals with the
relationships among the contexts and concepts of the different source ontologies. These relationships are
equality, inclusion, intersection, etc. Therefore, the OCM deals with the information flow between the source
ontologies and the shared vocabulary. Finally, the shared vocabulary is the component in which all source
ontologies converge. This component is composed of the generic concepts and the context that will be used to
query the system. Users use this vocabulary to query and get answers to the system. Once the user chooses the
context and makes the query, the system will use the OCM component to know which concepts are related
with. Thereby, the system gets access to the information sources to produce the output data.
We find several research works proposing methodologies in order to build an integration system. One
example is [11] in which a characterization of the ontology integration process is presented. This proposal is
focused on the analysis of the quality of the ontologies to obtain a reusable resulting ontology. Another
example, presented in [9], describes the Chimarea approach. This approach provides support for merging
ontological terms of different sources, checking the coverage and correctness of ontologies, and maintaining
ontologies over time. A last example is the FCA-MERGE method [16] in which a bottom-up technique for
merging ontologies based on a set of document is described.
Our work is focused on the ontological heterogeneity problem [18]. This problem appears when the
mapping between the source ontologies and the shared vocabularies must be performed. The ontological
heterogeneity has a series of inherent problems because each ontology corresponds only to one information
source created independently. There are two basic types of ontology mismatches: conceptualization
mismatches and explication mismatches. In our last work [3] we have described our proposal to solve them.
Besides, we have defined a useful and practical method containing three main stages: building source
ontologies, building the mappings among source ontologies and building the shared vocabulary. Each of
these stages serves as a guide to create the three components introduced above. Furthermore, to achieve each
stage a set o f steps should be performed.
In this paper, we focus on the second stage, building the mappings among source ontologies, by carrying
out the series of steps involved. We will explain these steps in order to understand how the tool works later.
We will present the federation layer architecture to show the mappings with the structure of components also
described in this paper. Then, the supporting tool together with its web interfaces will be shown with an
example of its use.
This paper is organized as follows: Section 2 presents a summary of our method and architecture. More
descriptively the second stage will be explained because the supporting tool implements its steps. Then, in
Section 3 we will show the structure of the architecture components and the design of the automated tool,
which applies these steps in order to calculate similarity of concepts. An example describing how our tool
works is shown in Section 4. Future work and conclusions will be discussed afterwards.
2. An Approach to Solve Semantic Heterogeneity
In order to introduce our approach we briefly explain the federation layer architecture presented in [2].
Figure 1 shows this architecture, which has three main components: source ontologies, shared vocabu lary and
OCM.
As we previously mentioned, there is one source ontology for each information source and a specific
context (or domain) is defined for each source ontology. Thereby, we use the tuple (ontology, context) to
define each ontology.
Besides, each ontology might be related to several contexts indicating the different roles of one database.
Each context contains a series of concepts included in the ontology, and the specific context (or domain) is
made up of all of these concepts.
Figure 1. Part of the federation system architecture
Then, the set of contexts associated to the ontologies can be written as:
(O1 , C1 ) = { c 11 , c 12 , c13 ,..., c 1m} for m 0.

......................
(On ,Cn ) = { c 21, c 22 , c 23 ,..., c nm } for m 0.
We represent each ontology as follows:

(O1, C1 ) = { concept 1, concept2 , ...., conceptn} for n equal to the number
of concepts in the ontology (1)
(O1, C1 ) = { c 11, c 12 , c13 ,..., c 1m} for m 0.
c 11 ={ concept 1, concept2 , concept 5 , concept10}

............
c1m = { concept 1 , concept 3, concept5 , concept 12 } for m equal to the whole
number of contexts.
The concepts in (1) might be relationships, classes, subclass/subrelationship relationships, class/instance

relationships and hierarchy relationships [6].
The OCM component deals with the relationships among the contexts of the different source ontologies.
These relationships are equality, inclusion, intersection, etc. For instance, the equality relationship means that
contexts in one ontology are the same as contexts in another ontology. As another example, the union (join) of
two contexts may be included in another context and vice versa. Some generic examples are:
< On ,Cn (Cnm) > = < Ok ,Ck (Ckl) >

< On ,Cn (Cnm) > < On ,Cn (Cnp ) > = < Ok ,Ck (Cko ) >
< On ,Cn (Cnm) > < Ok ,Ck (Ckl) > < Ok ,Ck (Cko ) >
These types of relationships help to create a component called shared vocabulary. It includes the generic
concepts involving the source ontologies together with the resulting contexts. The OCM component is
responsible of providing these elements. Also, the OCM component will have the equality axioms describing
the similarity relationships between concepts of two or more contexts, which are connected by some of the
relationship described above. We use the functions defined in [[14],[15] ] in order to find the similarity values
within these related contexts. The (2) and (3) functions show the formulas where a and b are concepts of two
ontologies (O1 y O 2 respectively).
S ( aO1 , bO 2 ) = w p .S p ( a O1 , b O2 ) + w f .S f (a O1 , b O2 ) + wa S a (a O1 , bO 2 ) for w p , w f , wa 0 and w p + w f + wa = 1
(2)
|A I B|
S(a,b)= for 0 a 1 (3)
|A I B| + a(a,b)|A/B| + ( 1 a(a,b))|B/A|
The function (2) is a sum of products (value times weight (w)) where w represents the parts, the functions
and the attributes (wp , wf , y wa respectively). This model is called feature matching, where parts are structural
elements of a concept (or class), such as roof and floor of a building; functions represent the purpose of
the concept; and attributes correspond to additional characteristics of a concept. Consequently, the
relationships between the contexts define values to these weights. The function (3) is based on the Tverskys
model [17] where A and B correspond to description sets of a and b (i.e., synonym sets, sets of distinguishing
features, etc). The equality axioms are built with the result of these functions for the significant cases, that is
for high similarity values.
Finally, the shared vocabulary involves a series of generic concepts and contexts built using the equality
axioms. Users use the vocabulary to query and get answers through the user interface layer. Once the user
chooses the context and makes the query, the system will use the OCM component to know which concepts
are related with. Thereby, the system gets access to the information sources to produce the data.
In previous works [[1],[2]] we have also proposed a useful method to create the three component of our
federated architecture: source ontologies, shared vocabulary and OCM. This method contains three main
stages: building source ontologies, building the mappings among source ontologies and building the shared
vocabulary.
The first stage, building source ontologies, contains two main steps: searching for relationships and
classes and searching for contexts. The first step implies a complete analysis of the information sources, e.g.,
what information is stored, how it is stored, the meaning of this information (the semantic), etc. The second
step implies the definition of the specific context (or domain) for each ontology, and the definition of the
several contexts within an ontology.
The second stage, building the mappings among source ontologies, contains three main steps: defining the
mapping, searching for similarities and building the equality axioms. The first step implies defining the
relationships among the contexts of the source ontologies built in the previous stage. As the contexts are
defined globally, this is a straightforward step. The second step, search for similarities, is the most important
step. We use the functions (2) and (3) previously explained in order to find similarity values within the related
contexts. Finally, the last step, building the equality axioms, also is a straightforward step because high
similarity values must be looked for in the related context.
The last stage, building the shared vocabulary, contains two main steps: creating the generic concepts and
creating the generic contexts. The former step can be achieved by using the equality axioms created in the last
stage. For each equality axiom, one concept must be chosen to be the generic concept within this vocabulary.
Once the generic concepts are chosen, the ontologies must be used to generate a unique ontology or shared
vocabulary. The latter step, creating the generic context, consists of determining the contexts that will be used
by the users. The contexts must include (like in the first stage) their generic concepts.
We refer the reader to [[1],[2]] for a more detailed description of this method.
3. An Automated Environment to Solve Semantic Heterogeneity

In this section we present the structure of software components used to implement the supporting tool. The
diagram showing the components and their dependencies is presented in Figure 2 where the structure is
represented using the UML notation [5]. The components, their interfaces and dependency relationships are
described below. Some components are described in terms of their interfaces and sub-components, and others
are only mentioned for brevity reasons.
w The Coordinator Component

The intent of this component is to coordinate all the processes accordingly by using each component at a
time. Once the ontology is loaded by the user (in Ontolingua Language), the Coordinator calls the Parser
and Instantiation Component to obtain an object structure (representing an instantiation of the Ontology
Model Component) as a result. In this way the whole ontology, its common and attribute classes, its
relations, functions, and instances will be objects of the Ontology Model. Then, when the user loads at
least two different ontologies, the coordinator invokes the Context Creator Component to generate the
different contexts and the relationships among them. In order to calculate the similarity values among the
concepts included in the related contexts, the Similarity Searcher Component is invoked.
w The Parser and Instantiation Component

The component should parse the Ontolingua code loaded by the user in order to create an object structure
which represents a valid instantiation of the Ontology Model Component. The way the former component
uses services of the latter is described later in this section. Besides, error codes generated during the
parsing process or the creation of an instance are returned to the Coordinator Component. Users should use
the Ontolingua Editor [10] to avoid syntactic problems.
Figure 2. Component diagram of the supporting tool
The interface P_Management_Services is provided by the component. Next we present a short description
of it:
w P_Management_Services:
Used by: Coordinator Component
Aim: The provision of an interface allowing the initiation of the parser process by the generation of
an object structure of the classes involved in this process. This instantiation is created to allow the
parser to analyze each word of the Ontolingua code.
Returned data: If some error is detected by the parser process, an specific code error is returned.
w The Ontology Model Component

This component corresponds to the Java translation of the Ontology. We use the syntax of Ontolingua [6]
where an ontology contains classes, relations, functions, instances and axioms. Figure 3 shows how the
different elements of an ontology are divided into. The first division refers to two different elements. On
one branch we have the classes and on the other branch the relations and functions. Firstly we analyze the
class branch, which is also divided into two new branches: common classes and attribute classes. Both are
classes defined in the ontology to represent things about the world. A class is a unary relation, a set of
tuples (lists) of length one. Each tuple contains an object which is said to be an instance of the class. An
individual or object is an any identifiable entity in the universe of discourse, including classes themselves.
The specific role defined in the ontology is the difference between them. The common classes have the
role to represent things about the domain and the attribute classes have the role to represent information
about a common class (attribute). Both roles exist because the ontologies do not have the concept of
attribute. For example if an information source has represented the data name as a string of 20 characters,
in the ontology this name is an object with many properties, it is not a string because the classes and object
are about the world and not about data structures.
On the other branch, Figure 3 shows relations and functions. A relation is a set of tuples that represents a
relationship among objects in the universe of discourse. Each tuple is a finite, ordered sequence (i.e., list)
of objects. A relation is also an object itself, namely, the set of tuples. A function is a mapping from a
domain to a range that associates a domain element with exactly one range element. The elements of the
domain are tuples, as in relations. The range is a class, a set of singleton tuples, and element of the range is
an instance of the class. The functions can also be viewed as sets of tuples.
Figure 4 shows an example of an ontology defined in Ontolingua with classes and relations and specify the
common classes and the attribute classes according to the way they are defined. The relation Has_Part is
enough to classify Organ as an attribute class because it denotes a property about the Animal class. The
documentation part in the definition can be obtained from WordNet [13].
Figure 3. Proposed division to represent the ontology
Figure 4. An example of a common and attribute class and a relation
Figure 51 shows the class diagram used in the ontology instantiation. Each user can create your own
ontology involving the user and ontology classes. The ontology_class class involves common and attribute
classes (using the has_attributes association) and super/subclasses (using the has_superclass association).
The relations and functions are contained in the function/relation class. The ontology_class_instance class
has the instances of the classes and the i_values subclass has the instances of the relations and functions.
1
In this context the terms ontology_class and ontology_class_intantiation denote the classes and the instances of the ontologies.
They do not denote the instances of a class of an Object Oriented paradigm but similar terms with different meanings.
A dependence relationship exists between this component and the Context Model Component because one
association with the ontology_class class within the first component is required. This association indicates
the classes contained by the contexts.
Two different kinds of interfaces are identified in the Ontology Model Component, as shown in Figure 2.
Next we present a short description of them:
w O_Constructor_Services:
Used by: Parser and Instantiation Component
Aim: The provision of an interface to construct elements of the Ontology Model in order to generate
a possible model instantiation. The Parser and Instantiation Component could access directly to the
class constructor of the model. If it does so, it might also access to the behavior of the created object,
which should not be allowed to. That is why the Instantiation Component should only see a narrow
interface, which provides a service for creating an object structure to represent an instantiation of the
model.
Returned data: According to the method being invoked, an instance of an element of the model is
returned.
w Search_of_Concepts_Services:
Used by: Similarity Searcher Component
Aim: The provision of an interface to find the properties, classes, relations to be used in the similarity
functions previously seen.
Returned data: According to the method being invoked, an instance of an element or composed
element of the model is returned.
function/relation
name : String
+has_superclass 0..* explanation : String
+has_attributes
ontology_class
name : String
explanation : String +has_domain
0..1 1
1..* 1..* +has_range_r relation function

1
+has_range_f
+involve
ontology
name : String 1
source_name : String
ontology_class_instance
0..* value : String i_values +involve_rel
explanation : String 1..*
1
user +correspond
username : String
password : String
Figure 5. Class diagram of the ontology model component
w The Context Creator Component

This component has the responsibility of creating the object structure which represents a valid instantiation
of the Context Model Component corresponding to the context and its relationships loaded by the users.
Component C_Management_Services:
Aim: The provision of an interface allowing the initiation of the context creator process by generating
an object structure of the classes involved in this process.
Returned data: An specific code error is returned if some error is detected.
w The Context Model Component

This component corresponds to the Java translation [7] of the context defined by the users. Figure 6 shows
the class diagram used in the context instantiation. The dependence relationship to the Ontology Model
Component comes from the context class. This class has all the classes and functions/relations included in
it. The context_relation class denotes the relationships (intersection, union, equality, etc.) among the
contexts.
Two different kinds of interfaces are identified in the Context Model Component, as is shown in Figure 2.
Next we present a short description of them:
w C_Constructor_Services:
Used by: Context Creator Component
Aim: The provision of an interface to construct elements of the Context Model in order to generate a
possible model instantiation.
Returned data: According to the method being invoked, an instance of an element of the model is
returned.
w Context_Services:
Used by: Similarity Searcher Component
Aim: The provision of an interface to find the related contexts and the concepts included in them to
be used in the similarity functions previously seen.
Data returned: According to the method being invoked, an instance of an element of the model is
returned.
context
name : String
1..*
+connect
context_relation
relation_type : String
+relate
0..*
Figure 6. Class diagram of the context model component
w The Similarity Searcher Component

This component has the task of calculating the similarity values within two related contexts. It uses the
Ontology Model Component in order to obtain the common and attribute classes, the relations and
functions, and to put them within the formulas (2) and (3). The Context Model Component is used to
obtain the concepts included in the related contexts.
Only the interface S_Management_Services is provided by this component:
w S_Management_Services:
Aim: The provision of an interface allowing the initiation of the similarity process by generating an
object structure of the classes involved in this process. This instantiation is created to allow the
calculation of the similarity values
Returned data: The similarity values are returned. If some error occurs, the error code is also
returned.
4. Using the Tool: Step by Step

There are four main steps the users must follow to work with the system: loading the ontologies, loading
the generic and specific contexts, relating the contexts and finding similarities. In the first step, loading the
ontologies, the user must enter the ontology code (in Ontolingua) of his/her own ontology. The web interface
used by the user to make this task is shown in Figure 7. The text box in the figure shows the ontology code
entered. When the button OK is pressed the ontology is stored in the system with the structure defined in
Figure 5. If no errors occur the system will give a successful message. In order to make the final comparison
(the last step) the user must load at least two ontologies successfully.
Figure 7. The web interface to enter an ontology
In the second step, loading the generic and specific contexts, the user enters the generic context and then
the associated specific contexts. Besides, within each specific context he/she must choose the set of concepts
involved in it. Figure 8 shows the web interface to make this task. With the button Store Specific Context we
can store the specific context entered in the respective text box and also make the association of the chosen
concepts. Then, this page is shown again in order to let the user continue loading specific contexts. The button
OK must be pressed when the user wants to finish this step.
In the third step, relating the contexts, the user must relate specific contexts of different ontologies. These
relationships can be equality, inclusion, intersection, etc. Figure 9 shows the web interface to do this step.
Note that each specific context is joined with its ontology and the user must relate contexts of different
ontologies. If the user relates two contexts of the same ontology an error message is generated by the system.
The two list of contexts are the same and are constructed by all the contexts stored by the user for each
ontology. When the button Store Relationship is pressed the system stores the relationship and loads the page
again adding this relationship into the two lists of contexts. The relationship ontology1.context1 =
ontology2.context4 is an example of this. Then the user can again relate this relationship with another context
or related context.
Figure 8. The web interface to enter generic and specific contexts
Figure 9. The web interface to enter the relationships among contexts
When the button Show Included Concepts is pressed another page is open showing the concepts included in
the context selected in the first list. If the user chooses an element with related context (as the example
described before) an error message is displayed. The button OK must be pressed when the user wants to finish
this step.
In the last step, finding similarities, one relationship among contexts must be chosen by the user to let the
system calculate the similarity values between the included concepts. In order to so, the system uses the
information stored and put it in the similarity functions (2) and (3) seen in the previous sections. Figure 10
shows the simple web interface to choose one relationship among contexts. Once one relationship is chosen
and the button OK is pressed the system opens the page shown in Figure 11. The results are obtained by
making paired combination among all the concepts in one ontology and all the concepts in another ontology.
Figure 10. The web interface to choose one relationship
Figure 11. The web interface showing the final results
For example, the similarity value between country and state is very high because many attributes, function
and parts are similar. Otherwise, the similarity values between place and state or between country and town
are very low because their elements are different.
As a final remark, the tool was developed using the Java Platform [7], and Eclipse [4] as the working
environment. The interfaces were created in the Web browser. The connection between the users and the
server is made by using the technology of Java Servlet [8]. The server uses the Linux operating system and
the PostgreSQL [12] database. Currently, the system is off-line and only works locally because it is still under
testing.
5. Conclusions and Future Work
Based on the second stage of our method, we have presented a useful and practical supporting tool in order
to calculate the similarity among concepts included in different ontologies. This stage, called building the
mappings among source ontologies, has a series of steps involved which should be followed to come up to the
final results. The tool widely simplifies the users work when they are making integration tasks.
Also, a structure of components has been presented together with class diagrams, which store the
information given by the ontology and the contexts. Out of the Ontology, common and attribute classes,
relations, functions and instances are extracted. Finally, the users interfaces involved in operating the tool
have been described.
However, our work is, by now, in a development stage for a number of tasks which are still being
developed. As a future work, we are changing the similarity functions in order to take advantages of all the
information given by the ontology, for example the use of instances. Then we will aim at defining different
methods to let users change the weights (w) in the similarity function. It will allow to put more weight to the
attributes and less weight to the instances. Additionally, we are working on solving other problems about
ontological heterogeneity not considered in this work, such as, aggregation-level mismatches.
6. References
[1] Buccella A., Cechich A. and Brisaboa N.R. An Ontology Approach to Data Integration. Journal of Computer
Science and Technology. Vol.3(2). Available at http://journal.info.unlp.edu.ar/default.html, 2003, (pp. 62-68).
[2] Buccella A., Cechich A. and Brisaboa N.R. An Ontological Approach to Federated Data Integration. 9 Congreso
Argentino en Ciencias de la Computacin, CACIC2003, La Plata, October 6-10, 2003, (pp. 905-916)..
[3] Buccella A., Cechich A. and Brisaboa N.R. A Context -Based Ontology Approach to Solve Explanation
Mismatches. Jornadas Chilenas de Computacin. JCC 2003. Chilln, Chile, November 3-9, 2003.
[4] Eclipse Home Page. http://www.eclipse.org.
[5] Fowler, M. and Scott, K. UML distilled, Addison-Wesley 1997.
[6] Gruber T. Ontolingua: A Mechanism to Support Portable Ontologies. Knowledge Systems Laboratory, Stanford
University, Stanford, CA, Technical Report KSL 91-66. 1992.
[7] Java SE Platform. http://java.sun.com.
[8] Java Servlet. http://java.sun.com/products/servlet/..
[9] McGuiness, D.L., Fikes, R., Rice, J. and Wilder, S. An Environment for Merging and Testing Large
Ontologies. In Anthony Cohn, Fausto Giunchiglia, and Bart Selman, editors, KR2000 Proceedings.
Morgan Kaufmann, 2000, (pp. 483 493).
[10] Ontolingua Editor. http://ontolingua.stanford.edu/index.html.
[11] Pinto, H.S. , Martins, J.P. Ontology Integration: How to perform the Process. Workshop on Ontologies and
Information Sharing, IJCAI 2001. Seattle (USA). AAAI Press, (pp. 71-80).
[12] PostgreSQL Home Page. http://www.postgresql.org/.
[13] Richardson, R. and Smeaton, A. Using WordNet in a Knowledge-Based Approach to Information Retrieval.
Technical Report CA-0395, Dublin City Univ., School of Computer Applications, Dublin, Ireland, 1995.
[14] Rodriguez, A., Egenhofer, M. Determining Semantic Similarity among Entity Classes from Different Ontologies.
IEEE Transactions on Knowledge and Data Engineering, Vol.15(2), March/April 2003, (pp. 442-456).
[15] Rodriguez, A., Egenhofer, M. Putting Similarity Assessments into Context: Matching Functions with the Users
Intended Operations. Context 99, Lecture Notes in Computer Science, Springer-Verlag, September 1999 (pp. 310-
323).
[16] Stumme, G. and Maedche, A. Ontology Merging for Federated Ontologies on the Semantic Web. In Proceedings
of the International Workshop for Foundations of Models for Information Integration (FMII-2001), Viterbo, Italy,
September 2001.
[17] Tversky, A. Features of Similarity. Psychological Rev., Vol.84, 1977, (pp. 327-352).
[18] Visser, P., Jones, D., Bench-Capon, T., Shave, M. An Analysis of Ontology Mismatches; Heterogeneity versus
Interoperability. AAAI 1997 Spring Symposium on Ontological Engineering, Stanford University, USA; also
appeared as AAAI Technical Report SS-97-06, 1997.
[19] Wache, H., Vgele, T., Visser, U., Stuckenschmidt, H.. Schuster, G., Neumann, H. and Hbner, S. Ontology -
based Integration of Information - A Survey of Existing Approaches, In Proceedings of IJCAI-01 Workshop:
Ontologies and Information Sharing, Seattle, WA, 2001, (pp. 108-117).
Proceso de Medicin de Funcionalidad en la Elicitacin de

Requerimientos
Mabel Bertolami Alejandro Oliveros

Departamento de Informtica, Departamento Departamento de Computacin, Facultad de
de Matemtica, Facultad de Ingeniera, Ingeniera, UBA - Magster de Ingeniera de
UNPSJB Software, Facultad de Informtica, UNLP
mbertolami@gmx.net oliveros@fibertel.com.ar
Resumen
El Anlisis de Puntos Funcin es una tcnica de medicin que se aplica a los diferentes artefactos
producidos durante el proceso de desarrollo de software y en especial a los documentos de diseo. En este
artculo se describe un proceso de medicin de funcionalidad de un sistema de informacin en la etapa de
Elicitacin de Requerimientos, el objetivo es medir el tamao funcional de los Escenarios. Particularmente
se midieron los escenarios construidos a partir del Lxico Extendido del Lenguaje [13]. El proceso de
medicin forma parte de un esquema mayor que se describe en [2] y [3]. Consiste de una serie de etapas
compuestas por subprocesos. Durante las etapas del proceso se aplican reglas y se utilizan formularios para
documentar el proceso de medicin. Se presenta un resumen de la aplicacin a un caso, las conclusiones y se
indican las futuras lneas de investigacin.
1. Introduccin.
La Ingeniera de Software provee los medios que facilitan el diseo de software de mayor calidad, ms
confiable y con menor costo. Las organizaciones que logran esos objetivos disponen de sofisticados
programas de medicin de calidad y productividad [12]. Un aspecto crucial de estos requisitos de medicin es
la necesidad de determinar el tamao del software. Entre las tcnicas propuestas se incluye la medicin de la
cantidad de lneas de cdigo, que tiene importantes limitaciones entre las que pueden mencionarse: la
imposibilidad de aplicarla en las primeras etapas del proceso de desarrollo y de manera uniforme a travs del
tiempo de vida del software [25].
El concepto de medicin del tamao funcional, adoptado por los mtodos de Anlisis de Puntos Funcin
(FPA), es una alternativa a esas limitaciones. Estos mtodos miden el tamao del sistema software en
trminos de la funcionalidad requerida por el usuario e independientemente de la tecnologa que se utilice
para implementarlo [8]. Se caracterizan por ser aplicables a los productos obtenidos a lo largo del ciclo de
desarrollo permitiendo refinar las mediciones a medida que se avanza en el proceso, lo que contribuye a
mejorar la precisin de los resultados.
En la bibliografa de FPA se propone aplicar esta tcnica a partir de la especificacin de requerimientos

[22] y adems se mencionan las ventajas asociadas a la disponibilidad de una contabilizacin de los Puntos
Funcin (FP) en las etapas iniciales del desarrollo [5] as como tambin los beneficios del FPA relacionados a
mejorar la definicin y verificar la completitud de los requerimientos funcionales [6].
En [2] y [3] se presenta un enfoque para medir los FP antes de completar la especificacin de
requerimientos, esto es en la etapa de elicitacin y a partir de medir los Escenarios. stos permiten entender la
aplicacin y su funcionalidad: cada escenario describe una situacin especfica de la aplicacin centrando la
atencin en su comportamiento [15]. Esto significa que los escenarios se pueden utilizar como documentacin
base para el clculo de FP.
La principal ventaja de esa medicin es estimar el tamao del producto a construir en una etapa muy
temprana de su desarrollo. Esto permite anticipar una amplia gama de decisiones, por ejemplo, la de
desarrollar o comprar un producto de software, con las consiguientes ventajas para la administracin del
proyecto.
El enfoque propuesto en este trabajo toma como base el Mtodo MKII FPA [19]. Este mtodo se puede
usar para medir el tamao funcional de cualquier aplicacin de software que se pueda describir en trminos de
transacciones lgicas. Los conceptos de transaccin de MKII y de episodio de los escenarios en el enfoque
de Leite presentan similitudes. Explotando estas similitudes se enuncian un conjunto de reglas para
identificar, clasificar y cuantificar los diferentes tipos de componentes lgicos del Lxico Extendido del
Lenguaje y Escenarios (L&E) para obtener una medida del tamao funcional del sistema [2], [3].
El resto del artculo est organizado como sigue: en la seccin 2 se presentan las propuestas relacionadas,
en la seccin 3 se introducen los escenarios, en las secciones 4 y 5 se presentan el enfoque de medicin y el
proceso de medicin de funcionalidad de L&E. En la seccin 6 se presenta la aplicacin a un caso de estudio
y en la seccin 7 se exponen las conclusiones de la investigacin y los futuros trabajos.
2. Propuestas relacionadas.
Se han propuesto diferentes mtodos para medir el software orientado a objetos [20] basado en el modelo
de Casos de Uso mediante la aplicacin del modelo de FP [8]. Estos enfoques aprovechan la relacin
natural existente entre ambos: FPA es un mtodo para medir software desde una perspectiva de los
requerimientos y Casos de Uso es un mtodo para desarrollar requerimientos. Ambos tratan de ser
independientes de la tecnologa usada para implementar la solucin de software [16], [23].
En [8] se propone un mapeo del mtodo OOSE basado en Casos de Uso de Jacobson con el modelo
abstracto de FP y se establece la utilizacin del estndar IFPUG FPA. En [16] tambin se plantea usar ese
mtodo sobre Casos de Uso. Otra propuesta [9] sugiere la integracin de Casos de Uso con MKII FPA.
Se observa una cierta proximidad entre los enfoques mencionados en los prrafos previos y el presentado
en este artculo debido a que los Casos de Uso y los escenarios presentan caractersticas similares y ambos
representan el comportamiento. Sin embargo existe una diferencia sustancial entre ellos: los escenarios del
enfoque de L&E y los Casos de Uso se utilizan en diferentes etapas del proceso de Ingeniera de
Requerimientos. Si se considera el modelo elicitacin-especificacin-validacin [17], los Casos de Uso son
una herramienta de especificacin de requerimientos en tanto estos escenarios se utilizan en la elicitacin de
requerimientos, lo que no impide que puedan ser utilizados en etapas ms avanzadas del desarrollo.
3. Escenarios.
En el enfoque utilizado [14] los escenarios representan descripciones parciales del comportamiento del
sistema en un momento especfico de la aplicacin, se representan en lenguaje natural, estn vinculados
naturalmente al LEL, evolucionan durante el proceso de desarrollo del software y se representan de manera
estructurada. Se componen de: Nombre, Objetivo, Contexto, Recursos, Actores, Episodios, Excepciones,
Restricciones.
Un escenario debe satisfacer un objetivo que es alcanzado ejecutando sus episodios. Cada episodio
representa una accin realizada por un actor, donde participan otros actores y se utilizan recursos [13]. Los
actores son las personas o estructuras organizacionales que cumplen un rol en el escenario y los recursos son
los medios de soporte, dispositivos u otros elementos pasivos necesarios para el escenario. Mientras se
ejecuta un episodio pueden plantearse excepciones sealando un obstculo para alcanzar el objetivo. Las
restricciones se usan para caracterizar requerimientos no funcionales aplicados al contexto, recursos y
episodios. El contexto se describe detallando una ubicacin geogrfica o temporal y precondiciones [15]. Los
escenarios son construidos a partir del LEL de acuerdo a heursticas especficas [11], [15].
4. Medicin de funcionalidad de LEL y Escenarios.

Considerando que los escenarios representan las funciones requeridas por el usuario, se utiliza un enfoque
similar al proceso de descomposicin funcional [22]. Cada escenario se descompone en un conjunto de
episodios que representan acciones nicas, de ese conjunto se descartan algunos episodios segn ciertos
criterios y se calculan los FP de los restantes. Los FP del sistema se obtienen a partir de la sumatoria de los FP
de cada episodio. Se considera nica accin a aqulla que representa una accin atmica -no puede
descomponerse en otras- disparada por algn evento del mundo externo o por una consulta para obtener
informacin, que se realiza en forma completa e independiente de otras [19].
Los FP del cada episodio se calculan mediante: FP = NI + NR + NO siendo NI la cantidad de Tipos de

elemento dato (DET) de entrada, NR la cantidad de recursos referenciados y NO la cantidad de DET de salida.
N
El ndice de Puntos Funcin se calcula mediante: FP = FPi donde N es el total de episodios.
i =1
Tomando como base a L&E se est considerando todo el sistema, no exclusivamente las funciones
asignadas al software. En consecuencia es previsible que se obtenga una cantidad de FP mayor que en el
enfoque tradicional. Esto no representa un impedimento, pues un escenario comienza en el macrosistema y
contina evolucionando a medida que el artefacto de software se va construyendo [10], luego la cantidad de
FP inicial se puede ir refinando en paralelo con la evolucin de los escenarios. Desde la ptica del FPA, [7]
menciona que las diferentes tcnicas para medir la funcionalidad pueden aplicarse desde los documentos de
especificacin y tambin a los productos posteriores en el ciclo de vida permitiendo mejorar las estimaciones
de tamao y por lo tanto, las estimaciones de costo o productividad.
4.1. Definiciones y Reglas.
En las primeras etapas de anlisis del problema se confecciona una lista de episodios candidatos. Un
episodio candidato es aqul que puede estar incluido en la lista de episodios elaborada inicialmente, pero an
se debe determinar su inclusin en la lista definitiva. Las heursticas de medicin se establecieron a travs de
un conjunto de Reglas siguiendo el modelo situacin-decisin-accin-argumento [21].
En la definicin del enfoque se establece que se deben excluir los episodios repetidos y los episodios que
son escenarios de la lista de episodios candidatos.
La Regla 1 establece que si un episodio representa un escenario no se debe considerar para contabilizar los
FP entonces no se incluye en la lista de episodios candidatos.
En los escenarios se encuentra una descripcin completa de las interacciones del actor con el sistema.
Existen algunas acciones que aunque son necesarias para la realizacin del escenario no contribuyen al
tamao funcional del sistema. Por ejemplo:
El recepcionista llama por telfono al pasajero/husped/pax cuando llega la hora.
Si un episodio representa acciones que no aportan funcionalidad al sistema no se lo considera para

contabilizar los FP y en consecuencia no se incluye en la lista de episodios candidatos (Regla 2).
Clasificacin de los episodios segn su tipo y estructura. Los episodios son el centro del anlisis debido a
que cada episodio representa una accin realizada por un actor, donde participan otros actores y se utilizan
recursos. Los episodios son de tipo simple, condicional y opcional. Independientemente del tipo, un episodio
puede ser expresado como una nica accin o un escenario. El modelo de escenarios provee la descripcin de
comportamientos con diferentes rdenes temporales. Una secuencia de episodios implica un orden de
precedencia, pero un orden no secuencial requiere el agrupamiento de dos o ms episodios. Esto se usa para
expresar un orden paralelo o secuencial indistinto [15].
Si un episodio simple representa una nica accin, esta accin es atmica y se realiza en forma completa e
independiente de otras, la decisin es considerarlo para contabilizar los FP entonces se incorpora a la lista de
episodios candidatos (Regla 3).
Si un episodio condicional representa una nica accin que puede o no ejecutarse segn se cumpla una
condicin entonces se lo considera para contabilizar los FP y por lo tanto se incorpora a la lista de episodios
candidatos (Regla 4).
Si un episodio opcional representa una nica accin que puede o no ejecutarse entonces se lo considera
para contabilizar los FP y en consecuencia se lo incorpora a la lista de episodios candidatos (Regla 5).
Otra categora que merece un anlisis es el Conjunto de episodios. Cuando un episodio pertenece a un
grupo de episodios secuencial cada uno de los episodios de la secuencia se debe clasificar segn las Reglas 3
a 5. Si un grupo de episodios no secuencial representa dos o ms acciones entonces cada una de las acciones
que cumpla con los criterios de las Reglas 3 a 5 se debe considerar para contabilizar los FP e incorporar a la
lista de episodios candidatos (Regla 6).
Las excepciones o casos alternativos se refieren a los casos de excepcin que pueden interrumpir la
evolucin normal del escenario. Cada excepcin se describe como una sentencia simple que especifica la
causa de la interrupcin. Si incluye el ttulo de otro escenario, la excepcin ser tratada por ese escenario
[15]. En el primer caso se descartan segn la Regla 2 y en el segundo por la Regla 1.
Restricciones. Las restricciones provienen del contexto del problema y del contexto del escenario. Son un
atributo de los recursos, episodios bsicos o subcomponentes del contexto [15]. Son aquellos aspectos que al
presentarse impiden la accin. Las restricciones reflejan requerimientos no funcionales [11]. No se
considerarn pues no representan funcionalidad (Regla 7).
Transaccin lgica y episodio. La transaccin lgica es un concepto clave del FPA en MKII [19], en [2] se
realiz un anlisis detallado de la equivalencia conceptual entre el episodio simple y la transaccin lgica en
MKII. Este anlisis permiti establecer como concepto que el episodio simple que representa una nica
accin es equivalente al concepto de transaccin lgica. Esta hiptesis permiti desarrollar un proceso
efectivo de FPA de los escenarios, pero su establecimiento definitivo depende de una mayor experimentacin.
Clasificacin de episodios. Las interacciones de un actor con el sistema son provocadas por: 1) La
ocurrencia de algn suceso en el mundo externo que requiere la realizacin de algn procesamiento, 2) La
necesidad de recuperar informacin. La primera de ellas se corresponde con el concepto de evento en MKII y
la segunda con el de consulta. Por lo tanto, todo episodio definido segn la Regla 3 debe pertenecer a la
clasificacin evento o consulta.
4.2. Componentes de los episodios.
Para calcular los FP del sistema se debe determinar cules son los componentes de los episodios que
contribuyen al clculo. Con ese objetivo cada episodio se descompone en tres componentes Entrada-Proceso-
Salida (E-P-S):
- Entrada: consiste en la adquisicin de los datos provistos por el usuario que llegan al sistema, sea para
describir un evento de inters en el mundo externo o una consulta para recuperar informacin del sistema.
- Proceso: consiste en las acciones de almacenamiento y/o recuperacin de informacin que describe el
estado de los elementos de inters para el mundo exterior.
- Salida: son los tems provistos al usuario, sea cual fuere la categora de la accin. Esta parte comprende las
tareas de presentacin de la informacin hacia el mundo externo [19].
Clasificacin de los componentes E-P-S de los episodios. Los componentes E-P-S de un episodio contienen
una serie de objetos1 que se clasifican en dos grupos: aqullos que se corresponden con smbolos del LEL y
palabras o frases no definidas en el LEL [3]. A su vez dichos smbolos pueden subclasificarse en Simples y
Complejos.
Definido en el LEL: se corresponde con las entradas del LEL.

Simple: un tem atmico de informacin reconocible por el usuario. ste a su vez puede ser:
independiente, no depende ni participa en la definicin de otros smbolos.
no depende de otros smbolos y es una entrada de otro smbolo.
Complejo: es un conjunto formado por uno o ms smbolos pertenecientes a la clasificacin Simple y/o uno
o ms No definido en el LEL.
No definido en el LEL: palabra o frase que por sus caractersticas no se describe como entrada del LEL, pero
es necesaria para el desarrollo del episodio. Puede representar un objeto que intuitivamente se reconoce como
atmico, compuesto o recurso.
- Tipos de elemento dato (DET). Esta denominacin incluye a todas las entradas del LEL pertenecientes a la
clasificacin Simple y a los objetos atmicos No definido en el LEL que integran los componentes entrada y
salida del episodio.
En el caso que el componente entrada/salida incluye una entrada del LEL perteneciente a la clasificacin
Simple se debe clasificar como DET e incluir en la lista de DET de entrada/salida del episodio (Regla 8).
Si el componente entrada/salida incluye un objeto perteneciente a la clasificacin No definido en el LEL se

debe clasificar como DET e incluir en la lista de DET de entrada/salida del episodio (Regla 9).
Cuando el componente entrada/salida incluye una entrada del LEL perteneciente a la clasificacin
Complejo se deben identificar los tems que lo componen. Para ello se debe buscar en la nocin del smbolo
del LEL e incluir cada uno de los tems en la lista de DET de entrada/salida del episodio (Regla 10).
Cuando un episodio se inicia automticamente se debe identificar el tem disparador, clasificarlo como
DET de entrada y agregarlo a la lista de DET de entrada del episodio (Regla 11).
- Recursos. Esta denominacin abarca a todas las entradas del LEL pertenecientes a la clasificacin Simple o
Complejo y a los objetos No definido en el LEL que forman parte del componente proceso del episodio.
Si en el componente proceso de un episodio se identifica una entrada perteneciente a la clasificacin

Simple, Complejo o un objeto No definido en el LEL, se debe clasificar como recurso e incorporar a la lista de
recursos del episodio (Regla 12).
Aporte de cada componente al tamao funcional. Una vez identificados los DET en los componentes
entrada y salida y los recursos en el componente proceso del episodio se requiere establecer reglas para
valorar su contribucin a la cuenta de FP del episodio.
- DET en el componente entrada y salida del episodio: el tamao de los componentes entrada y salida de
un episodio es proporcional a la cantidad de DET en dichos componentes.
Cuando el componente entrada/salida del episodio incluye un DET clasificado segn las Reglas 8 a 11 se
debe contabilizar cada DET distinto y no las ocurrencias de cada uno de ellos. En consecuencia corresponde
sumar 1 (por cada DET) a la cuenta de DET de entrada/salida (Regla 13).
- Referencias a recursos: el tamao del componente proceso de un episodio es proporcional a la cantidad de

recursos referenciados durante la realizacin de las acciones. Se considera la siguiente definicin: las
1 En este artculo se considera la definicin: Un objeto es cualquier entidad del mundo real, importante para la discusin de los
requerimientos, con un borde claramente definido [4].
operaciones crear, leer, actualizar, borrar, listar y usar un recurso se denominan genricamente referenciar un
recurso.
Si el componente proceso de un episodio incluye una referencia a un recurso clasificado segn la Regla
12, se debe contabilizar una nica referencia al recurso si es la primera vez que aparece la referencia al
recurso. Por lo tanto se debe sumar 1 (por cada recurso referenciado) a la cuenta de recursos (Regla 14).
4.3. El lmite del sistema.
El lmite de la aplicacin define un borde conceptual entre el software y el usuario. La aplicacin incluida
dentro del lmite debe conformar un cuerpo consistente de funcionalidad, significando que dicho lmite debe
incluir operaciones (o procesos) completos [19].
Debido a que los escenarios representan las funciones del sistema se establece como lmite del sistema al
borde conceptual que encierra todos los escenarios, lo que significa considerar a cada uno de los escenarios
dentro del lmite del sistema y todo aquello que no est contenido en los escenarios est fuera del sistema
(Regla 15).
El lmite del sistema elicitado utilizando L&E y el del software a desarrollar no necesariamente sern
coincidentes debido a que quizs no se requiera automatizar todas las funciones del sistema. Luego, es posible
que el primero incluya mayor funcionalidad que el segundo. El clculo de FP se realizar en base al lmite
determinado desde L&E.
El anlisis de las definiciones de usuario en FPA y actor en los escenarios sugiere la equivalencia de
ambos conceptos y soporta la decisin: el conjunto de todos los actores de los escenarios representa
adecuadamente el concepto de usuario en FPA [2].
Si la descripcin de un escenario incluye uno o ms actores entonces se debe considerar usuario a cada
actor presente en el escenario y organizar una lista de usuarios del sistema con todos los actores de los
escenarios y slo stos (Regla 16).
5. Proceso de medicin de funcionalidad de L&E.

El proceso de medicin de funcionalidad de L&E se describe como una secuencia de etapas. Cada etapa se
compone de subprocesos. El producto resultante de cada subproceso se utiliza como entrada para el siguiente.
La Etapa 4 y el subproceso 6.1 de la Etapa 6 se deben reiterar para cada episodio y la Etapa 5 para cada
componente de cada episodio.
Los subprocesos se describen en trminos del modelo Entrada-Proceso-Salida. Este modelo, usado por
muchos sistemas, considera que un sistema es til en la medida que transforme alguna cosa en otra diferente.
Lo que llega al sistema es la entrada, lo que causa el cambio es el proceso y lo que sale del sistema es la salida
[24]. En el proceso de medicin se usa este modelo para indicar que en cada etapa se recibe un producto como
entrada, se realiza un determinado proceso con/sobre l y se obtiene un nuevo producto como salida.
Durante las diferentes etapas se aplican las reglas previamente definidas y se utilizan tres formularios para
documentar los estados intermedios y final del proceso. La Tabla 1 presenta una visin global del proceso: las
seis etapas principales del proceso de medicin y los subprocesos que las integran. Asimismo para cada
subproceso se indican las reglas y formularios utilizados as como sus entradas y salidas.
Es fundamental que el proceso de FPA sobre L&E est documentado, ello facilita y organiza el proceso de
recoleccin de datos, favorece el proceso de revisin y el control de cambios proporcionando informacin
acerca de qu se contabiliz durante el anlisis y establece las bases para la construccin del sistema.
Indudablemente es conveniente disponer de formularios estndar para registrar el proceso de FPA y stos
deben formar parte de la documentacin del proyecto, incluyendo la documentacin propia de L&E. En [2] se
reproducen los formularios propuestos, se establecen una serie de normas para completar cada formulario y se
incluyen ejemplos de utilizacin.
Tabla 1. Etapa Subproceso

Subproceso
Etapa Regla Formulario*

Nombre Entrada Salida
utilizada
1 2 3
1.1 Determinar el propsito de la Objetivo Propsito
1. Punto de vista y - - - -
medicin medicin medicin
propsito de la
medicin Propsito Punto de vista
1.2 Determinar el punto de vista - - - -
medicin del usuario
2.1 Determinar la funcionalidad que Punto de vista, Lmite del
15 - - -
2. Lmite del se incluir en la medicin propsito, L&E sistema
sistema Lmite del
2.2 Identificar usuarios 16 - - - lista de usuarios
sistema, L&E
3.1 Descomponer los escenarios en lista_episodios_
1 - - - Escenarios
episodios candidatos1
3.2 Eliminar episodios repetidos de la lista_episodios_ lista_episodios_
- - - -
lista candidatos1 candidatos2
3. Identificacin lista_episodios_ lista_episodios_
episodios 3.3 Reducir a episodios simples 3, 4, 5, 6, 7 - - -
candidatos2 candidatos3
3.4 Descartar los episodios que no lista_episodios_ lista_episodios_
2 - - -
incluyen funcionalidad candidatos3 candidatos4
3.5 Organizar un catlogo de lista_episodios_ Catlogo de
- S - -
episodios candidatos4 episodios
Componentes
4.1 Identificar los componentes E-P-S - - - - Cada episodio
del episodio
4. Descomposicin 4.2 Identificar los DET de cada Componente Lista DET de

episodios 8, 9, 10, 11 - S - E/S de cada E/S del
componente
episodio episodio
4.3 Identificar los recursos de cada Componente P Lista recursos
12 - S -
componente de cada episodio del episodio
5.1 Contar DET en el componente E Lista DET de E Total DET de E
13 - E S
del episodio del episodio (NI)
5. Contabilizacin
DET y recursos 5.2 Contar referencias a recursos en 14 - E S
Lista recursos Total recursos
referenciados el componente P del episodio del episodio (NR)
5.3 Contar DET en el componente S Lista DET de S Total DET de S
13 - E S
del episodio del episodio (NO)
NI, NR, NO del FP del episodio
6. Determinacin 6.1 Calcular los FP del episodio - - - E
episodio (FPi)
tamao
funcional FP de cada Total FP de la
6.2 Calcular los FP de la aplicacin - - - E
episodio aplicacin
* E: contenido parcial o total del formulario se utiliza como entrada en el subproceso

S: contenido parcial o total del formulario se produce en el subproceso
5.1. Etapas del proceso de medicin.
Etapa 1 Punto de vista y propsito de la medicin. El proceso de contabilizacin de FP requiere establecer el

lmite de la aplicacin que se va a someter a la medicin. Esto servir para determinar qu parte de la funcionalidad
va a estar incluida en el proceso y cul quedar excluida. La eleccin del lmite depende del punto de vista y
propsito de la medicin [19]. Esta etapa requiere dos subprocesos. Determinar el propsito de la medicin (1.1), el
objetivo es medir la funcionalidad requerida por el usuario desde L&E, con el propsito de usar esta medida en
estimaciones de costo, esfuerzo y agenda de un proyecto de desarrollo. Determinar el punto de vista (1.2), que es
desde el cual se miden los FP. Debido a que se trata de medir la funcionalidad entregada al usuario, se considera el
punto de vista del usuario.
Etapa 2 Lmite del sistema. En esta etapa se ejecutan dos subprocesos: Determinar la funcionalidad que se incluir
en la medicin (2.1), en base al punto de vista y propsito de la medicin se determina incluir todos los escenarios
que representan la funcionalidad del sistema desde la visin del usuario. La Regla 15 establece el lmite que incluye
a todos los escenarios. Los usuarios interactan con el sistema a travs del lmite establecido, en consecuencia es
necesario identificarlos. En el segundo subproceso, Identificar usuarios (2.2), se determina la lista de usuarios que
interactan con el sistema a travs del lmite del sistema (Regla 16).
Etapa 3 Identificacin episodios. Luego de elegir el lmite apropiado, la siguiente decisin ms crtica es
determinar correctamente el conjunto de episodios asociados con los usuarios identificados. Esta etapa requiere los
subprocesos:
3.1 Descomponer los escenarios en episodios. Los escenarios comprendidos dentro del lmite del sistema se deben
descomponer en los episodios. Se requiere analizar cada uno de los escenarios e incorporar cada uno de los episodios
que no son escenarios a una lista.
3.2 Eliminar episodios repetidos de la lista. De la lista de episodios obtenida previamente se deben eliminar los
episodios que aparecen repetidos. Esto significa comparar cada uno de los episodios con los otros que estn en la
lista y si representa la misma funcionalidad que otro existente quitarlo de la lista.
3.3 Reducir a episodios simples. Los episodios de la lista de episodios candidatos obtenida en el paso anterior deben
analizarse segn las reglas de la seccin 4.1 para decidir su permanencia o exclusin de la lista.
3.4 Descartar los episodios que no incluyen funcionalidad. Se requiere eliminar de la lista de episodios candidatos a
aqullos que no aportan funcionalidad.
3.5 Organizar un catlogo de episodios. Un enfoque recomendado cuando se analizan y definen los requerimientos
del software es producir versiones refinadas sucesivamente de un catlogo de las transacciones lgicas que se
requiere que realice la aplicacin (o proyecto). Durante las primeras etapas de anlisis del problema el catlogo de
transacciones lgicas consistir de una lista de todos los eventos y consultas candidatos [19].
Se utiliza el Formulario 1 Catlogo de episodios para registrar los episodios. La Figura 1 muestra un ejemplo
del caso de estudio Recepcin del Hotel [1].
Figura 1. Formulario 1: Catlogo de episodios

Etapa 4 Descomposicin episodios. Un paso previo a la realizacin del clculo de la funcionalidad de un episodio
es reconocer sus componentes E-P-S y en cada uno determinar sus DET y recursos segn corresponda. Se requieren
los siguientes subprocesos:
4.1 Identificar los componentes E-P-S. Es necesario analizar la estructura de cada episodio para descomponerlo en la
parte correspondiente a ingreso de datos desde el usuario, proceso a realizar dentro del lmite y retorno de
informacin hacia el usuario.
4.2 Identificar los DET de cada componente. Tanto el componente E como el componente S de un episodio incluyen
datos que provienen desde o se retornan hacia el usuario. Para identificar los DET se aplican las Reglas 8 a 11.
Por cada episodio Pi se genera un Formulario 2 Detalle del anlisis por episodio que se utiliza para registrar los
DET identificados en los componentes E y S del episodio.
4.3 Identificar los recursos de cada componente. El componente P de un episodio incluye referencias a recursos.
Para identificar los recursos se aplica la Regla 12.
En el Formulario 2 del episodio se registran los recursos identificados en el componente P del episodio Pi. Al
finalizar la Etapa 4 se habr completado parte del Formulario 2 de cada episodio.
Etapa 5 Contabilizacin DET y recursos referenciados. Posteriormente a la identificacin de los DET y recursos
en los componentes respectivos se requiere contabilizarlos. Se realizan los siguientes subprocesos:
5.1 Contar DET en el componente entrada del episodio. Se cuenta la cantidad de DET y se completa el campo
TOTAL de la columna DET ENTRADA del Formulario 2 del episodio Pi con el valor N .
I i
5.2 Contar referencias a recursos. Se cuenta la cantidad de recursos referenciados y se completa el campo TOTAL de
la columna RECURSO REFERENCIADO del Formulario 2 del episodio Pi con el valor N R .
i
5.3 Contar DET en el componente salida del episodio. Se cuenta la cantidad de DET y se completa el campo TOTAL
de la columna DET SALIDA del Formulario 2 del episodio Pi con el valor N O
i
Al final de la Etapa 5 se habrn completado tantas copias del Formulario 2 como episodios haya en el catlogo de
episodios, en la Figura 2 se reproduce la resultante.
Figura 2. Formulario 2 de un episodio

En este punto del proceso se copia la informacin asociada a cada episodio obtenida desde los respectivos campos
TOTAL del Formulario 2 en las columnas CANTIDAD DET ENTRADA, CANTIDAD REC. REF. y CANTIDAD DET SALIDA del
Formulario 3 Resumen del clculo de los FP.
Etapa 6 Determinacin tamao funcional. El tamao funcional FP de un episodio resulta de la suma de NI , NR y

NO, esto se realiza para cada episodio y la sumatoria de todos ellos produce los FP del sistema. Para ello se requieren
dos subprocesos. Calcular los FP del episodio (6.1) en el que se calcula el tamao funcional del episodio Pi y se
completa el campo FP del episodio en el Formulario 3 (Figura 3). En el segundo, Calcular los FP de la aplicacin
(6.2), se calcula la sumatoria de los FP de cada episodio y se completa el campo TOTAL FP del Formulario 3. En este
punto finaliza el proceso con la obtencin de los FP del sistema.
Figura 3. Formulario 3: Resumen del clculo de los FP
6. Aplicacin a casos de estudio.

Este enfoque se aplic a cuatro casos de estudio. En [3] se presenta un anlisis detallado de los resultados y las
conclusiones obtenidas. La Tabla 2 resume la aplicacin al caso de estudio Recepcin del Hotel [1].
La aplicacin de FPA a L&E fue realizada por el primero de los autores de este paper. El esfuerzo requerido por la
aplicacin de FPA a L&E se redujo sustancialmente cuando el proceso se estabiliz y se cont con una definicin
precisa de sus actividades y se alcanz destreza en su ejecucin. La medicin de los dos ltimos casos de estudio
requiri 11 y 9,6 hs. respectivamente, destacando que el ltimo era un sistema muy grande. El anlisis comparativo
de ambos indica que: 1) el esfuerzo por episodio para el primer caso fue superior en un 60%; 2) el esfuerzo por PF
fue un 135% mayor. Estos resultados, si bien pueden ser indicadores del esfuerzo que significan las mediciones,
demandan mayor experimentacin para establecer estimaciones del esfuerzo de medicin.
7. Conclusiones y trabajos futuros.

Los casos de estudio atacados permiten responder positivamente a la pregunta existe un proceso para medir FP
en productos de la etapa de elicitacin de requerimientos?, vale decir: se pueden medir los FP a partir de L&E con un
proceso definido.
La medicin inicial del tamao funcional de un sistema con un proceso eficiente tiene las ventajas de facilitar la
estimacin del tamao de una aplicacin en la etapa inicial del desarrollo y posibilitar el refinamiento en las etapas
posteriores.
Este artculo presenta el proceso de medicin desarrollado para obtener mediciones de tamao de los artefactos
producidos en la etapa de elicitacin de requerimientos. El enfoque desarrollado permite medir el tamao funcional
de los Escenarios producidos en el contexto de L&E y se basa en el Mtodo MKII FPA. Las similitudes conceptuales
identificadas entre el modelo de transacciones de MKII y los episodios de los escenarios permitieron establecer una
conceptualizacin de contabilizacin de FP, describir un proceso para ejecutarla y aplicar el desarrollo a un conjunto
de casos, obtenindose resultados alentadores.
Aunque se carece de mediciones formales del esfuerzo de estimacin realizado, se observ una notable reduccin
del esfuerzo requerido a medida que se fue adquiriendo experiencia en el proceso, de todas maneras la estimacin del
esfuerzo requiere mayor experimentacin. El uso de una herramienta automatizada que soporte el proceso de clculo
permitira reducirlo an ms. Se considera que la aplicacin de esta propuesta de FPA no representa una carga
significativa al proceso de elicitacin.
Tabla 2. Resumen del caso de estudio Recepcin del Hotel
Etapa Subproceso
Observaciones del caso de estudio Recepcin del Hotel
Nombre
1.Punto de vista y 1.1 Determinar el propsito de la
propsito de la medicin
medicin 1.2 Determinar el punto de vista
Lmite del sistema incluye 10 escenarios: cancelacin
de reserva, check in, check out, pago, pedido de
2.1 Determinar la funcionalidad
alojamiento, pedido de servicio extra, recepcin del
que se incluir en la medicin
Hotel, reposicin de insumos, servicio de despertador,
2.Lmite del
solicitud de reserva.
sistema
Lista de 8 usuarios: Recepcionista, Agencia, otro
hotel, pasajero, Departamento Mantenimiento,
2.2 Identificar usuarios
Departamento Mucamas, Departamento
Administracin, Departamento Compras.
3.1 Descomponer los escenarios Se identifican 53 episodios pertenecientes a los 10
en episodios escenarios.
3.2 Eliminar episodios repetidos
Se descartan 7 episodios.
de la lista
Se descartan 13 episodios: 4 Excepcin, 7
3.Identificacin 3.3 Reducir a episodios simples
Restriccin, 2 Escenario
episodios 3.4 Descartar los episodios que
Se descartan 15 episodios.
no incluyen funcionalidad
Incluye 17 episodios pertenecientes a 8 escenarios.
Formulario
3.5 Organizar un catlogo de Se descartan 2 escenarios: en uno los episodios son
Catlogo de
episodios escenarios y en el otro los episodios estn repetidos
episodios
en otros escenarios.
4.1 Identificar los componentes Se descompone cada episodio en componentes
E-P-S entrada, proceso y salida.
4.Descomposicin 4.2 Identificar los DET de cada Se identifican los DET en los componentes entrada y
episodios salida.
componente
Se registran los DET de entrada y DET de salida.
4.3 Identificar los recursos de Se identifican los recursos en el componente proceso.
cada componente Se registran los recursos 17 Formularios
5.1 Contar DET en el Detalle del
componente entrada del Se cuentan 50 DET anlisis por
episodio episodio
5.Contabilizacin 5.2 Contar referencias a recursos
DET y recursos en el componente proceso del Se cuentan 22 recursos referenciados
referenciados episodio
5.3 Contar DET en el
componente salida del Se cuentan 31 DET
episodio
6.Determinacin 6.1 Calcular los FP del episodio Se calculan los FP de cada episodio Formulario
tamao 6.2 Calcular los FP de la Se suman los FP de cada episodio y se obtienen 103 Resumen del
funcional aplicacin FP. clculo de los FP
En cuanto a los trabajos futuros hay un programa general establecido [3]. En el campo especfico del proceso de
medicin las futuras investigaciones debern orientarse en la direccin de estabilizar y profundizar el resultado. Ello
significa construir un modelo conceptual adecuado del proceso y avanzar en los resultados experimentales. Para ello
se investigar la posibilidad de desarrollar un proceso para aplicar otros enfoques de FPA, por ejemplo IFPUG y
extender su alcance a otros tipos de escenarios de elicitacin [18]. Tambin es necesario construir una herramienta
CASE que soporte el proceso, establecer mediciones del esfuerzo requerido por el proceso de contabilizacin de FP
en L&E e investigar la curva de aprendizaje del proceso y estrategias de implantacin posibles en ambientes
productivos.
8. Referencias.
[1] Bertolami, M., Centeno, E., LEL y Escenarios de la Recepcin del Hotel, Caso de estudio desarrollado en el marco del
Magster en Ingeniera del Software, U. N. L. P., 2001.
[2] Bertolami, M., Una propuesta de Anlisis de Puntos Funcin aplicado a LEL y Escenarios, Tesis del Magster en Ingeniera
de Software presentada a la Facultad de Informtica de la U. N. L. P., 2003.
[3] Bertolami, M., Anlisis de Puntos Funcin en la elicitacin de requerimientos, Workshop on Requirements Engineering,
Piracicaba, Brasil, 2003.
[4] Davis, A., Software Requirements: Objects, Functions, and States, Englewood Cliffs, Prentice Hall, 1993.
[5] Dekkers, C.A., Managing (the Size of) Your Projects A Project Management Look at Function Points, CROSSTALK The
Journal of Defense Software Engineering, Feb. 1999.
[6] Dekkers, C., Aguiar, M. Applying Function Point Analysis to Requirements Completeness, CROSSTALK The Journal of
Defense Software Engineering, Feb. 2001
[7] Fenton, N., Pfleeger, S., Software metrics A rigorous and Practical approach, Second Edition, PWS Publishing Company,
1996.
[8] Fetcke, T., Abran, A., Nguyen, T., Mapping the OO-Jacobson Approach into Function Point Analysis, Universit du Qubec
Montreal, Software Engineering Management Research Laboratory, 1998.
[9] Grant Rule, P., Scenarios, Use Cases & MKII FPA, GIFPA (Guild of Independent Function Points Analysts), 1998.
[10] Hadad, G., Kaplan, G., Oliveros, A., Leite, J., Integracin de Escenarios con el Lxico Extendido del Lenguaje en la
elicitacin de requerimientos. Aplicacin a un caso real, Universidad de Belgrano, 1996.
[11] Hadad, G., Kaplan, G., Oliveros, A., Leite, J., Construccin de Escenarios a partir del Lxico Extendido del Lenguaje, 26
JAIIO, Buenos Aires, Argentina, 1997.
[12] Jones, C., Software Measurement Programs and Industry Leadership, Software Productivitiy Research Inc, CROSSTALK,
The Journal of Defense Software Engineering, Feb. 2001.
[13] Leite, J., Oliveros, A., Rossi, G., Balaguer, F., Hadad, G., Kaplan, G., Maiorana, V., Lxico extendido del lenguaje y
escenarios del sistema nacional para la obtencin de pasaportes, Universidad de Belgrano, 1996.
[14] Leite J., Rossi G., et al, Enhancing a Requirements Baseline with Scenarios, Proceedings of RE 97 International
Symposium on Requirements Engineering, IEEE, 1997.
[15] Leite, J., Hadad, G., Doorn, J., Kaplan, G., A Scenario Construction Process, Requirements Engineering Journal, 2000.
[16] Longstreet, D., Use cases and function points, Longstreet Consulting Inc, 2000.
[17] Loucopoulos, P., Karakostas, V., System Requirements Engineering, McGraw-Hill, 1995.
[18] Maiden, N., CREWS-SAVRE: Scenarios for Acquiring and Validating Requirements, Automated Software Engineering,
vol 5, nro4, 1998.
[19] MKII Function Points Analysis Counting Practices Manual, Versin 1.3.1, UKSMA (United Kingdom Software Metrics
Association), 1998.
[20] Probasco, L., Dear Dr. Use Case: What About Function Points and Use Cases?, RationalEdge, agosto 2002
[21] Rolland, C., Modeling the Requirements Engineering Process, Universit de Paris I Pantheon-Sorbonne, 1993.
[22] Symons, C., Software sizing and estimating MKII FPA, John Wiley and Sons, 1991.
[23] Tavares, H., Carvalho, A., Castro, J., Medio de pontos por funo a partir da especificao de requisitos, Workshop on
Requirements Engineering, Valencia, Espaa, 2002.
[24] http://www.colostate.edu/Depts/Speech/rccs/theory35.htm, consultado en diciembre 2003.
[25] http://www.isbsg.org.au/html/homepage.html, International Software Benchmarking Standards Group, consultado en agosto
2003.
ArgoCASEGEO - Uma Ferramenta CASE de Cdigo-Aberto para o

Modelo UML-GeoFrame
Jugurta Lisboa Filho

Maurcio Fidlis Rodrigues Jnior
Jaudete Daltio
Universidade Federal de Viosa - Departamento de Informtica
Campus da UFV, 36570-000 Viosa, MG, Brasil
{jugurta, mfrj, jdaltio}@dpi.ufv.br
Resumo
Este artigo descreve o desenvolvimento de uma ferramenta CASE de cdigo aberto, a ArgoCASEGEO,
bem como sua arquitetura modular. A ferramenta ArgoCASEGEO permite a modelagem de banco de dados
geogrficos com base no modelo conceitual UML-GeoFrame, que especfico para aplicaes de Sistemas
de Informao Geogrfica (SIG). O artigo descreve ainda as regras de transformao empregadas pelo
mdulo de gerao automtico do esquema lgico-espacial para o SIG GeoMedia. O dicionrio de dados
associado ao esquema modelado armazenado como um documento XML/XMI, visando sua utilizao por
outros programas.
1. Introduo.
Bancos de Dados Geogrficos (BDG) so colees de dados georreferenciados, manipulados por Sistemas
de Informao Geogrfica (SIG). Na rea de geoprocessamento, normalmente o prprio usurio que
desenvolve as aplicaes de SIG. Assim, redundncia e inconsistncia so caractersticas marcantes na
maioria dos BDG, muitas vezes comprometendo a confiabilidade do sistema e, conseqentemente, pondo em
risco grandes investimentos pblicos ou privados. Desta forma, o desenvolvimento de metodologias e de
ferramentas que auxiliem os projetistas de BDG so fundamentais para a melhoria da qualidade das
aplicaes de SIG.
Um BDG pode ser projetado com base em metodologias tradicionais de projeto de banco de dados [8], ou
seja, as fases de projeto conceitual, lgico e fsico devem ser contempladas. Um esquema conceitual de dados
elaborado na fase de projeto conceitual, sendo necessrio definir o modelo de dados a ser utilizado, o que
vai facilitar a comunicao entre projetistas e/ou usurios envolvidos. Diversos modelos especficos para
modelagem de BDG tm sido propostos e aperfeioados nos ltimos anos, entre os mais citados esto os
modelos GeoOOA [14], MADS [23], OMT-G [4], UML+SpatialPVL [1] e UML-GeoFrame [17].
Concluda a modelagem conceitual, o prximo passo - projeto lgico - consiste na transformao do

esquema conceitual em um esquema de dados compatvel com o modelo de dados do software de SIG que
ser utilizado. Esta etapa de transformao de um esquema conceitual em um esquema lgico-espacial, e sua
implantao em um software de SIG, pode ser feita de forma automtica por uma ferramenta CASE
(Computer Aided Software Engineering). Alguns dos modelos conceituais citados anteriormente so
suportados por ferramentas CASE como, por exemplo, Perceptory [5], REGIS [13], AIGLE [15] e Editor Java
MADS [20].
Porm, uma dificuldade enfrentada por estas ferramentas que cada software de SIG implementa seu
prprio modelo de dados. A falta de um modelo de representao de dados espaciais padronizado acarreta
problemas na troca de dados entre softwares de SIG distintos, que incluem perda na preciso de dados,
comprometimento de qualidade da informao, perda de definies de atributos e georreferenciamento. Para
que o intercmbio de dados espaciais acontea sem o comprometimento da informao necessrio um alto
grau de interoperabilidade entre os SIG. Com esta finalidade, o consrcio OpenGIS vem definindo um
modelo padro para a troca de dados, que suportado pela linguagem XML/GML (Geography Markup
Language), para o transporte e o armazenamento de informaes geogrficas, incluindo aspectos geomtricos
e propriedades de objetos de interesse [24].
Este artigo descreve a arquitetura da ArgoCASEGEO, uma ferramenta CASE de cdigo aberto para
modelagem de BDG que suporta o modelo UML-GeoFrame [17]. O esquema conceitual elaborado por esta
ferramenta armazenado em um documento XML (Extensible Markup Language), de forma que possa ser
facilmente acessado e manipulado. Esta ferramenta tambm prov um mdulo de gerao automtica, capaz
de gerar esquemas de dados para os formatos mais comumente encontrados nos principais SIG comerciais.
Alm disso, a ArgoCASEGEO possui suporte para reutilizao de esquemas de dados baseado em padres de
anlise [9].
O restante deste artigo est organizado da seguinte forma: a seo 2 apresenta um resumo do modelo
UML-GeoFrame. A seo 3 descreve as vantagens do uso de padres de anlise na modelagem conceitual de
BDG. A seo 4 detalha o desenvolvimento da ferramenta ArgoCASEGEO, mostrando sua arquitetura e
descrevendo cada mdulo implementado. Consideraes finais e trabalhos futuros so descritos na seo 5.
2. O Modelo UML-GeoFrame.
A modelagem conceitual de BDG com base na linguagem UML [3] e no framework GeoFrame [17] produz
um esquema de banco de dados de fcil entendimento, melhorando a comunicao entre projetistas e/ou
usurios. Alm de ser usado na elaborao de esquemas de banco de dados, o modelo UML-GeoFrame
adequado para especificao de padres de anlise [9].
O GeoFrame um framework conceitual que fornece um diagrama de classes bsicas para auxiliar o
projetista nos primeiros passos da modelagem conceitual de dados de uma nova aplicao de SIG. O uso
conjunto do diagrama de classes da linguagem UML e o GeoFrame permitem a soluo da maioria dos
requisitos de modelagem de aplicaes de SIG. Um esquema conceitual de dados geogrficos construdo com
base no modelo UML-GeoFrame inclui, por exemplo, a modelagem dos aspectos espaciais da informao
geogrfica e a diferenciao entre objetos convencionais e objetos/campos geogrficos. A especificao
desses elementos feita com base no conjunto de esteretipos mostrados na Figura 1.
Fenmeno geogrfico e Componente espacial Componente espacial

Objeto convencional de objetos geogrficos de campos geogrficos
Objeto geogrfico Ponto Pontos irregulares

Campo geogrfico Linha Grade de pontos
Objeto no geogrfico Polgono
Polgonos adjacentes
Obj. espacial complexo Isolinhas
<<funo>> funo categrica
Grade de clulas
TIN
Figura 1 Esteretipos do Modelo UML-GeoFrame
O primeiro conjunto de esteretipos (Fenmeno geogrfico e Objeto convencional) usado para

diferenciar os dois principais tipos de objetos pertencentes a um BDG. Fenmeno geogrfico especializado
em Objeto geogrfico () e Campo geogrfico (), segundo as duas formas de percepo dos fenmenos
geogrficos, descritas por Goodchild [11]. Objetos no geogrficos so modelados de forma tradicional e so
identificados atravs do esteretipo ().
Os conjuntos de esteretipos Componente espacial de objetos geogrficos e Componente espacial de

campos geogrficos so usados para a modelagem do componente espacial de fenmenos segundo as vises
de objeto e de campo, respectivamente. A existncia de mltiplas representaes modelada atravs da
combinao de dois ou mais esteretipos em uma mesma classe. Por exemplo, uma classe Municpio pode ter
duas formas de abstrao de seu componente espacial, pontual e poligonal, o que especificado pelo par de
esteretipos ().
Por ltimo, o esteretipo <<funo>> usado para caracterizar um tipo especial de associao que ocorre
na modelagem de campos categricos. Segundo Chrisman [7], numa estrutura de cobertura categrica o
espao classificado em categorias mutuamente exclusivas, ou seja, uma varivel possui um valor do tipo
categoria em todos os pontos dentro de uma regio (ex.: tipos de solos). A Figura 2 ilustra um diagrama de
classes no modelo UML-GeoFrame contendo dois temas: Educao e Meio-Ambiente.
Educao
Bairro
Cidade

* 1
idBairro codMun
nome nome
populao Meio-Ambiente
1
* <<funo>> Tipo
Vegetao
Escola
Aluno
Vegetao
1 *
nome nome Tempe-
Relevo
contato endereo ratura
endereo responsvel
Figura 2 Exemplo de esquema UML-GeoFrame
No tema Educao, modelado como um pacote UML, pode-se observar as classes de fenmenos
geogrficos na viso de objetos Cidade e Bairro, cuja representao espacial do tipo polgono, e a classe
Escola, com representao espacial do tipo ponto. Alm destas, Aluno uma classe modelada como objeto no
geogrfico. No tema Meio-Ambiente esto modeladas trs classes de fenmenos geogrficos percebidos na
viso de campo, que so Vegetao, Relevo e Temperatura, cada uma com seus diferentes tipos de representao
espacial. Este tema inclui ainda a classe Tipo Vegetao, que modelada como objeto no geogrfico, estando
associada classe Vegetao (representada por polgonos adjacentes) atravs do esteretipo <<funo
categrica>>, ou seja, cada regio/polgono est associada a um tipo de vegetao.
3. Padres de Anlise.
Um padro de anlise um mecanismo de reutilizao que permite aos projetistas menos experientes
reutilizarem o conhecimento de outros especialistas. Segundo Gamma e outros, um padro apresenta a
essncia de uma soluo para um problema recorrente, em um contexto especfico [10]. Esta definio
genrica, que serve tanto para os padres de projeto (design patterns) quanto para os padres de anlise
(analysis patterns) compreende as idias fundamentais de um padro. A expresso uma soluo para um
problema significa que cada padro identifica um problema e apresenta uma soluo para ele. A expresso
essncia de uma soluo significa que somente os elementos essenciais so descritos, deixando os aspectos
especficos para serem detalhados pelo projetista, dado que aspectos especficos normalmente no so
reutilizados. A expresso problema recorrente significa que os padres devem ser descritos para problemas
que j ocorreram diversas vezes e iro ocorrer novamente. Por ltimo, em um contexto especfico significa
que a soluo completa vlida para um contexto particular.
Um padro de anlise descreve um conjunto de classes, possivelmente pertencentes a diferentes hierarquias

de classes, e as associaes existentes entre elas [9]. Padres de anlise podem ser vistos, portanto, como uma
forma de descrever subesquemas de projetos mais complexos, os quais ocorrem com freqncia durante o
processo de modelagem de muitas aplicaes. O uso de padres melhora, de forma significativa, o tempo de
desenvolvimento de novas aplicaes, uma vez que a reutilizao ocorre atravs de subesquemas e no
atravs de classes isoladas [12].
Geralmente, um padro de anlise apresenta a soluo do problema de uma forma mais sugestiva do que
prescritiva, fornecendo um modelo e a discusso do porqu a soluo proposta desta forma, suas vantagens
e desvantagens. Segundo Fowler, a contribuio realmente importante de um padro no o modelo
fornecido como soluo, mas sim, o raciocnio que est por trs desta soluo [9].
A maioria dos padres de anlise publicados at o momento foi projetada, principalmente, para solucionar
problemas de aplicaes comerciais como, por exemplo, os padres descritos em [9] e [12]. No entanto, a
idia de padres de anlise pode ser usada para aumentar a qualidade e a produtividade no desenvolvimento
de aplicaes no-convencionais como as aplicaes de SIG. A adequabilidade do uso de padres de anlise
na modelagem de BDG mostrada em [16]. Exemplos de padres de anlise para aplicaes de SIG podem
ser encontrados em [2] e [18].
4. A Ferramenta ArgoCASEGEO.
ArgoCASEGEO uma ferramenta CASE que tem como objetivo dar suporte modelagem de BDG com
base no modelo UML-GeoFrame. Os esquemas de dados elaborados a partir desta ferramenta so
armazenados no formato XMI (XML Metadata Interchange), uma sintaxe para armazenamento de esquemas
conceituais de dados, em documentos XML [21].
Em sntese, XMI combina os benefcios da XML para definio, validao e compartilhamento de

formatos de documentos com os benefcios da linguagem de modelagem visual UML para especificao,
visualizao, construo e documentao de objetos distribudos e modelos de negcios.
Uma ferramenta CASE , antes de tudo, um software de desenho grfico. Para evitar um grande esforo de
programao no sentido de desenvolver uma ferramenta grfica desde o incio, optou-se por utilizar como
ponto de partida algum software grfico existente. Este software deveria suportar o desenho de diagramas de
classes da linguagem UML e ser extensvel para suportar os esteretipos definidos no modelo UML-
GeoFrame.
Aps analisar algumas alternativas, optou-se pelo editor ArgoUML como ferramenta de trabalho. Assim, a
ArgoCASEGEO foi desenvolvida como uma extenso do software ArgoUML, uma ferramenta de modelagem
que se encontra sobre uma licena de utilizao e distribuio open-source, desenvolvida na linguagem Java.
ArgoUML suporta diversos diagramas UML, como o de classes, casos de uso, atividade e de colaborao.
A Figura 3 ilustra a arquitetura da ferramenta ArgoCASEGEO, que composta de quatro mdulos. O

Mdulo Grfico permite projetar o esquema conceitual, provendo um conjunto de construtores do modelo
UML-GeoFrame. O Mdulo Dicionrio de Dados armazena a descrio detalhada dos elementos do diagrama
criado pelo projetista, no formato XMI. O Mdulo Gerao Automtica permite a transformao de esquemas
conceituais armazenados no dicionrio de dados em esquemas lgicos correspondentes a alguns modelos
utilizados em SIG comerciais. O Mdulo de Engenharia Reversa, ainda no implementado, possibilitar ao
projetista obter esquemas conceituais a partir de aplicaes de SIG existentes.
Mdulo Grfico
Diagrama Repositrio de
UML- ArgoUML
(Java) Padres de
GeoFrame Anlise
Mdulo Dicionrio de Dados

Repositrio de
Metamodelo Esquemas
UML- XML/XMI Conceituais de
GeoFrame dados
Mdulo Gerao Automtica Mdulo de Engenharia

Reversa
Regras de Regras de
Transformao Transformao
Conceitual- Lgico-
Lgico Conceitual
Formato outros OpenGIS

GeoMedia TerraLib
Shape formatos (GML)
Figura 3 Arquitetura da Ferramenta ArgoCASEGEO
As sees seguintes descrevem detalhadamente cada um destes mdulos.
4.1 Mdulo Grfico.
A ferramenta ArgoCASEGEO possibilita a criao de diagramas que contm os construtores e esteretipos

sugeridos pelo modelo UML-GeoFrame. A partir deste diagrama o usurio pode criar o seu esquema
conceitual de dados. Um esquema conceitual UML-GeoFrame suporta trs tipos distintos de classes: Objeto
Geogrfico, Objeto no Geogrfico e Campo Geogrfico. Os campos existentes nas classes implementadas
apresentam nome, atributos (e seus respectivos domnios), operaes e smbolos correspondentes ao tipo de
representao espacial.
Essas classes podem estar relacionadas entre si por meio de relacionamentos como generalizao &
especializao, agregao, composio ou associao. Numa associao podem ser especificados o nome do
relacionamento e a multiplicidade de cada classe. As classes podem estar agrupadas de forma a constiturem
um determinado tema, o que modelado pelo construtor Pacote, da linguagem UML. A barra de construtores
disponveis ilustrada na figura 4.
Figura 4: Barra de Ferramentas para o diagrama UML-GeoFrame

A Figura 5 ilustra o ambiente ArgoCASEGEO contendo o padro de anlise Malha Viria Urbana, composto
das classes NLogradouro, TrechoLogradouro e MalhaViria, que so subclasses da classe Objeto_Geogrfico ()
e a classe Logradouro, subclasse de Objeto_No_Geogrfico (), isto , no possui representao espacial. A
classe NLogradouro possui representao espacial do tipo ponto (), Trecho Logradouro do tipo linha () e
Malha Viria do tipo complexo (). Esto representados relacionamentos do tipo associao e agregao entre
as classes modeladas.
Figura 5 Ambiente grfico do ArgoCASEGEO representando o padro de anlise Malha Viria no

modelo UML-GeoFrame.
Um esquema de dados UML-GeoFrame pode ser salvo como um novo Padro de Anlise, podendo ser
(re)utilizado em novos esquemas de dados, compondo-se assim, o Catlogo de Padres de Anlise. Por outro
lado, se o projetista est iniciando um novo projeto interessante antes consultar os padres de anlise
existentes a fim de reutiliz-los. Alm do diagrama, um padro de anlise pode conter uma documentao
adicional, na qual podem estar descritos o contexto, as foras e exemplos de uso do padro.
4.2. Mdulo Dicionrio de Dados.
O dicionrio armazena o esquema de dados criado pelo usurio. Um esquema possui dois tipos de dados,
os grficos (desenho) e os semnticos (nomes das classes, dos atributos, multiplicidades das associaes, etc).
No dicionrio de dados so armazenados os dados semnticos, enquanto os dados grficos so armazenados
em um arquivo do prprio ArgoCASEGEO.
O dicionrio de dados armazena os esquemas conceituais no formato XMI. Toda classe delimitada por
um tag (ou marcao) que contm o nome da classe, suas representaes espaciais (que variam de acordo com
o tipo de classe especificada) e suas caractersticas (features). A tag feature possui dois nveis de
detalhamento, responsveis por armazenar os dados correspondentes a seus atributos e operaes.
A figura 6 exemplifica o dicionrio de dados correspondente classe TrechoLogradouro, que possui

representao espacial do tipo linha, o atributo SentidoCirc e a operao getSentidoCirc. Os tipos usados nesta
definio, incluindo o tipo do atributo, parmetros e valores de retorno das operaes so referenciados
externamente para outro trecho de cdigo do mesmo arquivo que armazena as definies destes tipos, criado
pelo prprio ArgoUML.
<Foundation.Core.Class>
<Foundation.Core.ModelElement.name>TrechoLogradouro</Foundation.Core.ModelElement.name>
<Foundation.Core.GeneralizableElement.isLine xmi.value="true"/>
<Foundation.Core.Classifier.feature>
<Foundation.Core.Attribute>
<Foundation.Core.ModelElement.name>SentidoCirc</Foundation.Core.ModelElement.name>
<Foundation.Core.Classifier xmi.idref="xmi.16"/>
</Foundation.Core.Attribute>
<Foundation.Core.Operation>
<Foundation.Core.ModelElement.name>getSentidoCir</Foundation.Core.ModelElement.name>
<Foundation.Core.Parameter.type>
</Foundation.Core.Parameter.type>
</Foundation.Core.Operation>
</Foundation.Core.Classifier.feature>
</Foundation.Core.Class>
Figura 6 Representao de uma classe UML-GeoFrame em XMI
Os relacionamentos entre as classes modeladas no esquema so mantidos em um tag especfico, que

armazena seu nome, propriedades relacionadas (que variam de acordo com o tipo, associao, agregao ou
composio), sua multiplicidade e as referncias das classes que compe o relacionamento. Para a definio
de generalizaes, o tag interno responsvel por armazenar referncias s subclasses e s superclasses.
Herana mltipla permitida.
Por fim, as definies dos pacotes so mantidas em um tag mais externo, que engloba todas as outras
descritas anteriormente e possui apenas seu nome como atributo. A figura 7 exemplifica o dicionrio de dados
correspondente associao Rel_Logr_Trec, que possui navegabilidade em ambas direes, multiplicidade um-
para-muitos (1-*) e referncias para as classes que o compe.
<Foundation.Core.Association xmi.id="xmi.5">
<Foundation.Core.ModelElement.name>Rel_Logr_Trec</Foundation.Core.ModelElement.name>
<Foundation.Core.Association.connection>
<Foundation.Core.AssociationEnd xmi.id="xmi.6">
<Foundation.Core.AssociationEnd.isNavigable xmi.value="true"/>
<Foundation.Data_Types.MultiplicityRange xmi.id="xmi.8">
<Foundation.Data_Types.MultiplicityRange.lower>1</Foundation.Data_Types.Multiplic
ityRange.lower>
<Foundation.Data_Types.MultiplicityRange.upper>*</Foundation.Data_Types.Multiplic
ityRange.upper>
</Foundation.Data_Types.MultiplicityRange>
</Foundation.Core.AssociationEnd.association>
</Foundation.Core.AssociationEnd>
</Foundation.Core.Association.connection>
</Foundation.Core.Association>
FIGURA 7 Representao de uma associao armazenada em XMI

4.3. Mdulo Gerao Automtica.
Aps a realizao da modelagem conceitual, o usurio necessita transformar o esquema elaborado em uma
implementao efetiva, caracterizando uma aplicao de SIG. Isto deve ser realizado aps a definio do
software de SIG que ser utilizado. Como cada software de SIG possui seu prprio modelo lgico de dados,
no possvel estabelecer um conjunto nico de regras de transformao para fazer a gerao automtica do
esquema lgico-espacial, ao contrrio por exemplo da transformao de esquemas conceituais Entidade-
Relacionamento em esquemas lgicos dos SGBD relacionais. Desta forma, para cada software de SIG a
ferramenta ArgoCASEGEO necessita de um Mdulo de Gerao Automtica (MGA) especfico. Espera-se
que com a adoo de um modelo de dados padro, em desenvolvimento pelo Consrcio OpenGIS [22], este
problema seja resolvido.
Dois MGAs j foram implementados na ferramenta ArgoCASEGEO. O primeiro mdulo, descrito em [19],
transforma esquemas UML-GeoFrame para o formato Shape, usado no SIG ArcView 3.2 (ESRI) e importado
por quase todos os outros SIG. Um segundo mdulo de gerao, apresentado na seo abaixo, transforma
esquemas conceituais UML-GeoFrame em esquemas lgico-espaciais do SIG GeoMedia, da Intergraph. Os
prximos mdulos a serem implementados so: (1) MGA-GML, que ir gerar esquemas segundo o modelo
padro que est sendo desenvolvido pelo consrcio OpenGIS; (2) MGA-TerraLib, que ir gerar esquemas de
dados no formato da biblioteca de componentes espaciais TerraLib [6].
4.3.1. Mdulo de Gerao Automtica GeoMedia.
O MGA-GeoMedia tem como entrada a identificao do dicionrio de dados que contm o esquema
conceitual a ser transformado. Para a criao de um ambiente de trabalho dentro deste software necessria a
criao de uma conexo com um banco de dados existente, que possa armazenar os layers (camadas de dados
espaciais) de representao vetorial, ou seja, uma coleo de elementos do tipo ponto, linha, polgono ou
objeto complexo, e as tabelas associadas a estes layers. Desta forma, o MGA-GeoMedia cria um banco de
dados para armazenar todos os elementos gerados pelo mapeamento automtico. O GeoMedia suporta vrios
outros SGBD relacionais.
Para cada elemento do esquema conceitual de dados aplicada uma determinada regra de transformao. A
seguir esto descritas estas regras.
Regra 1 Pacotes
Um pacote composto por um conjunto de classes inter-relacionadas. Portanto, define-se um banco de

dados GeoMedia para cada pacote no esquema conceitual, que armazenar todos os temas gerados pelo
mapeamento correspondente a ele, tanto os layers quanto suas tabelas relacionadas. Classes que no estejam
definidas dentro de um pacote so armazenadas em um banco de dados padro criado pelo mapeamento. Os
nomes destes arquivos e suas localizaes so fornecidos pelo usurio.
Regra 2 Classes do tipo Objeto Geogrfico ()
Cada classe modelada como Objeto_Geogrfico gera pelo menos um layer dentro do seu banco de dados
correspondente, cuja representao espacial definida de acordo com o esteretipo de representao a ela
atribuda. Estas representaes espaciais s podem ser do tipo ponto, linha, polgono ou objeto complexo. O
conjunto de atributos definidos na classe associado representao espacial, sendo definidos como campos
da mesma tabela relacional.
Para classes que possuam mltiplas representaes espaciais o usurio pode escolher entre gerar vrios
layers com as distintas representaes espaciais ou optar pela criao de um nico layer de representao
complexa, onde podem ser definidos tanto pontos, quanto linhas ou polgonos. O projetista deve decidir, em
tempo de execuo, qual tipo de mapeamento deseja.
Regra 3 Classes do tipo Campo Geogrfico ()
Como foi dito na seo 2, a realidade geogrfica pode ser observada de acordo com duas vises [11]. A
viso de campos geogrficos enxerga o espao geogrfico como uma superfcie contnua, sob a qual variam
os fenmenos a serem observados segundo diferentes distribuies.
O GeoMedia um software vetorial, ou seja, possibilita apenas a representao espacial de objetos do tipo
ponto, linha ou polgono. Portanto, no possvel realizar um mapeamento automtico dos objetos que so
modelados como campo. Porm, segundo Goodchild [11], as representaes de campos geogrficos nada
mais so do que agregaes de pontos, linhas e polgonos, acoplados a caractersticas espaciais. Um campo
com representao espacial do tipo Isolinhas, por exemplo, pode ser mapeado em um layer de representao
do tipo linha, possuindo um valor (cota) associado a cada linha. De acordo com esta anlise, o programa
prope algumas sugestes de mapeamento para o projetista, que pode optar por uma delas. Alm dos atributos
sugeridos, so acrescidos tabela tambm os atributos pertencentes a cada classe.
Regra 4 Classes do tipo Objeto No Geogrfico ()
Cada classe modelada como Objeto_No_Geogrfico gera apenas uma tabela dentro do banco de dados
correspondente. Objetos so classificados como No Geogrficos justamente por no possurem representao
espacial.
Regra 5 Associao, Agregao e Composio
O mapeamento de relacionamentos do tipo agregao, composio e associao realizado de acordo com

a multiplicidade especificada. Existem basicamente trs grandes tipos de multiplicidades de uma associao:
um-para-um (1..1); um-para-muitos (1..*); e muitos-para-muitos (*..*), sendo que os demais tipos so
derivaes destes. Este mapeamento se baseia nas regras de transformao de associaes especificadas em
um esquema conceitual para um esquema lgico de um SGBD relacional, que so bem conhecidas [8].
Regra 6 Generalizao & Especializao
O mapeamento de relacionamentos do tipo generalizao-especializao (IS-A) pode ser realizado de trs

formas distintas, descritas sucintamente abaixo. Estas opes de generalizao so informadas pelo projetista
durante a criao do esquema conceitual, sendo a opo (A) adotada como padro. So elas:
Opo A: Os atributos da superclasse e das subclasses so unidos em uma nica tabela, que recebe o nome
da superclasse. A representao espacial escolhida de acordo com os tipos das subclasses associadas. Por
exemplo, seja a superclasse Recursos_Hidricos que possui as subclasses Rio e Lago. Se ambas subclasses
possurem representao espacial do tipo polgono, Recursos_Hidricos tambm ser mapeada com esta
representao. Porm, se Rio for do tipo linha e Lago do tipo polgono, Recursos_Hidricos ter representao
mltipla.
Opo B: So mapeadas apenas as subclasses, de acordo com seus atributos e representaes espaciais. Os
atributos da superclasse so acrescentados ao conjunto de atributos das subclasses.
Opo C: criada para cada classe uma tabela contendo seus atributos. As subclasses possuem a
representao espacial definida no esquema conceitual e a superclasse composta apenas de uma tabela. Os
atributos definidos como chave da superclasse so mapeados tambm como atributos das subclasses. Cada
classe d origem a um layer com a representao espacial especificada e a uma tabela associada que contm
os atributos descritivos. As tabelas referentes s subclasses tm a mesma chave da tabela referente
superclasse.
Para exemplificar o processo de gerao automtica pode-se tomar como entrada o dicionrio de dados do
esquema conceitual mostrado na figura 5 (Padro Malha Viria). O MGA-GeoMedia ir criar o esquema lgico-
espacial mostrado na Figura 8. A janela Malha_Viria, com a sub-janela Legend ilustra o esquema espacial
gerado, composto de trs layers: Malha_Viria, com representao do tipo Objeto Complexo; N-Logradouro,
com representao do tipo ponto; e Trecho_Logradouro, com representao do tipo linha. As demais janelas
ilustram as tabelas relacionais que foram geradas, so elas: Logradouro, Malha_Viria, N-Logradouro e
Trecho_Logradouro. Com exceo da tabela Logradouro, as outras trs tabelas ficam automaticamente
relacionadas com seus respectivos layers. A partir deste esquema o usurio pode optar por incluir ou importar
os dados, realizando o processo de carga do BDG.
Figura 8 - Esquema Malha Viria gerado automaticamente para o GeoMedia
5. Concluses.
O uso de uma ferramenta CASE no processo de desenvolvimento de aplicaes de SIG faz com que o
tempo de criao do projeto seja reduzido, possibilitando uma conseqente reduo de custos e aumento na
qualidade dos bancos de dados geogrficos.
A ferramenta ArgoCASEGEO foi desenvolvida para auxiliar o projetista a desenvolver suas aplicaes de
SIG com mais qualidade, seguindo uma metodologia de projeto tendo como base um modelo conceitual
especfico para aplicaes geogrficas e uma coleo reutilizvel de padres de anlise. A documentao
produzida ao longo do projeto (ex.: esquema conceitual e dicionrio de dados) possibilita posteriores
consultas e visualizaes, o que facilita consideravelmente a futura manuteno do sistema e a gerao
imediata de novas verses da aplicao com as atualizaes. O armazenamento do dicionrio de dados no
formato XML/XMI permite o intercmbio de esquemas e pode servir para novos usos como, por exemplo, por
ferramentas automticas de descoberta e busca de padres de anlise.
Como trabalhos futuros esto previstos o desenvolvimento dos novos mdulos de gerao automtica
(MGA-GML e MGA-TerraLib) e a implementao do mdulo de engenharia reversa.
Agradecimento
Este trabalho foi parcialmente financiado pelo Conselho Nacional de Desenvolvimento Cientfico e
Tecnolgico CNPq, entidade governamental brasileira promotora do desenvolvimento cientfico e
tecnolgico.
6. Referncias bibliogrficas.
[1] Bdard, Y. Visual modeling of spatial databases towards spatial extensions and UML, Geomatica, v.53, n.2, 1999.
[2] Bhering, E. M.; Lisboa Filho, J.; Calijuri, M. L.; Souza, L. A. DE. A. Sistema de informao da rede de infra-
estrutura sanitria de Cachoeiro de Itapemirim-ES. Informtica Pblica, v.4, n.1, 2002.
[3] Booch, G.; Jacobson, I.; Rumbaugh, J. The Unified Modeling Language User Guide. Addison-Wesley, 1998.
[4] Borges, K. A. V.; Davis Jr, C. D. Laender, A.H.F. OMT-G: an object-oriented data model for geographic
applcations. GeoInformatica, v.5, n.3, 2001.
[5] Brodeur, J; Brdard, Y.; Proulx, M., J.; Modeling Geospatial Application Databases using UML-based
Repositories Aligned with International Standards in Geomatics. In Proc. 8th ACM GIS, Washinghton D.C, 2000.
[6] Cmara, G.; Monteiro, A. M. V.; Cartaxo, R.; Paiva, J. A. C. TerraLib - Tecnologia Brasileira de Geoinformao:
para quem e para qu?, Informtica Pblica, v.4, n.1, 2002.
[7] Chrisman, N. Exploring Geographic Information Systems. John Wiley & Sons, 1997.
[8] Elmasri, R.; Navathe, S. B. Fundamentals of Database Systems. 3.ed. Addison-Wesley, 2000.
[9] Fowler, M. Analysis Patterns: Reusable Object Models. Addison Wesley Longman, 1997.
[10] Gamma, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software. Addison Wesley, 1994.
[11] Goodchild, M. F., Geographical data modeling, Computers & Geosciences, v.18, n. 4, 1992, pp 401-408.
[12] Hay, D. C. Data Model Patterns: Conventions of Thought. Dorset House Publishing, 1995.
[13] Isoware. CASE-Toll REGIS. Disponvel em http://www.isoware.de/, Acessado em maro de 2002.
[14] Ksters, G. et al. GIS-Application Development with GeoOOA. Int. Jounnal of GIS, v.11, n.4, 1997.
[15] Lbath A., Pinet, F. The Development and Customization of GIS-Based Applications and Web-Based GIS
Applications with the CASE Tool AIGLE. In Proc. 8th ACM GIS, Washinghton D.C, 2000.
[16] Lisboa Filho, J.; Iochpe, C.; Beard, K. Applying Analysis Patterns in the GIS Domain. In Proc. 10th Annual
Colloquium of the SIRC, Dunedin, NZ, 1998,.
[17] Lisboa Filho, J.; Iochpe, C. Specifying analysis patterns for geographic databases on the basis of a conceptual
framework. In Proc.7th ACM GIS, Kansas City, 1999.
[18] Lisboa Filho, J.; Iochpe, C.; Borges, K. A. Analysis patterns for GIS data schema reuse on urban management
applications. CLEI Electronic Journal, v.5, n.2, 2002, pp 1-15.
[19] Lisboa Filho, J.; Pereira, M. A. Desenvolvimento de uma ferramenta CASE para o Modelo UML-Geoframe com
Suporte para Padres de Anlise. In: IV Simpsio Brasileiro de Geoinformtica - GEOINFO, 2002, Caxamb-MG.
Anais... Caxamb: SBC, 2002.
[20] Minout, M.; Parent, C.; Zimnyi, E. A Tool for Transforming Conceptual Schemas of Spatio-Temporal Databases
with Multiple Representations. In Proc. of the IASTED Int. Conf. on Database Applications, DBA'2004, Innsbruck,
Austria, 2004.
[21] Object Management Group. Meta Objects Facility (MOF) Specification. 2000. Available in: http://www.omg.org.
[22] OpenGIS. The OpenGIS Guide. K. Buehler and L Mckee (eds). Open GIS Consortium Technical Committee, 1998.
[23] Parent, C. et al. Spatio-temporal conceptual models: data structures + space + time. In Proc.7th ACM GIS, Kansas
City, 1999.
[24] Simon Cox , Paul Daisey, Ron Lake, Clemens Portele, Arliss Whiteside. OpenGIS Geography Markup Language
(GML) Implementation Specification. Open GIS Consortium, Inc., 2003.
Una Experiencia en la Validacin Terica de Mtricas de Software
Nelly Condori-Fernandez, Silvia Abraho y Oscar Pastor

Departamento de Sistemas Informticos y Computacin
Universidad Politcnica de Valencia, Camino de Vera s/n, 46022, Valencia.
{nelly,sabrahao,opastor@}dsic.upv.es
Resumen
Actualmente gran parte de las mtricas presentadas en la literatura no suelen ser validadas
tericamente, a pesar de los problemas identificados en el estado actual de la investigacin emprica
dentro del rea de la Ingeniera de Software. La validacin terica es una importante fase en la cual
aseguramos que una mtrica se adapta a los principios de la teora de la medicin (mide lo que
propone medir). En este trabajo, nosotros discutimos la utilizacin de un marco de validacin terica
denominado DISTANCE, mediante su aplicacin a un conjunto de mtricas de tamao y complejidad
estructural propuestas para Modelos Navegacionales.
1. Introduccin
Fenton, define a la medicin como el proceso por el cul se asignan nmeros o smbolos a atributos de
entidades del mundo real [1]. De esta manera, se disminuye cierto grado de subjetividad en un proceso de
medicin, mediante la utilizacin de mtricas. Sin embargo, no slo interesa contar con una diversidad de
mtricas, sino tambin, saber si dichas mtricas son vlidas. Es decir, si miden lo que realmente debieran
medir. De esta manera, la validacin se constituye en un aspecto crucial en la medicin del software, ya que
asegura que las medidas representen con precisin los atributos del software que se pretenden cuantificar.
En la literatura se reconocen dos tipos de validacin: la interna y la externa, comnmente referidas como
terica y emprica respectivamente [2].
La validacin interna es un ejercicio terico que asegura que la mtrica tiene una caracterizacin numrica
apropiada de la propiedad que pretende medir [3], [4]. Esto es por supuesto un pre-requisito para demostrar la
utilidad de dicha mtrica (validacin emprica).
La validacin externa se lleva a cabo para demostrar con evidencia real que una mtrica es til en el
sentido de que est asociada con alguna caracterstica externa del software tal como la usabilidad, la
mantenibilidad, etc. [5].
Briand et al. afirman que una mtrica es vlida si se demuestra que dicha mtrica mide lo que propone
medir y hay una acumulacin de evidencia convincente que demuestra su utilidad [3]. Por lo tanto, ningn
tipo de validacin por si sola es suficiente, ambas deben de llevarse a cabo. Sin embargo, en este trabajo nos
centramos en la aplicacin de un marco formal, denominado DISTANCE [6] para validar tericamente un
conjunto de mtricas de tamao y de complejidad estructural para Modelos Navegacionales [7]. En [8], dichas
mtricas fueron presentadas y validadas, pero, la validacin terica no fue explicada con la profundidad que
se requiere. Por tal razn, en este artculo presentamos esta validacin, por ser importante.
Este trabajo ha sido soportado parcialmente por el proyecto CICYT con referencia TIC 2001-3530-C02-01.
La eleccin de DISTANCE se debe a que nos proporciona un marco sistemtico consistente con la teora
de la medicin, ya que utiliza el concepto de distancia y disimilaridad basado en estructuras de proximidad
[17]. Adems, este marco ha sido aplicado en la validacin terica de mtricas orientadas a objeto [9], [10].
El objetivo del presente artculo es transmitir nuestra experiencia en la aplicacin de DISTANCE

resaltando sus desventajas en la definicin formal y validacin de mtricas de software para Modelos
Navegacionales.
El presente trabajo est organizado de la siguiente manera: En la seccin 2, presentamos brevemente las
principales aproximaciones propuestas para la validacin terica de mtricas. En la seccin 3, presentamos el
marco formal DISTANCE, donde se describe el modelo de proceso de construccin de medidas basadas en la
distancia. En la seccin 4, se explica brevemente las primitivas bsicas del Modelo Navegacional OOWS.
Posteriormente, se presenta el conjunto de mtricas que fueron validadas tericamente con dicho marco
formal y se describe las desventajas encontradas en DISTANCE. Finalmente en la seccin 6, presentamos las
conclusiones obtenidas y trabajos futuros a desarrollar.
2. Aproximaciones Propuestas para la Validacin Terica

Actualmente las diversas aproximaciones sobre validacin terica en la medicin del software se han ido
orientando bsicamente en dos direcciones: Aproximaciones basadas en la teora de la medicin y
aproximaciones basadas en propiedades. La presente seccin est centrada en presentar brevemente el estado
actual de dichas aproximaciones.
2.1. Basadas en la Teora de la Medicin
El objetivo es verificar si una mtrica ha sido construida siguiendo los principios de la teora de la
medicin. El fundamento de esta teora consiste en que toda medicin debe asegurar una adecuada
representacin del atributo real medido mediante smbolos o nmeros asignados [4] [11]. Consecuentemente,
esta aproximacin tiene tres componentes principales: una estructura relacional emprica, una estructura
relacional numrica y un mapeo de la estructura emprica a la estructura numrica. En cuanto a los
principios de la teora de la medicin, se puede encontrar en [11], [12].
Teniendo en cuenta esta aproximacin, la medicin del software resulta ms compleja pero ms precisa ya
que tiene una base formal en un conjunto de axiomas debidamente consensuado que define el concepto de
distancia. Su objetivo es obtener la escala a la que pertenece una mtrica, y por lo tanto sus transformaciones
admisibles. Los marcos formales ms conocidos dentro de este tipo son: Whitmire [4], Poels y Dedene [6] y
Zuse [13].
2.2. Basadas en Propiedades
La medicin con esta aproximacin resulta menos compleja que las basadas en la teora de la medicin.
Suministran condiciones necesarias para definir conceptos como: tamao, longitud, complejidad, cohesin,
acoplamiento del sistema, etc. Los marcos formales ms conocidos dentro de este tipo son: Briand et al. [15],
Weyuker [16]. Siendo el trabajo de mayor aceptacin de esta categora, Briand et al., quien justifica su
aproximacin axiomtica para identificar y clarificar las propiedades esenciales de los conceptos que son
frecuentes en la ingeniera del software. Sin embargo para Kitchenham [14], no est claro que los beneficios
superen los riesgos de su utilizacin.
3. DISTANCE: Un Marco Formal para la Construccin de Medidas de Software

El marco DISTANCE de Poels y Dedene [6], [9] proporciona procedimientos constructivos para modelar
los atributos de inters del software y definir las correspondientes medidas. Este se basa en los conceptos de
distancia y disimilitud. Los atributos del software son modelados como distancias conceptuales entre las
entidades del software que caracterizan y otras entidades del software que sirven como puntos de referencia.
Estas distancias son medidas mediante funciones matemticas que satisfacen el conjunto de axiomas del
espacio de las mtricas.
3.1. Dimensiones y Elementos del Marco
El concepto de distancia es el concepto clave de este marco. Sin embargo, este marco usa el concepto de
disimilitud que ha sido formalmente definido en la teora de la medicin a travs de las estructuras de
proximidad [17]. Adems, el concepto de funcin de distancia sobre un conjunto se define a travs de
axiomas necesarios y suficientes (no-negatividad, identidad, simetra, desigualdad triangular). Esta funcin de
distancia tambin se la denomina mtrica.
3.2. Modelo de Proceso
El proceso de construccin de medidas basadas en la distancia consiste en cinco pasos. Dicho proceso se
inicia por la solicitud de una peticin para encontrar o construir una funcin de medicin para un atributo de
software attr. que caracteriza las entidades de software en un conjunto P. Para esto, primero se debe encontrar
una abstraccin de la medicin para las entidades de software. Las entidades de software de inters deben ser
modeladas de manera tal que enfaticen el atributo en cuestin. Esto significa que el modelo deber permitir
observar hasta que punto una entidad de software es caracterizada por el atributo. El resultado del primer paso
es un conjunto de entidades de software M que puede ser usado como abstracciones de medicin o modelos
de las entidades de software del conjunto P para el atributo de inters attr. Adems se debe definir una
funcin de abstraccin abs: P M que describa formalmente las reglas del mapeo.
Si el primer paso tiene xito, podrn ejecutarse en paralelo dos caminos de actividades. Por un lado, definir
el conjunto M como un espacio de mtrica. Para esto, se modela las distancias entre los elementos de M como
secuencias de transformaciones elementales (Te). Tales secuencias representan una serie de cambios atmicos
aplicados a un elemento de M, para llegar a otro elemento de M. El nmero de cambios atmicos necesarios
para transformar un elemento en otro determina la distancia entre estos elementos. La salida formal de este
paso es un conjunto de tipos de transformaciones elementales sobre M, que deben usarse para construir las
secuencias. A continuacin se define una mtrica: M M para cuantificar la distancia entre los
elementos de M.
Por otro lado, se necesita determinar como se ve el modelo de la entidad de software en P. En el caso de
que la entidad fuera caracterizada por el menor valor terico de attr. Entonces, este hipottico modelo nulo
o modelo de referencia puede ser utilizado como punto de referencia o norma para la medicin. El resultado
de este paso es la definicin de una funcin ref: P M que devuelve para cada entidad de software en P una
abstraccin de referencia para attr en M.
Despus de haber ejecutado los dos caminos de actividades, existe un paso final en el proceso de medicin
basado en la distancia. Este ltimo paso es el que expresa la idea bsica de esta aproximacin. El atributo de
software attr se define y se mide como una distancia especfica dentro del espacio de mtrica M. El punto
hasta el cual attr caracteriza una entidad de software p P se define mediante la distancia entre el modelo
actual de p para el atributo attr (i.e., abs(p)) y el modelo de referencia para attr (i.e., ref(p)). Cuanto mayor sea
la distancia, ms difiere la abstraccin de la medicin real del modelo de referencia que se ha establecido y
as es mayor el grado con que attr caracteriza p. Por eso, el valor de attr para p es el valor obtenido a travs
de la mtrica para el par (abs(p), ref(p)). La salida formal del ltimo paso es la medida : P definida
tal que p P: (p) = (abs(p), ref(p)). De esta manera, culmina el proceso del Modelo de DISTANCE.
4. OOWS: Mtodo De Produccin De Soluciones Web Orientadas A Objeto
OOWS es un mtodo para el desarrollo e implementacin de aplicaciones para entornos Web. Fue
concebido como una extensin de OO-Method, mtodo ideado para la produccin automtica de sistemas de
software orientado a objetos. Bsicamente, OOWS concibe el proceso de desarrollo de sistemas web a travs
de tres pasos:
Elicitacin de requisitos funcionales: basado en casos de uso y escenarios para la construccin de los
esquemas conceptuales.
Modelado Conceptual Clsico: Se basa en una estructura funcional y dinmica, donde la estructura y el
comportamiento del sistema son capturados.
Modelado navegacional y de presentacin: Un modelo de navegacin que describe los requisitos
navegacionales del sistema utilizando vistas parciales del Modelo de Objetos relacionadas entre s a travs de
enlaces de navegacin. Un modelo de presentacin que comprende de un conjunto de patrones de
presentacin.
A continuacin explicaremos las primitivas bsicas del modelo de navegacin por ser de mayor inters
para el presente trabajo.
4.1. Modelo de Navegacin
En OOWS, el Modelo de Navegacin est compuesto por un conjunto de mapas de navegacin, uno por
cada tipo de usuario o actor del sistema. Un mapa de navegacin describe todas las alternativas de
navegacin que ofrece el sistema a un actor. Como se presenta en la figura 1, el modelo de navegacin
comprende de un conjunto de contextos navegacionales, cada contexto es una unidad abstracta de interaccin
del usuario con el sistema y estn compuestos por un conjunto de clases de navegacionales etiquetadas por el
estereotipo <<vista>> puesto que representan vistas sobre las clases del modelo de objetos. Estas vistas
muestran un conjunto de atributos y servicios de las clases que son relevantes en un contexto dado. Estos
contextos son etiquetados por el estereotipo <<context>> y pueden ser de dos tipos: contextos
navegacionales de exploracin, que deben ser alcanzables en cualquier momento independientemente del
contexto actual. Y los contextos navegacionales de secuencia que slo pueden ser visitados siguiendo una
secuencia predefinida de enlaces de navegacin. Las clases navegacionales son conectadas usando dos tipos
de relacin: Una relacin de contexto que es una relacin binaria unidireccional que puede ser definida
sobre una relacin de agregacin o de herencia existente entre dos clases navegacionales e indica navegacin
entre el contexto actual y el contexto destino. Una relacin de dependencia de contexto, es utilizada para
complementar la informacin de una clase navegacional con otra clase requerida en el actual contexto. Sin
embargo, no implica un enlace entre contextos, es decir, no define una navegacin.
Para una informacin mas detallada acerca de las primitivas de OOWS pueden ser encontrados en [18]
Administrador <<Contex t>>

Sesiones
E E E E E E <<Vista>> <<Vista>>
E
<<Context>> <<Context>> <<Context>> <<Context>> <<Context>> <<Context>> <<Context>>
Obras Sesiones
Internautas Obras Abonos Horarios Administradores TiposEntradas Espectadores
Titulo Fecha L/E
Crear()
Dest ruir()
E
E E E E
<<Context>>
Modificar()
<<Context>> <<Context>> <<Context>> <<Context>>
Companyias Artistas Sesiones Cestas Configuraciones
S S
<<Context>> <<Context>>
Ventas Butacas
Figura 1 : Modelo Navegacional
A continuacin se presenta este marco para intentar validar tericamente un conjunto de mtricas.
5. Aplicacin del Marco DISTANCE

En [7], se propuso un conjunto de mtricas de tamao y complejidad estructural para Modelos
Navegacionales OOWS [18]. Estos modelos conceptuales son productos intermedios del mtodo de desarrollo
web, denominado OOWS y son usados para modelar la estructura navegacional y el contenido de las
aplicaciones web. En la validacin de dichas mtricas nosotros aplicamos DISTANCE. En la Tabla 1, se
observa que no fue posible validar todas las mtricas. Las razones se explicarn a lo largo de la presente
seccin.
Tabla 1. Mtricas para Mapas Navegacionales y Contextos Navegacionales

Mtricas para mapas Validacin Mtricas para contextos Validacin
navegacionales navegacionales
Nmero de Contextos SI Fan-IN de un Contexto SI
Navegacionales (NCN) Navegacional (FICN)
Nmero de Enlaces SI Fan-Out de un contexto SI
Navegacionales (NEN) Navegacional (FOCN)
Densidad de un Mapa NO Nmero de clases SI
Navegacional (DMN) Navegacionales(NCLN)
Profundidad del Mapa SI Nmero de Atributos de SI
Navegacional (PMN) Clases Navegacionales
(NACN)
Amplitud del Mapa SI Nmero de Mtodos de SI
Navegacional. (AMN) Clases Navegacionales
(NMCN)
Camino ms corto entre SI
Contextos
Navegacionales (CCN)
Compactness (Cp) NO
5.1. Definiciones Previas
Los constructores bsicos de un mapa navegacional son los contextos y enlaces navegacionales. A
continuacin, definiremos formalmente los principales conceptos que sern usados en la validacin terica de
las mtricas mostradas en la Tabla 1. Un Mapa Navegacional es definido sobre la base de la teora de grafos.
Definicin 1. Universo de Mapas Navegacionales
UNMap es Universo de Mapas Navegacionales. Es decir, es el conjunto de todos los mapas navegacionales
sintcticamente correctos que pueden ser definidos en los modelos navegacionales de OOWS de acuerdo al
dominio de aplicacin.
Definicin 2. Universo de Contextos Navegacionales
UCoN es el Universo de Contextos Navegacionales. Es decir, es el conjunto de todos los contextos
navegacionales sintcticamente correctos que pueden ser definidos en los modelos navegacionales de OOWS
de acuerdo al dominio de aplicacin.
Definicin 3. Universo de Enlaces Navegacionales
UEN es el Universo de Enlaces Navegacionales. Es decir, es el conjunto de todos los enlaces navegacionales
sintcticamente correctos que pueden ser definidos en los modelos navegacionales de OOWS de acuerdo al
dominio de aplicacin.
Definicin 4. Mapa Navegacional

Un Mapa Navegacional (NMap), es un grafo dirigido que consta de un conjunto de contextos navegacionales
(C), los cuales estn conectados por un conjunto de enlaces navegacionales (E). Un enlace navegacional est
formado por un par de contextos navegacionales ordenados..
NMap = C , E donde : E = {(CoN , CoN ' ),...(CoN ' ' , CoN ' ' ' ) / CoN UCoN } (1)
C = {CoN ,..., CoN n } if C = E = NMap es vaco
En un mapa navegacional, nosotros podemos distinguir los siguientes niveles de contextos definidos como
subconjuntos de contextos navegacionales de NMap.
Definicin 5. Nivel Raz

Es el conjunto formado por un solo contexto navegacional. Es el nodo raz de NMap.
Raiz( NMap) = {CoN NMap / Nivel0 ( NMap) = Raiz( NMap) Nivel0 ( NMap) = 1} (2)
Definicin 6. Nivel de Contextos Exploracin

Es el conjunto formado por contextos navegacionales que son hijos del contexto navegacional raz. Se ubican
en el primer nivel del Mapa Navegacional.
Nivel1 ( NMap) = {CoN NMap/ CoN' Raiz( NMap) : CoN Hijo(CoN' )} (3)
Definicin 7. Nivel de Contextos Secuenciales

Es el conjunto de contextos navegacionales que son hijos de contextos navegacionales en el i-1 simo nivel de
contextos.
Niveli ( NMap ) = {CoN NMap / CoN ' Niveli 1 ( NMap ) : CoN Hijo(CoN ' ) para i {2,..., n}} (4)
Definicin 8. Camino
Es el conjunto de enlaces navegacionales adyacentes entre dos contextos navegacionales.
Cm1,mk = {(m1,m2)(m2,m3),,(mk-1,mk) / mk NMap} (5)
5.2. Aplicacin del Proceso de Construccin
Una vez definido algunos conceptos necesarios para facilitar el entendimiento del proceso de construccin
de la medida basada en la distancia; en esta sub-seccin, utilizando las definiciones del punto anterior,
seguiremos cada uno de los pasos explicados brevemente en la seccin 3. Para esto, ejemplificaremos dicho
proceso con la mtrica PMN, Profundidad del Mapa Navegacional.
Paso 1: Encontrar una abstraccin de la medicin

El fundamento de este paso es encontrar una abstraccin de la medicin para las entidades de software. En
nuestro caso el conjunto de entidades de software P es el universo de mapas navegacionales, UNMap, y p es
un mapa navegacional (p UNMap). Como el atributo de inters, attr es la profundidad de un mapa
navegacional. nuestro conjunto de entidades de software que enfatiza este atributo (M) sera el conjunto de los
nmeros naturales, N, que representa el mximo nivel de todo el mapa navegacional. Entonces, p puede ser
mapeado en otro elemento de M, abs(p) M, resultando la siguiente funcin de abstraccin:
absPMN: UNMap Nat: NMap max[i Niveli (NMap)] (6)
Paso 2: Modelar distancias entre las abstracciones de la medicin

En este paso, el objetivo principal es modelar las distancias entre los elementos del conjunto M. Para ello,
se debe encontrar un conjunto de tipos de transformacin elemental (Te) que sea constructivamente completo
e inversamente constructivamente completo para el conjunto de abstracciones definidas en el paso anterior. Es
decir, que un elemento de M puede ser alcanzado por una secuencia finita de modificaciones de otro elemento
tambin de M. En nuestro caso, como M es el conjunto de nmero naturales, Te contiene slo dos tipos de
transformacin elemental, pues, con sumar o restar una unidad recorremos todos los nmeros naturales.
Por lo tanto, tenemos:

t0-PMN: Nat Nat: i i + 1
(7)
t1-PMN: Nat Nat: s i - 1
Paso 3: Cuantificar las distancias entre las abstracciones de la medicin

En este paso cuantificamos las distancias que fueron definidas en M a travs de las transformaciones
elementales (Te). La funcin que cuantifica esas distancias se denomina mtrica, el cual retorna siempre un
nmero real positivo. Siendo definida por la diferencia absoluta.
PMN: Nat Nat : (i,j) i j (8)
Paso 4: Encontrar una abstraccin de referencia

En este paso, se necesita determinar como se vera el atributo attr en P. Si el Mapa Navegacional es
caracterizado por el valor terico ms bajo, obteniendo de esta manera una abstraccin de referencia para attr
en M. En nuestro caso, el punto de referencia es 0. Pues un contexto raz tiene profundidad 0 por estar
ubicado en el primer nivel.
refPMN: UNMap Nat: NMap 0 (9)
Paso 5: Definir la medida de software

Formalmente, la medida del atributo de software definido est dada por la distancia entre abs(NMap) y
ref(NMap).
PMN: UNMap : NMap max[i de Niveli (NMap) (10)
Como:
ref(NMap)= 0
y abs(NMap)= max[i de Niveli (NMap). Mximo nivel del mapa navegacional.
Entonces la distancia entre abs(NMap) y ref(NMap) es :
(NMap)=(abs(NMap),ref(NMap))
= max[i de Niveli (NMap) - 0
= max[i de Niveli (NMap)
Por lo tanto, la mtrica PMN es formalmente construida para el atributo: profundidad del mapa
navegacional.
En la Tabla 2, se presenta las funciones de abstraccin para las mtricas que fueron posibles validar
referentes a los mapas navegacionales. Y en la tabla 3, las funciones de abstraccin para las mtricas
referentes a los contextos navegacionales. Las funciones de referencia, no se presentan por considerarlas
triviales, dado que consiste en definir un valor terico mnimo y esto es determinado por el conjunto vaco o
por el nmero natural 0, segn sea el caso.
Todas estas mtricas fueron validadas en una escala ratio. No obstante, las mtricas DMN y Cp, no
pudieron ser validadas por ser mtricas indirectas (que se obtienen a partir de otras mtricas directas) y por
este motivo no fueron soportadas por DISTANCE. Las razones sern mencionadas en el siguiente punto.
Tabla 2. Funciones de Abstraccin para el conjunto de mtricas para un mapa navegacional.
Mtricas Funciones de Abstraccin

Nmero de Contextos absNCN: UNMap (UCoN): NMap SCoN(NMap)
Navegacionales (NCN) Donde:
SCoN(NMap) es el conjunto de contextos navegacionales dentro
de una Mapa Navegacional. SCoN UCoN
Nmero de Enlaces absNEN: UNMap (UEN): NMap SEN(NMap)

Navegacionales (NEN) Donde:
SEN(NMap) es el conjunto de enlaces navegacionales dentro de
una Mapa Navegacional. SEN UEN
Profundidad del Mapa absPMN: UNMap Nat: NMap max[i de todo Niveli (NMap)]
Navegacional (PMN)
Amplitud del Mapa absAMN: UNMap(UCoN): NMapSCoN(Level1 (Nmap))
Navegacional. (AMN) Donde:
SCoN(Level1(Nmap)) es el conjunto de contextos navegacionales
que pertenecen al Nivel 1 del Mapa Navegacional (Vea
definicin de Contextos de Exploracin).
Camino ms corto entre absCCN: UNMapNat: NMapmin[i de todo |Cj(mi,mi+1)|]
Contextos Donde:
Navegacionales (CCN) min[i de todo |Cj(mi,mi+1)|] es el mnimo nmero de enlaces
adyacentes entre dos contextos navegacionales.
Tabla 3. Funciones de Abstraccin para el conjunto de mtricas para contextos navegacionales.
Mtricas Funciones de Abstraccin

Fan-IN de un Contexto absFICN: UEN Nat: SEN(CoNi) j (CoN, CoNi)
Navegacional (FICN) SEN(CoNi)
Donde:
SEN(CoNi) es el conjunto de enlaces navegacionales para un i-
simo Contexto Navegacional.
Fan-Out de un contexto absFOCN: UEN Nat: SEN(CoNi) j (CoNi, CoN)
Navegacional (FOCN) SEN(CoNi)
Donde:
SEN(CoNi) es el conjunto de enlaces navegacionales para un i-
simo Contexto Navegacional.
Nmero de clases absNCLN: UCoN (UClN): CoN SClN(CoN)
Navegacionales(NCLN) Donde:
SClN(CoN) es el conjunto de clases navegacionales dentro de
un Contexto Navegacional.
Nmero de Atributos de absNACN: UClN (UA): ClN SA (ClN)
Clases Navegacionales Donde:
(NACN) SA(ClN) es el conjunto de atributos dentro de una clase
navegacional.
Nmero de Mtodos de absNMCN: UClN (UM): ClN SM (ClN)
Clases Navegacionales Donde:
(NMCN) SM(ClN) es el conjunto de mtodos dentro de una clase
navegacional.
5.3. Debilidades de DISTANCE
A pesar de que DISTANCE ha sido aplicado exitosamente en mtricas orientados a objetos, tales como las
mtricas de Chidamber y Kemerer [9] y las mtricas para modelos conceptuales ER y UML [10], hasta el
momento, este marco no haba sido aplicado en entidades como los modelos navegacionales. Esto nos
permiti detectar algunas debilidades de dicho marco que mencionamos a continuacin:
No ha sido posible validar las mtricas DMN y Cp usando las estructuras de proximidad unidimensional
proporcionadas por DISTANCE ya que estas son mtricas indirectas en la escala de tipo ratio. De esta
manera, se asume que dichas mtricas tienen una validacin terica implcita puesto que las mtricas
directas que la componen (NCN y NEN en el caso de la DMN, y, NCN y CCN en el caso de la Cp) si
fueron validadas exitosamente.
La abstraccin de referencia propuesta por DISTANCE no permite representar con exactitud la semntica
de ciertas entidades de software. Una de las suposiciones de este marco es que la entidad a ser medida
debe ser caracterizada por un valor hipottico mnimo. Segn DISTANCE, el valor mnimo para un mapa
navegacional es el conjunto vaco (indicando un mapa navegacional sin ningn contexto). Sin embargo,
considerando el mtodo OOWS [18] esta representacin no es vlida ya que el constructor mnimo vlido
para un mapa navegacional sera dado por 1 contexto navegacional y 0 enlaces.
6. Conclusiones y Trabajos Futuros
En este trabajo se ha discutido el estado actual de las aproximaciones existentes para la validacin terica
de mtricas y tambin una experiencia en la utilizacin del marco DISTANCE.
Las aproximaciones basadas en propiedades son tiles para clasificar y validar mtricas de algunos
atributos del software. Sin embargo, se centra slo en atributos internos (tamao, complejidad, cohesin y
acoplamiento) mantenindolos independientes de los atributos externos del sistema. Es decir, no cubren todos
los posibles atributos que puede interesar medir y sobre los cuales existe un conocimiento considerable.
En cuanto a las aproximaciones basadas en la teora de la medicin, siguen una aproximacin ms rigurosa
y sistemtica pero no existe en la literatura todava una aproximacin que sea lo suficientemente amplia para
validar mtricas directas e indirectas en distintas escalas.
Por ello, resulta esencial avanzar en el establecimiento de propiedades formales para cada atributo as
como el estudio de otros atributos que pueden ser de inters para posibilitar en el futuro el establecimiento de
mtricas vlidas. En este sentido pretendemos estudiar y aplicar prximamente algunas estructuras
matemticas (representaciones extensivas, representaciones de proximidad espacial multidimencional, etc.)
[4], [19] con la finalidad de validar las mtricas indirectas todava pendientes.
Agradecimientos
Los autores agradecen a Geert Poels por su valiosa contribucin en la discusin y aplicacin de DISTANCE.
Referencias
[1]Fenton, N.E., Pfleeger, S.L: Software Metrics: a Rigorous and Practical Approach, 2nd Ed., PWS Publishing Company,
(1997).
[2]Kitchenham, B.: Towards a Framework for Software Measurement Validation, IEEE Transactions of Software
Engineering, Vol. 21, No. 12, (1995) 929-944.
[3]Briand, L, El-Elman, K, Morasca S.: Theoretical and Empirical Validation of Software Product Measures. ISERN
Technical Report ISERN-95-03, (1995)
[4]Whitmire, S.: Object Oriented Design Measurement. Wiley Computer Publishing. ISBN 0-471-13417-1, New York
(1997)
[5]ISO/IEC 9126/1: International Standard Information technology Software Product Quality.
[6]Poels, G., Dedene G.: Distance-based software measurement: necessary and sufficient properties for software
measures, Information and Software Technology, Vol. 42, No. 1, (2000) 35-46.
[7]Abraho S., Olsina L. and Pastor O.: Towards the Quality Evaluation of Functional Aspects of Operative WebApps
International ER'02 Workshop on Conceptual Modeling Quality, Tampere, Finland, (2002).
[8]Abraho, S., Condori N., Olsina L., Pastor, O: Defining and Validating Metrics for Navigational Models, 9th
International Software Metrics Symposium (METRICS 2003), Sydney, Australia, Septiembre 2003.
[9]Poels, G., Dedene G.: DISTANCE: A Framework for Software Measure Construction, Reserch Report 9937, Dep. of
Applied Economics, Katholieke Universiteit Leuven (1999)
[10]Genero, M: Defining and Validating Metrics for Conceptual Models, Tesis Doctoral, Departamento de Informtica,
Universidad de Castilla-La Mancha, Espaa (2001).
[11]Briand L., El Emam, K., Morasca, S.: On the Application of Measurement Theory in Software Engineering, Empirical
Software Engineering, 1, Kluwer Academic Publishers (1996) 61-88.
[12]Roberts, R.: Measurement Theory with Applications to Decisionmaking, Utility, and the Social Sciences, Addison-
Wesley (1979).
[13]Zuse, H.: A Framework for Software Measurement, Walter de Gruyter, Berlin, (1998).
[14]Kitchenham, B. A., Stell, J. G.: The Danger of Using Axioms in Software Metrics, IEEE Proc. Software Engineering,
Vol. 144, No. 5-6, (1997) 279-285.
[15]Briand L., Morasca, S., Basili, V. R.: Property-based Software Engineering Measurement, IEEE Transactions on
Software Engineering, Vol. 22, No. 1, Enero 1996, pp. 68-86.
[16]Weyuker, E. J.: Evaluating Software Complexity Measures, IEEE Transaction on Software Engineering, Vol. 14, No.
9, (1988) 1357-65.
[17]Suppes, P. Krantz D. M., et al. : Foundations of Measurement: Geometrical, Threshold, and Probabilistic
Representations, Vol. 2, Academic Press, San Diego-CA, (1989).
[18]Pastor, O., Abraho, S.M., Fons, J.J: Object-Oriented Approach to Automate Web Applications Development, 2nd Int.
Conference on Electronic Commerce and Web Technologies (EC-Web'01), Germany, LNCS 2115, Springer Verlag,
(2001)16-28.
[19]Krantz, D.H., Luce, R.D., Suppes, P. y Tversky, A.: Foundations of measurement. Vol I: Additive and polynomial
representations, Academic Press (1971).
!" # $ !% & '

( ) *+ , ),
- . / 0 1 " &/ 1'

2
, . "
,/ " 02
/1 , 2
0) 3 ) 4 5 0
, .
! "
, 02 " 2 0
0 !
/ 1, 6 / . /1 2 !
! 0 , 0
7
!0 7 ! 7 ,
,
! " # $ % !& !! !#' ( )

* + , - !& !!'
. /
! $ !#'
0 +
% - !&' 1
. , !! !2'
*
34(15 *
6 .
7
0
5
8
9 : +
6
.
;
* . *
1
: 54
. .
54 <
* .
. (
=
54 *
+
* , !! !2'
.
* 3 7 34(15
!#' . 54 34(15
2' 1 ( 3 83(19 !,' > * 3
? 8>3?9 34(15 54 . 54 6
+ * 34(15
+ 1
+ 6
7 0 7
7 ,
* ; 6 2
34(15 . *
" ; .
0 #
@ A
*
34(15 . 54
34(15 . 3(1 >3? 6 9
6 3 4 8 439 3 4
) 8)43 9 3 ) 8)53 9/ 9
34(15 ; 0 *: 3 8:309 !-'
43 )43 )53
7 !"'
54 )
54 34(15 ;
B < 7
C2 ) D =
6 0 0
) 4
63 7 2!' 1 . * ;
D . /
*
34(15 54 8
!96 9 3(1 >3?6 / 9
D 6 54
( 34(15 43 )43 )53 +
.
Modelo de Modelo de
43
Dominio Negocio
<< PIM-PIM mappings >> << PSM-PSM mappings >>
Modelo Modelo de
de Slice Casos de Uso
<< PIM-PSM mappings >>

!
Modelo Conceptual
Modelo de Slice Modelo de
de Datos
Extendido Casos de Uso Extendido
Modelo de Navegacin Modelo de

Extendido Modelo de
composicin
Servicio
de Servicios
Modelo Model
Modelo Modelo
)53
OR XML Schema Modelo Xlink

WSDL BPEL4WS
"! # !
$ 1 34(15
* + 54 )43 8
!9 1 +
. +
0 +
1 .
)43 7 .
+ . E
+
*
+ 7
+
+ 34(15 2'/
+ :30 > * DF G30 5(0
!A !$ !% 22'/ !#'
2"' )53 +
% & '
+
6 7 !0
7 ! 7 ) *
% ( )
:30 . : #
H * ;
I !-'
+
5
54 <
+ . )43 :
. 0 "
2&' H I H
I: / * / ;
. : "
/ * 6
; . E
( "
5 "
8 * ; . ; 9
8
* 9 0 2
:30
1..* Servicio de
Usuario
0..*
Servicio de Servicio
Usuario de Usuario
Compuesto Bsico
Servicio Servicio
Bsico Bsico
Funcional Estructural
$ 3 5 :
: " 8
0 9
+ 6 7 &" !
'0 7 . 6
H: ; *
I/ H: 7
+ I !-' :30
E 6 88 99 88 7 99,)
6 88 /99 88:;/99 88/;/99
" 0
"
0 " 0
, *
:30 #
% *$ ( * )
* .
)
+
1 . +
. 8 !96 7
7
- !&'
; 7
5
+ ( . #
34(15 +
+
( + .
8 9 6 0 ,:
6 ;
. . : .
. ( 0
*
7
:
: .
)
+ . /
0
7 + +
+ :30 : !!' )
88//99 88:/99
+ , "' )
+ 34(15 +
54 + +
0
5 7 )
7 ; 6
7 7 "
+
+ ; 6
- ) (E
. +
- ' 6
+ 0 .
. 0
.
- ' ) 6 0 .
+ .
0
.
- ) 6 E
+
Modelo Conceptual Modelo de

de Datos Casos de Uso
- Atributos Modelo de Casos de Uso

Extendido
- Servicios Bsicos Estructurales
- Atributos
Modelo Conceptual
de Slice
- Servicios Bsicos Funcionales
- Relaciones include y extend
Modelo Conceptual de Slice

Extendido
- Estructuras
Navegacionales
Modelo Conceptual de Navegacin

Extendido
$ % 3 ) 3 3 = +
1 . )43
+ 34(15
.
+ , "' ) (
0 A' 54 ;
)
) ; *
. H1 J 3 I:
; 0 @ #8 9
1 J 3 @ #8 9
Login
Author
Forgot Password
-LastName
-FirstName
-Address Paper
Register As New -ZIP -Authors
Author
-Town -Title
-State -SubTitle
-Country 1..* -KeyWords
1..*
Submit Paper -Phone -Abstract
-Email -File
Author -Affiliation
-Login
Edit Author Data
-Password
View Papers
$ +. / 3 : $ +.09 3 (
+ +
+ - ) 5 ;
+ 6
.
) * . <
8
9 ) /"
KK 5LL 5 -
.
8 9 .
KK@M5LL (
A8 9

8 A8 99 0
. . . /"
. 6 /
/$ 6
. .
/ / -
. /
( /"
. A8 9
. .
:30 1 * $
/"
/"
= 3 6 A8 9
<<FBS>> <<FBS>>
Register as New Forgot Password <<SBS>>
<<FBS>>
Author Show Author Data
Login
<<FBS>>
Forgot Password
<<FBS>>
<<include>> Register Paper Data
<<FBS>> <<FBS>
Register as Send Paper
New Author
<<include>> <<include>>
Author <<FBS>>
<<CS> Login
Submit Paper
Author <<include>>
<<CS>> <<SBS>>
Edit Author Data
Show Papers
<<extend>> <<extend>>
<<CS>> <<FBS>> <<SBS>>

View Papers Download File Show Paper Data
$ 2. / 3 : $ 2.0/ 3 : +
. 5 :
Login
Register Paper Data
Send Paper
$ 1( 1 5 H5 ) I
+ - '
+ 8 "9 6
+
.
0 .
. 6 /3 = /3 =
6 /3 = 3 6 .
% /3 = 6 3
0 ) B .
. . 8/3 = 6 9 7
. .
< : /
.
34(15
*
! - !& !!'
+ (
+
. + 34(15
+ + (
H I
. H I( /3 =
3 6 . /3 = /3 = 6
* /" 8 A9 .
+
<<SS>>
Show Author Data
-LastName
<<SS>>
-FirstName
<<SS>> Show Paper Data
-Address
Show Papers -Authors
-ZIP
-Town -Authors 1 1 -Title
-Title -SubTitle
-State
-Abstract -KeyWords
-Country
-Abstract
-Phone
-Email
-Affiliation
$ 33 5
+ %- ' ) +
+
"6
+ .
.
0 . .
:30 . 1
* /" 8
A $9
*
+ 8 ,9
1 * 0
6 = : <
+ 0 , +
1 J 3
<<FS>>
Register as
New Author
-LastName
<<FS>> -FirstName
Forgot -Address
Password -ZIP
-Login -Town
-State
-Country
-Phone
<<FS>>
-Email
Login
-Affiliation
-Login -Login
-Password -Password
1
<<FS>>
Register <<SS>>
Paper Data 1..* Show
-Authors Papers
1
-Title
-Authors
-SubTitle 1
<<SS>> 1 -Title
-KeyWords -Abstract
-Abstract Show Author
Data
-LastName
1
-FirstName
-Address <<SS>>
<<FS>> -ZIP Show
1
-Town Paper Data
Send Paper
-State -Authors
-Country <<FS>>
-File -Title
1 -Phone Download
-SubTitle
-Email File
-KeyWords
-Affiliation -File -Abstract
$ 43 5 + 1 J 3
+ +- ' )
+ 8 9
!!' + (
. + 0 - +
1 J 3
1
Index
1
1
<<FS>> 1
Forgot Forgot Password
<<FS>>
Password Register As New Author Register as
Login 1 New Author
1
1
<<FS>>
1 Login
Submit Paper
<<SS>>
View Paper Show Papers
1
Edit Author Data 1 1..*
<<FS>> Logout 1
Register
Paper Data
Download File
Show Paper Data
1 1 1
<<FS>> <<SS>> <<FS>> <<SS>>

Send 1 Show Author Download Show Paper
Paper Data File Data
$ 53 < + 1 J 3
2 * 06 $
* .
34(15
54 ) 6
+
+ +
: * .
54
. +
N ;. *
; 6
+
*
H I 5 .
+
34(15
54
* 34(15
:
; 54 ) *
15
34(15
* 6 (1( 8&%7J&&A$J2&&" !9
1 3 (1 45 3
7 E 874 2&&2D&#&A&D &2D&!9 : F C 8 ?D2&&"D!29
&
!' 1 ; ) 3 ) 3 ?6 6 > 1 " / <6 #8!D29

2!D#% 2&&!
2' . ) 3 O M6 6 >; 3 0 1 " 0 /! 6 7
5 B 3 8 53 P :30Q 2&&"9 > 2&&" 5 @ :51
"' 5 ) 0 7 F6 3 : = ?0 3 6 01 ">;
0 /! 3 RM 0 5 3 = 7 M
8 95 DO 0 < 5 M 2&&&
#' C6 M 1 " = 3# -1 2&&&
A' 0 ( 6JJ J B R J + 2&&"
$' @ )6 @ 3 0 > 1 " < !1 3
5 O "! S" !---
%' ? ; C ) >6 06 > 1 " 4
3 , 829 2$D"- 2&&!
,' = T F U <6 # ->" 3 !0 A! 6 :30V2&&& 0< 5 !-"- #!&D#2#

2&&&
-' 4 T B ; 7 5 15 M )6 $ < 3 !0 / A! 6
1 3 A,8,9 "#D#" 1 !--A
!&' 4 T B ; 7 U 1 U 3 6 @3 7 $ 3 !0 1 " " 3 T ) 45D-,D
!, F 4 5 F 6 6JJ D* J J!--,
!!' U < M = 3 06 7 # - B 1 "
3 1 7 :30W2&&& ? C > 2&&&
!2' U < U 1 3 . 56 1 "; = 3 CC>A #1 7
4 T D 5 B 7 84 >57&"9 5 B ( ) > F ?
> 0 8 9 2%DA& C 2&&"
!"' U T O F 56/ 0 >6 6 4 5 B O # $#D$-
5 D> 2&&"
!#' 3 . ) O M C3 6 6 /D6;< 3 : = ?0 1 " 6 "
6 (15 45 2&&! X T 8C 9 < 2&&! 0< 5D2#$A 5 O 45M< "DA#&D##!22D&
5 2&&2
!A' 3 ( O O M6 $ 1 "/ = 3 # -< / !7 @ 4
5 > 84 5> &"9 7 4 ( 2&&" 1
!$' 3 O M C3 6 7 # - 0 C") >$ 6 " 6 @ 4
: 3 0 :30 2&&! 7 8 .9 0< 5 2!,A 5 O 22AD2"-
2&&!
!%' 3 O M C3 6 3 3 0 C") >$ 6 " 6 # -
C 5 B 5 3 85 5 39 5 DO @ F F M 8 9 455<6 !$!-D
!"$$ O 5 5 32 A-D%2 2&&"
!,' >3? C 6 3 3 C 3 T * C8 9 2&&! ( < J2&&!D&%D&!
F 6 6JJBBB J 2&&"
!-' >3? C # 0 - / 0 , E,
F F 6
6JJBBB J J J J 2&&"
2&' ) ; 3) ? T (6 / >C 1 3 O 6 #$ !&
> 2&&" 2AD2,
2!' F ; 5 B @= 06 1 " > $2 G
) 1 V 4 5 O4 !#-D!AA 2&&&
22' O M 3 6 A! 7 6 = 3 H - 7 !$ > 1 4 5
145 V&# F 80 9 %D!! C 2&&#
Estimacio n y Planificacio n de Proyectos Software con Ciclo de Vida

Iterativo-Incremental y empleo de Casos de Uso
Jose Antonio Pow-Sang Portillo Ricardo Imbert Paredes

Pontificia Universidad Catolica del Peru Universidad Polite cnica de Madrid
Seccion Ing. Informa tica Facultad de Informa tica
Peru Espan a
jpow@pucp.edu.pe rimbert@fi.upm.es
Resumen
La estimacion de costos y esfuerzos sigue siendo una de las tareas ma s difciles en la gestion de un
proyecto de software. Esta actividad es realizada por el jefe de proyecto, quien es responsable de hacer
dichas estimaciones lo ma s precisas posible. En la actualidad existen te cnicas que permiten realizar esta
labor aunque, lamentablemente, aun no hay te cnicas maduras especficas para enfoques de desarrollo como
la orientacion a objetos o los sistemas expertos. A ello se suma el problema de la escasa informacion
proporcionada por las te cnicas de estimacion existentes para su aplicacion a ciclos de vida de desarrollo de
software diferentes al de cascada, como, por ejemplo, los ciclos de vida iterativo-incrementales o en espiral.
El presente artculo presenta una propuesta para estimar y planificar proyectos software cuyo ciclo de
vida sea el iterativo-incremental. Dichas actividades se realizara n a partir de la especificacion de los casos
de uso del sistema, la cual se ha debido realizar previamente.
1. Introduccio n
La creciente complejidad de los desarrollos software que provoco la denominada crisis del software se
ha tratado de abordar mediante el planteamiento de nuevos metodos, metodologas, tecnicas y paradigmas
para minimizar su impacto. El alcance de dichas propuestas no se limita exclusivamente a actividades
relacionadas con el desarrollo en s de los sistemas, sino que abarca tambien las actividades de gestio n de los
mismos. Una de estas actividades es la de la estimacio n de los proyectos software.
A pesar de que la estimacio n de proyectos continua siendo una tarea muy compleja, en muchas ocasiones
dejada al albur de la pericia del experto estimador , en las ultimas decadas se han desarrollado algunas tecnicas
para la estimacio n del esfuerzo de proyectos software completos, tales como Puntos de Funcio n [17] y
COCOMO II [4]. Aun as, estas tecnicas si bien se postulan como independientes de la tecnologa final de
desarrollo fueron concebidas para su aplicacio n en sistemas basados en el paradigma estructurado con un
ciclo de vida cla sico o en cascada de Royce [14], y aun es difcil emplearlas en desarrollos orientados a
objetos y ciclos de vida iterativo-incrementales, tan en boga en los ultimos an os. Incluso, parece interesante
que estas tecnicas de estimacio n exploten para sus propo sitos la informacio n proporcionada por pra cticas muy
extendidas ultimamente, como, por ejemplo, la de los casos de uso.
Teniendo en cuenta la problema tica planteada, el presente artculo propone una tecnica para estimar y
planificar las iteraciones en proyectos orientados a objetos, basada en los casos de uso de los mismos, la
tecnica de puntos de funcio n y el metodo de COCOMO II.
Este documento se ha estructurado de la siguiente manera: la seccio n 2 muestra un breve resumen de las
tecnicas de estimacio n y su relacio n con los casos de uso; la seccio n 3, plantea una propuesta para la
estimacio n y planificacio n de las iteraciones; y, finalmente, se presentan las conclusiones obtenidas de este
trabajo.
2. Las tecnicas de estimacio n y los casos de uso

Esta seccio n muestra un breve resumen de las tecnicas de puntos de funcio n y COCOMO II, y su relacio n
con los casos de uso. Adema s, se da una visio n general del trabajo que se ha encontrado con respecto al tema.
2.1 La tecnica de Puntos de Funcio n

La tecnica de Puntos de Funcio n [17] fue introducida por Albrecht [1] y su propo sito es medir el software
cualificando la funcionalidad que proporciona externamente, basa ndose en el disen o lo gico del sistema. Los
objetivos de los Puntos de Funcio n son:
Medir lo que el usuario pide y lo que el usuario recibe.
Medir independientemente de la tecnologa utilizada en la implantacio n del sistema.
Proporcionar una metrica de taman o que desoporte al ana lisis de la calidad y la productividad.
Proporcionar un medio para la estimacio n del software.
Proporcionar un factor de normalizacio n para la comparacio n de distintos software.
El ana lisis de los Puntos de Funcio n se desarrolla considerando cinco para metros basicos externos del
Sistema:
1. Entrada (EI, del ingles External Input).
2. Salida (EO, del ingles External Output).
3. Consultas (EQ, del ingles External Query).
4. Ficheros Lo gicos Internos (ILF, del ingles Internal Logic File).
5. Ficheros Lo gicos Externos (EIF, del ingles External Interface File).
Con estos para metros, se determinan los puntos de funcio n sin ajustar (PFsA). A este valor, se le aplica un
Factor de Ajuste obtenido en base a unas valoraciones subjetivas sobr e la aplicacio n y su entorno; es decir, las
caractersticas generales del sistema.
2.2 COCOMO II y los Puntos de Funcio n

COCOMO, propuesto y desarrollado por Barry Boehm [4], es uno de los modelos de estimacio n de costos
mejor documentados y utilizados. El modelo permite determinar el esfuerzo y tiempo que se requiere en un
proyecto de software a partir de una medida del taman o del mismo expresada en el numero de lneas de
co digo que se estimen generar para la creacio n del producto software.
Debido a la complejidad de los proyectos de software, el modelo original fue modificado, denomina ndose
al modelo actual COCOMO II. El nuevo modelo permite determinar el esfuerzo y tiempo de un proyecto de
software a partir de los puntos de funcio n sin ajustar, lo cual supone una gran ventaja, dado que en la mayora
de los casos es difcil determinar el numero de lneas de co digo de que constara un nuevo desarrollo, en
especial cuando se tiene poca o ninguna experiencia previa en proyectos de software. Esto hace que ambos
modelos Puntos de Funcio n y COCOMO II sean perfectamente compatibles y complementarios.
2.3 Los casos de uso y la tecnica de estimacio n de Puntos de Funcio n

Los casos de uso fueron introducidos en 1987 como una herramienta de la tecnica Objetory [15] . Su
utilizacio n en los procesos de Ingeniera de Software fue propuesta por Ivar Jacobson y publicada en su libro
Object Oriented Software Engineering [7]. Actualmente, su empleo se ha extendido aun ma s, debido a su
inclusio n en UML [10], por lo que su uso en el desarrollo de software orientado a objetos se ha vuelto
altamente recomendable, si no obligatorio.
David Longstreet, en uno de sus artculos [8], sen ala que el ana lisis de puntos de funcio n se puede aplicar
de manera sencilla con los casos de uso mejorando la calidad de los documentos de requerimientos y, a la vez,
mejorando la estimacio n del proyecto de software. El aplicar la tecnica de Puntos de Funcio n permite verificar
y validar el contenido de un documento de Especificacio n de Requisitos de Software.
Lo interesante de la aplicacio n de ambas tecnicas es que se puede actualizar el conteo de los puntos de
funcio n cada vez que los casos de uso cambien y, de esta manera, determinar el impacto que un caso de uso
especfico puede producir en la estimacio n del desarrollo de todo el proyecto.
Thomas Fetcke [5] propone una forma para utilizar la tecnica de puntos de funcio n con la metodologa
OOSE de Jacobson [7]. La relacio n que muestra se basa en los casos de uso y en el diagrama de clases de
ana lisis propuestos por dicha metodologa. En su propuesta no especifica el tipo de ciclo de vida que se debe
seguir con su tecnica, por lo que se podra inferir que se debera usar el modelo ciclo de vida en cascada.
3. Propuesta para Estimacio n y Planificacio n de Iteraciones

La propuesta para determinar la estimacio n y planificacio n del esfuerzo de un desarrollo que se apoya en
un ciclo de vida iterativo-incremental comprende dos pasos principales: en primer lugar, determinar los casos
de uso a realizar por iteracio n y, posteriormente, estimar el esfuerzo para cada iteracio n. A continuacio n se
detallan las actividades que se siguen en cada uno de los pasos mencionados.
3.1 Paso 1: determinar los casos de uso a realizar por iteracio n

El objetivo de esta tarea es determinar los casos de uso que se debera n implementar en cada iteracio n. Para
ello, se debera haber realizado previamente la especificacio n de todos los casos de uso del software a
construir y que debera n estar en el documento de especificacio n de requisitos de software (para la
especificacio n de casos de uso, se puede revisar [2][3][11] y para el documento de especificacio n de
requisitos de software, [6][13]).
Para esta actividad se propone la utilizacio n de un nuevo diagrama al que se ha denominado diagrama de
precedencias, en el cual se muestran gra ficamente las precondiciones de cada uno de los casos de uso que se
incluyen en sus respectivas especificaciones.
La idea de dicho diagrama fue tomada de Doug Rosenberg [16] quien propone la realizacio n de un
diagrama similar al propuesto, especificando las relaciones precede e invoca (invoke en ingles) para
determinar los requerimientos de usuario. La Figura 1, muestra un ejemplo de un diagrama de precedencias.
precede Caso de uso B
precede
Caso de uso A precede
Caso de uso D
Caso de uso C
Figura 1. Ejemplo de Diagrama de Precedencias
El diagrama se utilizara para saber quecaso de uso necesita de alguna funcionalidad o informacio n que es
administrada o implementada por otro caso de uso. Esto permitira conocer quecaso de uso debe programarse
antes que otro, de manera que lo necesario para que se pueda implementar un caso de uso ya ha ya sido
desarrollado en una iteracio n previa.
Siguiendo la idea del pa rrafo anterior, los casos de uso que se encuentran a la izquierda del diagrama, se
implementara n antes de los que se encuentran a la derecha; es decir, en el ejemplo propuesto en la Figura 1,
Caso de uso A se debera implementar antes que Caso de uso C.
Es importante resaltar que en este diagrama no se consideran los casos de uso incluidos y extendidos, ya
que estos se pueden considerar como parte de aquellos que les hacen referencia.
3.2 Paso 2: estimacio n del esfuerzo para cada iteracio n

La siguiente actividad, despues de determinar quecaso de uso se realizara en cada iteracio n, consiste en
determinar el esfuerzo que tomara cada iteracio n. Para ello, se propone la utilizacio n de las tecnicas de puntos
de funcio n y COCOMO II.
3.2.1 Paso 2.a: Determinar los puntos de funcio n sin ajustar

El criterio seguido, para adaptar la tecnica de puntos de funcio n para ciclos de vida iterativos-
incrementales, consiste en considerar que el resultado del ca lculo de los puntos de funcio n sin ajustar para
todo el proyecto y sin considerar iteraciones, debera ser igual a la suma de los puntos de funcio n sin ajustar
(PFsA) calculados para cada iteracio n por separado. La fo rmula 1 muestra la hipo tesis planteada.
n
PFsA _ Total = PFsA(i )
i =1
Donde:
PFsA_Total = puntos de funcio n sin ajustar de todo el proyecto, calculado sin
considerar iteraciones.
PFsA(i) = puntos de funcio n sin ajustar de la iteracio n i.
Fo rmula 1: Equivalencia de los PFsA totales versus los PFsA de las iteraciones
A continuacio n se detallan las tareas a realizar en este paso.
a) Determinar los puntos de funcio n sin ajustar para ILF/EIF por caso de uso.
Para esta tarea, inicialmente, se determinan los ficheros, sin importar si son lo gicos internos (ILF) o de
interfaz externos (EIF), que sera n utilizados por cada caso de uso y, a continuacio n, se determinan los DETs y
RETs de cada ILF y EIF. Para esto, se debera seguir los pasos que especifica la tecnica de puntos de funcio n
[17].
Posteriormente, se determinan los puntos de funcio n sin ajustar correspondientes a un fichero lo gico
interno o externo para cada caso de uso. Para ello, se utiliza la siguiente fo rmula (fo rmula 2).
n
1
PFsA _ F ( j ) = xPeso(i )
i =1 TCU (i )
Donde:
PFsA_F = punto de funcio n sin ajustar para un caso de uso j debido a los ILF/EIF.
TCU(i) = numero total de casos de uso que utiliza un ILF/ EIF i.
Peso(i)= Peso debido a la complejidad del ILF/EIF i.
i= ILF/ EIF utilizado en el caso de uso j.
j= caso de uso en cuestio n.
Fo rmula 2. Ca
lculo de PFsA debido a ILF/EIF por cada caso de uso
A continuacio n, se obtienen los puntos de funcio n sin ajustar para cada iteracio n debido a los ILFs o EIFs,
segun la fo rmula 3, que se muestra a continuacio n:
n
TPFsA(i ) = [PFsA _ F ( j )]
j =1
Donde:
i= iteracio n especfica
TPFsA(i)= total de puntos de funcio n sin ajustar para una iteracio n i.
PFsA_F(j) = punto de funcio n sin ajustar para un caso de uso j debido a ILF/EIFs.
j= caso de uso a implementar en una iteracio n i.
Fo rmula 3. Ca
lculo de PFsA por cada iteracio n
b) Determinar los puntos de funcio n sin ajustar para las transacciones de cada iteracio n
Para cada iteracio n se realiza, por cada caso de uso, lo siguiente:
Se determinan las entradas externas (EI), salidas externas (EO) o consultas externas (EQ) de cada caso
de uso, utilizando para ello las reglas de la tecnica de puntos de funcio n [17].
Se determinan los DETs, FTRs para cada EI, EO y EQ utilizando para ello las reglas especificadas en
la tecnica de puntos de funcio n.
Con los datos obtenidos anteriormente, se calculan los puntos de funcio n sin ajustar para cada EI, EO
y EQ.
Como resultado de los dos pasos anteriores se obtiene el numero de puntos de funcio n sin ajustar para cada
iteracio n.
3.2.2 Paso 2.b Determinacio n del esfuerzo utilizando COCOMO II

Para realizar este paso, en primer lugar es preciso estimar cada uno de los drivers de coste propuestos por
el metodo COCOMO II (RELY, DATA, etc), correspondientes a cada iteracio n.
A partir de estos valores y los puntos de funcio n sin ajustar correspondientes a cada iteracio n, se obtiene el
esfuerzo en meses de cada una de las iteraciones y, con este valor, se puede determinar el tiempo y personas
necesarias para acabar la iteracio n y por ende el tiempo de todo el proyecto.
Es importante resaltar que el contexto del proyecto puede cambiar al pasar de una iteraci o n a otra
(conocimiento de la plataforma de desarrollo, integracio n del equipo de desarrollo, etc), por lo que podra ser
necesario reestimar de nuevo el esfuerzo requerido para las iteraciones siguientes, revisando ficheros
(ILF/EIF) y transacciones (EI, EO y EQ) en caso de cambio de requisitos, y recalculando drivers de coste en
caso de cambios contextuales u organizacionales.
4. Conclusiones y trabajo futuro.

La mayora de las aproximaciones actuales para estimar proyectos, aun definiendose como independientes
de la tecnologa y modelos de ciclo de vida, tienen un cara cter fuertemente influido por los ciclos de vida en
cascada. A pesar de que son va lidas para otras aproximaciones, como los ciclos de vida iterativos-
incrementales, por ejemplo, en general no ofrecen ninguna gua para acometer dicha adaptacio n.
El presente trabajo muestra una propuesta para determinar el esfuerzo de proyectos software que emplean
ciclos de vida iterativos-incrementales y con casos de uso. En terminos generales, a partir de los casos de uso
identificados para cada iteracio n, se calcula la proporcio n de utilizacio n de puntos de funcio n sin ajustar por
caso de uso. A continuacio n se obtienen los puntos de funcio n sin ajustar por cada caso de uso debidos a las
transacciones (EI, EO, EQ). Por ultimo, se determinan los puntos de funcio n sin ajustar por cada iteracio n y, a
partir de ellos, y mediante la aplicacio n del metodo de COCOMO II, se obtiene el esfuerzo tambien de cada
iteracio n.
Esta tecnica propuesta ha sido usada en proyectos de software en los que participa una sola persona con
resultados esperanzadores: los desajustes entre esfuerzos estimados y esfuerzo real nunca sobrepas o el 10%.
Esto ha animado a que la propuesta haya sido aplicada en nuevos proyectos, con el fin de refinar el proceso.
En un futuro, una vez que la tecnica esteestabilizada, sera aplicada a nuevos desarrollos de caractersticas
ma s amplias, como equipos de desarrollo mas numerosos o aplicaciones mas complejas.
5. Bibliografa
[1] Albrecht, A. J. Measuring Application Development Productivity, IBM Applications Development Symposium,
Monterey, CA, USA, 1979.
[2] Bittner, K., Use Case Modeling, Addison-Wesley, USA, 2003.
[3] Bittner, K., Why Use Cases Are Not Functions, http://www.therationaledge.com, USA, 2000.
[4] Boehm, B., COCOMO II Model Definition Manual, http://sunset.usc.edu/research/COCOMOII, USA, 1999.
[5] Fetcke, T., Bran, A., Nguyen, T., Mapping the OO-Jacobson Approach into Function Point Analysis. Proceedings of
TOOLS-23 97, IEEE, USA, 1997.
[6] IEEE Computer Society, IEEE Std 830-1998, Recommended Practice for Software Requirements Specifications, The
Institute of Electrical and Electronics Engineers, USA, 1998.
[7] Jacobson, I., Object-Oriented Software Engineering. A Use Case Driven Approach, Addison-Wesley, USA, 1992.
[8] Longstreet, D.,Use Case and Function Points, http://www.softwaremetrics.com/, Longstreet Consulting Inc, USA,
2001.
[9] Ministerio de Administraciones Publicas, Me trica Version 3, http://www.map.es, Espan a, 2000.
[10] Object Management Group, OMG Unified Modeling Language, http://www.uml.org, USA, 1999.
[11] Pow-Sang, J., La Especificacion de Requisitos con Casos de Uso: Buenas y Malas Pra cticas, II Simposio
Internacional de Sistemas de Informacio n e Ing. de Software en la Sociedad del Conocimiento-SISOFT 2003,
Pontificia Universidad Cato lica del Peru, Lima-Peru, 2003.
[12] Pow-Sang, J., GESPROMET, Sistema para la Gestion de Proyectos de Software Utilizando ME TRICA Version 3.
Tesis de Ma ster en Ingeniera del Software, Universidad Politecnica de Madrid, Espan a, 2002.
[13] Rational Software, Rational Unified Process version 2001A.04.00.13 , USA, 2001.
[14] Royce, W. W., Managing the Development of Large Software Systems: Concepts and Techniques. Proceedings
WESCON, 1970.
[15] Rumbaugh, I. Jacobson, and G. Booch, Unified ModellingLanguage Reference Manual, Addison Wesley, 1997.
[16] Rosenberg, D., Scott, K., Use Case Driven Object Modeling with UML, Addison-Wesley, Massachusets, USA,
1999.
[17] The International Function Point User Group (IFPUG), Function Point Counting Practices Manual-Release 4.1,
USA, 1999.
Composicin y Coordinacin de Componentes mediante

Conectores y WebServices
M. Katrib J.L. Pastrana E. Pimentel
Facultad de Matemtica y E.T.S.I. Informtica. E.T.S.I. Informtica.
Computacin. Universidad de Mlaga Universidad de Mlaga
Universidad de la Habana pastrana@lcc.uma.es ernesto@lcc.uma.es
mkm@matcom.uh.cu
Resumen
La reutilizacin de componentes es uno de los principales objetivos que se plantean en la ingeniera del
software actual. El siguiente trabajo, que contina la lnea emprendida en trabajos anteriores, muestra cmo
una extensin de la metfora del "Diseo por Contrato" puede ser usada como herramienta simple y elegante
para la composicin, coordinacin y reutilizacin de componentes software previamente existentes. Para ello
se definen conectores en forma de contratos (precondiciones, postcondiciones e invariantes) y
comportamientos impuestos al servidor (en caso de incumplimiento de los mismos) entre componentes
mediante la extensin del interfaz del componente servidor (en el que se expresan sus caractersticas
funcionales) con los requisitos no funcionales que el componente cliente desea. Un conector ser, por tanto,
un componente, cuya implementacin es generada de forma automtica a partir de su definicin, y ser el
encargado de conectar, coordinar, sincronizar y modelar el comportamiento en caso de fallo del componente
remoto que queremos usar desde uno o varios componentes. De esta forma, el uso de estos conectores nos
permitir tener un software, basado en la composicin de componentes previos ya existentes, que sea de
calidad, tolerante a fallos y conceptualmente distribuido
A nivel de implementacin, se propone una herramienta que genera automticamente dichos conectores a
partir de descripcin funcional extendida (IDL + Contratos) con lo que separa los detalles semnticos y de
comportamiento de los de los detalles funcionales y de implementacin. Versiones anteriores de la
herramienta se basan en Java usando AspectJ y bajo el estndar CORBA de OMG y en C# usando .NET. En
este trabajo se propone tambin una herramienta que utiliza WebServices y tecnologa XML para la
implementacin de los conectores.
La posibilidad de definir uno o ms conectores diferentes para un mismo componente remoto y el hecho de
ser el cliente quin imponga el comportamiento que desea del componente remoto que acta de servidor hace
que se pueda tener ms de un comportamiento diferente de un mismo componente remoto en funcin de quin
lo use. Esto posibilita una mayor reutilizacin de componentes en lo que podramos llamar "Software
Orientado al Cliente".
1. Introduccin
Trabajos precedentes, [5, 6, 7, 8], presentan un modelo para el desarrollo de software basando en la
composicin de componentes a los que se le establece como necesaria una clara separacin entre los aspectos
computacionales de los componentes respecto a otros requisitos no funcionales que son susceptibles de
cambiar durante su ciclo de vida. Entre estos requisitos podemos citar: sincronizacin, coordinacin,
persistencia, replicacin, distribucin, tiempo real, etc.
Recordemos qu entendemos por componente y las caractersticas que debe tener un componente para
permitir el desarrollo de software mediante composicin de los mismos:
Componentes son unidades Software binarias que pueden ser insertados en un sistema y puestos a trabajar.
Se entiende por binario el que sea ejecutable por una mquina (mas o menos directamente, i.e. no
necesariamente cdigo nativo para un CPU concreto sino incluso un cdigo virtual) y no que sea el cdigo
mquina para un procesador dado o que no sea legible por un humano, para que puedan ser usadas como
unidades de desarrollo.
Siete Criterios para Componentes:

1. Pueden ser usados por otros elementos Software (Clientes).
2. Pueden ser usados por clientes sin la intervencin de sus desarrolladores.
3. Incluyen una especificacin de todas las dependencias.
4. Incluyen una precisa especificacin de la funcionalidad que ofrece.
5. Slo pueden ser usados basndose en su especificacin.
6. Es componible con otros componentes.
7. Pueden ser integrados rpida y suavemente en un sistema
Para poder expresar los requisitos no funcionales de un componente, sus interfaces deberan ser enriquecidas
con definiciones semnticas, requerimientos de sincronizacin y de comportamiento ante fallos para poder
asegurar un correcto comportamiento de los mismos, de modo que, la composicin de componentes alcance a
realizar el objetivo deseado del sistema software.
Nuestra propuesta se basa en la definicin de conectores entre componentes. Dichos conectores, no son
simples adaptadores de interfaces que slo adapten el nombre de las operaciones o el tipo de los parmetros.
Son componentes activos que permiten la definicin de requisitos va asertos, as como la definicin del
comportamiento ante el incumplimiento de los mismos. La posibilidad de definir ms de un conector (con
requisitos y comportamientos diferentes) sobre un mismo componente remoto permite una mayor
reutilizacin de un componente, ya que un mismo componente servidor puede ser usado con diferentes
comportamientos por varios componentes clientes.
Considrese el siguiente ejemplo: un componente productor y otro consumidor se sincronizan a travs de un

componente buffer acotado. La circunstancia de que el productor intente colocar un elemento sobre un buffer
lleno o que el consumidor intente extraer un elemento sobre un buffer vaco no debe considerarse un error,
sino una simple sincronizacin entre componentes. Sin embargo, supongamos que el productor, por ejemplo,
usa un buffer acotado en el proceso de produccin (adems del que ya usa para comunicarse y sincronizarse
con el consumidor) que podra ser una instancia diferente de la misma clase de componente buffer. En este
caso, si podramos considerar como un error el intentar extraer elementos sobre el buffer vaco o insertar
sobre el buffer lleno. Significa esto que el funcionamiento de ambos buffer es diferente? La respuesta es NO
(de hecho podran ser instancias diferentes de la misma clase de componente buffer). La diferencia radica en
los requisitos no funcionales y/o en el comportamiento del mismo ante el incumplimiento de los mismos, que
es precisamente lo que modela el conector.
La solucin a problemas de cambios de requisitos o de escalabilidad es simple, sencilla y conocida desde hace
aos. Al igual que cualquier producto hardware est compuesto por un conjunto de componentes
interconectados, los productos software deben seguir la misma filosofa y estar formados por un conjunto de
componentes software conectables, de manera que pueda ser sustituido un componente, si es necesario, o
cambiar la conexin o tipo de sta. Esta filosofa o arquitectura software de composicin, adems de permitir
el desarrollo de un software ms flexible y escalable, permite no hacer diferencias entre sistemas distribuidos
y no distribuidos, ya que la localizacin de los componentes no afecta a la funcionalidad del sistema (aunque
como es obvio puede afectar a la eficiencia del mismo).
En la presente propuesta, se extiende la semntica del contrato (precondiciones, postcondiciones e

invariantes) [12] de manera que pueda ser usada para garantizar la coordinacin de componentes. Esta
coordinacin se realizar a travs de las clusulas de comportamiento ante fallo que permitirn la suspensin
de la llamada hasta que se verifique la condicin, el fallo de la llamada (excepcin) o el reintento de la misma.
Todos los conectores de componentes del sistema tendrn, tambin, la posibilidad del uso de un predicado
especial timeout con un parmetro real para especificar los requerimientos temporales de cualquier
servicio. Es importante notar que, a diferencia del modelo original propuesto por Meyer [12] en el que los
asertos se verifican en el componente servidor, en este modelo, es el conector el encargado de verificar los
asertos que el cliente exige para un servicio (precondicin) o propone como invariante o postcondicin. Esto
significa que no es el componente que ofrece el servicio quin asegura el funcionamiento, sino que es el
cliente quien impone las condiciones de funcionamiento particulares para l. Es decir, es el cliente quien
decide en qu condiciones quiere que se ejecuten sus peticiones.
2. Ejemplo: Una Biblioteca Virtual.

Supongamos que se tiene una biblioteca virtual donde se pueden leer diferentes revistas o libros. Para ello
tenemos un servidor que puede ser accedido por diferentes navegadores. Dicho servidor, tambin debe ser
actualizado, modificando la informacin que l contenga. Esta aplicacin, por tanto, tendra un nmero
indeterminado de componentes (instancias reales), pero que corresponden a 3 clases de componentes:
navegadores, administradores y servidor. El interfaz (IDL) del servidor podra ser como el siguiente:
interface ServidorBiblio
{ String Consultar();
void Administrar();
void establecer_deseo_administrar(boolean deseo);
boolean esta_siendo_administrado();
boolean desea_ser_administrado();
};
Cdigo Fuente 1. Interfaz del Servidor de la Biblioteca
Veamos cmo a partir de esa interfaz, se puede disear los conectores para que puedan interaccionar con l,
tanto los navegadores como los administradores. Un navegador, podr consultar siempre que no est siendo
modificado, o se desee modificar el servidor y nunca podr administrar, mientras que el administrador
precisa exclusin mutua para modificar el servidor.
Connector ConectorNavegador define ServidorBiblio
{ String Consultar()
{ Require: (!esta_siendo_administrado()) &&
(!desea_ser_administrado())
On Failure: Suspend;
// Esperamos cuando est o desea ser administrado
};
void Administrar()
{ Require: false
On Failure: throw new ExcepcionDeAcceso();
// Servicio no habilitado para un cliente Navegador.
};
void establecer_deseo_administrar(boolean deseo)
{ Require: false
// Servicio no habilitado para un cliente Navegador.
};
boolean esta_siendo_administrado()
{ /* No requiere Precondicin. Es equivalente a Require: true
Hemos colocado toda la interfaz para que se tenga una
visin completa de los servicios ofrecidos por el
componente, pero para aquellos servicios que no se vaya
a expresar ningn aserto, no es necesario incluirlos en
el conector.*/
};
boolean desea_ser_administrado()
{ // No requiere Precondicin. Es equivalente a Require: true
};
};
Cdigo Fuente 2. Conector para el Navegador del Servidor WWW
Connector ConectorAdministrador define ServidorBiblio

{ String Consultar()
{ Require: false // Servicio no habilitado
};
void Administrar()
{ Require: Available() //Requiere exclusin mutua.
};
void establecer_deseo_administrar(boolean deseo)
{ }; / No requiere Precondicin.
boolean esta_siendo_administrado()
boolean desea_ser_administrado()
};
Cdigo Fuente 3. Conector para el Administrador del Servidor WWW
Ntese que el diseo del conector est siendo utilizado tambin para expresar de forma explcita la
prohibicin de un determinado tipo de clientes para usar determinado tipo de servicios del servidor. En el
ejemplo anterior, al imponer como precondicin false la llamada al servicio de administrar para el caso de
los navegadores, se est especificando que dicho cliente no podr nunca satisfacer esa precondicin y
siempre ser elevada la excepcin de "falta de privilegio". Una vez ya definidos los conectores, cualquier
usuario o en cualquier componente, podra usarlos para acceder a nuestro servidor.
3. Desarrollo de Conectores Avanzados.

Un conector es tambin un componente, por tanto, cabe plantearse el uso de tcnicas tradicionales de
desarrollo y mejora de componentes a travs de tcnicas como la herencia, composicin y delegacin en el
desarrollo de nuevos conectores.
3.1 Herencia
La herencia se usa en el mbito de la programacin orientada a objetos y componentes para:
Concretizacin: Reemplazo de mtodos abstractos por mtodos concretos.
Extensin: Aadir nuevos mtodos.
Refinamiento: Escribir mtodos que ofrecen un mejor servicio que sus predecesores.
Parece adecuado que se pueda utilizar la herencia a la hora de mejorar o definir nuevos conectores. Por
ejemplo, supongamos que se tiene un componente buffer acotado con la siguiente interfaz:
interface Buffer
{ bool isEmpty();
bool isFull();
int get();
void put(in int x);
};
Cdigo Fuente 4. Interfaz del Buffer Acotado
A partir de esa interfaz podramos haber desarrollado un conector para usar dicho componente en una
aplicacin secuencial en la que sera errneo extraer informacin del buffer vaco o insertarla en un buffer
lleno. Definiendo un conector como el que se muestra a continuacin:
Connector BufferConnector define Buffer

{ int get()
{ Require: !isEmpty();
On Failure: Fail;
};
void put(in int x)

{ Require: !isFull();
On Failure: Fail;
};
};
Cdigo Fuente 5. Conector del Buffer Acotado
Supongamos que queremos usar el mismo buffer para sincronizar una aplicacin en la que un componente
productor y otro consumidor trabajan concurrentemente. En vez de definir un conector completamente nuevo,
podemos refinar el conector anterior usando la herencia:
Connector ConsumerBufferConnector extend BufferConnector
{ int get()
{ Require: !isEmpty();
};
};
Cdigo Fuente 6. Conector del Buffer del Consumidor
Connector ProducerBufferConnector extend BufferConnector

{ void put(in int x)
{ Require: !isFull();
};
};
Cdigo Fuente 7. Conector del Buffer del Productor
La herencia puede redefinir comportamientos o aadir comportamientos nuevos para un mismo componente
remoto de manera esttica. Se puede representar como una relacin "es un/a", por ejemplo, un
ConsumerBufferConnector es un BufferConnector. Los contratos y comportamiento de un
conector "hijo" sustituyen a los del padre salvo que no sean redefinidos.
3.2 Delegacin
La delegacin es una relacin entre componentes donde uno delega en otros los servicios que ste no es
capaz de resolver. Este mecanismo se convierte en una herramienta muy til y flexible cuando es posible
modificar en tiempo de ejecucin el componente en el cul se delega. La siguiente sentencia predefinida
permitir a un conector modificar en tiempo de ejecucin el conector en el cul delega: void
DelegateOn(string connector_name) (donde connector_name debe ser el nombre simblico
con el que el conector est registrado en el servicio de nombres del sistema) . Siguiendo con el ejemplo
anterior, el uso de la delegacin podra incrementar la tolerancia ante fallos de nuestro conector, pudiendo,
por ejemplo, cambiar el conector en que delega en caso de que el tiempo de respuesta de una llamada supere
una cota establecida. En el ejemplo anterior:
Connector FT_BufferConnector define Buffer

{ int get()
{ Require: timeout(10.0)
On Failure: DelegateOn(second_connector_name);
retry;
}
void put(in int x)
{ Require: timeout(10.0)
On Failure: DelegateOn(second_connector_name);
retry;
};
};
Cdigo Fuente 8. Conector Tolerante a Fallos va Delegacin
El uso de la delegacin permite la modificacin del conector a travs del cual accedemos a los servicios
ofrecidos por un componente remoto en tiempo de ejecucin, lo que nos permite cambiar de comportamiento
(si el nuevo conector tiene un comportamiento diferente) y/o cambiar de componente servidor (si el nuevo
conector est enlazado a un componente distinto).En este caso, el sistema puede incluir mecanismos de
tolerancia a fallos basados en buscar nuevos conectores en caso de que algn componente no responda o que
los resultados que nos ofrezca no sean de nuestro agrado. La delegacin, por tanto, puede verse como una
relacin del tipo tiene un/a por lo que un FT_BufferConnector tiene un Buffer.
3.3 Composicin.
La composicin de conectores es su aplicacin encadenada uno tras otro. Por tanto, se comportarn como
filtros. Esto puede ser til cuando se desea endurecer las restricciones de precondicin para un servicio, ya
que deber satisfacer todas las precondiciones (conjuncin de precondiciones). Adems, se ejecutarn todas
las sentencias On Failure correspondientes a todos los conectores cuyas precondiciones no hayan sido
satisfechas. Por ejemplo, basndonos en el ejemplo anterior del buffer, podemos generar un conector que
requiera exclusin mutua para el acceso al buffer.
Connector MutualExclusionBufferConnector before BufferConnector

{
bool isEmpty()
{ Require: Available();
}
bool isFull()
}
int get()
}
void put(in int x)

};
};
Cdigo Fuente 9. Conector Buffer con Exclusin Mutua.
Por tanto, la composicin es til cuando se desea aadir un comportamiento a un conector que no lo tiene
definido para ese servicio y se desea hacerlo ms estricto sin necesidad de parar la ejecucin del componente
remoto. Por ejemplo, en este caso, bastara con generar el nuevo conector que va antes del que estamos
usando y luego, o bien simplemente usar una sentencia de DelegateOn para cambiar dinmicamente el
conector a travs del que accedemos a los servicios, o bien, solamente parar el cliente para modificar en
nuestro cdigo el conector a usar. La composicin es una relacin de agregacin, es decir en nuestro ejemplo
tendremos un MutualExclusionBufferConnector ms un BufferConnector.
4. Implementacin de Conectores.
Hemos desarrollado una herramienta (de la que actualmente tenemos dos posibles implementaciones: una en
Java usando AspectJ y bajo el estndar CORBA de OMG y otra en C# usando .NET), que separa los detalles
semnticos y de comportamiento tanto de los de los detalles funcionales como de implementacin y cuyos
detalles de implementacin han sido comentados en los trabajos previos.
La ltima versin de nuestra herramienta (que est en fase de pruebas) utiliza servicios web y tecnologa
XML para el desarrollo de los conectores con el fin de obtener una mayor heterogeneidad en los usuarios de
la herramienta y estandarizacin en los protocolos de comunicacin. Los trabajos [9, 18] encaminados a la
inclusin de asertos y aspectos en .NET pueden ser una herramienta muy til y elegante a la hora de la
implementacin de los conectores, de forma que se pueda generar ms cdigo reflexivo y menos traduccin
fuente a fuente.
4.1 Estudio del uso de WebServices en la implementacin de Conectores.

Al igual que en las implementaciones anteriores con CORBA o TCP.NET, partimos de la idea de conectar,
coordinar y sincronizar un nmero, a priori, indeterminado de componentes ACTIVOS, es decir, no son
DLLs sino procesos que estn ejecutndose en una mquina virtualmente remota. El esquema de
comunicacin sera el siguiente:
Figura 1. Esquema de Comunicacin Usando Corba TCP.NET
Qu posibilidades habra de usar la tecnologa XML y los servicios Web para el desarrollo de los
conectores?
a.) Usar WebServices para interconectar los diferentes componentes activos (en la figura 1 donde pone
CORBA). Tiene la ventaja de que estandariza la comunicacin, pero bsicamente lo que se hace es
usar WebServices como middleware de comunicacin.
b.) Implementar el conector mediante un WebService en el que el componente servidor es un

componente local al WebService. Si bien la sensacin es buena y parece que todo funciona bien y
sencillo, tiene el problema de que perdemos uno de los objetivos o ideas iniciales, ya que de esta
forma el conector va pegado al servidor y ya no es el cliente el que impone los requerimientos y
comportamientos.
c.) Implementar el conector mediante un WebService en el que tenemos una referencia a un componente
remoto. A diferencia del apartado a el servicio Web no slo se encarga de la comunicacin, sino
tambin, de la evaluacin de contratos, ejecucin de sentencias en caso de fallo y planificacin de
peticiones en caso de que haya sentencias Suspend. Con esta opcin, al tener una implementacin
basada en XML y WS con lo que conseguimos la heterogeneidad de los clientes sin perder ninguna
caracterstica respecto al modelo anterior.
Figura 2. Esquema de Comunicacin Usando XML y WebServices
A la hora de realizar una implementacin basada en la opcin c surge un problema: Los WebServices no
tienen estado, es decir, se crean al efectuar una llamada y luego se destruyen. Cmo entonces podemos
realizar la parte de planificacin que realiza el conector? Cmo suspender a un llamante si luego no puedo
despertarlo?
Hay una solucin factible que consiste en declarar como estticos las variables que conforman el estado del
conector: enlace al servidor, lista de peticiones suspendidas, lista de precondiciones, lista de parmetros de
dichas precondiciones, nmero de peticiones suspendidas, etc. Sin embargo, seguimos estudiando otras
posibles soluciones ms elegantes.
5. Trabajos Relacionados
El presente trabajo presenta una propuesta para el desarrollo de software orientado a componentes a partir de
componentes ya existentes, as como su coordinacin y sincronizacin. Veamos algunos trabajos
relacionados.
Existen propuestas como iContract [10] o jContract [14] que incorporan el modelo de contrato para el lenguaje
Java. Sin embargo, son propuestas basadas en objetos y no en componentes y para diseo de aplicaciones
secuenciales, por lo que no son aplicables en el contexto de componentes distribuidos.
Otros trabajos como [5, 6, 7, 8] incorporan el concepto de contrato como herramienta de sincronizacin para
hebras y objetos separate.
Quiz los trabajos, a priori, ms relacionados seran los relacionados con la programacin orientada a aspectos
(POA). Sin embargo, nuestra propuesta se basa en definir aspectos no funcionales sobre componentes remotos
sobre los cuales no podemos tejer aspectos. Por otra parte, mediante el uso de la POA sera complicado el
poder tener diferentes comportamientos para una misma llamada y un mismo componente remoto (cosa que
es factible y sencilla, bastara con tener 2 conectores diferentes para un mismo componente), en lo que hemos
llamado Software orientado al Cliente.
En esta lnea, AspectIX [4], por ejemplo, pretende ser un middleware, una extensin de CORBA, que permita
tejer aspectos. Sin embargo, y a diferencia con CORBA, AspectIX adopta una arquitectura que sigue un
modelo de objetos fragmentados al estilo de INRIA, en el que un objeto distribuido consiste en un conjunto de
fragmentos que pueden interactuar y en el que el cliente de un objeto siempre tiene al menos uno de esos
fragmentos (en el caso de CORBA su Stub). AspectIX utiliza un tejedor estandar para Java y entrelaza los
aspectos con las llamadas que se realizan en los Stubs. Esto, imposibilita la definicin de comportamientos
diferentes para un mismo componente remoto (ya que el Stub es nico) y no permite el uso de aspectos no
funcionales para la sincronizacin de componentes, por ejemplo, la suspensin de una llamada si no se
verifica cierta propiedad antes de ejecutarla, ya que no habra quin la despertara.
Otra propuesta, en la misma lnea de la anterior, es la de Dinamic Wrappers propuestos en JAC (Java Aspect
Compiler) [15]. Esta propuesta, utiliza envoltorios para los mtodos, que pueden ser modificados
dinmicamente, para implementar el uso de aspectos en sistemas distribuidos. Si bien, el comportamiento
puede ser modificado dinmicamente, no se pueden tener dos comportamientos distintos al mismo tiempo y
existira el mismo problema cara a la sincronizacin que en el caso anterior.
Los primeros trabajos de Cristina Lopes [11] en el campo del lenguaje de coordinacin COOL, en el cul
existe un coordinador que se adjunta a cada objeto en tiempo de compilacin pueden parecer equivalentes a
los conectores propuestos, sin embargo, hay una gran diferencia. El coordinador de COOL est adjunto al
componente servidor y es ste y no el cliente quien impone los requisitos no funcionales, mientras que en
nuestro caso, es el cliente el que impone tanto dichos requisitos como el comportamiento ante su posible
incumplimiento.
En esta lnea, el modelo Coordinated Roles [13] mejora los trabajos de Lopes en el sentido de que es capaz de
generar, componer y cambiar los conectores en tiempo de ejecucin. Est fuertemente influenciado por las
propuestas de Aksit y parece que aporta todas las facilidades descritas en este trabajo y algunas ms (como la
posibilidad de definir patrones de coordinacin complejos entre varios objetos), sin embargo, y al igual que
muchos otros trabajos que van en esta lnea (como [1, 3]) todos ellos tiene el mismo problema: el servidor es
quin impone su ley.
Para finalizar la comparacin con trabajos similares y dado que enmarcamos nuestra implementacin en la
tecnologa de .NET y C#, debemos hacer mencin a Polyphonic C# [2].
Polyphonic C# es una extensin del lenguaje C# con un mecanismo de abstraccin de la concurrencia basado
en el clculo de uniones. Si bien el modelo se nos presenta como vlido para un sistema multihebras y para un
sistema de una orquesta de procesadores, en este caso, el sistema est orientado a eventos y no a llamadas a
servicios. Por otra parte, la unin de clculos que permiten la coordinacin como por ejemplo: public
String get() & private async contains(String s) se realiza en el servidor con lo que
volvemos a tener el mismo problema que con las propuestas anteriores: el servidor es quin impone su ley.
Sin embargo, esta idea que propone Polyphonic C# puede ser interesante cara a una nueva forma de definir
los conectores y como herramienta para su implementacin en futuras versiones.
6. Conclusiones y Trabajos Futuros.
La presente propuesta ofrece al diseador una herramienta basada en asertos (contratos) para expresar
requisitos no funcionales como la coordinacin/sincronizacin de componentes distribuidos de manera que es
el cliente quien impone el comportamiento no funcional de cada componente remoto que desea utilizar, lo que
permite una mayor flexibilidad y reutilizacin de los componentes ya existentes (por ejemplo dos clientes
pueden tener diferente comportamiento de un mismo componente remoto).
La herramienta encargada de la generacin de cdigo ha sido llamada ComponentsDxC y es capaz de generar

todo el cdigo que implementa un conector a partir de su definicin (IDL extendida). La primera versin fue
desarrollada para generar Java /CORBA, la segunda versin genera C#/ bajo dot-Net. Y actualmente se estn
generando WebServices (desarrollados en C#) para la implementacin de los conectores lo que los hace ms
independientes de los componentes que conecta.
Actualmente, ya dado que las nuevas versiones van orientadas al mundo de los servicios Web, se est
estudiando la posibilidad de modificar al sintaxis de definicin de los conectores basndonos en los lenguajes
de definicin de estos servicios y usando atributos o uniones de clculo para expresar los asertos.
Como trabajo futuro se desea la mejora de la herramienta para que sea ms amigable (actualmente es textual),
su posible combinacin con herramientas o lenguajes de composicin, as como estudiar la posibilidad del uso
de predicados de periodicidad para realizar planificaciones de tiempo real.
Referencias
[1] Aksit M., Wakita K., Bosch J., Bergmans L., Yonezawa A., Abstracting Object Interactions Using Composition
Filters, Proceedings of the Workshop on Object-Based Distributed Programming, ECOOP'93, 152--184, Lecture
Notes in Computer Science 791, 1994
[2] Benton N., Cardelli L., Fournet C., Introduction to Polyphonic C#
http://research.microsoft.com/~nick/polyphony
[3] Frolund S., Agha G., A Language Framework for Multi-Object Coordination, Proceedings of the European
Conference on Object-oriented Programming ECOOP'93, 346--360, 1993
[4] Hauck F., Becker U., Geier M., "AspectIX: A Middleware for Aspect-Oriented Programming.", Workshop on
Aspect-Oriented Programming. ECOOP'98,Bruselas (Blgica), 1998.
[5] Katrib, M. Fernndez, D. JavaA: inclusin de aserciones en Java, Revista Computacin y Sistemas,, Mxico,
1999
[6] Katrib, M. Pimentel, E. Synchronizing Java threads using assertions, Proceedings of TOOLS 31th, Editors, IEEE
Computer Society, ISBN: 0-7695-393-4. , Asia 1999
[7] Katrib, M., Pastrana J.L., Pimentel E. "Coordinacin de Objetos Separate en Java" , 4 Workshop Iberoamericano
de Ingeniera de Requisitos y Ambientes Software. IDEAS'201, San Jos (Costa Rica) 201.
[8] Katrib, M., Pastrana J.L., Pimentel E. "Conectores: Una Solucin para la Composicin y Coordinacin de
Componentes, en: 6 Workshop Iberoamericano de Ingeniera de Requisitos y Ambientes Software. IDEAS'203,
Asuncin, Paraguay (203) .
[9] Katrib, M.,Ledesma E., Including assertion attributes in .NET assemblies en .NET Developers Journal, USA,
September 2003
[10] Kramer R. iContract - The JavaTM Design by ContractTM Tool. Proceedings of Technology of Object-Oriented
Languages and Systems 26th International Conference and Exhibition. 1998
[11] Lopes, D: A Language Framework for Distributed Programming, Xerox Palo Alto Research Center, 1998
[12] Meyer, B. Construccin de Software Orientado a Objetos, Prentice Hall 1999
[13] Murillo J.M., Hernndez J., Snchez F, lvarez L.A., Coordinated Roles: Promoting Re-usability of Coordinated
Active Objects Using Event Notification Protocols, Proceedings of the COORDINATION'99 Conference, 53--68,
1999
[14] Parasoft Corporation. Using Design by Contract[TM] to Automate Java[TM] Software & Component Testing
http://www.parasoft.com/
[15] Pawlak R., Seinturier L., Duchien L., "Dynamic wrappers: handling the composition issue with JAC", TOOLS,
Santa Brbara (EEUU) 202
[18] Schult W., Polze A. Aspect-Oriented Programming with C# and .NET
An Academic Web-Based Agenda and Its Engineering Process
Renata P. M. Fortes - Andr P. Freire - Victor H. Vieira - Dbora M. B. Paiva

University of So Paulo - So Carlos-SP Brazil
{renata, apfreire, thugo, debora}@icmc.usp.br
Abstract
In order to provide an academic agenda to people about their schedule, we have developed No
Risk Planning through the Web Engineering Process. The Web Engineering steps used are
described and resulting artifacts are shown. We discuss the requirements for dealing with different
types of academic professionals and their needs. It is worth noticing that the evolution of the
software has been made by only three students in a 12 month span. Moreover, the final users
requirements have been addressed, following the evolution cycles of spiral model.
1. Introduction
The academic context encompasses a series of activities related to teaching and research. Frequently,
teachers and academic staff need to establish dates for exams, to communicate extra classes and to book
equipment such as projectors and computers. Other people involved in the academic context, mainly
students and secretaries, need to be aware of common schedules. For example, secretaries need to know
the available schedules of all teachers in a group to be able to schedule a meeting at an appropriate time.
Therefore, the importance and utility of a collaborative calendar is notable [6], mainly for supporting
the arrangement of academic and educational engagements. No Risk Planning is an electronic calendar1,
developed to facilitate the planning and scheduling of activities carried out in the academic context. It
allows arranging engagements for working groups and, alternatively, people can use No Risk Planning as
their own personal diary.
Many projects have been developed in order to offer a shared calendar or a shared agenda. WebCal
[4], Web Organizer [13] and Project Place [11] are systems in which users can add, consult, change or
remove items such as room reservations, announcements about meetings or conferences and general
appointments. In distance learning, they can be used as a public resource to support selecting important
dates. Moreover, in traditional education teachers can establish dates, students can visualize the course
schedule, the administrative sector can arrange meetings, and presentations in general can be arranged
and announced. Although many projects related to the shared calendar have been developed, we
emphasize other main motivations for the No Risk Planning project to be carried out, including: to develop
a system to satisfy educational and research calendar requirements; to offer features to help each member
of group find common available time; and to train developers in academic environment to deal with the
practitioners web development process. Related work on shared agendas has been addressed. Table 1
shows eighteen surveyed characteristics of eight important calendar projects that we have studied.
This paper is organized as follows: Section 2 introduces basic concepts about Web Engineering.
Section 3 presents the Web Engineering activities related to the No Risk Planning development process.
1
Available at http://nrp.sourceforge.net
Section 4 describes the main chara cteristics and functions of the calendar. In Section 5 we present our
concluding remarks.
Table 1. Comparison of Web-Based Calendar Systems
Publisher II
Zope Group
Office [19]
Calendar
Calendar
Calendar
Planning
Chronos
Calcium
Alltasks
No Risk
Absence
Collab
Web
Web
[14]
[15]
[16]
[17]
[18]
[20]
[21]
Software
Characteristic
Daily Calendar X X X X X X X
Weekly Calendar X X X X X X
Monthly Calendar X X X X X X X X X
Semester Calendar X X X X
Year Calendar X X X X
Personal Scheduling X X X X X X X
Group Scheduling X X X X X X X X X
Group Enable X X X
Eventual Scheduling X X X X X X X X X
Fixed Scheduling X X X
Appointment reminder X X X
Message sending/ chat X X X
Task listing X X X X
Palm Synchronization X X
Interface
X X X
Customization
File Sharing X X X
Python &
Programming Language PHP Perl P erl Perl Perl PHP Perl PHP
Zope
DBMS MySQL MySQL txt -- MySQL MySQL MySQL Optional --
2. General Aspects of Web Engineering
The applications developed to Internet have grown fast in scope and in use, affecting significantly all
aspects of our every day life [2]. Due to this fact, the processes of creation, ma nagement, maintenance and
quality control have been more complex. Web Engineering refers to the establishment and use of solid
scientific engineering, to the management principles, and a disciplined and systematic approach to
develop, make available and maintain high quality web based systems and applications. The spiral model
seems the model that fits better to Web Engineering, as it is usually used to develop projects with high
uncertainty level of its requirements and which technology nature changes constantly. Internet
applications have these characteristics. Based on this model, on each cycle, the application grows, and
has its functionalities increased, and its requirements are progressively being better identified, so that the
involved risks tend to be reduced [3].
3. Activities related to the No Risk Planning development process
Many activities and engineering tasks should be executed in order to build a reliable and usable Web-
based system. This section presents how the main stages of the No Risk Planning life cycle have been
performed. The framework proposed by Pressman has been extensively applied, supporting the
improvement of No Risk Planning process [9].
Formulation and Planni ng - In the formulation stage, the group responsible for the project should answer
a set of questions. Essentially, it is important to state the motivation for the development of the new
system, why the system is necessary and who will use it. The main motivation for the No Risk Planning
project was the relevance and utility of applications that address work in-group in educational and
research contexts. It is also important to observe that No Risk Planning calendar resulted from the
academic needs of our research group: InCA-SERVE2 project [8] has as objective offering infrastructure (in
terms of software) for building applications of ubiquitous computing in teaching and research. Frequently,
teachers and researchers need to book classrooms that hold all equipments, register appointments and
meetings of a working group and schedule lectures and presentations.
Therefore, No Risk Planning is necessary because it allows the systematically arrangement of

appointments and reservations. This is a common activity in academic context and the use of accessible
application and database can facilitate and improve working in-group. As a result, the main users of this
system are students, teachers, researchers, secretaries and everyone involved with academic issues.
Analysis - In the beginning, the detailed requirements of the No Risk Planning project were not well
defined. Therefore, a functional prototype was built with the objective of improving the requirements
analysis. We took into account the main needs of the potential users to build the prototype. There are two
main types of users for No Risk Planning : administrators and final users. Administrators are responsible
for user management. The administrator main screen offers statistical data about No Risk Planning use.
There is information related to number of institutes, departments, users and groups using the application.
Administrator is responsible for (1) managing users areas; (2) creating, changing and removing institutes
and departments; (3) defining working groups and (4) setting the system configuration.
The final user of No Risk Planning calendar is responsible for managing his agenda (adding,
changing, searching and removing appointments). The first step is the login and password authentication.
After authentication, the user can view his appointments. In the prototype, appointments can be classified
as eventual, important, common, leisure or academic. Each of them is represented with a different color.
There are also appointments of the group to which the user belongs. The acronym or the abbreviation of
the group name is presented between parentheses. On the top of the screen, the user has some options as
Personal Diary, Search, Your Data, Groups and Help, as shown in Figure 1.
Ten people, two lecturers and eight computer science students (potential users), informally evaluated
the prototype. They were asked to execute some elementary tasks and express their opinion about
implemented functionalities. During the evaluation, many suggestions were gathered that helped to
establish other No Risk Planning requirements. While the requirements analysis stage was taking place,
the types of analysis recommended by Pressman [10] were carried out in the No Risk Planning project.
The content analysis stage identified and created the necessary text, graphics, images and icons files
to compose the application. The interaction analysis stage was carried out by means of use-cases
diagram building. This type of diagram describes the system functionalities observed by external actors.
The administrator actor is re sponsible for the global system management. This includes system
configuration and users management. The calendar user actor manages his personal diary. The group
member actor is the user that is part of some working group. He can register appointments for his group,
2
InCA-SERVE is a project funded by an international cooperation program between CNPq/ProTeM -CC in Brazil and
NSF/CISE in the U.S. In Brazil, the project is also supported by FAPESP and CAPES
interact with other members by means of a chat program and share files and documents as well. The group
creator actor is responsible for managing the group, for instance, including and removing group members.
Figure 1. Main screen of the No Risk Planning prototype
The Functional analysis stage involves describing all operations and functions in details. Some
diagrams were stated: operations list, class diagram, activity diagram, collaboration diagram and state
diagram [12]. During the Configuration analysis stage, technical specifications for the No Risk Planning
project have been established: it is a system available on the Internet that can be accessed through the
World Wide Web (WWW). The programming language used is PHP, the database is MySQL and the web
server is Apache.
Engineering - The analysis stage stated operations for No Risk Planning application generating the
operations list. In the engineering stage, the simple operations were considered as modules and complex
operations were divided into modules. Afterwards, the navigation design was accomplished. It was
established the links among the modules: for each module was stated which modules it calls and which
modules call it. As a result, the navigational model was described and was visualized as a whole, giving a
general vision of the system.
Generation and Testing - In this stage, the source code was generated according to the analysis and the
engineering specifications. The prototype was partially reused: some functional modules constitute the
application resulting of the first increment of the framework proposed by Pressman. Simple unit and
integration tests were accomplished but we had not used specific techniques for this purpose.
Customer Evaluation - In this stage, another evaluation was carried out with potential users of the No Risk
Planning project. It was planned according to ISO/IEC 14598-5 International Standard recommendations
[5]. All requirements stated for the No Risk Planning project were evaluated. Besides functional
requirements, it was included the usability quality requirement focusing on the attributes identified by
Olsina et al [7]: global site understandability, online feedback and help features, and interface and
aesthetic features.
Nine people participated in the evaluation stage. They were allowed to explore the whole system and
they were asked to answer a questionnaire. The results demonstrate that users had problems with
navigability and usability. In spite of this, positive aspects of the No Risk Planning usage were observed
from the benefits of having an organized means of calendar information to exchange related academic
activities. Hence, we keep on developing and maintaining the No Risk Planning software. Other ideas
emerged from the evaluation stage and will be used as input for initial stages of the next increment of the
framework.
4. No Risk Planning: Characteristics and conveniences
As stated earlier, there are two main users for No Risk Planning: administrators and end-users. The
administrator has options such as Password, Basics Data, Help, Institutes, Departments, Accounts and
Groups. The Password option is used for the administrator to change his password. Basics Data is used
for the administrator to fill in a form with data about system configuration; for example, the institutions
name. Help describes the system. Institutes allow the administrator to create, change or delete as institute.
Departments use the same procedure of Institutes. The Accounts option allows the administrator to
manage users areas. Groups added by the administrator in the Groups option are used when users are
defining their groups.
The end-user has the following available functionalities: Personal Diary, Search, Your Data, Groups
and Help. In Personal Diary, the user has two options: add and remove an appointment. When he
chooses add new appointment, he selects the day of the week, the beginning and end times of the
appointment, and the appointment type (academic, leisure, important, common or normal).
Verifications are performed since calendar consistency is an important requirement of the No Risk
Planning project. In other words, if the user inserts an appointment which conflicts with another of the
same time, No Risk Planning removes the old one and inserts the new appointment, after user agreement.
It also checks if there are group appointments at the same time of the new appointment. They cannot be
overlapped. Only the group creator can remove a group appointment. When it is necessary to delete an
appointment, a list of all of the users personal appointments is presented. He can then choose one (or
more) of them to remove. Also, if the user wants to remove all his personal appointments, he can use the
delete all appointments option.
The Search option allows users to search for other No Risk Planning users. Information such as user
name, email, institute and department may be given. In Your Data option, users can change their personal
data; for instance, they can change their email and password. The Group option is the most important link
for working with groups. By using it, the user can create a new group. He is required to choose the name,
the acronym, the color to represent appointments of the new group, the category (for example,
undergraduate research), the number of members and a brief description of the new group. In the next
stage the user chooses the members that will participate in the new group. For this, a list of all registered
users is shown. The group is created, but members are not automatically added. No Risk Planning sends
them an email asking for authorization to be added. If they accept, they become members of the new group.
Users can also view all groups to which they belong.
5. Concluding Remarks
The usefulness and importance of a collaborative academic calendar motivated the No Risk Planning
development. In the educational context, this application can address the planning of many academic
activities. This project regarded aspects of Web engineering focusing on the WEBE framework proposed
by Roger Pressman. Activities such as Formulation and Planning, Analysis, Engineering, Generation
and Testing and Customer Evaluation were accomplished for the first framework increment. Lessons
learned about the process have been assimilated by the team of students responsible for the project, and
the main software quality assurance (SQA) tasks that have been pointed as essential to evolve the project
are: Software Configuration Management and Requirements Engineering.
Potential users evaluated the application and the data gathered are being used in ongoing works. It is
worth noticing that the three versions of No Risk Planning agenda have been developed during the last
year. Additionally, they will be important in the next framework cycle of evolutionary model: usability and
navigability characteristics are the main focus for improving the application. Another result of No Risk
Planning project was its well-succeeded integration with the CoWeb a Collaborative Web
implementation [1]. The integration has been very useful as a support to the learning approach that exists
in CoWeb, since it allows people to manage their tasks schedule. In this case, tasks are related to the
collaborative editing of lecture web pages. For instance, by using the No Risk Planning, a teacher can
arrange and announce the date the students should turn in homework, and he can also state the related
topics and important notes in a CoWeb page. Consequently, students can easily access both the
established date and notes related to the work.
Nowadays, No Risk Planning has 44 common users, 46 lecturers, 81 disciplines and 29 groups
registered. The perspective of the increased amount of all users has given us motivation to keep on the
research of how the process can attend to their demand, and to see alternative technical solutions (for
instance, by means of frameworks or design patterns) to improve its evolution.
References
[1] Arruda Jr., C.R.E.; Pimentel, M.G.C. Projeto e Implementao de um Sistema Colaborativo de Edio. Revista
Eletrnica de Iniciao Cientfica da Sociedade Brasileira de Computao (REIC-SBC), Ano 1. Novembro 2001.
(in Portuguese)
[2] Athula, G.; Murugesan, S. Web Engineering: An Introduction. IEEE Multimedia, v.l8, Issue 1, p.14-18, 2001.
[3] Costagliota, G.; Ferrucci, F.; Francese, R. Web Engineering: Models and Methodologies for the Design
Hypermedia Applications. Handbook of Software Engineering & Knowledge Engineering, Emerging
Technologies, v.2, p. 181-199, 2002.
[4] eXtropia home page. [Online]. http://www.extropia.com/scripts/calendar.html [21/06/2002]
[5] ISO/IEC 14598-5, International Standard. Information Technology - Software product evaluation - Part 5: Process
for evaluators (1997).
[6] Lee, H.. Your Time and my time: a temporal approach to groupware calendar systems. Information &
Management, Elsevier , 40, 159-164, 2003.
[7] Olsina, L., et al. Specifying Quality Characteristics and Attributes for Web Sites. First ICSE Workshop on Web
Engineering, ACM, Los Angeles, 1999.
[8] Pimentel, M. G. C., Abowd, G. D., Brotherton, J. Requirements for Capture-based Support to Learning
(Accepted in May 2002). Communications of the ACM, 2002.
[9] Paiva, D. M. B.; Sanches, R; Fortes, R. P. M. Melhoria de processo de software no contexto do desenvolvimento
acadmico de uma agenda na web. In: 14o. Congresso Internacional de Tecnologia de Software (CITS 2003).
Proceedings. Curitiba-PR. June, 2003. p. 56-68. (in Portuguese)
[10] Pressman, R. S. Software Engineering. 5th edition, McGraw-Hill, 2001.
[11] Project Place home page [Online]. http://projectplace.com/ [21/06/2002]
[12] Ribeiro,T.M.; Fortes, R.P.M.; Freire, A P. - Documentao do Software Agenda No Risk Planning So
Carlos-SP, ICMC-USP, Brasil, 2003. 69p. (Relatrios Tcnicos do ICMC, 182). (in Portuguese)
[13] Web Organizer home page. [Online]. http://weborganizer.sourceforge.net/ [21/06/2002]
[14] Chronoss. [Online]. http://chronoss.sourceforge.net [18/12/2002]
[15] Calendar Publisher II. [Online]. http://www.upoint.net/calendar2/index.shtml [18/12/2003]
[16] Web Absence. [Online]. http://www.unix-wissen.de/absence/ [18/12/2003]
[17] Calcium. [Online]. http://www.brownbearsw.com/calcium/. [18/12/2003]
[18] Alltasks. [Online]. http://freshmeat.net/projects/alltasks/. [18/12/2003]
[19] CollabOffice. [Online]. http://collaboffice.sourceforge.net/. [18/12/2003]
[20] WebCalendar. [Online]. http://webcalendar.sourceforge.net/. [18/12/2003]
[21] Zope Group Calendar [Online] .http://sourceforge.net/projects/zgc/. [18/12/2003].
Generacin Automtica de Aplicaciones basadas en Componentes a

partir de Bases de Datos
Ignacio Garca, Macario Polo, Mario Piattini
Grupo Alarcos
Escuela Superior de Informtica
Universidad de Castilla la Mancha
Paseo de la Universidad, 4
13071-Ciudad Real
igarcia@proyectos.inf-cr.uclm.es
Macario.Polo@uclm.es
Mario.Piattini@uclm.es
Resumen
Este artculo presenta una propuesta para generar aplicaciones basadas en componentes
distribuidos a partir de bases de datos. En particular, se describe el mtodo de reingeniera que aplicamos a
la base de datos para obtener, finalmente, la capa de componentes de la aplicacin. Inicialmente se obtiene,
mediante Ingeniera Inversa, un modelo de clases que representa el esquema conceptual de la base de datos,
que puede ser modificado por el ingeniero de software mediante la adicin de clases, operaciones, etc.;
entonces, se aplica un proceso de generacin automtica de cdigo, obtenindose un componente por cada
clase seleccionada.
1. Introduccin
Una de las herramientas ms potentes que ofrece la ingeniera del software para aprovechar o aumentar la
funcionalidad de los sistemas heredados es la reingeniera (Figura 1). De acuerdo con [3], la reingeniera est
compuesta a su vez por otros dos procesos, la ingeniera inversa y la ingeniera directa.
1. Desarrollo Inicial 2. Desarrollo Inicial

6. Ingeniera Directa 8. Ingeniera Directa
Anlisis Diseo Implementacin

4. Ingeniera
Inversa 3 Ingeniera
Inversa
5. Nuevos requisitos, 7. Redocumentacin 9. Redocumentacin

reestructuracin,
redocumentacin
Figura 1. Modelo de reingeniera simplificado

Segn [3], la ingeniera inversa es el proceso de construir especificaciones formales abstractas del cdigo
fuente de un sistema heredado (legacy), de manera que estas especificaciones puedan ser utilizadas para
construir una nueva implementacin del sistema usando ingeniera directa.
La ingeniera inversa cobra gran importancia dentro del proceso de mantenimiento, ya que de ella se
obtienen representaciones del sistema a un nivel de abstraccin ms alto que el original [23][1], lo que
aumenta la facilidad de comprensin del sistema original, su mantenibilidad, etc. [3]. La ingeniera inversa
suele aplicarse a sistemas antiguos, de los que queremos obtener modelos conceptuales y arquitectnicos de
ms alto nivel. Estos modelos se modifican y mejoran (en la Figura 1 correspondera a la etapa etiquetada
reestructuracin) y se utilizan como entrada para la siguiente fase de ingeniera directa.
Al aplicar ingeniera inversa a una base de datos para recuperar su correspondiente esquema conceptual, lo
ms habitual es obtener un esquema entidad-interrelacin [24] [25] [26] [27], si bien de otras propuestas se
obtiene una representacin orientada a objetos, normalmente en forma de clases [14]. En particular, la
utilizacin de diagramas de clases para representar el esquema de la BD supone, desde el punto de vista de la
reingeniera, la posibilidad de aprovechar las caractersticas del paradigma orientado a objetos no slo para la
posterior reconstruccin de la base de datos, sino tambin para la construccin de aplicaciones capaces de
manipular dicha base de datos [3].
En nuestro caso, procesaremos los diagramas de clases obtenidos de la ingeniera inversa para generar
aplicaciones multicapa cuya capa de dominio estar compuesta de componentes, en principio tipo EJB[7]
[15], que son componentes desarrollados mediante el lenguaje de programacin Java [6]. En este artculo
presentamos la parte del sistema encargada de realizar la ingeniera inversa y el mtodo seguido para la
generacin de la capa de componentes.
El mtodo dispone de un fuerte sustrato matemtico con el que describimos de manera formal: (1) el
metamodelo utilizado para representar los elementos de una base de datos que resultan de inters para nuestro
propsito; (2) el metamodelo mediante el cual describiremos la estructura genrica de un EJB [9] y la capa de
EJBs de la aplicacin; y (3) una funcin para realizar la transformacin entre metamodelos.
Este artculo esta organizado de la siguiente manera: en la seccin 2, mostramos algunas tecnologas
relacionadas con el software distribuido; en la seccin 3 hacemos una breve introduccin acerca de los
Enterprise Java Beans, donde mostramos algunas de sus caractersticas; en la seccin 4, pretendemos mostrar
una visin formalizada del problema y de los conjuntos de elementos que intervienen en la resolucin del
mismo; en la seccin 5 hacemos unos breves comentarios sobre la parte no automtica del proceso; en las
secciones 6 y 7 ofrecemos algunas conclusiones y algunas lneas de trabajo que podran seguirse a partir de
este trabajo.
2. Tecnologas de componentes
Las aplicaciones que utilizan arquitecturas de componentes distribuidos son relativamente recientes. No
obstante, existen distintas propuestas interesantes, que de alguna forma intentan solucionar el mismo
problema, que es ofrecer soporte a las aplicaciones que requieran ejecutar alguna funcionalidad a travs de la
red.
Microsoft, hace algn tiempo, tomo parte en esta joven tendencia. Su particular propuesta o contribucin
consisti en la extensin de una arquitectura de componentes propietaria. Esta arquitectura de componentes
de Microsoft era COM [10] (Component Object Model), que fue extendida a DCOM [5] (Microsoft
Distributed COM). Esta infraestructura permite a una aplicacin invocar componentes del Modelo de objetos
componentes instalados en otro servidor. A pesar de haberse portado a algunas plataformas, DCOM nunca ha
conseguido amplia aceptacin en dichas plataformas, por lo que rara vez se utiliza para facilitar la
comunicacin entre computadores con Windows y sin Windows [2].
Por otro lado, y tambin basado en el lenguaje de programacin Java, tenemos la tecnologa Java RMI [11]
(Remote Method Invocation). Java RMI tiene una filosofa similar a la ya clsica comunicacin estilo RPC
[12]. En RMI, vamos a disponer de una serie de objetos localizados en un servidor conectado a la red.
Mediante una previa localizacin del objeto, podremos ejecutar los mtodos pblicos del mismo esperando
una respuesta de esta accin. De manera muy simplificada, de los objetos que existan en el servidor,
conoceremos una interfaz, es decir, conoceremos sus operaciones pblicas o servicios, y a travs de esta
interfaz nos comunicaremos con el objeto.
No hace mucho surgi una nueva arquitectura de componentes distribuidos. Su nombre, muy descriptivo,
nos da una idea de que son y para que sirven. Esta tecnologa recibe el nombre de Servicios Web [13]. Un
Servicio Web es un componente que esta ejecutndose en un servidor, exponiendo una interfaz, mediante la
cual podemos invocar sus servicios para realizar una determinada actividad. Los Servicios Web intentan
solucionar algunos de los puntos flacos de las tecnologas, como por ejemplo la interoperabilidad entre
plataformas, interfaces fuertemente tipadas, uso de los estndares de Internet existentes, soporte para
cualquier lenguaje, etc [2]. Los Servicios Web se apoyan sobra un conjunto de protocolos, que son: UDDI y
DISCO para su bsqueda y descubrimiento, WSDL para la descripcin, SOAP para el formato de los
mensajes, y sobre todos estos XML para permitir la codificacin de toda la informacin. Adems, como
novedad respecto a otras arquitecturas, los Servicios Web no estn ligados a ningn protocolo de transporte
especfico, tan slo requiere de este que sea capaz de transmitir caracteres, que es lo que son al fin y al cabo
los documentos en XML.
Por ltimo, comentaremos algunos aspectos introductorios sobre otra arquitectura de componentes,
CORBA [4]. CORBA es un estndar creado por OMG a principios de los 90. Consiste en un sistema de
objetos distribuidos multiproceso, multilenguaje y que ofrece un acceso a la red totalmente transparente.
CORBA ofrece independencia multilenguaje, ofreciendo la posibilidad de realizar un desarrollo modular en el
que cada parte puede ser programada con el lenguaje que ms interese [22]. Mediante un acceso totalmente
transparente a la red, podemos hacer uso de objetos remotos, es decir, que se estn ejecutando en servidores
conectados a la red.
3. Caractersticas de los componentes Enterprise Java Beans
Por trmino general, los componentes tienen dos partes bsicas [14]:
Interfaz: Define los servicios que proporciona el componente (Conjunto de mtodos y

parmetros).
Implementacin: Incluye la funcionalidad que aporta el servicio.
Los Enterprise Java Beans [9] proporcionan un marco de trabajo independiente de la plataforma para el
desarrollo de componentes.
Los EJB son componentes que se ejecutan del lado del servidor. Esta caracterstica les confiere la
propiedad de dar soporte a operaciones concurrentes de forma fiable y eficiente. Dentro de la arquitectura de
componentes distribuidos EJB, existen varios tipos de Beans, estos son los Session Bean, Entity Bean y
Message Driven Bean. Los Session Bean simplemente realizan una tarea para un cliente sin utilizar
persistencia, los Message Driven Bean procesan mensajes de forma sncrona, y los Entity Bean, que son los
que ms interesantes para nuestro propsito, representan una entidad de negocio almacenada que existe de
forma persistente.
Figura 2. Clases de un Entity Bean.
Teniendo en cuenta que los EJB que vamos a utilizar bsicamente son los Entity Bean, vamos a describir
brevemente su estructura para comprender como funcionan. Segn la Figura 2, un EJB, se compone de los
siguientes elementos:
Interfaz Home: Define los mtodos que permiten a un cliente encontrar y crear un Entity Bean.
Cuenta con los mtodos create y findByPrimaryKey, que permiten al cliente crear una nueva
instancia del EJB o encontrar una ya existente mediante la clave primaria. En esta interfaz tambin
se definen los llamados mtodos Finder, que nos permiten recuperar una interfaz remota del EJB o
una coleccin de ellas, mediante las cuales ya podemos invocar las llamadas que necesitemos
realizar.
Interfaz Remota: Esta interfaz define los mtodos mediante los cuales el cliente interacta con el
EJB. Los mtodos aqu incluidos, generalmente, permiten manipular la informacin de la base de
datos que representa el EJB, bien modificndola, realizando alguna operacin de computo, etc. Una
referencia a esta interfaz es lo que se devuelve al cliente cuando este ejecuta una operacin create,
findByPrimaryKey o alguno de los mtodos Finder.
Enterprise Bean: Es una clase que implementa la interfaz EntityBean. Esta clase tiene como
propiedades a los atributos de la tabla de la base de datos a la que representa. En esta clase, se
implementan los mtodos que permiten gestionar el ciclo de vida del EJB, los mtodos create, los
mtodos findByPrimaryKey, los mtodos Finder, etc.
Clases Auxiliares: Estas son otras clases que el EJB necesite utilizar para desempear sus
operaciones, como podra ser, por ejemplo una clase que implementara algunas funciones
matemticas. Un ejemplo de esto, puede ser el que resulta de usar una clase que nos de soporte para
realizar los accesos a la base de datos (Figura 3).
Figura 3. Clase Broker que soporta el acceso a la base de datos.
Adems, al utilizar EJB, podemos seguir desarrollando nuestras aplicaciones siguiendo eficientes
arquitecturas multicapa [16], mediante las cuales, encapsulamos el software en distintas capas verticales en
funcin del rol que juegue dentro de nuestro sistema. Como se puede ver en la Figura 4, los componentes
distribuidos se encapsularan o situaran dentro de la capa de dominio:
Figura 4. Integracin de los EJB dentro de la arquitectura multicapa
Alguna de las tecnologas asociadas a los EJB son JDBC [17], que consiste en una API para el acceso a
bases de datos relacionales, y J2EE [18], que son un conjunto de APIs que nos permiten desarrollar, por
ejemplo, Servlets pginas JSP (mediante J2EE, podemos realizar de manera sencilla interfaces grficas para
aplicaciones WEB), as como aplicaciones para manipular documentos XML [19] (que es un medio excelente
para el intercambio de informacin entre aplicaciones heterogneas ), configurar aplicaciones, generar
interfaces de pginas web (esto junto con hojas de estilo XSL [20]), mediante JAXP o DOM [21].
Figura 5. Interaccin entre el cliente y el EJB.
Por ltimo y para terminar esta secci n, en la Figura 5 podemos ver la interaccin del cliente con el EJB. El
cliente, mediante la Interfaz Home , recupera o crea una instancia del objeto, mediante la cual realiza las
operaciones que neces ita realizar el EJB.
4. Formalizacin del problema
En esta seccin se describen los metamodelos correspondientes a la base de datos y a la capa de la

aplicacin formada por los componentes distribuidos.
El conjunto de componentes que generemos depender de la estructura de la base de datos a partir de la cual
comencemos el proceso de ingeniera inversa. De alguna forma necesitamos formalizar la informacin que
extraigamos acerca de la estructura interna de la base de datos, por lo que almacenaremos un metamodelo que
representa el esquema relacional de la base de datos.
De la misma forma, disearemos tambin un metamodelo para representar de manera formal la estructura
de un Entity Bean (el tipo de EJB que nos interesa) y de un conjunto de componentes de este tipo. En este
caso, el metamodelo nos permitir no slo formalizar los componentes que generemos, sino tambin las
relaciones entre ellos. El metamodelo nos permitir modelar tambin las posibles relaciones entre los
componentes que generemos, ya que nuestra meta es generar una capa de componentes distribuidos que
permita acceder a la base de datos original de forma remota, y para que esto se lleve a cabo de manera
correcta, cada EJB, que representar una ocurrencia de la tabla, debe saber qu otras ocurrencias de otras
tablas podran verse afectadas por modificaciones, consultas, inserciones o eliminaciones. Es decir, que otros
EJB deben ser notificados por posibles cambios. Todas las claves ajenas y restricciones de integridad que
puedan existir en la base de datos se implementarn a base de relaciones entre los componentes EJB.
Esto se refleja en que, al final, lo que queremos es obtener un sistema compuesto por mdulos entre los que
se establecen una serie de relaciones, formalmente:
S = (M , R) , R MxM
4.1. Metamodelo de una base de datos relacional
A continuacin, se describe brevemente el metamodelo que hemos desarrollado con anterioridad y que
puede encontrarse en [14]. Ntese que slo describimos los elementos de la base de datos que, de momento,
son relevantes para nuestro propsito.
Este metamodelo describe la informacin acerca de la estructura de la base de datos que es relevante y
necesaria para nuestro propsito. Para nuestro caso, necesitamos almacenar informacin sobre las tablas que
existen en la base de datos, las relaciones que existen entre ellas en forma de claves ajenas o foreignkeys, las
columnas de que consta cada tabla, el tipo de dato que almacena cada columna, si es clave primaria, si es
clave ajena, si admite valores nulos, etc.
Consideraremos que una base de datos DB, estar compuesta por tablas y por relaciones entre las tablas,
las claves ajenas. Estas claves ajenas se definen entre dos tablas, la tabla padre y la hija. Algebraicamente
expresado:
DB = (Tablas, FKS)
donde FKS Tablas x Tablas.
Dado t Tablas = (Nombre, Columnas, Indices ) , que son, respectivamente, el nombre de la tabla, el conjunto
de las columnas que la componen, y los ndices, que es tambin un conjunto de columnas que constituyen una
clave alternativa.
Dado c Columnas = (Nombre, tipo , permitidoN otNull , esPK ) , que son, respectivamente, el nombre de la
columna, el tipo de dato, si acepta valores nulos y si es clave primaria.
Por ltimo, dado un f FKS=(tPpal .Nombre, tSec .Nombre, cPpal , cSec ) , que son, respectivamente, el nombre
de la tabla principal, el nombre de la tabla secundaria, la clave primaria de la tabla principal, y las columnas
que forman la clave ajena en la tabla secundaria, y cuyos valores son restringidos por la clave primaria de la
tabla principal.
4.2. Metamodelo del diagrama de clases
Dentro de nuestro proceso de reingeniera, el modelo de clases es el punto intermedio al cual queremos
llegar al aplicar ingeniera inversa a la base de datos relacional, y del cual deseamos partir para realizar
ingeniera directa para obtener la capa de componentes EJB.
Al igual que ocurre con la base de datos, necesitamos una medio formal y consistente para representar
nuestros diagramas de clases, de forma que la estructura relacional de las bases de datos quede reflejada sin
ambigedad en nuestro modelo conceptual abstracto.
Los tem a representar en este tipo de diagramas son las clases y las relaciones que pueda existir. Dentro de
las clases, habra que distinguir entre clases normales, clases abstractas e interfaces. Las clases normales,
incluyen mtodos y atributos, las clases abstractas incluyen tambin mtodos y atributos, con la salvedad de
que algunos de estos mtodos pueden no estar implementados, y las interfaces slo contienen mtodos sin
implementar. Las interfaces pueden considerarse como una clase totalmente abstracta, donde la nica relacin
que puede establecer es mediante implementacin.
Formalizaremos la representacin de estos diagramas, al igual que hacamos en 3.2, mediante el lgebra
relacional. As pues, adoptaremos la formalizacin de un sistema basado en clases que se realizaba en [14].
Un sistema M, sera una tupla M = (C , R ) , donde C es el conjunto de clases e interfaces existentes en el

sistema, y R el conjunto de relaciones existentes entre los elementos de C, de forma que R CxC .
El conjunto R = ( A, D ) , donde A es el conjunto de asociaciones y agregaciones, y D es el conjunto de todas

las dependencias.
A continuacin, describiremos con ms detalle los conjuntos C y A, que como veremos ms adelante, nos
darn parte de la descripcin formal de nuestros componentes.
4.2.1. Formalizacin del conjunto de clases. Teniendo c C = (Nombre, Campos, Mtodos, Padres , esInterfaz) ,
donde Nombre es el nombre de la clase, Campos es el conjunto de campos de la clase, Mtodos es el conjunto
de mtodos de la clase, Padres es el conjunto de clases de las que hereda c y las interfaces que implementa, y
esInterfaz es un valor lgico que dice si c es una interfaz o no.
Siguiendo una definicin recursiva a partir de la definicin de c, continuaramos de la siguiente manera.
Dado f Campos = (Nombre, Tipo, Visibilida d , esPK ) , donde Nombre es el nombre del campo, Tipo es el tipo
del campo, Visibilidad es la visibilidad del mismo y esPK dice si forma parte de la clave primaria. Puede
extraar que a un campo de una clase se le asocie un atributo esPK, pero teniendo en cuenta que este
diagrama de clases va a representar el esquema relacional de la base de datos, y que cada clase se
corresponder con una tabla, necesitamos saber, a fin de establecer las correspondientes relaciones, cuales de
los campos de las clases constituyen las claves primarias en las tablas de la base de datos.
Dado m Mtodos = ( Nombre, Tipo, Visibilida d , Argumentos, esEsttica ) , donde Nombre es el nombre de la
clase, Tipo es el tipo del valor que devuelve, Visibilidad es la visibilidad del propio mtodo, Argumentos es un
conjunto de elementos del tipo (Nombre ,Tipo ) que pasamos a m y esEstatica que toma valores entre
{verdadero, falso} .
c.Padres vendra dado por la expresin {p C / p es una clase padre o interfaz implementada por c}.
El atributo esInterfaz, tomara los valores {true, false} en funcin de que la clase c sea una interfaz o no.
4.2.2. Formalizacin del conjunto de relaciones R. Consideraremos miembros de R, a las asociaciones ,

agregaciones y dependencias. Teniendo en cuenta, que en esta parte, como hemos mencionado ya, hemos
tomado como refe rencia el trabajo incluido en [14], comentaremos algunos aspectos necesarios para entender
mejor la aproximacin a la resolucin del problema.
Las agregaciones y las asociaciones, se tratan de la misma manera, por lo que caen dentro del mismo
conjunto, A, diferencindolas ms tarde en ciertos aspectos que no mencionaremos aqu. Las dependencias,
que son relaciones temporales entre clases, caen en el conjunto D, de forma que R = ( A, D ) .
Dado a A = (cL, Cr, isFinalL , isFinalR , cardL, cardR, Name, Fields ) , donde cL y cR, son las clases que forman
parte de la relacin, isFinalL y isFinalR, dicen si estas clases son finales, en el sentido de la navegabilidad,
cardL y cardR, representan la cardinalidad de cL y cR en la relacin. Name se refiere al posible nombre que
podamos darle, y Fields, representa un posible conjunto de campos de la asociacin o de la agregacin.
Dado d A = (cL , cR ) , donde cL C y cR C , y representan las clases que intervienen en la

dependencia, siendo cL la que depende de cR.
4.3. Funcin de transformacin
A groso modo, el concepto o idea que intentamos plasmar en este artculo, es el de el diseo y la
implementacin de una funcin que mediante tcnicas y patrones de la ingeniera del software, nos permita
realizar una compleja transformaci n que genere una capa de componentes EJB a partir de una base de datos
relacional.
f ( BD) = CapaEJB
Esta funcin de transformacin, estara definida como una funcin por partes, es decir, podra
descomponerse en otro par de funciones, que actuaran sobre distintas partes del dominio del problema:
f ( BD) = CapaEJB
( )
f1 BD ModeloClases f2 (ModeloClas es ) CapaEJB
En los apartados anteriores, hemos descrito de una manera formal como se realiza la primera parte de la
transformacin a partir de la base de datos, es decir, cmo operara la funcin f1 . Para la segunda fase de la
transformacin, que se correspondera con el proceso de ingeniera directa, tomaramos como entrada para la
funcin f2 la salida de la primera funcin, es decir, el diagrama de clases que representa el esquema relacional
de la base de datos.
Antes de analizar la funcin f2, debemos representar formalmente lo que queremos obtener, es decir,
debemos modelar de manera genrica esa capa de componentes EJB que interpondremos entre la base de
datos y las aplicaciones cliente que intentes acceder a ella.
4.4. Formalizacin de la capa EJB
Llamaremos Capa EJB al conjunto de Entity Beans que permitirn al cliente realizar cierto tipo de
operaciones sobre las tablas de la base de datos. El nmero de los componentes de los que est conformada
esta capa, podra depender de distintos factores, entre los que se encuentra la propia estructura de la base de
datos, y el patrn de diseo [16] que apliquemos a la hora de realizar la traduccin. Ms detalladamente,
cuando pasamos de un diagrama de clases a una base de datos, existen distintos patrones de diseo que nos
ofrecen soluciones genricas a problemas bien conocidos.
En nuestro estudio, eliminamos esta ambigedad, generando siempre un nmero predecible de

componentes. Cuando creemos la capa de componentes a partir de la base de datos, tendremos siempre tantos
componentes como tablas existan en la base de datos. As y de esta forma nos evitamos el tener que realizar
clculos complejos para determinar determinadas estructuras en la base de datos.
As pues, llamaremos E a la capa EJB, y diremos que E = (S , R) , donde S es el conjunto de Entity Bean y R
es el conjunto de relaciones existentes entre los componentes de la capa: R SxS
4.4.1. Metamodelo de un Entity Bean. Como hemos visto hasta ahora, nuestra motivacin y nuestro fin es el
generar esta capa de componentes que nos permitirn realizar diversas operaciones sobre la base de datos. A
lo largo de este apartado se describe de manera formal la estructura genrica de un EJB Entity Bean, es decir,
vamos a intentar plantear un metamodelo que nos permita representar los EJB y las posibles relaciones que
existan entre ellos (vase seccin 3).
Diremos que s S = (InterfaceH ome, Interface Re mota, ClaseEJB , Auxilares ) , donde InterfaceHome contiene
las cabeceras de los mtodos que permiten al cliente encontrar y crear instancias de un Entity Bean,
InterfaceRemota contiene los mtodos o servicios que el cliente puede realizar sobre la base de datos a travs
del componente, y Auxiliares, que representa al conjunto de clases que pueden ser necesarias para que el
componente realice su funcin.
ClaseEJB = (CamposT, CampoC, OtrosAtributos, ImpMHome, ImpMRemota, metodosAcceso,

OtrosMetodos), donde CamposT son los atributos del EJB que corresponden con los campos de la tabla,
CampoC, es un atributo que almacena el contexto del componente, OtrosAtributos es el conjunto de atributos
adicionales que podran ser necesarios, ImpMHome sera el conjunto de mtodos definidos en InterfaceHome,
pero ya implementados, ImpMRemota sera el conjunto de mtodos definidos en InterfaceRemota, pero ya
implementados, metodosAcceso son mtodos get_ y set_ que permiten acceder y establecer los valores de
todos los atributos , y OtrosMetodos sera el conjunto de mtodos que el desarrollador necesite agregar para
realizar determinadas operaciones, como puede ser realizar una insercin en la base de datos.
4.5. Descripcin formal proceso de ingeniera directa, la funcin f2
El algoritmo principal, que genera la capa de Entity Bean, toma como entrada el diagrama de clases que se
ha obtenido previamente aplicando ingeniera inversa a la base de datos. A partir de este diagrama, el
algoritmo calcula cules son los componentes EJB necesarios y los crea tambin, basndose en el metamodelo
que hemos comentado brevemente en los puntos anteriores.
A continuacin se detalla un fragmento de este algoritmo:

1 crearCapaEJB(M:DiagramaClases):E{
2 (
E = , ; )
3 S = ;
4 R = :
5 c M.C{
6 vCamposTabla = ;
7 vCampoContext = inicializarContext();
8 vOtrosAtributos = ;
9 vMetodosAcceso = ;
10 f c.Fields{
11 if(f.isPK)
12 vCamposTabla = vCamposTabla f;
13 else
14 vOtrosAtributos = vOtrosAtributos f;
15 vMetodosAcceso = vMetodosAcceso ("get" + f.Name,f.Type,"#", ,False);
16 vMetodosAcceso = vMetodosAcceso ("set" + f.Name,void,"#",f.Type,False);
17 }
18 vClaseEJB = (vCamposTabla,vCampoContext,vOtrosAtributos, ,,,vMetodosAcceso);
19 S = S (vClaseEJB,crearInterfaceHome(),crearInterfaceRemota());
20 }
M
[resto de funcin]
nn }
donde se puede observar, entre otras cosas, que la entrada es un diagrama de clases, y que devuelve un
elemento E que, como vimos en 3.4, representa la capa EJB. Para tener E completo, debemos calcular S y R,
que son el conjunto de Entity Bean y las relaciones entre los mismos respectivamente.
En el algorit mo, se ve lo que podra equivaler al clculo de S. Puede observarse, como tomamos el conjunto
de clases generado en el proceso de ingeniera directa, y lo transformamos a un conjunto de Entity Bean. Por
cada clase hemos creado un componente EJB que se comp leta con la informacin extrada de la clase.
Cada uno de los EJB generados contendr los mtodos estndar findBy que nos permitirn la
materializacin de instancias a partir de la informacin de la base de datos. Entre estos mtodos cabe destacar
los findByPrimaryKey, cuya misin es realizar bsquedas por la clave primaria de la tabla que le pasaremos;
si la tabla a la que representa el EJB dispone adems de la clave primaria de alguna clave alternativa, tambin
se generar un mtodo tipo findBy[ClaveAlternativa] al que pasaremos como argumento el valor de dicha
clave para la bsqueda. En el caso de que la clave primaria de la tabla o la alternativa estn formadas por ms
de una columna, generaremos, adems, un mtodo del tipo findBy[NombreDeLaColumna] para cada una de
las columnas que formen parte de las claves, a fin de obtener una coleccin de registros de la base de datos a
partir del dato que le pasemos como argumento.
5. Refinamiento Manual
Cuando generamos toda la capa de Entity Bean es preciso instrumentar los componentes EJB para indicar
qu operaciones va a haber a disposicin del cliente.
Junto con la interfaz del componente, hay otros mtodos, que no se generan automticamente. Algunos de
estos mtodos son los que puedan ser necesarios para permitir que el Bean realice su tarea de cmputo, es
decir, mtodos privados.
Como es lgico, el objetivo de nuestro estudio es conseguir la mayor automatizacin posible de este
proceso, permitiendo la generacin de la capa de EJB de forma sencilla segn distintas alternativas. Para
mermar la dificultad o incomodidad que pudiera derivarse de la realizacin de este cdigo que es inevitable
realizar, hemos pensado en la realizacin de una serie de asistentes que en cierto modo van a permitir aadir
estas funcionalidades a nuestros componentes en desarrollo.
La primera propuesta es la de implementar un pequeo entorno que permita realizar de forma grfica y
mediante diagramas de actividad, la especificacin de las operaciones que tengamos que agregar de forma
manual [8]. El uso de estos diagramas requerira ciertos conocimientos del lenguaje de modelado UML para
poder realizar la descripcin de las operaciones.
Como podra caber la posibilidad de que algunos de los posibles usuarios no tuvieran los conocimientos o
practica necesaria para utilizar dicho tipo de diagramas, tambin se implementara, dentro de este entorno, un
asistente para que de forma sencilla permita incluir manualmente el cdigo de los mtodos. Este asistente
permitira que la tarea de editar los archivos de texto se convierta en un sencillo proceso, en el que los pasos
triviales seran tan sencillos que solo tendramos que pensar qu cdigo es el que tenemos que insertar.
6. Conclusiones y lneas de trabajo futuras
En este artculo se han presentado los primeros resultados de un trabajo con el que pretendemos generar de
manera semiautomtica aplicaciones basadas en componentes distribuidos, constituyendo una lnea de
continuacin del trabajo presentado en [14]. Se han descrito los diferentes metamodelos involucrados y el
mtodo seguido para generar la capa de componentes, estando an pendiente la descripcin de los
metamodelos y funciones de transformacin correspondientes al resto de capas de la aplicacin.
A lo largo del artculo, slo hemos hablado de un tipo de componente EJB denominado Entity Bean. Es
muy posible que podamos de alguna forma utilizar las otras clases de componentes EJB para ofrecer
soluciones con un nivel de granularidad ms fino, que sea capaz de ofrecer soluciones ms personalizadas y
eficientes a problemas ms concretos, as como adaptar el trabajo para generar aplicaciones para otras
plataformas, como Microsoft .NET.
Como idea para una futura mejora del sistema, se plantearn otras alternativas a la hora de generar el
middleware de componentes EJB a partir de la base de datos. Esto se refiere a que en lugar de realizar la
traduccin una tabla, un EJB, se plantear la posibilidad de utilizar alguna heurstica para agrupar conjuntos
de tablas (que puedan ser agrupadas por representar herencias u otro tipo de relaciones) para ser asociadas a
un solo componente.
7. Agradecimientos
Este trabajo est parcialmente financiado por el proyecto MS (Ministerio de Ciencia y

Tecnologa/FEDER, TIC2003-02737-C02 -02).
8. Referencias
[1]Piattini, M.G., Calvo-Manzano, J.A., Cervera, J. y Fernndez, L. Aplicaciones informticas de gestin, Editorial RA-
MA, Madrid, 1996.
[2]Short, S. Creacin de Servicios Web XML para la plataforma Microsoft .NET , Editorial Mc Graw Hill, Madrid,
2002.
[3]Arnold, R.S., Software Reeingineering, IEEE Press, 1992
[4]http://www.omg.org, Disponible en 15-12-2003.
[5]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndcom/html/msdn_dcomtec.asp, Disponible en 15-
12-2003.
[6]http://java.sun.com, Disponible en 15-12-2003.
[7]http://java.sun.com/products/ejb/, Disponible en 15-12-2003.
[8]Booch, G., Rumbaugh, J., Jacobson, I.., El Lenguaje Unificado de Modelado. Editorial Addison Wesley, Madrid, 1999.
[9]http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/EJBConcepts4.html, Disponible el 15-12-2003.
[10]http://www.cs.umd.edu/~pugh/com/, Disponible en 15-12-2003.
[11]http://www.ccs.neu.edu/home/kenb/com3337/rmi_tut.html, Disponible el 15-12-2003.
[12]http://www.ietf.org/html.charters/oncrpc-charter.html, Disponible el 15-12-2003.
[13]http://www.w3.org/TR/ws-arch/, Disponible el 15-12-2003.
[14]M. Polo, J.A. Gmez, M. Piattini, F. Ruiz, Generating three-tier applications from relational databases: a formal and
practical approach, Information and Software Technology 44 (2002) 923-941.
[15]http://java.sun.com/products/javabeans/, Disponible el 15-12-2003.
[16]Gamma, E. et al, Design patterns: elements of reusable object-oriented software, Editorial Addison-Wessley, 1995.
[17]http://java.sun.com/products/jdbc/, Disponible el 15-12-2003.
[18]http://java.sun.com/j2ee/, Disponible el 15-12-2003.
[19]http://www.W3.org/TR/2000/REC-xml-20001006, Disponible el 15-12-2003.
[20]http://www.w3.org/Style/XSL/, Disponible el 15-12-2003.
[21]http://java.sun.com/xml/jaxp/index.jsp, Disponible el 15-12-2003.
[22]http://rodrigo.gnome-db.org/documentation/talk-corba/, Disponible el 15-12-2003.
[23]T.J. Biggerstaff, B.G. Mitbander, D.E. Webster, Program understanding and the concept assignment
problem,Communications of the ACM 37 (5) (1994) 72-83.
[24]M. Andersson, en: Loucopolous (Ed.), Extracting an Entity Relationship Schema from a Relational Database through
Reverse Engineering, Proceedings of the 13 th International Conference on Entity-Relationalship Approach, Springer-
Verlag, Berlin, LNCS, vol. 881, 1994, pp. 403-419.
[25]L. Pedro de Jess, P. Sousa, en: Nesi, Verhoef (Eds.), Selection of Reverse Engineering Methods for Relational
Databases, Proceedings of the Third European Conference on Software Maintenance, IEEE Computer Society, Los
Alamitos, CA, 1998, pp. 194-197.
[26]R. Chiang, T. Barron, V.C. Storey, Reverse engineering of relational databases: extracting of an EER model from a
relational database, Journal of Data and Knowledge Engineering 12 (2) (1994) 107-142.
[27]J.L. Hainaut, J. Henrard, J.M. Hick, D. Roland, V. Englebert, Database Design Recovery, Proceedings of Eighth
Conferences on Advance Information Systems Engineering, CAiSE96, Springer, Berlin, 1996, pp. 463-480.
Elicitao de Requisitos para o Desenvolvimento de uma Ferramenta de

Apoio Metodologia de Elicitao de Requisitos de Software Baseada na
Teoria da Atividade (META1)
Simone Franceto Luiz Eduardo Galvo Martins

UNIMEP - Universidade Metodista de UNIMEP - Universidade Metodista de
Piracicaba Piracicaba
simonefranceto@ig.com.br lgmartin@unimep.br
Abstract
This work presents the requirements elicitation for the development of an automated tool for a Requirements
Elicitation Methodology Based on Activity Theory. The objective of such tool is to support the use of the
methodology (called META), not only stimulating and improving the productivity of the development team but
also improving the quality of the requirements engineering process. The tool should also collect and store the
data in a repository, adding quality to the process of requirements elicitation, besides helping the
understanding of the system context to the subsequent phases of the requirements engineering and the
implementation of the software system. Documentation, requirements analysis and logical project of the tool
also are presented in this article.
Keywords: META, Automated Tool, Activity Theory, Requirements Elicitation, Requirements Engineering.
1. Introduo
Na fase inicial da Engenharia de Software, a utilizao de mtodos, tcnicas e ferramentas do suporte

fase da Engenharia de Requisitos, auxiliando na obteno de requisitos claros e consistentes para o
desenvolvimento do software. O levantamento de requisitos compreensveis por todas as partes envolvidas no
desenvolvimento do sistema (clientes, analistas, desenvolvedores etc.) um fator essencial que previne falhas
no entendimento do problema a ser solucionado e, conseqentemente, evita que tais falhas sejam propagadas
ao sistema que est sendo desenvolvido.
Este trabalho apresenta a elicitao de requisitos feita para o desenvolvimento de uma ferramenta
automatizada que d suporte META (a metodologia de elicitao de requisitos empregada foi a prpria
META). O objetivo da ferramenta proposta agilizar e otimizar o emprego da META, impulsionando sua
utilizao e melhorando a produtividade da equipe de desenvolvimento que adotar esta metodologia, bem
como melhorar a qualidade da elicitao de requisitos realizada. A ferramenta auxiliar o emprego da
metodologia, garantindo a organizao e o armazenamento das informaes levantadas ao longo da elicitao
de requisitos feita com a META, agregando qualidade ao processo de elicitao de requisitos, alm de auxiliar
na compreenso do ambiente do sistema.
Para elicitar os requisitos da ferramenta proposta, foram seguidos os princpios e conceitos da Teoria da
Atividade, conforme discutida por [8] [4]. Assim, a ferramenta est fundamentada na Metodologia de
Elicitao de Requisitos de Software Baseada na Teoria da Atividade proposta por Martins [5].
2. Reviso Bibliogrfica
2.1. Papel da Engenharia de Requisitos
1
META: Metodologia de Elicitao de Requisitos Baseada na Teoria da Atividade
A Engenharia de Requisitos (ER) uma etapa importante do processo de desenvolvimento de software

devido a alta complexidade dos sistemas. A funo da ER gerar especificaes que descrevam de forma no
ambgua, consistente e completa, o comportamento do domnio de um problema. Existem vrias tcnicas que
contribuem para atingir este objetivo na elicitao de requisitos, onde busca-se entender quais so as
necessidades do usurio que devem ser atendidas pelo software que ser desenvolvido [7]. A negociao de
requisitos deve ser um processo objetivo. As decises a serem tomadas em relao aos requisitos do sistema
devem ser baseadas nas necessidades tcnicas e organizacionais, e negociaes devem ser conduzidas usando
somente argumentos lgicos e tcnicos, evitando-se que sejam influenciadas por necessidades pessoais dos
indivduos.
2.2. Metodologia de Elicitao de Requisitos de Software Baseada na Teoria da Atividade
A Teoria da Atividade tem como uma de suas vertentes de origem os trabalhos do psiclogo Vygotsky
(escola histrico-cultural Sovitica, no perodo de 1920 a 1930). Leontev e Lria deram continuidade ao
trabalho de Vygotsky e passaram a ser responsveis pelo termo atualmente empregado: Teoria da Atividade
[8].
A Teoria da Atividade formada por um conjunto de conceitos que buscam compreender e explicar porque
e como as atividades humanas so desenvolvidas. Dentro do contexto de uma atividade um sujeito atua sobre
o objeto atravs de uma ferramenta de mediao2 que por sua vez tem o papel de transformar este objeto em
resultado. As relaes sistmicas entre o sujeito e seu ambiente em uma atividade so representadas pelos
conceitos de comunidade, regras e diviso do trabalho, como mostra a Figura 1 [2]. Assim, o relacionamento
entre o sujeito e objeto mediado por ferramentas; o relacionamento entre o sujeito e a comunidade
mediado por regras e o relacionamento entre o objeto e a comunidade mediado pela diviso do trabalho. As
regras neste contexto so normas explcitas e implcitas, convenes e relaes sociais dentro da comunidade.
A diviso do trabalho refere-se a organizao explcita ou implcita de uma comunidade relacionada ao
processo de transformao de um objeto em resultado [6].
Ferramenta
Sujeito Objeto Resultado
Diviso do
Regras
Trabalho
Comunidade
Figura 1 - Representao sistmica de uma atividade (Diagrama de Engestrm) [2].
Os fundamentos da Teoria da Atividade so constitudos de um conjunto de princpios que compem um

sistema conceitual geral. De acordo com Martins a organizao dos princpios pode variar de autor para autor,
os quais normalmente a dividem em cinco ou seis [5]. Para uma melhor organizao da Metodologia de
Elicitao de Requisitos, Martins classifica os conceitos da Teoria da Atividade em dois grupos: i) Conceitos
Relativos Estrutura Hierrquica da Atividade; ii) Conceitos Relativos aos Elementos que Formam o
Contexto da Atividade. META est fundamentada nestes conceitos, como podemos observar no Quadro 1.
A Metodologia de Elicitao de Requisitos proposta por Martins, divide-se em trs etapas principais, cada
qual envolvendo procedimentos que auxiliam na identificao e descrio das atividades. A cada etapa
desenvolvida, os requisitos tornam-se mais claros e a elicitao vai se desenvolvendo gradativamente, como
pode ser observado no Quadro 2 o qual apresenta a organizao da metodologia [4] [5].
2
Mediao: O papel principal desempenhado pela mediao mediar a ao humana utilizando ferramentas tcnicas ou psicolgicas.
Quando se introduz o conceito de comunidade novas formas de mediao aparecem (alm daquela possibilitada pelas ferramentas), estas
novas formas de mediao so as regras e a diviso do trabalho.
Quadro 1 Relao de princpios e conceitos3 que fundamentam a META

Conceitos Relativos Estrutura Conceitos Relativos aos Elementos
Princpios
Hierrquica da Atividade que Formam o Contexto da Atividade
(1) - Princpio da unidade entre (1) - Atividade (7) - Sujeito
conscincia e atividade (2) - Motivo (8) - Objeto
(2) - Princpio da orientao a objetos (3) - Ao (9) - Ferramenta Tcnica
(3) - Princpio da estrutura hierrquica (4) - Meta (10) - Ferramenta Psicolgica
da atividade (5) - Operao (11) - Comunidade
(4) - Princpio da internalizao- (6) - Condies (12) - Regras
externalizao (13) - Diviso do Trabalho
(5) - Princpio da mediao (14) - Resultado
(6) - Princpio do desenvolvimento
Quadro 2 Etapas da Metodologia de Elicitao de Requisitos de Software Baseada na Teoria da

Atividade.
Principais Etapas
1 Etapa 2 Etapa 3 Etapa
Diviso do problema em atividades Delineamento do contexto das atividades Descrio da estrutura hierrquica das
(unidades de elicitao de requisitos) (para cada atividade) atividades (para cada atividade)
Procedimentos
1.1 Levantar atividades candidatas 2.1 Identificar os motivos e 3.1 Identificar as aes e operaes da
resultados da atividade atividade
1.2 Selecionar atividades 2.2 Identificar os elementos no nvel 3.2 Descrever as metas das aes
individual
1.3 Descrever histrico das 2.3 Identificar os elementos no nvel 3.3 Descrever as condies de
atividades selecionadas social realizao das operaes
2.4 Modelar a atividade atravs do
diagrama de Engestrom
1 Etapa - Diviso do Problema em Atividades: Consiste em organizar os problemas em atividades,

auxiliando em uma primeira viso do ambiente do sistema em que se encontra inserido o sujeito (ator
envolvido na atividade) e as diversas tarefas existentes dentro de um contexto scio-organizacional.
2 Etapa - Delineamento do Contexto das Atividades: Aps definidas as atividades, delineado o
contexto de cada atividade atravs dos elementos: motivos, resultados, sujeitos, ferramentas de mediao
(tcnicas e psicolgicas), objetos, regras, comunidade e diviso do trabalho.
3 Etapa - Descrio da Estrutura Hierrquica das Atividades: Nesta etapa a atividade dividida em
trs nveis hierrquicos: atividade, ao e operao. Ao e operaes dentro do contexto da atividade podem
ter um correspondente direto com os requisitos funcionais do sistema.
3. Processo de Elicitao e Modelo Lgico para o Desenvolvimento da Ferramenta
3.1. Elicitao de Requisitos
A META faz uma ligao entre o domnio da aplicao e as informaes obtidas atravs do processo de
elicitao utilizando a metodologia. A ferramenta implementar esta ligao utilizando um Banco de Dados
que disponibilizar as informaes atravs de consultas e relatrios especficos para o desenvolvimento dos
processos seguintes da ER. O quadro 3 auxilia na apresentao resumida das atividades elicitadas para o uso
da ferramenta. Este resumo contm todos os procedimentos apresentados no quadro 3, exceto o procedimento
1.3, devido o grande volume de informaes que foram levantadas.
3
Cada princpio e conceito tem uma definio e numerao dentro da META.
Quadro 3 Resumo da Elicitao de Requisitos para o desenvolvimento da

ferramenta de apoio META
As Figuras 2 e 3 exemplificam o resultado do procedimento 2.4, as quais apresentam o

comportamento entre os elementos do nvel individual. Observando estas figuras com o diagrama de Engestrm da
Figura 1, nota-se que o procedimento 2.3 no foi desenvolvido, pois a utilizao da ferramenta, nesta primeira
verso, envolver somente o analista de requisitos, no envolvendo uma comunidade (formada por atores que
de alguma forma influenciam o(s) objeto(s) da atividade).
3.2. Observaes Referentes ao Processo de Elicitao de Requisitos Realizado
A primeira verso da ferramenta de apoio META, para a qual foi realizada a elicitao de requisitos ora
apresentada, ser para um ambiente mono-usurio. Apenas o analista de requisitos estar envolvido no
contexto da utilizao da ferramenta. A seguir apresentamos os resultados e alguns pontos observados durante
a elicitao de requisitos, os quais nos auxiliaram no desenvolvimento do projeto da ferramenta.
Observou-se uma seqncia entre os procedimentos vinculados s etapas da META. Para garantir
qualidade e integridade das informaes coletadas, o analista no poder saltar etapas e procedimentos. A
ferramenta dever bloquear a passagem para o prximo procedimento se existir campos em branco do
procedimento em desenvolvimento, que sejam pr-requisitos para os prximos.
Para todos os procedimentos da META importante que a ferramenta apresente de forma resumida, uma
interface interativa com definies e princpios da META, auxiliando o analista a identificar rapidamente
o procedimento que dever ser trabalhado.
Com a finalidade de manter todas as etapas e procedimentos documentados, todas as alteraes que
surgirem durante o desenvolvimento do trabalho devero ser registradas com data, hora, motivo e
responsvel pela alterao.
O modelo de Engestrm nos permite uma viso real do contexto onde a atividade est inserida, com o
relacionamento entre sujeitos e objetos mediados pelas ferramentas (neste contexto a palavra ferramenta
um dos elementos da atividade).
Os requisitos da ferramenta podem ser observados claramente nas colunas Aes e Operaes de
cada atividade. Neste procedimento conseguimos identificar o que ser necessrio efetivamente na
implementao da ferramenta. Por exemplo: na Atividade A5, as Aes so: Analisar o contexto do
ambiente em estudo; Utilizar as atividades selecionadas; Aplicar as definies (7,8,9,10) da META. As
operaes so: Preencher campos especficos da ferramenta da atividade A5. Com estes requisitos a
atividade A5 dever conter um frame com o descritivo resumido do princpio (6) da META, uma relao
de todas as Atividades Selecionadas e um campo onde ser cadastrado o Sujeito (Elemento no Nvel
Individual) de cada Atividade Selecionada.
3.3. Modelo Lgico
Com a realizao da elicitao de requisitos para o desenvolvimento da ferramenta, todos os

procedimentos da META foram analisados e sero implementados na ferramenta. Assim o Projeto do
Software foi modelado de acordo com a Estrutura Hierrquica da Atividade e os Elementos que formam o
Contexto da Atividade observados no quadro 1, os quais so elementos fundamentais na construo da
ferramenta para fazer a ligao das informaes que sero obtidas de um contexto em anlise com a META.
Todos os elementos que fazem parte do contexto da Atividade esto identificados como uma entidade na
representao UML, exceto o histrico no qual entendemos ser uma entidade importante enriquecendo as
informaes levantadas das atividades identificadas. A figura 4 apresenta o comportamento da interao entre
as entidades pertencentes a META. A maioria dos elementos se relaciona com multiplicidade de muitos para
muitos, o que denota o grau de complexidade nas relaes existentes entre estes elementos.
Tcnica Psicolgica
Resultado
Ferramenta Objeto
atua sobre transformado em Codigo Resultado
Cdigo Ferramenta Cdigo Objeto
Resultado
1..n Ferramenta 1..n 1..n Objeto 1..n 1..n
Candidata Selecionada Observaes
1..n
utiliza 1..n
obtm
transforma
1..n 1..n 1
Atividade
Motivo
Sujeito Cdigo Atividade possui
1..n realiza 1..n 1 1..n Cdigo Motivo
Cdigo Sujeito Atividade
Motivo
Nome "Ator" Data / Hora
Observaes
1..n Observaes 1..n
1..n pertence
1..n 1 1..n
0..n
Comunidade Ao
Meta
Codigo Comunidade Codigo Ao possui
Comunidade possui Cdigo Meta
Ao
1 1..n Meta
Observaes
1 possui 0..n
regula 1
1..n 1..n
1..n Responsabilidade 1
Regra Codigo Responsabilidade Histrico
0..n
Cdigo Regra Responsabilidade Cdigo Histrico 1..n
Regra Observaes Histrico Opeao
Observaes Condio
Cd Operao atende Cd Condio
Operao
1..n 1..n Condio
1..n Observaes
tem
Figura 4 Modelagem lgica da ferramenta

4. Concluso
O presente estudo est sendo realizado baseando-se em um novo paradigma, que a organizao dos
requisitos em torno do conceito de atividade. Com a ferramenta em desenvolvimento, espera-se uma
importante contribuio para a Elicitao de Requisitos, e dados extrados atravs de um primeiro contato
com o ambiente em estudo, devero ser armazenados e organizados em um repositrio de dados, os quais
auxiliaro os analistas de requisitos nas fases posteriores da Engenharia de Requisitos e no desenvolvimento
do sistema de software, atravs de consultas e anlise de relatrios gerados pelo cruzamento de informaes.
A elicitao de requisitos realizada muito contribuiu para observaes de pontos chaves, que ainda no
haviam sido analisadas, como por exemplo, a seqncia entre os procedimentos vinculando as etapas da
metodologia. Outro ponto observado na realizao da elicitao foi a ausncia dos elementos no nvel social,
devido a ferramenta ser utilizada por apenas um analista de requisitos, no envolvendo um conjunto de atores
com suas respectivas responsabilidades. Atravs da modelagem das entidades pertencentes META,
observamos os relacionamentos que devero existir, garantindo integridade ferramenta em desenvolvimento.
Para as prximas fases deste trabalho, o desenvolvimento da ferramenta seguir a partir da modelagem das
classes apresentadas na modelagem lgica. Para a validao da ferramenta espera-se aplic-la em situaes
reais de desenvolvimento de software.
[1] M. Cole, and T. Engestrm, A Cultural-Historical Approach to Distributed Cognition. In G. Solomon, ed.,
Distributed Cognition, Cambridge: Cambridge University Press, 1993, pp. 1-47.
[2] K. Kuutti, Activity Theory as a Potential Framework for Human-Computer Interaction. In Context and
Consciousness - Activity Theory and Human- Computer Interaction, MIT Press, 1996, pp. 17-44.
[3] N. A. M. Macedo, J. C. S. P. Leite, Elicit@99 um Prottipo de Ferramenta para a Elicitaco de Requisitos.
WER 99, Workshop en Requerimientos/Workshop de Engenharia de Requisitos II. Buenos Aires, 1999, pp.45-55.
[4] L. E.G. Martins, B. M. Daltrini, An Approach to Software Requirements Elicitation Using the Precepts from
Activity Theory. Proceedings of the Fourteenth IEEE International Conference on Automated Software
Engineering, Florida, 1999.
[5] L. E.G. Martins, Uma Metodologia de Elicitao de Requisitos de Software Baseada na Teoria da Atividade.
Dissertao de Doutorado Unicamp, Campinas, 2001.
[6] G. G. C. Neto, ; A. S. Gomes, P. Tedesco, Aliando Teoria da Atividade e TROPOS na Elicitao de Requisitos
de Ambientes Colaborativos de Aprendizagem. WER 2003, 6th International Workshop on Requeriments
Engineering. Piracicaba, Brazil, November 27-28, 2003 Proceedings, pp.63-77.
[7] R. H. THAYER, M. DORFMAN, Introduction to Tutorial Software Requirements Engineering. In Software
Requirements Engineering, 2 nd Ed., IEEE CS Press, 1997.
[8] J. V. WERTSCH, P. D. RIO, A. ALVAREZ, Estudos Socioculturais da Mente Porto Alegre: ArtMed- 1998.
Integrando BON con Alloy

Pablo Castro
Departamento de Computacion, Universidad Nacional de Ro Cuarto
e-mail:pcastro@dc.exa.unrc.edu.ar
Gabriel Baum
Laboratorio de Investigacion y Formacion en Informatica Avanzada, Universidad Nacional de La Plata
e-mail:gbaum@sol.info.unlp.edu.ar
Resumen
En este articulo proponemos la integracion de dos herramientas utilizadas para el desarrollo de soft-
ware; la primera de ellas es el lenguaje de modelado BON (Business Object Language), cuyas principales
caractersticas son su simpleza e integridad. La segunda es Alloy, un lenguaje logico que permite ciertas ve-
rificaciones automaticas sobre sus especificaciones. La idea principal es utilizar Alloy para agregar a BON
la posibilidad de realizar comprobaciones automaticas durante la etapa de diseno.
1. Introduccion.
Durante la decada del 90 el advenimiento del paradigma de orientacion a objetos, tanto en la industria como
en la academia, dio lugar al surgimiento de diversos lenguajes de diseno y desarrollo para estas tecnologas,
por diversas razones el lenguaje UML (Unified Modelling Language, [5] [3]) fue adoptado por gran parte de
la comunidad como un estandar. Este lenguaje es el resultado de la unificacion de diferentes notaciones, y su
principal proposito es proveer a los desarrolladores un lenguaje que soporte las diferentes etapas del proceso de
desarrollo. Igual que otros lenguajes, UML necesita de los metodos formales para brindar seguridad a los des-
arrolladores en actividades crticas, tales como: disenar componentes de alto riesgo en un sistema, controlar que
los cambios en un diseno no introduzcan inconsistencias, verificar que se satisfagan las especificaciones y evitar
funcionalidades no deseadas. La introduccion de OCL (Object Constraint Language, [10]) en la especificacion
del Unified Modelling Language significo un gran avance en este aspecto, aunque no del todo satisfactorio de-
bido sobre todo a su semantica semi-formal. Diversos autores han realizado interesantes trabajos en cuanto a
la formalizacion del UML y su semantica, pero debido a que esta notacion es muy amplia (9 diagramas y 5
diferentes vistas), estas formalizaciones son de una complejidad importante. En trabajos anteriores ([13] [11]
[12]) hemos definido formalismos sobre UML, con el principal proposito de realizar verificaciones durante el
proceso de desarrollo. Pero, debido a las caractersticas anteriormente citadas, la aplicacion de estos metodos no
es tan directa ni clara como puede desearse. En la proximas secciones mostramos como BON ([1] [9]) permite
una aplicacion transparente de los metodos formales, y principalmente de ciertas tecnicas que permiten realizar
controles rigurosos durante la etapa de desarrollo y reuso de componentes. De la misma forma proponemos
una mejora del metodo de desarrollo asociado a BON mediante la utilizacion de una herramienta basada en un
lenguaje logico llamado Alloy.
2. La Notacion BON.
BON (Business Object Notation) es un lenguaje grafico para especificar y describir sistemas bajo el pa-
radigma de orientacion a objetos, una de sus caractersticas es que no solo provee un lenguaje grafico para
la descripcion de sistemas, tambien posee un proceso recomendado para el desarrollo de software. BON es
extremadamente simple en comparacion a otros lenguajes; solo posee 2 diagramas de modelado, y no permi-
te diferentes vistas de un diseno. Esto ultimo evita las inconsistencias que pueden ser introducidas al existir
distintas descripciones de un mismo componente. En [4] se destacan las siguientes virtudes de BON:
Integridad: existe un mapeo transparente entre el diseno y la implementacion; BON fue disenado para
interactuar con el lenguaje Eiffel, de una manera tal que el traspaso de una clase de diseno a su imple-
mentacion en Eiffel no requiere traduccion.
Reversibilidad: los cambios producidos en una etapa del desarrollo pueden ser automaticamente reflejados
en las etapas anteriores. Por ejemplo, un cambio en una clase de Eiffel es directamente reflejada en
cambios sobre la clase de diseno.
Otra importante caracterstica de este lenguaje es la utilizacion del concepto de diseno por contratos, dicha
tecnica esta basada en los conceptos de pre, pos-condiciones e invariantes -introducidos por Hoare [7] en los
anos 70 - lo cual permite producir software de alta calidad y facilmente mantenible. En ([1],[9]) se pueden
encontrar interesantes introducciones a BON.
3. El lenguaje Alloy.
Alloy ([2]) es un pequeno lenguaje logico que permite formalizar aspectos estructurales de un sistema de
software, as como tambien describir ciertos cambios dinamicos producidos por la ejecucion de operaciones.
Aunque Alloy esta inspirado en el lenguaje Z ([8]), tambien posee algunas caractersticas propias de los lengua-
jes orientados a objetos.
Una descripcion en Alloy se realiza por partes llamadas parrafos (o paragraphs) que pueden clasificarse
en cuatro tipos: signaturas (signatures), funciones (functions), restricciones (facts) y aserciones (assertions).
Las signaturas permiten definir tipos de manera modular y pueden poseer campos que definen relaciones con
otros tipos. Los parrafos fun son formulas parametrizadas que sirven para reflejar el concepto de cambio de
estado, y aunque estos constructores sintacticos sirven para representar el concepto de funcion matematica,
esto no necesariamente debe de ser as. A veces es necesario introducir restricciones a los modelos de nuestras
especificaciones, esto puede ser hecho mediante parrafos Fact, por otra parte, en una especificacion Alloy se
pueden expresar propiedades que el disenador espera que se cumplan, esto se realiza utilizando las formulas
Assert.
Un aspecto relevante de Alloy es que provee herramientas para controlar automaticamente la validez de las
aserciones que conforman una especificacion, es decir, es factible controlar de forma automatica si un diseno
cumple determinadas propiedades deseables. Mas aun, es posible verificar la consistencia de una especificacion
completa, esto es, verificar si existen modelos del sistema a desarrollar. Debido que Alloy es basicamente una
extension de la logica de primer orden y por lo tanto no es decidible, es necesario imponer una cota (o scope en
ingles) a la cantidad de elementos en los dominios semanticos, de manera tal que exista un proceso de decision.
Aunque esta restriccion limita el proceso de verificacion a conjuntos finitos, en la practica la clase de problemas
tratables es de gran interes y amplitud. Una descripcion en detalle de tanto la sintaxis de Alloy como de su
semantica puede encontrarse en [2].
4. La Traduccion BON-Alloy.
La dificultad mas grande en la traduccion radica en que un modelo de clases BON incluye necesariamente
el concepto de estados, y por ende tambien el de cambio de estados. Mientras que una especificacion Alloy
en realidad es una teora logica que carece de esta nocion, dicho problema puede solucionarse realizando un
pequeno truco con las signaturas, que describiremos mas adelante.
Como primer paso vamos a disenar una correspondencia entre las aserciones BON y las formulas Alloy,
el lector puede observar que el cuadro 1 indica la contraparte en Alloy de cada elemento del lenguaje de aser-
ciones del Business Object Language. Por otro lado, la traduccion general de una clase BON a (parte de) una
BON Alloy BON Alloy

for all () all <-> () <=>
exists () some member of () in
and () && not () not
or () || x:T (x es de tipo T) x:T
-> () => x.r (operador dot) x.r
Figura 1: Correspondencia entre smbolos BON y Alloy
especificacion Alloy se realiza de la siguiente forma. Sea C una clase arbitraria descrita mediante textos,
class C feature
a1 : T1 ensure:pos1
..
.
ak : Tk ensure:posk
ak+1 (xk+1 : Tk+1 ) require:prek+1 ensure:posk+1
..
.
an (xn : Tn ) require:pren ensure:posn
invariant: I
end
En donde los ai con i k son busquedas (no producen modificaciones), mientras tanto los aj con k + 1
j n son comandos (cambian el estado del sistema), aqu solo consideramos el caso de comandos con un
solo parametro, el metodo es facilmente extendible para el caso general. Como primer paso de la traduccion
debemos introducir el tipo C en la especificacion, esto se realiza de la siguiente forma:
sig C{}
Si consideramos que las clases T1 , ..., Tk ya han sido introducidas en el modelo Alloy, entonces la nocion de
estado es construida de la siguiente forma:
sig State{
c:set C,
t01 :set T1 ,
..
.,
t0k :set Tk
a1 :C->?T1
..
.
ak :C->?Tk }
Si en la clase C existe un atributo ai de tipo SET [Ti ] entonces en la declaracion de State debe ser elimina-
do el smbolo ? de la expresion ai : C >?Ti . Intuitivamente, un elemento de la signatura State senala la
configuracion de cada relacion y cada objeto en un determinado momento. Es interesante notar que para cada
clase del modelo hay que agregar los campos necesarios en la signatura State, aqu solo nos restringimos a una
clase general. Por otra parte, la nocion de herencia entre dos clases arbitrarias Ti y Tj se refleja por medio del
mecanismo extends de Alloy, esto obliga a agregar restricciones para asegurar la consistencia entre los estados
y la relacion de subtipos, esto es expresado por:
sig Tj extends Ti {}
fact { all s:State | s.t0j in s.t0i }
Por otro lado, las restricciones sobre las busquedas (posi , 1 i k) se expresan mediante parrafos fact; para
este proposito es necesario notar que la aparicion de la expresion ai en las pre-condiciones e invariantes (pos-
condiciones) debe ser reemplazada -en el lenguaje de Alloy- por self.(s.ai ) (self.(s0 .ai )), ya que es necesario
indicar tanto el estado como el objeto de los que se habla. De la misma forma, la ocurrencia de una variable con
una navegacion x.r debe ser reemplazada por una expresion que indique el estado correspondiente, es decir,
x.(s.r) (x.(s0 .r)). De igual manera, la ocurrencia de un tipo ti debe ser reemplazada por s.t0i (s0 .t0i ). En cuanto
la expresion (old x) en las pos-condiciones debe ser cambiada por s.x para indicar el estado anterior de x.
Llamaremos a estas transformaciones junto con las traducciones de la figura 1. Teniendo en cuenta esto, las
restricciones sobre las busquedas se traducen:
fact{ all s:State | self:s.c | (pos1 )[result \ self.(s0 .a1 )] }
..
.
fact{ all s:State | self:s.c | (posk )[result \ self.(s0 .ak )] }
En donde la expresion [result \ self.(s0 .a1 )] significa cambiar cada ocurrencia de result por el termino
self.(s0 .a1 ).
Por otro lado, los comandos son traducidos como formulas parametrizadas que relacionan estados (el estado
anterior y el posterior), la dificultad de la traduccion radica en que ciertas restricciones implcitas en las pos-
condiciones de los comandos deben ser explicitadas en Alloy. Por ejemplo, el unico efecto de un comando en
BON consiste a lo sumo en un cambio de estado del objeto corriente (@) y de algunos de sus parametros;
para expresar esta situacion en Alloy proponemos un abordaje similar al utilizado habitualmente en Z, mas
precisamente, si el objeto corriente es de tipo C, introducimos una formula DeltaC que restringe los cambios
a dicho objeto. La traduccion de un comando arbitrario ai viene dada por:
fun ai (s,s:State,self:s.c,x:s.ti ){
(prei ) && DeltaC(s,s,self)
(posi )
}
En donde la formula DeltaC es expresada de la siguiente forma:

fun DeltaC(s,s:State,self:s.c){
s0 .c0 = s.c0
s0 .t01 = s.t01
..
.
s0 .t0m = s.t01
s0 .a1 = s.a1 - self > T1
..
.
s0 .ak = s.aj - self > Tk
}
Es decir, DeltaC(s,s,self) establece que los unicos cambios entre los estados se realizan sobre el objeto self.
De la misma forma se pueden considerar las formulas DeltaT1 ...DeltaTn , o cualquier combinacion de ellas
(por ejemplo, DeltaT1 T2 (s, s0 , self 1, self 2)).
Para finalizar es necesario traducir el tratamiento de los invariantes de las clases. Un invariante se expresa
mediante una formula fun y un parrafo assert. El invariante I de la clase C, resulta en:
fun I(s:State){
all x:s.c | (I)
}
assert ai HoldsInv{
all s,s:State | self:s.c, x:s.t0i | Inv(s) && ai (s,s,self,x) => Inv(s)
}
El parrafo fun expresa que el invariante debe cumplirse para su argumento s:State. Por otra parte, la formula
assert predica que la operacion ai mantiene el invariante (debera escribirse un assert por cada i). Esta forma de
expresar los invariantes permite utilizar la herramienta de Alloy para verificar su validez, o bien para encontrar
contraejemplos.
5. Verificando Reuso.
Una de las principales ventajas de los lenguajes orientados a objetos es la posibilidad de reusar compo-
nentes, es decir, reutilizar la funcionalidad de una clase, o un conjunto de clases, en un contexto diferente, e
inclusive adaptar los componentes a nuevos requisitos. Pero una de las principales desventajas del reuso es la
posibilidad de introducir inconsistencias en lugares en los que antes no existan. En esta seccion mostramos
como la traduccion a Alloy permite evitar ciertos conflictos que pueden aparecer durante el reuso por medio de
la herencia.
La relacion de herencia es un potente mecanismo de reuso que permite agregar nuevas caractersticas a una
clase, o extenderla, sin tener que cambiar los clientes que usan la clase, ni sus aspectos basicos. En la notacion
BON cuando existe una relacion de herencia entre dos clases Ci y Cj (Ci es subclase de Cj ) las aserciones
de Cj son heredadas por Ci . Formalmente, esto quiere decir que al invariante de Cj se le agrega, por medio
de una conjuncion, el invariante de Ci . Este mecanismo puede convertir al invariante de Cj en una asercion no
satisfacible, es decir, en una contradiccion. Una forma de detectar este conflicto es formalizando la relacion de
herencia mediante Alloy y utilizar la herramienta para verificar la formalizacion . Ilustraremos esto por medio
de un ejemplo, la siguiente es la descripcion de la clase MICROEMPRESA.
Class MICROEMPRESA
inherit
EMPRESA
feature
CUIT:INT
invariant
contrata.count < 5
end
Debido a la herencia el invariante de la clase MICROEMPRESA es:

e : Contrata e.trabaja en = @ contrata.count < 5
para agregar esta clase en la traduccion de la figura ?? debemos incorporar la signatura M icroempresa y los
cambios correspondientes en State, ademas de introducir la siguiente formula assert:
fun InvMicroEmpresa(s:State){
InvEmpr(s)
all e:s.microempresa | # e.(s.contrata) < 5
}
de esta forma podemos verificar la satisfacibilidad del invariante de MICROEMPRESA mediante el comando
run InvMicroEmpresa for 2 , lo cual nos devuelve el modelo de la figura 2. En otras palabras, podemos
asegurar que la introduccion del nuevo invariante no tiene conflictos con el invariante heredado.
Otro requisito de BON sobre la herencia es que las clases descendientes solo pueden refinar las aserciones de
los comandos, es decir, las pre-condiciones solo pueden ser debilitadas y lo pos-condiciones solo fortalecidas.
La pregunta que naturalmente surge es Como saber que las condiciones de refinamiento se cumplen?. Hay dos
posibilidades, la primera es utilizar un calculo del estilo wp ([6]), lo cual puede costar tiempo y dedicacion a los
desarrolladores. La segunda es utilizar una herramienta del estilo de Alloy; por ejemplo la siguiente version de
MICROEMPRESA es una subclase de EMPRESA que redefine el comando Despedir.
Figura 2: Modelo que satisface el invariante de MICROEMPRESA
Class MICROEMPRESA
inherit
EMPRESA
redefine Despedir end
feature
CUIT:INT
Despedir(e:Empleado)
require: e in contrata && contrata.count > 1
ensure: not (e in contrata) and (for all x member of Contrata it holds not(x=e) and x member of (old Contrata)) and
CUIT = (old CUIT)
invariant
contrata.count < 5
end
es interesante notar que la pre-condicion y pos-condicion de Despedir pueden expresarse en Alloy de la si-
guiente forma:
fun pre(s:State, e:s.empleado){ fun pre(s:State, e:s.empleado){

e in self.(s.contrata) e in self.(s.contrata) && #(s.contrata) > 1
} }
fun pos(s,s:State, self:s.empresa, e:s.empleado){ fun pos(s:State, self:s.empresa, e:s.empleado){
e in self.(s.contrata) && #(s.contrata) > 1 x !in self.(s.contrata)
} all e:self.(s.contrata)| !(e=x) && e in self.(s.contrata)
s.CUIT = s.CUIT }
en donde las formulas pre y pos son las pre y pos-condiciones del comando Despedir de la clase EMPRESA,
en tanto pre y pos son las pre y pos-condiciones de la clase MICROEMPRESA. La obligacion de prueba
sobre las aserciones puede expresarse mediante parrafos assert:
assert WeakPre{
all s:State | all self:s.microempresa, e:s.empleado | pre(s,self,e) => pre(s,self,e)
}
assert StrenghtPos{
all s,s:State | all self:s.microempresa, e:s.empleado | pos(s,s,self,e) => pos(s,s,self,e)
}
ahora podemos verificar la aserciones mediante los comandos check WeakPre for 3 y check StrenghtPos
for 3 , la ejecucion del ultimo retorna un resultado satisfactorio, mientras tanto el primer comando produce
un contraejemplo de la asercion WeakPre, esto significa que no se cumple el requisito de debilitamiento de
pre-condiciones.
Aunque el metodo aqu mostrado para verificar refinamientos no es determinante como un calculo tiene la
gran ventaja de ser automatico, es decir, tiene un costo bajo para los desarrolladores. Por otra parte, si bien el
analisis de las especificaciones se realiza para pequenas cantidades de atomos, los desarrolladores pueden elegir
un scope lo suficientemente grande como para asegurar un alto grado de confianza sobre sus sistemas.
6. Conclusiones.
En este trabajo mostramos una traduccion general de disenos BON al lenguaje logico Alloy, la principal
ventaja del metodo es su claridad; las formulas de BON se traducen directamente a Alloy, mientras que las
traducciones sobre otros lenguajes (por ejemplo, OCL) son oscuras y le agregan dificultades al proceso de
desarrollo. Por otra parte, BON posee una semantica bien definida lo que permite volcar los diferentes conceptos
de su lenguaje de una forma transparente en Alloy.
Otra de las grandes ventajas de BON es la doctrina de diseno por contratos, que permite desarrollar sistemas
confiables y posibilita las verificaciones formales sobre sus componentes. En las diferentes secciones del articulo
mostramos como la traduccion a Alloy permite:
Controlar la consistencia de los componentes de los disenos en BON.
Verificar las obligaciones de prueba establecidas por los contratos.
Controlar el reuso de componentes, para evitar la introduccion de inconsistencias y la preservacion de
propiedades.
Es evidente que la conjuncion de las dos herramientas provee un interesante framework a los desarrolladores,
por una parte, se pueden disenar los sistemas de una manera rigurosa y simple, y por otra se pueden verificar
diferentes propiedades del sistema de una forma automatica. Sin embargo, estas ideas dejan importantes puertas
abiertas.
Referencias
[1] B.Meyer. Object-Oriented Software Construction. Second Edition, Prentice-Hall, 1997.
[2] D.Jackson. A Micromodularity Mechanism. avalaible at http//:sdg.lcs.mit.edu/dng/publications.
[3] Hans-Erik Eriksson and Magnus Penker. UML Toolkit. John Wiley & Sons, 1998.
[4] Richard F.Paige and Jonathan S.Ostroff. A Comparation of the Business Object Notation and the Unified
Modelling Language. In proceedings of OOPSLA 91, 1999.
[5] J.Rumbaugh G.Booch and I.Jacobson. The Unified Modeling Language User Guide. Addison-Wesley,
1999.
[6] David Gries. The Science of Programming. Springer-Verlag, New York, 1981.
[7] C.A.R. Hoare. An Axiomatic Basis for Computer Programming. Communications of the ACM 12, 576-
580, October 1969.
[8] J.M.Spivey. The Z Notation. Springer, 1997.
[9] Kim Walden and Jean-Mark Nerson. Seamless Object-Oriented Software Architecture, Analysis and De-
sign of Reliable Systems. Prentice-Hall, 1994.
[10] J.B Warmer and A.G.Kepple. The Object Constraint Language: Precise Modeling with Modeling.
Addison-Wesley, 1998.
[11] Pablo Castro y Gabriel Baum. Utilizando Contratos de Reuso con Alloy. Anales del CACIC 2001, 2001.
[12] Pablo Castro y Gabriel Baum. Maquinas Evolutivas. Anales del CACIC 2002, 2002.
[13] Pablo Castro y Gabriel Baum. Una Formalizacion del Proceso de Desarrollo. Anales del CLEI 2003, 2003.
Measuring component adaptation?
Antonio Brogi1 , Carlos Canal2 , and Ernesto Pimentel2

1
Department of Computer Science, University of Pisa, Italy
brogi@di.unipi.it
2
Department of Computer Science, University of Malaga, Spain
{canal, ernesto}@lcc.uma.es
Abstract
Adapting heterogeneous software components that present mismatching interaction behaviour is one of the crucial
problems in Component-Based Software Engineering. The process of component adaptation can be synthesized by a trans-
formation from an initial specification (of the requested adaptation) to a revised specification (expressing the actual adap-
tation that will be featured by the deployed adaptor component). An important capability in this context is hence to be
able to evaluate to which extent an adaptor proposal satisfies the initially requested adaptation. The aim of this paper is
precisely to develop different metrics that can be employed to this end. Such metrics can be fruitfully employed both to
assess the acceptability of an adaptation proposal, and to compare different adaptation solutions proposed by different
servers.
1 Introduction
One of the general objective of coordination models is to support the successful interoperation of heteroge-
neous software elements that may present mismatching interaction behaviour [10]. In the area of Component-
Based Software Engineering, the problem of component adaptation is widely recognised to be one of the
crucial issues for the development of a true component marketplace and for component deployment in gen-
eral [4, 5]. Available component-oriented platforms address software interoperability at the signature level by
means of Interface Description Languages (IDLs), a sort of lingua franca for specifying the functionality of-
fered by heterogeneous components possibly developed in different languages. While IDL interfaces allow to
overcome signature mismatches, there is no guarantee that the components will suitably interoperate, as mis-
matches may also occur at the protocol level, due to differences in the interaction behaviour of the components
involved [15].
The need for component adaptation is also motivated by the ever-increasing attention devoted to developing
extensively interacting distributed systems, consisting of large numbers of heterogeneous components. Most
importantly, the ability of dynamically constructing software adaptors will be a must for the next generation of
nomadic applications consisting of wireless mobile computing devices that will need to require services from
different hosts at different times.
In our previous work [2, 3], we have developed a formal methodology for component adaptation that
supports the successful interoperation of heterogeneous components presenting mismatching interaction be-
haviour. The main ingredients of the methodology can be summarised as follows:
Component interfaces. IDL interfaces are extended with a formal description of the behaviour of compo-
nents, which explicitly declares the interaction protocol followed by a component.
Adaptor specification. Adaptor specifications are simply expressed by a set of correspondences between
actions of two components. The distinguishing aspect of the notation used is that it yields a high-level,
partial specification of the adaptor.
?
This work has been accepted for presentation at COORDINATION 2004, Lecture Notes in Computer Science, 2949.
Adaptor derivation. A concrete adaptor is fully automatically generated, given its partial specification and
the interfaces of two components, by exhaustively trying to build a component which satisfies the given
specification.
The methodology has proven to succeed in a number of diverse situations [2], where a suitable adaptor is
generated to support the successful interoperation of heterogeneous components presenting mismatching in-
teraction behaviours. The separation of adaptor specification and adaptor derivation permits the automation
of the error-prone, time-consuming task of constructing a detailed implementation of a correct adaptor, thus
notably simplifying the task of the (human) software developer. One of the distinguishing features of the
methodology is the simplicity of the notation employed to express adaptor specifications. Indeed the desired
adaptation is simply expressed by defining a set of (possibly non-deterministic) correspondences between the
actions of the two components.
Consider for instance a typical scenario where a client component wishes to use some of the services
offered by a server. (For instance, a client wishing to access a remote system via the network, or a mobile
client getting into the vicinity of a stationary server.) The client will ask for the server interface, and then
submit its service request in the form of an adaptor specification (together with its own interface). The server
will run the adaptor derivation procedure to determine whether a suitable adaptor can be generated to satisfy
the client request. If the client request can be satisfied, the server will notify the client by presenting a (possibly
modified) adaptor specification which states the type of adaptation that will be effectively featured. The client
will then decide whether to accept the adaptation proposal or not. (In the latter case the client may decide to
continue the trading process by submitting a revised adaptor specification, or to address another server.)
Expressing adaptation trading by means of adaptor specification features two main advantages:
Efficiency. Clients and servers exchange light-weighted adaptor specifications rather than component code.
Besides contributing to the efficiency of communications, this notably simplifies the trading process, when
the client has to analyse the adaptation proposed by the server.
Non-disclosure. The server does not have to present the actual adaptor component in its full details, thus
communicating only the what of the offered adaptation rather than the how.
Summing up, the process of component adaptation can be synthesized by an adaptor specification S,
representing the client request, and by a (possibly modified) adaptor specification C, representing the actual
adaptation offered by the server. The specification C is then interpreted as a contract guaranteeing that: (1)
The client will be able to interoperate successfully with the adaptor (viz., the client will not get stuck), and (2)
all the client actions occurring in C will be effectively executable by the client.
An important issue in this context is hence how to evaluate to which extent a contract proposal satisfies the
initial specification defining the requested adaptation. The aim of this paper is precisely to develop different
metrics for component adaptation. Such metrics can be fruitfully employed both to assess the acceptability of
an adaptation proposal and to compare different adaptations proposed by different servers.
The rest of the paper is organised as follows. Section 2 recalls the key aspects of the methodology for
component adaptation developed in [2, 3]. Section 3 is devoted to present several metrics to assess the ac-
ceptability of an adaptation proposal. Such metrics are then extended in Section 4 to deal with additional
quantitative information. Finally, some concluding remarks are drawn in Section 5.
2 Component adaptation
Throughout this paper we will use an example concerning a Video-on-Demand system (VoD), simplified to
some extent. The VoD is a Web service providing access to remote clients to a repository of movies in video
format.
When interacting with a client, the VoD executes clients instructions, represented by the different input
messages the VoD is able to react to (message names are in italics in the description that follows). For instance,
clients may search the VoD catalog for a movie, or ask the service which is the premiere of the day. Once a
certain movie is selected, the client may decide to preview it for a few minutes, or to view it all. In either case,
the client must indicate whether it wants to play the movie (which will be shown by a viewer), or to record
it on its disk. During video transmission, chunks of data are sent by the server by means of repeated stream
output messages, while the end of the transmission is marked with an eof output message.
Following [2], component interfaces are extended with a description of the interactive behaviour of com-
ponents. Suppose that the behaviour of the VoD server during the video data transmission phase is described
by a process algebra term of the form:
Server = stream!(y). Server + . eof !(). 0
where is an internal silent action.

Consider now a simple Client that (repeatedly) receives data by performing an input action data, and
which may decide autonomously to abort the data transmission by performing an output action abort:
Client = data?(x). Client + . abort!(). 0
It is worth observing that the mismatch between the two components above is not limited to signature dif-
ferences (viz., the different names of actions employed, such as stream in the server and data in the client),
but it also involves behavioral differences, in particular the way in which either component may close the
communication unexpectedly.
2.1 Hard adaptation
The objective of software adaptation is to deploy a software component, called adaptor, capable of acting
as a component-in-the-middle between two components and of supporting their successful interoperation.
Following our approach, a concrete adaptor will be automatically generated starting from the interfaces of
the components and from a specification of the adaptor itself. Such a specification simply consists of rules
establishing correspondences between actions of the two components. More precisely, an adaptor specification
is a set of rules of the form:
a1 , . . . , am b1 , . . . , bn ;
where ai and bj are the input or output actions performed by the components to be adapted. By convention,
given a specification S, actions on the left-hand side of rules refer to one of the components to be adapted (in
the examples here, the client), and we will refer to them by [S]cl , while actions on the right-hand side of rules
refer to the other component (the server), and will be denoted by [S]sr . To simplify notation, and without loss
of generality, we assume that the sets of client and server actions are disjoint.
For instance, the adaptation required for the video transmission between the server and the client can be
naturally expressed by the specification:

data?(u) stream!(u) ;
abort!() stream!(u) ;

S1 =

abort!() ;
eof !() ;

The first rule in S1 states that the input action data? in the client matches or corresponds to the output
action stream! in the server. This same stream! action is also matched to clients abort! in the second rule,
stating that the client may abort the transmission even when the server is trying to send video data. Thus,
combining both rules we have that the action stream! may correspond non-deterministically to either data?
or abort!, depending on the evolution of the client. In the third and fourth rules, actions abort! and eof! are
represented without a corresponding action in the other side. For instance, the fourth rule of S1 indicates that
the execution of an eof! server action does not necessarily call for a corresponding client action. Notice that
rules in an adaptor specification may establish one-to-one, one-to-many, and many-to-many correspondences
among actions of the two components. They can also be employed to express asymmetries naturally, typically
when the execution of an action in one of the component may not require a corresponding action to be executed
by the other component.
Given an adaptor specification and the interfaces of two components, a fully automated procedure [2]
returns non-deterministically one of the possible adaptors components (if any) that satisfy the specification,
and that let the two components interoperate successfully. For instance, for the specification S1 above the
generation procedure may return the adaptor:
A = stream?(u). (data!(u). A + abort?(). eof ?(). 0)

+
eof ?(). abort?(). 0
In this example a full adaptation is achieved, and hence the server will return the submitted specification S1 as
the contract proposal. However, in general the server may be able to offer the client only a partial adaptation,
namely a contract C which is a proper subset of the submitted specification S.
To illustrate the idea, let us develop further our example of the VoD system. Suppose now that the client
uses different action names for accessing the service than those considered by the server (again action names
are in italics in the description that follows). For instance, the client wishes to perform its info action either
for requesting information on a particular movie (by indicating its title), or for asking the service to suggest a
movie (by using in this case the empty string as parameter), and its watch and store actions to play and record a
movie, respectively. Hence the client submits the adaptor specification S2 below, establishing correspondences
with the previously described server actions1 :

inf o!(t) search?(t) ;
inf o!(00 00 ) premiere?() ;

S2 =

watch!(m) view?(m), play?() ;
store!(m) view?(m), record?() ;

Let us suppose that as a reply to the specification S2 , the client receives from the server the following
contract CA :
CA = inf o!(t) search?(t) ;
The straightforward reading of the contract proposal CA is that while the server commits to let the client search
the movies database, for some reason it will not feature the adaptation required to let the client watch or store
such movies. (For instance, the server might decide to feature a partial adaptation even if a full adaptation
would be feasible, in order to balance its current workload or for other internal service policies.)
Hence, given an adaptor specification S, the type of component adaptation that we have described so far:
either it yields a (possibly partial) adaptation proposal C (where C is a subset of S),

or it fails when no adaptation is possible.
The sole possibility of removing some rules from the initial specification obviously limits the success
possibilities of yielding a (partial) adaptation. Indeed there are many situations in which more flexible ways of
weakening the initial specification may lead to deploying a suitable partial adaptor, as we shall discuss in the
next section.
1
For the sake of simplicity, we omit here the correspondences concerning the data transfer actions (data, abort, stream,
eof) already described in specification S1 .
2.2 Soft adaptation
The methodology for hard adaptation described in [2] has been extended in [3] to feature forms of soft adap-
tation. One of the key notions introduced in [3] is the notion of subservice. Intuitively speaking, a subservice
is a kind of surrogate of a service, which features only a limited part of such service. Formally, subservices are
specified by defining a partial order @ over the actions of a component:
bj @ bi
indicating that the service bj is a subservice of bi .

It is important to observe that adding subservice declarations to component interfaces paves the way for
more flexible forms of adaptation. Indeed, subservice declarations support a flexible configuration of compo-
nents in view of their (dynamic) behaviour, without having to modify or to make more complex the protocol
specification of component interfaces.
As one may expect, the introduction of subservices increases notably the possibilities of successful adapta-
tions, as an initial specification can be suitably weakened by providing (when needed) subservices in place of
the required services. A direct consequence of enabling soft adaptation is that a client that submits an adaptor
specification may now receive a rather different contract proposal, in which the server may declare its intention
both to feature only some of the services requested and to subservice some of them. Hence, the process of soft
adaptor generation in presence of subservice declarations can be described as follows.
1. The initial adaptor specification S is actually interpreted as the specification S obtained by expanding
every rule r in S with a new set subs(r) of correspondence rules that are obtained by replacing one or
more (server) actions in r with a corresponding subservice. That is, S = S subs(S), where subs(S) =
rS subs(r).
2. The process of adaptor construction generates (if possible) a partial adaptor that satisfies a subset C of the
extended specification S .
(Notice that while both C and S are subsets of S , in general C is not a subset of S since possibly some service
requests have been subserviced.)
For instance, in the Video-on-Demand service, offering a clip preview of a movie can be considered a typi-
cal subservice of offering the whole movie, while starting to view a movie could be considered as a subservice
of downloading it into the hard disk of the client. These subservice definition are expressed as follows:
preview?(m) @ view?(m) ;
play?() @ record?() ;
The previous adaptor specification S2 is hence actually interpreted by the server as the following expanded
specification S2 :

inf o search ;

inf o premiere ;

inf o search ; watch view, play ;

inf o premiere ; watch preview, play ;

S2 = S2 =

watch view, play ;
store view, record ;

store view, record ; store view, play ;

store preview, record ;

store preview, play ;

where for simplicity we have omitted signs and parameters in the actions of both components.
Depending both on the actual protocols of the components, and on the servers policy, the server may return
different contract proposals, for instance:

inf o search ;

watch view, play ;

CB =

watch preview, play ;
store preview, record ;

where the contract proposal CB indicates that some watch requests will be adapted into previews, while all
store requests will be adapted into previews.
As in the case of the partial adaptation described in the previous section, it is worth noting that a server
may decide to subservice some of the client requests even if this is not strictly necessary in order to achieve a
successful interoperation of the two components. Hence, the contract proposal returned may present relevant
differences with respect to the original client requests, and some additional information would be of help for
deciding whether or not to accept a proposed adaptation. Thus, together with the contract proposal, the server
should provide the client with some explanation of why some requests have not been satisfied, such as for
instance temporarily unavailable service, insufficient access rights, or unsolved protocol mismatch, as
discussed in [3].
However, this kind of qualitative information is usually insufficient and most of the times the client needs
a quantitative estimation on how close to the original request is a certain contract proposal with respect to
an alternative one (either provided by the same server or by a different one). The main aim of this work is
exploring different possibilities for achieving a quantitative measure of adaptation.
3 Measuring adaptation
In this section we develop two initial metrics to compare an initial specification S with a contract proposal C.
3.1 Rule satisfaction

A first way to measure the distance between an initial specification S and a contract proposal C is to inspect
how many rules of S are satisfied by C.
For the case of hard adaptation, where C is a subset of S, one may simply count the number of correspon-
dence rules of S that are contained in C, that is consider the ratio:
]C
]S
where ] X denotes the number of rules in a specification X.
However, the above ratio does not make much sense in the context of soft adaptation, where in general the
rules of C are not a subset of the rules of S. Indeed, as we have already mentioned, both S and C are subsets
of S , but C may even contain more rules than S.
In the general context of soft adaptation, one should measure how many rules of S are satisfied by C,
either because they are included verbatim in C or because a subserviced version of them is included in C.
More precisely, we can single out three possible cases for each rule r in S:
1. r is fully satisfied by C. Namely, r belongs to C, but no subserviced version of r belongs to C. Formally:
r C subs(r) C =
2. r is partly satisfied by C with some subservicing. Namely, some subserviced version of r belongs to C.
Formally:
subs(r) C 6=
3. r is not satisfied by C. Namely, neither r nor any subserviced version of r belongs to C. Formally:
r 6 C subs(r) C =
Based on the above observation, we define the metric m1 (S, C) which, given a specification S and a
contract C, returns two values. The first value indicates the percentage of rules of S that are fully satisfied by
the contract proposal C. The second value indicates the percentage of rules of S that are partly satisfied, that
is subserviced, by the contract proposal C. Formally:

] {r S C | subs(r) C = } ] {r S | subs(r) C 6= }
m1 (S, C) = ,
]S ]S
For instance, consider again the specification S2 and the contract CB already presented, together with the
new contract proposal CC :
inf o search ;
CC = watch view, play ;
store view, play ;

We have that m1 (S2 , CB ) = 41 , 24 , while m1 (S2 , CC ) = 42 , 14 , from which we could deduce that the

contract proposal CB is worse than CC with respect to the specification S2 , since CB presents less rules fully
satisfied and more subserviced rules than CC .
3.2 Action enabling
The simple inspection of the percentage of rules satisfied by a contract proposal does not however deal ad-
equately with specifications that contain nondeterministic correspondence rules. For instance, consider once
more the specification S2 and the contract CB already presented, together with the new contract proposal CD :

inf o search ;
CD = inf o premiere ;
watch preview, play ;

that, according to metric m1 , m1 (S2 , CB ) = 41 , 24 , while on the other hand m1 (S2 , CD ) =

We

2 observe
1

4 , 4 , from which we should conclude that the contract proposal CD is closer to the specification S2 than
CB , since in CD the number or rules of S2 fully satisfied are greater than in CB . However, the adaptor
corresponding to the new contract CD will allow the client to perform a smaller number of actions than CB
(viz., action store is not present in CD ). Hence, a finer metric should consider the percentage of client actions
(instead of rules) whose execution will be actually enabled by the adaptor proposal. Again, for the case of hard
adaptation, one may simply consider the ratio between the number of client actions occurring in C and in S,
formally:
] [C]cl
] [S]cl
However, the above ratio is a bit coarse in the general context of soft adaptation, since it does not consider
the subservicing possibly operated by the adaptor. More precisely, we can single out three possible cases for a
client action a occurring in S (viz., for each a [S]cl ):
1. a is fully enabled by C. Namely the execution of a is enabled by C without introducing subservicing, that
is, a only occurs in rules of C that were in S too. Formally:
a [C]cl a 6 [C subs(S)]cl
2. a is partly enabled by C with some subservicing. Namely the execution of a is enabled by C via some
subservicing, that is, a occurs in some subserviced version of rules of S. Formally:
a [C subs(S)]cl
3. a is not enabled by C. Namely a does not occur in (any rule of) C. Formally:
a 6 [C]cl
Based on the above observation, we define a new metric m2 (S, C) which, given a specification S and a
contract C, returns two values. The first value indicates the percentage of client actions in S that are fully
enabled by C. The second value indicates the percentage of client actions in S that are partly enabled by C.
Formally:
] ([C]cl \[C subs(S)]cl ) ] [C subs(S)]cl
m2 (S, C) = ,
] [S]cl ] [S]cl
For instance, considering again the specification S 2 along with the contracts CB and CD , we observe
that m2 (S2 , CB ) = 13 , 23 while m2 (S2 , CD ) = 13 , 13 , from which we should now conclude that CB in

which all client actions are being adapted represents a better adaptation than CD in which no adaptation
for action store is featured. In other words, if we only take into account the number of (partially) satisfied rules
(as given by metric m1 ), the contract proposal CD presents a greater level of satisfaction for the specification
S2 . Nevertheless, from an intuitive point of view, CB seems closer to S2 than CD , which is correctly reflected
by metric m2 .
4 Adding quantitative information

So far we have assumed that contract specifications are plain sets of correspondence rules, some of which may
have been introduced because of subservicing. We now consider the case in which contract specifications are
enriched so as to contain additional quantitative information denoting usage percentage of the individual rules
during the construction of the adaptor. For instance, consider again the specification S2 already presented,
together with the following annotated version of the contract proposal CB :

inf o search : 1;
watch view, play : .8;

CB 0 =

watch preview, play : .2;
store preview, record : 1;

The intended meaning of the numbers annotated on the right of the correspondence rules is to provide an
estimation of the degree of subservicing employed in the adaptation. For instance, the first rule of CB 0 indicates
that the first rule of S2 is kept as is in CB , i.e., without subservicing it (while the second rule of S2 has not
been used at all during the construction of the adaptor). On the other hand, the second and third rules of CB 0
state that the third rule of S2 has been used 80% of the times during the adaptor construction to match client
action watch, while its subserviced version has been employed the remaining 20% of the times. Finally, the
fourth rule of CB 0 states that the fourth rule of S2 has been always subserviced.
Hence, we can refine metric m1 so as to measure the percentage with which the rules of S are satisfied
without or with subservicing by C:
*P P +
rS {p | hr : pi C} rsubs(S) {p | hr : pi C}
m3 (S, C) = ,
]S ]S

1.8 1.2
For instance, for the contract CB 0 above we have that m3 (S2 , CB 0 ) = 4 , 4 , which offers a more
precise information on the adaptation proposal than that provided by m1 (S2 , CB ) = 41 , 24 for the non-

annotated version CB of the same contract proposal.

The metric m3 (S, C) above allows to exploit the information provided by annotated contracts in order to
measure the percentage of overall subservicing of the original specifications. However, subservices may not
be all the same for clients. Typically, a client may consider a subservice bj to be an acceptable surrogate of
bi , while a different subservice bk of bi may not be of interest or valuable for the client. Therefore, a finer
metric should try to combine the information provided by an annotated contract together with an assessment
of subservices performed by the client.
We hence consider that a client may wish to set its own criteria to assess the quality of a soft adaptor
obtained in response to its request for adaptation. As soft adaptors employ subservicing, clients may wish to
assess how much the employed subservicing will affect the quality of the adaptation proposed. For instance,
in our VoD system, the client may wish to weight the subservice relation presented by the server on the basis
of its own assessment. For instance, the client may annotate the above subservice relation as follows:
preview @.5 view ;
play @1 record ;
where the first annotation (@.5 ) indicates that the client will be half satisfied if the preview subservice will be
provided in place of the view service. The second annotation (@1 ) instead indicates that the subservicing of
record with play is not relevant for the client. Annotations must maintain some kind of consistency. In fact,
they should satisfy the following property:
a @u b b @v c implies a @uv c
which ensures that @ is also a partial order.

The annotated subservice relation can be lifted to rules as follows:
mina0 [r0 ]sr ,a[r]sr {x | a0 @x a} if r0 subs(r)

r0 @v r iff v =
1 if r0 = r
We can hence refine metric m3 to take into account the subservicing assessment made by the client:
{p v | hr0 : pi C r0 @v r}
P
m4 (S, C) = rS
]S
For instance, for the above specification S2 and the annotated contract CB 0 , we have that m4 (S2 , CB 0 ) =
(1 1 + .8 1 + .2 .5 + 1 .5) 4 = .6, which can be considered as a measure of the optimality of the
contract for the client, i.e., of the degree of satisfaction achieved during adaptor construction.
The introduction of quantitative annotations (both in contracts and in subservice relations) paves the way
for a more precise assessment of the actions or services whose execution will be enabled by an adaptor pro-
posal. However, such an assessment needs to consider the actual interaction protocols followed by the compo-
nents and the adaptor. Consider for instance the following specification S3 , and the contract proposal CE :

watch view, play : .5;
S3 = watch view, play ; CE =
watch preview, play : .5;
where as before preview @.5 view. The quantitative annotations in CE denote the usage percentage of the
rules during the construction of the adaptor, resulting in a satisfaction measurement m4 (S3 , CE ) = (1 .5 +
.5 .5) 1 = .75.
However, let us suppose now that the contract CE corresponds for instance to the actual adaptor:
A = watch. ( preview. A + view. A )
It is easy to observe that the real percentage of subservicing employed by the server to enable the execution
of client actions depends on the actual protocols of the components involved (in the example, the frequency
with which the server drives the adaptor to perform action preview instead of view). Furthermore, a simple
inspection of the protocols of the two components may not suffice. Suppose for instance that the protocol of
the server is:
Server = preview. Server + view. Server
From that, we cannot conclude that the adaptor will perform the actions preview and view with the same
frequency, since the choice between the two branches of the alternative may depend on internal policies of the
Server not represented at the protocol level. Hence, the amount of times that action watch will be subserviced
when using the adaptor A above will not depend merely on the protocol describing the adaptor, but mainly in
the actual behaviour of the Server and the Client which determines the frequency these components present
the actions complementary to those offered by the adaptor.
Hence, a quantitative assessment of the actual, possibly subserviced, execution of client actions should
take into account also probabilistic information associated with protocols (e.g., see [12]). For instance a prob-
abilistic definition of the previous process Server, as:
Server = preview. Server .9 +.1 view. Server
indicates that the left branch of the alternative will be executed with probability .9. Hence, most of the times
the subservice preview will be offered to the client instead of the service view originally requested. This
information should be taken into account in order to refine metrics like m3 and m4 in order to yield a more
precise information on the adaptation proposal.
5 Concluding remarks
When heterogeneous software components have to be combined in order to construct complex systems, one
of the crucial problems to be solved is the mismatching of interaction behaviours they may present. To the
best of our knowledge, in spite of the relevance of this topic, not many efforts have been devoted to develop
well-founded component adaptation theories.
A number of practice-oriented studies have analysed different issues encountered in (manually) adapting a
third-party component for using it in a (possibly radically) different context (e.g., see [8, 9, 16]). The problem
of software adaptation from a more formal point of view was specifically addressed by the work of Yellin
and Strom [18], which constitutes the starting point for our work. They used finite state grammars to spec-
ify interaction protocols between components, to define a relation of compatibility, and to address the task
of (semi)automatic adaptor generation. The main advantage of finite state machines is that their simplicity
supports an efficient verification of protocol compatibility. However, such a simplicity is a severe expressive-
ness bound for modelling complex open distributed systems. On the contrary, process algebras feature more
expressive descriptions of protocols and enable more sophisticated analysis of concurrent systems. For this
reason, several authors propose their use for the specification of component interfaces and for the analysis of
component compatibility [1, 6]. A technique for automatically synthetising connectors is discussed in [11] by
focussing on avoiding deadlocks caused by mismatching coordination policies among COM/DCOM compo-
nents that present compatible interfaces. A different approach is that of [17], where software composition is
addressed in the context of category theory. The connection between components is obtained by superposition,
defining a morphism between actions in both components. Morphisms are similar to our specifications, though
the kind of adaptation provided is more restrictive, limiting adaptation to a kind of name translation similar to
that provided by IDL signature descriptions. Finally, in [14], type systems and finite state automata are used
for describing component interfaces, and a game-theoretic framework is defined for the automatic generation
of adaptors avoiding component deadlock. Their proposal is quite appealing, although it shares most of the
limitations of those based on finite automata.
Following the above comparison with significant related works in the literature, we argue that our ap-
proach [2, 3] facilitates the adaptation of components by combining expressiveness and effectiveness in a
formally grounded methodology. Our proposal is based on the idea of deriving a concrete adaptor, given its
specification and the behaviour description of the two components to be adapted. As full adaptation is not al-
ways possible (e.g., because behavioral protocols cannot be matched, or because the requested services are not
fully available), soft adaptation features a flexible way of adapting components, and calls for mechanisms
to assess the appropriateness of proposed adaptors.
Component adaptation is also a relevant issue in the context of mobile computation, where nomadic ap-
plications (client components) will need to require services from different hosts (server components). Again,
the behaviours mismatching can be solved by adapting both client and server protocols, considering an initial
adaptation (given by a set of rules) requested by the client. If the server cannot fully satisfy these initial re-
quests, it could offer an alternative (partial) adaptation (given by a set of possibly revised rules) , whose
appropriateness should be evaluated by using the previously mentioned mechanisms.
If the references to formal adaptation of software components are scarce in the literature, those trying
to address a measurement of the results obtained are probably non-existing. There are quite a few proposals
for measuring the quality of component-based systems, usually dealing with measuring the adequacy of the
components in a repository w.r.t. the particular needs of a software developer (see for instance [7] for catching
a glimpse on the state-of-the-art in this field). Although there are works, as [13], dealing with measuring the
semantic distance between functional specifications on a formally based setting, most of the proposals in the
component-based field deal with component specification and metrics using long lists of mostly qualitative
attributes. Some of these metrics are proposed as an estimation of the effort required for adapting (manually)
software components.
At the best of our knowledge, this work is the first proposal addressing the measurement of the (automatic)
process of software adaptation and of its result (the adaptor). In this paper, we have defined a set of behaviour-
oriented metrics which feature different ways of measuring the distance between an adaptor request and the
adaptor which will be effectively deployed. Thus, m1 gives a measure based on the satisfied adaptation rules,
whereas m2 defines a metric where enabled services are taken into account. On the other hand, in the previous
mobile scenario, metrics m3 and m4 take into account additional quantitative information provided by the
server and client components, respectively.
It is worth noting that the metrics m1 , m2 , and m3 can be computed directly by server components (they
only need the client protocol specification and the initial adaptor request). Thus, servers may ultimately send
back to the client only metric values rather than the adaptor proposal specification, hence increasing further
the non-disclosure of information.
Our plans for future work include integrating the adaptation methodology in existing CBSE development
environments, so as to allow experimenting and assessing the methodology on large numbers of available
components. Another interesting direction for future work is to extend the adaptation methodology to deal
with probabilistic protocols, as suggested at the end of Section 4.
References
1. R. Allen and D. Garlan. A formal basis for architectural connection. ACM Transactions on Software Engineering and
Methodology, 6(3):21349, 1997.
2. A. Bracciali, A. Brogi, and C. Canal. A formal approach to component adaptation. Journal of Systems and Soft-
ware, 65(3), 2003. A preliminary version of this paper was published in COORDINATION 2002: Fifth International
Conference on Coordination Models and Languages, LNCS 2315, pages 8895. Springer, 2002.
3. A. Brogi, C. Canal, and E. Pimentel. Soft component adaptation. In Electronic Notes in Theoretical Computer Science
(ENTCS), 85(3), 2003.
4. A.W. Brown and K.C. Wallnau. The current state of CBSE. IEEE Software, 15(5):3747, 1998.
5. G.H. Campbell. Adaptable components. In ICSE 1999, pages 685686. IEEE Press, 1999.
6. C. Canal, E. Pimentel, and J.M. Troya. Compatibility and inheritance in software architectures. Science of Computer
Programming, 41:105138, 2001.
7. A. Cechich, M. Piattini, and A. Vallecillo (Eds). Component-Based Software Quality. LNCS 2693. Springer, 2003.
8. S. Ducasse and T. Richner. Executable connectors: Towards reusable design elements. In ESEC/FSE97, LNCS 1301.
Springer, 1997.
9. D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch: Why reuse is so hard. IEEE Software, 12(6):1726,
1995.
10. D. Gelernter and N. Carriero. Coordination languages and their significance. Communications of the ACM. 35(2):97
107. 1992
11. P. Inverardi and M. Tivoli. Automatic synthesis of deadlock free connectors for COM/DCOM applications. In
ESEC/FSE2001. ACM Press, 2001.
12. B. Jonsson, K.G. Larsen, and W. Yi. Probabilistic extensions of process algebras. Handbook of Process Algebra.
Elsevier, 2001.
13. R. Mili et al. Semantic distance between specifications. Theoretical Computer Science, 247:257276, Elsevier 2000.
14. R. Passerone et al. Convertibility Verification and Converter Synthesis: two faces of the same coin. In Proc. of the Int.
Conference on Computer-Aided Design. ACM Press, 2002.
15. A. Vallecillo, J. Hernandez, and J.M. Troya. New issues in object interoperability. In Object-Oriented Technology,
LNCS 1964, pages 256269. Springer, 2000.
16. K. Wallnau, S. Hissam, and R. Seacord. Building Systems from Commercial Components. SEI Series in Soft. Engi-
neering, 2001.
17. M. Wermelinger and J.L. Fiadeiro. Connectors for mobile programs. IEEE Transactions on Software Engineering,
24(5):331341, 1998.
18. D.M. Yellin and R.E. Strom. Protocol specifications and components adaptors. ACM Transactions on Programming
Languages and Systems, 19(2):292333, 1997.
Anlisis de Restricciones de Integridad en el Nivel Conceptual
M. A. Pastor, M. Celma-Gimnez, L. Mota-Herranz

Universidad Politcnica de Valencia
Camino de Vera s/n
E-46022 Valencia Espaa
{mapastor|mcelma|lmota}@dsic.upv.es
Resumen
El estado de desarrollo alcanzado por la tecnologa de bases de datos ha conducido al uso de este tipo de
sistemas en todos los mbitos de aplicacin de los computadores. Una vez consolidada esta tecnologa, la
atencin de los investigadores se ha orientado al campo del diseo de bases de datos, conscientes de que una
razn importante del xito de un sistema de bases de datos reside en la bondad de su diseo. As, el campo
del modelado conceptual ha adquirido gran relevancia, observndose que muchos de los problemas clsicos
del diseo de bases de datos, se abordan ahora desde el nivel conceptual. El objetivo que se persigue es
poder modelar, en etapas tempranas de la construccin de un sistema de informacin, todas sus propiedades
tanto estticas como de evolucin, de forma que las fases posteriores en la construccin del sistema sean en
la medida de lo posible automatizables. Uno de los problemas clsicos, que ahora se aborda desde el nivel
conceptual es el de la integridad de los datos: especificacin de restricciones estticas y de evolucin del
sistema, comprobacin de las restricciones, generacin de transacciones de evolucin consistentes, etc. Es en
este marco en el que se sita el presente trabajo; su intencin es hacer un anlisis de restricciones de
integridad en el nivel conceptual que pueda servir de base para la generacin automtica de transacciones
consistentes (o seguras) con las que sea posible especificar los requisitos (o procesos) de evolucin
planteados por los usuarios. Para hacer este anlisis, se definen algunas propiedades de las restricciones que
permiten clasificarlas desde el punto de vista de su satisfaccin y de su restauracin frente a operaciones de
actualizacin. Para presentar estas ideas sobre un modelo de datos concreto, se propone una extensin del
Modelo EntidadRelacin, consistente en la incorporacin de un lenguaje lgico y un lenguaje transaccional
que permitan modelar de forma completa la realidad. La eleccin de este modelo se justifica por su
popularidad y sencillez, aunque las autoras son conscientes de que las ideas y resultados presentados seran
directamente trasladables a otros modelos de datos conceptuales (UML, ODMG, OASIS, etc.).
1. Introduccin.
Uno de los objetivos que ha guiado la evolucin de la tecnologa de bases de datos en su ya dilatada
historia, ha sido el mantenimiento de la integridad de los datos, entendida como calidad de la informacin
almacenada. La consecucin de este objetivo ha producido importantes desarrollos en distintos frentes:
extensin de los lenguajes de definicin de datos para poder especificar restricciones de integridad en el
esquema de la base de datos; desarrollo de tcnicas de comprobacin y mantenimiento de la integridad frente
a la actualizacin de la base de datos, etc. Una caracterstica comn a los trabajos realizados en este campo,
ha sido el punto de vista adoptado; los desarrollos se han situado generalmente en el nivel lgico (relacional)
de la base de datos, habindose obtenido resultados muy importantes en esta direccin [10] [11].
Una vez consolidada la tecnologa de bases de datos y generalizado su uso, la atencin de los
investigadores se ha orientado al campo del diseo de bases de datos, siendo conscientes de que una razn
importante del xito de un sistema de bases de datos reside en la bondad de su diseo. As, el campo del
modelado conceptual ha adquirido gran relevancia en la ltima dcada, observndose que muchos de los
problemas clsicos del diseo de bases de datos, se abordan ahora desde el nivel conceptual. El objetivo que
se persigue es disponer de modelos de datos y metodologas de diseo que permitan modelar, en etapas
tempranas de la construccin de un sistema de informacin, todas sus propiedades observables, de forma que
las fases siguientes en la construccin del sistema sean en la medida de lo posible automatizables. Uno de los
problemas clsicos que se aborda ahora desde el nivel conceptual es el de la integridad: especificacin de
restricciones estticas y de evolucin del sistema, comprobacin de las restriciones, generacin de
transacciones de evolucin consistentes, etc. Es en este marco en el que se sita el presente trabajo, su
intencin es hacer un anlisis de restricciones de integridad en el nivel conceptual que pueda servir de base
para la generacin automtica de transacciones consistentes (o seguras) con las que poder modelar los
requisitos (o procesos) de evolucin planteados por los usuarios. Para hacer este anlisis, se definen algunas
propiedades de las restricciones que permiten clasificarlas desde el punto de vista de su satisfaccin y de su
restauracin frente a operaciones de actualizacin. Para presentar las ideas sobre un modelo de datos concreto,
se propone una extensin del Modelo EntidadRelacin; la eleccin de este modelo se justifica por su
popularidad y sencillez; las autoras son conscientes de que las ideas y resultados presentados seran
fcilmente trasladables a otros modelos de datos conceptuales (UML, ODMG, OASIS, etc.).
El trabajo se organiza como sigue. En el segundo apartado se presenta la extensin del Modelo Entidad
Relacin que se propone; la extensin principal consiste en la incorporacin de un lenguaje lgico y un
lenguaje transaccional, que permitan modelar de forma completa la realidad. En el tercer apartado se definen
las propiedades de las restricciones en las que se basa el anlisis que se va a realizar. En el cuarto apartado se
aplica este anlisis a las restricciones expresables en un diagrama EntidadRelacin, y por ltimo, en el
quinto apartado se presentan las conclusiones y los trabajos futuros previstos.
2. Una Propuesta de Extensin del Modelo EntidadRelacin.

Las metodologas de diseo de bases de datos conciben el proceso de desarrollo como un proceso divido en
fases: concepcin de la base de datos (anlisis y diseo conceptual), diseo de la base de datos (diseo lgico
y diseo fsico) e implementacin (definicin y carga de la base de datos, y desarrollo de los programas de
acceso).
Entre las metodologas existentes destaca el hecho de que en muchas de ellas, el modelo de datos utilizado
como herramienta de modelado en el diseo conceptual es el Modelo EntidadRelacin (ER). Este hecho se
puede justificar por dos razones: la sencillez y economa de conceptos del modelo, y el uso de las
abstracciones de entidad y de relacin entre entidades como elementos de modelado bsicos, conceptos
prximos a la percepcin humana de la realidad y por ello fcilmente comprensibles por el usuario; lo que
facilita la comunicacin entre ste y el diseador. As, hoy en da, podemos encontrar numerosas propuestas
de metodologas de desarrollo basadas en ER [3], [4], [6]; todas ellas consisten en una definicin ms o
menos extendida del modelo original [2], unas reglas u orientaciones para el modelado conceptual, y unas
reglas precisas, automatizables en su mayora, para traducir el esquema conceptual obtenido al Modelo
Relacional. En [8], [9] se hace un estudio exhaustivo del Modelo ER y sus extensiones.
Estudiando las extensiones del Modelo ER que se proponen en estas metodologas, y obviando pequeos
detalles diferenciadores, se pueden extraer algunas conclusiones. Las extensiones del Modelo ER son muy
limitadas en lo que a la especificacin de restricciones semnticas se refiere. Tambin y debido a las
caractersticas del Modelo ER, el modelado conceptual y posteriormente el diseo lgico estn dirigidos por
los datos, se trata de obtener unas estructuras que representen adecuadamente la informacin que la
organizacin necesita para el cumplimiento de sus funciones, de acuerdo al anlisis de los requisitos de los
usuarios. En ninguno de los dos niveles (conceptual y lgico) se presta atencin al modelado de los requisitos
de evolucin del sistema planteados por los usuarios.
Por todo ello, se considera que, aunque asumiendo como vlidas las metodologas ER existentes, stas
requieren una extensin del modelo en dos sentidos: una extensin del Modelo ER con un lenguaje
declarativo que permita especificar restricciones de integridad que no se pueden expresar grficamente en el
diagrama; y una extensin del Modelo ER con un lenguaje transaccional que permita representar los
requisitos de procesamiento de la informacin, es decir las posibles transacciones a travs de las cuales
evolucionar el sistema diseado.
2.1. El Modelo ERE.
El Modelo EntidadRelacin se basa en dos conceptos bsicos de modelado, el concepto de entidad y el

concepto de relacin entre entidades. Respetando estos dos constructores bsicos, las extensiones del modelo
que han aparecido coinciden en la incorporacin de nuevos mecanismos de abstraccin (agregacin y
generalizacin) y de distintos tipos de restricciones de integridad. En todas las versiones, se propone un
lenguaje grfico de definicin de estructuras que salvando pequeas diferencias es muy similar. Tambin, y
como ya se ha comentado anteriormente, la mayora de las propuestas se caracterizan por prestar muy poca
atencin al modelado de la dinmica o la evolucin del sistema; caracterizndose por ello el estilo de
modelado que se realiza con este modelo de datos como diseo dirigido por los datos. An as, existen
algunas excepciones a esta situacin y se pueden encontrar en la literatura versiones del Modelo ER que
incorporan lenguajes de operadores sobre las estructuras del modelo, con los que especificar la evolucin del
sistema [1], [5],[ 6]; sin embargo, estas extensiones no son ampliamente utilizadas.
La extensin del modelo que se propone, aunque es propia [6], incorpora elementos presentes en otras
propuestas. Por ello y por considerarlo innecesario, debido a su popularidad, no se va a hacer una
presentacin exhaustiva del Modelo Entidad Relacin Extendido (ERE) que se va a utilizar; en su lugar en
este apartado se resumir la sintaxis y la semntica del modelo propuesto.
El Modelo ERE consta de tres lenguajes: un lenguaje grfico de definicin de estructuras, un lenguaje
lgico, y un lenguaje transaccional. En el Anexo A, se incluye una definicin de estos lenguajes.
2.1.1. Lenguaje Grfico. El lenguaje grfico consta de smbolos para poder especificar tipos de las cuatro
clases de estructuras disponibles en el modelo (entidades con sus atributos, entidades dbiles, relaciones entre
entidades con sus atributos propios y entidades compuestas o agregadas con sus atributos propios). Asimismo
ofrece una notacin para representar jerarquas de herencia entre tipos de entidades. El lenguaje permite
expresar tambin los siguientes tipos de restricciones de integridad: restriccin de identificacin sobre
entidades, restriccin de valor no nulo sobre atributos, restriccin de unicidad sobre atributos, restricciones de
cardinalidad de las entidades en su participacin en las relaciones, y restricciones sobre las jerarquas entre
entidades. A un esquema conceptual expresado en este modelo de datos se le denomina diagrama ERE.
2.1.2. Lenguaje Lgico. El lenguaje lgico L del Modelo ERE, es un lenguaje al estilo del Clculo Relacional
de Tuplas del Modelo Relacional. Al igual que los clculos relacionales, el lenguaje que se propone es un
lenguaje lgico de primer orden cuya sintaxis viene definida por un alfabeto y un conjunto de reglas de
formacin de frmulas bien formadas. El alfabeto, que es particular para cada sistema, se deriva del diagrama
ERE y las reglas de formacin de frmulas son universales. Con este lenguaje lgico se pueden expresar
propiedades sobre el diagrama (frmulas bien formadas); estas frmulas pueden representar restricciones de
integridad (frmulas bien formadas cerradas) o consultas (frmulas bien formadas abiertas). La semntica del
lenguaje (interpretacin de un lenguaje de primer orden) viene definida por una extensin (ocurrencia o
estado) del diagrama ERE; las reglas de evaluacin de las frmulas del lenguaje en una extensin del
diagrama son universales a todos los lenguajes de primer orden.
2.1.3. Lenguaje Transaccional. El lenguaje transaccional T que se propone consta de un conjunto de

operadores con los que manipular las estructuras del modelo. El lenguaje ofrece operadores genricos de
insercin y de borrado para las estructuras entidad y relacin; as como operadores genricos de creacin y de
eliminacin de entidades especializadas en una jerarqua de entidades. Con estos operadores se pueden definir
transacciones usando cualquier lenguaje de programacin; este lenguaje proporciona las estructuras bsicas de
programacin (iteracin, seleccin, asignacin, etc.) entre las cuales se intercalan los operadores del Modelo
ERE (la sintaxis del lenguaje de programacin no se incluye en el Anexo A). Las transacciones definidas con
el lenguaje T representarn los requisitos de evolucin planteados por los usuarios en la fase de anlisis. En
este contexto del diseo conceptual, una transaccin se entiende como una secuencia de operaciones de
manipulacin sobre una extensin del diagrama ERE; la secuencia queda definida por la semntica de las
estructuras de programacin presentes en la transaccin. Extendiendo al nivel conceptual las propiedades del
concepto de transaccin en el nivel lgico, una transaccin se considerar una unidad tmica de ejecucin
que preserva la consistencia de los datos. Se denominar esquema de transaccin a una transaccin
parametrizada.
A continuacin se presenta un ejemplo de uso del Modelo ERE. El ejemplo es relativo a una compaa
fabricante de productos (tems). Los departamentos se encargan de vender los productos directamente al
pblico o de suministrarlos a otras compaas.
nombre tipo nombre
tem n n n
Compaa
Suministro
n
Venta T,D
taller marcas
1 n
nombre Departamento Productora Distribuidora
Figura 1. Ejemplo de diagrama ERE
Un ejemplo de uso del lenguaje lgico sera la definicin de la restriccin de integridad, no expresale en el
diagrama, todo departamento tiene asignada la venta de algn item o la distribucin de algn tem a otra
compaa:
RI: DX(Departamento(DX) (SX(Suministro(SX)SX.Departamento=DX)

VX(Venta(VX)VX.Departamento=DX)))
Un ejemplo de uso del lenguaje transaccional sera el siguiente esquema de transaccin que permite la
insercin de nuevos tems. Observese el uso de los operadores genricos, ins_entidad e ins_relacin, para la
insercin de entidades y relaciones.
Transaccin Alta_tem (nombre_tem:, tipo_tem:, nombre_dep:)

Variables: IX: tem, DX: Departamento, VX: Venta
Inicio
ins_entidad tem atributos nombre nombre_tem, tipo tipo_tem
ins_relacin Venta donde
IX(tem(IX) IX.nombre=nombre_item
DX(Departamento(DX) DX.nombre=nombre_dep
VX.tem=IX VX.Departamento=DX))
Fin
2.2. Formalizacin del Modelo ERE.
La definicin formal de un modelo de datos asegura el uso correcto del mismo, al evitar ambigedades en
la interpretacin y posterior uso de los conceptos proporcionados por el modelo. Las siguientes definiciones
formalizan los conceptos bsicos del modelo ERE y algunos otros conceptos, apoyados en ellos, que sern
utilizados en los apartados siguientes. Se asume la existencia de un conjunto finito de tipos base (entero, real,
etc.), un conjunto numerable de dominios definidos sobre los tipos base (D1, D2 , , Dn ), y un conjunto
numerable de nombres (nombre de atributos, nombres de entidades, etc.).
Definicin 1. Esquema ERE. Un esquema en el Modelo ERE, es un triplete (ES, J, RI), donde ES es el
conjunto de estructuras, J es el conjunto de jerarquas entre entidades y RI es el conjunto de restricciones de
integridad definidos en el esquema. El conjunto ES se compone a su vez del conjunto de tipos de entidad E, el
conjunto de tipos de entidad dbil ED, el conjunto de tipos de relacin R, y el conjunto de tipos de entidad
compuesta (agregada) EC.
ES = {E, R, ED, EC}

E = {Ei: (A1:D1, A2:D2, , Ani:Dni) / ni 1, Atr(Ei) = {Ai , A2 , , Ani}}
R = {Ri: (E1, E2, , Eni, A1:D1, , Ami:Dmi) / ni 2, mi 0, k/ 1 k ni: Ek E EC,
Atr(Ri) = {Ai , A2 , , Ami} }
ED = {EDi: (Ei, R1, R2 , , Rni) / EiE , k/ 1 k ni: Rk=( Ek1, , Ekj-1, Ekj, Ekj+1, , Ek nk)R, Ekj= Ei y
Rk (Ekj (1,1), (Ek1, , Ekj-1, Ekj+1, , Ek nk) (-, -)),
k: 1.. ni (Idn(Ek1) Idn(Ekj-1) Idn(Ekj+1) Idn(Ek nk)) Atr(Ei) }
EC = {ECi: (Ri) / Ri = (E1, E2, , Eni, A1: D1, , Ami: Dmi) R,
Atr(ECi) = Atr(Ri) Atr(E1) Atr(Eni) }
J = {Ji: (EG, E1, E2, , Eni) / ni 1, EG E EC , k/ 1 k ni: Ek E y Ek no es dbil,
Atr(EG) Atr(Ek) }
RI = {Wi: Wi es una frmula bien formada cerrada del lenguaje lgico L derivado de ES}
En la definicin anterior la funcin Atr, es una funcin que aplicada sobre un tipo de entidad o un tipo de
relacin devuelve el conjunto de sus atributos, e Idn es una funcin que aplicada sobre un tipo de entidad o un
tipo de relacin devuelve sus atributos identificadores. El modelo ERE permite la definicin de tipos de
entidades simples (E) y tipos de entidades compuestas o agregadas (EC), una entidad compuesta se define a
partir de una asociacin (tipo de relacin) definida entre entidades. Una entidad dbil es una entidad simple
con restriccin de identificacin respecto a otras entidades con las que se relaciona y de las que hereda sus
identificadores. En una jerarqua entre entidades, las entidades especializadas heredan los atributos de la
entidad general.
En el conjunto RI, se incluyen todas las restricciones de integridad definidas sobre el esquema ERE, tanto
las que tienen una notacin grfica asociada como las que, por no tenerla, se expresan directamente en el
lenguaje lgico L.
En el Modelo ERE se exige que en un esquema todo tipo de entidad EiE que no sea dbil ni
especializada, tenga una restriccin de identificacin en RI. Al conjunto de atributos sobre los que se define la
restriccin de identificacin se le denomina identificador. Las restricciones de identificacin de los tipos de
relacin, de los tipos de entidad dbil y de los tipos de entidad compuesta se derivan de su definicin en el
esquema.
Sea EDi = (Ei, R1, R2 , , Rni) una entidad dbil en la que k/ 1 k ni: Rk=( Ek1, , Ekj-1, Ekj, Ekj+1, , Eknk)
y Ekj=Ei, entonces se cumple: Idn(EDi) =Idn*(Ei) k:1..ni (Idn(Ek1) Idn(Ekj-1) Idn(Ekj+1) Idn(Eknk)),
es decir el identificador de una entidad dbil se construye con los atributos heredados de los identificadores de
las entidades de las que depende a travs de las relaciones Rk (k:1..ni) mas su seudoindentificador (atributos
discriminantes).
El identificador de un tipo de relacin se deriva de los identificadores de los tipos de entidad asociados y
de las restricciones de cardinalidad del tipo de relacin. Sea R = (E1, E2, , En, A1:D1, , Ami:Dmi) un tipo de
relacin, entonces Idn(R) = Idn(Ei1) Idn(Ei2) Idn(Eik), 1 k n, 1 ij n (j:1..n) y el subconjunto de
tipos de entidades A={Ei1, Ei2, , Eik} tiene la siguiente restriccin de cardinalidad respecto al resto de tipos
de entidades, sea B, asociados en R, R (A(-, 1), B(-,-) ).
Sea ECi = (Ri) una entidad compuesta, entonces Idn(ECi) = Idn(Ri).

Sea Ji: (EG, E1, E2, , Eni) una jerarqua de entidades, entonces k/ 1 k ni , se cumple Idn(Ek) = Idn(EG).
Para cada tipo de estructura del conjunto ES, existe un dominio asociado que se deriva fcilmente de su
definicin en el esquema:
Sea Ei=(A1:D1, A2:D2, , Ani:Dni)E entonces Dom(Ei) = D1 D2 Dni .

Sea Ri=(E1, E2, , Eni, A1:D1, , Ami:Dmi)R entonces
Dom(Ri) = Dom(E1 ) Dom(E2) Dom(Eni) D1 D2 Dmi .
Sea EDi=(Ei, R1, R2 , , Rni)ED entonces Dom(EDi)={(ei, r1, r2 , , rni): ei Dom(Ei) y
k/ 1 k ni: rk=( e1, e2, , ei, , emk) Dom(Rk)}.
Sea ECi=(Ri)EC entonces Dom(ECi) = Dom(Ri).
Definicin 2: Extensin de un esquema ERE. Una extensin (ocurrencia o estado) de un esquema

consiste en un subconjunto del dominio de definicin de cada tipo de estructura del esquema.
:{
{(Ei) D1 D2 Dni: Ei=( Ai1:Di1, Ai2:Di2, , Ain:Din) E y
JiJ ( (Ji = (EG, E1,, Ei,, En) EG = ( AG1:DG1, AG2:DG2, , AGn:DGn)
Ei= (Ai1:Di1, Ai2:Di2, , Ain:Din) (vG1, vG2, , vGn, vi1, vi2, , vin) (Ei)) (vG1, vG2, , vGn)(EG)) }
{(Ri) (E1 ) (E2) (Eni) D1 D2 Dmi: Ri=(E1, E2, , Eni, A1:D1, , Ami:Dmi) R y
rj (Ri) ( rj = (e1, e2, , eni, v1, v2, , vmi) rk (Ri) (rk = (e1, e2, , eni, v1, v2, , vmi) ) }
{(EDi) = {(ei, r1, r2 , , rni): EDi=(Ei, R1, R2 , , Rni)ED,

ei(Ei) y k/ 1 k ni: rk=( ek1, ek2, , ei, , ekmk)(Rk) }
{(ECi)= (Ri): ECi=(Ri) EC } }
En la definicin de una extensin de un esquema se contemplan las restricciones de integridad

inherentes al Modelo ERE:
Las entidades que participan en una relacin deben pertenecer a la extensin de los
correspondientes tipos de entidad en el tipo de relacin.
No pueden existir en la extensin de un tipo de relacin dos relaciones que liguen al mismo
conjunto de entidades.
Toda entidad en la extensin de un tipo de entidad especializada debe tener su correspondiente
entidad en la extensin de su tipo de entidad general.
Definicin 3: Satisfaccin de la integridad. Sea un estado de un esquema , se dice que WRI se satisface
en el estado si y slo si W es cierto en , en caso contrario se dice que W se viola en . Sea un estado de
un esquema , se dice que satisface la integridad si y slo si para cada WRI, W se satisface en .
Definicin 4: Comprobacin de la integridad. Dados, un estado de un esquema , una restriccin WRI,

una transaccin T sobre , y el estado resultante T() de aplicar la transaccin T al estado ; la comprobacin
de la integridad consiste en determinar si para cada WRI, W se satisface en T() o, si en caso contrario se
viola.
Definicin 5: Modelo de un esquema ERE. Se dice que un estado es modelo de un esquema si para toda
restriccin WRI, W se satisface en .
Definicin 6: Esquema ERE consistente. Se dice que un esquema es consistente si tiene un modelo.
Definicin 7: Mantenimiento de la integridad. Dados, un estado de un esquema , una transaccin T

sobre tal que T() viola alguna W de RI; el mantenimiento de la integridad consiste en encontrar una
transaccin T, T T, tal que T() satisface toda W RI.
3. Anlisis de Restricciones en el Nivel Conceptual.

Para mantener la integridad de los datos en un sistema de bases de datos, se debe especificar en el esquema
() aquellas propiedades del mundo real que la base de datos debe satisfacer en cualquier estado (). Estas
propiedades, expresadas en forma de restricciones de integridad (RI), sern comprobadas (definicin 4), frente
a cualquier cambio (actualizacin) de la base de datos, rechazndose la actualizacin en caso de que alguna
restriccin se viole, o buscando una restauracin (mantenimiento) de la integridad (definicin 7).
As, las dos actividades centrales al tratamiento de la integridad en un sistema de bases de datos son la
comprobacin y la restauracin. Por ello, es importante definir las propiedades de las restricciones frente a
operaciones de actualizacin en estos dos sentidos.
La primera propiedad importante de una restriccin es la de ser relevante respecto a una operacin de
actualizacin, es decir conocer si la restriccin puede ser violada o no por dicha operacin. Fue Nicolas [7]
quien introdujo y estudi este concepto ya clsico en bases de datos.
Definicin 8: Restriccin relevante. Sea un esquema ERE, = (ES, J, RI), una restriccin WRI y una
operacin de actualizacin Op sobre , se dice que W es relevante para Op si y slo si existen dos estados y
de y una sustitucin base (i.e. que instancia todas las variables con constantes) de las variables de Op
tales que W se satisface en y W se viola en = Op(). En caso contrario se dice que W no es relevante
para Op.
Ejemplo: En el diagrama ERE de la figura 1, la restriccin Todo tem tiene asignado un nombre no es
relevante respecto a la operacin de insercin en Compaa y la restriccin Todo tem debe ser vendido por
algn departamento es relevante para la operacin de insercin en tem.
La siguiente propiedad importante de una restriccin es la de ser relevante respecto a una operacin en
cualquier caso, es decir conocer que la restriccin siempre ser violada por la operacin, independientemente
del estado sobre el que se aplica la operacin as como de la instancia de la operacin.
Definicin 9: Restriccin relevanteindependiente. Sea un esquema ERE, =(ES, J, RI), y una restriccin
WRI relevante para una operacin de actualizacin Op sobre , se dice que W es relevanteindependiente
para Op si y slo si para todo modelo de , y toda sustitucin base de las variables de Op, Op() viola
W. En caso contrario se dice que W es relevantedependiente para Op.
Ejemplo: En el diagrama ERE de la figura 1, la restriccin Todo tem debe ser vendido por algn
departamento es relevanteindependiente para la operacin de insercin en tem ya que el nuevo tem no
participa en la relacin Venta. La restriccin Toda compaa tiene asignado un nombre es
relevantedependiente para la operacin de insercin en Compaa ya que depende del valor del atributo
nombre en la operacin.
Otra propiedad importante de una restriccin, respecto a una operacin de actualizacin es la de ser
restaurable en caso de violacin, es decir conocer si cuando la restriccin es violada por la operacin la
integridad se puede restaurar o no.
Definicin 10: Restriccin restaurable. Sea un esquema ERE, =(ES, J, RI), y una restriccin WRI
relevante para una operacin de actualizacin Op sobre , se dice que W es restaurable para Op si y slo si
existe una operacin, Op tal que para todo modelo de , y toda sustitucin base de las variables de Op, tal
que Op() viola W, existe una sustitucin base para las variables de Op tal que Op(Op()) satisface
W. En caso contrario se dice que W no es restaurable para Op.
En este trabajo, se van a asumir algunas hiptesis para la restauracin. En primer lugar, la violacin de una
restriccin provocada por una operacin de insercin (resp. borrado) nunca se restaurar con una operacin de
borrado (resp. insercin). En segundo lugar, los valores proporcionados por el usuario para una operacin no
pueden ser modificados en la restauracin.
departamento es restaurable para la operacin de insercin en tem con una operacin de insercin en Venta.
La restriccin Toda compaa tiene asignado un nombre no es restaurable para la operacin de insercin en
Compaa sin cambiar los valores proporcionados por el usuario.
Por ltimo, otra propiedad importante de las restricciones restaurables es la de que la operacin de
restauracin sea nica, es decir que W slo se pueda restaurar, en caso de violacin por Op, a travs de la
operacin Op.
Definicin 11: Restriccin restaurabledeterminista. Sea un esquema ERE, = (ES, J, RI), y una
restriccin WRI restaurable para una operacin de actualizacin Op sobre , se dice que W es
restaurabledeterminista para Op si y slo si la operacin restauradora Op es nica. En caso contrario se
dice que W no es restaurabledeterminista para Op.
departamento es restaurabledeterminista para la operacin de insercin en tem ya que la restauracin slo
es posible con una operacin de insercin en Venta. La restriccin Todo departamento vende algn item o lo
suministra a una compaa no es restaurabledeterminista para la operacin de insercin en Departamento
ya que la restauracin puede realizarse con una insercin en Venta o una insercin en Suministro.
4. Clasificacin de Restricciones en el Modelo ERE.

De acuerdo a las propiedades de las restricciones definidas en el apartado anterior, las restricciones que se
pueden definir en un diagrama ERE se clasifican segn el siguiente cuadro:
Tabla 1. Clasificacin de restricciones del Modelo ERE.

RESTRICCIN OPERACIN TIPO
Restriccin de valor no nulo. Insercin relevantedependiente
no restaurable
Restriccin de unicidad. Insercin relevantedependiente
no restaurable
Restriccin de identificacin. Insercin relevantedependiente
no restaurable
Restriccin de cardinalidad min=1 Insercin en E relevanteindependiente
(y max>1) del tipo de entidad E en restaurabledeterminista
el tipo de relacin R. Borrado en R relevantedependiente
restaurabledeterminista
Restriccin de cardinalidad max=1 Insercin en R relevantedependiente
(y min=0) del tipo de entidad E en no restaurable
el tipo de relacin R.
Restriccin de cardinalidad min=1 Insercin en E relevanteindependiente
y max=1 del tipo de entidad E en el restaurabledeterminista
tipo de relacin R. Insercin en R relevanteindependiente
no restaurable
Borrado en E relevanteindependiente
Borrado en R relevanteindependiente
Restriccin de especializacin total Insercin en tipo de entidad relevanteindependiente

(y solapada). general restaurableno determinista
Borrado en tipo de entidad relevantedependiente
especializada restaurabledeterminista
Restriccin de especializacin Insercin en tipo de entidad relevantedependiente
disjunta (y parcial). especializada no restaurable
Restriccin de especializacin total Insercin en tipo de relevanteindependiente
y disjunta. entidad general restaurableno determinista
Insercin en tipo de entidad relevanteindependiente
especializada no restaurable
Borrado en tipo de entidad relevanteindependiente
especializada restaurabledeterminista
Restriccin inherente: toda Insercin en R relevantedependiente
componente de una relacin de tipo no restaurable
R es una entidad de tipo E.
Borrado en E relevantedependiente
Restriccin inherente: toda entidad Insercin en E relevantedependiente
especializada de tipo E es una no restaurable
entidad del tipo general G.
Borrado en G relevantedependiente
Restriccin inherente: no existen Insercin en R relevantedependiente
dos relaciones de tipo R que asocien no restaurable
las mismas entidades.

En este trabajo se han alcanzado los siguientes objetivos:
Se ha definido una extensin del Modelo ER, con un lenguaje lgico y un lenguaje transaccional.
Se ha hecho un nlisis de las restricciones de integridad en el nivel conceptual, en funcin de las
propiedades de comprobacin y restauracin de las restricciones respecto a una operacin de
actualizacin.
Se ha hecho una clasificacin de las restricciones de integridad del Modelo ERE en funcin del
anlisis anterior.
Los trabajos relacionados que estn en proceso de realizacin son:
Realizar el anlisis de las restricciones de integridad de un diagrama ERE que son

restaurablesindependientes y determinar las operaciones restauradoras ms adecuadas.
Desarrollar un algoritmo para generar las transacciones de actualizacin seguras (consistentes) sobre
un esquema ERE, para un subconjunto de restricciones del Modelo ERE.
6. Bibliografa
[1] Celma, M.; Mota, L.; Pastor, MA; Casamayor, J.C. Sobre la enseanza de las Bases
de Datos: teora y diseo. Actas de 1 JIDBD, Espaa, 1996.
[2] Chen, P.P. The Entity/Relationship Model: Toward a Unified View of Data.
CACM 29, 1976.
[3] de Miguel, A.; Piattini, M.; Marcos, E. Diseo de Bases de Datos Relacionales.
RAMA, 1999.
[4] Elmasri, R.; Navathe, S. Fundamentos de Sistemas de Bases de Datos. Addison Wesley, 2000.
[5] Gogolla, M. An Extended EntityRelationship Model. LNCS 767.

Springer Verlag, 1994
[6] Mota, L.; Celma, M.; Casamayor, JC. Bases de Datos Relacionales: teora y diseo.
Universidad Politcnica de Valencia. SPUPV94.767, 1994.
[7] Nicolas, J. M. Logic for improving integrity checking in relational databases.
Acta Informatica 18 (3): 22753, 1982.
[8] Thalheim, B. An Overview on Semantical Constraints for Database Model
Proc. 6th I. C. Intellectual Systems and Computer Science, Moscow, Russia, Dec, 1996.
[9] Thalheim, B. EntityRelationship Modeling. Foundations of Database Technology.
Springer Verlag, 2000.
[10] Trker, C; Gertz, M. Semantic integrity support in SQL-99 and comercial (object-)
relational database management systems. VLDBJ 10(4): 241-269, Dec. 2001.
[11] Mayol, E.; Teniente, E. A survey of current methods for integrity constraint maintenance
and view updating. In Advances in conceptual modeling, Chen, P.; Embley, D.W. et alt. (eds)
LNCS 1727. Nov. 1999.
7. Anexo A
7.1. Lenguaje Grfico del Modelo ERE.
a) Tipo de entidad simple b) Tipo de relacin R. Cardinalidad: R(E(1,n), F(0,1))

E
E
1 n
E R F
c) Tipo de entidad dbil E dependiente de R

Una ocurrencia de E puede participar en i ocurrencias de R,
1 1 <= i <= n. El doble arco para E representa la cardinalidad
E R mnima 1 de E. Las cardinalidades mximas se representan
en el arco opuesto a la entidad.
d) Tipo de entidad agregada (compuesta) R e) Jerarqua de entidades: entidad general (G) y

entidades especializadas (F, E y H)
E R F
G
S X={T|P }, Y={D|S} X,Y
G F E H
f) Tipos de atributos
a1
a2
a a a a n a a a
Normal Identificador nico No nulo Multivaluado Estructurado Derivado
7.2. Lenguaje Lgico del Modelo ERE.
Sintaxis
a) Alfabeto:
Smbolos de constante: elementos de los dominios asociados a los atributos del esquema. (Estos
dominios son simples, es decir, definidos sobre tipos de datos escalares).
Smbolos de variable: hay tres clases de smbolos de variables:
variabledominio: se define asociada a un dominio del esquema ERE.
variableentidad: se define asociada a una entidad del esquema ERE.

variablerelacin: se define asociada a una relacin del esquema ERE.
Smbolos de predicado: se pueden distinguir los siguientes:
nombres de dominio: cada uno de los nombres de los dominios del esquema.
nombres de tipo de entidad: cada uno de los nombres de los tipos de entidad del esquema.
nombres de tipo de relacin: cada uno de los nombres de los tipos de relacin del esquema.
Operadores de comparacin: <, >, , , = y
Predicado unario de comprobacin de valor nulo: nulo.
Todos los nombres de atributos, nombres de entidades, nombres de rol (de una entidad en una
relacin) y nombres de relacin del esquema.
Conectivas lgicas: , , y .
Cuantificadores: y .
Smbolos auxiliares: (, ), ', :, ., {, } y ,.
b) Reglas de formacin de frmulas bien formadas (fbf)
Trmino: existen tres clases de trminos:

Trminorelacin:
una variablerelacin es un trminorelacin.
si W es un trminorelacin de tipo R y uno de los tipos de entidad relacionados en R es un objeto
agregado definido sobre la relacin S, entonces W.S es un trminorelacin.
Trminoentidad:
una variableentidad es un trminoentidad.
si W es un trminorelacin de tipo R, y Ei es uno de los tipos de entidad no agregada relacionados a
travs de R con una sola participacin, entonces W. Ei es un trminoentidad.
si W es un trminorelacin de tipo R, y Ei es uno de los tipos de entidad no agregada relacionados a
travs de R con ms de una participacin en R, y ri es uno de los roles con los que participa Ei,
entonces W.ri es un trminoentidad.
Trminodominio:
una constante de cualquier dominio es un trminodominio.
una variabledominio es un trminodominio.
si V es un trminoentidad de tipo E (resp. un trmino relacin de tipo R) y A es un atributo de E
(resp. de R), entonces V.A es un trminodominio.
si V es un trminoentidad definido sobre la entidad dbil ED que se identifica mediante su relacin
con la entidad E, y Ai es un atributo identificador de E entonces V.Ai es un trminodominio.
si V es un trminoentidad definido sobre la entidad especializada E, y Ai es un atributo de su entidad
general, entonces V.Ai es un trminodominio.
Condicin: una condicin es una frmula atmica del lenguaje que puede ser de cualquiera de los
siguientes tipos: comparacin, condicin de pertenencia o comprobacin de valor nulo.
Comparacin: es de la forma X Y, donde es un operador de comparacin y X e Y son
trminosdominio del mismo tipo sobre los que est definido dicho operador.
Condicin de pertenencia:
D(t) donde D es un nombre de dominio y t es un trminodominio de tipo D.
E(t) donde E es un nombre de entidad y t es un trminoentidad de tipo E.
R(t) donde R es un nombre de relacin y t es un trminorelacin de tipo R.
Comprobacin de valor nulo: nulo(t) donde t es un trminodominio.
Reglas que definen el conjunto de frmulas bien formadas (fbf):

toda condicin es una fbf.
si F es una fbf, entonces (F) y F son fbfs.
si F y G son fbfs, entonces F G, F G y F G son fbfs.
si F es una fbf y X un smbolo de variable, entonces X F y X F son fbfs.
slamente las frmulas definidas por las cuatro reglas anteriores son fbfs.
Semntica
Dada una extensin (ocurrencia o estado) de un esquema , las reglas de evaluacin de una frmula bien
formada cerrada son las siguientes:
Si F es una comparacin de la forma t t entonces F se evala a indefinido si alguno de los dos
trminos denota al valor nulo o si no est definida la operacin para el dominio de t y t; en caso
contrario, F se evala al valor de certeza de la correspondiente comparacin.
Si F es una condicin de pertenencia de la forma D(t) donde D es un nombre de dominio, entonces F
se evala a cierto si el valor denotado por el trmino t est incluido en el dominio D; en caso
contrario F se evala a falso.
Si F es una condicin de pertenencia de la forma E(t) donde E es un nombre de entidad, entonces F
se evala a cierto si la ocurrencia de la entidad de tipo E denotada por el trmino t pertenece a ; en
caso contrario F se evala a falso.
Si F es una condicin de pertenencia de la forma R(t) donde R es un nombre de relacin, entonces F
se evala a cierto si la ocurrencia de la relacin de tipo R denotada por el trmino t pertenece a ; en
caso contrario F se evala a falso.
Si F es una comprobacin de valor nulo de la forma nulo(t), entonces F se evala a cierto si t denota
al valor nulo; en caso contrario se evala a falso.
Si F es de la forma G, G H, G H, G H, donde F y G son fbfs, F se evala de acuerdo con
las tablas de verdad usuales.
Si F es de la forma X G, entonces F se evala a cierto si para alguna asignacin a X de un valor de
su dominio, G se evala a cierto; en caso contrario se evala a falso.
Si F es de la forma X G, entonces F se evala a cierto si para cualquier asignacin a X de un valor
de su dominio, G se evala a cierto; en caso contrario se evala a falso.
7.3. Lenguaje Transaccional del Modelo ERE.
La sintaxis de los operadores del lenguaje transaccional es la siguiente, se omite la semntica por razones
de espacio y porque es obvia:
Operador para insertar entidades en un tipo de entidad:
ins_entidad nombre_tipo_entidad {donde condicin | atributos atributo1 valor1, }
donde condicin es una fbf abierta con una sola variable libre del tipo de la entidad en la que se
inserta.
Operacin para eliminar entidades de un tipo de entidad:
bor_entidad nombre_tipo_entidad [donde condicin]
donde condicin es una fbf abierta con una sola variable libre del tipo de la entidad de la que se
borra.
Operacin para insertar relaciones en un tipo de relacin:
ins_relacin nombre_tipo_relacin donde condicin [atributos atributo1 valor1, ]
donde condicin es una fbf abierta con una sola variable libre del tipo de relacin en la que se
inserta.
Operacin para eliminar relaciones de un tipo de relacin:
bor_relacin nombre_tipo_relacin [donde condicin]
donde condicin es una fbf abierta con una sola variable libre del tipo de relacin de la que se borra.
Operacin para especializar entidades de un tipo (general) en un tipo especializado:
ins_especializacin nombre_de_subtipo donde condicin [atributos atributo1 valor1, ]
donde condicin es una fbf abierta con una variable libre del tipo de entidad especializada.
Operacin para eliminar entidades de una especializacin:
bor_especializacin nombre_de_subtipo [donde condicin]
donde condicin es una fbf abierta con una sola variable libre del tipo de entidad especializada.
Experincias no Desenvolvimento e Integrao de um Gerenciador de

Alertas para Ambientes de Ensino a Distncia na Internet
Daniela Leal Musa, Gustavo de Abreu Sisson, Jos Palazzo Moreira de Oliveira
Instituto de Informtica Universidade Federal do Rio Grande do Sul (UFRGS)
Caixa Postal 15.064 91.501-970 Porto Alegre RS Brazil
{musa,sisson,palazzo}@inf.ufrgs.br
Resumo
Este artigo apresenta um gerenciador de alertas para acompanhamento das atividades

realizadas pelos estudantes em cursos disponibilizados em ambientes de ensino a distncia
baseados na Web. Neste trabalho, gerenciador de alertas um mecanismo de monitorao
que envia mensagens para alguns usurios ou programas quando um determinado evento
ocorre. No contexto de ensino a distncia, este sistema pode ser usado para monitorar as
atividades dos estudantes em cursos na Web e, dada a existncia de certas condies, enviar
mensagens para o professor ou estudante, propor novas estratgias de ensino ou adaptar o
contedo de acordo com o perfil do estudante.
Palavras-chave: Ensino a Distncia, Sistema de Alertas, Monitorao de Alunos, Regras
ECA.
Abstract
This paper describes an alarm manager to monitor the online student activities in courses
through the Internet. In this paper an alarm is defined as a monitoring system that give some
users the feedback of the occurrence of some specified situations. In the scope of distance
learning, this system could be used to monitor student activities in courses online. When
certain conditions are detected it would send messages to the teacher or the student or even
other programs to propose new teaching strategies or to adapt the course content to better fit
the student learning style.
Key words: Distance Learning, Alarm System, Student Monitoring, ECA rules.
1 Introduo
Atualmente, a maioria dos ambientes de ensino a distncia (EAD) baseados na Web preocupam-se
com o processo de gerenciamento dos cursos, com as formas de apresentao do material instrucional e
com a disponibilizao de ferramentas de comunicao para interao entre alunos e professor. Nesses
ambientes, percebe-se uma falta de mecanismos que possibilitem ao professor realizar um
acompanhamento mais completo e abrangente das atividades dos alunos nos cursos, diagnosticando o
nvel de conhecimento, bem como o ritmo de aprendizagem destes alunos.
No desenvolvimento de cursos de ensino a distncia, o professor no tem uma presena to efetiva

como nos cursos presenciais. Frente a isso, uma das preocupaes apresentadas pelos professores o
processo de avaliao dos esforos individuais dos estudantes, principalmente quando envolve um grande
nmero de participantes, assim como a obteno de resultados que permitam a avaliao da classe como
um todo, pois, no mtodo de ensino a distncia, a ausncia do professor dificulta a avaliao.
Normalmente, o processo de avaliao dos alunos em cursos via Web realizado apenas atravs da
anlise de informaes coletadas de testes, exerccios ou relatrios extensos que apresentam um histrico
dos acessos feitos s pginas do curso [4]. Por esta razo, muito importante a existncia de ferramentas
apropriadas que possibilitem o monitoramento do que est sendo feito por cada estudante, detectando
situaes de problema e avisando ao professor sobre o comportamento de alguns alunos. Com isso, o
professor ter acesso s peculiaridades de cada aluno, e ser-lhe- possibilitado adequar as aulas s
individualidades de cada um, podendo, ele, dessa forma, exercer um acompanhamento mais prximo,
estimulando e orientando o aluno nas suas sesses de estudo.
Em alguns ambientes de ensino baseados na Web, o comportamento dos alunos avaliado pelo uso da
tecnologia de agentes da Inteligncia Artificial. Um agente monitora os processos de interao dos alunos
com o ambiente do curso, visando identificar o processo de aprendizagem de cada aluno [12]. Quanto
maior for a quantidade de informaes sobre o comportamento de cada aluno, mais adequadamente os
agentes podero auxiliar os alunos. Na maioria dos ambientes de ensino que utilizam tcnicas de
monitorao do comportamento dos alunos, as informaes necessrias para esta descoberta so retiradas
de uma anlise dos registros dos logs de acessos ao servidor Web de ensino a distncia. Tais registros
podem fornecer o comportamento de cada aluno no tocante aos acessos aos arquivos (pginas),
armazenados no servidor. Porm, preciso realizar vrias consultas nesses registros para se obter
informaes que sejam importantes e que possam auxiliar na descoberta do comportamento do aluno. Um
sistema de alertas pode ser usado para realizar essas consultas e avisar ao professor sobre o que est
ocorrendo com alguns estudantes.
O objetivo deste artigo apresentar um gerenciador de alertas para apoio ao ensino, que ajuda o
professor a ter um acompanhamento mais completo das atividades dos estudantes nos cursos distncia,
tentando minimizar a tarefa do professor de buscar estas informaes em relatrios extensos ou grficos
complexos. Alm disso, o gerenciador de alertas tambm auxilia os alunos em suas sesses de estudo,
enviando material complementar, avisos ou ajudas quando julgar necessrio.
O gerenciador de alertas, aqui proposto, foi integrado ao ambiente de ensino a distncia Claroline, de
forma a identificar os requisitos necessrios para a sua integrao em ambientes de ensino a distncia
baseado na Web.
Este artigo est organizado como segue. Na seo 2 apresentamos algumas pesquisas que vm sendo
desenvolvidas para o acompanhamento das atividades dos estudantes em ambientes de aprendizado a
distncia baseados na Web. Na seo 3 mostrado o gerenciador de alertas proposto. Na seo 4
descrita a integrao do ambiente de ensino a distncia Claroline e o gerenciador de alertas. Finalmente,
na seo 5, apresentamos as concluses deste trabalho e os trabalhos futuros.
2 Trabalhos Relacionados
Em geral, o comportamento dos estudantes avaliado pelo uso da tecnologia de agentes da
Inteligncia Artificial. Otsuka et al [6] apresenta um modelo composto por agentes de interface. Os
agentes de interface aprendem observando e monitorando as aes dos usurios, e atuam como assistentes
pessoais, colaborando com o usurio e com outros agentes na realizao de determinadas tarefas. O
modelo proposto por Otsuka composto de trs mdulos: (1) mdulo de acompanhamento, que realiza o
rastreamento das interaes dos alunos no ambiente e gera relatrios sobre a participao dos mesmos;
(2) mdulo de auxlio anlise de aproveitamento, que seleciona e apresenta ao professor dados que
podem auxiliar na anlise do aproveitamento do aluno em uma atividade especfica; (3) mdulo de
validao, que responsvel pela construo do perfil do aluno. At o presente momento nenhum
resultado tinha sido apresentado sobre a eficcia deste modelo proposto, e se o mesmo j tinha sido
implementado e estava em uso.
O sistema ConBa (CONcept BAsed system) [8] composto por agentes de interface que so capazes
de monitorar e aconselhar os estudantes durante a navegao no material instrucional. O sistema
composto por dois agentes principais, o agente professor e o agente tutor. O agente professor oferece a
interface para o professor-humano executar as seguintes atividades: (1) gerenciar o material instrucional
do curso; (2) descobrir, atravs do agente tutor, quais os assuntos esto sendo estudados pelos alunos; (3)
modificar o perfil do estudante, informando ao agente tutor que um certo assunto pode ser considerado
adquirido pelo estudante. O agente tutor mantm uma descrio das pginas j percorridas pelo estudante,
as quais so consideradas como assuntos j estudados pelo estudante. Esses agentes, no tomam decises,
nem agem a favor do estudante, eles simplesmente geram sugestes com base nas pginas j visitadas
pelos alunos e na estrutura do site do curso. Os agentes no levam em considerao o conhecimento
prvio dos alunos e nem o seu estilo e ritmo de aprendizagem. Seria interessante, que o agente pudesse
indicar material complementar, somente quando percebesse esta necessidade por parte do aluno, e no
simplesmente quando ele encerra um mdulo ou acessa uma pgina especfica.
Jaques e Oliveira propem uma arquitetura multiagente para monitorao dos acessos s ferramentas
de comunicao (lista, bate-papo, frum) de um ambiente de EaD [3]. Esta arquitetura composta por
quatro agentes que se comunicam entre si, sendo um agente professor e trs agentes coletores. Os agentes
coletores monitoram as discusses que esto ocorrendo nas ferramentas de comunicao e analisam
quantitativamente esses dados. O agente professor envia esses dados ao professor-humano, na forma de
relatrios. Esses relatrios contm apenas dados quantitativos sobre o acesso dos estudantes s
ferramentas de comunicao, sendo informado, para cada ferramenta, o nmero de acessos por estudante,
o nmero de mensagens trocadas e as interaes entre aluno-aluno, aluno-assunto e aluno-aluno-assunto.
Com os dados das interaes do tipo aluno-aluno possvel identificar os alunos que mais interagem
entre si. Os tpicos que mais interessaram a cada um dos alunos podem ser descobertos pelos dados da
interao aluno-assunto. J, a interao do tipo aluno-aluno-assunto, identifica os assuntos mais
discutidos entre um grupo de alunos.
Alguns ambientes propem o uso de arquivos de log de acesso do servidor Web para coletar
informaes. Niegemann [5] apresenta a ferramenta EDASEQ (Exploratory Data Analysis for Sequential
Data) para auxlio anlise de trajetrias de navegao dos estudantes. A ferramenta percorre o arquivo
de log do servidor Web, converte os dados para um arquivo no Excel e gera grficos sobre a navegao
dos estudantes dos cursos. Porm, necessria uma anlise humana para retirar-se informao importante
destes grficos. Segundo Niegemann, a ferramenta ainda no foi utilizada com dados reais de navegao,
dados fictcios foram produzidos para testar a funcionalidade da ferramenta.
O modelo de monitoramento apresentado por Peled [7] composto por um filtro que retira dos
arquivos de log informaes consideradas desnecessrias como: o tipo de navegador usado, os acessos
gerados por cliques duplos, acessos de professores ou administradores do curso, atividades
administrativas, login, etc. Os dados resultantes destas filtragens ficam contidos em arquivos do tipo
texto. Este sistema foi testado em um curso com 200 estudantes, porm nenhuma ferramenta ainda tinha
sido desenvolvida para tornar a visualizao destas informaes mais facilitada. Uma anlise exaustiva
nos arquivos textos gerados necessria, o que torna o processo invivel.
Conforme se observa nas pesquisas atuais, a maioria das tcnicas utilizadas oferece relatrios finais
com os dados de acesso e geralmente feita uma anlise humana para retirar-se informao importante
desses relatrios. O professor deve buscar essas informaes para cada estudante e no recebe um aviso
do que est acontecendo no processo de aprendizagem. H uma necessidade de alternativas, para que,
mesmo distncia, possa-se obter informaes sobre o comportamento do estudante e que esses dados
tambm sejam considerados no processo de avaliao.
3 Sistema de Alertas
Uma soluo para o problema apresentado na seo 2 o uso de um sistema de alertas que monitora os
processos de interao dos alunos com o ambiente do curso e gera um histrico da navegao. Uma
anlise neste histrico realizada pelo sistema de alertas e quando determinadas situaes so detectadas,
o professor avisado sobre o que est ocorrendo com alguns estudantes. Com isso, o sistema pode
descobrir quando um estudante realiza uma parada significativa em alguma parte do curso, o que pode
significar o no entendimento ou aprofundamento do contedo abordado. Os dados dessa anlise tambm
podem ser usados para auxiliar os alunos em suas sesses de estudo, estimulando-os, indicando material
complementar, exerccios, etc. O coordenador do material instrucional tambm beneficiado pelo uso de
um sistema de alertas, pois pode receber avisos sobre as pginas que no esto sendo acessadas e outras
informaes sobre possveis problemas na estrutura do site.
O gerenciador de alertas, apresentado neste trabalho, foi implementado na forma de biblioteca de
funes e desenvolvido com abordagem de software livre. Estes requisitos so importantes, pois facilita a
integrao do gerenciador com qualquer ambiente de ensino a distncia baseado na Web. A arquitetura
do Gerenciador de Alertas apresentada na figura 1.
Sistema de Alertas
1
Ambiente de
Monitor de EAD na Web
Editor de alertas Base de dados Eventos
Administrador Aluno
3
2
Mdulo de Gerenciador Base de dados

Monitorao Log de Alertas Ambiente EAD
Figura 1 Arquitetura do gerenciador de alertas
O sistema de alertas composto pelos seguintes mdulos: Editor de alertas, monitor de eventos,
mdulo de monitorao, base de dados, Log e gerenciador de alertas, os quais so apresentados em
detalhes nas prximas sub-sees.
3.1 Criao e Edio de Alertas

O Editor de alertas utilizado pelos professores ou administradores dos cursos para definio dos
alertas utilizados no acompanhamento das atividades dos alunos. Neste ambiente, cada professor pode
criar seus prprios alertas para seus cursos ou selecionar alertas j definidos por outros professores. A
figura 2 mostra a interface do usurio para a definio de alertas na implementao atual do sistema.
Figura 2 Interface do Editor de Alertas
Um alerta composto por: um evento de disparo, uma ou mais condies que devem ser verificadas e
a ao que deve ser realizada. Os eventos so indicadores de situaes ocorridas e podem ser de dois
tipos: (1) eventos do ambiente: so eventos gerados pelo professor ou aluno durante a sua interao com
o ambiente de ensino. Exemplos de eventos deste tipo podem ser o logon do aluno, trmino de algum
exerccio ou acesso a uma determinada pgina; (2) eventos temporais: algumas situaes devem ser
checadas em um determinado perodo de tempo, como por exemplo: uma vez por semana. Este tipo de
evento dependente de um tempo e no de alguma situao que tenha ocorrido devido a interao do
usurio no ambiente de ensino.
No momento de criao do alerta, o professor seleciona o evento de disparo do alerta. Na

implementao atual do sistema, o professor no pode incluir um novo evento, ele apenas escolhe os
eventos de uma lista j pr-definida pelo administrador do sistema de alertas.
Outra informao que deve ser informada no momento de criao de um alerta a condio a ser
testada, na ocorrncia do evento de disparo. Hoje, a condio informada para o sistema na forma de
consultas SQL, o que exige uma noo desta linguagem por parte do professor e tambm do
conhecimento sobre a estrutura do modelo de dados do ambiente. J est sendo estudada, uma soluo
que exporte para o professor a estrutura lgica do ambiente de ensino e um outra forma de representao
das condies, de maneira que o professor possa criar seus alertas sem o conhecimento da linguagem
SQL.
A ao do alerta tambm deve ser informada no momento de criao do alerta, e pode ser de dois
tipos: mensagem no navegador ou e-mail. O destinatrio da mensagem deve ser informado, o qual pode
ser o professor, aluno ou administrador do curso. O tipo de ao e o destinatrio so selecionados de uma

lista j definida, no sendo possvel a insero de uma nova ao ou destinatrio.
As situaes que necessitam de envio de alertas e as aes a serem tomadas, foram definidas por um
grupo de psiclogos e pedagogos, como parte das pesquisas do projeto ao qual este trabalho est inserido.
Mais detalhes sobre a definio dessas situaes e aes podem ser encontradas em Tapejara [TAP
2001].
Os dados informados para a criao de um alerta so armazenados na base de dados(1) da figura 2.

Operao de consulta, excluso e incluso de novos alertas so possveis via Editor de alertas, sendo que
um alerta j definido por um professor, pode ser aproveitado por qualquer outro professor do sistema.
3.2 Monitorao
O gerenciador de alertas utiliza-se de um mecanismo de monitorao que responsvel por armazenar,
na base de dados-log (2), todas as informaes sobre a atividade dos usurios no curso e refere-se s
sesses e seqncia de pginas acessadas pelos usurios. As informaes armazenadas so: (1) user_id:
cdigo de identificao do usurio; (2) IP: endereo IP da mquina que acessou o ambiente de ensino; (3)
page_id: URL da pgina que o usurio acessou; (4): access_datetime: data e hora de acesso pgina; (5)
course_id: identificao do curso em que o usurio est logado no momento em que faz acesso pgina
em questo; (6) session_id:, identificador da sesso em que o usurio est logado no momento em que
acessa uma pgina. Se o identificador de sesso no estiver disponvel no ambiente de ensino no qual est
sendo feita a monitorao, este pode ser calculado ou definido na configurao inicial do mdulo de
monitorao.
A gerao das informaes sobre a atividade dos usurios no curso, comea a ser produzida a partir do
momento que o usurio inicia a sua sesso de estudo. A partir da, qualquer operao efetuada
armazenada na base de dados (log). Quando o aluno acessa uma pgina do tipo exerccios, o nmero de
acertos e o nmero de erros em cada exerccio tambm so armazenados na base de dados (log).
Tambm fazem parte do processo de monitorao alguns ndices definidos pelo grupo de psiclogos e
pedagogos, pesquisadores do projeto ao qual este trabalho est inserido. Estes ndices so resultados de
anlises sobre os dados armazenados e so calculados no momento em que forem necessrios, no sendo
registrados na base de dados (log). Estes ndices, refletem o processo de navegao do aluno no curso.
Alguns desses ndices so apresentados abaixo. Uma descrio mais detalhada destes ndices pode ser
encontrada em Tapejara [TAP 2001].
Um exemplo de situao monitorada apresentada na tabela 1.
Tabela 1 Exemplo de monitorao
user id IP page code cours id access datetime session id
26 143.54.13.149 191 trabalhos.html INF01191 2003-02-21 15:30:27 1

O aluno de id=26, acessou a pgina 191_trabalho.htm do curso INF0119 no dia 2003-02-21, s
15:30 horas, sendo a sua sesso de nmero 1 no dia. O mdulo de monitorao armazena estas
informaes na base de dados (log).
3.3 Gerenciador de Alertas

O gerenciador de alertas recebe um aviso do Monitor de eventos informando a ocorrncia de alguma
situao importante. Aps este aviso, o gerenciador de alertas, acessa a base de dados do sistema de
alertas para verificar as condies associadas quele evento. Logo em seguida, a base de dados (log)
consultada de forma a testar a condio definida. Se a condio for verdadeira, a ao indicada na base de
dados do sistema de alertas realizada.
O gerenciador de alertas, tambm armazena um histrico de todos os alertas gerados de modo a
realizar estatsticas sobre o aproveitamento dos alunos no curso.
4 Integrao do Sistema de alertas no Ambiente de ensino a distncia-Claroline

O sistema de alertas apresentado na seo anterior foi integrado a um ambiente de ensino a distncia
de forma que se pudessem identificar quais os principais requisitos de integrao de sistemas de alertas
com ambientes de ensino a distncia. Esta seo descreve, em detalhes, tal integrao. O sistema de
alertas foi integrado ao ambiente Claroline [1]. Claroline um ambiente de ensino a distncia
desenvolvido pela UCL (Universit catholique du Louvain) que segue a filosofia de software livre.
Atualmente, uma instalao do Claroline est sendo usada por 500 alunos e 20 professores do Instituto de
Informtica da UFRGS. Os professores utilizam o ambiente para disponibilizao de contedo
educacional, exerccios e agendamento de tarefas, como complemento s aulas presencias.
Alguns motivos foram determinantes na escolha do Claroline. Primeiro, o ambiente adota a poltica de
licena GPL para software livre, requisito importante para este trabalho. Segundo, o Claroline foi
desenvolvido em linguagem PHP e base de dados MySQL, as mesmas usadas para implementao do
sistema de alertas, o que facilita a integrao dos sistemas. O cdigo fonte do ambiente de simples
entendimento, pois sua estrutura contm variveis de ambiente e bibliotecas de funes, o que auxilia no
acrscimo de outros mdulos de software.
4.1 Arquivo de configurao

Obviamente, uma primeira necessidade de integrao est associada comunicao do sistema de
monitorao com os dados registrados pelo ambiente de EAD em uma base de dados. Os dados contidos
nessa base de dados so de extrema importncia para o sistema de alertas, pois as condies que devem
ser checadas e as aes realizadas por um alerta, utilizam esses dados. No caso especfico do Claroline,
um arquivo de configurao foi o meio pelo qual tal comunicao se tornou possvel [10].
Na nossa integrao, o arquivo de configurao fornece informaes sobre o acesso a base de EAD do
Claroline. O arquivo de configurao formado pelos seguintes campos:
- DATABASE, banco MySQL que contm os dados do ambiente de ensino;
- MYSQLUSER, usurio que tem acesso de leitura e escrita no banco de dados do ambiente;
- MYSQLPASSWORD, senha do usurio de acesso ao banco de dados;
- USERTABLE, tabela no banco de dados que contm os dados referente aos usurios do
ambiente (e.g. nome, identificador de usurio e e-mail);
- USERFIELD, atributo da tabela definida em USERTABLE que possui o cdigo de
identificao do usurio;
- USEREMAIL: atributo da tabela definida em USERTABLE que possui o endereo de e-mail
do usurio;
- ADMINCONDITION: identificao de usurio do tipo administrador;
- TUTORCONDITION: identificao de usurio do tipo professor;
- STUDENTCONDITION: identificao de usurio do tipo aluno.
Os dados que compem o arquivo de configurao devem ser fornecidos pelo administrador do
ambiente de EAD, j que tal administrador quem conhece os detalhes administrativos do ambiente. A
soluo atravs de arquivo de configurao permite que o sistema de monitorao rapidamente tenha
acesso aos dados crticos para a monitorao. Obviamente que a integrao facilitada se a base de EAD
for implementada atravs de MySQL, como o caso do Claroline. Na integrao com outros ambientes
de EAD que no utilizam MySQL a integrao tambm deve contm, alm do arquivo de configurao,
adaptaes para o acesso base no baseada em MySQL.
4.2 Monitorao
O mdulo de monitorao a base para o sistema de alertas, pois sem os resultados da monitorao,
no seria possvel a gerao de alertas. O ambiente Claroline j possui em sua estrutura um mecanismo
que armazena no banco de dados: a data e hora que um determinado aluno realizou login no ambiente, o
curso que ele acessou, e o identificador da sesso de estudo. Esse mecanismo precisou ser alterado, de
forma a armazenar os outros dados importantes para o sistema de alertas. Esses dados so: IP do aluno,
URL da pgina acessada, nmero de erros e acertos nos exerccios. Em todas as pginas do ambiente,
que se deseja monitorar o acesso, foi includo o cdigo PHP apresentado na Figura 3, que realiza uma
chamada funo StudentMonitor do gerenciador de alertas.
include(..\..\Gerenciador\ManagerUtils.lib);
...
StudentMonitor($uid,AGENDA,$currentCourseID);
...
Figura 3 Exemplo de script PHP de monitorao [10]
No exemplo, quando o aluno acessa a pgina de agenda do curso, um registro no banco de dados
inserido. Esse registro refere-se a pgina acessada, data e hora de acesso, identificador do usurio, IP,
identificador do curso e identificador de sesso. Uma vantagem de termos usado o ambiente Claroline, foi
a de ele j possuir algum mecanismo de monitorao, o que normalmente no existe nos ambientes de
ensino a distncia baseados na Web. Esse mecanismo preliminar facilitou a incorporao do mecanismo
de monitorao necessrio ao ambiente de ensino. Em ambientes que no possuem nenhum mecanismo
de monitorao, este processo deve ser adicionado da mesma forma, mas obviamente acaba por se tornar
uma tarefa relativamente complexa.
4.3 Testes de implementao

A fim de validar a integrao do sistema de alertas no ambiente Claroline, alguns alertas foram
definidos e colocados em funcionamento no ambiente.
A figura 4 ilustra um exemplo de alerta utilizado em um dos testes realizado. Tal alerta envia uma
mensagem para o navegador do aluno durante a sua interao com o ambiente. Quando o sistema de
alertas percebe que o aluno no est acessando, por exemplo, a pgina de exerccios, a seguinte
mensagem enviada.
Figura 4 Exemplo de alerta enviado ao Claroline
Em conversas informais com alguns alunos e professores, que utilizaram o sistema e receberam alertas,
pode-se notar que os mesmos acharam interesssante receber alguns tipos de alertas e acharam
inconvenientes outros tipos. Os alertas que sugerem aos alunos um contedo a ser estudado ou um
exerccio a ser realizado, foram considerados bons. Alertas que enviam ao aluno um e-mail lembrando-o
de acessar o curso, aps um perodo de inatividade, foram considerados inoportunos.
Uma sugesto dada pelos professores seria o envio de alertas aps um determinado perodo de tempo.
Ou seja, agrupar os alertas gerados em um conjunto maior, e ento envia-los ao usurio. Esta sugesto
pode ser aplicada para alguns tipos de alertas. Em outros tipos, esta sugesto no se aplica, pois o usurio
deve ser informado no momento que ocorre o evento.
Concluses e Trabalhos Futuros

O sistema de alertas apresentado neste artigo foi implementado como um mdulo genrico de modo
que possa ser acoplado em outros ambientes de ensino baseado na Web. Visando validar o uso deste
sistema em um ambiente de EAD em produo, o mesmo foi integrado ao ambiente Claroline, que est
em uso por um grande nmero de usurios, entre alunos e professores do Instituto de Informtica da
UFRGS.
O processo de integrao do sistema de alertas com o ambiente Claroline foi facilitado principalmente
porque os dois sistemas utilizam a mesma tecnologia de base de dados (MySQL) e linguagem de
programao (PHP). Caso o sistema escolhido, utilizasse outra base de dados, um mecanismo de acesso a
esta base deveria ser implementado. Uma vantagem foi a escolha de um ambiente desenvolvido na
poltica de software livre, pois assim tivemos acesso a todo o cdigo-fonte e a base de dados, podendo
alter-los quando necessrio. Uma das dificuldades encontradas na integrao foi o fato de o sistema de
alertas necessitar do administrador do ambiente de EAD para informar dados sobre a base de dados do
ambiente de ensino. Alm disso, as condies dos alertas serem expressas na forma de consultas SQL,
limita o uso do ambiente. J est sendo investigada uma maneira de resolver essas dificuldades, sendo
pesquisada uma maneira de informar os dados do ambiente de ensino sem precisar diretamente do
administrador do ambiente, e uma linguagem ou editor que possua condies j definidas para uso no
momento de edio dos alertas.
Com os alertas que esto sendo gerados no ambiente Claroline, possvel capturar os dados que so
essenciais para a validao desse modelo tanto para o acompanhamento das atividades dos alunos como
uma maneira de mant-los motivados no curso em que esto cursando. Alguns resultados j foram
obtidos e mostram-se bem promissores e so importantes indicativos para a validao do sistema.
Espera-se que esta experincia possa dar mais um passo para que a Educao a Distncia seja uma
alternativa vivel no processo educacional.
Referncias
[1] Claroline (2003) Ambiente de Gerenciamento de Cursos:Claroline. Disponvel em:
http://www.claroline.net.
[2] Haydt, R. C. (1997) Avaliao do processo Ensino-Aprendizagem. So Paulo: tica, 1997.
[3] Jaques, P. A. (1999) Agentes de Software na Monitorao da Colaborao em Ambientes
Telemticos de Ensino. Porto Alegre, 1999. 89f. Dissertao (Mestrado em Informtica) - Faculdade de
Informtica, PUCRS, 1999.
[4] Musa, D. L. (2001) Um Sistema de Alertas Inteligentes para Ambientes de Ensino na Internet. Porto
Alegre: PPGC UFRGS. Dissertao de Mestrado.
[5] Niegemann, H. (2002) EDASEQ A log file analysis program for assessing navigation processes
Proceedings of the 8th International Conference on Computers in Education / International
Conference on Computer-Assisted Instruction 2000. Taipei, Taiwan.
[6] Otsuka, J. L.; LACHI, R. L.; VAHL, J.C.; ROCHA, H. V.(2002) Uso de Agentes de Interface no
Ambiente TelEduc. In: IV Workshop de Ambientes de aprendizagem baseados em agentes, XIII
Simpsio Brasileiro de Informtica na Educao (SBIE 2002) . So Leopoldo, 12-14 de novembro,
2002.
[7] Peled, A. (1999) Logging for Sucess - Advancing the Use to Improve Computer Mediated Distance
Learning - Journal of Educational Computing Research. v. 21, n. 3, 1999.
[8] Rahkila, M, Karjalainen, M. (1999) Evaluation of Learning in Computert Based Education Using
Log Systems. 29th ASEE/IEEE Frontiers in Education Conference, (San Juan, Puerto Rico, 1999).
Pp. 16-21, 1999.
[9] Roda, C. A multi-agent system for advising and monitoring students navigating instructional Web
sites." In 6th International Conference on Information Systems Analysis and Synthesis (ISAS 2000),
Special session on Cooperative and Distance Learning. Orlando, Florida. July 2000. 505-509
[10]Sisson, Gustavo A. (2002) Gerenciador de Alertas para um Ambiente de Ensino a Distncia na
Internet. Porto Alegre: CIC UFRGS, 2002. Trabalho de Diplomao.
[11] Tapejara (2001) Determinao dos ndices e indicadores das trajetrias de aprendizagem de sujeitos
submetidos ao ensino tutorializado e assncrono pela Internet. Relatrio Tcnico.
[12]Viccari, Rosa. (1998) Artificial Intelligence and Educacional Systems. Journal of School n.2, Olivais,
vol I, 1998.
On Evolution of XML Work ow Schemata
Fabio Zschornack, Nina Edelweiss

Universidade Federal do Rio Grande do Sul { UFRGS
Instituto de Informatica
Caixa Postal 15064 { 91501-970 { Porto Alegre, RS, Brazil
ffabiozs, ninag@inf.ufrgs.br
Abstract
XML is arising as a new format to represent the enterprises' business processes, since it is a exible and
interchangeable language. In the work ow area, one of the most discussed questions is the evolution of the
work ow representations, in order to meet new requirements. Despite the number of existing proposals,
none of them deals with evolution of work ows that use the XML syntax. In this paper, we present a
proposal for work ow evolution in which the work ow schema is represented in XML. The proposal is based
on versioning concepts, that allow the storage and use of dierent versions of the same work ow schema.
An evolution architecture is proposed, in order to separate the involved concepts in a set of managers. Two
of these managers are discussed in depth in this paper { Version Manager and Modication Manager. The
Version Manager handles (schema) versions and the Modication Manager controls the changes that can
be applied over them.
1 Introduction
Enterprises are driven by business processes, and tipically use work ow technology in order to achieve
better results. According to [16], work ow is the automation of a business process, in whole or part, during
which documents, information or tasks are passed from one participant to another for action, according
to a set of procedural rules. A work ow management system (WFMS) completely denes, manages and
executes work ows through the execution of software whose order of execution is driven by a computer
representation of the work ow logic [15].
A work ow can be represented in dierent formats (e.g. Petri nets, graph models, statecharts). Nowa-
days, XML is arising as an interesting way of work ow modeling [17, 1, 4], mainly due to features like
exibility and interchange facilities, specially in e-commerce environments [10, 11].
One of the most important questions in work ow management is the dynamic behaviour of business
processes. This re ects in work ow construction, that in many cases cannot be dened completely in
advance or must be modied when external or internal changes occur. Although there are some proposals
that deal with work ow evolution issues (e.g. [3, 12, 9]), there is a lack of suitable mechanisms to model
evolution when work ow is represented in XML, regarding specially the hierarchical arrangement of its
elements.
In this paper, we propose an evolution architecture to manage modications of XML work ows, based
on versioning features. In summary, we make the following contributions:
We present a language that models work ow versions in XML in an hierarchical way.
We propose a versioning approach in order to store many alternative versions for the same schema,
thus preserving the whole history.
We present a set of generic modication operations, which can be used to change a schema version.
We show how generic operations are implemented in terms of an existing XML update language.
The remainder of this paper is organized as follows. Section 2 presents an overview of our evolution
architecture, describing shortly its constituent parts. An example is shown in section 3, that motivates
the need of evolution and serves as a basis for the illustrations in the other sections. Section 4 describes
the language used to represent XML work ow and the schema version management approach. In section 5
we present the modication strategy to change work ow schema versions. In section 6 we present some
related work. We conclude the paper and point out some future work in section 7.
2 Evolution Architecture Overview

In order to allow the denition and management of work ow versions, an evolution architecture is here
proposed. It deals with the pair schema-instances, in which the schema is the work ow representation
that acts as a pattern, and the instances are the enactments (or executions) of a particular schema. In our
approach, the schema can hold many versions, so that instances are, in fact, bound to schema versions.
The evolution architecture, presented in gure 1, is divided into three major parts:
Figure 1: Overview of the proposed evolution architecture

Interface { this layer allows the work ow administrator to execute some high-level operations related
to schema evolution and versioning as well as instances manipulation. These operations act on the
respective modules in the underlying layer.
Evolution Management { constitutes the core of the architecture. It contains a set of modules
(managers) that eectively accomplish the operations dened in the interface. Four modules are
dened in this layer:
{ Version Manager { this module deals with the work ow schemata and their component versions.
Among its responsibilities, the Version Manager validates the schema specication passed by the
administrator and controls the whole versions' lifecycle, from their creation to their deletion. The
relationships among versions of a same schema are stored in a structure named Versioned Schema.
{ Modication Manager { this module implements changes on a specic version, previously created.
All versions are kept for historical purposes. This module also veries the correctness of the version
after the application of the modications.
{ Instance Manager { this manager creates a new work ow instance based on a schema version
specied by the respective operation on the interface.
{ Propagation Manager { when a modication occurs, it must be guaranteed that all enacted in-
stances will continue their executions properly. The Propagation Manager is responsible of mi-
grating/adapting the aected instances to the new schema version, according to their execution
points.
Repository { all information handled by the Evolution Management layer is stored in a repository.
Since work ow schemata are represented in XML (see section 4.1), the repository is preferentially
an XML native database. The upper layer can also retrieve and modify the documents, whenever
necessary.
This paper details the rst two managers, addressing the creation and maintenance of schemata and
versions (Version Manager), as well as changes that can be applied over versions (Modication Manager).
The other two managers (Instance Manager and Propagation Manager) are beyond the scope of this
paper.
3 A Motivating Example
We illustrate the need of evolving work ow with an example, adapted from [4]. It is an on-demand
computers assembly process, that is divided into two basic parts: the order reception from the customer
and the computer assembly. In the rst part of the process, some checks are performed in the incoming
order, like budget and technical checks. The order must also be approved by a responsible person. After
the successful conclusion of the rst part, the ordered computers can be assembled. The organization
must then request third-party components, since they do not have stocks. At the end of this process, the
ordered computers are sent to the customer. Figure 2 shows the described process, denominated P 1, in a
graphical fashion.
Figure 2: Work ow P 1
Later the process must to be changed, in order to cope new internal requirements. The manager, from
that point on, approves all orders, while the vice-president is freed from this responsibility. Another
change is that deliver and billing tasks must be done in parallel, saving time in the entire process. So,
based on P 1, we can create a new representation, P 2, that holds the process variant. The orders that
have started under P 1 can be concluded normally, with no modications in their executions.
4 Version-based Schema Representation

The architecture presented in section 2 is conceived to deal with any form of work ow representation.
However, since we are considering evolution in an XML environment, our work ows are modeled in XML,
as follows.
4.1 Work ow Representation in XML

The conceptual basis of our work ow schema modeling language is the structured work ow as dened in
[8]. Brie y, a structured work ow consists of an activity S , that can be atomic or complex. An atomic
activity cannot be decomposed any further. On the other hand, a complex activity consists of a sequential,
parallel, conditional, or loop structure, each of which is either atomic or complex. Figure 3 illustrates
the concepts above, where X and Y are atomic or complex activities.
Figure 3: Structured work ows [8]

All the activities (atomic or complex) in structured work ows are properly nested, in other words, the
structures cannot be overlapped. The result of this is that deadlock and lack of syncronism, two critical
problems in work ow modeling [13], are completely avoided. The nesting feature is inherent to well-formed
XML documents [18], which impose the total \enclosure" of the respective elements. So, XML can be
used to represent structured work ows.
A language to model work ows in XML, taking into account evolution questions, is presented in [20].
The language is based on proposals like XRL [1] and WQM [4]. Only the control ow is represented,
disregarding other aspects like data ow and the organizational model. We adopt this strategy mainly
because the most important changes on work ows are applied to their control ows, according to the
number of existing proposals in the literature [3, 6, 9, 7, 5].
Figure 4 depicts the hierarchical representation (XML Schema) of the elements dened in [20], using
the notation of XML Spy tool [2]. Elements are modeled by rectangles, dotted lines represent optional
elements/relationships, and full lines represent required ones. Attributes are omitted in this gure. The
process element embodies all the structures, being the unique starting and ending point of the control
ow. Inside this element, one component is allowed, which can be a simple activity (activity element) or
a complex structure (sequence, parallel, conditional, or loop element). A sequence element can hold one
or more components, denoting that the various internal elements will be executed in a sequential way. A
parallel element is sintatically similar to sequence, holding many components. However, the semantics
is dierent, since a parallel structure can execute the internal elements at the same time. A conditional
Figure 4: Structural hierarchy of the work ow modeling language
element can have only two internal elements: true and false. A condition is evaluated at the start of the
structure execution and depending on the boolean result, the right path is chosen. Into true and false,
only one component can be put. The same happens with the loop element, which executes a simple or
complex activity repeatedly.
Figure 5 shows the work ow process P 1 described in section 3 according to the language dened above.
A document that follows the specication described in this section is named a work ow schema version.
To create a new work ow schema, the administrator uses the createSchema operation available in the
interface, passing a work ow specication document as a parameter to the Version Manager. In the
following section, the versioning approach used by the architecture is better explained.
4.2 Schema Versioning Approach

The Version Manager implements versioning in order to allow the storage of multiple alternatives for the
same work ow schema. This capability enables the maintenance of various active versions at the same
time, each one holding many enacted instances. Moreover, it permits the storage of the whole schema
derivation history, since our approach does not allow physical removal of (at least stable) versions.
The main attribution of the Version Manager is to control both schemata and versions in a suitable
way. This is performed through the use of a structure named Versioned Schema. One versioned schema
is dened for each created work ow schema. A versioned schema models the relationships among versions
of the respective work ow schema in a tree-based fashion. In other words, a specic version may have
many descendant versions, but only one ascendant (except the root version, which has no ascendants).
This can be represented in XML format as depicted in gure 6, that shows a versioned schema structure
of our work ow schema in section 3. According to this gure, the versioned-schema element contains two
versions, P 1 and P 2. The version P 1 is the parent of P 2, denoting that the former is the ancestor of the
latter. If another version is descendant from P 1, it is represented as a P 2 sibling.
A schema version can be created in two ways: (i ) by the createSchema operation (previously described),
or (ii ) by a derivation. In the former case, the work ow specication passed to the Version Manager
becomes the root version of the newly created versioned schema. This is the case of version P 1, that was
created by the administrator. In the latter case, the administrator uses a specic operation to derive a new
version that is similar to the original one. P 2 was created by a derivation on P 1, receiving modications
<?xml version="1.0"?>
<schema-version>
<process>
<sequence>
<loop until="order=`ok'">
<sequence>
<conditional condition="new_order">
<true>
<activity name="Enter order"/>
</true>
<false>
<activity name="Revise order"/>
</false>
</conditional>
<parallel>
<conditional condition="order>50000">
<true>
<activity name="Vice-pres apprv."/>
</true>
<false>
<activity name="Manager apprv."/>
</false>
</conditional>
<activity name="Technical check"/>
<activity name="Budget check"/>
</parallel>
</sequence>
</loop>
<parallel>
<activity name="Order video"/>
<activity name="Order card"/>
<activity name="Order case"/>
</parallel>
<activity name="Receive parts"/>
<activity name="Assemble"/>
<activity name="Deliver"/>
<activity name="Bill"/>
</sequence>
</process>
</schema-version>
Figure 5: Representation of P 1 in XML
<versioned-schema id="P">
<version name="P1">
<version name="P2"/>
...
</version>
</versioned-schema>
Figure 6: Versioned schema P represented in XML
further (section 5).

A schema version can assume a set of states, re ecting its evolution during lifetime, from creation to
the (logical) removal. Figure 7 shows the state diagram for a schema version, together with the operations
that perform the state transitions.
The states that a schema version can go through are described below:
Working { each new schema version is created in this state. It is a transient state, in which modication
operations can be applied over the version (see section 5). A version in the working state can be
physically deleted if necessary.
Stable { from this state on, all information about the version evolution is stored. This state is reached
through a promote operation, from the working state. In the stable state, new versions may be derived,
but no physical deletion is permited, since the version may have derived some other versions. The
delete can only be logical, preserving all version's behaviour.
Active { in the active state, it is possible to create new instances according to the schema version
Figure 7: State diagram of a schema version
representation (instances are beyond the scope of this paper), as well as to derive new versions. No
removal is allowed, since there can be enacted instances.
Suspended { this state is similar to active except that it cannot be used to create new instances. The
enacted ones can run their executions normally. New versions can be derived from this version, as in
stable and active states. It is possible to return to the active state, through an activate operation.
Discontinued { this is a state that leads to a logical removal of the version. However, this will only
take place when all the instances of this version nished their executions. The delete operation is done
automatically after the conclusion of the last instance.
Being substituted { as the discontinued state, this state leads the version to the logically removed
phase. Nevertheless, enacted instances must migrate to another version in order to continue their
executions. Instances adaptation is done by the Propagation Manager, not addressed in this paper.
Logically removed { in this state a version cannot derive new versions nor hold or create instances,
being stored for historical purposes only.
For each transition presented in gure 7, there is a correspondent operation in the interface. Table 1
shows the allowed operations in each one of the states dened above.
Table 1: Work ow version states and operations

Status Promote Derive Activate Suspend Deactivate Replace Delete
Working y n n n n n y (*)
Stable n y y n n n y (**)
Active n y n y y y n
Suspended n y y n y y n
Discontinued n n n n n y y (**)
Being Substituted n n n n n n y (**)
y - operation may be performed n - operation cannot be performed
* - physical delete ** - logical delete
In the approach proposed in this paper, the Version Manager also stores the version lifetime. This is
done by the life-cycle and status elements, shown in gure 4. Each operation is passed to the Version
Manager, that updates the version document accordingly. The status element has itime and (optionally)
ftime attributes, that store the initial and nal times when a state was the current one. In gure 8 the
states for schema version P 1 are shown, disregarding the control ow. The last status element does not
have a ftime attribute, denoting this is the current state.
5 Modication of Work ow Schema Versions

Our evolution architecture allows changes on work ow schemata in order to adequate them to new re-
quirements. Changes on schema versions are suitably handled by the Modication Manager, retrieving
<schema-version>
<life-cycle>
<status name="working" itime="1" ftime="2"/>
<status name="stable" itime="2" ftime="5"/>
<status name="active" itime="5" ftime="15"/>
<status name="discontinued" itime="15"/>
</life-cycle>
...
</schema-version>
Figure 8: States of schema version P 1
the right document and applying modications on it.

As described in section 4.2, a version can only be modied when it is in the working state. To assure
this constraint, the Modication Manager checks the current state of the version and performs the changes
only when allowed.
5.1 Generic Modication Operations

In general, a work ow can be modied in several ways. Activities may be inserted or deleted, new branches
may be added to a total or partial fork, activities can change their positions, among others [3, 7, 9, 5].
Concerning XML documents, modications can be delete, rename, insert (after/before), and replace
elements, attributes and/or PCDATA [14]. These operations can be applied in any XML document, that
must be further revalidated against a DTD or XML Schema, in order to correctness be guaranteed.
As our approach relies exclusively on XML documents to model work ow evolution, we take into
consideration those document operations that are useful or \make sense" when the document represents
a work ow. We identify four operations in this case, that may be executed in conjunction or not. They
are:
Insertion { a new component is put into the work ow document, in a specic position.
Deletion { this operation performs a removal of a component of the work ow document.
Movement { the position of a component is changed to other place on the same work ow document.
Structure transformation { a component is transformed to other component, thus changing its
original semantics.
The operations above act only on elements, since we are interested in control ow changes and attributes
have little in uence on such part.
Table 2: Operations allowed to the structures

Operation sequence
p parallel
p conditional loop
Insertion
Deletion
p-always possible -possible in restricted cases -not allowed
Table 2 is constructed analysing the structures presented in section 4.1 and considering that a work ow
document is valid and each operation is solely applied. We observe that the insertion operation can be
normally performed into sequence and parallel elements, because these structures accept more than one
direct sub-element. In conditional element, the operation can be done only if it inserts a false element,
since it is optional. While a loop permits only one direct sub-element, insertions are not allowed into it.
The deletion operation can be performed in a restricted way in case of sequence, parallel and conditional
elements, and is denied for loop. For sequence and parallel, deletion operation cannot result in less than
one sub-element. From the conditional element only the false sub-element can be removed, while no
removal is allowed in loop. The movement operation may be considered a composite operation, as it
combines an insertion and a deletion. So eects in the structures must be evaluated in a whole, following
the insertion and deletion rules. Finally, the structure transformation converts one complex structure to
another, whenever possible. In this way, the operation can only result in a valid document if it transforms
a sequence into a parallel or vice-versa, because these two structures are sintatically identical.
Obviously, these operations can be applied over a schema version in conjunction, modifying many parts
of the same version. Although each operation separately may carry the version to a invalid document,
the nal result must be a valid work ow schema version, as transactions in a traditional DBMS.
5.2 Operations Implementation

The Modication Manager can perform the operations described above using a modication language,
XUpdate [19]. XUpdate is designed to change any XML document, and can hold many modication
operations in it. This language was chosen because it describes the operations in XML syntax, so we have
all the components (versions, versioned schemata, modications) in a standard way of representation.
When a modication is needed, the administrator calls the changeSchema operation in the interface,
specifying the version to be modied and the XUpdate document that contains the changes. The operation
is passed to the Modication Manager, that retrieves the version and applies the changes over it, only
when the version is in the working state. The resulting document must be revalidated for correctness
purposes.
Each generic modication operation dened in section 5.1 can be mapped to one or more XUpdate
commands, in order to implement changes on work ow schema versions. In table 3 we present the generic
operations and the respective XUpdate commands that implements the operations.
Table 3: Implementation of the modication operations in XUpdate

Operation XUpdate command(s)
Insertion insert-before/insert-after/append
Deletion remove
Movement variable/value-of (+ insertion and deletion)
S. transf. rename
The insertion operation can be implemented in two ways: (i ) insert-before (insert-after), that puts
a new element before (after) a given element, and (ii ) append, that inserts a new element as the latest
child of another element. The deletion can be simply implemented by a remove command, that deletes an
element from the document. For the movement operation, we must use variable and value-of commands
in conjunction with one insertion and the deletion operations. The variable command binds an element to
a dened variable, while the value-of command restores an element. Finally the structure transformation
can be directly done by a rename command, that changes the name of an element.
Figure 9 illustrates the XUpdate document that is applied over P 2 in order to conform it to the new
requirements described in section 3.
6 Related Work
Regarding work ow evolution, work ow versioning and XML work ow modeling, there are some proposals
that can be taken into account. They are described in this section.
6.1 Work ow Evolution and Versioning

On the evolution side, the most important proposals are [3] and [12]. The former provides a set of
modication operations that allow to change a work ow schema and to migrate active instances to the
modied schema. However, versioning concepts are not considered, so there is only one active schema at
a moment and all instances must execute under it. The same drawback is present in [12]. But dierently
<xupdate:modifications version="1.0" xmlns:xupdate="http://www.xmldb.org/xupdate">
<xupdate:variable name="manager"
select="/schema-version/process/sequence/loop/sequence/parallel/conditional/false/
activity"/>
<xupdate:insert-before select="/schema-version/process/sequence/loop/sequence/parallel/
conditional">
<xupdate:value-of select="$manager"/>
</xupdate:insert-before>
<xupdate:remove select="/schema-version/process/sequence/loop/sequence/parallel/
conditional"/>
<xupdate:variable name="deliver" select="/schema-version/process/sequence/
activity[@name=`Deliver']"/>
<xupdate:variable name="bill" select="/schema-version/process/sequence/
activity[@name=`Bill']"/>
<xupdate:insert-after select="/schema-version/process/sequence/activity[@name=`Assemble']">
<xupdate:element name="parallel"/>
</xupdate:insert-after>
<xupdate:append select="/schema-version/process/sequence/parallel[2]">
<xupdate:value-of select="$deliver"/>
</xupdate:append>
<xupdate:append select="/schema-version/process/sequence/parallel[2]">
<xupdate:value-of select="$bill"/>
</xupdate:append>
<xupdate:remove select="/schema-version/process/sequence/activity[@name=`Deliver']"/>
<xupdate:remove select="/schema-version/process/sequence/activity[@name=`Bill']"/>
</xupdate:modifications>
Figure 9: XUpdate document applied on version P 2
from [3], that approach relies on an instance-based model, allowing ad-hoc changes on specic instances.
Compared with these two proposals, our approach has versioning features, that oer the storage of the
dierent version alternatives and allow many active schema versions, and is based on schemata rather
than on instances.
The proposals described in [9], [7], and [5] deal with the versioning concept. In the model presented in
[9], a schema is named a work ow type, and an instance is a work ow. Each schema is versioned, and
basic operations over versions are create, modify, and delete. A set of operations is dened, as well as
migration conditions, that rule new versions derivation and instances migration. However, since a delete
operation is provided, it can be possible to remove useless versions, not recording all history of a specic
schema. This is not allowed in our approach, because schema history would be aected. The proposal
developed by [5] is similar to [9], since it is also based on versioning concepts and provide modication
operations and migration rules. This approach provides an evolution strategy that is independent from
the work ow representation, preserving internal migration algorithms. In despite of this, the proposal has
the same disadvantage of the previous one, that is, the possibility of loss of useless versions. The proposal
presented in [7], although based in versioning, has limitations in respect to instances migration and does
not oer details of its modication operations. As the other two proposals, allows versions removal, which
is not permited by our approach.
6.2 Work ow Representation in XML

There are a few work ow modeling languages in XML. We point out three proposals: [1], [4], and [17].
The rst one is basically a language that enables document routing on the Internet, in order to enable
e-commerce partners to exchange information between them in a seamless way. The language is com-
posed by a set of basic building blocks, and semantics is expressed in terms of Petri Nets. The modeling
approach presented in [4] also works with building blocks (structures), the language being described in
terms of XML Query Algebra. The main objective of this proposal is to provide queries over work ows
constructed on this language. Finally, the language presented in [17] constitutes a generic model for busi-
ness processes interchange among dierent work ow modeling tools, designed by Work ow Management
Coalition (WfMC). In opposite of previous approaches, this one is not based on structures, modeling
transitions between activities in a explicit way. This feature helps in designing complex control ows, on
the other hand, work ow modications in this proposal are not intuitive to the user, since in most cases
attributes values must be changed to re ect the modication. Moreover, to ensure correctness of resulting
ows are sometimes a dicult task in the WfMC language, in contrast to structured proposals, where
this problem is almost trivial.
None of these proposals deal with questions like evolution or versioning of the work ow models. Our
work has enriched the two rst proposals, considering evolution aspects and versioning features.
7 Concluding Remarks and Future Work

This paper proposed an evolution architecture for work ow representations in XML, that regards version-
ing related to work ow schemata. The language that models work ows in XML is based on structures,
which are easy to manipulate. The use of versions increases the power of the evolution strategy, because
we can have many alternative versions at the same time, each active one with enacted instances. In
addition, our approach does not allow versions removal, which is permited in other proposals, considering
that the history maintenance enables queries over past versions and instances. We presented two specic
managers of the architecture, Version Manager and Modication Manager, that encapsulate all necessary
functionality to control work ow versions (and schemata) as well as modications over versions, respec-
tively. One of the main characteristics of this work is that all components (versions, versioned schemata,
and modications) are represented with the same syntax, XML. This is a desirable feature since we have
a unique form to manage and handle the components of the architecture.
As future work we point out the denition of the other managers of the architecture (Instance Manager
and Propagation Manager), in order to integrate all the proposed modules. To do so, we will dene the
structure of the instances and propagation policies to migrate/adapt aected instances to another version,
with little or no impact. We are also studying on a variation of XUpdate to implement the modication
operations, considering the structures of the representation language as basic elements. As another work,
we are analysing the better way to store all the documents. Finally, the integrated architecture will be
implemented and connected to a WFMS that deals with XML representations, in order to provide this
system with evolution capabilities and check the feasibility of the proposed architecture.
References
[1] W.M.P. van der Aalst and A. Kumar. XML Based Schema Denition for Support of Inter-
organizational Work ow. Technical report, University of Colorado, Boulder, 2000. Available at:
http://spot.colorado.edu/akhil/pubs.html.
[2] Altova Inc. XML Spy, 2003. Available at: http://www.xmlspy.com.
[3] F. Casati, S. Ceri, B. Pernici, and G. Pozzi. Work ow Evolution. Data & Knowledge Engineering,
24(3):211{238, January 1998.
[4] V. Christophides, R. Hull, and A. Kumar. Querying and Splicing of XML Work ows. In Proc.
of the 9th International Conference on Cooperative Information Systems, CoopIS, pages 386{402,
Trento, Italy, September 2001. Berlin, Springer-Verlag.
[5] P. Dias, P. Vieira, and A. Rito-Silva. Dynamic Evolution in Work ow Management Systems. In
Proc. of the 3rd International Workshop on Web Based Colaboration, WBC, pages 254{260, Prague,
Czech Republic, September 2003. Los Alamitos, IEEE Computer Society Press.
[6] J. Eder and W. Gruber. A Meta Model for Structured Work ows Supporting Work ow Transfor-
mation. In Proc. of the 6th East-European Conference on Advances in Databases and Information
Systems, ADBIS, pages 326{339, Bratislava, Slovakia, September 2002. Berlin, Springer-Verlag.
[7] G. Joeris and O. Herzog. Managing Evolving Work ow Specications. In Proc. of the 3rd Interna-
tional Conference on Cooperative Information Systems, CoopIS, pages 310{319, New York, August
1998. Los Alamitos, IEEE Computer Society Press.
[8] B. Kiepuszewski, A. H. M. ter Hofstede, and C. Bussler. On Structured Work ow Modelling. In

Proc. of the 12th Conference on Advanced Information Systems Engineering, CAiSE, pages 431{445,
Stockholm, Sweden, June 2000. Berlin, Springer-Verlag.
[9] M. Kradolfer and A. Geppert. Dynamic Work ow Schema Evolution Based on Work ow Type
Versioning and Work ow Migration. In Proc. of the 4th International Conference on Cooperative
Information Systems, CoopIS, pages 104{114, Edinburgh, Scotland, September 1999. Los Alamitos,
IEEE Computer Society Press.
[10] A. Kumar and J. Leon Zhao. Work ow Support for Electronic Commerce Applications. Decision
Support Systems, 32(3):265{278, January 2002.
[11] K. Lenz and A. Oberweis. Modeling Interorganizational Work ows with XML Nets. In Proc. of the
34th Annual Hawaii International Conference on System Sciences, HICSS, Maui, Hawaii, January
2001. Los Alamitos, IEEE Computer Society Press.
[12] M. Reichert and P. Dadam. ADEPTf lex { Supporting Dynamic Changes of Work ows Without
Loosing Control. Journal of Intelligent Information Systems, 10(2):93{129, March/April 1998.
[13] W. Sadiq and M. E. Orlowska. Applying Graph Reduction Techniques for Identifying Structural
Con icts in Process Models. In Proc. of the 11th Conference on Advanced Information Systems
Engineering, CAiSE, pages 195{209, Heidelberg, Germany, June 1999. Berlin, Springer-Verlag.
[14] I. Tatarinov, Z. G. Ives, A. Y. Halevy, and D. S. Weld. Updating XML. In Proc. of the ACM
SIGMOD International Conference on Management of Data, pages 413{424, Santa Barbara, USA,
May 2001. New York, ACM Press.
[15] Work ow Management Coalition. The Work ow Reference Model, January 1995. Available at:
http://www.wfmc.org/standards/docs.htm.
[16] Work ow Management Coalition. Terminology & Glossary, February 1999. Available at:
http://www.wfmc.org/standards/docs.htm.
[17] Work ow Management Coalition. XML Process Denition Language, Version 1.0, October 2002.
Available at: http://www.wfmc.org/standards/docs.htm.
[18] World Wide Web Consortium. Extensible Markup Language (XML) 1.0 (Second Edition), 2000.
Available at: http://www.w3.org/TR/REC-xml.
[19] XML:DB. XUpdate - XML Update Language, 2000. Available at: http://www.xmldb.org/xupdate.
[20] F. Zschornack and N. Edelweiss. Uma Linguagem para Representac~ao de Work ow em XML com
Suporte a Evoluc~ao e Versionamento de Esquemas. In Articulos de la XXVIII Conferencia Lati-
noamericana de Informatica, CLEI, Montevideo, Uruguay, November 2002. Montevideo, Universi-
dad de la Republica.
Desarrollo de Sistemas Domticos Guiado por Modelos
Javier Muoz, Joan Fons, Vicente Pelechano, Oscar Pastor
Dpto. de Sistemas Informticos y Computacin

Camino de Vera s/n, 46022
Valencia
{jmunoz, pele, jjfons, opastor}@dsic.upv.es
Resumen
La introduccin de las tecnologas de la informacin en el hogar ha dado lugar a un nuevo tipo de
sistemas informticos: los sistemas domticos. Actualmente, el estado de las tcnicas y mtodos para el
desarrollo de este tipo de sistemas se encuentra poco evolucionado. En la mayora de los casos se utilizan
tecnologas muy cercanas al espacio de la solucin. En este artculo se propone la aplicacin a este tipo
especfico de sistemas del enfoque de desarrollo basado en modelos (MDA), con generacin automtica de
cdigo. Para ello se propone un lenguaje de modelado de sistemas domticos independiente de tecnologas
de implementacin, y se proporcionan unas guas para realizar la transformacin de los modelos creados
con este lenguaje hacia OSGi, un estndar de la industria para el desarrollo de sistemas de gestin del
hogar digital.
1. Introduccin.
Las nuevas tecnologas de la informacin estn integrndose en el hogar de forma paulatina [1]. Este
proceso est dando lugar a un nuevo tipo de sistema informtico: los sistemas domticos. Aunque entre la
comunidad de desarrolladores de sistemas domticos se tiene una concepcin del rea muy centrada en las
tecnologas que se utilizan, en este artculo se entender que un sistema domtico es aquel sistema
informtico encargado de proporcionar servicios en el mbito del hogar o, en general, de los edificios. El
hogar del futuro, cada vez ms cercano, va a proporcionar a sus habitantes una gran variedad de servicios de
todo tipo (automatizacin, comunicaciones, multimedia, etc.) [2] que necesitan de un sistema de gestin
integrador que proporcione una visin homognea del mismo.
Actualmente no existe una gran difusin de los sistemas domticos debido en gran medida a que las
tecnologas que utilizaba hasta ahora todava no se encontraban maduras y, por tanto, tenan un precio muy
elevado. Esto est cambiando a gran velocidad debido a la aparicin de nuevos factores. La creacin de
estndares especficos [3,4], el descenso de los precios, el inters de los constructores y de grandes compaas
como Sun o Microsoft, hacen prever una aumento en el nmero y complejidad de los sistemas domticos [4].
Esto contrasta con el nivel de evolucin de los mtodos y tcnicas para su desarrollo, ya que la mayora utiliza
tecnologas de muy bajo nivel de abstraccin (programacin de microcontroladores o de redes de control de
dispositivos) que hacen que el desarrollo no sea eficiente y que el producto software no resulte escalable ni
mantenible. En este contexto parece necesaria una nueva generacin de mtodos de desarrollo para sistemas
domticos que aumenten el nivel de abstraccin del proceso. En este artculo se propone la utilizacin del
modelado conceptual dentro de un mtodo de generacin automtica de cdigo para lograr ese fin.
Actualmente, cuando un desarrollador desea aplicar los principios que postula MDA [5] se encuentra con
una serie de carencias bsicas. Existe una carencia de lenguajes que permitan expresar los modelos con
conceptos del dominio del problema (PIM) o con conceptos de una tecnologas (PSM). En general el
desarrollador se ver obligado a realizar un esfuerzo inicial para definir las primitivas adecuadas al dominio
de su aplicacin y a la tecnologa destino. Una vez realizado este paso se encontrar la siguiente carencia.
MDA tampoco propone qu transformaciones utilizar, ni tan siquiera como expresarlas. Esto hace que, de
nuevo, sea el desarrollador el que deba realizar esta tarea. En definitiva, adems de una filosofa de trabajo,
poco ms se puede utilizar directamente de MDA.
La estructura del trabajo es la siguiente. En el segundo apartado se realizar una descripcin de la

propuesta del Object Management Group (OMG) para el desarrollo basado en modelos. En el apartado 3 se
describe el lenguaje de modelado propuesto para la descripcin de los sistemas domticos de manera
independiente de tecnologa. En la seccin 4 se presenta OSGi, un estndar industrial para el desarrollo de
sistemas de gestin del hogar digital. En las seccin 5 se muestra cmo se pueden realizar las
transformaciones entre modelos y entre un modelo y cdigo fuente. Finalmente se presentan las conclusiones
del trabajo y se comentan trabajos relacionados con ste.
3. Home Automation MOdeling laNguage.

Los sistemas domticos poseen una serie de caractersticas que los diferencia de otros tipos de sistemas
informticos. En un sistema domtico la interaccin con el entorno fsico del sistema es un factor muy
importante. En el desarrollo de un sistema domtico es necesario establecer mecanismos para que pueda
extraer informacin del entorno y realizar acciones sobre l. Debido a ello, en el sistema domtico existirn
dispositivos que no sern computadores. Esto no es habitual en otros tipos de sistemas informticos como las
aplicaciones de gestin o los web.
Por otra parte, hay que destacar que un aspecto importante de los sistemas domticos es la integracin de
los distintos tipos de servicios que debe ofrecer: automatizacin, seguridad, comunicaciones, multimedia, etc.
Para ello se valdr tanto de elementos hardware, ya comentados en el parrafo anterior, como elementos
software (video bajo demanda, mensajera electrnica, etc.) .
Por todo esto, es necesario un lenguaje de modelado especfico que tenga en cuenta estas caractersticas y
proporcione a los desarrolladores primitivas intuitivas del dominio. En este artculo se propone Home
Automation MOdeling laNguage (HAMON) como lenguaje para el modelado conceptual de sistemas
domticos de manera independiente de tecnologa. El lenguaje se estructura en cuatro modelos: el modelo de
servicios, el modelo estructural del sistema, el modelo de configuracin y el modelo funcional.
Para ilustrar la descripcin del lenguaje se presenta un sencillo caso de estudio. Se trata de automatizar una
sala de visin de multimedia, de tal modo que cuando se inicie la reproduccin se debe reducir al quince por
ciento la iluminacin de la sala y aumentar la temperatura cinco grados respecto al estado actual. La sala se
debe iluminar al mximo cuando haya gente en ella, siempre y cuando no se encuentre reproduciendo una
pelcula. Existir una iluminacin secundaria, accionada por un interruptor, para poder accionar los controles
del servicio de reproduccin multimedia.
El primer paso en la construccin del modelo del sistema domtico es la descripcin de los distintos tipos
de servicios que van a utilizarse. Esto se realiza en el Modelo de Servicios. En HAMON, un servicio es una
agrupacin funcional. La descripcin de un servicio se realiza mediante sus operaciones, propiedades y el
contrarto. El contrato supone tanto la definicin de restricciones sobre la ejecucin de las operaciones como la
definicin de su comportamiento mediante un DTE. Un servicio tambin puede tener conceptualmente un
papel activo; por ejemplo, todo servicio de regulacin de temperatura deber encenderse cuando la
temperatura de la ubicacin en la que se encuentra descienda del umbral que tiene establecido. Para poder
expresar este comportamiento la descripcin de los servicios incluir disparadores. En el Modelo de Servicios
tambin se pueden definir relaciones entre stos. Las relaciones pueden ser de dos tipos: de
generalizacin/especializacin y de agregacin.
Figura 1. Modelo de servicios del sistema de ejemplo

En el Modelo Estructural del Sistema se incluyen las instancias de los servicios que van a existir en el sistema
y sus relaciones. Se trabaja a nivel de instancias porque, en este dominio, los requisitos del usuario van a venir
expresados de este modo. Adems, existen relaciones entre instancias de servicios que deben describirse a
este nivel. Por ejemplo, un servicio de deteccin de presencia puede utilizarse para activar la iluminacin,
encender la calefaccin, mandar un mensaje al propietario o iniciar la reproduccin de un multimedia, entre
otras acciones. Dicha relacin es especfica entre ciertas instancias de servicio, ya que no existe una relacin
conceptual entre los distintos tipos de servicio. Todo esto influir en la funcionalidad del servicio, ya que no
ser posible describirla completamente hasta conocer con que otros servicios se relaciona. Debido a estas
razones, es necesario realizar la descripcin de la estructura del sistema a nivel de instancia.
Figura 2. Modelo estructural del sistema de ejemplo
En definitiva, el modelo estructural se compondr de instancias de servicios y relaciones entre ellas. Las
relaciones podrn ser de dos tipos. Por un lado existirn enlaces, que vendrn determinados por las relaciones
de agregacin del modelo de servicios. Por otra parte se incluirn relaciones de dependencia de uso. Estas
relaciones se utilizarn para describir la necesidad de una instancia de utilizar las operaciones de otra. Por
tanto, con las relaciones de dependencia de uso se describirn las relaciones especficas de instancia, mientras
que con los enlaces se describirn las relaciones determinadas por el tipo de servicio.
Como se coment en la introduccin de esta seccin, en un sistema domtico es necesario incluir

informacin sobre los elementos hardware y software que van a interactuar con su entorno. Sin estos
elementos, el sistema no podra realizar la funcionalidad especificada. Para ello en HAMON es introduce el
Modelo de Configuracin.
En el modelo de configuracin se asociarn uno o ms proveedores de servicios a las instancias de

servicios que as lo requieran. Un proveedor de servicios es un elemento de modelado que proporcionar al
sistema domtico un servicio para la comunicacin con el entorno fsico o lgico del mismo. La descripcin
de un proveedor de servicios es idntica a la de un servicio (ver seccin 3) .
Para proporcionar al analista unas primitivas conceptuales ms adecuadas a este dominio, los provedores de
servicios pueden ser dispositivos, aunque estos no aaden ninguna semntica. Con el mismo propsito se han
incluido las primitivas sensor y efector como especializacin de los dispositivos. En este caso s que tienen
una semntica nueva. Los sensores slo podrn tener propiedades que capturan informacin sobre el entorno
del sistema. Los efectores slo podrn tener operaciones con las que actuar sobre dicho entorno.
Finalmente, el Modelo Funcional se utiliza para especificar las acciones que llevan a cabo las operaciones
de cada instancia de servicio del sistema. Debido a que, en ocasiones ser necesario utilizar los proveedores
de servicios para su completa especificacin, este modelo se desarrollar cuando se halla realizado el modelo
de configuracin.
En HAMON para la especificacin de las acciones se utilizar un subconjunto del lenguaje de acciones
semnticas (ASL) definido en la especificacin de UML [7]. Por lo tanto, cada operacin de una instancia de
servicio tendr asociado un mtodo que contendr dichas acciones. ASL no est asociado a ninguna
tecnologa de implementacin, por lo que el modelo conservar la independencia tecnolgica.
Television.reproducir( VideoBajoDemanda.media_seleccionado )
Salon.fijarTemperatura( Salon->TemperaturaSalon.temperatura 5 )
LuzSalon.fijarIntensidad( 15 )
Figura 3. Modelo funcional de la operacin iniciarReproduccion de la instancia

de servicio ReproduccionMultimedia
4. Open Service Gateway Initiative.

Open Service Gateway Initiative (OSGi) [8] es una asociacin de empresas creada con el fin de desarrollar
una especificacin abierta que facilite la prestacin de servicios a redes de dispositivos desde redes externas.
En este consorcio participan empresas multinacionales como Sun Microsystems, IBM, BMW, Oracle, Nokia,
Toshiba o Telefnica I+D.
La especificacin, que actualmente se encuentra en su versin 3.0, gira en torno al concepto de pasarela de
servicios. Una pasarela de servicios es el dispositivo que realiza las funciones de plataforma para la prestacin
de servicios. En el hogar, por ejemplo, la pasarela de servicios (o pasarela residencial, en este caso) estar
conectada a la red de control de dispositivos, la red interna de datos, la red multimedia del hogar y el acceso a
Internet. OSGi especifica un entorno de ejecucin para pasarelas de servicios que define representaciones
software para los distintos elementos del sistema (paquetes, servicios, dispositivos, drivers, etc.), las interfaces
y el comportamiento que deben cumplir estos y las relaciones entre ellos. Tambin proporciona funcionalidad
para la administracin del sistema (bsqueda de servicios, registro de eventos, gestin del ciclo de vida, etc.).
En definitiva, se trata de una tecnologa que proporciona cierto nivel de abstraccin respecto a la
implementacin final, por lo que resulta muy interesante para nuestro mtodo.
Figura 4. La pasarela residencial como punto de convergencia de las distintas redes del hogar
Aunque OSGi define las lneas bsicas de cmo deben ser las relaciones entre los distintos elementos del
sistema, es posible utilizarlo para realizar diversas arquitecturas. La arquitectura de referencia est ideada para
la gestin remota de los servicios, pero en la propia especificacin se describen brevemente otras alternativas
[8, sec. 2.4]. Por tanto, es necesario definir cual va a ser la arquitectura de los sistemas generados en nuestro
mtodo de produccin de software a partir de modelos.
Para nuestro trabajo estamos considerando una arquitectura centralizada en las que todos los dispositivos se
comunican nicamente con la pasarela residencial. Esta arquitectura es la ms sencilla porque permite
concentrar toda la lgica en un punto y slo es necesario generar cdigo para una tecnologa: OSGi. Para
especificarla se est desarrollando un metamodelo a partir del cual se generaran los modelos PSM expresados
en trminos OSGi/Java siguiendo la arquitectura definida. En la Fig. 5 puede ver una parte de dicho
metamodelo, en la que aparecen algunos de los principales elementos descritos en la especificacin de OSGi.
Figura 5. Principales elementos del metamodelo de OSGi en desarrollo
5. Transformaciones de Modelos.
Un paso clave para la aplicacin de un mtodo que siga una filosofa MDA es la transformacin entre
modelos a distintos niveles de abstraccin. En la especificacin de MDA nicamente se proponen posibles
aproximaciones para realizar esta tarea [5 sec. 3.10], pero no se indica qu tcnicas concretas se pueden
utilizar. Tradicionalmente se han empleado descripciones algortmicas sin una base formal subyacente. En la
actualidad existen diversas aproximaciones para la transformacin de modelos con una base formal [9]:
transformaciones de grafos, gramticas de grafos, reglas de reescritura o transformaciones XSL. En este
artculo se proponen las gramticas de grafos [10] para definir las transformaciones entre los modelos
independientes de plataforma creados con HAMON y los modelos de sistemas OSGi siguiendo la arquitectura
descrita por el metamodelo presentado en el apartado anterior. Las gramticas de grafos tienen una base
formal con mucha tradicin y pueden representarse grficamente, aunque despus es posible convertirlas a
ASL [9] o PROLOG [11].
Figura 6. Reglas para la transformacin de servicios HAMON en servicios OSGi
Finalmente, es necesario proporcionar tcnicas para la ltima de las transformaciones: la conversin del
modelo expresado en trminos de una plataforma especfica a cdigo fuente de dicha tecnologa. Aunque sera
posible la generacin directa desde los modelos independientes de plataforma, la transformacin intermedia
ayuda a disminuir la complejidad de esta labor, ya que se podr realizar de manera muy natural.
La generacin de cdigo es un campo en efervescencia tanto en la industria como en la comunidad

cientfica. Debido a las caractersticas propias del mtodo propuesto, se ha considerado que una opcin
adecuada podra ser la utilizacin de plantillas junto con un lenguaje de scripts que gestione el orden de
aplicacin de estas. Existen varios de estos lenguajes de plantillas para generacin de cdigo, como Velocity,
TL [12] o Jostraca.
public interface #//name# {
#for //Operation#
#//__create_code#
#end#
}
Figura 7. Plantilla para la generacin de cdigo de una interfaz Java

En la Fig. 7 se ha utilizado una sintaxis como la de TL para escribir una plantilla que convierte un elemento
de tipo JavaInteface en cdigo fuente. En dicha plantilla se realiza la sustitucin del nombre de la
interfaz y para cada una de las operaciones asociadas se invoca el mtodo que genera su cdigo.
6. Conclusiones y Trabajos Relacionados.

En este artculo se ha propuesto la aplicacin del desarrollo guiado por modelos al dominio de las
aplicaciones de gestin del hogar. Para ello se ha completado la propuesta MDA con una serie de tcnicas
concretas para la creacin de los modelos y las transformaciones de estos. Entre ellas se encuentra HAMON,
un lenguaje para el modelado independiente de plataforma de sistemas domticos que proporciona primitivas
intuitivas en el dominio. Por lo tanto, se contribuye al desarrollo de mtodos avanzados para la creacin de
sistemas de gestin del hogar.
HomeNet Tool es una herramienta grfica presentada en [20] que permite la programacin de la
funcionalidad del sistema relacionando eventos de los diversos dispositivos. Aunque es una aproximacin
bastante cercana a la propuesta en este artculo, carece de una semntica bien definida de todos los elementos
de modelado, lo que puede producir ambigedades en los modelos. SENDA [13] (SErvices and Networks for
Domotic Applications) es una propuesta basada en CORBA para proporcionar una infraestructura de soporte
al desarrollo de sistemas domticos que pretende ser una alternativa a OSGi. Aunque proporciona guas para
el modelado matemtico de los sistemas desarrollados con SENDA, el objetivo de estos es la simulacin, no la
generacin automtica de cdigo.
7. Referencias.
[_1] Ryan, J.L., Home Automation, Electronics & Communication Engineering Journal , Volume: 1 Issue: 4 , July-
Aug. 1989, pp 185-192.
[_2] Stepehn S. Intille, Designing a Home for the Future, Pervasive Computing, Abril-June 2002, pp 80-86.
[_3] Wacks, K. P., International Development of Home Automation Standards, Consumer Electronics, 1992. Digest
of Technical Papers. ICCE., IEEE 1992 International Conference on , 2-4 June 1992. pp 274 -275
[_4] Hwang. M., Jeon. Y., Kim. J., Standarization Activities and Technology Competitors for the In-Home
Networking, International Conference on Communication Technology, 1998.
[_5] Object Management Group. MDA Guide V1.0, 2001. http://www.omg. org/mda
[_6] Pastor, O., Gmez, J., Insfrn, E., Pelechano, V., The OO-Method Approach for Information Systems Modeling:
From Object-Oriented Conceptual Modeling to Automated Programming., Information Systems 26, 7 (2001).
Elservier Science, pp 507-534
[_7] Object Management Group. Unified Modeling Language V1.5, 2003.

http://www.omg.org/technology/documents/formal/uml.htm
[_8] Open Services Gateway Initiative, Osgi Services Platform. Release 3, 2003, http://www.osgi.org
[_9] Daniel Varr and Andrs Pataricza, UML Action Semantics for Model Transformations, International Journal
of Periodica Politechnica (in press), 2003.
[_10] Dorr, H. Efficient Graph Rewriting and its implementation, Lecture Notes in Computer Science, 922, 1995,
Springer.
[_11] Dniel Varr, Automated Program Generation for and by Model Transformation Systems, Proc. AGT 2002:
Workshop on Applied Graph Transformation, 2002.
[_12] J. Craig Cleaveland, Program Generators with XML and Java, Prentice-Hall, 2001.
[_13] F. Moya, J.C. Lpez, SENDA: An Alternative to OSGi for Large Scale Domotics. Networks, pp. 165-176,
World Scientific Publishing. 2002.
BMW A Systematic Process for Business Modelling Activity
Ana Alice do N. S. Monteiro Alexandre Vasconcelos

CESAR Centro de Estudos e Sistemas Universidade Federal de Pernambuco, Centro
Avanados do Recife de Informtica
ana.alice@cesar.org.br Caixa Postal 785, CEP 50732-970, Recife - PE,
Brasil
amlv@cin.ufpe.br
Abstract
This article presents a process flow (BMW Business Modelling Workflow) to aid in the definition of a work
system to accomplish business modelling activity. This process will serve as basis to focus on subjects related
with business semantics and information technology, aiding the perception and the communication between
the business area and software developers. It is also intended to minimize scope definition problems and
software requirement, through larger emphasis in problem understanding, business process and goals. BMW
has elements that structure and address its activities, which are guided essentially by phases that have
guidelines and targets.
1 Introduction
According to Falkenberg [4], in an organization, information systems should be developed to support and
aggregate value to the business processes. This suggests the importance that should be given to requirements
engineering, especially to requirements elicitation, the initial activity of the requirements engineering life
cycle, which beyond discovering users needs, also requests a careful organizational analysis, and its
relationship with the business domain and organizational processes [8].
The problems related to requirements understanding phase are high, especially if identified when the
system is already in operation [10] [16]. Concerning the cost, when identified in the initial phases, mistakes
usually demand an effort twice smaller than when identified in the system development final phases, and
faults detected in the early requirements bring serious operational consequences [15]. Another problem,
related to inadequate requirements knowledge, is that in according to Jones [7], usually the requirements
hidden in the users, i.e., those that are not clearly expressed by the users, can represent at least 30% of
increase of software functionality.
Observing those symptoms, and considering that, according to Bubenko [2] requirements engineering
denotes the area between business modelling and information system modelling and development. It looks
very promising to use business models in order to improve quality of requirements specification. So it
justified a reason for the interest in this area through a number of journals and annual international
conferences related to requirements engineering area.
Business modelling incites the requirements specification quality, considering that, business models serve
as an additional source of knowledge, for supporting effective communication and contractual negotiations
between different groups of people involved in the procurement process [2]. The main objective of any
business model is to represent a vehicle for communication of the human thought, facilitating the mutual
perception and understanding of some aspects of a common business reality [9]. The revelation of alternatives
for the use and applicability of the business modelling activity has been developing, presenting opportunities
and limitations. Several academic and industrial experiences can be observed in [3] and [12]. So, the business
modelling acquires a fundamental importance in the requirements elicitation process.
This article presents a strategy to guide the process of accomplishment of the business modelling activity.
In a wide vision, the process discusses the objectives, participants, phases and guidelines, proposing some
artefacts to register business information, and it still presents a set (group) of rules that aid in the identification
of elements that represent information about the businesses. The systematic of work proposed by that process
contains necessary activities to achieve the businesses modelling activity in the sense of promoting business
domain knowledge acquisition, favoring the requirements elicitation activity, through the elaboration of
models that can represent different concepts and information about the business. This article is organized as
follows. In section 2 we present business modelling context and some observations concerning the use of
models to understand business operations. Section 3 shows an overview of the proposed process and its
phases. Section 4 presents a study case in order to illustrate how the BMW process can be applied in a
practical manner. Finally, Section 5 presents the conclusions of this work.
2 Business modelling
Business modelling is the use of models and methods in the organizations to understand and change
business operations together with information systems development [11].
Methods of business modelling are used commonly by the organizations to describe and to represent their
businesses. The product resulting from a business model is usually used in the organizations as part of the
activities related with the business process re-engineering or initiatives of business processes improvement.
According to Tolis [14], the work of development of the business modelling can be applied in the strategic
level of the organizational context, in the level of business processes, and in the support to the information
systems and the information technology.
Several techniques have been proposed with the intention of promoting the representation of the
knowledge about business processes. The representation of those information is important to understand the
organization and their businesses and appropriately to elicit with more effectiveness and consistence the
intended information systems requirements. Among the main techniques of businesses modelling, can be
mentioned i* [18], EKD Enterprise Knowledge Development [1], BSDM Business System Development
Method [6]. i* consisting of two modelling components. The Strategic Dependency (SD) model describes a
process in terms if intentional dependency relationships among agents. The Strategic Rationale (SR) model
describes the issues and concerns that agents have about existing process and proposed alternatives. The EKD
method is a structural framework that includes a number of interrelated model types to describes and
document views, opinions and knowledge concerning the business, in its present state as well as its future
state. The BSDM Business System Development Method is an enterprise modelling method which was
introduced by IBM. It provides a modelling framework to capture and analyse a business operation and
requirements which helps the understanding of the complex business environment.
However, none of those techniques presents a systematic way that evidence guidelines to promote an
effective participation of the stakeholders, through the clear understanding of their roles, during the
accomplishment of the businesses modelling activity. It looks very promising to use a process with previsible
activities, controlled and understood by the stakeholders, making possible the presentation of the progress in a
more concrete way.
3 Overview of the proposed Process

The objective of the proposed process flow BMWBusiness Modelling Workflow is to help to construct
business modelling activity. BMW is a process flow for business modelling activity development. The
essential elements that compose the BMW process consist of the following topics [13]:
Presentation of the process objective.
Considerations for the definition of the participants team for the accomplishment of the works.
Templates that guide the phases related with business modelling activity, guided by BMW.
A suggestion of artifacts to be built in that process.
Guides for business modelling construction orientation.
By using this elements, it is possible to create a systematic approach to promote business modelling
activity. BMW intends to base the definition of who, how, what, and when to accomplish actions to promote
and to impel the communication and understanding between the software developer and the business
managers, through the discussion for the elaboration of business models. It aids the understanding of the
reasons, goals, concepts, process and business requirements supporting requirements engineering stage. The
figure 1 shows a overview of the BMW process.
BMW ELEMENTS
Objectives Participants Phases Artifacts Guides
Sponsor Preparation Finding business goals

Business Domain
Business Specialist Elaboration Model Finding business rules
Facilitator Evaluation Business Terms Finding business process
Project Manager Glossary
Publication Finding business actors and
resources
Finding business information
systems early requirements
Elaborating business terms
glossary
Elaborating business domain
model
Figure 1 overview of BMW process
Related to Participants, BMW recommends the following participants:

Sponsor - Organization senior manager that is fully responsible for the activity and ensures that it
meets BMW guidelines for propose activities. Sponsor arches with the activity costs and promote
visibility of the activity in the organization.
Business specialists business managers with knowledge in the specific area to be modelled. They
carry out a role fundamental in the business models elaboration.
Facilitator professional with knowledge about the process and of the business modelling technique
to be used. This professional has the responsibility of structuring in a solid way the modelling
process.
Project Manager to define and establishes together with the facilitator the objectives, the scope
modelling work plan.
BMW guides its activities by the following phases: Preparation, Elaboration, Evaluation and Publication.
The activities of each phase are defined with dependences and execution order among the same ones. Targets
guide each phases that has a systematic description defining when and how the tasks should be accomplished.
The final products should be documented in artifacts, so BMW suggests two templates: business domain
model and business terms glossary. Those artifacts essentially have the objective of standardizing the
documents formats to be produced by the accomplishment businesses modelling activity.
To address and discuss business scope and targets in this approach, BMW suggest the EKD method to
orient business model construction. In other words, now, the BMW process is adopting the models of the
EKD method to elaborate the business models. However, the process is essentially generic to be used with
other business modelling techniques. Additionally, BMW process proposes guidelines that aid in the
characterization of those elements, such as goals, process, rules, and etc. related to business scope that is
being modeled.
The Figure 2 presents a workflow detail to show BMW activities. In this picture we can observe that:
Each phase has goals, which carry into effect specific actions.
When actions are concluding, the results aid to reach next phase goals.
Preparation
Goal 1 delivery Delivering business information survey
To accomplish meeting for
start explanation and process
presentation
aid
Goal 2
To structure the modelling
session comprise Gathering business information survey
Accomplishing modelling session action plan
make possible
Elaboration
To built:
Goal 1 comprise
Goals model
To accomplish modelling Business rules model
session
Business process model
Actors and resources model
Goal 2 Information system early Requirements

subsidize
To accomplish models Elaborating Business Terms Glossary
integration
Evaluation
comprise
Goal 1 Elaborating business domain model
To accomplish models
validation make possible
comprise
Consisting models and to document suggestions
Publication
subsidize
Goal 1
To publish the results comprise Publishing business domain model and
business terms glossary end
Figure 2 BMW phase workflow.
The BMW process suggests two concepts to evidence the accomplishment of the business modelling
activity[13]:
Business models construction expressed through a graphic representation, creating business shared
images of the organization.
Workflow methodology definition describing the step by step, through activities development
systematizing using guidelines and recommendations.
The first businesses modelling activity is related to the knowledge acquisition and assemble information,
gathering elements and mapping information that aid in the subsequent activities. For that, BMW suggests the
Preparation phase. That phase has two goals, the Goal 1 Accomplishing meeting for explanation and
process presentation and the Goal 2 - Structuring the modelling session. This two goals need to be reached
for aiding success business modelling activity. Based on information gathered in previous phase, the
Elaboration phase could be started, that uses the business intentions achieved the Preparation phase to
supporting the initial goal, i.e., Goal 1 Accomplishing the modelling session. The modelling session is one
of the most relevant procedure of the business modelling activity, which include the construction of the
business models, aiding the next goal of the Elaboration phase, Goal 2Accomplishing the models
integration Developing models integrated enables organizations to derive knowledge from goals model, rule
model and process model related with the business captured at the previous activity during the modelling
session, done with the stakeholders participation. The Elaboration phase are concluded when the integrated
business models have been built. After this, the Evaluation phase could be started, which is characterized by
the Goal 1 To Accomplish models validation. This task must be done with the stakeholders participation to
promote the acceptance by the organizational staff. During the evaluation activity, the team has to formalize
business model. At the end of this analysis, two products must have be done, the business domain model and
business term glossary. The next phase of BMW process, the Publication phase, divulges the results obtained
with business modeling activity.
In the sequel each part of BMW phases is explained, describing individually the guidelines and
recommendations of the work process of each phase proposed by BMW. It is worth noting that in this paper
the term workflow means activities of work instead of (WFMS) Workflow Management Systems.
3.1. The Preparation Phase
The Preparation phase starts the process. The goals of that phase focus in the initial understanding
regarding the basic conception of the business intentions and in the definition of the business specialist team
that will participate in the business modelling activity.
Initially, BMW recommends a meeting for formally authorizing and publish the activity planning. This
formal meeting links the project to the ongoing work of business modelling. The major activities of this
meeting are summarized as follows:
Work development team presentation.
Early business needs.
Overview presentation of the business modeling activity purpose and targets.
Deliver and explanation business information survey (questionnaire).
Modelling session specialist team formalization.
The business information survey filled up by the business specialist is the major activity of this phase. This
survey helps business modelling development team to understand the business context and objectives.
Moreover, Preparation phase accomplished activities motivates the team to participate in an effective way of
the whole process.
After gathered early information about the business context, they need to be debugged. That activity guides
the Goal 2 To structure the modelling session, aiding information to the Facilitator of the modelling session.
Therefore, sometimes get the opportunity to interview the seminar participants, in advance, could be an
excellent initiative. Dragging a non-participative person to a modelling session is by all means wrong and
contra-productive.
3.2. The Elaboration Phase
The Elaboration phase is concerned with the modelling session when business knowledge needs to be
discussed and business models is constructed. At this activity the development team have to emphasize the
business goals and information system early requirements related to the modeled domain. The products of this
phase are strongly related to the success of the business modelling session. BMW process recommends the
construction of the following models (all of them based on the EKD method) such as goals model, business
rules model, business process model, business actors and resources model and business information system
early requirements model.
The goals model structures the description of the businesss goals, problems, causes, restrictions and
opportunities. The goals model focuses on describing intentional aspects of the business and it must be seen
as a tool for the stakeholders initial motivation. To concentrate on the business itself it is important during
the development of goals model. The goals model components motives participants to define the others
models components.
The business rules model is used to define and maintain explicitly business rules and policies.
Considering this approach, a business rule is defined as being a declaration that explains or restricts some
aspects of the business. It has an atomic aspect; it cannot be decomposed. It consolidates the businesss
structure, controlling or influencing the businesss behavior. Through the business rules the actions related to
the objectives and goals can be made more explicit or restricted. Consequently, the business rules model must
establish a strong relation among the business goals, identifying:
Rules that affect the goals set by the organization.
Relationship existent between the business rules and goals.
The business processes model is used to define and discuss business activities and processes, the way they
interact, and the way they handle information. This model structures the tasks related to business rules to aid
achievement of the business objectives. It may be considered an active part of the business and describes the
functions of the business, involves the utilization, transformation or production of resources.
The business actors and resources model reflect the structure of the stakeholders roles and
responsibilities in the accomplishment of the tasks related to the business. Actors and resources can be
organizational units, roles, individuals or groups of individuals, machines, etc. It describes how different actor
and resources are related, and how they are related to components of the business objectives or goals and
process.
The business information system early requirements model represents an approach to identify the
software system requirements that will assist the business. It allows announcing and to analyze the goals,
problems, processes and rules, through the statement functional and no-functional information system early
requirements that it is being projected. This model serves as a bridge and as a basis for a contract between
stakeholders and software developers. It is a new model proposed by BMW process. This model was done
based on technical components and requirements model of the EKD Method with some modifications to
become it more simplified. The following modifications were proposed for that model:
Do not identify objectives for the information system, because the objectives concept in the BMW
context is related to the business nor to the information systems.
Do not consider the subsystem identification and technical components during the software early
requirements identification, because the construction of building blocks could be a subsequent
activity, accomplished in the analysis and project phase of the software products development cycle.
The business terms glossary was proposed in substitution to the EKD conceptual model. This approach is
being adopted to present in a descriptive and explicit way the business concepts, instead of representing it for
a Concept Name and its relationship with other concepts, as originally is built by EKD Method.
3.3. The Evaluation Phase
The Evaluation phase is characterized by the accomplishment of the validation of the models produced in
the business modelling session. The objective of this alternative is to reduce the misunderstanding about
business needs between participants.
Stakeholders could validate built models through the following process:

Publishing of the models by the facilitator.
Fixing a modelling review seminar.
One important driver for the development of models review is the critical analysis of conflicts and
inconsistencies among the models before the evaluation session.
In the general context, the business modelling activity looks for to maximize the organizations potentiality
and their effectiveness in the knowledge transfer of the business processes. However, the effectiveness and
the efficiency in business modeling activity, still presents some restrictions and problems, especially that
related to warranty quality of the produced models [17]. Seeking to reduce that problem, the BMW business
modelling process recommends the evaluation of the models produced with stakeholders participation. After
this, the models are ready to be published. It is important to consider that, the Evaluation phase doesn'
t intend
to analyze the patterns and requirements of the models quality warranty. However, the models quality in the
validation process should consider, qualitative aspects, such as:
Inconsistencies between the models implementations and their integrations.
Clarity and easiness in the reading of the models.
Feasible representation between logical conception and their description through the models.
The production aggregate value that makes the continuity of the development of the work in the
organization viable.
The following actions are acquired as final result of the Evaluation phase activities:
The revision of the models components.
The integrated models validated by the stakeholders.
Business terms glossary updates.
Analysis and acceptance of the produced documents.
3.4. Publication Phase
This phase publishes the results obtained with accomplishment of the business modelling activity.
To facilitate and to standardize the structuring of the products, BMW proposes two artifacts:
Business domain model document.
Business terms glossary.
The publication of the results can be accomplished in several styles, depending on the formalisms and
existent methodologies in the organization. CASE - Computer-aided Software Engineering tools is advisable
for the construction and documentation of the models. They also can help the publication process, as for
instance, through the export of the models, interface with Web-browser, and integration with other tools, etc.
4 Study Case
In order to validate the process, a practical experience of the BMW process was accomplished in a real
project. The SIMAC project - Information system for management of all attendance of the Public System of
Health - Brazilian Ministry of Health. The basic assumptions of SIMAC are to promote all the process to
qualify action strategies and to identify the applied results for SUS - Public System of Health at the clinic and
hospital area. All of the activities proposed by the BMW process were executed. The next sections show how
BMW process was used in this study case.
4.1. Preparation Phase
The objectives of this phase were to identify information about the business and define business
specialists team that will participate of the process. In this study case the following activities are
distinguished in the preparation phase:
Meeting for presentation the process and the work plan to the business modelling activity.
This meeting was promoted by the project sponsor, which invited business specialist group responsible for
each area related with the business context. During the meeting, besides to show the process work and the
business modelling contributions, together, we defined team roles and responsibilities; as well we elicit
relevant information from the organizational context that the business is inserted
Assigning techniques to identify the business elements and to elaborate the business model.
A resume presented the techniques and tools involved with business modelling process was showed to the
participants. In addition, we specify the resources necessary - people and infrastructure to achieve the
business modelling activity.
Delivering the business survey (questionnaire) to the participants.
The aim of the questionnaire was to explore and investigate information related to the business in a
discipline way. During the meeting the hole questionnaire was presented and discussed with the participants.
The participants demonstrated interested in collaborating with the activities. But, some of them argued the
lack of time and some difficulty in registering the information at the business survey. Even so, 60% of them
answered this with relevant information about the business.
Based on the questions answered by the business specialists, some business components macro was
identified as well as, a more detailed understanding of the business main areas and the stakeholders
responsible by each one of that.
Considering these, action plan to structure the modelling session was done. The aspects covered here
through the activities presented above were some of the most important for the successful development of the
modelling session, which is the major goal of the next BMW phase, the Elaborating phase.
In the following, the Elaborating phase activities were programmed through the defining the focus, the
objective, the work calendar and the participants of the business modelling session.
4.2. Elaboration Phase
This phase started with a brief explanation about the general vision of the process and of the method to be
applied and which the objectives of the business modelling session. This helps business specialists to
understand better business modelling activity.
However, none of the participants had knowledge about no one business modelling process, and nor of any
other workflow to accomplish business modelling, as well as, they had never received any previous training.
They need to understand what is business modelling is, and how BMW process could be applied.
The group achieves the targets in the Elaborating phase as follows:

Facilitator showed the business information captured from the survey.
The format to present the information collected was based on the business model elements, such as,
goals, process, rules, and actors.
Based on the information captured, a brainstorm session was started to create the models.
During the modelling session four models were created:

The Goals Model was the most elaborated one, since the goal creates a common vision of the
business objectives.
The business rules model was discussed based on legal documents and definitions. Information
concerned with business rules was examined to capture its relationship between the goals identified.
The business processes model was defined according to rules, goals and actors related to the business
context.
The business actors and resources model was defined based on business process. The development
team perceived some roles related with the actor. They considered sufficiently detailed at this stage
of the process.
The business information system early requirements model wasnt done during the modelling
session. The facilitator and the project manager involved in business modelling process made this
model late. During business modelling activity many requirements connected into the models
discussed was established. The complete software system requirements were found out after this
process. But, in according with the stakeholders opinion the business modelling activity helps them
to understand their needs and to understand clearly software system requirements and scope.
The business terms glossary was done by the facilitator and project manager late based on
information sent by business specialist and some research documents.
4.3. Evaluation Phase
In order to validate the models produced at the modelling session an extranet was developed to dispose all
the documents and products made during the process. To enable an effective model evaluation a formal
meeting was done with the stakeholders.
Although Flynn [5], in their researches consider that stakeholders is reluctant for engage in models
validations sessions, that behavior was not observed in the accomplishment of that study case. BMW process
from the beginning emphasizes stakeholders participation, and its simplicity and usability attend this aspects.
Though, it is important to affirm, that due to the initial participation of the stakeholders in the Preparation
phase, was observed a reasonable compromising and a satisfactory quality of the models. Additionaly, that
fact can also be attributed to the following factors:
Understanding BMW workflow by the stakeholders.
Simplicity of the models to describe and to represent the businesses.
Based on the BMW recommendations, through the Evaluation phase template[13], the focus of this activity
was concentrated in the following points:
Analysis of inconsistency in the integration of the models.
Evaluation of the explicitness and easiness in the reading of the models and their contents.
Verification if the business logical concepts the model constructed are consistent.
Stakeholders motivation and compromising with the validation, and contribution with the continuity
of the development of the work in the organization.
All the improvement suggestions accepted by the group were documented in a textual way, being reflected
later in the models by the facilitator. It is possible to affirm that the results were reached and the business
modelling activity supplied orientations and fundamental support for the developer team and business
specialists improving the communication, business knowledge and its functional needs.
4.4. Publication Phase
The BMW process doesn' t suggest any tools to accomplish of the modelling results publication,
considering that this activity is quite related with the organizations methodology and the way that
organizational development team works. However, BMW Process advises the publication of the products,
produced from that activity, such as:
Consultations documents related to business context, such as laws, rules, politics, etc.
Information gathered from the participants during business modelling and validation sessions.
Survey answered by the stakeholders.
Record meetings, business terms glossary and all of the produced models, properly documented
under the versions control.
5 Conclusion
This paper describes step-by-step BMW process to achieve business modelling activity. One of the
advantages of adopting the process proposed in this paper is the effect on the participants. Since that, from the
beginning they understand how they are involved in the whole process.
The accomplishment of that study case was useful to show the importance of the BMW workflow in a real
situation of an information technology project, aiding the business understanding for the software product
development. The effort undertaken in elapsed of the activities was 80 hours. The project team consisted of
ten persons, which eight belong to business specialist team. Two of them belong to the technology specialist
team, one of which was the project manager, other the facilitator of business modelling session. Both together
have done all the activities related with the BMW process.
It is worth noting that the formal meeting in the evaluation phase could be done with different groups of
stakeholders to improve the quality of the models in compliance with the business needs.
As limitations of our work approach, we consider that in cases of applying BMW process using another
enterprise modeling method, such as i*, we recommend to development of new guidelines to support the
elaboration of the business models.
As future work, would be important to investigate which the best approach to introduce a business
modelling process in an organization, considering aspects of the acceptance of the workflow proposed and
such a elaborated models, as well as the stakeholders motivation for use them. Another aspect of concern is
the development of a tool to promote a computational support to aid in the activities and workflow proposed
by the process.
6 Reference
[1] Bubenko J.A., jr., Persson A., and Stirna J., D3: EKD User Guide. Royal Institute of Technology (KTH) and
Stockholm University, Stockholm, Sweden, 2001.
[2] Bubenko, J.A. & Kirikova, M., Improving the Quality of Requirements Specifications by Entreprise
Modelling. In Nillsson, A.G. and C. Tolis and C. Nellborn (Eds.). Perspectives on Business Modelling
Understanding and Changing Organisations, pp. 243-268, Springer - Verlag Berlin, 1999.
[3] Cysneiros, G., Ferramenta para o Suporte do Mapeamento da Modelagem Organizacional em i* para UML.
Tese de Mestrado, Centro de Informtica, Universidade Federal de Pernambuco, 2001.
[4] Falkenberg, E.D., Hesse, W., Lindgren, P., Nilsson, B.E., Oei, J.L.H., Rolland, C., Stamper, R.K., Van
Assche, F.J.M., Virrijn-Stuart, A.A., Voss,K. FRISCO: A Framework of Information System Concepts. The
IFIP WG 8.1 Task Group FRISCO, International Federation for Information Processing, Geneva, 1996.
[5] Flynn, D. J. and Warhurst, R., An empirical study of the validation process within requirements
determination. Information Systems Journal 4, pp 185-212, 1994.
[6] IBM, London, UK. Business System Development Method. Introducing BSDM, 2nd edition, May 1992.
[7] Jones, C., Applied software measurement. 2.ed. New York, McGraw-Hill, 1996.
[8] Kotonya, G. E Sommerville, I., Requirements Engineering Processes and Techniques. John Willy & Sons,
1997.
[9] Lindstrm, C-G, Lessons Learned from Applying Business Modelling: Exploring Opportunities and Avoiding
Pitfalls, In Nilsson, A.G., Tolis, C., Nellborn, C. (Eds.) Perspectives on Business Modelling Understanding
and Changing Organisations, Springer-Verlag, 1999.
[10] Loucopoulos, P. E Karakostas, V., System Requirements Engineering. London McGraw-Hill, 1995.
[11] Nilsson, A. G., Tolis, C., Nellborn, C. (Eds.). Perspectives on Business Modelling Understanding and
Changing Organisations. Springer-Verlag, Berlin, 1999.
[12] Persson, A., Enterprise Modelling in Practice: Situational Factors and their Influence on Adopting a
Participative Approach. PhD Thesis, Department of Computer and Systems Sciences, Stockholm
University/Royal Institute of Technology, Sweden, ISSN 1101-8526, 2001
[13] Monteiro,A.A.N.S., Modelagem de Negcio na Prtica: Um Mtodo para Suportar a Compreenso e

Comunicao das Necessidades dos Negcios. MSc. Thesis, Universidade Federal de Pernambuco, Centro de
Informtica. February/2003.
[14] Tolis, C. & Nilsson, A.G., Using Business Models in Process Orientation. In Lundeberg, M. & Sundgren, B.
(eds.), Advancing Your Business - People and Information Systems in Concert. The Economic Research
Institute (EFI), Stockholm School of Economics, Stockholm, 1996.
[15] U.S. Departament of Defense. Software Technology Plan. Volume II Plan of Action Techinical Report
Draft 5,8/15/91, 1991.
[16] Weiringa, R. J., Requirements Engineering Frameworks for Understanding. New York, John Wiley e Sons
Ltd. 1996.
[17] Yu, E. S.K. and Mylopoulos, J., From E-R to A-R Modelling Strategic Actor Relationships for Business
Process Reengineering. Proceedings 13the International Conference on the Entity-Relationship Approach,
Manchester, England, 1994.
[18] Yu, E., Modeling Strategic Relationship for Process Reengineering. PhD thesis, Computer Science
Department, University of Toronto. Toronto, Canada. 1995.
Un Framework para la Implementacin de Relaciones de Asociacin,

Agregacin y Composicin en UML
Marta Ruiz, Manoli Albert, Victoria Torres, Vicente Pelechano

Cam de Vera s/n, E-46022, Spain
{mruiz, malbert, vtorres, pele}@dsic.upv.es
Resumen
Este trabajo propone un framework para la implementacin de relaciones de asociacin, agregacin y
composicin. Para ello se presenta una interpretacin semntica de estos conceptos que permite eliminar
ambigedades introducidas por UML. Esta interpretacin se realiza a travs de un conjunto de propiedades
que permiten caracterizar estas relaciones. Una vez definida la semntica de estas relaciones, se propone un
framework basado en patrones de diseo que permite obtener su representacin software en funcin de las
propiedades que las caracterizan. El framework propuesto proporciona una solucin de calidad,
introduciendo beneficios considerables respecto otras aproximaciones de implementacin existentes en la
actualidad.
1. Introduccin.
En la actualidad los mtodos y herramientas de desarrollo se estn orientando cada vez ms a proponer
procesos de desarrollo basados en modelos (Model-Driven Development)[13]. Estas aproximaciones
proponen procesos de generacin de cdigo que toman como entrada las abstracciones de modelado
propuestas por el propio mtodo. Esta situacin de partida constituye una fuente importante de problemas,
puesto que estas abstracciones carecen en muchas ocasiones de una semntica precisa (dificultando su
utilizacin en los modelos, e impidiendo garantizar que el cdigo generado sea funcionalmente equivalente a
la especificacin del sistema). En el Modelado Conceptual OO una de las abstracciones ms utilizada es la
Relacin de Asociacin. Durante los ltimos aos diversos autores ([5, 16, 2, 8, 17, 15]) han estudiado la
semntica de estas relaciones, identificando propiedades estructurales y de comportamiento que permitan
caracterizarlas. Sin embargo no existe ninguna aproximacin que haya logrado un consenso entre los distintos
autores. UML [19] tampoco soluciona este problema, puesto que la semntica que propone presenta
numerosas ambigedades, tal como se seala en [2] y [6]. Esta falta de consenso deja a las relaciones de
asociacin sin una semntica precisa y clara que permita utilizarlas sin ambigedades durante el modelado
conceptual. Si a esta situacin le aadimos que las diversas tcnicas de implementacin para las relaciones de
asociacin propuestas en la actualidad (Objeto-Relacin, Punteros [7, 10], Metaclases [17, 24], Genericidad
[20, 10], ...) ofrecen soluciones parciales y de baja calidad (debido a diversas razones, como la dificultad en el
mantenimiento de la consistencia, complejidad de implementacin, difcil aplicabilidad, etc.) se hace evidente
la necesidad de proponer (1) un modelo con una semntica precisa para las relaciones de asociacin y (2)
una/s tcnica/s de implementacin de calidad para estas relaciones.
El presente trabajo pretende dar respuesta a estas dos necesidades en el contexto de un mtodo de
generacin de cdigo basado en modelos, OO-Method[21]. En primer lugar para lograr que el modelo
conceptual propuesto por OO-Method sea preciso es necesario proporcionar una semntica clara para las
abstracciones de modelado, entre ellas, las relaciones de asociacin. La manera de definir esta semntica va a
ser precisar la semntica propuesta por UML para los conceptos de asociacin, agregacin y composicin,
eliminando las ambigedades introducidas por UML. En este trabajo se propone una interpretacin semntica
para estos conceptos basada en la utilizacin de un marco multidimensional que identifica un conjunto de
propiedades que permiten caracterizar las relaciones de asociacin. En segundo lugar para mejorar la
implementacin de las relaciones de asociacin se propone un framework basado en el uso de patrones de
diseo [3] que permite obtener una implementacin de calidad de las relaciones de asociacin en funcin de
los valores de las propiedades que las caracterizan. Los patrones de diseo son estructuras de diseo de
calidad altamente usadas por los desarrolladores OO, su uso en la construccin del framework nos permite
aprovechar las ventajas que stos proporcionan.
Este trabajo se estructura de la siguiente manera: en el apartado 2 se presenta un modelo para las relaciones
de asociacin. En este apartado se propone una semntica precisa para los conceptos de UML asociacin,
agregacin y composicin basada en un marco multidimensional que identifica un conjunto de propiedades
que permite caracterizar las relaciones de asociacin. En el apartado 3 se presenta la estructura del framework
propuesto para la implementacin de la asociacin, agregacin y composicin. Para ello se hace uso de
patrones de diseo. En el apartado 4 se presentan detalles de implementacin de las clases de diseo
introducidas en el framework. El proceso de generacin de cdigo propuesto est completamente guiado por
los posibles valores que pueden tomar las propiedades del marco presentadas en el apartado 2 y que
caracterizan las relaciones de asociacin. Por ltimo conclusiones y trabajos futuros.
2. Relaciones de Asociacin. Un Marco Conceptual.

La Relacin de Asociacin es una de las abstracciones ms usadas en el modelado conceptual OO. UML
categoriza estas relaciones en tres tipos: asociacin, agregacin y composicin. Sin embargo la clasificacin
de las relaciones y la definicin de estos conceptos que realiza UML no es aceptada por la mayora de los
miembros de la comunidad OO. El principal motivo de la no aceptacin de la propuesta UML es la falta de
precisin en la definicin de estos conceptos. Existen diversos trabajos [2], [6] que identifican las
ambigedades introducidas por UML al definir la semntica de estos tres tipos de relaciones. Para precisar la
semntica de las relaciones de asociacin, en este apartado se propone una interpretacin particular de la
semntica de los conceptos de UML asociacin, agregacin y composicin. Para ello, a continuacin, se
llevan a cabo dos tareas: (1) construir un marco conceptual que identifique las propiedades ms relevantes de
las relaciones de asociacin y (2) a travs de estas propiedades dar semntica a los conceptos de asociacin,
agregacin y composicin. En los siguientes subapartados se presentan cada uno de estos pasos.
2.1. Marco conceptual.
En este subapartado se presenta un marco conceptual que identifica un conjunto de propiedades que
permite caracterizar las relaciones de asociacin en el Esquema Conceptual. Estas propiedades han sido
seleccionadas y adaptadas de las diversas aproximaciones OO de modelado existentes en la actualidad [11].
Esta seleccin se ha realizado tras un proceso de anlisis en el cual se han estudiado las aproximaciones OO
actuales ms relevantes ([5, 16, 2, 8, 17, 15]) que trabajan en este tipo de abstraccin.
El marco identifica las propiedades estructurales y de comportamiento que caracterizan las relaciones de
asociacin. Esto nos proporciona un conjunto de propiedades que permiten categorizar los distintos tipos de
relaciones. Este marco nos permite entender las caractersticas esenciales y la semntica de las relaciones de
asociacin, independientemente de los trminos utilizados para nombrarlas.
A continuacin vamos a presentar cules son estas propiedades que constituyen el marco. Para cada
propiedad: definimos cual es su semntica, identificamos el elemento de la relacin sobre el cual se define,
proporcionamos una nomenclatura que se utilizar a lo largo del presente trabajo e introducimos los posibles
valores que puede tomar.
Caractersticas Temporales.
- Definicin: Esta propiedad especifica si una instancia de una clase puede ser conectada o desconectada
durante su existencia (creando o destruyendo un enlace1) a uno o ms objetos de una clase asociada. El
valor Estatica indica que no es posible crear o destruir un enlace desde un objeto durante la vida de
ste (slo es posible en el momento de su creacin/destruccin). El valor Dinamica indica que si es
posible crear o destruir un enlace desde un objeto durante la vida de ste.
- Definida sobre: los extremos de la relacin (association-end, siguiendo la definicin del estndar
UML [19] en la pgina 3-71).
- Nomenclatura: CTrol2.
- Valores: Estatica | Dinamica.
1
Un Enlace es una instancia de una relacin de asociacin.
2
Rol es el nombre de un extremo. Si no est definido y la clase asociada tiene solo una relacin, usaremos
el nombre de la clase como el nombre del rol.
Multiplicidad
- Definicin: La multiplicidad especifica el valor mnimo (Min) / mximo (Max) de objetos de una clase
que deben/pueden ser conectados a slo un objeto de la clase asociada.
- Definida sobre: los extremos de la relacin.
- Nomenclatura: Minrol, Maxrol.
- Valores: enteros no negativos.
Propagacin de Borrado
- Definicin: La propagacin de Borrado indica qu acciones deben llevarse a cabo cuando se destruye
un objeto (sobre sus enlaces y objetos relacionados). Restrictivo: si el objeto tiene enlaces no puede ser
destruido. Cascada: si el objeto tiene enlaces, stos y sus objetos relacionados se destruyen. Enlace: si
el objeto tiene enlaces, stos se borran (no se destruyen los objetos asociados).
- Nomenclatura: PBrol.
- Valores: Restrictivo | Cascada | Enlace.
Visibilidad
- Definicin: La visibilidad especifica si un objeto puede ser accedido por su/s objeto/s asociado/s. El
valor No Visible indica que el objeto no puede ser accedido por su/s objeto/s asociados. El valor
Visible especifica que s puede ser accedido.
- Nomenclatura: Vrol.
- Valores: Visible | No Visible.
Proyeccin de Identificacin
- Definicin: Esta propiedad especifica si un objeto proyecta su identidad sobre sus objetos asociados.
El objeto sobre el que se proyecta la identidad mantiene su propia identidad como primaria, slo que
tambin puede ser identificado por su objeto asociado. El valor Proyectado indica que al objeto se le
proyecta la identidad de su objeto asociado y No Proyectado indica lo contrario.
- Nomenclatura: PIrol.
- Valores: Proyectado | No Proyectado.
Reflexividad
- Definicin: La reflexividad especifica si un objeto puede ser conectado a s mismo. El valor Reflexiva
indica que es posible, mientras que No Reflexiva indica lo contrario.
- Definida sobre: la relacin.
- Nomenclatura: RFrelacion.
- Valores: Reflexiva | No Reflexiva.
Antisimetra
- Definicin: La antisimetra especifica si un objeto puede ser conectado a otro objeto el cual ya est
conectado a l. Si es posible, el valor de la propiedad es No Antisimetrica. Si no es posible, el valor de
la propiedad es Antisimetrica.
- Definida sobre: la relacin.
- Nomenclatura: ASrelacin
- Valores: Antisimetrica | No Antisimetrica.
A continuacin se presenta cmo hacer uso de las propiedades presentadas para precisar la semntica de
los conceptos de UML asociacin, agregacin y composicin.
2.2. Una Interpretacin Semntica
Una vez introducido el marco conceptual se precisa la semntica de los conceptos asociacin, agregacin y
composicin de UML. Para ello se parte de las definiciones bsicas que propone UML para cada concepto. A
partir de aqu se completa la semntica a travs de las propiedades del marco. Las definiciones UML de las
que partimos son las siguientes:
- Asociacin: Una asociacin declara una conexin (enlace) entre instancias de clases asociados. Como
mnimo requiere de dos extremos, cada uno especificando una clase conectada y un conjunto de
propiedades que deben satisfacerse para que la relacin sea vlida. (pg. 2-64 [19]).
- Agregacin: Una agregacin es una relacin "todo/parte", en el cual uno de los extremos representa el
todo y el otro representa la parte de la agregacin. Slo las asociaciones binarias pueden ser
agregaciones. (pg. 2-66 [19]).
- Composicin: Una agregacin compuesta es "una forma de agregacin fuerte". (pg. 2-66 [19]).
Tabla 1. Valores fijos de las propiedades para la Asociacin, Agregacin y Composicin.

Propiedad/Concepto Asociacin Agregacin Composicin
Compuesto, Componente
Caractersticas Temporales Esttica,
Multiplicidad (1,1) , (,)
Propagacin de Borrado , Cascada
Visibilidad Visible, No Visible
Proyeccin de Identificacin No Proyectado, Proyectado
Reflexividad No Reflexiva No Reflexiva
Antisimetra Antisimetrica Antisimetrica
Para completar la semntica de estos conceptos se especifica el valor de las propiedades introducidas en el
apartado 2.1 para cada uno de ellos, de tal manera que cada concepto se site de manera correcta dentro del
marco conceptual propuesto. En la tabla 1 se pueden ver los valores de las propiedades para la asociacin,
agregacin y composicin (El smbolo indica que una propiedad puede tomar cualquier valor). Para cada
concepto (columna) la tabla muestra los valores de las propiedades.
Aspectos de Modelado. La semntica presentada tiene algunas implicaciones sobre el modelado

conceptual. Concretamente hay dos aspectos influenciados por la semntica:
- El valor CT = Dinamica definida sobre un extremo de la relacin, implica la existencia de dos
operaciones en la clase situada en el extremo opuesto que permitan conectar y desconectar objetos de
la clase con objetos de la clase relacionada: operaciones de insercin y borrado de enlaces.
- Debido a la no ortogonalidad de las propiedades del marco, la semntica de algunas propiedades
restringen los posibles valores de otras propiedades:
o CTA = Estatica implica PBA <> Enlace
o MinA >= 1 implica PBB <> Enlace
o PIA = Proyectada implica MaxB = 1
Este conocimiento puede aplicarse en la construccin de herramientas de modelado grficas que incluyan
comprobacin semntica. Esto ayudar al ingeniero software en la construccin de Esquemas Conceptuales.
3. Un Framework para la Implementacin de Relaciones de Asociacin.

Para implementar una relacin de asociacin entre dos clases se propone un framework3 basado en
patrones de diseo que permite obtener una solucin software de calidad. Este framework pretende solucionar
los problemas que se han detectado entre las distintas tcnicas de implementacin actuales propuestas para
implementar las relaciones de asociacin. Entre estas tcnicas encontramos algunas que hacen uso de
punteros o referencias [7,10], otras de primitivas existentes [1, 9, 20, 12, 4, 23, 22, 10, 18], otras de clases
parametrizadas [14], otras de metaclases [17, 24]. Estas tcnicas en general presentan los siguientes
problemas: (1) no proporcionan una implementacin directa para las propiedades (se utilizan elementos
software artificiales para representar las propiedades del marco conceptual), (2) no garantizan el
cumplimiento de los requisitos intrnsecos de una relacin de asociacin (no se permite la dinamicidad y en
ocasiones no se garantiza el mantenimiento de la dependencia existencial), y (3) no satisfacen algunos de los
criterios de calidad de software ms relevantes (implementaciones complejas, clases y relaciones no
3
Utilizamos una aproximacin heavy-weight puesto que nos permite representar de forma adecuada el
modelo propuesto. En [11] se propone una implementacin light-weight.
reusables, dificultad en la extensibilidad y mantenimiento, y coste temporal y espacial alto en tiempo de

ejecucin).
El framework propuesto pretende dar solucin a estos problemas de tal manera que la solucin software
propuesta proporcione una implementacin natural de las propiedades del marco, cumpliendo los requisitos
intrnsecos de las relaciones, y que dicha solucin software sea sencilla, con elementos reusables y de fcil
mantenimiento.
El framework propuesto implementa las relaciones de asociacin basndose en las propiedades del marco
conceptual propuesto en el apartado 2.1. De esta manera, como aportacin importante de este trabajo, se
define un nico proceso de transformacin basado en las propiedades del marco que obtiene la representacin
software de una relacin de asociacin caracterizada por estas propiedades. As, este proceso permite obtener
la implementacin de la asociacin, agregacin y composicin.
3.1. Problemas y Soluciones en la Implementacin de Relaciones de Asociacin
Antes de presentar el framework con detalle se presentan cules son las dificultades ms importantes que
aparecen en la implementacin de las relaciones de asociacin. Para cada una de ellas se presenta la solucin
software que propone el framework. Las soluciones propuestas utilizan patrones de diseo presentados en
Gamma et al. [3].
- Problema: Una relacin de asociacin tiene semntica propia, adicional a la semntica de las clases
participantes en la relacin. Por ello es importante implementar la relacin y las clases participantes de
forma que la implementacin individual de cada una de ellas no introduzca dependencias explcitas
(referencias, atributos, mtodos) y no introduzcan un alto acoplamiento respecto a las otras. Solucin
Propuesta: Se utilizar el patrn Mediator para encapsular la interaccin entre las clases participantes en
una relacin, promoviendo un bajo acoplamiento entre ellas, que evita que los objetos se referencien
explcitamente, permitiendo variar su interaccin de forma independiente.
- Problema: Los objetos de las clases participantes tienen un comportamiento y una estructura adicional a
la especificada por su clase de dominio (por participar en una relacin de asociacin). Es importante
implementar este comportamiento y estructura adicional independientemente del comportamiento y
estructura propio de las clases participantes. Solucin Propuesta: Se utiliza el patrn Decorator para
representar las clases participantes. Con la aplicacin de este patrn se definen clases de diseo auxiliares
que envuelven a las clases participantes y que mantienen la estructura y comportamiento propios de los
objetos como participantes en una relacin de asociacin, dejando que las clases participantes mantengan
su comportamiento y su estructura (ajenos a la relacin).
- Problema: Es necesaria la reutilizacin del comportamiento y la estructura comn de las relaciones. Por
ejemplo se puede definir una estrategia de ejecucin para la creacin y destruccin de enlaces. Solucin
Propuesta: Se aplica el patrn Template Method para implementar mtodos que definan una estrategia
de ejecucin. Los pasos de la estrategia son redefinidos e implementados en subclases dependiendo del
valor de las propiedades de cada relacin de asociacin especfica.
Con la utilizacin de estos patrones de diseo la implementacin de cada uno de los elementos de una
relacin de asociacin se centraliza, lo que facilita el mantenimiento del cdigo y beneficia la reusabilidad de
los distintos elementos participantes en la relacin.
3.2. Estructura del Framework. Clases de Diseo.
Una vez vistas de forma intuitiva las ideas bsicas del framework se presenta con ms detalle la estructura
de ste. Como se acaba de ver, los patrones de diseo utilizados en el framework son el patrn Mediator,
Decorator y Template Method.
A continuacin se introducen las clases de diseo que forman el framework. Para ello se va a presentar
para cada elemento de una relacin de asociacin cules son las clases de diseo que lo representan.
Supongamos una relacin de asociacin R con dos extremos EA y EB conectando las clases A y B
respectivamente:
- Las clases participantes (A y B). Por cada clase de dominio participante en la relacin de asociacin se
define una clase de diseo (ClaseAsociada).
ClaseAsociada
Implementa la estructura y el comportamiento de las clases del dominio.
Es independiente de la relacin de asociacin que mantiene.
- Los extremos de la relacin (EA y EB). Las propiedades que caracterizan los extremos de una relacin
(Min, Max, CT, V, PI y PB) repercuten en la estructura y el comportamiento de los objetos de las clases
sobre las que estn definidas (A y B). Esto significa que los objetos de las clases participantes tienen un
comportamiento y propiedades adicionales a las propias/inherentes de la clase. Para poder representar
este comportamiento y propiedades adicionales se aplica el patrn Decorator. Este patrn define una
clase decoradora como envolvente a otra clase (decorada). En nuestro caso se aplica el patrn sobre las
clases de dominio de tal manera que cada clase asociada tiene una decoradora
(DecoradorColegaClaseAsociada) que la envuelve.
En la figura 1 se puede ver un ejemplo grfico de cmo los objetos decoradores envuelven a los
objetos de las clases participantes en una relacin de asociacin. En el ejemplo existe una relacin
TrabajaPara entre las clases Empleado y Empresa. En este caso el objeto Juan de la clase
Empleado est envuelto por un objeto decorador (DecoradorJuan), al igual que el objeto IBM de la
clase Empresa est envuelto por otro objeto decorador (DecoradorIBM). De esta manera las clases
decoradas, clases asociadas, mantienen el comportamiento y las propiedades propias de la clase mientras
que las clases decoradoras mantienen el comportamiento y las propiedades propias de los objetos como
participantes en una relacin de asociacin. Las clases asociadas slo son accesibles a travs de las clases
decoradoras.
La estructura y el comportamiento de estas clases decoradoras se puede generalizar para obtener una
clase padre que defina la estructura y el comportamiento comn de las clases decoradoras de clases
asociadas. Esta clase, a la que llamamos DecoradorColega, es una clase abstracta que define la interfaz
comn de las clases decoradoras y que, utilizando el patrn Template Method, define mtodos plantilla
que especifican estrategias de ejecucin comunes. En esta clase se definen estrategias de ejecucin para:
la conexin de un enlace a un objeto decorador (conectar_enlace) y la desconexin de un enlace de
un objeto decorador (desconectar_enlace). Los pasos de estos mtodos sern implementados en
las subclases. En el apartado 4 se presentan los detalles de implementacin de estos mtodos.
DecoradorColega
Clase abstracta.
Define un atributo de clase por cada propiedad de los extremos de las relaciones de asociacin (Min,
Max, CT, PB, V y PI).
Mantiene una referencia a una coleccin de enlaces, dependiendo del valor de la propiedad V, que
permite que los objetos decoradores puedan acceder a sus enlaces: coleccionEnlaces:
MediadorAsociacion[].
Define los mtodos plantilla: conectar_enlace, desconectar_enlace.
DecoradorColegaClaseAsociada
Subclase de DecoradorColega.
Declara la interfaz de la clase asociada que decora (ofrece en su interfaz los servicios pblicos de las
clases de dominio).
Define los atributos identificadores de la clase, dependiendo del valor de la propiedad PI.
Implementa los mtodos crear_enlace y destruir_enlace.
Implementa los pasos de los mtodos conectar_enlace y desconectar_enlace dependiendo
del valor de las propiedades Max, Min y CT. Estos pasos son:
comprobar_multiplicidad_maxima, comprobar_multiplicidad_minima y
comprobar_caracteristicas_temporales.
Mantiene una referencia al objeto que decora: objetoDecorado: ClaseAsociada
- La relacin de asociacin en s (R). Las propiedades que caracterizan a las relaciones de asociacin (RF y
AS) repercuten en el comportamiento y la estructura de los enlaces (como se puede ver en la figura 1, la
clase mediadora mantiene las propiedades especificadas sobre la relacin). Esta clase mediadora slo es
accesible por sus clases colega (clases decoradoras). Para representar este elemento se aplica el patrn
Mediator. Este patrn define una clase mediadora que encapsula la interaccin de un conjunto de
objetos. Se utiliza esta estructura para representar los enlaces como instancias de una clase mediadora
(MediadorAsociacionNombreRelacion) y que encapsulan la interaccin de los objetos asociados.
Al igual que ocurra con las clases decoradoras, se generalizan las clases mediadoras en una clase
padre que defina la estructura y el comportamiento comn de estas clases. A esta clase la llamamos
MediadorAsociacion, es una clase abstracta que define la interfaz comn de las clases mediadoras y
que utiliza el patrn Template Method para definir la estrategia comn de: la creacin de objetos enlaces
(constructor) y la destruccin de objetos enlaces (destructor). Los pasos de estos mtodos
sern implementados en las subclases. En el apartado 4 se detalla la implementacin de estos mtodos.
MediadorAsociacion
Clase abstracta.
Define los mtodos plantilla: constructor y destructor.
Mantiene una referencia a los objetos participantes en el enlace, con los atributos:
objetoRelacionado1: DecoradorColega y objetoRelacionado2: DecoradorColega.
Define un atributo por cada propiedad de las relaciones de asociacin (RF y AS).
MediadorAsociacionNombreRelacion
Subclase de MediadorAsociacion.
Implementa los pasos de los mtodos constructor y destructor dependiendo del valor de las
propiedades RF y AS. Estos pasos son: comprobar_reflexividad y
comprobar_antisimetria.
TrabajaPara
Empleado Empresa
RFTrabajaPara
ASTrabajaPara
CTEmpleado CTEmpresa
MinEmpleado MinEmpresa
MaxEmpleado MaxEmpresa
PIEmpleado PIEmpresa
PBEmpleado PBEmpresa
VEmpleado VEmpresa
JuanIBM
DecoradorJuan DecoradorIBM
Juan IBM
Figura 1. Ejemplo de objetos creados utilizando el framework
La aplicacin de los patrones Mediator y Decorator permite generar una solucin software reusable
(clases participantes reusables) y de fcil mantenimiento; implementar las propiedades y las operaciones
propias de los enlaces en la clase mediadora; las propiedades y las operaciones propias de los objetos como
objetos participantes en una relacin en las clases decoradoras; mientras que las propiedades y las
operaciones propias de las clases participantes se implementan en las clases correspondientes.
La aplicacin del patrn Template Method en las clases abstractas permite definir plantillas de mtodos
que definen estrategias de ejecucin comunes a todas las relaciones. Los pasos de la estrategia son
implementados en las clases hijas que representan la relacin de asociacin especfica.
En la Figura 2 se puede ver una estructura de clases de diseo generada utilizando el framework propuesto.
4. Detalles de Implementacin.
Una vez presentada la estructura del framework se presentan algunos detalles concernientes a la
implementacin de las clases de diseo.
MediadorAsociacion DecoradorColega
TrabajaPara * 2
Empleado Empresa
MediadorAsociacionTrabajaPara DecoradorColegaEmpleado DecoradorColegaEmpresa
1
1 1
* 1
* 1
Empleado Empresa
Figura 2. Aplicacin del Framework a una relacin de Asociacin
4.1. Creacin de Enlaces
Las clases decoradoras ofrecen en su interfaz un mtodo que permite crear un enlace asociado a un objeto
de la clase. El mtodo, al que llamamos crear_enlace, debe solicitar la creacin de un objeto enlace a la
clase mediadora correspondiente, por lo que delegar su ejecucin en el mtodo constructor de la clase
mediadora. Una vez creado el enlace, el mtodo constructor hace uso de un mtodo de las clases
decoradoras, conectar_enlace, que se encarga de relacionar los objetos participantes con el nuevo enlace.
A continuacin se presentan los detalles de implementacin de estos tres mtodos.
Mtodo crear_enlace de la clase Decoradora Concreta. Se implementa en la clase

DecoradorColegaAsociada. Debe crear un objeto enlace entre dos objetos decoradores: el objeto que
ejecuta el servicio, al que llamaremos objeto servidor, y el objeto definido como parmetro, al que
llamaremos objeto asociado. Para ello llama al mtodo constructor de la clase mediadora.
MediadorAsociacion crear_enlace(DecoradorColega objAsociado){
MediadorAsociacion enlace = new MediadorAsociacion(this, objAsociado);
return enlace;
}
Mtodo constructor de la clase Mediadora Abstracta. Se implementa en la clase MediadorAsociacion

y define la estrategia para crear un objeto enlace. Tiene como parmetros los objetos que se relacionan a
travs del enlace (objetos participantes). Los pasos de la estrategia son:
1. Comprobar que se puede llevar a cabo la creacin del enlace: Las propiedades de la relacin que
imponen alguna restriccin a la creacin de enlaces son: (1) RF (se comprueba mediante el mtodo
comprobar_reflexividad) y (2) AS (se comprueba mediante el mtodo
comprobar_antisimetria). Estos mtodos se implementarn en la subclase
MediadorAsociacionNombreRelacion.
2. Dar valor a los objetos participantes: atributos objetoRelacionado1 y objetoRelacionado2.
3. Llamar al mtodo conectar_enlace de los objetos participantes. Este mtodo relacionar a los
objetos participantes con el enlace que se ha creado.
void MediadorAsociacion(DecoradorColega objAso1, objAso2){

comprobar_reflexividad(objAso1, objAso2); //paso 1.1
comprobar_antisimetria(objAso1, objAso2); //paso 1.2
ObjetoRelacionado1 = objAso1; //paso 2
ObjetoRelacionado2 = objAso2; //paso 2
ObjetoRelacionado1.conectar_enlace(this); //paso 3
ObjetoRelacionado2.conectar_enlace(this); //paso 3
}
Mtodo conectar_enlace de la clase Decoradora Abstracta. Se implementa en la clase

DecoradorColega y define la estrategia para conectar un enlace a un objeto decorador (objeto que ejecuta
el servicio, objeto servidor). El mtodo conectar_enlace tiene como parmetro el objeto enlace que se
quiere asociar. El mtodo tiene que comprobar que no se violen las restricciones de integridad de la relacin.
Los pasos de la estrategia son los siguientes:
1. Comprobar que es posible aadir un enlace al objeto servidor. La comprobacin viene determinada
por las propiedades: (1) Max (se comprueba mediante el mtodo
comprobar_multiplicidad_maxima) y (2) CT (se comprueba mediante el mtodo
comprobar_caracteristicas_temporales). Estos mtodos se implementarn en las subclases

DecoradorColegaClaseAsociada.
2. Aadir el enlace al objeto servidor.
void conectar_enlace(MediadorAsociacion objEnlace){

comprobar_multiplicidad_maxima(); //paso 1.1
comprobar_caracteristicas_temporales(); //paso 1.2
ColeccionEnlaces.add4(objEnlace); //paso 2
}
4.2. Borrado/Destruccin de Enlaces
Las clases decoradoras ofrecen en su interfaz un mtodo que borra (desconecta) un enlace de un objeto de
la clase, borrar_enlace. Este mtodo debe destruir el objeto enlace, para lo que delega su ejecucin en el
mtodo destructor de la clase mediadora. Antes de destruir el enlace, el mtodo destructor hace uso de
un mtodo de las clases decoradoras, desconectar_enlace, que se encarga de eliminar la relacin de los
objetos participantes con el enlace. A continuacin se presentan los detalles de implementacin de estos tres
mtodos.
Mtodo borrar_enlace de la clase Decoradora Concreta. Se implementa en la clase

DecoradorColegaAsociada. Debe borrar un enlace de un objeto decorador (objeto que ejecuta el
servicio, objeto servidor). Los objetos relacionados por el enlace son el objeto servidor y un objeto asociado
definido en el mtodo como parmetro. Los pasos que lleva a cabo el mtodo son:
1. recuperar el objeto enlace de la coleccin de enlaces del objeto servidor ,
2. destruir el objeto enlace.
void borrar_enlace(DecoradorColega objAso2){

MediadorAsociacion miEnlace;
miEnlace = ColeccionEnlaces.find5(objAso2); //paso 1
miEnlace.destruir_enlace(); //paso 2
}
Mtodo destructor de la clase Mediadora Abstracta. En la clase MediadorAsociacion se define este

mtodo que determina la estrategia para destruir un enlace. Los pasos de la estrategia son los siguientes:
1. Llamar al mtodo desconectar_enlace de los objetos participantes en el enlace. Los objetos
participantes en el enlace que va a ser destruido tienen que eliminar la relacin con dicho enlace.
2. Destruir el enlace.
void destruir_enlace(){
ObjetoRelacionado1.desconectar_enlace(this); //paso 1
ObjetoRelacionado2.desconectar_enlace(this); //paso 1
destroy(); //mtodo destructor de la clase mediadora //paso 2
}
Mtodo desconectar_enlace de la clase Decoradora Abstracta. La clase DecoradorColega define este

mtodo que determina la estrategia para eliminar un enlace de la coleccin de enlaces de un objeto. Los pasos
de la estrategia son los siguientes:
1. Comprobar que es posible eliminar el enlace del objeto. La comprobacin viene determinada por las
siguientes propiedades: (1) Mn (se comprueba mediante el mtodo
comprobar_multiplicidad_minima) y (2) CT (se comprueba mediante el mtodo
comprobar_caracteristicas_temporales). Estos mtodos se implementarn en la subclase
DecoradorColegaClaseAsociada.
2. Eliminar el enlace del objeto servidor del atributo ColeccionEnlaces.
4
El mtodo col.add(e) de la clase coleccin inserta el elemento e a la coleccin col.
5
El mtodo col.find(e) de la clase coleccin devuelve el elemento e de la coleccin col.
void desconectar_enlace(MediadorAsociacion objEnlace){

comprobar_caracteristicas_temporales(); //paso 1.1
comprobar_multiplicidad_minima(); //paso 1.2
ColeccionEnlaces.del6(objEnlace); //paso 2
}
4.4 Creacin de Objetos Asociados.
Las clases de dominio tienen un mtodo constructor encargado de crear un objeto de la clase. La
implementacin de este mtodo es la comn en la creacin de un objeto. El comportamiento especfico en la
creacin de objetos debido a la existencia de una relacin de asociacin se implementa en el mtodo
constructor de las clases decoradoras. Este mtodo se encarga de construir el objeto decorador (de la
clase DecoradorColegaClaseAsociada) y el objeto asociado al que decora (de la clase
ClaseAsociada). Esto permite mantener independientes el cdigo que implementa la creacin de un objeto
de una clase participante y el cdigo que implementa la creacin de un objeto decorador, lo que beneficia la
reusabilidad de las clases y mejora el mantenimiento del cdigo.
Mtodo constructor de las clases Decoradoras. El mtodo constructor de la clase

DecoradorColegaClaseAsociada crea un objeto de la clase decoradora.
Este mtodo proporciona funcionalidad que permite relacionar el objeto creado con un objeto asociado.
Esto es obligatorio cuando la Multiplicidad Mnima as lo indique (Min > 0), en otro caso debe ser opcional.
De esta manera, la clase DecoradorColegaClaseAsociada tiene un mtodo constructor
sobrecargado, de forma que existen 2 mtodos constructores:
1. Mtodo constructor simple:
- Argumentos: atributos del objeto a crear.
- Pasos: (1) crea el objeto decorador e inicializa su estado, y (2) crea el objeto decorado e inicializa su
estado.
2. Mtodo constructor complejo:
- Argumentos: atributos del objeto a crear y el/los objeto/s a relacionar.
- Pasos: (1) crea el objeto decorador e inicializa su estado, (2) crea el objeto decorado e inicializa su
estado, y (3) relaciona el objeto decorador con el /los objeto/s a relacionar.
4.5. Destruccin de Objetos Asociados.
Las clases de dominio tienen un mtodo destructor encargado de destruir un objeto de la clase. La
implementacin de este mtodo es la comn en la destruccin de un objeto. El comportamiento especfico en
la destruccin de objetos debido a la existencia de una relacin de asociacin se implementa en el mtodo
destructor de las clases decoradoras. Este mtodo se encarga de destruir el objeto decorador (de la clase
DecoradorColegaClaseAsociada) y el objeto asociado al que decora (de la clase ClaseAsociada). Esto
permite mantener independientes el cdigo que implementa la destruccin de un objeto de una clase
participante y el cdigo que implementa la destruccin de un objeto decorador.
Mtodo destructor de las clases Decoradoras. En la destruccin de un objeto (al que llamamos objeto
servidor decorador) de una clase decoradora, el mtodo destructor de la clase
DecoradorColegaClaseAsociada realiza una serie de acciones dependiendo del valor de la propiedad
Propagacin de Borrado asociada a la clase:
- Restrictivo: si el objeto servidor decorador tiene enlaces se devuelve una excepcin, en otro caso: (1)
se destruye el objeto decorado y (2) se destruye el objeto servidor decorador.
- Enlace: (1) se borran los enlaces del objeto, a travs del mtodo borrar_enlace, (2) se destruye el
objeto decorado y (3) se destruye el objeto servidor decorador.
- Cascada: (1) se borran los enlaces del objeto, a travs del mtodo borrar_enlace, (2) se destruyen
los objetos asociados, (3) se destruye el objeto decorado, y (4) se destruye el objeto decorador
6
El mtodo col.del(e) de la clase coleccin elimina el elemento e de la coleccin col.
4.6. Atributos identificadores y visibilidad de objetos.
En este subapartado se presentan algunos detalles de implementacin de las clases decoradoras y de las
clases asociadas.
Atributos Identificadores. Los atributos identificadores de una clase decoradora son los atributos que han
sido especificados como identificadores en su correspondiente clase de dominio. Los atributos identificadores
de una clase asociada dependen del valor de la propiedad PI de su clase de dominio correspondiente:
- Si sobre una clase A relacionada con una clase B a travs de una relacin R, el valor de la propiedad
PI es No Proyectado, los atributos de identificacin de la ClaseAsociada de A sern los
especificados en la clase de dominio A.
- Si el valor de la propiedad PI sobre la clase A es Proyectado, los atributos identificadores de la
ClaseAsociada de A sern los atributos identificadores de la clase de dominio A ms los atributos
identificadores de la clase de dominio B.
Visibilidad de Objetos. Cuando el valor de la propiedad Visibilidad sea No Visible sobre un extremo de la
relacin, la clase asociada al extremo opuesto de la relacin no mantiene una referencia a los enlaces de dicha
relacin, es decir, no se define el atributo coleccionEnlaces en la clase decoradora correspondiente, y por
tanto tampoco se definen los mtodos conectar_enlace ni desconectar_enlace que actualizan la
referencia.

En este trabajo se propone un framework para la implementacin de las relaciones de asociacin,
agregacin y composicin. Para ello hemos presentado una interpretacin particular de los conceptos de
asociacin, agregacin y composicin introducidos por el estndar UML7. Para la definicin de estos
conceptos hemos construido un marco conceptual basado en el estudio de diferentes aproximaciones que
tratan la asociacin en modelos conceptuales OO. El marco identifica las propiedades relevantes de las
relaciones de asociacin y nos permite dar interpretaciones precisas de las abstracciones asociacin,
agregacin y composicin. Una vez definida la semntica de estas abstracciones, proponemos un framework
basado en el uso de patrones de diseo para implementarlas. Este framework determina las correspondencias
entre las propiedades del marco y los elementos software del Espacio de la Solucin. La aplicacin de
patrones a los mtodos de desarrollo de software aporta beneficios interesantes ya que permite estructurar el
proceso de generacin de cdigo ofrecer soluciones reutilizables y probadas, que sean lo suficientemente
abstractas cmo para ser utilizadas en cualquier lenguaje de programacin. Esta aproximacin est siendo
incorporada en una herramienta CASE (ON Model Execution) de soporte a OO-Method [21].
Adems, estamos desarrollando un asistente que ayude al analista a especificar el tipo de relacin a
modelar: asociacin, agregacin y composicin. El asistente recopila informacin a travs de preguntas. Estas
preguntas estn orientadas a determinar los valores de las propiedades.
Pretendemos mejorar el marco conceptual propuesto, identificando patrones estructurales y de
comportamiento que no hayamos identificado hasta el momento, y el framework para la implementacin de
relaciones, utilizando otros patrones de diseo que mejoren la calidad del software obtenido.
Referencias.
[1] A. Albano, G Ghelli, R. Orsini. A relationship mechanism for a strongly typed objectoriented database
programming language. G.M. Lohman, A. Sernadas, R. Camps, editors, Proc. of the 17th Int. Conf. on Very Large Data
Bases, VLDB91, pag. 565575, Barcelona, Catalonia, Spain, 1991. Morgan Kaufmann.
[2] B. Henderson-Sellers, F. Barbier, What is this thing called aggregation?, A.C. Wills J. Bosch R. Mitchell, B.
Meyer editors, Proceedings of TOOLS 29, pag. 216-230. IEEE Computer Society., 1999.
[3] E. Gamma, R. Helm, R. Johnson, J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software,
Addison-Wesley, Reading, MA, 1994.
7
Este trabajo se ha desarrollado sobre la versin 1.4 de UML, la nueva versin 2.0 no supone cambios
significativos.
[4] B.K. Ehlmann, G.A. Riccardi. An integrated and enhanced methodology for modeling and implementing object
relationships. Journal of Object-OrientedP rogramming, 10(2):4755, May 1997.
[5] Franco Civello. Roles for composite objects in object-oriented analysis and design., OOPSLA93, pag. 376-393,
ACM Press, 1993. ISBN: 0-89791-587-9.
[6] Gonzalo Genova, Juan Llorens, Vicente Palacios, Sending messages in UML, Journal of Object Technology
(JOT) 2(1), January-February 2002, pag. 99-115.
[7] I. Graham, J. Bischof, B. Henderson-Sellers, Associations considered a bad thing, Journal of Object Oriented
Programming, 9(9) Pag. 41-48, 1997.
[8] James J. Odell. Six different kinds of composition., JOOP, 5(8), January 1994.
[9] J. Bosch. Relations as object model components. Journal of Programming Languages, 4:39 61, 1996.
[10] J. Rumbaugh, Relations as semantic constructs in an object-oriented language, In Meyrowitz [Mey87], ACM
SIGPLAN Notices, 12(22), Pag. 466481, 1987
[11] Manoli Albert, Vicente Pelechano, Joan Fons, Marta Ruiz, Oscar Pastor, Implementing UML Association,
Aggregation and Composition. A Particular Interpretation based on a Multidimensional Framework, CAiSE2003, 2003,
pp 143-158, Johan Eder, Michele Missikoff (Eds.), LNCS (2681) ISBN 3-540-40442-2.
[12] M. Doherty, J. Peckham, V.F. Wolfe. Implementing relationships and constraints in an object-oriented database
using a monitor construct. N.W. Paton, M.H. Williams, editors, Proc. of the Int. Workshop on Rules in Database
Systems, RIDS93, LNCS 1312, pag. 347363, Edinburgh, Scotland, 1993. Springer-Verlag.
[13] Mellor, S.J.; Clark, A.N.; Futagami, T. Model-driven development Guest editor's introduction. IEEE
Software, p. 14-18, Sept.-Oct. 2003
[14] M. Kolp, A. Pirotte. An aggregation model and its C++ implementation. M.E. Orlowska, R. Zicari, editors,
Proc. of the 4th Int. Conf. on Object-Oriented Information Systems, OOIS97, pag. 211224, Brisbane, Australia,
November 1997. http://yeroos.qant.ucl.ac.be/file.pdf/P-97-06.pdf.
[15] Monika Saksena, Robert B. France, Mara M. Larrondo-Petrie. A characterization of aggregation., Springer
editor, Proceedings of OOIS98, pag. 11-19. C. Rolland, G. Grosz, 1998.
[16] Monique Snoeck, Guido Dedene. Core modelling concepts to define agreggation. Lobjet, 7(1), February 2001.
[17] M. Dahchour. Integrating Generic Relationships into Object Models Using Metaclasses, PhD thesis, Dept.
Computing Science and Eng., Universit Catholique de Louvain, Belgium, Mar. 2001.
[18] N. Zhang, T. Hrder, J. Thomas. Enriching object-relational databases with relationship semantics. Proc. of the
3rd Int. Workshop on Next Generation Information Technologies and Systems, NGITS97, pag. 215222, Israel, 1997.
[19] Object Management Group. Unified Modeling Language Specification Version 1.5. Technical report,
www.omg.org, March 2003.
[20] O. Daz, N.W. Paton. Extending ODBMSs using metaclasses. IEEE Software, pag. 4047, May 1994.
[21] O. Pastor, J. Gmez, E. Insfrn, V. Pelechano. The OO-Method Approach for Information Systems Modelling:
From Object-Oriented Conceptual Modeling to Automated Programming. Information Systems, 26(7), 507-534, 2001.
[22] R. Nassif, Y. Qiu, J. Zhu. Extending the object oriented paradigm to support relationships and constraints. In
Meersman et al. [MKK91], pag. 305329.
[23] S. Hwang, S. Lee. An object-oriented approach to modelling relationships and constraints based on abstraction
concept. A.M. Tjoa, R. Wagner, editors, Proc. of the Int. Conf. on Database and Expert Systems Applications,
DEXA90, pag. 3034, Vienna, Austria, 1990. Springer-Verlag.
[24] W. Klas, M. Schrefl, Metaclasses and their application , Springer-Verlag, LNCS 943, 1995
Gerncia de Conhecimento na Engenharia de Requisitos
Denise F. Togneri1,2 , Ricardo de A. Falbo 2 , Credin S. de Menezes2 , Bernardo S. Wernesback 1,

Diogo Q. de Almeida1 , Marina F. Crtes1
FAESA - Faculdades Integradas Esprito-santenses

1
Colegiado do Curso de Cincia da Computao

Rua Anselmo Serrat, 199, Vitria-ES, Brazil, CEP: 29041-010
2UFES - Universidade Federal do Esprito Santo
Centro Tecnolgico - Mestrado em Informtica

Avenida Fernando Ferrari, s/n, Vitria-ES, Brazil, CEP: 29060-900
togneri@terra.com.br, {falbo, credine}@inf.ufes.br
Resumo
A Engenharia de Requisitos uma das principais atividades da Engenharia de Software um processo
sistemtico de captura, modelagem e documentao de requisitos atravs de uma abordagem iterativa e
cooperativa. uma atividade que envolve um processo intensivo de conhecimento [5] e nesse sentido,
muito importante a adoo da Gerncia de Conhecimento para apoiar sua realizao. A rea de Gerncia de
Conhecimento tem como objetivo promover o amadurecimento, a comunicao e a preservao do
conhecimento formal e informal existente nas organizaes. Este trabalho investiga como a rea de Gerncia
de Conhecimento pode apoiar as atividades do processo de Engenharia de Requisitos e apresenta uma
ferramenta que utiliza a tecnologia de agentes e se prope a integrar essas duas reas. Essa ferramenta foi
desenvolvida para Web e foi modelada usando o paradigma da orientao a objetos e a metodologia GAIA
[14] para modelagem dos agentes.
1. Introduo
No contexto da Engenharia de Requisitos (ER), as organizaes de software, como qualquer outra
organizao, sofrem com problemas relacionados falta de gerncia de conhecimento, uma vez que este est,
em sua maior parte, na mente de seus membros [1]. Dentre os vrios problemas a serem enfrentados,
destacam-se [2]: (1) perda de conhecimento que pode ocorrer se houver receio de compartilh-lo ou quando
um profissional se desliga da organizao; (2) escassez do conhecimento, que dificulta sua obteno por parte
de novos profissionais, diminuindo a produtividade; (3) falta de tempo para compartilhar o conhecimento; (4)
dificuldade em localizar um conhecimento especfico para resolver um problema e (5) dificuldade na
reutilizao do conhecimento quando do desenvolvimento de projetos similares.
Este artigo discute o uso de gerncia de conhecimento na Engenharia de Requisitos e apresenta CRETA
[13], uma ferramenta que apia a gerncia de conhecimento neste contexto. A ferramenta permite que o
conhecimento criado, aprendido e utilizado durante o processo de Engenharia de Requisitos seja formalizado,
armazenado e colocado disposio dos membros da organizao. Ela oferece recursos para atender a essas
necessidades, possibilitando, ainda, a organizao e disseminao de conhecimento atravs do uso de agentes.
Este artigo est estruturado da seguinte forma: a seo 2 aborda a Gerncia de Conhecimento na
Engenharia de Requisitos. Na seo 3, os requisitos de uma infra-estrutura para apoiar a Gerncia de
Conhecimento so apresentados. A seo 4 introduz CRETA, uma ferramenta de apoio Engenharia de
Requisitos Cooperativa, que explora o apoio Gerncia de Conhecimento na Engenharia de Requisitos e
discute os servios de gerncia de conhecimento gerais e especficos que foram introduzidos em CRETA. A
seo 5 discute os trabalhos correlatos. Finalmente, na seo 6, so apresentadas as concluses deste trabalho.
2. Gerncia de Conhecimento e Engenharia de Requisitos

A Gerncia de Conhecimento (GC) consiste em coletar e armazenar sistematicamente o conhecimento
adquirido, compartilhar este conhecimento atravs de uma memria organizacional e promover o surgimento
de novo conhecimento [11]. Neste contexto, conhecimento pode ser definido como informao combinada
com experincia, contexto, interpretao e reflexo, podendo ser explcito ou tcito [4]. Na literatura existem
vrios conjuntos de atividades propostos para a GC [1, 7]. Abecker et al. [1], por exemplo, afirmam que as
atividades bsicas da GC so: identificao, aquisio, desenvolvimento, disseminao, uso e preservao de
conhecimento. Nessa viso, a memria organizacional est no centro do processo, sendo considerada como
um repositrio do conhecimento disponvel na organizao [9]. Para atingir seus objetivos, a GC pode se
beneficiar de diversas tecnologias, tais como data warehouses, Internet, mquinas de busca, ontologias,
agentes e ferramentas de groupware [2, 5, 10, 11, 12].
Uma organizao de software deve possuir um processo de ER maduro, definido e bem documentado, com
objetivo de implementar boas prticas. Devem ser documentados, dentre outros, os procedimentos, as
atividades a serem realizadas, as competncias individuais, as lies aprendidas, os padres de documentos e
os diversos artefatos produzidos, tais como planos e atas de entrevistas, especificaes de requisitos de
software e mensagens eletrnicas trocadas [8]. Esses documentos no so apenas produtos do trabalho, pois
existe informao adicional dentro deles: (1) durante o projeto eles documentam as decises; (2) aps o fim
do projeto, eles contm o seu histrico. Podem ser reutilizados de diversas formas em projetos futuros, para
que as pessoas possam aprender com eles, atravs da anlise das solues de diferentes problemas similares
[12]. Dada a complexidade envolvida no processo de ER, uma preocupao crescente tem sido organizar,
registrar e gerenciar o conhecimento, experincias, documentos e padres envolvidos, de forma a promover
reuso, disseminao, compartilhamento e aprendizado organizacional. Sendo assim, uma abordagem
promissora consiste em utilizar a GC para apoiar o processo de ER. A criao de um repositrio de
conhecimento serviria como uma rea para o compartilhamento do conhecimento, apoiando vrias das
atividades da ER, tais como a definio do processo de ER e a elicitao de requisitos.
3. Requisitos de uma Infra-estrutura para Gerncia de Conhecimento

Para ser efetivamente utilizada, a GC deve estar integrada ao processo da organizao, permitindo que o
conhecimento relevante seja coletado e armazenado, medida que gerado no trabalho. Natali & Falbo [10]
discutiram a importncia da GC no desenvolvimento de software e apresentaram requisitos de uma infra-
estrutura de Gerncia de Conhecimento para organizaes de software . Como a ER parte do processo de
desenvolvimento de software, esses requisitos tambm se aplicam a uma infra-estrutura de GC para apoiar a
ER, tratando dos seguintes aspectos [10]:
R1. Deve ser permitido o cadastro do conhecimento formal sobre processos de software, incluindo
conhecimento sobre processos, atividades e procedimentos, dentre outros;
R2. Deve ser permitido o cadastro dos conhecimentos informais existentes na organizao, tais como
competncias individuais e lies aprendidas durante a realizao de um processo de software;
R3. Deve-se permitir a excluso peridica de itens de conhecimento formais ou informais obsoletos ou
sem utilidade, tomando por base o feedback dos usurios;
R4. Deve-se permitir a indexao tanto do conhecimento formal como das lies aprendidas aprovadas;
R5. Deve-se fornecer mecanismos de busca aos diversos itens de conhecimento;
R6. Deve-se permitir que o usurio avalie o conhecimento utilizado, classificando-o e registrando
comentrios, se for necessrio;
R7. Deve-se fornecer mecanismos de disseminao do conhecimento de forma pr -ativa, ou seja, de
iniciativa do prprio sistema. Os itens de conhecimento que o sistema julgar relevantes devem ser
apresentados ao usurio como uma sugesto de ajuda na realizao de uma atividade;
R8. Deve-se permitir o registro do projeto de software pelo gerente de projeto, bem como do processo
adotado para seu desenvolvimento de forma a possibilitar que possa ser controlado de forma efetiva;
R9. Durante a definio do processo de software, o sistema deve oferecer conhecimento j cadastrado
sobre processos de software de projetos semelhantes e fornecer sugestes para o gerente de projeto;
R10. Deve-se possibilitar o apoio s diversas atividades do processo de software de um projeto especfico,
permitindo que os artefatos de software produzidos possam ser armazenados, reusados e disseminados.
A Engenharia de Software, e por conseguinte a ER, trata de trabalho em equipe e, para apoiar as interaes
e discusses em grupo, diversas aplicaes de groupware podem ser utilizadas [3]. Nesse sentido, uma infra-
estrutura geral de GC tambm deve se beneficiar desse uso e, portanto, os seguintes requisitos gerais relativos
cooperao na GC tambm devem ser atendidos:
R11. Deve-se permitir que as comunicaes sncronas ou assncronas mediadas por computador, relativas
a um projeto de software, contendo as discusses, as idias, as justificativas e as opinies dos
membros da equipe possam ser registradas;
R12. Em relao memria organizacional, os itens de conhecimento registrados referentes memria do
processo de interao e comunicao em grupo devem ser organizados e indexados para facilitar o
compartilhamento, mesmo que os participantes estejam geograficamente distribudos;
R13. Deve-se permitir o registro das atividades do processo de software adotado, de forma a oferecer
mecanismos para que um participante de um projeto visualize os demais participantes ativos,
facilitando a comunicao, e perceba quem so seus parceiros, seu papel e as instrues para execuo
de cada atividade, bem como o perodo previsto e realizado e a situao de cada uma delas;
R14. Deve-se possibilitar a automatizao da coleta e apresentao para o grupo das informaes sobre as
atividades dos participantes individuais, dentro de um espao de trabalho compartilhado,
possibilitando atualizao contnua das aes dos participantes e do progresso global do grupo.
Conforme destacado por Natali & Falbo [10], o requisito R7 que trata da disseminao do conhecimento,
ainda que seja um requisito geral da Gerncia do Conhecimento, deve ser definido atravs de ferramentas
especficas, levando em conta seu funcionamento e caractersticas particulares, uma vez que no possvel
oferecer ajuda pr-ativa sem conhecer detalhes sobre a tarefa que est sendo realizada.
4. Introduzindo Gerncia de Conhecimento em CRETA - uma Ferramenta de Apoio

Engenharia de Requisitos Cooperativa
CRETA uma ferramenta de apoio Engenharia de Requisitos Cooperativa [13] se prope a integrar
aplicaes de groupware com a rea de ER, auxiliando o trabalho de engenheiros de requisitos, especialistas
de domnio, gerentes de projetos, patrocinadores e gerentes de conhecimento, que interagem com ela. Seu
objetivo apoiar as atividades principais do processo de ER, tais como elicitao, anlise, negociao,
documentao, validao, gerncia de requisitos e acompanhamento do processo de ER. Os participantes
fazem uso das ferramentas de groupware disponveis - tais como agenda eletrnica, correio e compromisso
eletrnico, listas de discusses, reunies virtuais sncronas (chat ) e assncronas (frum) - para facilitar a
comunicao, cooperao e interao entre os envolvidos.
A implementao de CRETA foi baseada na Web, utilizando-se as tecnologias Java e JSP-JavaServer

Pages, de forma a permitir que tanto os participantes geograficamente dispersos quanto os usurios internos
de uma organizao acessem a ferramenta. Entretanto, em sua verso original [13], CRETA no possua apoio
GC. Sendo assim, um novo componente denominado Gerncia de Conhecimento foi desenvolvido e
integrado CRETA, com objetivo de incorporar novas funcionalidades que possibilitam o registro do
conhecimento criado ou capturado, a recuperao, o acesso, o uso, a disseminao e a manuteno do
conhecimento armazenado, como mostra a figura 1.
A base do sistema de GC proposto sua memria organizacional, que gerencia o conhecimento necessrio
ER. Os diferentes itens de conhecimento existentes em CRETA foram agrupados em duas categorias:
Item de Conhecimento Formal, que agrupa o conhecimento sobre o processo de ER, incluindo o
conhecimento sobre atividades, modelos de ciclo de vida, mtodos, padres, recursos, os artefatos
gerados durante a execuo deste processo, dentre outros. Esses itens de conhecimento foram
definidos com base na ontologia de processo de software proposta em [6]. Agrupa tambm o
conhecimento sobre os padres de documentos e listas de verificao usados na ER;
Item de Conhecimento Informal, que agrupa o conhecimento sobre as competncias dos indivduos, as
lies aprendidas, que podem ser tanto pontos positivos quanto oportunidades de melhoria, e as
comunicaes eletrnicas efetuadas pelos participantes do processo de ER. Essas comunicaes
podem ser efetuadas atravs de correio eletrnico, compromisso eletrnico, chat e frum.
Gerente de Engenheiro de Especialista Gerente do Patrocinador do

Conhecimento Requisitos do Domnio Projeto Projeto
Definio Engenharia
Gerncia do Trabalho Acompanhamento
de de
Conhecimento Cooperativo de projeto
processo Requisitos
Memria Organizacional
Conhecimento Formal Conhecimento Informal
Projeto Lies
Conhecimento Recursos e Interaes e Aprendidas e
Processo Artefatos Comunica es
Padres Competncias
Figura 1 Arquitetura da ferramenta proposta.
4.1. Os Servios Gerais de Gerncia de Conhecimento em CRETA

Seguindo a proposta de Natali & Falbo [10], os requisitos apresentados na seo 3 so tratados em CRETA
principalmente atravs de servios gerais de GC, que podem ser utilizados a qualquer momento. CRETA
possibilita que o gerente de conhecimento cadastre o conhecimento formal sobre os processos de ER. A
excluso de um item de conhecimento formal pode ser feita pelo gerente de conhecimento, caso o item se
torne obsoleto ou sem utilidade. CRETA permite tambm que o engenheiro de requisitos ou o gerente de
projeto registrem os itens de conhecimento informal. No entanto, no caso das lies aprendidas, uma vez que
nem todas so teis organizao, antes que possam ser usadas e disseminadas CRETA possibilita que o
gerente de conhecimento possa estrutur-la, adapt-la e generaliz-la, bem como aprov-la.
Para facilitar o processo de recuperao dos diversos itens de conhecimento armazenados no repositrio,
esses itens so indexados em CRETA atravs de palavras-chave. Para apoiar a indexao automtica do
conhecimento, foi desenvolvido um Agente Indexador de Conhecimento. Quando um novo conhecimento
formal for cadastrado ou alterado ou uma lio aprendida for aprovada, esse agente analisa seu contedo em
busca de palavras-chave, previamente cadastradas, de forma a criar um ndice do contedo da memria
organizacional. Esse agente no se comunica com os outros agentes existentes em CRETA; apenas monitora
o banco de dados espera do cadastro de um novo item de conhecimento, para que este seja indexado.
CRETA permite a busca dos diversos itens de conhecimento armazenados na memria organizacional,
atravs da utilizao de filtros especficos. Essa busca uma iniciativa do usurio, pois cabe a ele definir suas
necessidades. Para auxiliar a manuteno da memria organizacional, se um item de conhecimento de ER for
reutilizado, seu contedo deve ser avaliado. CRETA possibilita que o usurio efetue essa avaliao,
atribuindo ao item uma classificao que varia de ruim a timo e registrando comentrios, tais como
problemas que enfrentou ao us-lo e solues adotadas. Finalmente, CRETA apia o gerente de
conhecimento na manuteno peridica da memria organizacional, tomando por base o feedback fornecido
pelos usurios. Itens de conhecimento obsoletos ou no usados podem ser identificados e excludos.
4.2. Os Servios Especficos de Gerncia de Conhecimento em CRETA

Apesar da maioria dos servios implementados em CRETA serem gerais, podendo estar presentes em
qualquer ferramenta de GC, h uma funcionalidade que fornecida de forma especfica em CRETA: a
disseminao de conhecimento, que particularmente importante quando os usurios no esto motivados a
buscar ou no sabem da existncia de conhecimento relevante tarefa que esto executando [10].
Agentes especficos foram implementados em CRETA para desempenhar um papel ativo na disseminao
do conhecimento armazenado. Esses agentes foram modelados utilizando-se a metodologia GAIA [14]. O
Agente Disseminador de Conhecimento implementado responsvel por monitorar o repositrio de
conhecimento e quando perceber que um novo conhecimento cadastrado de interesse de algum
desenvolvedor, envia uma solicitao (atravs do Agente Gerenciador de Servio) ao Agente Mensageiro para
que este envie um correio eletrnico informando sobre o novo conhecimento disponvel. O Agente
Disseminador baseia-se nas informaes das reas de interesse cadastradas por cada participante para
executar seu papel. O Agente Gerenciador de Servio foi definido, em tempo de projeto de arquitetura, para
ser responsvel pelo controle, registro e manuteno das interaes no sistema multiagente. Desse modo, as
interaes previstas entre os agentes so feitas via o Agente Gerenciador de Servio, que trata de repassar a
mensagem para o agente mais apropriado para respond-la ou para toda a organizao.
CRETA permite que o gerente de projeto registre um projeto e defina o processo de execuo da ER,
utilizando como apoio o conhecimento registrado na organizao. Para apoiar essa definio, foi construdo o
Agente Assistente do Processo de ER, que monitora a ao do gerente de projeto durante a definio do
processo de ER e, baseado nas informaes fornecidas, compara os projetos j cadastrados no ambiente e seus
respectivos processos, buscando caractersticas semelhantes. Esse agente pode enviar uma solicitao para o
Agente Atendente do Gerente do Projeto (atravs do Agente Gerenciador de Servios) fornecendo dados
estatsticos e sugestes para prover conhecimento para o gerente de projeto.
5. Trabalhos Correlatos
Existem inmeras pesquisas voltadas para a utilizao da GC para apoiar as organizaes de software e os
processos envolvidos no seu negcio, dentre os quais est o processo da ER [5, 10]. Natali & Falbo [10]
discutiram a importncia da GC no desenvolvimento de software e apresentaram uma infra-estrutura de GC
integrada ao ambiente ODE - Ontology-based software Development Environment, tendo por base ontologias.
CRETA possui alguns pontos em comum com esse trabalho. A base da infra-estrutura proposta a
memria organizacional, ao redor da qual os servios de GC so organizados. No entanto, a memria
organizacional de ODE estruturada com base em ontologias, o que no ocorre com CRETA. ODE e
CRETA apiam os servios gerais de GC, tais como armazenamento, busca, uso e disseminao de
conhecimento e utilizam agentes nessa disseminao. Por outro lado, adotam uma abordagem de GC de forma
a es tar ativamente integrada ao processo dirio de trabalho da equipe. ODE armazena conhecimento sobre o
processo de software, enquanto CRETA trata especificamente do conhecimento relacionado ER. Alm
disso, CRETA suporta o trabalho cooperativo e utiliza o conhecimento informal envolvido na troca de
mensagens como um item de conhecimento do repositrio, o que no acontece em ODE.
Dignum & Heinmannsfeld [5] apresentam a ferramenta Wisdom, que oferece uma linguagem de alto-nvel
para representao do conhecimento e possui facilidades para a coleta, codificao, apoio e processamento de
conhecimento dentro e fora da organizao. Em Wisdom, o conhecimento precisa ser representado como
tabelas de decises, sistemas de quadros ou atravs de Prolog, enquanto que, em CRETA, o conhecimento
representado na forma de objetos armazenados em tabelas de um sistema gerenciador de banco de dados
relacional.
6. Concluses
A ER, como um processo intensivo de conhecimento, deve se beneficiar dos recursos oferecidos pela GC
para tornar-se mais eficiente, gerando produtos de maior qualidade em um tempo menor. Este artigo
apresentou uma aplicao da Gerncia de Conhecimento na Engenharia de Requisitos que utiliza agentes para
automatizar esse apoio, facilitando a criao e utilizao de uma memria organizacional. Em relao aos
diversos requisitos apontados na seo 3, e que podem ser aplicados para apoiar a ER, o Quadro 1 apresenta a
situao de atendimento desses requisitos na verso atual de CRETA.
No que tange a ER, CRETA permite registrar os principais itens de conhecimento formal sobre o processo
de ER (R1) (R8). Em relao aos itens de conhecimento informal (R2), CRETA trata de lies aprendidas e
comunicaes efetuadas (R11), que so tratadas separadamente. Seria interessante que CRETA permitisse a
composio de pacotes de experincia usando tais comunicaes, como sugere a abordagem da Fbrica de
Experincia [2]. Com relao manuteno da memria organizacional (R3) (R6), CRETA oferece
mecanismos para tal. Contudo, a excluso de itens de conhecimento (R3) pode ser aperfeioada, de forma a
assumir uma postura mais pr-ativa. A indexao em CRETA (R4) (R12) feita atravs de palavras-chave e
pode ser aperfeioada com o uso de ontologias e, por conseguinte, a prpria busca (R5) e disseminao (R7).
CRETA apia diversas atividades da ER (R10), dentre elas a definio do processo da ER (R9). Contudo,
assistentes inteligentes podem aperfeioar esse apoio. Finalmente, no que se refere ao apoio ao trabalho em
equipe (R13) (R14), CRETA oferece diversas facilidades, tais como mecanismos que possibilitam que um
participante perceba quem so seus parceiros na execuo de uma determinada atividade, por exemplo. No
entanto, a percepo pode ser aperfeioada atravs da adoo de uma abordagem de feedback compartilhado.
Quadro 1 Atendimento dos requisitos de gerncia de conhecimento em CRETA.

Atendimento Requisito
R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14
Parcial x x x x x x x x x x
Total x x x x
Maiores experimentaes so necessrias para validar a ferramenta, explorar suas limitaes, confirmar as
concluses e apontar novas descobertas, pois, atualmente, CRETA est sendo utilizada somente com
propsitos acadmicos. A GC fornece os recursos bsicos necessrios para o desenvolvimento de uma cultura
de trabalho na qual ocorrem constantes trocas de conhecimento e aprendizado. Apesar disso, apenas a
existncia de ferramentas de apoio GC no suficiente para o estabelecimento dessa cultura. Torna-se
necessrio que os participantes dos projetos estejam conscientes da responsabilidade de cada um em
compartilhar o conhecimento que possuem, para enriquecer o contedo da memria organizacional.
Referncias
[1] A. Abecker, A. Bernadi, K. Hinkelmann. Toward a Technology for Organizational Memories. IEEE Intelligent
Systems. Nova York, v. 13, n. 3, p. 40-48, mai./jun. 1998.
[2] V. R. Basili, M. Lindvall, P. Costa. Implementing the Experience Factory Concepts as a Set of Experience Bases.
In: PROCEEDINGS OF THE INTERNATIONAL CONFERENCE ON SOFTWARE ENGINEERING &
KNOWLEDGE ENGINEERING (SEKE01), 13., 2001., Buenos Aires, Argentina.
[3] D. Chaffey. Groupware, workflow and intranets: reengineering the enterprise with collaborative software. Boston:
Digital Press, 1998.
[4] T. Davenport, L. Prusak. Working Knowledge: How Organizations Manage What They Know. Boston, USA: Harvard
Business School Press, 1998.
[5] V. Dignum, K. Heinmannsfeld. Knowledge Management for Requirements Engineering. In: PROCEEDINGS OF
THE WORKSHOP ON KNOWLEDGE ACQUISITION (KAW99), 12., 1999., Banff, Canada.
[6] R. A. Falbo. Integrao de Conhecimento em um Ambiente de Desenvolvimento de Software. 1998. 205 p. Tese
(Doutorado em Cincias em Engenharia de Sistemas e Computao) - Programa de Ps -Graduao de Engenharia,
Universidade Federal do Rio de Janeiro, Rio de Janeiro, 1998.
[7] G. Fischer, J. Ostwald. Knowledge management: problems, promises, realities, and challenges. IEEE Intelligent
Systems. New York, v. 16, n. 1, p. 60-72, jan./fev. 2001.
[8] G. Kotonya, I. Sommerville. Requirements engineering: processes and techniques. Chichester, Inglaterra: John
Wiley, 1998.
[9] T. Kouwenhoven. Reengineering for learning. SIGGROUP Bulletin. [S. L.], v. 19, n. 1, p. 39-45, abr. 1998.
[10] A. C. C. Natali, R. A. Falbo. Gerncia de Conhecimento em ODE. XVII SIMPSIO BRASILEIRO DE
ENGENHARIA DE SOFTWARE (SBES2003), 17., 2003., Manaus, AM.
[11] D. E. OLeary. Enterprise Knowledge Management. IEEE Computer. N. York, v. 31, n. 3, p.54-61, mar. 1998.
[12] I. Rus, M. Lindvall, S. S. Sinha. Knowledge management in software engineering: a state-of-the-art report. Rome,
NY, EUA: Departamento de Defesa Americano, 2001.
[13] D. F. Togneri, R. A. Falbo, C. S. Menezes. Supporting Cooperative Requirements Engineering with an Automated
Tool. In: WORKSHOP ON REQUIREMENTS ENGINEERING(WER02), 5., 2002, Valncia, Espanha.
[14] F. Zambonelli, N. R. Jennings, M. Wooldridge. Developing Multiagent Systems: The Gaia Methodology. ACM
Transactions on Software Engineering Methodology , v. 12, n. 3, p. 317-370, julho 2003.
Mtodos Heursticos para el Anlisis de Clasificacin en Sitios E-

Commerce
Ma Beatriz Bernbe Loranca

Cuerpo Acadmico de Ingeniera de Software -Aplicaciones Estadsticas.
Facultad de Ciencias de la Computacin, BUAP.
Calle 14 sur y Avenida San Claudio, Colonia San Manuel, Puebla, Mxico.
E- mail bety@cs.buap.mx
Luis Antonio Olsina Santos

GIDIS, Departamento de Informtica, UNLPam
Calle 9 y 110, (6360) General Pico, La Pampa, Argentina.
E-mail olsinal@ing.unlpam.edu.ar
Resumen
El presente trabajo emerge de un proyecto en el rea de la Teora Matemtica de la Computacin. Dentro

de esta disciplina, se distinguen algunas subreas como lo son la Teora de la Complejidad y Funciones
Recursivas y Maquinas de Turing. Entre los mltiples temas que se estudian en este campo, podemos
mencionar a los Mtodos Heursticos y Problemas NP y NP-Completos. Para efectos de aplicacin, se
recurri al estudio de 3 heursticas con el objetivo de obtener diferentes clases sobre una muestra de 49 sitios
E-Commerce. Consecuentemente, es posible comparar los conjuntos obtenidos con las categoras arrojadas
en al Anlisis de Conglomerados. Perseguimos de esta forma enriquecer y trascender la investigacin
iniciada en la evaluacin de sitios e-commerce hacia la construccin de modelos que sean capaces de
describir y explicar la relevancia de un sitio web en virtud de cierto grado de cumplimiento sobre la
funcionalidad de atributos de calidad. Mas an, planteamos la sospecha de asociacin entre sitios
independientemente de los atributos que compartan, y aunque sabemos que es prematuro hacerlo aqu, s
podemos decir que este trabajo marca la pauta para enunciar hiptesis que despierten el inters para
conocer ms a fondo las razones del porqu las categoras son de determinada manera.
As, el propsito principal de este artculo es poder encontrar grupos diferentes sobre una misma muestra
utilizando tres mtodos heursticos distintos, a saber: Bsqueda Local, Recocido Simulado, y Algoritmo de
Empatamiento. El resultado obtenido conduce a estudiar y reconocer el mecanismo ideal para el proceso
clasificatorio de sitios aleatorios en e-commerce, y, dado que dicho proceso se concentra en la clasificacin
de sitios, es obligado centrarse en analizar a los grupos obtenidos independientemente de la tcnica
aplicada. Por otro lado, se combinan los resultados concentrados en el Anlisis de Conglomerados con los
conjuntos que se observan en los tres mtodos que se explican en las secciones subsecuentes.
1. Introduccin
Es sabido que existen distintos mtodos cuantitativos de utilidad para la evaluacin de sitios web [11], como
as tambin mtodos y tcnicas para analizar datos y realizar predicciones. La actividad de evaluacin debera
tener tal grado de adopcin en la prctica, de forma tal que para que un sitio (por ejemplo, de e-commerce)
pudiera salir al mercado su calidad estuviera garantizada. Sin embargo, en la realidad esto rara vez sucede.
Prescindiendo de las estrategias que actualmente usan las empresas para asegurar la calidad y predecir sus
potenciales ventas, no slo sera til disponer de un modelo de calidad que refleje la descripcin de las
caractersticas y atributos necesarias para garantizar la calidad de un sitio de e-commerce, sino tambin saber
qu sucede con los sitios que cumplen con un cierto conjunto de tales caractersticas.
En el presente artculo se hace uso de las heursticas de Recocido Simulado, Bsqueda Local, y Algoritmo
de Empatamiento con el fin de obtener resultados de clases. Una vez obtenidas dichas clases, se realiza un
anlisis comparativo para reducir dichas clases en un conjunto final que este compuesto por los sitios
coincidentes que conforman los grupos para los diferentes mtodos aplicados.
Dado que se eligieron tres mtodos diferentes, conviene mencionar que este trabajo surge de un proyecto
experimental que se centra en aplicar heursticas de algoritmos NP y NP-completos a datos que no tuvieran
respuesta exponencial. La tabla que es objeto de estudio (ver tabla en [10]), obviamente no entra en la
categora NP. Sin embargo puede convertirse en un problema de tal magnitud si la matriz aumenta en sitios y
variables, lo que es totalmente viable dado el estado de crecimiento de la web. Por tanto, la aplicacin de
Recocido simulado [7, 12], Empatamiento, y Bsqueda Local, se bas inicialmente en programar los
algoritmos de cada una de las tcnicas tomando como datos de entrada a la matriz binaria, no importando la
naturaleza propia de las heursticas tal como se realiz con Conglomerados [2]. De esta manera, es posible
observar qu resultados se obtienen con diferentes estrategias (con una base terica bien definida como lo son
las heursticas), de un modo experimental. Esto nos permite adentrarnos cada vez ms en la esencia del
fenmeno sobre el procesamiento de nuestros datos binarios y alimentar los resultados que ya se obtuvieron
en Conglomerados y Ajuste Log-lineal. Deseamos posteriormente estudiar a cada uno de los sitios que
sobresalen en este estudio.
Cabe destacar que este avance de investigacin es consecuencia de trabajos previos [2, 9, 10].
Originalmente se parti de un modelo de funcionalidad que considera a 17 caractersticas para sitios de
comercio electrnico. Como hemos citado, los resultados se almacenan en una tabla binaria que representa
ausencia y presencia de los atributos de calidad [9]. Estos datos se procesaron y evaluaron con tcnicas
estadsticas multivariadas dando como resultado importantes relaciones de los atributos de calidad y de los
sitios. Particularmente, en este trabajo, se retoma la informacin obtenida el anlisis de Clusters con respecto
a los sitios. Considerando entonces las clases resultantes de los mtodos alternativos presentados en este
artculo, se crean otros nuevos a partir de los ya presentados en [10].
Para efectos de organizacin, el presente trabajo se divide en cinco secciones, a saber: 1) Introduccin, 2)
Mtodo de Recocido Simulado, 3) Algoritmo de Bsqueda Local, 4) Algoritmo de Empatamiento, y
finalmente las conclusiones.
2. Recocido Simulado
Por el lado de la heurstica Recocido Simulado se pretende reducir el problema mencionado al problema de
Coloreado de Grafos y resolverlo mediante Recocido Simulado creando un grafo donde cada nodo represente
un sitio web y las aristas sean las relaciones entre ellos. Los 49 sitios web y sus relaciones son representados
por un grafo no dirigido con 49 nodos (cada nodo representa un sitio). Las relaciones estn dadas por los
atributos en comn que poseen los sitios, es decir, cuanto ms parecidos sean los atributos que comparten dos
sitios, la posibilidad de que haya una arista que los una es mayor (se emplea este criterio en este trabajo pero
bien podran generarse instancias aleatorias para pruebas particulares). En este caso, se utiliz el criterio de
crear grupos para cada una de las categoras de funcionalidad, pero es ms viable producir clases sin
restricciones de atributos.
El problema de Coloreado de Grafos es uno de los problemas NP-difciles ms estudiados. Podemos

definirlo informalmente como sigue: Dado un grafo no dirigido, la meta es colorear los nodos del grafo con
un nmero de colores mnimo, de tal manera que si dos nodos son adyacentes deben tener diferente color [3].
A pesar de que los datos concentrados en la tabla binaria citada no tienen problema de respuesta en tiempo y
complejidad, no podemos asegurar que esta estabilidad se mantenga. Nos preocupamos sobre el futuro
comportamiento del procesamiento de los datos cuando se incremente el tamao de la muestra. Se asoma esta
incertidumbre por que los datos de los 49 sitios que se evaluaron, corresponden a un estudio del ao 2000.
Sin duda alguna, ha variado la situacin tanto de los sitios como de la muestra debido a que las condiciones
naturales del crecimiento en la web obligan al cambio, por ejemplo, cada vez son ms los portales e-
commerce que nacen y se actualizan, y, en menor cantidad, tienden a desaparecer.
La idea de promover la heurstica de Recocido Simulado en este artculo, es categorizar sitios con esta
tcnica, y posteriormente, extrapolarla a estudios recientes sobre muestras ms grandes de sitios e-commerce,
tanto de un mismo extracto como heterogneas, en donde se concentren sitios de diferentes pases.
El algoritmo de recocido simulado est basado en una analoga entre la simulacin de recocido de slidos y la
problemtica de resolver problemas de optimizacin combinatoria de gran escala. Recocido denota un
proceso de calentamiento de un slido a una temperatura en la que sus granos deformados recristalizan para
producir nuevos granos [3, 8]. Aplicando y adecuando lo anterior, el procedimiento principal que genera las
instancias y clases de nuestra tabla binaria de entrada es el algoritmo de la Figura 1, el cual fue codificado en
lenguaje C recurriendo a Visual Basic para que se produzca una interfaz atractiva de los grafos y sus aristas,
los cuales corresponden a los sitios y sus relaciones respectivamente.
Procedimiento RECOCIDO SIMULADO
Comenzar
INICIALIZAR(Si=estado_inicial, c=temperatura_inicial)
k = 0
Repetir
Repetir
Sj = PERTURBACIN(Si)
CRITERIO_METROPOLIS(Z(Sj), Z(Si))
Hasta equilibrio trmico
k = k + 1
c = ENFRIAMIENTO(c)
Hasta criterio de paro
Terminar
Figura 1. Procedimiento de Recocido Simulado.
Las pruebas se realizaron inicialmente con las tres clases de atributos referentes a Informacin del
Producto, Caractersticas de la Compra y Personalizacin del Cliente. Bajo la aplicacin del algoritmo de la
Figura 1, se gener una instancia para representar las relaciones de los atributos de la clase de Informacin del
Producto, que es la que se muestra en las Figuras 2 y 3, las cuales detallan el antes y despus del coloreado.
Figura 2 y 3. Clases sin colorear. Clases coloreadas Tabla 1. Informacin del Producto
Cuando la heurstica genera el coloreo, obtenemos 34 clases diferentes ya que los sitios, como puede
observarse, estn demasiado relacionados con respecto a este atributo, esto se debe a que la Informacin del
Producto es la categora que ms presencia tienen los sitios. Las clases arrojadas por el programa quedan
definidas en la Tabla 1. No perdamos de vista que de acuerdo a la manera en que se program esta heurstica,
cuanto ms clases resultantes haya, mayor es la relacin que se da entre los sitios.
Un aspecto interesante que debemos reflejar de estudios previos [2, 10] con respecto a esta seccin, son los
resultados arrojados por las tcnicas estadsticas con respecto a Caractersticas de la Compra, las cuales
sobresalieron en dicho estudio. En este epgrafe valoraremos ambos resultados.
Figura 4. Clases sin colorear y coloreadas Tabla 2. Caractersticas de la Compra
La instancia que representa los sitios y su relacin en cuanto a la clase de atributos de Caractersticas de la
Compra est dada por la Figura 4, en donde se puede observar que respecto a estos atributos, los sitios no
estn tan relacionados como en la clase anterior, de manera que se puede an distinguir nodos sin aristas
adyacentes. Como resultado tenemos el coloreado que se observa en dicha figura con slo 7 clases diferentes.
En la Tabla 2 se concentran las clases con respecto a la categora de Caractersticas de la Compra.
Recordemos las clases obtenidas (abajo llamadas grupos) en el Anlisis de Conglomerados ([2, 10]):
grupo 1: c3, c6, c9, c10, c11, c13, c19, c20, c21, c22, c27, c28, c34, c37, c40, c44, c47
grupo 2: c14, c15, c16, c25, c26, c41
grupo 3: c1, c4, c5, c8, c12, c17, c18, c24, c29, c31, c32, c38, c39, c42, c43, c45, c46, c48, c49
grupo 4: c2, c7, c23, c30, c33, c35, c36
Las analogas entre el grupo 1 de conglomerados y el grupo 1 de Recocido simulado, se distinguen en los
sitios 3, 6, 9, 13, 20, 21, 27, 28, y 40. Comparando el grupo 2 de la heurstica y el 1 de Clusters, obtenemos
las coincidencias 14, 15, 16, 25 y 41, concluyendo que el grupo 1 y 2 de Recocido Simulado bien pueden
formar una sola clase si adecuamos el algoritmo para que genere slo 6 clases. Cabe mencionar que en
Conglomerados, se crearon 4 clases ex profeso, debido a que en las rplicas realizadas, se prob con ms
clases, pero no se concluy en una buena sntesis que hablara sobre similitudes entre los sitios. Y, por el lado
de esta heurstica, el algoritmo se program para que se generaran tantas clases de acuerdo a las relaciones
similares entre sitios bajo el esquema de una determinada categora. Esto pretende de alguna manera
responder a las dudas que se asoman al observar las discrepancias entre las clases de ambas tcnicas, sin
embargo, esta situacin es sana en la discusin que orilla este estudio. Es fcil notar que ninguno de los
mtodos ha sido manipulado para lograr grupos exactos u homogneos, ya que, an siendo tcnicas distintas
con diferentes bases tericas y propsito, es posible observar interesantes coincidencias. Para la tercera clase
de atributos sobre Personalizacin del Cliente podemos ver la Tabla 3.
Tabla 3. Personalizacin del Cliente Tabla 4. Polticas de Promocin Tabla 5. Mecanismos de Bsqueda
Estas clases presentan mucha diferencia en relacin con los Clusters, las analogas que pudiramos
describir por el momento estaran forzadas, por tanto dejaremos la discusin en las conclusiones una vez que
hayamos presentado los resultados de los otros algoritmos. En cuanto a la categora de Polticas de
Promocin, la representacin esta dada en la Tabla 4. El programa cada vez que se ejecuta, genera un archivo
con los conjuntos que se forman. Finalmente, en la Tabla 5, ordenamos los sitios para la categora de
Mecanismos de Bsqueda. Se obtuvo un archivo con 21 grupos.
3. Bsqueda Local
Entre los procedimientos de aproximacin, una tcnica que resulta eficiente para hallar una asignacin que
verifique a una frmula que se pueda satisfacer, es la tcnica de bsqueda local. Para aplicar este
procedimiento a un problema particular, es necesario especificar el criterio de vecindad a un punto, la funcin
objetivo y un procedimiento que permita obtener las soluciones iniciales. El algoritmo de bsqueda local
que presentamos aqu opera sobre el espacio discreto de posibles asignaciones de la frmula de entrada. Como
funcin objetivo se usa el polinomio que se obtiene de aritmetizar la frmula booleana conocida en este tema.
Lo ms natural es que, partiendo de un punto inicial, en cada punto examinado se compara con sus vecinos y
se va por el primer descenso. Cuando se desciende, se repite el procedimiento. Para un punto x , denotamos
por com ( x , j ) al complemento de x en la direccin j, a saber, a la asignacin que coincide con x salvo en la j-
sima entrada, en donde tiene asociado el complemento de ( x ) j [7].
El esquema de Bsqueda Local es til para diferentes casos que presentan problemas de respuesta en
tiempo y complejidad, slo debe apropiarse a la situacin particular, incluso en este trabajo, observamos
claramente que la tabla con la que contamos, es un contraejemplo de este esquema y, sin embargo, se adecu
al procesamiento de los datos, arrojando importantes clasificaciones. Un ejemplo clsico, que es ideal para
aplicarle a este algoritmo, es el procesamiento de la tabla que corresponde a la evaluacin de la frmula
booleana. El conjunto de tales evaluaciones, generalmente se plantean como los valores de verdad de las
proposiciones asociadas, formando una estructura bidimensional binaria. Justamente de ah surge la idea de
hacer corresponder el mecanismo de procesamiento a estos resultados booleanos hacia nuestros datos binarios
de la tabla e-commerce.
Resumiendo y adecuando tal tcnica a nuestro caso, observamos que las categoras de atributos no son
homogneas, as que se les pueden asignar pesos, es decir, cada categora representa 5-1, y por tanto debemos
considerar esto cuando se le da importancia a las variables de cada categora. De esta manera se tiene: IP= 3;
3/17 = 5-1 , CC= 8; 8/17 = 5-1 , PC= 2; 2/17 = 5-1 , PP= 2; 2/17 = 5-1, MB = 2; 2/17 = 5-1
A partir de ahora le podemos dar un peso homogneo a cada uno de los atributos, sin importar a que
categora pertenezcan, y todas las categoras tendrn el mismo peso. Entonces cada atributo dependiendo de la
categora tendr el siguiente valor:
Atributo: IP = 1/15, CC = 1/40, PC = 1/10, PP = 1/10, MB = 1/10
Estos valores los podemos utilizar junto con la tabla de correlaciones para establecer un criterio de vecindad
en la aplicacin de bsqueda local. Dado que se trata de una matriz binaria con la que vamos a tratar, es
conveniente aplicar un mtodo de bsqueda local que se define por 3 puntos importantes:
1.- Un punto inicial,

2.- Una funcin objetivo f(x),
3.- Un criterio de vecindad
El punto inicial lo tomamos como mejor nos convenga en este caso es el primer elemento de la matriz dado
que no tenemos una funcin objetivo especfica. Lo importante en este caso ser el criterio de vecindad, para
el caso de bsqueda local, el criterio utilizado es la distancia de Hamming (DH), que consiste en que teniendo
una cadena de bits se selecciona una posicin y se intercambia el bit de esa posicin de 1 a 0 de 0 a 1,
dependiendo de su valor. Lo anterior es para DH = 1, que se refiere a que slo existir una diferencia de un bit
entre los vecinos -esta distancia puede ser mayor. As, para el caso anterior, se pueden generar n vecinos
donde n es la longitud de la cadena. Aplicando esta distancia a la matriz binaria de los sitios, sta la
utilizaremos para buscar vecinos y no producirlos. El mecanismo es el siguiente: se toma un sitio
representado por una fila de la matriz binaria, entonces se busca su vecino ms cercano, es decir, aquel otro
sitio con el que tenga la menor DH. Una vez realizado esto lo que hacemos con estos dos sitios es
fusionarlos. Se les aplica el operador AND, para generar un nuevo elemento que se almacena en una matriz
secundaria. Esta accin se hace iterativamente hasta que tengamos una clasificacin de 4 conjuntos de los
sitios. Esta DH la podemos limitar segn nuestras necesidades; la distancia que se est admitiendo es menor o
igual a 3. Se prob tambin con esta limitacin, pero a medida que avanzaba el programa ya no haba
elementos en la matriz que tuvieran una DH menor o igual a 3. Los resultados del mtodo de bsqueda local
se muestran a continuacin:
Conjunto1: 1,3,5,9,15,16,23,25,26,30,41,48,
Conjunto2: 6,8,10,13,14,17,19,22,27,32,34,36,37,40,44,47
Conjunto3: 2,7,11,20,21,28,33,35,38,39,43,45,46
Conjunto4: 4,12,18,24,29,31,42,49
A simple vista notamos coincidencias entre el grupo 1 de Conglomerados y el grupo 2 de Bsqueda Local.
En este algoritmo si forzamos la creacin de 4 clases para establecer una congruencia con el nmero de clases
de los Clusters, pero bien pudimos generar mas de 4 grupos. Debido a que estamos centrados en enriquecer
los estudios anteriores de clasificaciones, si indiscriminadamente producamos mas conjuntos con esta tcnica
la finalidad de comparacin se alejaba de nuestro objetivo.
4. Algoritmo de Empatamiento por Ocurrencia

El problema se basa principalmente en reducir la dimensin de una matriz binaria. Ya que los datos obtenidos
en esta tabla son de forma aleatoria, se supone que se consideran como una muestra del comportamiento
general de los sitios web. Entonces en esta seccin se propone una solucin basada en un algoritmo de
empatamiento por ocurrencia, el cual analiza y agrupa en forma estadstica la dependencia entre todas las
variables.
El algoritmo toma como entrada una matriz binaria de nxm, y un psilon que representa el margen de
similitud entre las variables y da como salida un agrupamiento basado en el cumplimiento de tal similitud. La
idea general se centra en verificar si cada variable est en relacin con el resto de las variables en cada uno de
los casos. Si es igual en todos los casos, entonces tiene una similitud de 100%, conforme aumente la variacin
en los casos, entonces disminuir tal porcentaje. Si el porcentaje satisface el criterio de similitud, entonces se
dice que las variables son similares y se agrupan en un mismo criterio. En este caso las variables que se
consideran en el algoritmo son los sitios web.
Entrada: Mat[n][m],
Salida: Mat[n][m]
For i 0 to m-1 begin
For j i+1 to m begin
For k to n begin
If(Mat[k][i] = Mat[k][j])
Prob prob+1
Endfor k
Prob prob/n
If((1-prob) < e)
Grupoi j
endfor j
endfor i
El algoritmo anterior se codific en lenguaje C. Se dise un mecanismo de optimizacin para que el

programa procesara una gran cantidad de datos sin observar una variacin significativa en el tiempo de
procesamiento. Analizando e interpretando el resultado producido por la implementacin del algoritmo
anterior, concluimos la siguiente similitud entre los sitios obtenidos por esta tcnica con respecto al Anlisis
de Clusters. Los grupos que se produjeron en este algoritmo son tambin 4. Las coincidencias con la
clasificacin de los sitios son:
G1: 4,9,19,20,21,22,37,40,44
G2: 17, 24, 31,32, 42, 46,48, 49
G3: 34
En el grupo 4 no hay iguales. El resto de los sitios tuvo dispersin con relacin a las dems tcnicas.
5. Conclusiones
Hemos encontrado similitudes y diferencias entre los grupos resultantes, y esto es lo que esperbamos.
Aunque no formulamos una hiptesis inicial sobre los sitios relevantes, si cremos en la posibilidad de
resultados coincidentes. La generacin de las clases usando los tres mtodos explicados en este artculo es
genuina, pero no podemos ser indiferentes en torno a la heterogeneidad de los 16 conjuntos comparados.Una
razn que explica esta dispersin obedece a que no se consideraron los mismos criterios de manipulacin en
los algoritmos, estos fueron aplicados de manera exploratoria, y ahora conociendo la situacin algortmica de
cada uno de los mtodos, podemos modelarlos ms robustamente para encontrar clases ms homogneas.
Como conclusin se puede mencionar que el problema se resolvi satisfactoriamente, sin embargo, es
necesario analizar los resultados obtenidos con estrategias y modelos de mercadotecnia para poder hallar una
posible relacin entre los resultados actuales con el enfoque operativo del anlisis de mercado. Deberamos
estudiar a fondo cmo se desenvuelven los sitios que sobresalieron en este trabajo. Por otro lado, podemos
decir que las heursticas son aplicables hasta el momento para una posible clasificacin basada en relaciones
bajo el criterio de similitud entre atributos de los sitios.
Refirindonos a la tcnica de Recocido Simulado, la mayor parte de las pruebas arroj resultados diferentes
pero podemos notar una cierta aproximacin entre las categoras de Personalizacin del Cliente y la de
Polticas de Promocin con una solucin de 15 clases en ambas. Notamos tambin que slo algunos sitios
como el 6 o el 34, resaltan en las comparaciones con las dems tcnicas el grupo concentrado. Ciertamente en
Recocido Simulado, se generaron clases tomando como base a las 5 diferentes categoras de funcionalidad.
Los otros mtodos no toman ese criterio.
Comparando Bsqueda Local, Clusters y Empatamiento observamos importantes diferencias y similitudes,

sin embargo, podemos reducir el anlisis a una clase final: 6, 9, 13, 19, 22, 27, 37, 40, 44, con una ocurrencia
de 3, excepto el sitio 40, que tuvo la mxima calificacin de 4. Evidentemente, este sitio cobra una gran
importancia, debido a que en [2], lo propusimos como representante de una clase bien definida.
Por el lado de la descripcin terica que intenta justificar la importancia de las tcnicas heursticas descritas
en las secciones anteriores, podemos decir que la razn que indujo a la aplicacin de estos algoritmos y/o
tcnicas al procesamiento de la tabla de sitios, se basa en un estudio experimental para expresar la
trascendencia de los mtodos heursticos en problemas no contenidos en los NP y NP-Completos. No
obstante, un gran parecido de nuestros datos sobre los sitios se observa en uno de los problemas NP clsicos
como lo es la tabla que concentra los valores de verdad sobre la evaluacin de predicados escritos en forma
clausular. De ah, emerge una inquietud en experimentar la aplicacin de los mtodos descritos en este paper.
Finalmente, la preocupacin de que en este artculo se de seguimiento a las investigaciones anteriores y se
promueva as ms estudio a partir de aqullos, obedece a que conociendo los resultados categricos y la
asociacin entre sitios, estos nos ayuden a responder a preguntas que se concentren en los sitios y no en los
atributos (como se enfatiz en [2, 10]). Por ejemplo, algunos cuestionamientos que siempre se asoman en un
anlisis de grupos de sitios web, son: Cul clase tiene mayor calidad? Qu significa que diferentes tcnicas
hayan categorizado a los sitios de esa manera? En qu me ayuda medir la calidad de un sitio el saber que
cierto sitio pertenece a la clase X? Si quisiera mejorar la calidad de un sitio que pertenece a la clase Z, qu
medidas debo tomar? Indudablemente, estas preguntas invitan e incentivan a profundizar nuestras
investigaciones recientes.
Referencias
[1] Anderson, T.W, 1984, "An Introduction to Multivariate Statistical Analysis", 2nd Edition, Wiley.
[2] Bernbe L., B, Olsina, L; 2003, Anlisis Factorial de Correspondencias Simples en el procesamiento de datos
cualitativos sobre funcionalidad en comercio electrnico, XI Conferencia de Ingeniera Elctrica 2003, CINVESTAV-
IPN, Mxico.
[3] Carlos Domingo, Tania Jimnez. Recocido Simulado. Posgrado en Modelado y Simulacin de Sistemas.Universidad
de los Andes, Venezuela. http://Chue.Ing.Ula.Ve/Docencia/Postgrado/Cursos/Mss05/Sa-Mio.Html
[4] Delta Luna, G. Morales Notas Lgica/Ibera 86, http://delta.cs.cinvestav.mx/~gmorales/logica/ibera96/node4.html
[5] Dillon, W.R. & Goldstein, M., 1984, "Multivariate Analysis: Methods and Applications", Wiley, NY.
[6] Dixon,W.J , 1990, "BMDP Statistical Software Manual", Vol I, II., Dixon,W.J Eds, University of California Press,
Berkeley, California.
[7] Hctor Sanvicente Snchez, Implementacin del Algoritmo de Recocido Simulado en la Determinacin ptima de
los Dimetros de las Tuberas de una Red de Agua:
http://W3.Mor.Itesm.mx/~Jfrausto/Papers/Sanvice/Connachidra/Morelia.Doc
[8] Jos David Canca Ortiz. Notas Recocido Simulado. Univ. de Sevilla, http://www.Esi2.Us.Es/~Dco/Recocido.Htm
[9] Lafuente, G.H.; Oliveto, J.; Olsina, L.; 2000, Requerimientos de Calidad en Sitios de E-commerce Proceed. JUCSE
00, Nuevas Tendencias en Ingeniera de Software, Universidad Catlica de Santiago del Estero, Argentina, ISBN 950-
31-0045-3
[10] Loranca, M.B. & Olsina, L.; 2003, Tcnicas Estadsticas para el Anlisis de la Calidad de Sitios Web , 6o
Workshop Iberoamericano de Ingeniera de Requisitos y Ambientes Software (IDEAS 2003), Asuncin, Paraguay, pp.
178-189, ISBN 84-96023-05-2.
[11] Olsina, L., Rossi G., Measuring Web Application Quality with WebQEM, IEEE Multimedia, 9(4), 2002, pp. 20-29.
[12] Optimizacin Con Recocido Simulado Para El Problema De Conjunto Independiente. Informtica en Lnea.
Publicacin UAM. No 3, Art. 2. http://Www.Azc.Uam.Mx/Publicaciones/Enlinea2/3-2rec.Htm
Una Aproximacin Lingstica de

Ingeniera de Requisitos para OO-Method
Isabel Daz Oscar Pastor Lidia Moreno Alfredo Matteo

Universidad Central de Venezuela Universidad Politcnica de Valencia (Espaa)
{idiaz|opastor|lmoreno}@dsic.upv.es ~ amatteo@kuaimare.ciens.ucv.ve
Resumen
En este trabajo se describe una aproximacin que utiliza tcnicas de anlisis del lenguaje natural para el
tratamiento de los requisitos de un sistema de software. Est basada en un proceso que se desarrolla con el
propsito de generar automticamente diagramas de secuencia a partir de la especificacin textual de los
casos de uso. Se trata de integrar esta facilidad al marco de Ingeniera de Requisitos de OO-Method, un
mtodo orientado a objetos concebido para la produccin automtica de sistemas de software. La
aproximacin lingstica define una estrategia para la construccin de ontologas a distintos niveles de
abstraccin, estableciendo mecanismos de trazabilidad entre stas. Con tal propsito utiliza roles semnticos
que sirven de enlace entre las abstracciones de cada modelo, independientemente del patrn sintctico
empleado para identificarlas. Adems de simplificar las tareas del Analista, la aproximacin garantiza que
los requisitos tengan una contraparte en el Modelo Conceptual OO-Method al mismo tiempo que agilizan las
actividades de documentacin y mantenimiento del sistema.
1. Introduccin
Desde hace ms de tres dcadas se han reportado diversas aproximaciones basadas en tcnicas y
herramientas de procesamiento del lenguaje natural para el desarrollo de sistemas de software [4]. Distintos
han sido sus propsitos y mbitos de accin [27]. De particular inters para este trabajo son aquellas que
hacen uso de las propiedades lingsticas de un texto para obtener informacin que permita construir modelos
conceptuales automticamente [6, 22, 33, 37]. Y ms especficamente, las propuestas que establecen vnculos
susceptibles de automatizar entre una especificacin funcional de requisitos y patrones de interaccin de
instancias. Tal es el caso de los trabajos de Feijs y Li. El estudio presentado por Feijs establece
correspondencias entre algunos tipos de sentencias escritas en lenguaje natural y MSCs (Message Sequence
Charts) [16]. Un caso de uso es considerado como una concatenacin de sentencias, cada una de las cuales
tiene asociado un tipo de MSC semnticamente equivalente. Por otra parte, Li plantea un proceso
semiautomtico de derivacin de diagramas de secuencia a partir de descripciones textuales de casos de uso
[25, 26]. La traduccin permite obtener parcialmente un conjunto de instancias y algunos de los mensajes que
stas intercambian.
La aproximacin que se expone en este artculo sigue la direccin de los trabajos referidos. Fue ideada con
el propsito de incorporar tcnicas de procesamiento de lenguaje natural en OO-Method, un ambiente
particular de generacin automtica de software. Este sistema orientado a objetos transforma modelos de alto
nivel de abstraccin sucesivamente hasta lograr obtener el cdigo de la aplicacin. La primera transformacin
automtica de modelos en OO-Method ocurre al finalizar la etapa de Ingeniera de Requisitos, durante la cual
el Analista construye el Modelo de Diagramas de Secuencia. Este modelo es utilizado entonces para generar
una versin preliminar del Modelo Conceptual. La aproximacin lingstica que se describe en este trabajo
introduce un nuevo mecanismo que permite traducir, de forma semiautomtica, un Modelo de Casos de Uso
en un Modelo de Diagramas de Secuencia. Este proceso se desarrolla en cuatro fases. Las tres primeras dotan
de informacin morfosintctica y semntica a las oraciones del caso de uso. En la cuarta fase, esta
informacin es utilizada para convertir cada oracin en un patrn de interaccin de instancias.
Este artculo ha sido estructurado en diez secciones. La primera se ha reservado a esta introduccin. La
segunda seccin describe OO-Method como contexto, motivacin y objetivo del trabajo presentado. La
tercera seccin muestra una perspectiva general de la aproximacin lingstica propuesta. En las cuatro
secciones siguientes se presentan las fases del proceso sobre el que se fundamenta esta aproximacin en

Esta investigacin ha sido subvencionada por el Consejo de Desarrollo Cientfico y Humanstico de la Universidad Central de
Venezuela y el Proyecto CICYT SIRIM (TIC2003-07158-C04-03).
trminos de sus objetivos, insumos y productos y de las actividades que se desarrollan. La octava seccin
describe el estado actual de la investigacin y su proyeccin en un futuro inmediato. Por ltimo, las
conclusiones del trabajo realizado y las referencias.
2. OO-Method
OO-Method es un sistema de produccin automtica de software
compuesto de un editor grfico que permite modelar el dominio de la MODELO CONCEPTUAL
aplicacin y un compilador que transforma estos modelos en cdigo
[17, 28, 35]. En OO-Method cumple un rol protagnico la construccin CLASE 1 CLASE 2
del Modelo Conceptual a partir del cual es posible generar de forma

CLASE 3 CLASE 4
automtica el Modelo de Ejecucin (Fig. 1). El Modelo Conceptual
CLASE 5
describe grficamente el espacio del problema desde las perspectivas MODELO OBJETO
estructural, dinmica, funcional y de presentacin. Cada primitiva de S1 Class: C
modelacin utilizada en estas representaciones tiene su contraparte en E1 [accept] state = "r"
S2 [return] state = "f"
OASIS, un lenguaje de especificacin formal orientado a objetos basado S3 MODELO
E1
en lgica dinmica [34, 36]. As, cada pieza de informacin grfica del FUNCIONAL
Modelo Conceptual puede ser traducida automticamente a un concepto C1 self::[y=0]
OASIS. La especificacin OASIS es utilizada luego para generar el
Modelo de Ejecucin que describe el sistema en un lenguaje de MODELO MODELO DE
DINMICO PRESENTACIN
programacin determinado.
TRADUCCIN
La construccin del Modelo Conceptual se realiza a partir del Modelo AUTOMTICA
de Requisitos del sistema de software en desarrollo [17, 18]. La Figura 2
muestra los modelos que se generan durante la fase de Ingeniera de OASIS
Requisitos de OO-Method. Esta fase inicia con la definicin de la
Misin que describe la razn de ser del sistema y sus principales TRADUCCIN
funcionalidades. Considerando las posibles interacciones del sistema AUTOMTICA
con su entorno se obtiene el rbol de Refinamiento de Funciones

(ARF), cuya raz corresponde a la Misin del Sistema. Tal MODELO DE EJECUCIN
representacin materializa la descomposicin jerrquica de las Visual Visual
Basic Java C++
funcionalidades del sistema en funciones con distintos niveles de BDR BDR BDR
abstraccin. Un nodo intermedio del ARF puede ser visto como un
compendio de funciones elementales descritas por los nodos hoja. Una
funcin elemental es aquella que puede ser activada directamente por un Fig. 1. OO-Method
actor o por la ocurrencia de un evento temporal.
Cada una de las funciones elementales del ARF ser un caso de uso en el Modelo de Casos de Uso.
Utilizando una estrategia iterativa de refinamiento se completa este modelo mediante la identificacin de los
actores que interactan con estos casos de uso, la descripcin en lenguaje natural de estos ltimos, la
determinacin de otros casos de uso que se deriven de los identificados a travs del ARF y el establecimiento
de relaciones entre stos (de inclusin y extensin). La construccin del Modelo de Casos de Uso permite
enlazar el Modelo de Requisitos (que especifica la interaccin del sistema con su entorno) y el Modelo
Conceptual OO-Method (encargado de describir los componentes internos del sistema, sus relaciones y
restricciones). Este enlace se concreta a travs del Modelo de Diagramas de Secuencia. Se construye un
diagrama de secuencia para cada escenario de un caso de uso y se aplican ciertos estereotipos predefinidos
que permiten clasificar los mensajes [17, 32]. La informacin aportada por el Modelo de Diagramas de
Secuencia posibilita la generacin semiautomtica de una versin preliminar del Modelo Conceptual. Esto se
realiza a travs de un conjunto de mecanismos de trazabilidad responsables de establecer correspondencias
entre dichos modelos (Fig. 2).
La construccin del Modelo de Diagramas de Secuencia a partir del Modelo de Casos de Uso es una labor
manual. La identificacin de objetos, mensajes y parmetros es tarea exclusiva del Analista quien, utilizando
su experiencia y conocimiento del problema, elabora el diagrama de secuencia de un escenario en particular.
El proceso que se describe en este trabajo permite generar de forma semiautomtica una versin preliminar
del Modelo de Diagramas de Secuencia a partir del Modelo de Casos de Uso. La traduccin es
"semiautomtica" porque requiere la participacin del Analista. Esta participacin es guiada y controlada por
el mismo proceso. Adems de facilitar las tareas de edicin de los diagramas de secuencia, este nuevo punto
de traduccin en OO-Method tiene otras ventajas de mayor trascendencia para efectos del fin ltimo que se
persigue: la construccin del Modelo Conceptual OO-Method. Dos de las ventajas son:
Consistencia: lograda por utilizar siempre los mismos criterios para la MODELO DE
REQUISITOS
deduccin y especificacin de los elementos de cada diagrama de
secuencia a partir del Modelo de Casos de Uso. Esto se garantiza MISIN DEL SISTEMA
debido a que tales criterios son inherentes al mtodo y a la

herramienta que implementa su aplicacin, independientemente de ARF
razonamientos personales y subjetivos. F1 F2 F3
Trazabilidad: es posible determinar con exactitud el impacto que

F4 F5
ocasiona en el Modelo de Diagramas de Secuencia, los cambios
realizados en el Modelo de Casos de Uso y viceversa.
MODELO DE
CASOS DE USO
El proceso de de traduccin semiautomtica del Modelo de Casos de
Uso al Modelo de Diagramas de Secuencia, se sustenta en el uso de
tcnicas y herramientas de procesamiento del lenguaje natural [2, 30].
Este proceso tiene el propsito de:

Obtener informacin del texto de un caso de uso de tal manera que
sea posible generar una versin preliminar de los diagramas de MODELO DE
secuencia que le correspondan. DIAGRAMAS DE
SECUENCIA
Establecer mecanismos de trazabilidad bidireccional entre el Modelo
de Casos de Uso y el Modelo de Diagramas de Secuencia.
Aplicar una estrategia para la creacin de ontologas que representen
la conceptualizacin concertada del universo del discurso tanto a
MODELO CONCEPTUAL
nivel de requisitos (Modelo de Casos de Uso) como de anlisis
(Modelo de Diagramas de Secuencia). TRADUCCIN
MANUAL
TRADUCCIN
SEMIAUTOMTICA
Garantizar la continua y oportuna actualizacin de la documentacin

Fig. 2. Ingeniera de Requisitos
del sistema.
3. Descripcin del Marco Lingstico

El proceso de traduccin de casos de uso en diagramas de
Mensaje
secuencia se apoya en una plataforma que permite procesar y
Emisor
controlar la informacin lingstica. Esta informacin es obtenida,
principalmente, de la especificacin en lenguaje natural de los Mensaje
Receptor
casos de uso. El texto de un caso de uso describe la funcionalidad Mensaje
del sistema desde la perspectiva de sus tipos de usuarios. Esta
funcionalidad es expresada como una secuencia completa de Actor Sistema
Emisor/Receptor Emisor/Receptor
interacciones entre el actor y el sistema con el propsito de
satisfacer algn objetivo, incluyendo posibles variantes de dicha Fig. 3. Modelo de Comunicacin
secuencia [9, 10, 20, 32].
Un caso de uso describe la comunicacin establecida entre un actor y el sistema para el intercambio de
informacin as como tambin las acciones que debe realizar el sistema internamente para dar respuesta a
estas solicitudes de informacin (Fig. 3). Estas acciones son contadas tal como son percibidas desde el
exterior del mismo, sin revelar detalles internos. El sistema es considerado como una caja negra que procesa o
transforma la informacin suministrada por los actores. En este contexto, un escenario es una secuencia o
trayectoria especfica de las acciones que describe un caso de uso [21, 32, 39]. Un caso de uso es considerado
como una compilacin de mltiples escenarios, cada uno de los cuales es una instancia del caso de uso [9,
20].
El marco lingstico propuesto supone que la especificacin de un caso de uso se concreta a travs de un
documento semi-estructurado escrito en "lenguaje natural" que describe determinada funcionalidad de un
sistema de software [14]. La Figura 4 muestra parte de la gramtica que detalla la estructura que debe tener el
lenguaje de un caso de uso. Esta estructura podra redefinirse, en atencin a intereses particulares de
documentacin o segn la utilidad que pretenda drsele. Ntese que, en la gramtica, un caso de uso es
expresado como una secuencia ordenada de oraciones simples y oraciones especiales (entre otras:
condicionales, iteraciones, inicio y fin). Las oraciones simples tienen un nico sujeto (el actor o el sistema) y
un slo predicado (un nico verbo que describe la accin ejecutada por el actor o el sistema) [1]. Adems, esta
estructura permite establecer un particular estilo de representacin de las oraciones simples de un caso de uso.
As, una oracin debe ser redactada de forma declarativa, afirmativa y activa. El sujeto de una oracin simple
debe ser el actor o el sistema para lo cual debe utilizarse un sustantivo, en singular y sin adyacentes. El verbo
debe ser transitivo, en modo indicativo, tiempo presente, forma simple, nmero singular y en tercera persona.
<Caso de Uso> ::= <metainformacin><cuerpo>
<cuerpo> ::= <trayectoria bsica>[<trayectoria alterna>]
<trayectoria bsica> ::= caso_de_uso 'INICIA CUANDO' {<paso>}+
<paso> ::= [nmero]{<oracin simple>|<oracin especial>}
<oracin simple> ::= <oracin de interfaz>|<oracin de proceso>
<oracin de interfaz> ::= <actor-sistema>|<sistema-actor>
<actor-sistema> ::= [determinante] actor {<comunicacin>|<accin no predefinida>} <objeto> {<circunstancia>}*
<sistema-actor> ::= <sistema-actor directa>|<sistema-actor indirecta>
<sistema-actor directa> ::= [determinante] sistema <comunicacin><objeto>{<circunstancia>}*
<sistema-actor indirecta> ::= [determinante] sistema <accin><objeto>{<circunstancia>}* {'a' | 'para' | 'al'} [determinante] actor
<oracin de proceso> ::= [determinante] sistema {<operacin>|<accin no predefinida>}<objeto>{<circunstancia>}*
<objeto> ::= <sintagma nominal> [ { 'y' | ',' } <sintagma nominal> ]+
<sintagma nominal> ::= [determinante] [adjetivo]sustantivo[adjetivo][<SP indeterminativo>]
<accin> ::= <comunicacin>|<accin no predefinida>|<operacin>
<comunicacin> ::= 'enva' | 'muestra' | 'informa' | 'solicita' | 'requiere' | 'introduce' | 'presenta' | 'notifica' | 'transmite'
<operacin> ::= 'registra' | 'consulta' | 'actualiza' | 'calcula' | 'obtiene' | 'compara' | 'verifica' | 'activa'
<accin no predefinida> ::= verbo_transitivo
<circunstancia> ::= <SP de pertenencia> | <SP de objeto indirecto> | <SP de cooperacin>
<SP de pertenencia> ::= {'de' | 'del'} <sintagma nominal>
<SP de objeto indirecto> ::= {'a' | 'para' | 'al'} <sintagma nominal>
<SP de cooperacin> ::= {'con'} <sintagma nominal>
<SP indeterminativo> ::= preposicin[adjetivo]sustantivo[adjetivo]
Figura 4. Vista "Parcial" de la Gramtica Propuesta
Por otra parte, la funcionalidad descrita en un caso de uso debe: (a) responder a una meta de interaccin
entre el sistema y uno o ms actores; (b) presentarse en trminos de la intencin del usuario al interactuar con
el sistema y de las responsabilidades de este ltimo; (c) ser expresada de forma esencial, utilizando el
lenguaje del dominio del problema (segn la clasificacin de Constantine y Lockwood [10, 11]);
(d) considerar un ambiente ideal de implementacin, excluyendo aspectos relativos a los recursos
tecnolgicos requeridos para la realizacin del caso de uso (nivel de requisitos) [15]; (e) mantener un nivel de
interaccin semntica, que significa que el caso de uso no debe describir la interfaz que utiliza el actor para
comunicarse con el sistema ni el formato de la informacin intercambiada con el sistema (segn la
clasificacin de Cockburn [9]).
El marco lingstico propuesto se fundamenta en un proceso iterativo que se desarrolla a travs de cuatro
fases secuenciales denominadas, respectivamente: Normalizacin Sintctica (Fase 1), Normalizacin
Semntica (Fase 2), Categorizacin (Fase 3) y Transmutacin (Fase 4). Las tres primeras fases dotan al caso
de uso de informacin lingstica. En la cuarta fase, esta informacin es utilizada con el fin de obtener los
diagramas de secuencia correspondientes. Se han especificado cada una de estas fases, sus actividades y las
relaciones establecidas entre stas utilizando SPEM (Software Process Engineering Metamodel) [31].
Tambin se han distinguido, explcitamente, las actividades en las que es necesaria la participacin del
Analista. Esto se indica grficamente mediante una lnea bidireccional que conecta la actividad y el Analista,
mostrando el intercambio de informacin que se efecta para el cumplimiento de las tareas de especificacin.
4. Normalizacin Sintctica
Los objetivos principales de esta primera fase del proceso de traduccin son dos: (1) preparar el texto del
caso de uso de manera tal que pueda ser utilizado para obtener informacin que facilite la construccin
automtica del Modelo de Diagramas de Secuencia y (2) generar una especificacin estndar del caso de uso
con fines de documentacin del sistema en desarrollo. La fase de Normalizacin Sintctica permite
determinar si el texto de un caso de uso cumple con las reglas de estructuracin y estilo de redaccin
impuestos por la gramtica predefinida. Se pretende as restringir las mltiples alternativas gramaticales que
el idioma ofrece, de tal manera que slo sean usados los componentes sintcticos ms adecuados y
convenientes para describir funcionalidades. Se trata con esto de eliminar las ambigedades, redundancias e
inconsistencias que la utilizacin del lenguaje natural haya podido introducir en el texto del caso de uso.
Adems de mejorar la calidad de la documentacin de los requisitos, esta fase se propone reconocer en cada
oracin del caso de uso sus constituyentes lxicos y dotarlos de informacin morfolgica til para que,
posteriormente, sea posible identificar elementos de modelado como, por ejemplo, instancias y parmetros.
La Normalizacin Sintctica inicia con la trascripcin del cuerpo del caso de uso y la incorporacin de la
informacin descriptiva del mismo. Como resultado, se espera obtener un caso de uso semi-estructurado,
gramaticalmente correcto y enriquecido con informacin morfosintctica. Para esto se realizan las siguientes
actividades (Fig. 5):
Edicin: consiste en la redaccin en
lenguaje natural del texto que forma parte NORMALIZACIN
SINTCTICA
del cuerpo del caso de uso (trayectoria
bsica y trayectorias alternas) y la
Anlisis
incorporacin de informacin descriptiva del Morfosintctico
mismo (nombre, actor principal, resumen,

precondicin, etc.). El texto debe ser escrito
segn la gramtica y reglas de estilo que se Revisin
Ortogrfica
Estructuracin
hayan establecido previamente. Esto es

verificado simult-neamente con el apoyo de
Completo
las actividades de Revisin Ortogrfica y /\
Incompleto
Edicin Etiquetacin
Estructuracin. La Figura 6 muestra un Analista
NORMALIZACIN
SEMNTICA
ejemplo de caso de uso, una vez realizada la

actividad de Edicin.
Revisin ortogrfica: realiza la verificacin Notacin: Fase ; Actividad ; Transicin ; Dependencia
ortogrfica del texto del caso de uso as Fig. 5. Actividades de la Fase de Normalizacin Sintctica
como la determinacin de palabras
inexistentes en los diccionarios del idioma.
Estructuracin: los constituyentes morfolgicos identificados a travs del Anlisis Morfosintctico son
agrupados en categoras sintcticas de nivel superior, esto es, en estructuras sintagmticas. Esta actividad
permite determinar si se ha respetado la estructura impuesta por la gramtica y las reglas de estilo
preestablecidas. Adems, se encarga de garantizar la concordancia gramatical de las oraciones del texto de
un caso de uso.
Anlisis Morfosintctico: consiste en la Caso de Uso Venta de Artculos
Actor Cajero
obtencin de las posibles interpretaciones Resumen Permite registrar la informacin de la venta de uno o ms artculos.
morfolgicas de cada palabra del cuerpo del Venta de Artculos INICIA CUANDO el Cajero inicia la sesin de una venta.
caso de uso y la identificacin de sus 1. El Sistema activa una nueva sesin de una venta.
2. El Sistema solicita el cdigo de barras y la cantidad vendida de un artculo.
respectivos rasgos gramaticales. Incluye la
PARA un artculo
desambiguacin de aquellas palabras que 3. El Cajero introduce el cdigo de barras y la cantidad vendida del artculo.
admiten ms de una interpretacin morfolgica. 4. El Sistema obtiene la descripcin y el precio por unidad del artculo.
5. El Sistema calcula el monto de la venta del artculo.
Etiquetacin: a cada palabra se asigna 6. El Sistema calcula el subtotal de la venta.
informacin relativa a sus rasgos morfolgicos 7. El Sistema muestra el subtotal de la venta.
8. El Sistema registra la descripcin, la cantidad vendida, el precio por unidad
y a la categora sintctica a la que pertenece. y el monto de la venta del artculo.
Para esto se requiere realizar un anlisis 8.1. El Sistema actualiza la cantidad en existencia del artculo.
morfosintctico de cada oracin del cuerpo del 9. El Sistema solicita el cdigo de barras y la cantidad vendida de un artculo.
caso de uso. La Figura 7 muestra cmo se FinPARA
10. El Cajero finaliza la sesin de la venta.
etiqueta la oracin correspondiente al paso 5 del 11. El Sistema calcula el monto total de la venta.
caso de uso Venta de Artculos (Fig. 6). 12. El Sistema muestra el monto total de la venta.
13. El Sistema registra la fecha y monto total de la venta.
14. El Sistema imprime el comprobante de la venta.
FIN Venta de Artculos
Fig. 6. Edicin de un Caso de Uso

PALABRA LEMA DESCRIPCIN MORFOSINTCTICA

Categora: Determinante ; Tipo: Artculo
El el Gnero: Masculino ; Nmero: Singular SINTAGMA
NOMINAL
Sistema Sistema Categora: Nombre ; Tipo: Propio
Categora: Verbo ; Tipo: Principal
GRUPO
calcula calcular Modo: Indicativo ; Tiempo: Presente
VERBAL
Persona: Tercera ; Nmero: Singular
el el Gnero: Masculino ; Nmero: Singular
Categora: Nombre ; Tipo: Comn SINTAGMA
monto monto Gnero: Masculino ; Nmero: Singular NOMINAL
Categora: Adjetivo ; Tipo: Calificativo
total total Gnero: Comn ; Nmero: Singular
de de Categora: Preposicin PREPOSICIN
GRUPO
la la Gnero: Femenino ; Nmero: Singular SINTAGMA
SINTAGMA
PREPOSICIONAL
Categora: Nombre ; Tipo: Comn NOMINAL DE PERTENENCIA
venta venta Gnero: Femenino ; Nmero: Singular
Fig. 7. Etiquetado de una Oracin Simple
5. Normalizacin Semntica
Despus que el caso de uso ha sido convenientemente estructurado, verificado sintcticamente y sus
unidades lxicas identificadas segn la funcin gramatical que cumplen dentro de la oracin, inicia la fase de
Normalizacin Semntica. Su principal objetivo es garantizar la consistencia terminolgica del texto del caso
de uso. Se trata de establecer un significado nico de determinadas palabras utilizadas al describir la
funcionalidad de un caso de uso. Se supone que el alcance mximo de la unicidad semntica es el contexto del
sistema de software en desarrollo aunque puede restringirse, segn convenga, a una de sus unidades
componentes. El caso de uso es el mbito mnimo de unicidad semntica que es posible considerar. Al
culminar esta fase, cada una de las palabras del cuerpo del caso de uso se ha provisto de significado y de
informacin til acerca de sus relaciones gramaticales con otras palabras.
Para estudiar el lxico de un caso de uso se distinguen las palabras que contienen informacin significativa
del dominio de aquellas que carecen de sta. En el caso de uso que se presenta en la Figura 6 puede afirmarse
que las palabras "artculo" y "venta" aportan informacin del dominio. Desde la perspectiva gramatical, este
tipo de palabras se caracterizan porque tienen sentido lxico designando: objetos, acciones o cualidades
representativas del mbito particular que describen. Las palabras que tienen sentido lxico pertenecen a clases
abiertas1. Sustantivos, verbos, adjetivos y adverbios del texto de un caso de uso son palabras que,
potencialmente, pueden tener sentido lxico en virtud de la funcin semntica que cumplen2. Por otra parte, es
posible tambin que la informacin significativa haya sido adherida a una unidad conformada por ms de una
palabra (abiertas y/o cerradas). En el ejemplo anterior, se pueden identificar las siguientes unidades
conceptuales: "cdigo de barras" y "monto total" (Fig. 6). A la palabra o conjunto de palabras con contenido
semntico en el dominio que se est modelando se denominar, en adelante, trmino significativo.
Utilizando UML, en la Figura 8 se muestra la composicin bsica de un trmino significativo [32].

Siguiendo la lnea del estructuralismo lingstico de Saussure, las palabras son consideradas signos
lingsticos y un trmino significativo queda definido entonces por su significado y su significante [41]. El
significado es la descripcin textual de la idea y expresa tanto la esencia del ser del concepto (denotacin)
como su utilidad (connotacin)3. En esta descripcin textual tambin se reconocen los trminos
1
Una clase es un conjunto de palabras que pueden sustituirse unas por otras en una misma oracin sin que se pierda su sentido. Cada
palabra pertenece a una clase. En espaol, generalmente se admiten ocho clases de palabras [29]: sustantivos, verbos, adjetivos,
adverbios, determinantes, preposiciones, pronombres y conjunciones. Las primeras cuatro clases de palabras se dice que son abiertas
porque frecuentemente se incorporan nuevas palabras a estos grupos. Por el contrario, las clases restantes se consideran cerradas
porque raramente son enriquecidas con nuevas palabras.
2
Se excluyen de este conjunto las palabras reservadas para describir oraciones especiales en un caso de uso.
3
Para describir los trminos del Language Extended Lexicon (LEL) se hace uso del significante ("symbol"), la denotacin ("notion") y la
connotacin ("behavioral response") [24]. La notion especifica qu es el symbol. Por otra parte, la denotacin de un trmino del LEL
describe la actuacin del symbol en el dominio, como escenarios de accin del mismo. No obstante, en la aproximacin lingstica
propuesta para OO-Method, la denotacin no pretende tal objetivo pues slo se refiere a la particular acepcin del significado en el
dominio (si es que la tiene alguna).
significativos1. Por otra parte, la materializacin de la idea se conoce como significante. Con el fin de evitar
ambigedades e inconsistencias, un trmino tendr un nico significado2.
El significado podr estar vinculado a ms

Equivalentes
de un significante uno de los cuales se escoge
como representante y, el resto, se consideran 0..
*
1
como significantes equivalentes a ste3. Por Denotacin 1
1
1 1
Significado Significante Representante
otra parte, un trmino significativo puede ser
simple (cuando est formado por una nica Connotacin
1
0..
* 1 1
palabra de clase abierta) o compuesto (si es 1
una unidad conceptual conformada por ms Jerga

0..
* Trmino Rol
Significativo 0.. Semntico
de una palabra abierta y/o cerrada). Adems, 1 0..
* * 1..
*
1 {disjoint}
el conjunto de todos los trminos 1
significativos constituye una jerga pues su Lengua Simple Compuesto
uso es propio de un dominio particular. Esta 0..
* 0..
*
jerga se contextualiza en determinada lengua 0..
* 0..
* {ordered}
o idioma. Por ltimo, un trmino

2..
* *
0..
Abierta Cerrada
significativo puede desempear uno o ms 1
roles semnticos en un caso de uso (se

explica en la prxima seccin). Fig. 8. Descripcin de un Trmino Significativo
Bsicamente, la Normalizacin Semntica consiste en la identificacin de los trminos significativos del

caso de uso para luego dotarlos de informacin que garantice su correcta utilizacin y facilite el
reconocimiento de los elementos del Modelo de Diagramas de Secuencia. Las actividades previstas en esta
fase se describen brevemente a continuacin (Fig. 9).
NORMALIZACIN
SEMNTICA
/
\
Lematizacin Analista
No Existe
NORMALIZACIN Identificacin Verificacin de Actualizacin

Existe
del Significante Existencia de la Ontologa

SINTCTICA de Trminos
Significativos CATEGORIZACIN
Notacin: Fase ; Actividad ; Transicin ; Dependencia
Fig. 9. Actividades de la Normalizacin Semntica
Identificacin del significante: el reconocimiento de los trminos significativos de un caso de uso y, en

particular, de sus significantes se realiza utilizando patrones sintcticos predefinidos. Un patrn sintctico es
una secuencia de sintagmas y/o categoras sintcticas utilizado para el reconocimiento de determinadas
estructuras gramaticales de la oracin de un caso de uso [40]. Cada patrn sintctico incluye tambin una
regla que establece cmo obtener el significante del trmino significativo a partir de esta estructura (Fig. 10).
Por otra parte, la forma cannica del significante del trmino significativo se obtiene a travs de la actividad
de lematizacin.
1
Se trata con esto de garantizar el principio de circularidad (maximizacin del uso de trminos significativos en la descripcin de otros)
y el principio de mnimo vocabulario (minimizacin del uso de palabras que carezcan de contenido informativo del dominio) [24]. La
circularidad de los trminos significativos puede alcanzar distintos niveles. El nivel ms bajo es aquel en el que la descripcin del
significado est compuesto por trminos significativos previamente identificados y/o clases cerradas de palabras.
2
Esta restriccin tiene como finalidad impedir la polisemia. De esta forma, un trmino significativo slo tendr asociado un nico
significado.
3
Entre el representante de un trmino significativo y sus equivalentes quedan establecidas relaciones de sinonimia.
Lematizacin: permite asignar al significante una

NOMBRE Sintagma Nominal Especificativo
representacin nica, utilizando para esto el lema DESCRIPCIN Identifica trminos significativos compuestos a partir
del significante. Dos trminos significativos son de sintagmas nominales especificativos.
ESTRUCTURA SN: [Det] [Adj] Sust [Adj] , donde
iguales si y slo si tienen el mismo lema. Por GENRICA Det: Determinante ; Sust: Sustantivo ; Adj: Adjetivo
ejemplo, las palabras "introduce" e "introducido" REGLA A , B: SN(Det: _ ; Adj1: _ ; Sust: A ; Adj2: B)
tienen el mismo lema ("introducir") por lo que se GENERATE(COMPUESTO(C1: A ; CERRADA: _ ; C2: B))
considerar un nico trmino significativo cuyo Sintagma Nominal Especificativo

significante ser representado por dicho lema. El El Cajero introduce la cantidad vendida del artculo
significante de los equivalentes de un trmino Trmino Significativo Compuesto
significativo tambin se representan a travs de su
lema. Fig. 10. Un Patrn Sintctico
Verificacin de existencia: una vez identificado un trmino significativo, se determina si ste ha sido
reconocido con anterioridad. Esto implica verificar si su significante se ha identificado previamente como
representante o equivalente. En caso afirmativo, se comprueba adems si el significado asociado al
significante concuerda con el que se desea dar en la oracin del caso de uso (esto con el objeto de evitar
homnimos o conflictos de significado). En caso negativo, se actualiza la Ontologa de Trminos
Significativos.
Actualizacin de la Ontologa de Trminos Significativos: consiste en la modificacin del cuerpo de
trminos significativos reconocidos. Este cuerpo constituye una ontologa pues define el vocabulario comn
que permite compartir informacin de los trminos significativos del dominio [3, 5, 12, 42, 43, 44]. Esta
ontologa describe el cuerpo de trminos significativos desde las perspectivas: (i) conceptual, que muestra
los componentes que definen cada trmino (Fig. 8) (ii) estructural, que especifica las relaciones semnticas
establecidas entre los trminos: equivalencia (sinonimia), anttesis (antonimia), generalizacin
(hiperonimia), especializacin (hiponimia), composicin (meronimia), es_parte_de (holonimia),
es_propiedad_de y agente [13].
EMISOR Locutor o remitente

CATEGORIZACIN RECEPTOR Interlocutor o destinatario
ACCIN Informa sobre lo que realiza el emisor
TITULAR Al que se aplica la accin ejecutada por el emisor
TERCERO Recibe de forma indirecta los efectos de una accin
FUENTE Contiene informacin imprescindible para la accin
COOPERADOR
NORMALIZACIN Identificacin de Clasificacin TRANSMUTACIN
Coopera con la accin
SEMNTICA Roles Semnticos de Sentencias
El Cajero introduce la cantidad vendida del artculo
Emisor Accin Titular Fuente

Fig. 12. Roles Semnticos
Fig. 11. Actividades de la Categorizacin
6. Categorizacin
En esta fase los trminos significativos y las oraciones de un caso de uso se clasifican segn el rol que
cumplen en el Modelo de Casos de Uso (Fig. 11). Las actividades de esta fase se resumen a continuacin:
Identificacin de roles semnticos: consiste en la determinacin del rol semntico que cada trmino
significativo cumple en el contexto de una oracin del caso de uso. Un rol semntico define el papel que
cumple el significante en la oracin segn el modelo de comunicacin que sirve de base al Modelo de Casos
de Uso. La Figura 12 muestra los principales roles semnticos establecidos. Un trmino significativo puede
tener ms de un rol semntico en el contexto de uno o ms casos de uso. La identificacin de los roles
semnticos de un trmino significativo se realiza utilizando patrones sintcticos. De esta forma, cada rol
semntico sirve de intermediario entre los patrones sintcticos y las abstracciones del caso de uso,
independizndolas de la forma cmo se expresan en lenguaje natural [8, 39, 40]. Una de las ventajas que
esto tiene es que es posible vincular a cada rol semntico, patrones sintcticos equivalentes en distintos
idiomas. Adems, en el mbito de un idioma en particular, se pueden considerar variaciones de estos
patrones que tomen en cuenta estilos lingsticos especficos de una comunidad.
Clasificacin de sentencias: utilizando la gramtica predefinida para el caso de uso y los roles semnticos
establecidos, cada una de las oraciones del caso de uso es clasificada segn su tipo: de interfaz actor-sistema,
de interfaz sistema-actor y de proceso1.
TRANSMUTACIN
Vinculacin con Actualizacin de la

la Ontologa de Ontologa de los
Trminos Diagramas de
Significativos Secuencia
Existe
No
Existe Completo
Incompleto
ID de Elementos Determinacin de Construccin MODELADO
CATEGORIZACIN del Diagrama de
de Modelado Existencia
Secuencia CONCEPTUAL
Actualizacin del
/
\
Diagrama de Analista
Secuencia
Fig. 13. Actividades de la Fase de Transmutacin
7. Transmutacin
Despus que el caso de uso ha sido normalizado sintctica y semnticamente, habindose identificado y
clasificado sus trminos significativos y oraciones, se construyen los diagramas de secuencia que le
correspondan (uno por cada trayectoria posible). El propsito principal de esta fase es traducir la
especificacin textual del caso de uso en representaciones de este tipo. La unidad bsica de construccin de
un diagrama de secuencia es el patrn de interaccin. Est formado por tres tipos de elementos: actor, sistema
e instancia. El elemento "actor" se corresponde con los actores que participan en el caso de uso. El elemento
"sistema" representa la frontera entre el sistema y su ambiente. Este tipo de elemento se encarga de controlar
la entrada y salida de informacin al sistema as como tambin de coordinar las acciones internas que se
deben realizar para el procesamiento de la misma. Por ltimo, una "instancia" representa un objeto de una
clase. La descripcin de un escenario de un caso de uso consistir en la combinacin conveniente de los
patrones de interaccin. A continuacin se describen las actividades de la fase de Transmutacin (Fig. 13):
Identificacin de Elementos de Modelado: reconoce los elementos que intervienen en un patrn de
interaccin (instancias, mensajes y, eventualmente, argumentos). Para esto se utiliza la informacin relativa
al rol semntico de cada trmino significativo y se aplican ciertas heursticas. Por ejemplo, el anlisis de la
oracin que se muestra en la Figura 12, permite deducir que: "Cajero" y "Artculo" son instancias, "cantidad
vendida" es un argumento (vinculado a "artculo") y que "introduce la cantidad vendida" es un mensaje.
Construccin del Diagrama de Secuencia: consiste en la identificacin del patrn de interaccin que
corresponde a cada oracin del caso de uso. A partir de las oraciones simples de interfaz y con los elementos
de modelado previamente identificados, es posible reconocer dos tipos de patrones: actor-sistema y sistema-
actor. De las oraciones simples de proceso se obtienen los patrones: sistema-instancia e instancia-sistema.
Por ltimo, estos patrones son organizados en el orden establecido por la secuencia de las oraciones del caso
de uso hasta conformar totalmente el diagrama de secuencia. La Figura 14 muestra uno de los diagramas de
secuencia del caso de uso Venta de Artculo que se presenta en la Figura 6.
Actualizacin de la Ontologa de Diagramas de Secuencia: los elementos de modelado identificados son
organizados en una ontologa. Estos conceptos estn vinculados estrechamente con los definidos en la
Ontologa de Trminos Significativos. Esto se debe a que un trmino significativo es un potencial elemento
de modelado de un diagrama de secuencia. Dado que, los diagramas de secuencia pueden ser posteriormente
modificados por razones diversas (refinamientos, optimizaciones, etc.), la trazabilidad entre ambas
1
Las oraciones de interfaz actor-sistema se caracterizan porque el emisor de la comunicacin es el actor. En las oraciones de interfaz
sistema-actor se observa que el emisor de la comunicacin es el sistema y el receptor es el actor. El emisor y el receptor de la
comunicacin en las oraciones de proceso es el sistema [14, 38].
ontologas no es necesariamente uno a uno. No obstante, se asegura que esta trazabilidad exista: todo
trmino significativo en la Ontologa de Trminos Significativos se corresponde con, al menos, un elemento
de modelado en la Ontologa de Diagramas de Secuencia y viceversa [7, 45].
Determinacin de Existencia: un mismo
elemento de modelado puede ser
identificado en varias oraciones de un caso Cajero
Sistema Venta Artculo
de uso y/o en distintos casos de uso. Esta Inicia la sesin de una venta
Paso 0 Paso 1
actividad garantiza que sea definido una Solicita el cdigo de barras y Activa una nueva sesin
sola vez en la Ontologa de Diagramas de Paso 2

la cantidad vendida del artculo
Secuencia. [UnArtculo]*
Actualizacin de la Ontologa de Paso 3 Introduce el cdigo de

barras y la cantidad vendida
Paso 4
Diagramas de Secuencia: consiste en la del artculo
Obtiene la descripcin y el
precio por unidad (CodBar)
modificacin del cuerpo de elementos de
Paso 5
modelado que han sido identificados Calcula el monto
(PrecUnidad,CantVen)
(incluye la incorporacin de nuevos Paso 6
elementos). Calcula el subtotal

(Monto)
Muestra el subtotal
Vinculacin con la Ontologa de Paso 7
de la venta
Paso 8
Trminos Significativos: se establecen Registra (Desc, CantVen,
PrecUni,Monto)
Paso 8.1
Actualiza la cantidad en
vnculos de trazabilidad entre los trminos Solicita el cdigo de barras y

existencia (CodBar,CantVen)
significativos y los elementos de modelado Paso 9

la cantidad vendida del artculo
de los diagramas de secuencia. Paso 10

Finaliza la sesin de
Paso 11
la venta
Actualizacin del Diagrama de Muestra el monto

Calcula el monto total
Secuencia: una vez que la versin Paso 12 total de la venta Paso 13

Registra (MontTot,Fech)
Imprime el comprobante
preliminar de un diagrama de secuencia ha Paso 14 de la venta
sido generada automticamente, el Analista

puede efectuar las modificaciones que
considere convenientes. Esta actividad
permite registrar estos cambios. Fig. 14. Construccin de un Diagrama de Secuencia
8. Presente y Futuro de la Investigacin

Hasta ahora, el proceso de traduccin propuesto se ha aplicado a nivel de laboratorio acadmico. Para esto
se han diseado ms de cuarenta patrones sintcticos. En la validacin se han utilizado casos de uso de tres
fuentes distintas: (i) ejemplos prcticos diseados en el mbito universitario, (ii) casos de uso que se
encuentran en la bibliografa [9, 10, 19, 20, 23] (iii) casos de uso escritos en algunas empresas para el
desarrollo de sus sistemas de software y que han sido suministrados por stas para realizar el estudio que nos
ocupa. El trabajo se ha realizado a mano, con el apoyo de herramientas especializadas tanto en el
procesamiento de lenguaje natural como en la edicin de diagramas de secuencia. Actualmente, se ha iniciado
la construccin de un prototipo que pretende integrar estas herramientas con el fin de facilitar la tarea de
traduccin de los casos de uso. Una vez construido el prototipo se realizarn las experimentaciones necesarias
para determinar el alcance de la propuesta, sus virtudes y defectos con el fin de realizar las modificaciones y
adecuaciones necesarias.
9. Conclusiones
En este trabajo se ha descrito la aproximacin lingstica utilizada para el establecimiento de un nuevo
punto de traduccin en OO-Method. El propsito de esta traduccin es generar de forma semiautomtica una
versin preliminar del Modelo de Diagramas de Secuencia a partir del texto de un caso de uso. Est basada en
un proceso que se desarrolla en cuatro fases sucesivas. Las tres primeras permiten obtener informacin
morfosintctica y semntica del caso de uso para lo cual se utilizan tcnicas de procesamiento del lenguaje
natural. La cuarta fase utiliza esta informacin para transmutar cada oracin de un caso de uso en un patrn de
interaccin de instancias. En este proceso cumple un papel importante la gramtica preestablecida del texto
del caso de uso as como tambin los patrones sintcticos, a travs de los cuales es posible reconocer
estructuras gramaticales y deducir conocimiento til en las distintas fases del proceso.
La aproximacin lingstica define una estrategia para la construccin de dos ontologas, con distintos
niveles de abstraccin. La Ontologa de los Trminos Significativos es una conceptualizacin de los vocablos
que contienen informacin del dominio. La Ontologa de los Diagramas de Secuencia, por su parte, define y
relaciona los elementos utilizados para construir estos diagramas. La trazabilidad entre estas representaciones
y los casos de uso queda garantizada por los vnculos que la aproximacin establece entre ambas ontologas.
Esta correspondencia es dependiente de la estructura de los modelos, sin dejar esta decisin en manos del
Analista.
La utilizacin de roles semnticos para la identificacin de las abstracciones de los modelos permite
independizarlas de la gramtica elegida y de los patrones sintcticos. De esta forma, los cambios en las
estructuras gramaticales, no afectan los vnculos establecidos entre los trminos significativos de los casos de
uso y los elementos de modelado de los diagramas de secuencia.
10. Referencias
[1] ALARCOS E. Gramtica de la Lengua Espaola. Real Academia Espaola. Coleccin Nebrija y Bello. Editorial Espasa
Calpe. Madrid, Espaa. Octubre, 2000.
[2] ALLEN J. Natural Language Understanding. 2nd. Edit. Benjamn Cummings series in Computer Science, 1995.
[3] AUSSENAC-GUILLES N., BIBOW B., SZULMAN S. Revisiting Ontology Design: a Method based on Corpus Analysis.
Proceedings of the 12th European Workshop on Knowledge Acquisition, Modeling and Management (EKAW'00).Pp. 172-188.
Springer-Verlag. October 2000.
[4] BOYD N. Using Natural Language in Software Development. Journal of Object Oriented Programming-Report on Object
Analysis and Design. February 1999.
[5] BREITMAN K.K., LEITE J.C.S.P. Lexicon based Ontology Construction. Proceedings of the 2nd International Workshop on
Software Engineering for Large Scale Multi Agent Systems (SELMA'03). ACM Computer Press. Portland, Oregon. 2003.
[6] BURG J.F.M., VAN DE RIET R.P. Analyzing Informal Requirements Specifications: A First Step towards Conceptual
Modeling. In Proceedings of the 2nd International Workshop on Applications of Natural Language to Information Systems
(NLDB'96). Amsterdam (The Netherlands).
[7] CERBAH F., EUZENAT J. Traceability between Models and Texts through Terminology. Data&Knowledge Engineering
38 (2001), 31-43. Elsevier Science B.V.
[8] CHOMSKY, N. Deep Structure, Surface Structure and Semantic Interpretation. Steinberg&Jakobovits, Pp. 183-216, 1971.
[9] COCKBURN A. Writing Effective Use Cases. Addison-Wesley. 2001.
[10] CONSTANTINE L., LOCKWOOD L. Software for Use: A Practical Guide to the Models and Methods of Usage-Centred
Design. Addison-Wesley, Boston 1999.
[11] CONSTANTINE L., LOCKWOOD L. Structure and Style in Use Cases for User Interface Design. In Object Modeling and
User Interface Design: Designing Interactive System by M. V. Harmelen (editor) and S. Wilson. Addison-Wesley, 2001.
[12] CORCHO O., FERNNDEZ-LPEZ M., GMEZ-PREZ A. Methodologies, Tools and Languages for Building
Ontologies. Where is their Meeting Point?. Data&Knowledge Engineering 46 (2003), 41-64. Elsevier Science B.V.
[13] DEHNE F., STEUTEN A., VAN DE RIET R.P. WordNet++: A Lexicon for de Color-X-Method. Data&Knowledge
Engineering 38 (2001), 3-29. Elsevier Science B.V.
[14] DAZ I., LOSAVIO F., MATTEO A., PASTOR O. A Specification Pattern for Use Cases. Por aparecer en
Information&Management. Elsevier Science B.V.
[15] DAZ I., MORENO L., PASTOR O. Traduccin de Casos de Uso en Patrones de Interaccin de Instancias: una
Aproximacin Lingstica. Memorias de las 3eras. Jornadas Iberoamericanas de Ingeniera de Software e Ingeniera del
Conocimiento. Valdivia, Chile. Noviembre, 2003.
[16] FEIJS L.M.G. Natural Language and Message Sequence Chart Representation of Use Cases. Information and Software
Technology 42(2000). Pp. 633-647.
[17] INSFRN E. A Requirements Engineering Approach for Object-Oriented Conceptual Modeling. Tesis de Doctorado en
Informtica. DSIC. Universidad Politcnica de Valencia. Espaa, 2003.
[18] INSFRN E., PASTOR O., WIERINGA R. Requirements Engineering-Based Conceptual Modeling. Requirements
Engineering, 7(2), 61-72. Springer-Verlag. March 2002.
[19] JACOBSON I., BOOCH G., RUMBAUGH J. The Unified Software Development Process. AddisonWesl, 1999.
[20] JACOBSON I., CHRISTERSON M., JONSSON P., VERGAARD G. Object-Oriented Software Engineering. A Use Case
Driven Approach. Addison-Wesley, 1992.
[21] JARKE M., BUI T., CARROLL J. Scenario Management: an Interdisciplinary Approach. Requirements Engineering 3(4),
1998. Pp. 155-173.
[22] JURISTO N., MORENO A., LPEZ M. How to Use Linguistic Instruments for Object-Oriented Analysis. IEEE Software
Vol. 17 Issue 3. May/June 2000. Pp. 80-89.
[23] LARMAN C. Applying UML and Patterns. Prentice Hall. Upper Saddle River NJ, 1998.
[24] LEITE J.C.S.P., HADAD G., DOORN J., KAPLAN G. Scenario Construction Process. Requirements Engineering 5, 2000.
Springer-Verlag. Pp. 38-61.
[25] LI L. A Semi-Automatic Approach to Translating Use Cases to Sequence Diagrams. Technology of Object-Oriented
Languages and Systems. June 07-10, 1999. Nancy, France.
[26] LI L. Translating Use Cases to Sequence Diagrams. In Proceeding of the Fifteenth IEEE International Conference on
Automated Software Engineering (ASE00).
[27] MTAIS E. Enhancing Information Systems Management with Natural Language Processing Techniques.
Data&Knowledge Engineering 41 (2002), 247-272. Elsevier Science B.V.
[28] MOLINA P. User Interface Specification: from Requirements to Code Generation. Tesis de Doctorado en Informtica.
DSIC. Universidad Politcnica de Valencia. Espaa, 2003.
[29] MORENO A. Entienda la Gramtica Moderna. Ediciones Larousse. Mxico, 1985.
[30] MORENO L., PALOMAR M., MOLINA A., FERNNDEZ A. Introduccin al Procesamiento del Lenguaje Natural.
Universidad de Alicante, Espaa. 1999
[31] OBJECT MANAGEMENT GROUP. Software Process Engineering Metamodel Specification. Version 1.0. November
2002. http://www.omg.org/uml.
[32] OBJECT MANAGEMENT GROUP. Unified Modeling Language Specification. Version 1.5. March 2003.
http://www.omg.org/uml.
[33] OVERMYER S., LAVOIE B., RAMBOW O. Conceptual Modeling through Linguistic Analysis using LIDA. IEEE
Proceedings of the Conference on Software Engineering (ICSE01). Pp. 401-410. Toronto, Canad.
[34] PASTOR O. Diseo y Desarrollo de un Entorno de Produccin Automtica de Software basado en el Modelo Orientado a
Objetos. Tesis de Doctorado en Informtica. DSIC. Universidad Politcnica de Valencia. Espaa, 1992.
[35] PASTOR O., GMEZ J., INSFRN E., PELECHANO V. The OO-Method Approach for Information Systems Modeling:
from Object-Oriented Conceptual Modeling to Automated Programming. Information Systems 26 (2001), 507-534.
[36] PASTOR O., RAMOS I. OASIS 2.1.1.: A Class-Definition Language to Model Information Systems Using and Object-
Oriented Approach. Departamento de Sistemas Informticos y Computacin. Servicio de Publicaciones de la Universidad
Politcnica de Valencia. Espaa, 1995.
[37] RAYSON P., EMMET L., GARSIDE R., SAWYER P. The REVERTE Project: Experiments with the Application
Probabilistic NLP to Systems Engineering. Proceedings of the 5th International Conference on Applications of Natural
Language to Information Systems (NLDB00). LNCS 1959, Pp. 288-300. Springer-Verlag.
[38] ROLLAND C., BEN-ACHOUR C., CAUVET C., RALYT J., SUTCLIFFE A., MAIDEN M., JARKE M., HAUMER P.,
POHL K., DUBOIS E., HEYMANS P. A Proposal for a Scenario Classification Framework. Requirements Engineering
3(1), 1998. Pp. 23-47.
[39] ROLLAND C., BEN-ACHOUR C. Guiding the Construction of Textual Use Case Specifications. Data&Knowledge
Engineering 25 (1998), 125-160. Elsevier Science B.V.
[40] ROLLAND C., PROIX C. A Natural Language Approach for Requirements Engineering. Proceedings of the 4th
International Conference on Advanced Information Systems Engineering (CAiSE'92). LNCS 593, Pp. 257-277. Springer-
Verlag. U.K. 1992.
[41] SAUSSURE F. Curso de Lingstica General. Publicaciones Akal. Madrid 1989.
[42] SPYNS P., MEERSMAN R., MUSTAFA J. Data Modelling versus Ontology Engineering. ACM SIGMOD Record 31(4),
Pp. 12-17. December 2002. Special Issue on Semantic Web and Data Management.
[43] USCHOLD M., JASPER R. A Framework for Understanding and Classifying Ontology Applications. Proceedings of the
16th International Joint Conference On Artificial Intelligence (IJCAI'99). Workshop on Ontologies and Problem-Solving
Methods (KRR5). Stockholm, Sweden. August 1999.
[44] VELARDI P., FABRIANI P., MISSIKOFF M. Using Text Processing Techniques to Automatically enrich a Domain
Ontology. Proceedings of the International Conference on Formal Ontology in Information Systems (FOIS'01). Volume 2001.
Pp. 270-284. October 17-19, 2001. Ogunquit-Maine, USA. ACM Computer Press.
[45] ZISMAN A., SPADOUDAKIS G., PREZ-MIANA E., KRAUSE P. Tracing Software Requirements Artefacts.
Proceedings of the 2003 International Conference on Software Engineering Research and Practice (SERP03). June 23-26,
2003. USA.
ArcADe: Um Modelo de Processo para Anlise e Projeto Baseado em

Arquitetura de Software
Marco Antnio Fagundes de Moraes Alexandre Marcos Lins de Vasconcelos

Secretaria de Informtica do Tribunal Regional Centro de Informtica da Universidade Federal
Eleitoral do Par - TRE/Pa de Pernambuco CIn/UFPE
mfagunde@tre-pa.gov.br amlv@cin.ufpe.br
Resumo
Reuso de software tem recebido uma crescente ateno como alternativa para o aumento de produtividade
e reduo do custo de desenvolvimento nas organizaes produtoras de software. Nesse contexto, a
arquitetura de Software (AS) merece ser destacada, pois permite reuso em nveis mais abstratos. Entretanto,
o tratamento explcito de AS no tem sido o foco dos processos de software largamente utilizados, devido a
algumas razes: terminologia especfica (componentes, conectores e configurao); AS uma disciplina
emergente; pouco suporte de ferramentas disponveis. Neste artigo, apresentamos o processo ArcADe
(Software Architecture-based Analisys and Design) que integra conceitos e padres largamente difundidos
com a AS. Este processo teve uma influncia do RUP (Rational Unified Process) e trata da relao entre os
requisitos e as abstraes arquiteturais, elaborao, representao e concretizao da arquitetura.
1. Introduo.
O reuso de software [9] tem recebido uma crescente ateno como uma alternativa para as organizaes
reduzirem tempo e custos envolvidos no processo de construo de software. Nesse contexto, diversas
abordagens que tratam do reuso tm sido definidas (e.g., Arquitetura de Software - AS [16], Middleware [4],
Padres de Projeto [6], Desenvolvimento Baseado em Componentes [1], etc.). Dentre essas abordagens a AS
merece destaque, pois permite reuso em nveis bem abstratos, ao mesmo tempo, que fornece um potencial
para a aplicao das demais abordagens. Por exemplo, considerando que a AS fornece uma descrio do
software em termos de componentes, conectores e configurao, podem-se utilizar Padres de Projeto e
Middleware na concretizao de componentes e conectores respectivamente.
Processos de software largamente utilizados (e.g., Rational Unified Software Process RUP [10]) no
favorecem o projeto arquitetural segundo a disciplina de AS [16], pois tratam da arquitetura seguindo uma
abordagem particular. Ou seja, no existe uma integrao natural entre a disciplina de AS e os processos
amplamente utilizados. Essa ausncia de integrao pode ser entendida por algumas razes: AS uma
disciplina recente; AS no apoiada pela maioria das ferramentas disponveis; AS enfatiza o projeto da
computao e da comunicao, e no somente da computao como geralmente acontece; AS descrita
atravs de componentes, conectores e configurao, e no apenas atravs de diagrama de classes como
geralmente feito em vrios projetos orientados a objetos.
Para tratar do problema da ausncia de integrao da AS com processos largamente utilizados, algumas
abordagens tm sido propostas, como por exemplo: utilizar UML (Unified Modeling Language) como ADL
(Arquitecture Description Language) [7], Catalysis [3] e MDA (Model-Driven Architecture) [11]. A primeira
abordagem trata da representao da arquitetura atravs de UML, em substituio s ADLs tradicionais que,
em sua maioria, apresentam um certo rigor formal e sintaxes complexas. O processo Catalysis envolve todo o
ciclo de desenvolvimento, trata explicitamente de componentes e conectores, e utiliza a UML para construo
de seus modelos. O MDA utiliza UML e enfatiza a construo de modelos independentes de plataforma e
tecnologia de implementao, com posterior transformao desses modelos em arquiteturas de software
especficas para determinadas plataformas.
Considerando as abordagens mencionadas acima, dois pontos devem ser levados em considerao.
Primeiro, as abordagens que utilizam UML para descrever a no envolvem todos os aspectos de projeto da
arquitetura (e.g., Desenvolver ou Selecionar uma Arquitetura), pois tratam somente da atividade de
representao da arquitetura (ver Subseo 2.2.2 as atividades do desenvolvimento baseado em arquitetura).
Segundo, Catalysis e MDA no so, por enquanto, amplamente difundidos em ambientes comerciais de
desenvolvimento de software.
Com base no contexto descrito, selecionamos um processo de software largamente utilizado, no caso o
RUP, e propomos um modelo de processo1 para anlise e projeto que integra os elementos do RUP (conceitos,
caractersticas e padres) com a AS. Esse modelo, chamado ArcADe [13] (software Architecture-based
Analisys and Design), adota os conceitos e princpios da AS como base, e utiliza os elementos do RUP para
organizar e representar o seu fluxo de trabalho. Devido ao nosso modelo adotar padres largamente utilizados
(e.g., UML), acreditamos que sua aceitao ser facilitada.
Alm desta seo introdutria, este artigo est organizado da seguinte forma: a Seo 2 introduz os
conceitos bsicos da nossa proposta. A Seo 3 apresenta a estrutura do ArcADe. A Seo 4 apresenta um
estudo de caso, onde o modelo aplicado no projeto de um sistema de software. Finalmente, a Seo 5
apresenta uma anlise do modelo, concluses e algumas direes para trabalhos futuros.
2. Escopo e Definies.
Os conceitos e princpios bsicos de AS tm um papel importante no modelo proposto. Elementos
arquiteturais, tais como, componentes, conectores e configuraes descrevem a arquitetura do software no
ArcADe. As subsees seguintes apresentam o escopo e os conceitos bsicos usados em nossa proposta.
2.1. Escopo e Uso do Modelo
O modelo proposto aplicvel a qualquer organizao de desenvolvimento de software, que deseje

alcanar nveis bem abstratos de reuso e melhorar suas capacidades de desenvolvimento, evoluo, operao e
suporte do software. O ArcADe no presume estrutura organizacional particular ou filosofias de
gerenciamento. Por outro lado, ele considera um modelo de desenvolvimento iterativo e incremental,
organizando as atividades de anlise e projeto, de modo a auxiliar os profissionais envolvidos no
entendimento e utilizao da disciplina de AS durante o desenvolvimento de software. Em relao ao uso do
modelo destacamos os aspectos listados na Tabela 1, apresentada a seguir.
Tabela 1 Uso do modelo

Quem? Analistas, Projetistas e Arquitetos de Software
Por que? Para se obter os benefcios inerentes a AS (e.g., clara estruturao do software, reuso em nveis
bem abstratos, facilidade do gerenciamento da complexidade pela decomposio do problema).
Como? Considerando um cenrio de utilizao (ver Seo 4), seguindo o fluxo de trabalho definido no
modelo e executando suas atividades conforme seus guias passo-a-passo.
Quando? Durante o mapeamento dos requisitos para a arquitetura, em conjunto com a realizao das
abstraes arquiteturais para obteno de um projeto detalhado a ser submetido
implementao.
O ArcADe pode ser utilizado em projetos de software grandes e complexos (e.g., sistemas com diferentes
plataformas, comunicao com legados, mltiplas linguagens de programao). Podendo tambm ser
adaptvel a projetos de tamanho e complexidade reduzidos. Adicionalmente, o modelo possibilita sua
integrao em um processo j existente na organizao, desde que os artefatos (o conceito de artefato
apresentado na Subseo 2.2.3) de entrada e sada do modelo sejam contemplados pelo processo considerado.
1
Segundo a ISO 15504 [8] Modelo define os objetivos em alto nvel de abstrao; Processo a definio operacional de um conjunto de
atividades para alcanar um propsito especfico
2.2. Termos e definies
Nesta subseo, apresentamos os conceitos bsicos de AS, o desenvolvimento baseado em arquitetura, uma
viso geral do RUP e analisamos como esse processo trata da arquitetura.
2.2.1. Arquitetura de software. Existem diversas definies de AS (e.g.[2,15]), dentre as quais a de Shaw &
Garlan [16] a mais tradicionalmente adotada pela comunidade da rea de AS. Essa definio foi utilizada
como base do modelo proposto e considera que AS fornece a descrio mais abstrata do software, envolvendo
sua estrutura, comportamento e propriedades chave (e.g., portabilidade). Em um processo de software, a AS
desempenha um papel importante como ponte entre os requisitos e a implementao (ver Figura 1.a).
Arquiteturas de software so geralmente descritas em termos de trs abstraes bsicas: componentes,

conectores e configurao. Componentes modelam os elementos que realizam processamento ou armazenam
informaes (e.g., clientes e servidores), comunicando-se com o ambiente externo atravs de uma interface
(conjunto de portas). Conectores modelam as interaes e as regras de comunicao entre os componentes.
Configurao representa a interligao de componentes e conectores em uma topologia especfica. A Figura
1.b apresenta uma viso geral da AS.
Configurao Componentes
Componente_A
Requisitos
Componente_B
Componente_C
Componente_A Componente_B Componente_C Conectores

Arquitetura de Conector_1
interface interface interface Conector_2
Software
Configurato
Componente_A
interface interface Conector_1
Conector_1 Conector _2 Componente_B
RMI Java
Conector_2
Implementao Componente_C
Delphi CORBA
(a) (b)
Figura 1 (a) AS como ponte entre requisitos e implementao (b) Viso geral da AS
Essencialmente, a AS apresenta uma descrio do software onde a computao (includa em

componentes) e a comunicao (embutida na noo de conectores) so claramente separadas [15]. Essa
separao reduz o acoplamento entre as partes de um sistema, aumentando as oportunidades de reuso de
componentes e conectores em outros contextos.
2.2.2. Desenvolvimento Baseado em Arquitetura (DBA). A adoo dos princpios da AS no

desenvolvimento de software implica na realizao de cinco atividades principais, como proposto por Bass et
al. [2]:
1. Entender o domnio dos requisitos - recomenda-se efetuar uma anlise do domnio, na qual
similaridades e variaes so antecipadas, enumeradas e registradas.
2. Desenvolver ou selecionar a arquitetura - aps a anlise dos requisitos, um estilo arquitetural particular
pode ser adotado (seleo) ou a arquitetura do software definida a partir do zero (desenvolvimento).
3. Representar a arquitetura - nessa atividade utiliza-se uma notao que precisamente descreva a
arquitetura do software. Essa notao pode ter uma base formal que permita simular, verificar as
propriedades ou ainda construir um prottipo do software.
4. Analisar ou avaliar a arquitetura - de posse da representao da arquitetura, possvel verificar se a
mesma exibe as propriedades desejadas (e.g., reusabilidade).
5. Implementar o sistema baseado na arquitetura - o ltimo passo para a realizao da arquitetura do
software em elementos concretos de implementao (nvel de cdigo).
2.2.3. Rational Unified Process (RUP). O RUP [10] um processo genrico para desenvolvimento de
software desenvolvido pela Rational Software Corporation, cujas principais caractersticas so: orientado a
objetos (utilizando UML para construo de seus modelos), dirigido por casos de uso, centrado na arquitetura
(o RUP segue uma viso particular de arquitetura ver Subseo 2.3) e desenvolvimento iterativo e
incremental.
Esse processo possui cinco conceitos bsicos: responsvel, artefato, atividade, fluxo e subfluxo.
Responsvel um papel que pode ser atribudo a uma pessoa ou grupo. Artefato uma informao produzida,
modificada ou usada. Atividade uma unidade de trabalho que pode ser executada por um responsvel. Fluxo
uma seqncia de atividades que so agrupadas em etapas do desenvolvimento (e.g., fluxo de requisitos).
Subfluxo usado para estruturar um fluxo em termos de atividades, responsveis, artefatos de entrada e sada.
O RUP fornece modelos para cada artefato e guias (prticas e tcnicas) para executar as atividades. A
seguir, analisamos como o RUP trata da arquitetura em relao definio de AS (ver Subseo 2.2.1).
2.3. Anlise do tratamento da arquitetura no RUP.
Para analisar como o RUP trata da arquitetura, inicialmente efetuamos um paralelo entre os fluxos de
processo do RUP e o DBA (ver Figura 2.a) para identificarmos as semelhanas e diferenas no tratamento da
arquitetura nesses dois processos. Em seguida, analisamos e verificamos o nvel de integrao da AS com o
RUP. Nessa verificao, observamos que o RUP adota o Modelo de Viso 4+1 [10] (ver Figura 2.b) para
tratar a arquitetura.
Desenvolvimento Baseado em Arquitetura Fluxos de Processo do RUP
Viso de
Entender o Domnio Modelagem de Negcio Viso Lgica Implementao
Usurios Finais Programadores
Requisitos Funcionalidade Gerenciamento de
Desenvolver/Selecionar a Arquitetura Viso de
Software
Anlise & Projeto Casos de Uso
Representar a Arquitetura Analista/Testadores
Analisar e Avaliar a Arquitetura Implementao Comportamento
Viso de Processo Viso de Implantao
Teste Integradores de Sistema Engenheiros de Sistema
Performance, Topologia de Sistema,
Escalabilidade Entreda, Instalao,
Implementao Implantao
Comunicao
(a) (b)
Figura 2 (a) Relao entre o DBA e fluxos de processo do RUP (b) O modelo de viso 4+1
Como resultado da anlise do tratamento da arquitetura pelo RUP, verificamos que o mesmo no est em
conformidade com a definio apresentada na subseo 2.2.1, no que diz respeito terminologia usada na AS
(componentes, conectores e configurao) e na pouca nfase reduo do acoplamento. Tal aspecto dificulta
uma adaptao/extenso do RUP para tratar a AS, haja visto que a diferena est no conceito base, no caso
arquitetura. Assim, uma provvel adaptao do RUP acarretaria na redefinio/reorganizao de todas as
atividades envolvidas no tratamento da arquitetura. Entretanto, os benefcios do RUP, tais como, difuso de
uso e suporte de ferramentas no devem ser descartados. Com base nesse contexto, formulamos um modelo
de processo que integra a AS com elementos do RUP, conforme apresentamos na prxima seo.
3. A abordagem ArcADe.
O ArcADe (software Architecture-based Analisys and Design) um modelo de processo para anlise e
projeto que integra a AS com elementos do RUP (conceitos, mtodos e tcnicas). O modelo adota a AS como
base, para definio das etapas do desenvolvimento e utiliza os elementos do RUP, para organizar e
representar o processo em um fluxo de trabalho. Neste ponto, destacamos que o nosso modelo no uma
adaptao/extenso do RUP, mas sim, uma integrao dos elementos desse processo com a AS.
Vale ressaltar que a integrao deve envolver tanto os requisitos funcionais como os no-funcionais
(RNFs). Contudo, em nossa proposta, consideramos somente os requisitos funcionais, pois o RUP dirigido
por casos de uso, os quais so empregados somente na descrio dos requisitos funcionais. A adequao do
ArcADe para tratar os RNFs, pode ser efetuada futuramente usando tcnicas propostas em [15], por exemplo.
3.1. Nveis de abstrao no ArcADe .
O ArcADe segue o modelo de desenvolvimento iterativo e incremental, adotado pelo RUP. Nesse modelo,
a idia bsica compor uma arquitetura abstrata a partir dos requisitos, fornecendo uma descrio de
componentes e suas interaes em um nvel elevado de abstrao (ver Figura 3 Nvel 1. Projeto da
Arquitetura). Essa arquitetura ter um subconjunto das abstraes arquiteturais (ver componente A e conector
1 na Figura 3) mapeadas para uma arquitetura concreta, fornecendo uma representao arquitetural mais
orientada implementao (ver concretizao do componente A e conector 1 na Figura 3 Nvel 2. Projeto
Detalhado).
No nvel de projeto detalhado, as abstraes arquiteturais (componentes e conectores) sero concretizadas

atravs do uso de estratgias de projeto (e.g., orientao a objetos Padres de Projeto) ou da incorporao de
produtos existentes (e.g., Commercial Off-The-Shelf - COTS [1]). Este processo repete-se (iterativamente) at
que a arquitetura global (incremental) tenha sido concretizada em termos de elementos de projeto.
Nvel 1 - Projeto da Arquitetura

Requisitos
A
Nvel 2 - Projeto Detalhado
A classe_1
classe_2
RMI Java
1 ORB
Implementao
Delphi CORBA
Nveis do ArcADe
Figura 3 Nveis de abstrao do ArcADe
Na prxima subseo apresentamos a organizao do nosso modelo conforme os nveis de abstrao

apresentados na Figura 3.
3.2. A organizao do modelo.
O RUP especifica atividades, artefatos e guias para tratar a arquitetura (de acordo com o Modelo de Viso
4+1 - ver Subseo 2.3) no fluxo de Anlise e Projeto. A partir desse fluxo e dos nveis de abstrao
apresentados na subseo 3.1, estruturamos o ArcADe em oito subfluxos (ver Figura 4.b): Selecionar uma
Arquitetura Candidata; Definir a Arquitetura Abstrata; Refinar a Arquitetura e Analisar Comportamento;
Projetar Componentes, Selecionar Componentes, Projetar Conectores e Selecionar Conectores. Neste ponto,
destacamos que componentes e conectores so projetados/selecionados explicita e distintamente, devendo ser
integrados para compor a arquitetura global do sistema. Essa integrao deve acontecer em estgios
posteriores do processo (etapa de implementao do sistema). Contudo, devido ao ArcADe tratar da etapa de
anlise e projeto, o estgio dos requisitos, modelagem de negcio e implementao sero tratados
futuramente, conforme mencionado na seo 5.
Conforme mencionamos no incio da Seo 3, o RUP forneceu elementos para construo do modelo
proposto, um dos quais foi a organizao do trabalho em um fluxo de atividades (ver Figura 4.a). As
atividades apresentadas nos digramas da Figura 4 representam subfluxos (o conceito de subfluxo foi
apresentado na Subseo 2.2.3). Em certos casos, esses subfluxos possuem o mesmo nome, mas importante
salientar que, devido diferena no tratamento da arquitetura (ver Subseo 2.3.), a maioria das atividades
dos subfluxos do ArcADe (Figura 4.b) foram elaboradas a partir de abordagens baseadas em AS, e somente
algumas importadas do RUP, conforme apresentado na prxima subseo.
[Iterao Incial
- Elaborao]
Projeto da
[Usa Estilo] [No Usa Estilo] Arquitetura
[Iterao
Inicial
Elaborao]
Selecionar umaDefinir a Arquitetura
Arquitetura Candidata Abstrata
Definir uma
Arquitetura Candidata Refinar a Analisar
Arquitetura Comportamento
[Iterao [Arquitetura Concreta e

Elaborao] Comportamento Esperado]
Analisar Comportamento
[Componentes [Componentes [Conectores No [Conectores
Existentes] No Existentes] Existentes] Existentes]
[No Tempo [Opcional]
Refinar a
Arquitetura Real] [Tempo Real]
Selecionar Projetar Projetar Selecionar

Componentes Componentes Conectores Conectores
Projetar Projetar Projetar Banco
Componentes Componentes de de Dados
Tempo Real
[Mais componentes para [Mais conectores para
projetar/selecionar para projetar/selecionar para
esta iterao] esta iterao]
Projeto
Detalhado
(a) (b)
Figura 4 (a) Fluxo de anlise e projeto do RUP (b) Modelo ArcADe
Em relao s diferenas na organizao dos dois diagramas, destacamos como aspecto principal a
execuo dos subfluxos Refinar a Arquitetura e Analisar Comportamento (ver destaque da Figura 4). No RUP
essa execuo paralela, mas no ArcADe ela seqencial. Optamos por essa organizao, devido ao
refinamento provocar mudanas estruturais na arquitetura, haja vista que elementos arquiteturais
(componentes e conectores) podem ser decompostos, agregados ou removidos. Por causa dessa mudana
estrutural, deve-se efetuar uma anlise de comportamento para verificar se as propriedades estruturais so
preservadas aps o refinamento. Por exemplo, se dois componentes no se comunicavam na arquitetura
abstrata, eles tambm no devem estar ligados na arquitetura refinada.
3.3. O modelo ArcADe.
O ArcADe fornece uma compilao de diversas abordagens baseadas em AS, tais como, [4,5,7], que so
organizadas em oito subfluxos de trabalho (ver Figura 4.b). Cada subfluxo descrito em termos de atividades
que, em sua maioria, foram elaboradas a partir de abordagens baseadas em AS. As demais atividades, que no
se enquadram nesse contexto, foram importadas do RUP e esto indicadas com (*) na descrio apresentada
nas subsees seguintes.
3.3.1. Subfluxo Selecionar uma arquitetura candidata. Utiliza a abordagem CBSP [5] para relacionar os
elementos do domnio com as abstraes arquiteturais (componentes e conectores), a fim de elaborar um
modelo intermedirio da arquitetura, que ser relacionado com estilos arquiteturais [16] para seleo de uma
arquitetura candidata. As atividades desse subfluxo so: Relacionar o Domnio com a Arquitetura e Identificar
Oportunidades de Reuso em Nvel Arquitetural.
3.3.2. Subfluxo Definir a arquitetura abstrata. Componentes e conectores do modelo intermedirio

(produzido no subfluxo anterior) so mapeados no vocabulrio da arquitetura candidata e dispostos seguindo
as regras de configurao do estilo. Fazendo isto, produz-se um modelo preliminar da arquitetura, que mostra
a relao de servios entre os componentes. Esse modelo deve ser convertido para a representao definitiva
da arquitetura do software usando UML. As atividades desse subfluxo so: Mapear Vocabulrio do Domnio
sobre a Arquitetura Candidata, Modelar Elementos Arquiteturais, Representar a Arquitetura e Analisar a
Arquitetura.
3.3.3. Subfluxo Refinar a arquitetura. A arquitetura abstrata submetida s regras de refinamento [14]
para a obteno de uma arquitetura em um nvel menos abstrato, que servir de base para a etapa de
concretizao das abstraes arquiteturais . As atividades desse subfluxo so: Aplicar Regras de Refinamento
e Revisar a Arquitetura.
3.3.4. Subfluxo Analisar comportamento. Devido ao fato de UML no permitir um exame de

comportamento rigoroso como o que existe em Wright [12], realizamos uma anlise limitada atravs da
construo de diagramas de estados para os componentes (abstratos e concretos) envolvidos no refinamento.
A partir de uma anlise na lista dos estados possveis nos diagramas construdos, podemos verificar se o
comportamento da arquitetura global ainda preservado aps o refinamento. As atividades desse subfluxo
so: Modelar Comportamento e Analisar Modelo.
3.3.5. Subfluxo Projetar componentes. Em um nvel mais concreto de projeto, componentes podem ser
projetados atravs da aplicao de Padres de Projeto, seguindo a abordagem [6] selecionam-se os padres
que forneam a soluo para o problema tratado. Em seguida, detalham-se as propriedades das classes (e.g.,
atributos) e dos casos de uso envolvidos para definir a estrutura e funcionalidade do componente. Finalmente,
utiliza-se a OMG IDL [17] (Interface Description Language) para especificar interface do componente. As
atividades desse subfluxo so: Efetuar Projeto Detalhado do Componente, Projetar Classes, Projetar Casos de
Uso (*), Especificar a Interface do Componente e Projetar Componente de Dados (*).
3.3.6. Subfluxo Selecionar componentes. Uma vantagem do ArcADe em relao aos processos utilizados
(e.g., RUP) que ele tanto guia a construo (projeto) quanto apoia a incorporao de produtos existentes
(e.g., COTS). Para a incorporao, adotamos o mtodo CRE [1] que identifica os produtos candidatos que
atendam um critrio de seleo (e.g., Interface do Componente). Esse mtodo indica, atravs de um ranking,
qual produto integrar o sistema final. Caso nenhum produto seja selecionado, sugerimos a execuo do
subfluxo Projetar Componentes. As atividades desse subfluxo so: Identificar, Descrever, Avaliar e Aceitar
Produtos Candidatos.
3.3.7. Subfluxo Projetar conectores. Em alguns casos, os tipos bsicos de mecanismos de comunicao
existentes (e.g., Remote Procedure Call) no so suficientes para atender as necessidades de conexo entre os
componentes, isto , no podem ser utilizados para implementar os conectores. Nesse contexto, sugere-se uma
extenso dos tipos bsicos atravs da abordagem [18] para a produo de um novo conector. As atividades
desse subfluxo so: Especificar Partes Concretas do Conector e Estender Tipo Bsico.
3.3.8. Subfluxo Selecionar conectores. Similarmente reutilizao de componentes, conectores podem

ser mapeados em tecnologias middleware (e.g., ORB). A fim de guiar o processo de seleo de um
middleware adequado, sugerimos novamente o mtodo CRE [1]. A partir do critrio de seleo (e.g., suporte
a mltiplas plataformas) identificam-se as tecnologias candidatas. Dentre essas tecnologias o mtodo CRE
indica qual ser integrada no sistema final. Caso nenhuma tecnologia seja selecionada, sugerimos a execuo
do subfluxo Projetar Conectores. As atividades desse subfluxo so: Identificar, Descrever, Avaliar e Aceitar
Tecnologias Candidatas.
Vale salientar que, cada atividade do modelo proposto detalhada em passos e artefatos de entrada/sada,
conforme apresentado em [13]. Na seo seguinte, ilustramos a execuo dos subfluxos do ArcADe,
considerando um determinado cenrio de utilizao.
4. Um cenrio de utilizao do ArcADe.
Esta seo ilustra a utilizao do ArcADe em um estudo de caso real, onde as atividades agrupadas nos
subfluxos so executadas atravs de seus guias passo-a-passo. Nesse estudo, usamos uma aplicao
desenvolvida em colaborao com Ncleo de Tecnologia da Informao (NTI) da UFPE (Universidade
Federal de Pernambuco). Nas prximas subsees, apresentamos a execuo do ArcADe considerando um
determinado cenrio e verificamos os benefcios alcanados com sua utilizao.
4.1. A aplicao SIG@UFPE.
A aplicao SIG@UFPE Sistema de Informao e Gesto Acadmica da UFPE possui como uma de suas
atribuies a automatizao do processo de controle acadmico em todos os nveis de ensino: graduao, ps-
graduao e extenso. Trata de servios como, matrcula, acompanhamento e encerramento de perodo. Todas
essas operaes so realizadas de forma descentralizada e segura atravs da Web.
Em face existncia de diversos cenrios possveis de execuo do ArcADe e do tamanho da aplicao

SIG@UFPE, ilustramos a utilizao do modelo proposto considerando dois aspectos. Primeiro, selecionamos
um cenrio de execuo representativo para a ilustrao, envolvendo trs elementos: utilizao de estilos
arquiteturais; uso de componentes inexistentes; e emprego de middleware para realizar conectores. Segundo,
limitamos o escopo do SIG@UFPE para algumas de suas funcionalidades (ver Subseo 4.2). Contudo,
vlido ressaltar que, outros cenrios devem ser experimentados para verificao completa do modelo,
conforme mencionado na seo 5.
Considerando o cenrio acima, seis subfluxos devem ser executados: Selecionar Arquitetura Candidata,
Definir Arquitetura Abstrata, Refinar a Arquitetura, Projetar Componentes e Selecionar Conectores. As
subsees seguintes apresentam a execuo de cada um desses subfluxos.
4.2. Artefatos base para execuo dos subfluxos.
O ArcADe considera como uma das suas principais entradas o documento de requisitos. No sistema
SIG@UFPE, o mdulo em construo trata do planejamento de matrcula e matrcula, o qual foi utilizado no
estudo de caso. Entre os principais requisitos funcionais desse mdulo destacam-se: [R01] Definir Atividades
Acadmicas a Ofertar; [R02] Realizar Pr-matrcula; [R03] Definir Atividades Acadmicas Ofertadas; [R04]
Criar Turmas e Subturmas; [R05] Controlar Espao Fsico e Recursos Humanos; [R06] Realizar Matrcula em
Atividade Acadmica; e [R07] Matricular em Turma. Dentre esses requisitos, limitamos o escopo do estudo
ao requisito [R04], pois o julgamos como um dos mais representativos devido ao grau de complexidade,
nmero de elementos envolvidos durante sua realizao e necessidade de comunicao com outros
componentes para cumprir suas responsabilidades.
4.3. Execuo dos subfluxos do ArcADe.
4.3.1. Subfluxo Selecionar uma Arquitetura Candidata. Inicialmente efetuamos o relacionamento dos
requisitos com a arquitetura de software atravs da abordagem CBSP (Component-Bus-System-Property) [5],
onde os requisitos ([R01]...[R07]) foram considerados de relevncia arquitetural e classificados como
componente de processamento (Cp). As dependncias entre esses componentes foram obtidas pela
necessidade de comunicao entre eles. Por exemplo, na Figura 5.a, o componente Gerenciador de Turmas e
Subturmas depende da informao de Espao Fsico (componente de dados Cd).
Componentes e dependncias auxiliam o arquiteto a encontrar um estilo arquitetural adequado.

Considerando o domnio da aplicao (Web) o estilo cliente-servidor [16] organizado em trs nveis foi
selecionado (Figura 5.b). A partir do modelo CBSP e do estilo selecionado, define-se a arquitetura abstrata
do sistema especfico, conforme apresentado na prxima subseo.
4.3.2. Subfluxo Definir a Arquitetura Abstrata. Conforme mencionamos no incio da Subseo 4.2,
limitamos o escopo do estudo de caso ao requisito [R04]. A partir desse requisito e considerando a
organizao da arquitetura em trs nveis, a estrutura do sistema fica da seguinte forma: o componente GUI
dedicado ao nvel de apresentao; os componentes Gerenciadores so alocados para o nvel de lgica do
negcio; e os componentes de dados so dedicados ao nvel de dados. Esse modelo preliminar, que mostra a
relao de servios, est esquematizado na Figura 5.b.
Em seguida, documentam-se as abstraes arquiteturais em um formulrio elaborado com base em [12],

contendo os seguintes itens: Interface (Servios Oferecidos - portas de entrada e de sada, Servios
Requeridos), Tipo, e Semntica do componente. A Tabela 2 apresenta um resumo da especificao do
componente GerenciadorTurmas utilizando esse formulrio.
Tabela 2 Especificao (Parcial) do Componente GerenciadorTurmas

Interface
Servios Oferecidos
Portas de Entrada
espAtivAcad: Oferece o servio responsvel pela atribuio de uma atividade acadmica para uma turma
....
Portas de Sada
consTurma: Fornece dados referente a uma determinada turma.
...
Servios Requeridos
consSalas: Solicita o servio responsvel pela obteno das salas disponveis...
Tipo
GerenciadorTurmas: Este tipo de componente encapsula as funcionalidades para criar turmas ...
Semntica: Para a criao de uma turma, o GerenciadorTurmas deve solicitar as atividades acadmicas ...
De posse da especificao dos elementos arquiteturais (ver Tabela 2) e do modelo de relao de servios
(ver Figura 5.b), representamos a arquitetura em UML usando a abordagem [7] (ver Figura 5.c), onde
definimos os esteretipos <<Arch-Component>> e <<Arch-Connector>> para modelar componentes e
conectores respectivamente. As interfaces dos elementos arquiteturais foram modeladas por classes de
interfaces. As portas e papis foram representadas pelos esteretipos <<in>> e <<out>> indicando o sentido
da comunicao. O modelo da Figura 5.c ser submetido a regras de refinamento na prxima subseo.
Figura 5 (a) Modelo CBSP (b) Relao de servios (c) Representao UML da arquitetura
4.3.3. Subfluxo Refinar a Arquitetura. Com a arquitetura abstrata definida, segue-se com sua
transposio para um nvel mais concreto. Para efeito ilustrativo, refinamos o componente
GerenciadorTurmas por decomposio em dois: GerenciadorCadastroTurmas oferece o servio de criao da
turma (atribuio da atividade acadmica) e gerenciamento de detalhes da turma (e.g., salas, horrios, etc); e
GerenciadorAlocDocentes oferece os servios para alocao de um ou mais docentes a uma turma criada. Na
prxima seo verificamos se a arquitetura global preserva suas propriedades aps o refinamento.
4.3.4. Subfluxo Analisar Comportamento. Devido ao refinamento provocar alteraes estruturais,

devemos verificar se a arquitetura refinada preserva o comportamento da arquitetura abstrata. Para isso,
construmos um diagrama de estados UML para cada componente envolvido no refinamento. Conforme
mencionamos na subseo 3.3, UML permite uma anlise de comportamento limitada, onde analisamos os
diagramas de estados e observamos que a lista de eventos (estados possveis) dos componentes resultantes do
refinamento est contida na lista de eventos do componente abstrato. Assim, verificamos que o
comportamento da arquitetura abstrata foi preservado.
4.3.5. Subfluxo Projetar Componentes. Cada componente da arquitetura refinada deve ser concretizado
atravs de estratgias de projeto. Observando a especificao dos componentes arquiteturais (ver Tabela 2) e a
representao da AS (ver Figura 5.c), selecionamos trs padres de projeto de acordo com seus propsitos:
Facade, Proxy e Command. Esses padres foram aplicados no projeto dos componentes GerenciadorTurmas
e GerenciadorCadastroTurmas. Nessa aplicao, os padres foram detalhados e instanciados no contexto dos
componentes (ver Figura 6).
<<Arch-Component>>
<<Arch-Component>>
GerenciadorTurma
GerenciadorCadastroTurma
s Projeto Arquitetural)
(from
s (from Projeto Arquitetural)
PortGerTurmas PortGerCadTurma
(from Projeto Arquitetural) (from Projeto Arquitetural)
<<in>> espAtivAcad() <<in>> cadTurma()

<<in>> cadTurma() FachadaPx
<<in>> espAtivAcad()
<<in>> espDocentes() Invoker <<out>> consTurmas()
<<out>> consTurmas() <<in>> consAtivAcad() <<out>> mensagens()
<<out>> mensagens() <<in>> consSalas()
evento(serv:
serv.execute()
Command)
<<Proxy>>
PxBDR
Servios
<<Proxy>>
<<out>> PxGerEspFisico
<<in>> consTurma()
GravarTurma() Command
ConcretCommand
<<in>> consSalas()
execute()
<<Proxy>>
PxGerAtivAcad
EspAtivAcad
<<in>> consAtivAcad()
CadTurma consultarAtivAcademica()
locarAtivAcad()
inserirTurma() desalocarAtivAcad()
atualizarTurma()
deletarTurma()
inserirHorarioTurma(
)d eletarHorarioTurma(
)
Figura 6 Projeto detalhado do componente GerenciadorTurmas
Aps o projeto da estrutura interna e da funcionalidade do componente (ver Figura 6), deve-se especificar
sua interface atravs do uso da IDL (Interface Description Language) OMG [17].
4.3.6. Subfluxo Selecionar Conectores. Inicialmente, os middleware que sejam potenciais candidatas so
localizados de acordo com o critrio de seleo ( ver Figura 7.a). Em seguida, selecionamos os middleware
que atendiam ao critrio (ver Figura 7.b).
(a) (b)
Figura 7 (a) Critrio para seleo de middleware (b) Lista de middleware candidatos
Em seguida, coletamos as informaes detalhadas sobre as tecnologias, a fim de expor os pontos positivos
e negativos de cada tecnologia. Analisando essas informaes, eliminamos duas tecnologias: RMI, por no
promover a interoperabilidade; e ILU, por no ser to difundida, tendo pouca documentao disponvel e
suporte. Finalmente, verificamos qual tecnologia melhor atende aos requisitos de comunicao. Nesse
momento, efetuamos alguns testes para verificar os aspectos legais e de comunicao. Considerando o uso da
tcnica de tomada de deciso e a conformidade dos testes, o middleware ORB (Visibroker) foi selecionado.
4.4. Benefcios Alcanados.
Os benefcios alcanados com a utilizao do ArcADe so os mesmos fornecidos pela AS, tais como, reuso
em nveis abstratos, utilizao de estilos arquiteturais e tratamento de conectores como entidade de primeira-
classe. Em contraste com o que utilizado no NTI (ver Figura 8), podemos destacar o seguinte:
<<Arch-Component>>
GerenciadorTurmas
PortGerTurmas
<<Arch-Connector>>
<<in>> espAtivAcad() Link
<<in>> cadTurma()
<<in>> espDocentes() RoleLink
<<out>> consTurmas()
<<out>> mensagens()
<<out>> consDocentes()
<<out>> consSalas()
<<out>> consAtivAcad()
<<Arch-Component>>
GerenciadorRecursosHumanos
<<Arch-Component>>
PortGerRecHum GerenciadorAtividadesAcademicas
PortGerAtivAcad
<<out>> consDocentes()
<<Arc-Component>> <<out>> consAtivAcad()

GerenciadorEspacoFisico
PortGerEspFisico
<<out>> consSalas()
(a) (b)
Figura 8 (a) Arquitetura produzida pelo ArcADe (b) Arquitetura obtida pelo processo usado no NTI
Primeiro, no ArcADe os componentes so diferenciados entre si atravs de um nome indicando seu tipo.
Segundo, o modelo proposto trata elementos arquiteturais em nveis bem abstratos, por exemplo, na interface
dos componentes os servios representam uma srie de operaes a serem disponibilizadas, em particular, o
servio cadastrar turmas fornece as operaes de incluso, excluso e alterao de uma turma. Finalmente,
no ArcADe conectores possuem status de primeira-classe, ou seja, torna explcito o projeto de conectores (ver
a classe Link na Figura 8.a), com isto promove-se a reduo do acoplamento entre os componentes do
sistema, aumentando-se as oportunidades de reuso de componentes e conectores em outros contextos.
No estudo de caso realizado, ilustramos a concretizao de um componente (GerenciadorTurmas) e a

seleo de um middleware para realizar um conector. Vale salientar que o ArcADe considera o modelo
iterativo e incremental. Sendo assim, os demais componentes e conectores podem ser concretizados em
iteraes futuras at que o nvel concreto da arquitetura global tenha sido alcanado.
5. Concluses e Trabalhos Futuros.

Este artigo apresentou o modelo ArcADe (Software Architecture-Based Analisys and Design) que define
como a arquitetura deve ser tratada explicitamente em um processo de desenvolvimento iterativo e
incremental. Esse modelo possui oito subfluxos que so organizados em dois nveis de abstrao distintos. No
nvel de Projeto da Arquitetura podem-se executar os seguintes subfluxos: Selecionar uma arquitetura
candidata; Definir a arquitetura abstrata; Refinar a arquitetura; e Analisar comportamento. No nvel de Projeto
Detalhado podem-se executar os seguintes subfluxos: Projetar componentes; Projetar conectores; Selecionar
componentes; e Selecionar conectores. Todos esses elementos so reunidos para tratar explicitamente a
arquitetura e os elementos arquiteturais (componentes e conectores).
Os subfluxos do modelo proposto foram testados, de forma experimental, no projeto do sistema

SIG@UFPE (desenvolvido pelo Ncleo de Tecnologia da Informao da UFPE) para ilustrar sua utilizao,
detectar inconsistncias e verificar a coerncia das atividades e passos definidos em cada subfluxo.
O ArcADe no envolveu todo o processo de desenvolvimento do software, pois foi concentrado na etapa de
anlise e projeto. No entanto, outras etapas do processo tambm podem ser afetadas e conseqentemente
precisam ser adaptadas. Por exemplo, a etapa de implementao deve ser redefinida, pois caso seja
selecionado um elemento arquitetural j existente, o esforo ser de adaptao e no de implementao.
Apenas um cenrio foi utilizado para ilustrar a execuo do modelo proposto, o que limitou a verificao
do ArcADe em apenas seis subfluxos. Sendo assim, a criao de novos cenrios para exercitar e analisar os
outros subfluxos, bem como a definio das outras etapas do processo de desenvolvimento de software so
trabalhos de pesquisa a serem analisados futuramente, de modo a que venhamos a ter um processo completo
de desenvolvimento baseado em arquitetura de software.
6. Referncias.
[1] C. Alves, Seleo de Produtos de Software Utilizando uma Abordagem Baseada em Engenharia de Requisitos,
Dissertao de Mestrado. Universidade Federal de Pernambuco, Brasil, Mar, 2001.
[2] L. Bass, P. Clements and R. Kazman. Software Architecture in Practice, Addison-Wesley, 1998.
[3] Catalysis. Website: http://www.catalysis.org, All contents copyrighted 1998. Last access in Jan/2004.
[4] E. Dashofy, N. Medvidovic and R. Taylor, Using Off-The-Shelf Middleware to Implement Connectors in
Distributed Software Architectures, 1998.
[5] A. Egyed, P. Grunbacher, and N. Medvidovic, Refinement and Evolution Issues in Bridging Requirements and
Architecture The CBSP Approach, In Proc. of the From Software Requirements to Architectures Workshop
(STRAW 2001), Toronto, Canada, May 14, 2001.
[6] E. Gamma, R. Helm, R. Johnson and J. Vlissides. Padres de Projeto Solues Reutilizveis de Software
Orientado a Objetos, Porto Alegre: Bookman, 2000.
[7] D. Garlan, A. Kompanek, and S. Cheng, Reconciling the Needs of Architectural Description with Object-
Modeling Notations, http://www-2.cs.cmu.edu/~able/publications/uml01/. Last access in Jan/2004.
[8] ISO/IEC TR 15504. Information technology Software process assessment. Canada, 1998.
[9] I. Jacobson, M. Griss and P. Jonsson. Software Reuse Architecture, Process and Organization for Business
Success, Addison-Wesley, 1997.
[10] P. Krutchen. The Unified Software Development Process, An Introduction, Addison Wesley, 1999.
[11] MDA Website: http://www.omg.org/mda, Last Updated Tuesday, March 12, 2002. Last access in Jan/2004.
[12] N. Medvidovic and R. Taylor, A Classification and Comparison Framework for Architecture Description
Languages, IEEE Transactions on Software Engineering, Vol 26. N 1, Jan, 2000.
[13] M. Moraes, Um Framework de Anlise e Projeto Baseado em Arquitetura de Software, Dissertao de

Mestrado. Universidade Federal de Pernambuco, Brasil, Jul, 2002.
[14] M. Moriconi, X. Qian, and R. Riemenschneider, Correct Architecture Refinement, Appeared in IEEE
Transactions on Software Engineering, April, 1995, Vol.21, N 4, pp. 356-372.
[15] N. Rosa, G. Justo, and P. Cunha, A Framework for Building Non-Functional Software Architectures, In 16th
ACM Symposium on Applied Computing, Las Vegas, USA, 2001. 16th ACM SAC. , 2001. p.141 147
[16] M. Shaw and D. Garlan. Software Architecture: Perspectives on an Emerging Discipline, Prentice Hall, New
Jersey, 1996.
[17] J. Siegel. CORBA Fundamental end Programming, John Wiley & Sons, Inc.1996.
[18] B. Spitznagel and D. Garlan, A Compositional Approach for Constructing Connectors, In Proc. of the Working
IEEE/IFIP Conference on Software Architecture (WICSA01), 2001.
Metaprogramming in .NET
Miguel Katrib, Mario del Valle, Iskander Sierra, Thaizel Fuentes

Computer Science Department, University of Habana
{mkm, mariovm, iskander, thai}@matcom.uh.cu
Summary
Among other reasons .NET excels other previous component technologies because it
seamlessly integrates code and metadata supporting metaprogramming facilities. This work
shows how using the .NET new notion of attribute, combined with the .NET reflection
capabilities we can achieve a more generic and abstract level of programming resulting in
less code and better developing process decreasing the programming effort. Two examples
are developed to enforce the previous statement. One example uses reflection and the emit
capabilities to silently generate code on the fly factorizing common behavior of non related
types. The other uses .NET attributes to introduce boolean assertions clauses as custom
attributes in .NET types. Calls to methods of such asserted type can then be intercepted
and using reflection the assertion attributes can be monitored in runtime supporting the
Design by Contract metaphor.
Components in Previous Technologies

Component oriented technologies like COM and CORBA use Interface Definition Languages
(IDLs) for type specification. The IDLs are based only in the operations signatures. They do not
include more semantic information other than the one that can be deduced from types, methods and
parameters names. Those IDLs have no linguistic construction attaching an actual implementation
of a component to an existing IDL. This task requires a dedicated plumbing effort.
Java technology alleviates the above drawback because the notion of interface type is included in
the Java programming language itself. But Java technology has the following weaknesses:
A mono linguistic approach, a Java component can only be used by another Java component. At
least there is no seamless and comfortable way to connect an EJB component to a component
resulting from other language and vice versa.
The documentation extracted from the component consists only of type signatures and
"formatted" comments.
The Java reflection mechanism is unable to recover the "information" embedded as comments.
Developers must know and work directly with the internals of a Java byte code file.
Strengths of the .NET Assemblies

Software components in the .NET technology are supported by the concept of assembly.
A .NET assembly is language neutral. It can be seamlessly used from other .NET assembly
independently of the original language that each one produced.
A .NET assembly contains code, data and metadata (data describing code and data). The
metadata can be fully extracted by the .NET reflection capabilities.
.NET introduces a new creature for adding metadata: attributes. Through attributes, developers
can include their own custom metadata in the assemblies. And because attributes are objects;
they could enjoy the goodies that the OO .NET conception supports.
Factorizing .NET Types

Reflection is the programmatic act of reading the metadata associated with an assembly and
types. .NET has full programmatic way to recover all metadata that the different .NET tools embed
in assemblies. So, using reflection, applications are not vulnerable to changes in the physical
representation of the assemblies.
This section will show how based on reflection we can factorize the common behavior existing
in apparently no related types.
A common task in programming is to reproduce similar behavior with different
implementations. When you can look forward planning all your potential different implementations
you can define a root type (be a class or an interface in .NET) and then implement different types
deriving (or implementing) the base type (or interface). But what you can do if you want to use
different types in a common new functionality and such types do not have a common root.
Furthermore, what to do if some of those types are not the result of a static writing of code but was
generated on the fly.
Suppose we have two types B and C having a common set of methods f1, f2, fn. But
unfortunately they didnt design as deriving from a common parent type A (or implementing a
common interface IA) defining such a common functionality.
How to implement a new functionality that uses an object with the above common
functionality f1, f2, fn despite if the object is of type B or C ?
Solution 1 Replicate the New Functionality for Both Types B and C

Having method overloading the traditional solution force to rewrite the same code for the
different types B and C as shown in the code excerpt below.
void NewMethod(B x){ void NewMethod(C x){
... ...
x.f1(); x.f1();
... ...
x.fn(); x.fn();
} }
Such new functionality should be called

B b;
...
NewMethod(b)
or
C c;
...
NewMethod(c)
The main drawbacks of this approach are the tight coupling and the low scalability due to code
replication. Under this approach we are forced to rewrite another NewMethod with a similar code
only to accept a parameter of the new type D having the common behavior as B and C.
Solution 2 Writing One Multi-choice Method

Another approach is to write only one NewMethod based on the Object root type
void NewMethod(Object x){
...
if (x is B)
((B)x).f1();
else (x is C)
((C)x).f1();
...
if (x is B)
(B)x.fn();
else (x is C)
(C)x.fn();
}
This approach results also in tight coupling and low scalability. A new type D forces to
rewire the existing NewMethod code to introduce the new choices. Even worst, what if D is a type
created on the fly by an application? This solution has no replicated code but it is inefficient due to
type questions and castings inside the NewMethod.
A Factory Proxy Type Solution Using Reflection

Obviously we can capture the common behavior of types B and C in a common interface IA
interface IA{
void f1();
...
void fn();
}
and then write the new functionality based on this interface type
void NewMethod(IA x){
x.f1();
...
x.fn();
}
The problem to solve is how to force yet existing types B and C, or forthcoming new types that
do not know about the existence of IA, to declare that they implement the interface IA. It is a
matter of the client code having an object of a type D matching the interface IA, to have the
possibility to call NewMethod even if D is not defined as implementing IA.
To bring such a capability to client code a general factory class could be defined (see the code
excerpt below). Receiving an object parameter and a Type parameter the method Create of the
ProxyFactory creates on the fly (using reflection) a proxy type implementing the interface type.
This proxy type uses the functionality existing in the type of the object x received as parameter to
the method Create. If the type of x has no methods with the same signatures as methods of the
interface type then an exception will be thrown. The type BProxy below illustrates how such proxy
type looks. Note how the new type (BProxy) wraps an object of the original type (B)
class ProxyFactory{
public static object Create(object x, Type interfaceType){
...
}
}
class BProxy : IA{

B b;
...
public void f1(){
b.f1();
}
...
public void fn(){
b.fn();
}
}
So, the client code interested in using the NewMethod needs to observe pattern below to create
the proxy object from its object myB
B myB;
...
IA a = ProxyFactory.Create(myB, typeof(IA));
NewMethod(a)
Certainly this solution implies an extra call because the calls of the form x.f() inside the
NewMethod will call the corresponding b.f() method of the wrapped object inside the proxy. But
this tiny extra cost in performance will be compensated with the adaptability and loose coupling of
the resulting code.
To avoid this extra call we could try to create the proxy type copying IL code from the original
methods into the corresponding methods of the proxy type, i.e. following the pattern:
class BProxy : IA{
public void f1(){
// ... a similar IL code of the f1 of type B
}
...
public void fn(){
// ... a similar IL code of the fn of type B
}
}
Unfortunately, arguing copyrights reasons Microsoft do not include such IL code copy and
pasting in the .NET reflection capabilities. Nevertheless, this is a no very persuasive argument
because such a facility could be controlled customizing the .NET security policy. For instance, there
will not be a copyright violation if programmers of the same enterprise (including the single case of
a programmer for him (her) self) do some copy and paste of their own IL code.
Using .NET Attributes to Introduce Assertions in .NET Assemblies
The Convenience of More Trusted .NET Assemblies

Despite of the good .NET security policy and security mechanisms .NET applications are not
forced to use the types (methods, properties) of an assembly under the "usage pattern" that this
types (methods, properties) request. Examining the .NET BCL this usage pattern appear in verbose
documentation. Yes, developers could trust in the confidence of Microsoft staff's capacity devoted
to the BCL, but we can not force that any assembly A must blindly trust in an incoming assembly B.
For example, let's consider an assembly exporting a type Stack having a Push method and a
Top property. How could this assembly require their client assemblies that they cannot apply Top
to a target s (of type Stack) if s is empty? How can the same assembly guarantee that after pushing
an object x in s, the property Top will return x?
The current section shows how to include Eiffel-like [10, 11] assertions in .NET using
attributes. This will result in a "logic formalism" to specify more semantic information about the
types defined in an assembly.
Attributes in .NET
Reflection really shines when used in conjunction with a .NET creature: attributes. Attributes
are defined by .NET special types (inheriting from the class System.Attribute). From
programming point of view, attributes are objects that can be initialized with basic and Type
parameters and that will be embedded in the metadata in a standard and integrated way ready to
be recovered by reflection.
Attributes enable declarative behaviour and data augmentation. Instead of wirecoding
functionality and features, such functionalities can be added to code decorating the assembly (and
almost all .NET languages features: types, methods, properties, events, parameters) with attributes.
In this way a software developer has the ability to achieve clear separation of concerns that the Aspect
Oriented Programming promotes [8, 14].
So, .NET tools or our customs tools (as is showed in the example below) can read the
metadata, look for the attributes and perform the functionality they specify without the objects or
its developers involvement.
Including Logic Assertions by Means of .NET Attributes

Assertions, as promoted for Eiffel and other languages, are logic expressions. In the presented
approach these logic expressions will be inserted in .NET types as string parameters of special
custom attributes that we call assertion attributes. The target of an assertion attribute will be the
entity specified by the assertion (a type or a method). An assembly embedding such attributes will
be named asserted assembly.
The intention is that when a asserted assembly is used in the development of an application the
developer could benefit from the assembly in two ways:
1. Extract the text of the assertions and verify if the text was correctly written. Then such
text serves for specification and documentation purposes.
2. Monitor the assertions. Verifying the assertions fulfilment in runtime. Resulting in
more reliable an error prune code.
The AssertionAttribute describes the assertion attribute
abstract Assertion: System.Attribute{
string BoolExpression {...}
string Label {...}
bool Inherited {...}
}
The BoolExpression gets the string describing the assertion clause. For example the string
"!Empty" used in the assertion attribute of the method Pop of the type Stack helps to specify that a
stack can not be popped if it is empty and helps to generate the code which will verify the non
emptiness, raising an exception if it evaluates false.
The Label allows adding extra information about the assertion. For example, Label = "To
pop an element the stack can not me empty" could be used to define a textual message about
the assertion semantics. It is useful for documentation and for exception information.
The Inherited property states if the assertion will apply also to a derived class.
Three classes InvariantAttribute, PreconditionAttribute and PostconditionAttribute
derive from AssertionAttribute they represent the three kind of assertions and differ in the target
of the attribute.
The InvariantAttribute will be targeted to a class, interface or struct type (Note in the
excerpt below how the AttributeUsage attribute is used for this purpose)
[AttributeUsage(
AttributeTargets.Class |
AttributeTargets.Struct |
AttributeTargets.Interface,
AllowMultiple = true)]
public class InvariantAttribute : AssertionAttribute {
InvariantAttribute(string CSALExpression) : base(CSALExpression){}
}
Because the property AllowMultiple is set to true then several invariant attributes can be
targeted to a same type. The semantics in this case means that a logical conjunction (&&) operation
will be applied to all the invariant attributes.
The InvariantAttribute means that the assertion described by text of the property
BoolExpression should be true for any instance of the targeted type. If assertions were monitored
at runtime and some of them evaluates false then an InvariantException exception will be
thrown. If the value of Label property is non null then string value of the property will be part of
the exception message.
The following invariant attribute can be attached to the definition of a type Rational and the
invariant uses the property Denominator:
[Invariant("Denominator != 0", Label="Denominator cannot be zero")]
struct Rational{
//...
public Numerator{
// An implementation of the property Numerator
}
public Denominator{
// An implementation of the property Denominator
}
}
The string "Denominator != 0" denotes a boolean expression in C#AL (see further). This
means that any instance of the Rational type must have a denominator different from zero. At
runtime, this invariant will be verified before and after the execution of each of the public methods
(properties) of the type. The property Label adds a readable text about the assertion, "Denominator
cannot be zero". This label will be displayed at runtime by the assertion monitoring mechanism
when throwing an exception because the assertion evaluates false, and is displayed for
documentation purposes by tools extracting the assertions from the assembly.
Preconditions and postconditions are assertions attributes that must be attached to methods
(including constructors and properties).
Under the Design by Contract guidelines a PreconditionAttribute will denote a condition
that is required by the assembly before applying the public method (property, constructor), attached
by that attribute. So the PreconditionAttribute class is defined as follows
[AttributeUsage(
AttributeTargets.Method |
AttributeTargets.Property |
AttributeTargets.Constructor,
public class PreconditionAttribute : AssertionAttribute {
PreconditionAttribute(string AALExpression) : base(AALExpression){}
}
Similarly, a PostconditionAttribute denotes the condition that will be ensured by the

assembly after applying the method (property, constructor).
[AttributeUsage(
AttributeTargets.Method |
AttributeTargets.Property |
AttributeTargets.Constructor,
public class PostconditionAttribute : AssertionAttribute {
PostconditionAttribute(string CSAssertion) : base(CSExpression){}
}
Note in the excerpt below how precondition and postcondition attributes are attached to a
method Push of an interface type Stack. Note in this case that the method Push has only one
precondition but has three postconditions (this is possible because the above property
AllowMultiple = true).
interface Stack {
public bool Full {get;}
public object Top {get; set;}
public bool Empty {get;}
public int Total {get;}
[Precondition("!Full", Label="The Stack cannot be full")]

[Postcondition("!Empty")]
[Postcondition("Total == pre Total + 1")]
[Postcondition("Top == x", Label="The Stack applies a LIFO policy")]
public void Push(object x);
//...Other Stack features

}
The precondition [Precondition("!Full", Label="Stack Overflow")] states that when
pushing an element in a stack the stack must not be full. The postcondition
[Postcondition("!Empty")] and ")] states that after pushing and element in a stack the stack
will not be empty, the postcondition [Postcondition("Total == Total.Old + 1")] states that
the total of elements in the stack will be Total.Old + 1 (i.e. one plus the previous value of Total
before executing Push), and the postcondition [Postcondition("Top == x", Label="The Stack
applies a LIFO policy")] states that the pushed element will be at the top of the stack.
The C# Assertion Language (C#AL)

The string parameter BoolExpression required by the assertion attribute constructors must
describe a text written in the C# Assertion Language (C#AL). C#AL is a C# like notation to express
some special boolean expression. Such expressions should be syntactically and semantically correct
if "it would be compiled" in the scope of the source text code of the entity (type, method or
property) targeted by this assertion attribute. So, if "it would be evaluated at runtime" it should
result in a bool value. This effect will be achieved by extracting the assertion attributes and
checking their correctness using the .NET reflection and optionally emitting the corresponding code
to evaluate the assertion at runtime.
According to the .NET visibility rules an identifier "appearing" in a C#AL expression should
be the name of an entity which is visible in the scope of the assertion and it must observe the
following rules:
1. Because assertions in an assembly are oriented to be used and tested by client code in other
assemblies, then only public (visible) features of the types exported by the assembly can be
used in the assertion's boolean expression. This policy is enforced in the recommended scenario
where assertions are used in the definition of an interface type because all features of an
interface are public.
For example, let a type Stack, if the Full property would be not public, then there would have
no sense that the public method Push have the precondition "!Full" if a client assembly
doesn't know anything about the Full property.
2. Pre and postconditions of an instance method (property) can use both instance (non static) and
type (static) features of the type defined the method (property).
3. Pre and postcondition of a static method (property) can only use static features of the type.
Inspired in the Eiffel assertions a set of special variables and operators were included in C#AL.
A special property Old can be applied to any term used in a postcondition of a method. This
property returns the corresponding value of the term previous the method's execution1.
For example the postcondition
[Postcondition("Total == Total.Old + 1",
Label="The stack must increase by one element"]
attached to the Push method of the type Stack, expresses that after pushing an element into the
stack, the Total property must have a value equal to the previous value of Total (denoted by
Total.Old) was increased by 1.
The variable value normally used by C# in the set part of a property implementation has the
same meaning when used in postconditions. For example, the postcondition Top == value after
the set part of the property Top means that after doing Top = x the value in the top of the stack
will be x. (this is normally the expected semantics in a set but it could change).
The term x.Old returns a copy of the previous value of x, i.e. the value of x before applying
the method (property) target of the postcondition. By default when x is of reference type the
returned value is a copy of the original reference. But if the dynamic type of the object attached to x
implements the interface ICloneable the returned value is the corresponding clone of x. So,
overridden the virtual method Clone developers can decide how deeply to apply the Pre policy.
Consequently a developer should override the method Equals so a postcondition of the form
x.Equals(x.Old) or x == x.Old will depend on how deep the developer wants to apply the
cloning and the equality police.
Other special feature included in C#AL is the special variable result. This "variable" can be
used in the postcondition of a non void method or in the postcondition of a get part of a property.
This variable result will refer to the returning value of the method (property). See for instance the
postcondition of the get part of the property Tomorrow of the type Date:
[Postcondition("result-this == 1", Label = "Tomorrow is the day after today")]
(Note that the above postcondition supposes that the minus operator is redefined for date
objects, returning the difference in days between two dates. This operator was not defined for
brevity reasons).
In addition to the C# boolean operators && || and !, two new boolean operators were
included. The operator => (read implies) for logical implication and the operator <=> (read if only
if) for logical equivalence. Although they can be expressed using the &&, || and ! they were
1
Old is the name used in the Eiffel language. In Eiffel old is a special unary operator, in C# notation we introduce
Old as a special property that we can apply to any target appearing in the text of a postcondition.
included to facilitate design and to improve readability. See for example the following invariant
assertion expressing the integrity of a Date type:
[Invariant(
@"(Day >= 1) && (Month >= 1) && (Month <= 12)
&&
(
((Month == 1) || (Month == 3) || (Month == 5) || (Month == 7) ||
(Month == 8) || (Month == 10) || (Month == 12) => (Day <= 31))
||
((Month == 4) || (Month == 6) || (Month == 9) || (Month == 11) => (Day <= 30))
||
((Month == 2) && (Year % 4 == 0) => (Day <= 29))
||
((Month == 2) && (Year % 4 != 0) => (Day <= 28))
)", Label("Day and Month consistency")]
Improving the Power of the Assertions Using Quantifiers

Assertions in Eiffel language lack more powerful logic. [2, 7] propose the inclusion of iterators
to express collections in Eiffel and also an extension of the assertion's logic based on the inclusion
of quantifiers in assertions. Quantifiers are also introduced for some Java extensions [5, 6].
Fortunately, .NET standardizes the notion of collection and iteration based on the
IEnumerable interface. Furthermore, the C# language includes the operator foreach to iterate
through IEnumerable objects. Based on this .NET concept, C#AL includes the universal quantifier
forall and the existential quantifier exists. These operators increase the expressivity of the
assertion's boolean expressions toward a predicate calculus. They have the syntax
forall (T x in C : E) and exists (T x in C : E)
where T is a type name, x is a variable, C is an expression denoting a collection returning objects
of some type that can be casting to T and E is a bool expression where the variable x should
appear.
The forall operator will evaluate true if for all x in the collection C the expression E
evaluates true, in other case it will evaluate false. The exists operator will evaluate true if at
least there exists one x in the collection C so that the expression E evaluates true, in other case it
will evaluate false.
When assertions are monitored at runtime, both operators will throw an InvalidCast
exception if the object returned by the iterator can not be cast to T. However, if you want to put an
assertion only to a subset of C you can use the following pattern:
forall (object x in C : (x is T) => E')
E' denotes the expression E changing all occurrences of x by the cast (T)x. In such case, the effect
will be the same as to evaluate the expression E only for those x having dynamic type T. The same
pattern can be applied to the operator exists.
A type Employee having a property MyDepartment and a type Department having a property
Employees could have the following invariants:
[Invariant("forall (Employee e in Employees : e.MyDepartment == this)",
Label = "The Department must have legal employees")]
class Department {
...
}
[Invariant("exists (Employee e in MyDepartment.Employees : e == this)",

Label = "Must be a legal employee")]

class Employee {
...
}
Quantifiers are also useful to specify consistency between add, remove and membership operations
of a collection type. For example, a Fire method of the Department type may have the
postcondition.
[Postcondition("! exists (e in Employees: x == e)",
Label = "Must be an employee of the Department")]
public void Fire(Employee e){...}
A classical use of postconditions has been to set consistency between an insert operation into a
collection and a membership operation to that collection. This is shown in the postcondition of a
method ContractEmployee in the type Department
[Postcondition("Has(e)", Label = "The Department must have this employee")]
public void ContractEmployee(Employee x){...}
Nevertheless, the reverse assertion could not be expressed without quantifiers, so note the following
postcondition for the method Has
[Postcondition("result <=> exists (Employee e in Employees : x == e)")]
public bool Has(Employee x){...}
The proposed quantifiers can also be useful in preconditions. Note the precondition of a
method AnnouunceMeeting in the type Department. This method announces a meeting date to all
its employees, but it requires the date not to be a holiday. This could be expressed in the following
precondition using the static property Holidays of the type Date:
[Precondition("forall (Date d in Date.Holidays : d != meetingDate"),
Label = "The meeting date must be a working day"]
public void AnnouunceMeeting(Date meetingDate){...}
The reader could argue that this behaviour could be better specified if the Date type would
have a bool property IsHoliday, then the above precondition could be replaced by the following
one:
[Precondition("!meetingDate.IsHoliday",
Label = "The meeting date must be a working day")]
public void AnnouunceMeeting(Date meetingDate){...}
More examples of how quantifiers can enhance the expressiveness of assertions can be found
in [2].
How to Reflect and Monitor Assertions?

The sections above illustrate how using attributes then metainformation (as assertions
attributes) can be inserted in a .NET assembly. It wouldnt be too useful stopping here because
attributes do not perform any action by themselves; they wait quietly in the assembly. We need that
applications could reflect and interpret them.
For this goal a C#AL Browser Tool was developed. This tool uses reflection to extract
assertion attributes from an assembly, listing the types in the assembly with their corresponding
assertions attributes, and checking if the string value of the property boolExpression is correct
according to C#AL (see Figure 1).
But assertions should be monitored at runtime, i.e. it is worth to evaluate the boolean
expressions represented by the assertions throwing exceptions if they are not fulfilled in the
corresponding evaluation points (preconditions before method calls, postconditions after method
calls, and invariants before and after method calls). Two approaches could be applied to implement
this goal.
Figure 1. A type Stack with assertion attributes displayed by a C#AL Browser
One approach consists on generating a trusted assembly from the original asserted one. The
trusted assembly works as a proxy to the original one. Each type and method in the original
assembly has a corresponding type and method in the trusted assembly. Public methods in the
trusted assembly have the same behaviour and result that their homologous in the original but plus
assertions evaluation.
So, if you want that an application monitors the assertions of an assembly A.dll then you must
remove the reference to the original A.dll from your project and insert a reference to the
corresponding trusted assembly TrustedA.dll. This TrustedA.dll includes proxies for all
features of the A.dll and a reference to the original A.dll. The resulting exe application will
monitor de assertion's fulfilment calling the methods of the proxy. Methods in TrustedA.dll
evaluate preconditions and invariants before calling the corresponding methods in A and evaluate
postconditions and invariants after return from methods in A.
This approach has a drawback because types in the trusted assembly must replicate the code
existing in the original assembly adding the extra code to evaluate assertions. This is a hard task to
implement because as it was mentioned in the previous section, .NET has no emit facility for
replicating code. Finally, once you have the new TrustedA you must recompile the client project
substituting A by TrustedA.
The second approach is based on the .NET interception capabilities. Under this approach to
monitor asserted types the types must derive from the BCL type ContextBoundObject.
We define an attribute type Interceptable (see code excerpt below) deriving from the BCL
attribute type ProxyAttribute. Types to be asserted must be attributed with an Interceptable
attribute. When the client code executes a new T( ) for a type T attributed with an attribute derived
from ProxyAttribute attribute the .NET CLR applies the method CreateInstance of the
ProxyAttribute the MarshalByRefObject object returned by this method will be the result of the
new T() before applying the corresponding constructor of T. So, overriding this method in our
Interceptable we can wrap an object of type T in a transparent proxy
[AttributeUsage(AttributeTargets.Class|AttributeTargets.Interface|
AttributeTargets.Struct, Inherited = true)]
public class Interceptable : ProxyAttribute {
public override MarshalByRefObject CreateInstance(Type T) {
MarshalByRefObject target = base.CreateInstance(T);
RealProxy rp = new InterceptingProxy(target, T);
return (MarshalByRefObject)rp.GetTransparentProxy();
}
}
The InterceptingProxy constructor loads a TrustedT type (if it was generated by a tool or
generated on the fly) and put a dummy object of the type AssertionEvaluator inside the proxy.
The type TrustedT will implement the following interface
interface AssertionEvaluator{
//For each method F in T we must have the corresponding methods
//for evaluate the assertions of F in TrustedT
public void Preconditions(string method, object [] parameters, T target){
//...Evaluate preconditions and invariants of method
}
public void Postconditions(string method, object [] parameters,
T target, object[]oldValues){
//...Evaluate postconditions and invariants of method
}
public object[] OldValues(string method, object [] parameters,
T target)
//...
}
Because the type InterceptingProxy derives from RealProxy then calls x.F(...) (where x
is of type T) can be intercepted by the method public IMessage Invoke(IMessage request).
So, overriding this Invoke method with the following pattern we can monitor the assertion
evaluation
public IMessage Invoke(IMessage request){
...
...obtain methodName and the array parameters from the request message
try {
dummy.Preconditions(methodName, parameters, target)
}
catch(){
...
}
object[]oldValues = dummy.OldValues(methodName, parameters, target);
...evaluate the call x.F(...) from the request message
try {
dummy.Postconditions(methodName, parameters, target, oldValues)
}
catch(){
...
}
Some Related Works

Several works shows how by using attributes in .NET we can obtain similar effects as the
Aspect Oriented Programming promotes [8, 14, 17].
Assertions were introduced in the Eiffel programming language as language constructions [10,
11, 12, 13]. Several papers intend to include assertions in Java [3, 6, 15]. Because Java has no
resources as .NET attributes, most of these works either include assertions as special comments or
extend the Java languages with new constructions.
Unfortunately the .NET Framework, and specially the .NET CLR, did not include an assertion
mechanism from the scratch. There is an Assert method in the Debug class, but this has only
debugging purposes and it is not enough to achieve the specification goal of the assertions. Some
authors [16] try to include assertions as first runtime entities into the Rotor runtime.
The eXtensible C# [4] is a C# extension including declarative assertions among other goals. At
present this assertion language is less expressive than C#AL.
Conclusions
The two proposed cases illustrate the significance of .NET resources for metaprogramming,
specially the powerful mixture between reflection and attributes.
Thanks to proposed assertion attributes, semantic information can now be embedded into
interfaces. Such approach is no so comfortably achieved without attributes. Lack of attributes is a
drawback in Java and other IDLs based technologies.
At the current state of the technology, assertions as boolean expressions (even including
quantifiers that raise the expressiveness to a predicate calculus) are not enough to specify about a
component's quality and behaviour, see [1]. We are exploring the use of attributes to express other
qualities of the software.
Attributes give developers the chance to insert metainformation in their software independently
of the source programming language. Based on attributes we have the opportunity to explore other
research areas as the specification of temporal constraints, components coordination and
synchronization in multithreading applications.
Bibliography
1. Beugnard A, Jzquel J M, Plozeau N, Watkins D, Making Components Contract Aware,
Computer, July 1999.
2. Coira J, Katrib M, Improving Eiffel Assertions Using Quantified Iterators, Journal of
Object Oriented Programming, Nov/-Dec 1997.
3. Design by ContractTM for JavaTM Using JMSAssertTM.
4. eXtensibleC# (XC#), www.resolvecorp.com
5. Fndez D, Katrib M, Pimentel E, Synchronizing Java Threads Using Assertions, Proceedings of
TOOLS 31th, Editors Jian Chen, Jian Lu, Bertrand Meyer, IEEE Computer Society, 1999.
6. iContract: The Java Design By Contract Tool,
http://people.cs.uchicago.edu/~songyanf/reserarch/contract_paper/other/icontract-
tools98usa.pdf
7. Katrib M, Martnez I, Collections and Iterators in Eiffel, Journal of Object Oriented
Programming, Vol 6, No 7, Nov/Dec 1993.
8. Ken Win Kuen, AOP An Introduction, COMP 610E 2002 Spring Software Development of E-
Business Applications. The Hong Kong University of Science and Technology
9. Meemken D. JaWA: Java with Assertions, Universitat Oldenburg,
http://theoretica.informatik.uni-oldenburg.de/~jawa/
10. Meyer B: Applying Design by Contract, Computer (IEEE), vol. 25, no. 10, October 1992, pages
40-51.
11. Meyer B: OBJECT-ORIENTED SOFTWARE CONSTRUCTION 2nd Edition, Prentice Hall,
1997.
12. Meyer B, Contracts for Components, Software Development Journal, June 2000
13. Meyer B: Eiffel: The Language, Prentice Hall, 1992.
14. Polze A, Schult W, Aspect Oriented Programming with C# and .NET
,{wolfgang.shult/andrea.polze}@hpi.uni-postdam.de
15. RSTCorp. AssertMate, http://www.rstcorp.com/, May 1998.
16. Tran N, Mingins C, Abramson D, Mikunov A, Suport for Assertions in the Rotor runtime,
www.csse.monash.edu.au/~namtt/rotor/MonashRotorProject.html
17. Vaster C, Aspect Oriented Programming and Metadata Driven Infrastructures, Microsoft
Tech Ed 03, Barcelona, Spain, July 2003.
Integrando Gesto do Conhecimento e Modelagem Organizacional

Francisco dos Santos Carvalho Jaelson Freire Brelaz de Castro
Universidade Estadual do Sudoeste da Bahia, DCE Universidade Federal de Pernambuco Cin
Vitria da Conquista (BA), Brasil Recife (PE),Brasil
(carvalho@uesb.br) (jbc@cin.ufpe.br)
Resumo
Este artigo enfoca o processo de integrao entre a Modelagem Organizacional e a Gesto do

Conhecimento. Existem vrios mtodos de apoio elicitao de requisitos. Entretanto, h uma lacuna quanto
formulao de propostas para o desenvolvimento, aquisio e aplicao do conhecimento organizacional
que possa subsidiar o trabalho de uma equipe de modelagem de requisitos organizacionais. Propomos a
tcnica denominada INTEGRATION que visa a integrao da Gesto do Conhecimento Tcnica i* [1] de
Modelagem Organizacional.
Palavras-chaves: Engenharia de Requisitos, Modelagem Organizacional, Tcnica i *, Tcnica

INTEGRATION, Gesto do Conhecimento, Memria Organizacional.
1. Introduo.
Considerando que as tcnicas de modelagem tm sua ateno central voltada para os aspectos da
funcionalidade dos sistemas e que, em sua grande maioria, esto preocupadas com o que e como fazer,
justificvel a busca de novas abordagens para o entendimento dos problemas organizacionais. Na literatura
sobre Engenharia de Requisitos existe uma lacuna relativa integrao da Gesto do Conhecimento (GC)
com a Modelagem Organizacional (MO), principalmente porque a GC uma rea recente para as
organizaes [2,3]. No geral, no h uma preocupao clara nos processos de modelagem com aspectos
inerentes capacitao (formao e uso de habilidades) dos atores organizacionais, no intuito dos mesmos
alcanarem melhorias expressivas nos processos decisrios que envolvem a consecuo de objetivos
essenciais para o desenvolvimento de sistemas de software. To pouco h nfase nos estudos quanto criao
e aproveitamento do conhecimento acumulado pela organizao. Os modelos tradicionais da Cincia da
Computao, principalmente voltados para o desenvolvimento de software e sistemas de informao, na sua
maioria esto mais preocupados em aprimorar a parte tcnica do processo de desenvolvimento de sistemas.
Muitos deles, acabam, entretanto, esquecendo de analisar o ser humano numa dimenso mais abrangente,
principalmente no que tange qualificao dos atores organizacionais para resolver problemas tcnicos e
sociais [4]. A integrao da GC com a MO visa criao de uma memria organizacional que d suporte aos
trabalhos de modelagem, que passaro a ser desenvolvidos num ambiente de maior envolvimento
interdisciplinar e acesso mais rpido aos conhecimentos do domnio da aplicao no qual o sistema previsto
ser desenvolvido.
No caso do desenvolvimento de sistema de software, a MO precisa ser uma ferramenta que

verdadeiramente contribua para que o processo de Engenharia de Requisito seja executado com alta
qualidade, de modo a desenvolver especificaes completas, consistentes, no ambguas e corretas dos
requisitos. Como afirmou Kotonya [5] os processos de Engenharia de Requisitos podem variar radicalmente
de uma organizao para outra, existindo vrios fatores que concorrem para isso, como por exemplo, a
maturidade tcnica, o envolvimento interdisciplinar, a cultura organizacional e o domnio da aplicao.
A compreenso do poder da GC para promover melhorias mais consistentes dos negcios uma forte
motivao para este artigo [6]. Propomos uma tcnica, denominada de INTEGRATION (Integrao da Gesto
do Conhecimento com a Modelagem Organizacional), que utiliza o conhecimento para auxiliar os processos
de MO. A Seo 2 apresenta a tcnica i*. A Seo 3 conceitua e mostra alguns objetivos da GC. A Seo 4
trata da tcnica INTEGRATION. A Seo 5 apresenta um Estudo de Caso. A Seo 6 trata dos trabalhos
relacionados. A Seo 7 indica sugestes para trabalhos futuros e na Seo 8 constam as concluses do artigo.
2. A tcnica i*.
Neste artigo ser inicialmente apresentada uma modelagem em i* que depois ser enriquecida com os
modelos da tcnica INTEGRATION. A tcnica do i* [1] tem objetivo de fornecer uma framework conceitual
mais rica para modelagem de processos que envolvem vrios participantes. A maioria dos formalismos
disponvel se concentra nos aspectos comportamentais do processo, mas deixam de lado as razes que esto
por detrs deles. Eles permitem a descrio dos componentes do sistema (atores) em termos de seu estado,
capacidades (processos que podem executar) e comportamento (como e quando os processos so executados),
mas no conseguem expressar as razes envolvidas nos processos (o porque). O i* fornece conceitos para
modelar e responder questes como [1]: a) Porque atores executam os processos? b) quem deseja que eles
faam isso? c) quais formas alternativas de executar um processo? d) por que os atores possuem ou recebem
informao?
A tcnica i* descreve uma configurao particular de dependncia de relacionamentos entre atores

organizacionais (Modelo de Dependncias Estratgicas - SD), bem como as razes que levam os atores
agirem em busca do alcance de um objetivo/meta (Modelo de Razes Estratgicas - SR) [1]. Os modelos do i*
so formalmente representados atravs da linguagem de modelagem conceitual Telos e representados pela
ferramenta OME [7].
Modelo de Dependncia Estratgica SD Modelo de Razes Estratgicas - SR
Figura 1- Exemplo do framework i* envolvendo os Modelos SD e SR.
Na tcnica i* [1] os participantes do processo so vistos como unidades semi-autnomas, chamadas atores,
cujo comportamento destes no totalmente controlvel ou previsvel, mas dependem um dos outros para
terem seus objetivos alcanados, tarefas executadas e recursos fornecidos. Conforme mostra a Figura 1, no
modelo SD, o ator A depende do Ator B. As razes da ao de cada ator podem ser vistas no Modelo SR,
representando que o Ator B realiza um conjunto de tarefas para atender ao Ator A. Os atores ou participantes
do processo tm liberdade de ao, dentro do contexto de restries sociais, e possuem propriedades
intencionais, tais como, objetivos, crenas, habilidades e compromissos [1,8].
As organizaes so representadas a partir da elaborao de modelos. Portanto, a MO torna-se uma tarefa
facilitadora para se chegar, gradualmente, s especificaes de requisitos, funcionais e no funcionais,
melhores e mais prximas dos requisitos das prprias organizaes [9]. A tcnica i* no s permite entender
os requisitos organizacionais que tero impactos sobre o sistema a ser desenvolvido, mas tambm permite
identificar alternativas para os vrios processos da organizao [10]. Todavia, a tcnica i* limitada para
tratar da abordagem de GC, mais notadamente da aquisio, criao, uso e evoluo do conhecimento. A
seo seguinte trata do conceito e os objetivos da GC. Exemplos do uso da tcnica i* so encontrados em
[1,4,10,11].
3. Gesto do Conhecimento (GC).
A GC um processo sistemtico de identificao, criao, renovao e aplicao dos conhecimentos que

so estratgicos na vida de uma organizao. Ela est preocupada com a representao, organizao,
aquisio, criao, uso e evoluo do conhecimento em vrias formas [2,3,12,13,18]. Para construir
tecnologias efetivas para a GC, precisa-se entender melhor como os indivduos, os grupos e as organizaes
usam o conhecimento [14,15,16]. A GC consiste em atividades focalizadas na organizao que ganha o
conhecimento de sua prpria experincia e da experincia de outros, e na aplicao desse conhecimento para
cumprir sua misso organizacional. Estas atividades so executadas de modo a envolver estratgias baseadas
na cognio para levantar o valor do conhecimento existente e para produzir o novo conhecimento [17].
Para alguns autores [2, 3, 12, 13, 18] os objetivos que deram origem gesto de conhecimento so: (i)
formular uma estratgia organizacional para o desenvolvimento, aquisio e aplicao do conhecimento; (ii)
implantar estratgias orientadas ao conhecimento; (iii) promover a melhoria contnua dos processos de
negcio, enfatizando a gerao e utilizao do conhecimento; (iv) monitorar e avaliar os resultados da
aplicao do conhecimento; (v) reduzir os tempos dos ciclos de desenvolvimento de novos produtos, de
melhoria de produtos j existentes e a reduo do desenvolvimento de solues para problemas; (vi) reduzir
os custos associados repetio de erros.
A GC uma disciplina em constante evoluo que vem sendo adotada em diversas reas, inclusive no
desenvolvimento de sistemas de software. Dingsyr [19] cita alguns estudos de casos da aplicao da GC na
rea de Engenharia de Software: NASA Software Engineering Laboratory, Daimler Chrysler, Ericsson
Software Tecnology, Australian Telecom Company, ICL High Performance Systems, ICL Finland, Telenor
Telecom Software.
Na seo seguinte apresentaremos a tcnica INTEGRATION, destacando por que conveniente integrar a
GC com a MO.
4. A tcnica INTEGRATION.
A tcnica INTEGRATION (Integrao da Gesto do Conhecimento com a Modelagem Organizacional)

apresenta indicaes para construo de uma estrutura que viabilize a captura, armazenamento, disseminao,
reuso, transformao e criao de novos conhecimentos. Desta forma, a tcnica INTEGRATION fornece a
equipe responsvel pela modelagem de requisitos um conjunto de informaes que potencializem a
compreenso das relaes de dependncias, objetivos, dos objetivos-soft, das tarefas e dos recursos, previstos
nos modelos de Dependncias Estratgicas e Razes Estratgicas da tcnica i* [1]. A tcnica i* mostra
apenas a representao grfica entre os atores. A INTEGRATION vai alm, pois utilizada trs submodelos
para especificar atributos dos atores, objetivos, recursos e solues reutilizveis. A INTEGRATION utiliza o
conhecimento para auxiliar os processo de MO; contribui para que os objetivos estratgicos estejam
relacionados com as vises dos atores, suas posies e papis desenvolvidos; trata do conhecimento pertinente
a uma situao atual e uma situao futura que se pretende alcanar; lida tanto de sistemas humanos como
tambm componentes tecnolgicos; pode ser aplicada em todas as organizaes que queiram implantar uma
infra-estrutura mnima para ter a GC como base de apoio aos processos decisrios, inclusive aqueles inerentes
ao desenvolvimento de sistemas de software.
4.1 Objetivos gerais da tcnica INTEGRATION.
Os principais objetivos gerais da tcnica INTEGRATION so: i) aproveitar a aprendizagem organizacional

para ser aplicado na melhoria dos processos de trabalho; ii) manter um "repositrio" de conhecimento que
auxilie a equipe de modelagem a compreender melhor as mudanas de objetivos e de atores organizacionais;
iii) melhorar a comunicao entre usurios e desenvolvedores; iv) aprimorar o processo de descrio de
objetivos de negcio e de papis dos atores que foram modelados em i*.
A INTEGRATION aponta para criao de uma Memria Organizacional [6], que auxilie nos processos de
MO da tcnica i* e possa ser estendida para processos mais amplos, de acordo com o interesse das
organizaes. Uma memria organizacional envolve a representao do conhecimento e informao em uma
organizao [20,21,14,16]. Ela pode incluir o conhecimento sobre objetivos, planos, produtos, processos de
produo, clientes, estratgias de marketing, resultados financeiros, experincias, percia na resoluo de
problemas, etc. Pode incluir, tambm, bases de dados, documentos eletrnicos, relatrios, requisitos de
produto, etc. A Memria Organizacional um repositrio do conhecimento e o know-how do conjunto dos
indivduos que trabalham em uma organizao, tendo por finalidade preservar o conhecimento, a fim de
permitir a socializao, uso, reuso, inovao e transformao do mesmo [22,23, 24, 30].
Na seo seguinte apresentamos diretrizes e a estrutura para a tcnica INTEGRATION.
4.2 A INTEGRATION: Estrutura e Diretrizes.
A Figura 2 mostra as bases principais da tcnica INTEGRATION, que composta de Processos

Organizacionais para Criao do Conhecimento, Locais do Aprendizado Organizacional, Tipos de Capital
Intelectual, e Alavancas de Suporte aos Processos Organizacionais.
Nas subsees 4.2.1, 4.2.2 e 4.2.3 sero tratadas em detalhe as quatro bases da tcnica INTEGRATION.
Em seguida descrevemos, na subseo 4.2.4, os modelos que fazem parte da tcnica INTEGRATION e na
Subseo 4.2.5 apresentamos as diretrizes para adoo da proposta.
Processos Organizacionais para Criao do Conhecimento

Captura e Criao Empacotamento e Distribuio e Transformao e
de Conhecimento Armazenamento Aplicao de Inovao de
(Etapa 1) (Etapa 2) Conhecimento Conhecimento
(Etapa 3) (Etapa 4)
Locais do Tipos de
Aprendizado Capital
Organizacional Modelagem Intelectual
Organizacional
Individual Capital Humano
Grupal (Gesto de
Organizacional Competncias)
Trabalho em rede Modelo de Modelo de Modelo de Solues
Reutilizveis Capital
Objetivos (MOb) atores (MAt) (MSRe) Estrutural
Capital
Relacional
- Explorao -Externalizao - Uso do - Explorao de novos

- Elicitao (Criao de Conhecimento conhecimentos
(Seleo e Captura) Conceitos) - Internalizao - Socializao do
- Anlise - Codificao (Justificao de conhecimento
- Negociao (Representao do Conceitos) -Combinao do
- Constituio de conhecimento) - Meio Eletrnico para conheciento para
Equipe de Trabalho - Escolha de Transmisso do Construo de Arqutipo
- Criar condies estrutura para Conhecimento - Adio da inovao e
para aprendizado recuperao da (Intranet e Internet} criatividade ao trabalho
informao - Suporte Decises - Externalizao (Criao
- Solues - Engajamento dos de novos conceitos)
Reutilizveis dirigentes e usurios - Manuteno e Evoluo
(lies aprendidas) - Identificao e da Memria Corporativa
avaliao dos recursos
intelectuais
Alavancas de Suporte aos Processos Organizacionais
Figura 2 - Macro-viso da INTEGRATION
Na Figura 2 so citadas as quatro etapas que compem os Processos Organizacionais para Criao do
Conhecimento, a saber: (i) Captura e Criao de Conhecimento (Etapa 1); (ii) Empacotamento e
Armazenamento de Conhecimento (Etapa 2); (iii) Distribuio e Aplicao de Conhecimento (Etapa 3); e (iv)
Transformao e Inovao de Conhecimento (Etapa 4). A Figura 2 tambm mostra quais so as Alavancas de
Suporte para viabilizar cada uma das quatro etapas mencionadas.
4.2.1 Processos Organizacionais para Criao do Conhecimento e as Alavancas de Suporte.
As quatro etapas que fazem parte dos processos organizacionais so descritas a seguir:
4.2.1.1 Captura e Criao de Conhecimento (Etapa 1).
Nesta etapa a organizao explorar as fontes e produzir conhecimentos pela converso dinmica e
externalizao de seu conhecimento tcito, ou seja, aquele que no tramissvel em linguagem formal e
sistemtica [3]. Visa-se selecionar, estruturar e organizar o conhecimento existente, tratando informaes no
fornecidas pela tcnica i*. Nesta fase o enfoque principal ser capturar e criar conhecimento especfico sobre
os objetivos e atores organizacionais. Para a etapa 1, destacam-se as seguintes Alavancas de Suporte aos
Processos Organizacionais:
1. Explorao - A explorao do conhecimento deve ser realizada de modo participativo, envolvendo os ambiente interno
e externo organizao. A criao de conhecimento deve ocorrer por converso (transformao) e compartilhamento do
conhecimento tcito e explcito da organizao. O conhecimento tcito pessoal, especfico ao contexto, difcil de ser
formulado e comunicado. J o conhecimento explcito o transmissvel em linguagem formal e sistemtica.
2. Elicitao - Proceder a elicitao de conhecimento (seleo e captura). A elicitao objetiva conhecer melhor a
dinmica organizacional, a identificar necessidades, a partir de consulta aos representantes de cada grupo de usurios
(atores) , de documentos do domnio, de conhecimento do domnio e de pesquisa de mercado.
3. Anlise - Proceder anlise de conhecimento, isto , descobrir problemas nas informaes que podero gerar
conhecimento, como por exemplo, informaes imprecisas, redundantes.
4. Negociao - Realizar negociao de conhecimento, visando dar soluo para os conflitos entre usurios, preservando
os interesses gerais de todos aqueles envolvidos no processo de criao do conhecimento.
5. Constituio de Equipe de Trabalho Dever existir uma Equipe de Trabalho responsvel pela implantao da GC,
identificando conhecimentos existentes e novos conhecimentos, bem como sendo responsvel pela seleo e captura do
conhecimento. Outra Equipe que dever ser constituda para realizar os trabalhos de MO.
6. Criar condies para o aprendizado - Devero ser criadas condies para o aprendizado, como por exemplo, viabilizar
a interao organizacional, dar maior autonomia aos funcionrios [25,26].
Alavancas de Suporte aos Processos Organizacionais para viabilizar a Captura e Criao de
Conhecimento (etapa 1)
4.2.1.2 Empacotamento e Armazenamento de Conhecimento (etapa 2).
Nesta etapa sero selecionadas as metodologias e tcnicas para codificao e armazenamento do

conhecimento, visando o uso de solues reutilizveis devidamente classificadas e indexadas. A Equipe de
Trabalho responsvel pela GC - constituda na etapa anterior - dever identificar e criar conceitos para
representar o conhecimento em um sistema computadorizado. Para tanto, mister se faz escolher tcnicas para
codificao e representao do conhecimento, escolher ontologias apropriadas ao contexto [14,15,16,21,22] e
definir tecnicamente qual o tipo de estrutura computacional suportar a Memria Organizacional a ser
construda. tambm nesta etapa que so identificadas e armazenadas as Solues Reutilizveis. Destacam-se
as seguintes Alavancas de Suporte aos Processos Organizacionais:
1.Externalizao (Criao de Conceitos) - A externalizao um processo de articulao do conhecimento tcito em

conceitos explcitos, expresso na forma de metforas, analogias, conceitos, hipteses ou modelos. A externalizao a
chave para a criao do conhecimento, pois cria novos conceitos a partir do conhecimento tcito.
2.Codificao (Representao do Conhecimento) - Dever ocorrer codificao e representao do conhecimento para
facilitar a difuso do conhecimento. No nosso caso, estendemos os modelos da tcnica i*.
3.Escolha de estrutura para recuperao da informao Identificar problemas gerais que podero estar relacionados
com o processo de busca de informaes na Memria Organizacional. Alguns problemas podem surgir, tais como: (i)
modo do usurio expressar seus pedidos; (ii) modo que o usurio poder navegar num sistema de hipertextos que
disponibilize a informao solicitada; (iii) forma de armazenamento de informaes; (iv) modo de filtragem da
informao a ser recuperada,
4.Solues Reutilizveis Devem ser classificadas e indexadas as informaes e organizadas na Memria Organizacional
as solues que a organizao considerar importantes para reuso.
Alavancas de Suporte aos Processos Organizacionais para viabilizar o Empacotamento e
armazenamento de conhecimento (etapa 2)
4.2.1.3 Distribuio e Aplicao de Conhecimento (etapa 3).
As equipes de modelagem e de GC podero ter acesso Memria Organizacional [20,22] que servir
como um mecanismo de apoio para implementao de solues organizacionais [21,23] e melhorias de
prticas de trabalho, bem como possibilitar uma melhor definio dos objetivos estratgicos e tticos [14,18].
Nesta etapa ser compartilhado conhecimento dentro de uma organizao por grupos funcionais diferentes,
que podem estar localizados muitas vezes em reas geogrficas diferentes. O conhecimento tambm pode ser
transferido entre organizaes por alianas inter-organizacionais e parcerias. Na aplicao de conhecimento,
busca-se que a organizao coordene suas formas diferentes de conhecimento na produo de servios
demandados interna ou externamente. Para a etapa 3, destacam-se as seguintes Alavancas de Suporte aos
Processos Organizacionais:
1.Uso do Conhecimento - A utilizao do conhecimento dever ser realizada de acordo com as necessidades da
organizao.
2.Internalizao do Conhecimento (Justificao de Conceitos) O processo de criao do conhecimento comea com o
compartilhamento do conhecimento tcito (etapa 1), passa pela converso conhecimento tcito em explcito (etapa 2). Na
etapa 3, o conceito criado de conhecimento precisa ser justificado, ou seja, a organizao dever determinar se realmente
vale a pena perseguir e adotar o novo conceito de conhecimento.
3.Meio Eletrnico para Transmisso do Conhecimento (Intranet e Internet) Cada ator organizacional poder prestar as
informaes, inclusive por uso de intranet ou internet.
4.Suporte a Decises Os conhecimentos disponibilizados na etapa 3 podero contribuir significativamente para apoiar os
processos decisrios da organizao.
5.Engajamento dos dirigentes e usurios Recomenda-se que os dirigentes e usurios estejam engajados no processo de
aplicao do conhecimento, pois a melhoria nas prticas adotadas para atingir os objetivos organizacionais depende de
uma participao ativa dos mesmos.
6.Identificao e avaliao dos recursos intelectuais - Deve-se escolher um modo simples e eficiente para medir, avaliar e
administrar os recursos intelectuais da organizao. Recomenda-se saber quem so os recursos, onde esto, quanto so,
quais as habilidades dos mesmos.
Alavancas de Suporte aos Processos Organizacionais para viabilizar a Distribuio e aplicao de
conhecimento (etapa 3)
4.2.1.4 Transformao e Inovao de Conhecimento (etapa 4).
Cada aplicao dos contedos do repositrio de conhecimento poder oferecer informaes e lies. Com
base na experincia dos usurios do repositrio de conhecimento poder-se- aprimorar o conhecimento
organizacional, permitindo melhoria do processo de modelagem, bem como das prticas de trabalho. Para a
etapa 4, destacam-se as seguintes Alavancas de Suporte aos Processos Organizacionais:
1.Explorao de novos conhecimentos De modo participativo, explorar o conhecimento interno e externo organizao,
compartilhando os conhecimentos tcitos e explcitos [3].
2. Socializao do conhecimento - Os indivduos devem interagir uns com os outros atravs de dilogos pessoais.
3.Combinao do Conhecimento para Construo de Arqutipo Arqutipo um modelo, um padro, um prottipo.
Para a nossa proposta significa transformao do conceito de conhecimento em algo tangvel ou concreto. Por exemplo,
um arqutipo pode ser considerado um prottipo no caso do processo de desenvolvimento de um novo produto.
4. Adio da inovao e criatividade ao trabalho - Para o sucesso no processo de gerao de novos conhecimentos, mister
se faz incluir a inovao e a criatividade como fatores essenciais das prticas de trabalho. necessrio implantar na
organizao um estilo gerencial que incentive aos funcionrios a descobrir novas maneiras de realizar o trabalho e
melhorar os servios e produtos finais [27].
5. Externalizao Para a etapa 4 a externalizao buscar novamente articular o conhecimento tcito, transformando-o
em conhecimento de conceitos explcitos, visando criar novos conhecimentos, adicionando, sempre que possvel, a
inovao.
6. Manuteno e Evoluo da Memria Organizacional - Os problemas ligados adio de novos conhecimentos, de
remoo ou de modificao do conhecimento obsoleto, problemas de coerncia de uma extenso cooperativa da Memria
Organizacional devem ser analisados. Outros problemas como conflitos entre pessoas, falta de motivao, falta do tempo
e problemas tcnicos tambm deve ser cuidadosamente analisados. A manuteno e evoluo do conhecimento deve ser
uma atividade contnua executada em cooperao prxima com os usurios que podem fazer as sugestes de
melhoria/update.
Alavancas de Suporte aos Processos Organizacionais para viabilizar a Transformao e inovao de
Conhecimento (Etapa 4)
Tendo apresentado os processos organizacionais para criao do conhecimento passamos agora para
examinar os Locais do Aprendizado Organizacional e Tipos de Capital Intelectual (Figura 2).
4.2.2 Locais do Aprendizado Organizacional.
Os Locais do Aprendizado Organizacional podem ocorrer em quatro nveis, a saber: individual, grupal,
organizacional (rotinas organizacionais) e trabalho em rede (parcerias inter-organizacionais, projetos
integrados entre unidades situadas em diferentes reas geogrficas etc.). O aprendizado organizacional base
para criao de novos conhecimentos. Alguns elementos contribuem para a criao do conhecimento, tais
como: experincias dirias, curiosidade, experincia dos clientes/pblico, experincia de outras organizaes
e o enfrentamento de crises/problemas.
4.2.3 Tipos de Capital Intelectual.
Com o passar do tempo, a organizao acumula uma coleo de conhecimento e capacidades, aqui
denominada de Capital Intelectual da organizao (vide Figura 2), o qual subdividimos em capital humano
(aspectos humanos/capacidades), capital estrutural ou organizacional (inclui equipamentos, materiais,
tecnologia, rotinas organizacionais etc) e capital relacional (originrio da agregao de valor nas relaes
com os outros usurios/clientes/mercado) [25,26].
A seguir iremos descrever a nossa proposta que integra GC com a MO.
4.2.4 Modelos da Tcnica INTEGRATION.
A tcnica INTEGRATION composta de trs sub-modelos: o Modelo de Objetivos (MOb), o Modelo de

Atores (MAt) e o Modelo de Solues Reutilizveis (MSRe). Os modelos contm informaes que sero teis
para apoio aos trabalhos de MO, na medida que oferecem um conhecimento mais aprimorado acerca dos
objetivos e atores organizacionais, seus problemas e alternativas para soluo dos mesmos.
Modelagem
Organizacional
Modelo de Objetivos Modelo de atores Modelo de Solues

(MOb) (MAt) Reutilizvieis (MSRe)
Nome do Objetivo: Nome do Ator: Nome da Soluo Reutilizvel:

Objetivo: Posio: rea de aplicao:
Finalidade: Papel: Nome(s) Autor (es):
Situao Atual:
Situao Futura:
Motivaes: Descrio de como resolver
Tipo Objetivo: (Estratgico, Ttico, Competncias (habilidades x problema:
Operacional) Posio): Recomendaes para auxiliar as aes
Macro-objetivos relacionados: Competncias (habilidades x dos atores:
Estratgias relacionadas: Papel): Idias de aperfeioamento da soluo
Ameaas: Priorizao dos objetivos traados Documentos relacionados soluo;
Pontos Fortes: para a unidade: Exemplo de aplicabilidade da soluo;
Atores Envolvidos:
Perodo Execuo:
Ordenamento de Tarefas: Tipo:
Problema a ser resolvido: Foco de Viso: Grau de complexidade:
Causa do Problema: Prioridade do ator na escolha de Data da utilizao:
Oportunidade: objetivos-soft: Palavra-Chave:
Grau de Prioridade: Unidade onde atua:
Objetivos co-relaconados: Tempo de Servio na Posio:
Legislao Envolvida:
Recursos Financeiros:
Recursos Materiais:
Recursos Tecnolgicos:
Recursos Informacionais
Processos Beneficiados:
Contribuio para os Macro-objetivos:
Grau de Criticidade:
Figura 3 Submodelos da INTEGRATION
A seguir apresentamos cada um dos trs submodelos da INTEGRATION:
4.2.4.1 Modelo de Objetivos (MOb)
O Modelo de Objetivos tem a finalidade de descrever os objetivos da organizao. Originalmente no i* um

objetivo modelado atravs de uma representao Oval (vide Figura 1). Agora foram adicionadas novas
informaes que no haviam sido contempladas na tcnica i*. A finalidade da extenso descrever os
objetivos da organizao junto com assuntos associados realizao destes objetivos. Utilizar-sede um
template (vide Figura 3) composto de itens considerados essenciais para complementar as informaes do i*
no que diz respeito a um objetivo. O Modelo de Objetivos descreve, essencialmente, as razes que subsidiam
outros submodelos, pois, de um modo geral, existe uma preocupao com a estrutura e a relevncia dos
processos, quando se define um objetivo organizacional. Os itens que compem o Modelo de Objetivos
devem ser formulados de acordo com o contexto a ser aplicado. Assim, a INTEGRATION flexvel, pois
permite que aos submodelos(MOb, MAt e MSRe) sejam adicionados outros itens no previstos no template
da Figura 3, possibilitando que o grupo de modelagem aprimore a expressividade e clareza do modelo.
4.2.4.2 Modelo de Atores (MAt)
O Modelo de Atores permite uma descrio mais ampla dos atores daquela apresentada na tcnica i*,
representada graficamente por Crculos (vide Figura 1) . Na INTEGRATION os papis dos atores podem ser
atribudos a agentes fsicos, unidades organizacionais ou agentes no humanos, similar a definio de atores
na modelagem da UML [28]. Uma unidade organizacional pode, por exemplo, ter o seu papel definido em
funo dos macro-objetivos estabelecidos pela organizao em determinado momento. Cada ator ter uma
responsabilidade, ou seja, uma srie de atribuies a cumprir. As responsabilidades assumidas pelos atores
organizacionais podem ser de trs tipos, a saber: a) estratgica - dizem respeito misso da organizao, suas
vises e diretrizes traadas para promover a manuteno e/ou expanso dos negcios; b) ttica - abrangem o
gerenciamento de interesses, visando cumprir o seu papel de acordo com estratgias definidas e buscando
concili-las com a sua necessria operacionalizao para consecuo dos objetivos e metas estabelecidos; c)
operacional - so relacionadas principalmente execuo das tarefas e indicam que um ator est
comprometido para executar um processo do negcio ou que um processo do negcio est atribudo a um
ator. A descrio dos atores ser completada atravs do preenchimento de um template (vide Figura 3).
4.2.4.3 Modelo de Solues Reutilizveis (MSRe)
O Modelo de Solues Reutilizveis permite organizar uma fonte de informaes para armazenamento
numa memria organizacional, contendo as experincias bem sucedidas da organizao, envolvendo tanto
conhecimentos j utilizados no ambiente de software como tambm em outros ambientes organizacionais. O
processo de identificao, organizao e armazenamento de solues reutilizveis deve ser gradual, sendo o
mais participativo possvel. As solues sero descritas conforme um template pr-definido (Vide Figura 3).
Na Figura 4 indicamos graficamente como a nossa proposta INTEGRATION est relacionada com o
Modelo de Dependncia Estratgica da tcnica i*.
+ tens do template do Modelo de Objetivos
+ tens do template do Modelo de Atores
+ tens do template do Modelo de Reutilizveis
Figura 4. Os Modelos MOb, MAt e MSRe adicionam novas informaes aos Objetivos, Atores e Recursos do
Modelo de Dependncia Estratgica da tcnica i*.
5. Estudo de Caso:
Aplicamos a tcnica INTEGRATION no processo de MO de dez organizaes do Brasil, cinco pblicas e

cinco privadas. O processo transcorreu do seguinte modo:
a) Constituio e Treinamento das Equipes de Modelagem - As equipes foram compostas de integrantes

que receberam treinamento para utilizar i* e INTEGRATION. O treinamento em cada organizao
durou 10 horas;
b) Identificao dos macro-objetivos e dos objetivos setoriais (tticos e operacionais) das organizaes
pesquisadas;
c) Gerao de Modelos de Objetivos (MOb), Modelos de Atores (MAt) e Modelos de Solues
Reutilizveis (MSRe).
d) Identificao das diretrizes da INTEGRATION que estavam sendo adotadas pelas empresas.
Como exemplo de aplicao de parte do Modelo de Objetivos, a Figura 5, notao na ferramenta OME [7],
mostra a decomposio de um dos macro-objetivos da Universidade Estadual do Sudoeste da Bahia:
Implantao da Poltica de Recursos Humanos, que deu origem ao sub-objetivo Desenvolvimento e
Implantao do Sistema de Gesto de Recursos Humanos. O nosso Estudo de Caso envolveu dirigentes e
funcionrios das organizaes pesquisadas, tendo durao total de seis meses.
Devido s restries de espao, apresentamos a seguir um exemplo contendo apenas parte do Modelo de
Objetivos (MOb), preenchido o template do Objetivo Desenvolvimento e Implantao do Sistema de Gesto
de Recursos Humanos. Tambm, devido s restries de espao, no apresentamos exemplos dos Modelos de
Atores (MAt) e Modelo de Solues Reutilizveis (MSRe).
Nome do Objetivo - desenvolvimento e Implantao do Sistema de Gesto de Recursos Humanos (SGRH).

Objetivo - melhoria dos servios burocrticos da Gerncia de Recursos Humanos (GRH), aperfeioando os
trabalhos internos e de atendimento ao pblico. A implantao do SGRH contribuir para tornar mais
eficiente o processo de acompanhamento da vida funcional de docentes, funcionrios, prestadores de servio e
estagirios, contribuindo para melhoria do processo decisrio
Finalidade oferecer um servio de melhor qualidade, segurana e de fcil acesso comunidade
universitria, disponibilizando informaes/estatsticas aos tomadores de decises.
Situao Atual quase que a totalidade das atividades da Gerncia de Recursos Humanos ainda era feita de
forma manual.
Situao Futura satisfao dos membros da comunidade universitria, principalmente, professores e
funcionrios tcnicos, em acessar, via rede (intranet e intranet) informaes sobre a sua vida funcional, sobre
o andamento de processos, bem como informaes gerais sobre a rea de recursos humanos da UESB.
Tipo de Objetivo - o objetivo em questo do tipo operacional, pois o mesmo est subordinado a um
objetivo ttico Organizao do Trabalho Interno da GRH.
Macro-objetivos relacionados o objetivo Desenvolvimento e Implantao do Sistema Informatizado de
Gesto de Recursos Humanos est subordinado ao objetivo ttico Organizao do Trabalho Interno da GRH.
Este ltimo por sua vez contribui para o alcance do Macro-Objetivo Implantao da Poltica de Recursos
Humanos, representando pela Figura 5.
Estratgias Relacionadas foram identificadas duas estratgias principais, a saber:
a) desenvolver sistema internamente, contando com a participao da equipe de desenvolvimento da Unidade
Organizacional de Informtica.
b) terceirizar o processo de desenvolvimento do SGRH, contratando programadores autnomos ou cedidos
por uma empresa especializada. A UESB optou pela primeira estratgia citada.
Figura 5 - Decomposio do Objetivo Implantao da Poltica de Recursos Humanos
5.1 Resultado do Estudo de Caso:
Buscamos com a nossa pesquisa avaliar como seria a utilizao da tcnica INTEGRATION em algumas
organizaes brasileiras. A integrao da tcnica i* com MO atravs da INTEGRATION permitiu:
Alargamento a viso das Equipes de Modelagem - Ao trmino do nosso Estudo de Caso,
constatamos nos depoimentos dos integrantes das organizaes pesquisadas que para eles a experincia foi
gratificante, tendo ocorrido um significativo aprimoramento da viso dos mesmos acerca da MO. Eles
afirmaram que o modelo proposto facilitou o entendimento sobre a organizao, principalmente no que diz
respeito aos objetivos, problemas e solues possveis para implementao. A INTEGRATION contribuiu
com a incluso de novos aspectos (vide Figura 3) que no estavam contemplados na tcnica i*.
Importncia do Modelo de Solues Reutilizveis Constatamos tambm que das organizaes
pesquisas, sete delas afirmaram que faro reuso imediato do conhecimento integrado as tcnicas de
modelagem para desenvolvimento de sistemas de software.
Dentre as vantagens identificadas na realizao do estudo de caso, destacamos a abertura no processo
comunicativo e boa receptividade por parte dos dirigentes e funcionrios das empresas pesquisadas e o
interesse por parte dos profissionais de informtica em conhecer as tcnicas i* e INTEGRATION. Dentre as
dificuldades encontradas, destacamos: a) No incio dos trabalhos foi constada falta de conhecimento da
tcnica i* b) No disponibilidade de Ferramentas no encontramos ferramentas de uso pblico que
permitisse integrar a MO e a GC.
6. Trabalhos Relacionados
No mbito internacional existem diversos grupos de pesquisa, tanto na rea de MO quanto na rea de GC.
Entretanto, a maioria deles vem trabalhando separadamente. Isto refora ainda mais a importncia do nosso
trabalho, no sentido de integrar as reas citadas.
7. Trabalhos Futuros
O nosso estudo direciona para outras pesquisas, a exemplo de: i) analisar a possibilidade de integrao da
INTEGRATION com outras metodologias de Modelagem, tais como Linguagem de Modelagem Unificada
(UML) [28], o Mtodo Bubenko [29]; ii) adicionar outros submodelos a INTEGRATION, que tratem
especificamente de regras, processos, sistemas de informaes, mantendo a estrutura geral da Integration. iii)
desenvolver uma ferramenta para suportar os modelos da INTEGRATION; iv) implementar modificaes na
ferramenta OME3 ORGANIZATION MODELING ENVIRONMENT [19], que suporta a tcnica i*, visando
incorporar as melhorias propostas pelos modelos da INTEGRATION.
8. Concluses
O presente artigo tratou da integrao da Gesto do Conhecimento Modelagem Organizacional. As

pesquisas nessa rea podem ser mais um passo no sentido de aprimorar o processo de desenvolvimento de
software, principalmente porque as atividades de Engenharia de Requisitos so difceis de serem definidas e
organizadas, j que envolvem a ligao entre as decises corporativas, baseadas no conhecimento e
experincia no negcio, e as decises inerentes ao processo de desenvolvimento de sistemas, baseadas no
conhecimento e experincia tecnolgica.
Conclumos que a tcnica INTEGRATION usa o conhecimento para auxiliar o processo de MO; serve de
apoio ao processo de definio de objetivos e papis dos atores; contribui para entender como os objetivos
esto relacionados com as vises dos atores, suas posies e papis desenvolvidos. A INTEGRATION
fornece uma base que viabilize a captura, armazenamento, disseminao, reuso, transformao e criao de
novos conhecimentos, fornecendo equipe de modelagem um conjunto de informaes que potencializem a
compreenso das relaes de dependncia e uma mais aprimorada compreenso de objetivos, dos objetivos-
soft, das tarefas e dos recursos, previstos nos Modelos de Dependncia Estratgica e de Razo Estratgica da
tcnica i*. Aponta-se para criao de uma memria organizacional que auxilie nos processos de MO da
tcnica i* e possa ser estendida para processos mais amplos, de acordo com o interesse das organizaes.
9. Referncias:
[1] Yu, E. Modelling Strategic Relationships for Process Reengineering. Phd Thesis, Computer Science
Departament. University of Toronto, 1995.
[2] Sveiby, K. A nova riqueza das naes. Rio de Janeiro: Campus, 1998.
[3] Nonaka, I. , Takeuchi, H. The Knowledge-creating company: how Japanese companies create the
dynamics of innovation. Oxford University Press, New York, 1995.
[4] Castro, Jaelson; Alencar, Fernanda, Cysneiros, Giberto, Mylopoulos, John. Integrating Organizational
Requirements and Object Oriented Modeling. In RE01. 2001.
[5] Kotonya, G. and Sommerville, I. Requirements engineering processes and techniques. John Willy &
Sons, 1998.
[6] Carvalho, Francisco S. Modelagem Organizacional e Gesto do Conhecimento: o Caso da
Universidade Estadual do Sudoeste da Bahia. Dissertao de Mestrado. Centro de Informtica.
Universidade Federal de Recife. Fev. 2003.
[7] ORGANIZATION MODELING ENVIRONMENT. Disponvel em
<http://www.cs.toronto.edu/km/ome/>. Acesso em dez 2003.
[8] Mylopoulos, J.; Chung, L. and Nixon, B. Representing and Using Non-Functional Requirements: A
Process Oriented Approach. IEEE Transaction on Software Engineering, vol. SE-18, no . 6, pp. 483-497,
June, 1992.
[9] Cysneiros, L. and Leite, J. Integrating Non-Functional Requirements into Data Modeling. 4th
International Symposium on Requirements Engineering. Limerick, Ireland. Jun. 1999.
[10] Yu, E. and Mylopoulos, J. Understanding Why in Software Process Modelling, Analysis and Design.
Sixteenth International Conference on Software Engineering. Sorrento, 1994.
[11] Yu, E. Strategic Modelling for Enterprise Integration. In Proc of the 14 th Word Congress of
International Federation of Automatic Control IFAC99. Beijing, China, July, 1999.
[12] Jurisica, I.; Mylopoulos, J. and Yu, E. Using Ontologies for Knowledge Management: An Information
Systems Perspective. Annual Conference of the American Society for Information Science, Washington,
D.C., Nov. 1999.
[13] Salazar, A. P. La Gestin del Conocimiento en las Organizaciones. Disponvel em:
<http://www.gestiondelconocimiento.com/leer.php?id=225&colaborador=apavez>, 2000.
[14] Abecker, A. Organizational Memory. Knowledge Acquisition, Integration, and Retrieval Issues, in (9)
113-124, 1999. Disponvel em: < http://citeseer.nj.nec.com/13246.html >. Acesso Ago. 2001.
[15] Breitman, K.K.; Leite, J.C.S.P. Lexicon Based Ontology Construction. 2nd. International Workshop on
Software Engineering for Large Scale Multi Agent Systems - SELMAS - ACM computer Press, Portland
Oregon, 2003.
[16] Falbo, R. A.; Natali, A. C. C. Uma Infra-Estrutura para Gerncia de Conhecimento em ODE. XVII
Simpsio Brasileiro de Engenharia de Software. Manaus, Brasil, Out de 2003.
[17] Wenig, G. Site member.aol.com. Disponvel em: <http://members.aol.com/rgwenig/homepage.htm>
2002. Acesso em ago.2002
[18] Oleary, D. and Studer, R. knowledge Management: An Interdisciplinary Approach. IEEE Intelligent
Systems, January/February, Vol. 16, No. 1, 2001
[19] Dingsyr, Torgeir. Knowledge Management in Medium-Sized Software Consulting Companies:
An Investigation of Intranet-based Knowledge Management Tools for Knowledge Cartography and
Knowledge Repositories for Learning Software Organisations. Tese de Doutorado. Department of
Computer and Information Science Faculty of Informatics, Mathematics and Electronics. Norwegian
University of Science and Technology, Jan 2002.
[20] Prasad, M.V.N. and PLAZA, E. Corporate Memories as Distributed Case Libraries. Proc. of
KAW'96, Banff, Alberta,Canada, November 9-14, p. 40-1 40-19, 1996.
[21] Abecker, A. et al. Towards a Technology for Organisational Memories. IEEE Intelligent Systems,
1998, 13(3) pp. 30-34.
[22] Euzenat, J.Corporate memory through cooperative creation of knowledge bases and hyper-
documents.In B. Gaines, M. Musen eds, Proc of KAW'96, Banff, Canada, November, pp. 36-1 36-18, 1996.
[23] Pomian, F. Mmoire d'entreprise, techniques et outils de la gestion du savoir. Ed Sapientia, 1996.
[24] Stein, E. and Zwass, V. Actualizing Organizational Memory with Information Systems. Information
Systems Research 6 (2), 1995.
[25] Garvin, D. Building a Learning Organization. In Harvard Business Review on Knowledge
Management. Harvard Business School Press, 1998.
[26] Senge, P. The Fifth Discipline: The Art and Practice of the Learning Organization. London: Random
House, 1990.
[27] Drucker, P. F; Dorothy L, Susan, S., Brown, J.S., Garvin, D. Harvard Business Review on Knowledge
Management (Harvard Business Review Series). Harvard Business School Press.Boston,1998. .
[28] Grady Booch et al. The Unified Modeling Language User Guide. Addison-Wesley, 2002.
[29] Bubenko, J.A. and Kirikova, M. Software requirements acquisition through enterprise modeling.
Stockholm University, Swende, 1994.
[30] Fiorini, S. T.; Leite, J.C.S.P, Lucena, C J. P. Process Reuse Architecture. CAiSE'01 The 13th
Conference on Advanced Information Systems Engineering, Interlaken, Switzerland, June, 2001.
Ferramenta de Inspeo de Requisitos de Software em Ambiente Web
Gustavo A. Gonzalez Briones - Tereza Gonalves Kirner

Programa de Ps-Graduao em Cincia da Computao
Universidade Metodista de Piracicaba So Paulo Brasil
e-mail: {gustavo, tgkirner}@unimep.br
Abstract
This paper focuses on the inspection of software requirements artifacts, employed as a best practice for
detecting defects on these artifacts, aiming to improve the quality of the software products. The main
objective of the paper is to present the PORTALIS tool, which has been developed, as part of a research
project, to support the inspection process Functional aspects and implementation issues of the tool are
described, as well as its usefulness and possible extensions are pointed-out.
1. Introduo.
A inspeo tem como objetivo avaliar artefatos de software, detectando defeitos que devero ser
posteriormente removidos ou corrigidos. O mtodo de inspeo foi proposto inicialmente por Fagan [3, 4],
sendo aprimorado, ao longo do tempo, por outros autores [2, 7]. Tradicionalmente, o processo de inspeo
tem, como elemento chave, sesses ou reunies nas quais especialistas trabalham em conjunto na deteco de
defeitos incorporados nos artefatos analisados. Como exemplos de artefatos de software passveis de serem
inspecionados, destacam-se: Documentos de Requisitos de Software; Especificaes de Requisitos
expressadas em uma linguagem ou mtodo; Documento de Projeto de Software; Cdigo do Software em
determinada linguagem de programao; etc.
Uma ferramenta para apoiar a inspeo de artefatos de software contribui para melhorar a qualidade das
inspees realizadas, alm de minimizar os custos decorrentes do planejamento, preparao e realizao de
inspees. Alm disso, se a ferramenta funcionar no ambiente da Internet, as reunies de inspeo (ou parte
delas) podero ser realizadas distncia, eliminando dificuldades decorrentes de disperso geogrfica da
equipe de inspeo, incompatibilidades de horrios e custos de viagens.
O presente artigo discute aspectos de desenvolvimento da ferramenta PORTALIS, cujo objetivo apoiar a
realizao de inspeo de artefatos resultantes da etapa de engenharia de requisitos. Esta etapa compreende as
primeiras atividades do processo de desenvolvimento de software, incluindo as fases de anlise de requisitos e
de especificao de requisitos do sistema de software considerado. O emprego da inspeo nas fases iniciais
do ciclo de desenvolvimento do software plenamente justificvel, uma vez que, quanto mais cedo um
defeito detectado, mais fcil, rpida e econmica ser a sua remoo [5].
A seo 2 artigo apresenta o processo de inspeo de software assumido no presente trabalho. A seo 3
detalha a ferramenta desenvolvida para apoiar a inspeo de artefatos resultantes da engenharia de requisitos
de software. A seo 4 contm as concluses do trabalho, seguindo-se algumas referncias sobre o assunto.
2. Processo de inspeo de software.

Neste trabalho, o processo de inspeo seguido levou em conta os estudos e experimentos, como os
relatados em [2, 3, 4, 7]. Tal processo caracterizado por: (a) um conjunto de etapas inter-relacionadas,
responsveis pelo planejamento e preparao da inspeo, deteco de defeitos no artefato considerado,
eliminao dos defeitos e avaliao dos resultados obtidos; (b) uma equipe responsvel por efetuar a
inspeo, composta por 4 a 6 profissionais, que desempenham papis especficos, como administrador,
moderador, inspetor e autor/cliente; (c) o artefato de software que ser inspecionado; e (d) recursos, como
documentos e formulrios, alm de uma infraestrutura de suporte realizao da inspeo.
As etapas da inspeo so resumidas a seguir.
Planejamento. Destina-se organizao da inspeo e sua aplicao em um determinado ambiente e

artefato. Nesta etapa, so selecionados os materiais referentes ao artefato a ser inspecionado,
elaborado um cronograma detalhado para realizao da inspeo. Como resultado da etapa,
preparado um Relatrio do Planejamento da Inspeo.
Preparao. Tem por objetivo tomar as providncias operacionais necessrias conduo da inspeo.
A etapa inclui a definio da equipe de inspeo, a obteno do documento referente ao artefato a ser
inspecionado, a elaborao de formulrios e outros recursos necessrios, bem como a distribuio
desses recursos entre os integrantes da equipe. Como resultado da etapa, tem-se a gerao dos
Documentos e Formulrios que subsidiaro a inspeo.
Deteco de Defeitos. Visa detectar defeitos no artefato de software. Nesta etapa, so realizadas as
reunies da equipe de inspeo, de acordo com determinada tcnica de leitura. Os defeitos detectados,
devidamente caracterizados e detalhados, comporo a Lista de Defeitos, resultante da etapa.
Eliminao dos Defeitos. Visa corrigir ou eliminar os defeitos constantes da Lista de Defeitos. Isso
requer a atuao do Autor ou Cliente, que pode contar com a participao do Moderador da equipe de
inspeo. O resultado desta etapa o Relatrio de Correes efetuadas.
Avaliao da Inspeo. Tem o objetivo de analisar os resultados propiciados pela inspeo, como
tambm acompanhar as correes executadas. Esta etapa envolve a participao do Administrador, do
Autor e do Moderador, gerando o Relatrio Final da Inspeo.
3. Ferramenta de inspeo de requisitos.
3.1. Objetivo.
A ferramenta PORTALIS (PORTAL da Inspeo de Software) , apresentada neste trabalho, visa fornecer
suporte realizao da inspeo de artefatos de software [1]. Trata-se de uma ferramenta para o ambiente
Web, desenvolvida como parte de um projeto de pesquisa que engloba o estudo de mtodos e tcnicas de
inspeo de software, alm da realizao de experimentos, no contexto da engenharia de requisitos [6]. O
foco atual da ferramenta apoiar a inspeo de Documentos de Requisitos de Software [5] e a inspeo de
especificaes expressadas em Unified Modeling Language (UML) [8].
3.2. Usurios.
A ferramenta atende s seguintes classes de usurios: (a) Administrador, cuja funo gerenciar o portal,
ficando sob sua responsabilidade as tarefas de manuteno dos cadastros de projetos, inspetores e
autores/clientes, alm de manuteno do banco de dados da ferramenta, incluindo classificaes de defeitos,
tcnicas de inspeo e controle de inspees; (b) Autor do sistema ou artefato inspecionado, que pode ser uma
pessoa fsica ou jurdica, interessada em que seu projeto seja inspecionado; (c) Inspetor, que o profissional
responsvel pelas inspees nos projetos cadastrados no PORTALIS; (d) Moderador, que um inspetor
responsvel por conduzir o processo de inspeo; e (e) Visitante, que inclui toda pessoa que visita o
PORTALIS, em busca de informaes gerais sobre inspeo ou especficas sobre projetos.
3.2.1. Viso do Administrador. O Administrador do PORTALIS responsvel pela manuteno dos

seguintes cadastros e informaes, necessrios para o funcionamento da ferramenta:
Tipos e Classificaes de Defeitos. Compreendem classificaes utilizadas para caracterizar os

defeitos detectados atravs das inspees. Tais classificaes, alm de indicar o qual o defeito
encontrado em determinado artefato, tambm indicam em que parte do artefato o defeito foi
encontrado, qual o seu grau de severidade, etc.
Tipos de Documentos. Compreendem os tipos de documentos que sero (ou foram) alvo de inspees.
Atualmente, como a ferramenta atende engenharia de requisitos, tais documentos incluem o
Documento de Requisitos de Software DRS [5], a Descrio do Sistema e os diferentes Diagramas
da UML (Diagrama de Casos de Uso, Diagramas de Classes, Diagramas de Seqncia, etc. [8]).
Tcnicas de Leitura. Incluem as tcnicas de leitura indicadas para a inspeo de software. Nesta
primeira verso, o PORTALIS disponibiliza as tcnicas de Checklist, Cenrios e Perspectivas, para
inspeo de DRS (ver [5, 7]) e as tcnicas de inspeo de Especificaes em UML (ver [8]).
Cadastros de Inspetores, Autores/Clientes e Projetos de Inspeo. A manuteno destes cadastros

permite o monitoramento das inspees que esto em andamento ou que j foram concludas.
3.2.2.Viso do Autor/Cliente. necessrio que o Autor fornea as informaes necessrias sobre o projeto
ou artefato que est sendo inspecionado, incluindo:
Identificao Pessoal. Ao acessar o PORTALIS, o Autor dever efetuar seu cadastro e registro um
login e senha para os acessos restritos ao sistema.
Identificao do Projeto. Aps acesso ao sistema, o Autor dever cadastrar o projeto ou artefato que
ser inspecionado. Neste cadastro, dever ser indicado se as informaes sobre o projeto em questo
so pblicas ou restritas equipe de inspeo.
Identificao da Documentao. Aps o cadastro do projeto, o Autor dever identificar claramente

cada documento que deseja ser inspecionado, enviando tais documentos ao PORTALIS.
Incio da Inspeo. Aps fornecer todas as informaes necessrias sobre o projeto ao PORTALIS, o
Autor poder indicar que o projeto j pode ser inspecionado. A partir deste momento, o Administrador
ter condio de certificar um Moderador, disparando, assim, a composio da equipe de inspeo que
dar prosseguimento ao processo de inspeo.
Processos. O Autor ter sua disposio, uma relao com os seus projetos cadastrados e o status de
cada um deles. Para os processos abertos ou em andamento, o Autor dever fornecer a documentao e
detalhamento do projeto, podendo tambm visualizar o nome dos inspetores. Para os processos
concludos, o Autor poder visualizar todas as informaes correspondentes.
3.2.3. Viso do Inspetor. Para participar do PORTALIS, como Inspetor, um profissional da rea necessita
passar pelas seguintes exigncias:
Identificao Pessoal. O profissional deve efetuar um cadastro, informando dados pessoais,

disponibilidade para atuar em equipes de inspeo, rea de especialidade e nvel de experincia em
inspeo de software. De posse destas informaes, o sistema poder listar os inspetores disponveis,
cabendo ao Administrador aprovar equipes de inspeo e nomear os Moderadores.
Participao de Inspees. Aps a seleo do Administrador, cada Inspetor recebe, por e-Mail, um
convite para participar em uma Inspeo e, caso este tenha interesse, dever acessar o PORTALIS e
aceitar o convite. Ao acessar o PORTALIS, o Inspetor ter sua disposio a documentao do projeto
para que seja iniciada a Inspeo.
As Figuras 1, 2 e 3 mostram telas constantes da viso do administrador e do inspetor. Uma descrio

detalhada da ferramenta PORTALIS apresentada em [1].
Figura 1. Exemplo de tela do administrador
Figura 2. Exemplo de tela do inspetor
Figura 3. Exemplo de tela do inspetor
3.3. Inspeo de software atravs do PORTALIS.
Uma vez selecionado para participar de uma equipe de Inspeo, o Inspetor poder acessar a ferramenta e
visualizar as suas atividades, tendo disposio as trs reas de trabalho descritas a seguir.
rea Informativa. Corresponde s opes de consulta s informaes detalhadas do projeto ou

artefato a ser inspecionado e documentao correspondente. O Inspetor poder, assim, ler a
descrio fornecida pelo Autor/Cliente sobre o projeto e acessar os documentos, podendo efetuar o
download de documentos e a impresso dos mesmos.
rea Interativa. Compreende as funes de comunicao com os integrantes da equipe de Inspeo e

com o Autor/Cliente, incluindo os seguintes recursos:
- Quadro de Discusso. Tem funo semelhante aos Fruns de Discusso da Internet, porm com
temas de discusso j definidos, versando acerca de comentrios e perguntas sobre o projeto em
geral ou sobre um determinado documento.
- Chat. O Inspetor poder estabelecer uma conversa com outro Inspetor ou mesmo com o Autor, caso
estes estejam conectados ao PORTALIS naquele instante.
- e-Mail. A funo principal do e-Mail a de enviar mensagens curtas, contendo informativos,

convocaes ou lembretes, avisando o Inspetor ou Autor que existem novas informaes no
sistema para serem consultandas.
rea de Inspeo. Destina-se exclusivamente aos trabalhos de inspeo, incluindo o acesso aos
seguintes recursos:
- Tcnicas de Leitura/Inspeo. A ferramenta disponibiliza as tcnicas de Checklist, Cenrios e

Perspectivas, assim como as Tcnicas de Leitura Horizontais e Verticais para inspeo de
especificaes em UML.
- Incluso de Defeitos. A ferramenta oferece formas de caracterizao e classificaes de defeitos,

comumente empregadas na inspeo de artefatos da engenharia de requisitos. Sendo assim, ao
inspecionar determinado documento, o Inspetor, ao detectar um defeito, servir-sede um menu
para escolha do tipo e classificao do defeito encontrado.
- Lista de Defeitos. Os defeitos identificados pelo Inspetor vo sendo listados na tela do computador,
para acompanhamento. Caso seja necessrio, o Inspetor poder editar os defeitos j listados para
eventuais correes ou alteraes.
- Relatrio Final. Este relatrio consiste em um documento, contendo a relao de todos os defeitos
encontrados, separados por documento correspondente e por Inspetor. O relatrio estar disponvel,
para consulta, para todos os integrantes da equipe de Inspeo, assim como para o Administrador.
Aps a aprovao pelos integrantes da equipe, o Relatrio Final ser encaminhado ao Autor.
3.4. Implementao da ferramenta.
A ferramenta PORTALIS foi implementada para executar via Internet. Entre as diversas linguagens e
bancos de dados disponveis, escolhido o PHP como linguagem de desenvolvimento, o MySQL como banco
de dados, o Linux como plataforma bsica da estrutura do servidor e o Apache como servidor de Internet.
Para a escolha destes softwares no desenvolvimento da ferramenta, foram levados em considerao diversos
aspectos, entre eles o custo, portabilidade e desempenho. Relacionado questo do custo, a idia a de
desenvolver uma ferramenta apenas com software cuja distribuio seja gratuita, sendo que a prpria
ferramenta tambm ser disponibilizada para utilizao livre [9].
Entre os recursos disponveis, adotados nesta ferramenta, destaca-se o acesso ao sistema via Browser
(Internet Explorer, NetScape ou similar), a troca de mensagens eletrnicas (e-Mail ), a troca de mensagens
pelo sistema (Frum) e conversas on-line (Chat).
O PORTALIS destina-se, inicialmente, a professores e alunos de graduao e de ps-graduao. Em um

segundo momento, aps um perodo de testes com o uso da ferramenta em um ambiente controlado, pretende-
se disponibilizar a ferramenta na Internet, para profissionais interessados.
4.Concluso.
Este trabalho teve por objetivo apresentar a ferramenta PORTALIS, desenvolvida para apoiar o processo
de inspeo de software. A ferramenta funciona em ambiente Web, agregando funcionalidades da Internet e
procedimentos especficos da inspeo de software. As contribuies do PORTALIS justificam plenamente
seu desenvolvimento e utilizao, podendo-se destacar:
Centralizao da documentao e dos resultados obtidos, possibilitando que todas as informaes

obtidas ao logo do processo de inspeo sejam adequadamente armazenadas, para consultas, emisso
de relatrios e anlises necessrias;
Agilizao no processamento final dos resultados obtidos atravs da inspeo, com otimizao da
tomada de deciso pertinente a novas estratgias de melhoria da qualidade dos produtos de software no
contexto das empresas e instituies;
Reduo de custos relativos realizao de inspees, principalmente no que tange aos custos das
reunies de inspeo, que, com a ferramenta, passam a ser no presenciais, reduzindo drasticamente as
despesas com translado de inspetores e infraestrutura em geral;
Disponibilidade das Informaes, uma vez que, atravs do ambiente Web, as informaes ficaro
acessveis a partir de qualquer computador conectado Internet.
Possibilidade de maior troca de experincias entre os participantes da inspeo, o que contribui para
estender a base de conhecimento incorporada ferramenta e, conseqentemente, para melhorar o
processo e os resultados das inspees realizadas.
Desta maneira, espera-se que a ferramenta contribua para a engenharia de requisitos, trazendo mais um
recurso para facilitar, auxiliar e agilizar os processos, na busca pelo aprimoramento dos produtos de software.
5. Referncias.
[01] Briones, G.A.G. Ferramenta de Inspeo de Software para Ambiente Web, Dissertao de Mestrado, Programa de Ps-
Graduao em Cincia da Computao, UNIMEP, Piracicaba, Brasil, 2004.
[02] Ebenau, R.G., Strauss, S.H. Software Inspection Process, McGraw Hill, New York, USA, 1994.
[03] M.E. Fagan, Design and Code Inspections to Reduce Errors in Program Development, IBM System Journal, Vol. 15,
Number 3, 1976, p. 219-248.
[04] M.E. Fagan, Advances in Software Inspections, IEEE Transactions on Software Engineering, Vol. 12, Number 7, July
1986, p. 744-751.
[05] T.G. Kirner, Inspection of Software Requirements Specification Documents: A Pilot Study, ACM International
Conference on System Documentation - SIGDOC97, Salt Lake City, USA, October 1997, p. 161-171.
[06] Kirner, T.G. Inspeo de Requisitos de Software: Tcnicas, Ferramentas e Estudos Empricos, Projeto de Pesquisa,
UNIMEP, Piracicaba, Brasil, 2003.
[07] A. Porter, H. Siy, L. Votta, A Review of Software Inspections, Advances in Computers, Vol. 42, 1996.
[08] G. Travassos et all, Detecting Defects in Object Oriented Designs: Using Reading Techniques to Increase Software
Quality, ACM Conference on Object-Oriented Programming, Systems, Languages, and Application OOPSLA99,
Denver, USA, 1999, p. 47-56.
[9] A. Weiss, The Politics of Free Software. ACM Networker, Vol. 5, Issue 4, December 2001, p. 26-31.
! " # $
% # &'( )#(*&+, -&* #) .
/0 12 3 $
4 5 6 3 $ 6 7 89
3 8 $ % 3
7 3 6 $ 3 :
$ ;3 0 3 0 3 :
3 % <$
= ) 3 $> 3 %3 8? $
6 $< 3 $ 89 3
! " "
# $ % %
! &' ()* !
+
"
, ! - . / + %
! + 0 1 % 1
! 1% % ! % &'*
$ % ! 2
+ % 3 4 1 &)* 5 6 &'*
,+ !
% 7 % ! %
1 % !
#
# !
8% 9 " 7:,
7 ; 7
% ! / 01 <2 &'*
7 &'* " % 6 / =
>/ #
7:, 1 ?1 @
A 1 % 6 + ;
@
, ;
@
> % 1 %
@
,
B % !
8% : ; 0 0 :
8 % C
1 C
+ ; >
+ , % +
4
1 % %
1 ! - .
;
$ 5 % !
! % ,5 ) 8% : $ 5 D
" ,5 E " 1
5 " F G %
: % ! +
% !
+ 1 1
&)*
> 8% 5 ! % + 1 "
# +
1
# &(G*
H% + % ! ,
% + FI 1; %
! + # &(* ,
+ ;
+ ; &(*
1 6 #
6 ;
5 2 ; 1
!
5 , &D* 6 =
> 1
1
1 % 7 % 6
% C
, % 6
7 >55
-@3 6 .&E F G* J -A 3 )% # .&K*
, >55 " C
&L*= . 1 6
@. B
" @ .
, J )% # -J .&'I* %
6 5 1 &K*
= @A @
@ @ 1
!
$ 2 6
# 1
&''* 1 6 + 6 ;
% # 6 %
6
, 6 % #
+ 6 %
; 1 &'(* C
&')*=
, = B C
" " @
= B
" 1@
8 = -
. " @
= ; @
8 = 1 +
+ @
5 =
1 ; % @
, =
" # $ % &
> % 6 % + 6
" # > ; M
+
%
; ; &'D* , "
6 %
% 8% : ;
> % = @
@ 6 @ +
0
6
> 8% :
1 $
; ; 6
; 7 ;
; ; ;
8% : ;%
;
"! #' &

, 8% : % B %
0 0 ,+ LI N ) 'E 2
! , + " ;
!
8% : > + =
) % * &
( !
A 0 < % '
; A
;
A ; < % ; 1 '
,
A P < % '
! % <
+ ;
A < % '
0 !
, 5 < % % ! E
%
3 4+ < % + '
-, . 1
7 1 5 ! < % ; ! F
- . 3 4+
4 7 ? CC
, + #
% " ,+
O
" > +
> O %
1 +
$ 8% : +
+ A P 3 4+ A ; , 5
; +
1 !
Q +
! > ;
"
8% :
"! + , &
># @ 8% : -
;
1 %
5 0R J &'E 'F* 8
4
# % ; ;
+
# ;
- 2 +
. < : -<: .&'G 'K* !
8% : 5 1 <: %C % ; !#
4 &(K* 2 "
2
> <: 6 ;
; + % 7 1
; +
, % " J &'I* %
3 3 1
&'K* , + # @ 6
# 1
&'L (I ('*=
" +
+ " $
+ S , &D K*=
< % @
, 1 1
+ @
, " 1 %
1@
:
" &(( ()*@
P % % 3 3
$ T @
7 "
- ; >55.@
: 1
> # @ = ; , 1
A P A 0 A < A
0 , % ; B 4 B
,8 '
<: # % ;
> - ; .
+ % U,
0 : V % 7 +
U> V , , + " -
. " 3 @
% ; 4 "
" ; "
1 1 3 @
, !. $ /
0 <: + C 1
,4 (
C 1 <:
) 0$ 0 1 &
$ # $ )
8 ; B /
, + 8 ; 8
7 , B B
$ 0 + ; $
+ 1 1 1 + ;
+ ; ,
+
$ 7 ; + ;
0 C
% #
0 6
> +
B + 2 + 6 ;
,
$ 4 7
1 0
0< - . %C
S / &(D*
1
C <: 0 >55
%
2 # $
: ; $ ;
# @ , ;
7 M
" 0
, ; 8% : <8 -<
&(L*. %
" <8 " 53, -5 3 , .
7
; "
+C ; 1
; " %
, <8 8% : ;
S + "
0 B % : 8 -0B$C:8 7. > ;
1 C 0B$C:8 7 , + !
" " "
- " . "
; +
B70
7 ; +
S + +
- " . %
+ 1 B70 A
"
; C >
0 % B 1
% $
7
A P " >
$ "
8% : # @ ;
3 4 5
" %
8% : % 6 ; =
- B B" . .&(E (F* +
%
, + ,
+ %
; + " , DKG1
DKD(1
, + =
W - + .@
- .@
?+ @
$055 -C C 1 1
% .@
00$ - % C 1
.
0 # +
=
, EIN + 53, GEN
+ #
;
GIN 1
KIN
"
" ; X 1
;% $ "
" = @ @
6 @ ; ;
3!
, +
$ "
=
: ; %
7 1
+ @
> -W 5$ B0P.
1 % 7
" @
, >55
8 0 3 &(D*
- =/ .@
, 6 ; ;
; 8
3! $
0 ; "
; , %
4 "
% 1 ;
@
, " 1 ;
; @
, " ?
1 ;
, "
+ 1 "
W 5$ > " +
+ 1 &D* # C C
@
, ; -666 $ ; .
7
" ; D $ C %
1 ; > "
; "
@
, + O C
; + " 8% :
3!
" ) ,
>
; , 1
, " =
,
% 7 " 1
@
3 #
@
,
@
H
$ ;
@
, - .
3!
2 6 7 8 6
, " ; ; =
, ;
1 B
;
1 7
, " "
+ + 1 #
; +
+ +
; C
1
$ % J ; ? 1
%
9 $
7 1 8% : - % 6
;
, 8% :
1 1 ! 1 C
# # @ Q
1
T + % 6
C
% &'I 'E 'K*
,
<: &'G 'K* ?
; +
%
0 1 1
# @ ; 0 1% 1
8% : ;
%
: ,
> 8% : -0 < 7 W
8% / 1 Y / Y2 0+ < W 5 0 4 W .
" Y , 5 W
; 8
&'*8% ! = Z = 1 =?? ! ?
, T)? 0 51 ! Z [(DFEE\, ['
&(* , B /] 1 \W 1 3 41 5 ! 8 = B B= 1
4! 1B 5R < 15 5 > 'LLG
&)*W 6 1 5 ! 8 R S 6= 3 7 = 1 =?? 6 ?
? R
&D*, 5S / 1 =1 =??!!! ? ?[K(F? I(IL?
&E*5 1 1 5 < > , Y > 1 $ R > C5 5 ! 1 (
S 61 > 5 5 ! 7 > 83 W R(II(
&F*H 6 8 5 : 51 = 41 / > C5 5 ! = 1 =??!!! 1 6 ?
! ? C C1 1
&G*5 8 =1 =?? ?
&K*S , 0 , 5 ! J =
1 =??!!! ? C ?! 6 ? ?Z 1 ! 6 1
&L*0 ! ^ 5 / > ! ; =0 R R !
B77 5 ! (II( 'DL-'. )C'G
&'I*7 =, A B =1 =??!!! ?
&''* <5 ! 7 =, V, 1 W A !CH (III
&'(*0 1 , 7 5 4 H 0 , / 0 Y8 / : 7 + B A
< W 1 5 ! S 7<(II' C BT S 6 1 <
7 (II' / ,
&')*W 4 W W W 1 5 ! =1 =??!!! ?
? P(II)?3 ?4 ? P R_, _4
&'D*W ; 0 0 01 =1 =??!!! ? ? ?01 )IC
Y1
&'E*41 , , =1 =??!!!
&'F*8 ! W 41 $ ! W 1 R =1 =??!!! ! ? ? !W 1 R1
&'G*< 5 ! 0 <: C < : T (II(IE II =
1 =??!!! ? ? ? ;
&'K*, 0 <: ` J =1 =??!!! ? ?!1 ?4 'FG
&'L*5 7 S1 1 0 a H W Z =
1 =??!!! 1 ? 6?(II'?''? 1 1
&(I*, 6 ^ 5 ! A7,$4D ; =1 =??!!! ! 1?
!!! ? ? ?1 LF?
&('*A 6 < W 5 ! = 1 =??!!! 6R ?
! Z> ; B [FII(\8 [ 74,B3/<>S 57\> ; 4R [,<4
&((*5 W R 0 0 1 Y 4W 3 =
1 =??; ? ? ?1 ?0 0 4>0 1
&()*< B 0 R =!!! R
&(D*0 3 1 =??!!!
&(E*41 8 5 ! 8 -858. 1 =??!!! ?
&(F*8 ?3 > 5 5 ! 0 =1 =??!!! ?83>55? 1
&(G*Y , Y / W A P 5 ! B 0
W = 1 =??!!! ?4 ? ? ? /P ?< N(I ?
, N(IW
&(K*W H 1 W 6 <: , =1 =??!!! ? ? ?W 6 <: ,
&(L*< 8 1 =??!!! ! ?D'L(?< _8 _ 1
Un Metamodelo para Catalysis Basado en el Metamodelo de UML
Gabriela A. Prez Roxana S. Giandini Claudia F. Pons
Universidad Nacional de La Plata, Facultad de Informtica

LIFIA - Laboratorio de Investigacin y Formacin en Informtica Avanzada
La Plata, Argentina, 1900
[gperez, giandini, cpons]@sol.info.unlp.edu.ar
Resumen
Catalysis es un mtodo para desarrollo de software que define con precisin el concepto de
abstraccin/refinamiento de modelos. El refinamiento de modelos permite validar los requerimientos del
sistema con el cdigo, pasando por las distintas etapas intermedias. La relacin de refinamiento proporciona
importantes ventajas hacia el mejoramiento de la claridad y mejor comprensin de los modelos y, por lo
tanto, hacia su exactitud.
Los diagramas de Catalysis se basan en notacin UML pero los elementos utilizados en los diagramas
no se condicen estrictamente con los definidos en el metamodelo de UML. Adems, Catalysis no tiene
definido an un metamodelo, necesario para poder construir y verificar la precisin de sus diagramas y la
consistencia entre modelos.
En este trabajo presentamos una propuesta de metamodelo para Catalysis, basada en el metamodelo
UML, considerando los principales constructores y relaciones que aparecen en los distintos diagramas.
1. Introduccin.
Los procesos de desarrollo de software basan la notacin para sus modelos y diagramas en algn lenguaje
de modelado. Tal es el caso del Rational Unified Process [3], donde los modelos y artefactos que se van
produciendo en las distintas etapas de desarrollo, se construyen en el lenguaje de modelado grafico UML
[10]. Actualmente, otro mtodo de desarrollo de software utilizado que presenta y especifica conceptos de
modelado con mayor precisin, por lo cual nos resulta interesante, es Catalysis. Este mtodo provee un
proceso sistemtico que permite construir modelos precisos desde las etapas tempranas de desarrollo. Esto es
posible debido a que Catalysis define ms formalmente que en otros procesos, el concepto de
abstraccin/refinamiento de modelos. El refinamiento de modelos relaciona los requerimientos del sistema
con el cdigo, pasando por las distintas etapas intermedias. Adems permite, a partir de modelos detallados,
recuperar tambin en forma precisa, modelos abstractos. La relacin de refinamiento proporciona importantes
ventajas hacia el mejoramiento de la claridad y mejor comprensin de los modelos, y por lo tanto, hacia su
exactitud.
Algunos de los conceptos de Catalysis, como tipo, especificacin de acciones, refinamiento de modelos
fueron incluidos en la versin de UML 1.0, sin profundizar en su modelado y formalizacin. A su vez, los
diagramas de Catalysis [1] se basan en notacin UML pero los elementos utilizados en los diagramas no se
condicen estrictamente con los definidos en el metamodelo de UML. Por el momento, Catalysis no cuenta con
herramientas CASE especficas para editar sus diagramas, y aunque se aconseja utilizar las herramientas de
edicin para UML, stas no incluyen todos los elementos necesarios para construir los diagramas Catalysis ni
para verificar su precisin, como el mtodo lo requiere. Resulta observable que la causa fundamental por la
que no existen herramientas CASE que cubran estos requisitos es que Catalysis no tiene definido an un
metamodelo que permita la verificacin de sus diagramas y la validacin de consistencia entre modelos.
La tcnica de metamodelado es til para describir la sintaxis y semntica de lenguajes de modelado. Por
ejemplo, en el documento de especificacin de UML, el metamodelo est descripto semi-formalmente.
Algunos de los elementos de modelado estn especificados con diagramas bien definidos, mientras que otros
estn descriptos informalmente en lenguaje natural.
Existen diversos trabajos relacionados con esta tcnica como [11, 12 y 13], cuyas propuestas tienden a
mejorar la definicin del metamodelo UML. Algunos artculos realizados por nuestro grupo de investigacin
[4, 5, 6, 7, 8] proponen modificaciones y formalizaciones para el metamodelo a fin de enriquecerlo y poder
as verificar con mayor precisin la consistencia de los modelos.
En este trabajo presentamos una propuesta para el metamodelo de Catalysis basada en el metamodelo de
UML, considerando los elementos de modelado presentes en los distintos diagramas. El artculo se organiza
de la siguiente manera: en la segunda seccin presentamos una breve descripcin del mtodo Catalysis y los
principales conceptos y diagramas que ste utiliza. En la tercera seccin proponemos un metamodelo para
definir la notacin de los modelos descriptos en la seccin 2, incluyendo restricciones sobre sus elementos. En
la cuarta seccin se muestran ejemplos que instancian al metamodelo propuesto. Por ltimo se presentan
conclusiones.
2. Catalysis.
Los dos conceptos bsicos que se utilizan en Catalysis son: Objeto y Accin. Estos dos conceptos se
definen al mismo nivel de abstraccin. Los objetos representa un cluster de informacin y funcionalidad, y las
acciones representan comportamiento, por ejemplo, un evento, una tarea, un mensaje, un cambio de estado,
una actividad, etc. Las acciones afectan a los objetos, cambiando su estado. Estos conceptos forman la base
para la construccin de los distintos modelos.
Catalysis clasifica los modelos en estticos, dinmicos e interactivos. Dentro de los modelos estticos se
tienen los diagramas de objetos y los de tipos. Dentro de los dinmicos, se tienen las especificaciones de
acciones y los diagramas de estados y, dentro de los interactivos se tienen los casos de uso, las colaboraciones
y los diagramas de interaccin. En lo que resta de esta seccin describiremos brevemente los conceptos
considerados en el metamodelo propuesto:
dentro de los diagramas estticos, el
diagrama de tipos; dentro de los interactivos, Seminario
el diagrama de colaboracin y el de Profesor +seminariosDictados nombre
secuencia; y por ltimo, la relacin de tema
refinamiento de modelos.
+seminariosCursados
2.1 Modelos estticos - Diagrama
Estudiante
de tipos.
nroAlumno
Un diagrama de tipos muestra tipos
relacionados por asociaciones. Un tipo es Figura 1. Diagrama de tipos
ms general que una clase. Es utilizado en
etapas tempranas del desarrollo, como la etapa de anlisis. Sus atributos y asociaciones representan
informacin que puede ser conocida sin especificar la forma en que es obtenida. Catalysis utiliza el concepto
de clase para los niveles mas detallados de diseo, es decir, mas cercanos a la implementacin. Los atributos y
asociaciones presentes en una clase muestran directamente los atributos almacenados y links de sus instancias.
La figura 1 muestra un ejemplo de diagrama de tipos.
2.2 Modelos interactivos.
En todos los modelos interactivos aparece

el concepto de accin. Este concepto es Seminario
Participante
diferente al que define UML, donde la accin nombre
participar en nombre
Seminario tema
es desencadenada cuando un mensaje es
recibido por un objeto. En Catalysis, una
accin representa cualquier cosa que pueda
Figura 2. La JointAction participarEnSeminario
ocurrir: un evento, una tarea, un mensaje, un cambio de estado, una interaccin o actividad. Incluye no slo
envo de mensajes o llamadas a procedimientos, sino tambin dilogos completos entre objetos de cualquier
tipo. Una accin puede estar asociada a tipos, para mostrar como los afectan, o con otras acciones, para
mostrar la relacin de refinamiento de la accin con las acciones que la constituyen. En Catalysis, el concepto
de accin se describe en dos niveles: un tipo accin, que describe a un conjunto de acciones que caracterizan
los efectos sobre los objetos que participan y una ocurrencia, que es instancia del tipo accin.
Una accin puede corresponder a un comportamiento colectivo, cuya responsabilidad es compartida por los
distintos participantes, o individual, donde la responsabilidad est asignada a un participante en particular. De
acuerdo a esto, se clasifican en dos tipos:
a- El tipo Joint Action

Una JointAction representa un cambio en el estado de algunos de sus participantes, sin especificar como
se realiza este cambio, y sin asignar an la responsabilidad a ninguno de ellos.
Las JointAction son tiles para describir interacciones entre el usuario y el sistema. En la etapa de anlisis, la
especificacin de una JointAction representa la idea de caso de uso (ver figura 2).
Cuando describimos un caso de uso no se define an que objetos del modelo sern los responsables del
comportamiento especificado.
Al igual que los casos de uso, una JointAction puede ser refinada en secuencias de acciones ms detalladas.
En alguna etapa de este refinamiento, el comportamiento colectivo especificado por la JointAction se divide
en partes, y cada parte ser asignada a algn participante en particular, generando LocalizedAction.
b- El tipo LocalizedAction
Una LocalizedAction es ms Empleado
especfica que una JointAction. Es inscribir nroLegajo
Asistente (...)
frecuentemente llamada operacin. Al
inscribirAsistente(...)
igual que la JointAction, tiene
participantes, pero asigna la
responsabilidad de su ejecucin a un
Figura 3. La LocalizedAction inscribirAsistente
receptor en particular, definiendo su
contexto. Un mensaje de un lenguaje de
programacin puede ser visto como una realizacin de una LocalizedAction.
La figura 3 muestra una LocalizedAction llamada inscribirAsistente( ) que cuya responsabilidad es asignada
al tipo Empleado. Esto es equivalente a tener el mensaje inscribirAsistente( ) dentro del compartimiento de
los mensajes.
Ya descripto el concepto de accin, introducimos los modelos interactivos:
? Diagrama de colaboracin
Una colaboracin es un conjunto
de acciones y de roles de tipos que
contratarSeminario
participan en ella. Estos roles y las
acciones tienen base en un modelo
de tipos comn. Vendedor
Una colaboracin representa cmo
las responsabilidades estn CompaiaSeminarios
distribuidas entre los objetos y
acciones para realizar un
comportamiento en particular. La Asistente
Figura 4 muestra un diagrama de
asistirASeminario
colaboracin. El icono de persona
no representa el mismo concepto de
actor de UML (como externo al Empleado
sistema); indica que probablemente
habr personas involucradas Figura 4. Diagrama de colaboracin
(internas o externas al sistema).
? Diagrama de interaccin o secuencia

El diagrama de colaboracin
muestra tipos de objetos y acciones que
intervienen para realizar un : Estudiante : Empleado : Seminario
determinado comportamiento, sin
indicar nada respecto a la secuencia inscribirAsistente
interna de acciones que se realiza para
llevar a cabo dicho comportamiento. El
diagrama de interaccin es necesario
para describir la secuencia de acciones
entre objetos relacionados, que es
ejecutada para especificar un escenario
en particular, es decir muestra
ocurrencias de acciones. En la etapa de Figura 5. Diagrama de secuencia. Ocurrencia de JointAction
diseo detallado, estas acciones se
especifican con mensajes, que no siempre estn a un mismo nivel de complejidad. Los diagramas de
secuencia de UML tienen la desventaja que permiten mostrar varios niveles de anidamiento de mensajes, es
decir realizar refinamientos en un mismo diagrama. Esto permite que un mensaje que ha sido refinado en un
diagrama pueda volver a refinarse de forma diferente en otro contexto. Como solucin a este problema,
Catalysis incorpora el concepto novedoso de accin, y el tipo JointAction (ms abstracta que las
LocalizedAction), introduciendo nueva notacin para mostrar ocurrencias de JointAction dentro de un
diagrama de secuencia.
En la figura 5 vemos una ocurrencia de una JointAction, donde la barra horizontal representa dicha
ocurrencia, y las pequeas elipses marcan los objetos participantes de dicha accin.
Similarmente a UML, las barras verticales representan la lnea de vida del objeto participante. La Figura 6
muestra un diagrama de secuencia tpico de UML, que tambin se utiliza en Catalysis para mostrar
ocurrencias de LocalizedAction.
2.3 Refinamiento / Abstraccin.
La abstraccin permite entender sistemas complejos sin involucrar detalles.

Un modelo abstracto muestra la informacin con el detalle necesario para su entendimiento, que
posteriormente puede ser refinado. Un refinamiento es una descripcin ms detallada que se conforma con
otra (sus abstracciones).
Todas las propiedades
especificadas en el modelo
abstracto, deben mantenerse
tambin validas en el
refinamiento (adems, en el
refinamiento pueden valer
nuevas propiedades)
Adems de manejar
la complejidad, la tcnica de
refinamiento captura la
relacin esencial entre Figura 6. Diagrama de secuencia. Ocurrencias de LocalizedAction
especificacin e
implementacin. El desarrollo por refinamientos sucesivos permite validar cundo el cdigo se corresponde a
su especificacin.
Catalysis considera cuatro formas bsicas de refinamiento:

Respecto a tipos, se definen dos refinamientos:
De modelo: especificar con ms detalle un atributo de un tipo.
De operacin: implementar o especificar con ms detalle una operacin.
Participante
participar en
un seminario
Profesor Estudiante
asistir a dictar nroAlumno
Seminario Seminario
Figura 7. a) Refinamiento de Accin b) Refinamiento de Objeto
Respecto a colaboraciones, se consideran los siguientes refinamientos:

De Acciones: donde se muestra con ms detalle una accin, especificando las acciones que componen a la
accin a refinar. Esta relacin se representa con el smbolo de agregacin definido en UML (ver figura 7a).
De Objetos: al igual que con las
acciones, podemos ver con ms
detalle un objeto, pensndolo como
compuesto por otros. Tambin se
muestra esta relacin de
refinamiento con el smbolo de
agregacin. (ver figura 7. b)
El proceso de Catalysis se basa

en una combinacin de estas cuatro
variedades de refinamiento. Es
usual refinar o abstraer el modelo
en ambas dimensiones (la
dimensin de los objetos y la
dimensin de las acciones) al
mismo tiempo (Figura 8), ya que
cuando se divide un objeto en Figura 8. Refinamientos simultneos
varios, se suelen introducir nuevas
interacciones mas especificas entre ellos. Recprocamente, cuando se refina una accin, es frecuente que los
objetos participantes necesiten tambin ser refinados para poder representar los estados intermedios entre las
acciones ms pequeas. En este trabajo slo consideramos los refinamientos de Accin y de Objetos, que son
los que requieren representacin en el metamodelo.
3. Metamodelo propuesto para Catalysis.
El metamodelo Catalysis que proponemos y el metamodelo de UML son estructuralmente similares. De

hecho, la definicin del metamodelo Catalysis est basada en la definicin del metamodelo de UML. En el
metamodelo de Catalysis se agregaron algunas metaclases1 nuevas como Action, LocalizedAction, etc., y se
han modificado o borrado otras.
Los elementos del metamodelo que no aparecen en las figuras es porque no han sufrido modificaciones
respecto a UML, por lo tanto pueden consultarse en el documento de especificacin de UML original.
3.1 Modelos estticos.
1
Una metaclase permite definir la sintaxis y semntica del elemento que representa dentro de un metamodelo. Por ejemplo, la metaclase
Type representa el concepto de tipo que podr ser instanciado en el metamodelo. En un modelo, el tipo Participante es una instancia de la
metaclase Type.
En la figura 9 se muestra parte del metamodelo de Catalysis2 que define la sintaxis de los diagramas
estticos.
ModelElement
name : Name +participant
AssociationEnd
1 +associations isNavigable : Boolean
* ordering : OrderingKind
aggregation : AggregationKind {ordered} Association
multiplicity : Multiplicity 2..* 1
Relationship changeability : ChangeableKind +connection
visibility : VisibilityKind
+associationEnd
0..1
{ordered}
+qualifier *
+generalization 1+child GeneralizableElement Attribute

Generalization * isRoot : Boolean initialValue : Expression
isLeaf : Boolean
+specialization
* +parent isAbstract : Boolean
1
+powerRange
+powerType Classifier
Type Class
Figura 9. Parte del metamodelo Catalysis Diagramas estticos
Las diferencias fundamentales de este diagrama con respecto al UML son:

? La metaclase AssociationEnd, que en el metamodelo de UML estaba relacionada con Classifier, haciendo
posible que slo los classifier se pudieran asociar, en Catalysis est relacionada con ModelElement. Este
cambio hace posible que cualquier ModelElement pueda estar asociado a otro ModelElement, y de esta
manera permitir que se puedan asociar Acciones, que al no ser Classifiers no podran asociarse.
? El segundo cambio importante es que Association no es subclase de GeneralizableElement, como est
definida en UML. Esto hace imposible establecer jerarquas de Association, como lo especifica UML.
Este punto fue discutido en un trabajo anterior [8], donde consideramos que las asociaciones pueden
refinarse, pero no relacionarse por herencia.
? Por ltimo, desaparece la clase AssociationClass, ya que no existe este concepto en Catalysis.
3.2 Modelos interactivos.
La figura 10 muestra un diagrama del metamodelo donde la metaclase GeneralizableElement es

subclasificada con metaclases nuevas, que representan elementos propios de Catalysis:
? La metaclase ActionType es una metaclase abstracta nueva que permite representar las acciones de
Catalysis. Esta metaclase no es un Classifier porque no tiene StructuralFeatures, ni BehavioralFeatures,
pero si, est definida como subclase de GeneralizableElement para permitir jerarquas de Acciones.
? Un ActionType puede tener cualquier nmero de parmetros.
? Las metaclases LocalizedActionType y JointActionType son subclases de ActionType.
? La metaclase ActionType puede tener cualquier nmero de participantes; stos se obtienen a partir de los
tipos con los cuales est asociada directamente la accin.
2
Los diagramas en los que se basan los diagramas presentados en esta seccin, pueden verse en su completitud en [10] (diagramas 2-5).
Como se explic en la subseccin anterior, una asociacin puede establecerse entre cualquier ModelElement.
Ya presentada la metaclase ActionType, estamos en condiciones de definir las siguientes reglas de buena
formacin en el contexto de Association, que restringen que tipos de ModelElement van a poder ser
asociados, y mediante que tipo de asociacin. Estas reglas de buena formacin estn expresadas en el lenguaje
para restricciones de objetos OCL [10] , integrado al UML:
GeneralizableElement
isRoot : Boolean
isLeaf : Boolean
isAbstract : Boolean
Parameter
ActionType defaultValue : Ex pression
Classifier
kind : ParameterDirectionKind
Type Class LocalizedActionType JointActionType
Figura 10. Metamodelo Catalysis Elementos generalizables.
Association - Constraints
[1] Las asociaciones deben establecerse entre elementos del mismo tipo, salvo un Classifier con una
ActionType.
self.allConnections -> forAll (c1, c2 |

( c1.oclIsKindOf(c2))
or ((c1.oclIsKindOf( Classifier) implies (c2.oclIsKindOf(ActionType))
or ((c2.oclIsKindOf(ActionType) implies (c1.oclIsKindOf( Classifier))
[2] Las acciones no se podrn asociar con una Association simple; es decir, slo se podrn asociar con una
agregacin o composicin. Esta regla verifica que, si la asociacin est definida entre dos acciones, slo uno
de los AssociationEnd puede tener en el atributo aggregation el valor #none3.
self.allConnections -> forAll (c1, c2 |

( c1.oclIsKindOf(ActionType ) or (c2.oclIsKindOf(ActionType)) implies
self.allConnections->select(aggregation <#none) ->size = 1
Se deberan formular reglas similares para la validacin de asociaciones entre otros elementos del modelo, por
ejemplo, asociaciones entre paquetes etc.
Asimismo, se debera restringir cules elementos tiene sentido asociar, y cules no. Por ejemplo:
[3] Las generalizaciones no se pueden asociar.

self.allConnections -> forAll (c1 | not c1.oclIsKindOf(Generalization) )
3
Existe una restrccin en UML que chequea que si una asociacin es una agregacin o composicin, se trata de una asociacin binaria.
Pg 2-52 de [10] (ver regla definida en el contexto Association)
ActionType Constraints
Regla Adicional
[1] Los participantes de una accin son los tipos que estn asociados a la accin.
self.allOppositeAssociationEnds -> select (me |not

me.participant.isOclKindOf(ActionType) )
? Diagrama de interaccin o secuencia
Al igual que en UML, una Collaboration

define un espacio de nombres; est compuesta por Namespace
varios escenarios, cada uno de los cuales, est
compuesto por varias interacciones (Figura 11).
La idea de interaccin cambia respecto a UML. En
Catalysis, las interacciones representan ocurrencias
Collaboration
de acciones de alguno de los tipos
LocalizedActionType o JointActionType. 1
+context
En la figura 12 puede verse que la metaclase ModelElement
Interaction se subclasifica en LocalizedInteraction
y JointInteraction. LocalizedInteraction
corresponde a una ocurrencia de
LocalizedActionType, y JointInteraction *
Scenario +interaction Interaction
corresponde a una ocurrencia de JointActionType.
La metaclase LocalizedInteraction tiene definidos 1 1..*
el emisor y el receptor (sender y receiver Figura 11. La metaclase Collaboration

respectivamente) de la interaccin. Por otro lado,
JointInteraction tiene definido el iniciador.
Cada una de las interacciones que conforman un escenario tiene una signatura.
Esta signatura estar formada por:
? El iniciador de la interaccin, si estuviera determinado
? Una lista de argumentos, entre parntesis, separados por coma, que representan los parmetros
actuales. Cada uno de estos argumentos es una referencia a una instancia, o una expresin en
pseudocdigo o en algn lenguaje de programacin.
? El receptor de la Interaccin, nicamente especificado en LocalizedInteraction
En la figura 13 puede verse en detalle cmo se relacionan las interacciones con las acciones. La
metaclase Action es una metaclase abstracta subclasificada en LocalizedAction y JointAction. La metaclase
LocalizedAction representa una accin concreta, y est a su vez subclasificada en las acciones concretas de
UML (CreateAction, CallAction, SendAction, etc.).
La metaclase JointAction no est subclasificada. Esta metaclase representa una accin abstracta, que
necesitara ser refinada, hasta que este refinamiento est formado slo por LocalizedActions.
Collaboration
1
+activador
+/ ownedElement * Action Interaction +succesor
AssociationRole
Association *
+base *
0..1
* +predecessor
2..*
{ordered} +connection
LocalizedInteraction JointInteraction
AssociationEnd
isNavigable : Boolean +/ connection 2..*
ordering : OrderingKind
aggregation : AggregationKind AssociationEndRole
multiplicity : Multiplicity
+base
changeability : ChangeableKind +receiver +iniciator
visibility : VisibilityKind +sender
ClassifierRole +/ ownedElement
+/ type
+availableFeature
Feature *
Classifier +base
1..*
1..*
Figura 12. La metaclase Collaboration e Interaction detallada.
Argument
Interaction Action
LocalizedInteraction JointInteraction LocalizedAction JointAction
CreateAction CallAction ReturnAction
Figure 13. Relacin entre las metaclases Interaction y Action

4. Instanciando el metamodelo de Catalysis.

Al construir un modelo para un dominio especfico en un lenguaje de modelado que tiene un metamodelo
definido, estamos instanciando al metamodelo del lenguaje en cuestin. Esto significa que cada elemento que
se modela es una instancia de alguna metaclase del metamodelo. Para poder comprender con mayor claridad
la relacin entre metamodelo y modelo, podemos volver a los ejemplos de la seccin 2, que ilustran algunos
diagramas de Catalysis.
La Figura 14 muestra una instanciacin del metamodelo en un diagrama de objetos, para el diagrama
Catalysis mostrado en la figura 2. Participante que es un tipo en el modelo, es en este diagrama una instancia
de la metaclase Type; la accin participarEnSeminario, es instancia de la metaclase JointActionType, que en
este caso no tiene parmetros, pero s tiene participantes (los tipos Participante y Seminario), los cuales son
accesibles a travs de los links conectando instancias de AssociationEnd y Association.
Diagramas de objetos similares pueden construirse para instanciar el resto de los modelos Catalysis
(diagramas de tipos, de secuencia, etc.), que no fueron includos en este artculo por limitaciones de espacio.
:Type : AssociationEnd : AssociationEnd : Type

+association +participant
name = Participante isNavigable = true isNavigable = true name = Seminario
+participant +association
+connection +connection
+feature +feature
+feature : Association : Association : Attribute :Attribute

: Attribute name = nombre name = tema
name = nombre
+connection +connection
: AssociationEnd : AssociationEnd
isNavigable = true isNavigable = true
: JointActionType
name = participarEnSeminario
Figura 14. Instanciacin del metamodelo para el diagrama de la Figura 2.
En conclusin, as como es necesario definir objetos o instancias de los elementos del modelo para poder
expresar su semntica en ejecucin (comportamiento), a nivel metamodelo, los elementos del modelo son
instancias de sus respectivas metaclases. Tener al modelo de usuario instanciado sobre el metamodelo nos
permite verificar reglas de buena formacin y restricciones como las que en este trabajo presentamos y poder
verificar tambin, consistencia entre modelos.
5. Conclusiones.
Catalysis es un mtodo para desarrollo de software donde se define ms formalmente que en otros
procesos, el concepto de abstraccin/refinamiento de modelos. El refinamiento de modelos relaciona los
requerimientos del sistema con el cdigo, pasando por las distintas etapas intermedias. La relacin de
refinamiento proporciona importantes ventajas hacia el mejoramiento de la claridad y mejor comprensin de
los modelos, y por lo tanto, hacia su exactitud. Los diagramas de Catalysis se basan en notacin UML pero
los elementos utilizados en los diagramas no se condicen estrictamente con los definidos en el metamodelo de
UML. Adems, Catalysis no tiene definido an un metamodelo, necesario para poder construir y verificar la
precisin de sus diagramas y la consistencia entre modelos.
En este trabajo hemos presentado una propuesta de metamodelo para Catalysis, basada en el metamodelo
UML, considerando los principales constructores y relaciones que aparecen en los distintos diagramas. Esta
propuesta de metamodelo fue recientemente tomada como base en la construccin de una herramienta Case
que est desarrollando nuestro equipo de investigacin. Esta herramienta, que ser utilizada en cursos de
enseanza de Ingeniera de Software, permitir la edicin y verificacin, con base formal, de diagramas
Catalysis dentro del proceso de desarrollo de software. Est siendo desarrollada como un plug-in para la
Plataforma Eclipse4 y fue presentada en [9] por nuestro grupo. La definicin del metamodelo fue necesaria
para validar la edicin de los diagramas, especificando en base a l, restricciones y reglas de buena formacin
a nivel metamodelo y a nivel modelo (como reglas del negocio). Estas reglas de buena formacin se definen
en el lenguaje de especificacin de restricciones OCL.
Como continuacin de este trabajo, proponemos la extensin del metamodelo para expresar modelos
dinmicos; como tambin la definicin de nuevas reglas sobre el metamodelo extendido, lo que permitir que
se enriquezca y pueda llevarse a cabo una ms completa verificacin de diagramas y consistencia entre
modelos generados a travs de la tcnica de refinamiento. Todo esto mejorar la calidad del proceso de
desarrollo de software.
6. Referencias.
1. D Souza, Desmond and Wills, Alan. Objects, Components and Frameworks with UML.Addison-Wesley.
1998.
2. Giandini Roxana, Pons Claudia, Gabriela Alejandra Prez . Use Case Refinements in the Object Oriented
Software Development Process"CLEI 2002", ISBN 9974-7704-1-6, Editors Alfredo Viola, Montevideo,
Uruguay, 25 al 29 de Noviembre de 2002.
3. Jacobson, I..Booch, G Rumbaugh, J., The Unified Software Development Process, Addison Wesley. (1999)
4. G. Prez, R. Giandini, C. Pons. " Model Refinements in the Object Oriented software Development Process "
Anales de las 31 JAIIO, ASSE2002. Santa F, Setiembre 2002
5. C. Pons, G. Perez, R. Giandini, and R. Kutsche. Understanding Refinement and Specialization in the
UMLIn Proceeding of Workshop on MAnaging Specialization/Generalization Hierarchies: MASPEGHI 2003,
Montral, Qubec, Canada,October 6th, 2003
6. C. Pons, R. Giandini, Garbi J., Mercado P., G. Baum. Dimensions in the Object Oriented software
Development Process In Proceeding of the 2002 IRMA International Conference, UML and UP Track ,
Renaissance Madison Hotel, Seattle, Washington,USA, May 19-22, 2002
7. Pons , Claudia, Giandini, Roxana and Baum, Gabriel. Specifying Relationships between models through the
software development process, 10th International Workshop on Software Specification and Design, USA, IEEE
Computer Society Press. Nov. 2000.
8. Pons C., Perez G. and Giandini R. Incremental Specialization vs. Overriding Specialization in theUnified
Modeling Language En Proceedings of IDEAS02. La Habana, Cuba. 22-26 de Abril de 2002
9. Pons C., Giandini R., Perez G. et al. Integrating Formal Methods in a Software Engineering Course with
Eclipse. Eclipse Technology eXchange Meeting. At International Conference on Object Oriented
Programming Systems Languages and Applications. OOPSLA 2003. Anaheim, California. 26 October 2003.
10. Unified Modeling Language (UML) Specification - Version 1.4, September 2001. UML Specification, revised
by the OMG, http://www.omg.org.
11. Atkinson C., Khne T.: The Essence of Multilevel Metamodeling. Martin Gogolla, Cris Kobryn (Eds.):
UML 2001 The Unified Modeling Language, Modeling Languages, Concepts, and Tools, 4th International
4
Para ms informacin consultar la pgina http://sol.info.unlp.edu.ar/eclipse
Conference, Toronto, Canada, October 1-5, 2001, Proceedings. Lecture Notes in Computer Science 2185
Springer 2001, ISBN 3-540-42667-1
12. Jos M. lvarez, Andy Evans, Paul Sammut: Mapping between Levels in the Metamodel Architecture. Martin
Gogolla, Cris Kobryn (Eds.): UML 2001 The Unified Modeling Language, Modeling Languages, Concepts,
and Tools, 4th International Conference, Toronto, Canada, October 1-5, 2001, Proceedings. Lecture Notes in
Computer Science 2185 Springer 2001, ISBN 3-540-42667-1
13. Andrey Naumenko, Alain Wegmann: A Metamodel for the Unified Modeling Language. Editors: J.-M.
Jzquel, H. Hussmann, S. Cook (Eds.): UML 2002 - The Unified Modeling Language : 5th International
Conference, Dresden, Germany, September 30 - October 4, 2002. Proceedings Lecture Notes in Computer
Science 2460 Springer 2001.
GOS: Especificao de um Mecanismo de Busca e Recuperao de

Componentes
Alessandreia Oliveira Regina M.M. Braga Fernanda Campos Marta Mattoso
COPPE/UFRJ CTU/UFJF DCC/UFJF COPPE/UFRJ
ale@cos.ufrj.br regina@acessa.com fcampos@dcc.ufjf.br marta@cos.ufrj.br
Abstract
Information retrieval and browsing techniques need to be complemented by strategies that focus in the
content and semantics of information. However, semantic issues involve different vocabularies describing
similar information in similar contexts. One solution to this problem is the adoption of ontologies, including
semantic relationships among terms in different vocabularies. Our proposal associates ontologies and
distributed mediators reducing the complexity of distributed heterogeneous information retrieval problem into
a less complex problem which is the identification of ontologically related terms across ontologies. We
present an architecture and its prototype including also an example in the Agricultural domain.
1. Introduo
Existe atualmente uma necessidade de complementao das tcnicas de recuperao de informao e
navegao existentes, atravs de uma estratgia que tenha seu foco no contedo e na semntica da
informao. Um problema crtico em caracterizar o contedo da informao o uso de vocabulrios
diferentes descrevendo informao semelhante, ou seja, diferentes termos so utilizados para caracterizar uma
mesma informao. Uma soluo para o problema de vocabulrios diferentes a utilizao de
relacionamentos semnticos entre os termos atravs do uso de ontologias1 [1].
A integrao de informaes no contexto do DBC - Desenvolvimento Baseado em Componentes [2] tem

como principal proposta a construo de aplicaes a partir de diferentes componentes pr-existentes. No
DBC, tanto a integrao quanto a busca de componentes pode ser beneficiada com o uso de ontologias. No
se pode reutilizar componentes prontos se no se sabe como e onde encontr-los. Dentro deste contexto, a
proposta de utilizao de repositrios de componentes surge como uma soluo para o armazenamento dos
mesmos, tornando -os pblicos e acessveis a todos. Considerando a disponibilidade da Web como meio de
busca por informaes mais utilizado atualmente, a construo de uma infra -estrutura capaz de facilitar a
busca por informaes de componentes armazenados em repositrios distribudos e que possam ser acessados
pela Web, torna-se uma questo importante para um processo de reutilizao. Alm disso, tal infra-estrutura
deve prover tambm recursos avanados para pesquisa de componentes. As estratgias de busca atualmente
disponveis na Web, baseadas em sua maioria no uso de palavras-chave, permitem a execuo de pesquisas de
forma limitada, originando respostas muito volumosas e genricas. No contexto de busca por componentes, as
propostas atualmente disponveis se concentram principalmente na anlis e sinttica da interface dos
componentes [3], [4]. Aliado a isto, a falta de informaes descritivas (metadados) relacionadas aos
componentes publicados, alm dos problemas associados a questes semnticas que envolvem a existncia de
diferentes vocabulrios descrevendo informaes semelhantes dentro de um mesmo contexto, diminuem
ainda mais a preciso e qualidade dos mecanismos de busca existentes.
Neste contexto, o sistema de busca SBS-AGRO [5] est sendo estendido, utilizando o sistema GOS [6],
para facilitar a busca por componentes de software no domnio agropecurio. Desta forma, foi especificado
um mecanismo capaz de reunir os diversos vocbulos encontrados no setor, atravs do uso de termos de uma
1
Ontologia, no contexto deste trabalho, um vocabulrio de termos e a especificao do relacionamento entre estes termos. Uma
definio deve ser criada para cada termo atravs de uma descrio informal, bem como a especificao dos relacionamentos entre os
termos, formando ento uma rede semntica.
ou mais ontologias relacionadas ao domnio, para permitir uma busca mais eficaz em repositrios locais ou
distribudos. O sistema GOS (GOA Ontology Services) utiliza um modelo de ontologias aliado a um
mecanismo de inferncia para lidar com a busca de componentes relacionados semanticamente a outros
componentes de uma ou mais ontologias. O objetivo do GOS , especificamente, reduzir o problema da
necessidade de conhecer a estrutura e semntica de dados espalhados nos vrios repositrios para um
problema menor que conhecer os relacionamentos ontolgicos entre os termos atravs das ontologias.
O restante deste artigo organizado como a seguir: a seo 2 apresenta alguns trabalhos relacionados
nossa proposta. A seo 3 descreve detalhes da arquitetura GOS, dos servios oferecidos pelo GOS e da base
de regras. A seo 4 mostra um exemplo do uso dos servios de ontologia no domnio agropecurio. Na seo
5 so reportadas as concluses deste trabalho.
2. Trabalhos Relacionados
Alguns sistemas de recuperao de informao usam, por exemplo, mecanismos de inferncia sobre
ontologias para derivar novas informaes. Estes trabalhos incluem OntoSeek [7], Thetis [8], Kess [9],
OBSERVER [10] , InfoSleuth [11]. Uma diferena entre estes projetos e o GOS que usamos um processo
semi-automtico para derivar novas informaes e relacionamentos interontolgicos. Estes projetos no
fornecem uma soluo para acessar informaes de diferentes domnios, de modo transparente para o usurio
como fazemos em nosso trabalho
Na literatura existem tambm trabalhos para auxiliar na recuperao de componentes, como em [12], onde
apresentada a arquitetura de um sistema multi-agente, baseado em ontologias de domnio, que utiliza um
conjunto de regras e UML para recuperao de componentes de software. O diferencial de nossa proposta em
relao a este projeto o uso de um processo semi-automtico para derivar novas informaes e
relacionamentos intra e interontolgicos. Em [4] apresentado o SPARS, um sistema de recuperao de
componentes baseado em um modelo de grafos e um algoritmo de classificao dos componentes. SPARS
no utiliza ontologia e baseia sua busca na relao atual entre os componentes e da propagao desses
relacionamentos. O sistema SPARS preocupa-se, principalmente com a parte sinttica da interface dos
componentes, no levando em considerao aspectos semnticos, como no GOS.
O GOS pode ser considerado como uma extenso da Odyssey-Search [13] onde foi implementado um
prottipo que realiza o armazenamento e a busca por informaes relevantes de um dado domnio para o
desenvolvimento de aplicaes e a busca por informaes em domnios correlatos ao domnio em questo.
Desta forma, podemos considerar que o diferencial da nossa proposta em relao aos trabalhos mostrados est
no fato de que utilizamos um conjunto de regras e um mecanismo de inferncia para deduzir novas
combinaes vlidas, inclusive a partir das combinaes j existentes. Este mecanismo automatiza a
inferncia de forma integrada com mediadores (apres entam um esquema de integrao comum) [14] e banco
de dados e permite obter as respostas atravs do acesso aos repositrios de dados subjacentes.
3. Arquitetura GOS
O sistema GOS faz parte de uma arquitetura denominada ComPublish [15] que visa auxiliar
desenvolvedores de software a publicar variados artefatos de software na Internet, tal como modelos,
diagramas, cdigo fonte, programas ou qualquer outro tipo de artefato utilizado ou produzido nas diferentes
etapas do processo de desenvolvimento de um software. Atravs de sua arquitetura baseada em mediadores, a
ComPublish (Figura 3.1) prov uma viso lgica de vrios componentes publicados local ou remotamente
dentro de um mesmo domnio de aplicao [16]. Seus principais servios so: (1) descrever e publicar
componentes armazenados em um repositrio qualquer da Internet; (2) integrar as informaes dos
componentes publicados de acordo com o seu domnio de aplicao; (3) prover o gerenciamento de ontologias
capazes de integrar termos de diferentes domnios; (4) prover mecanismos de pesquisa e a recuperao dos
componentes publicados. Maiores informaes a respeito da ComPublish podem ser encontradas em [15].
Browser Web
Consultas
Servidor GOA Mediador 1 GS GOS Servidor GOA

(Metadados + (Metadados de
Componentes) Dominio)
Servidor GOA Mediador 3 Mediador 2 Servidor GOA

(Metadados + (Metadados +
Componentes) Componentes)
Camada de Tradutor Tradutor Tradutor

Integrao
Servidor Servidor Servidor

Le Select Le Select Le Select
Componentes (modelos,
diagramas, casos de uso,
documentos, cdigo fonte,
programas, etc.)
Camada de Descries de
Publicao Componentes em XML
Figura 3.1: Arquitetura ComPublish [16]
No contexto do sistema SBS-AGRO, a arquitetura ComPublish pode tambm ser utilizada. No entanto, o
sistema tem seus repositrios de componentes locais, particionados por sub-domnio, que usa o sistema GOS
para auxiliar a busca pelos componentes locais. Quando a busca deve ser realizada em repositrios
distribudos, a arquitetura ComPublish pode ser integrada ao sistema. Em ambos os contextos, o sistema GOS
(Figura 3.2) responsvel por realizar as ligaes ontolgicas intra e interdomnios. Este sistema realiza os
mapeamentos necessrios entre termos do mesmo e de diferentes domnios e mantm as informaes
atualizadas a respeito do domnio. O GOS recebe do SBS-AGRO ou do mdulo Gerente de Servios (GS) da
ComPublish solicitaes de servios ontolgicos, como por exemplo, criao de ontologias e incluso de
termos ontolgicos, descoberta de informaes sobre componentes relacionados ao termo em questo e
estabelecimento de relacionamentos intra e interontolgicos.
GOS
GS
GRI GM GC MI
Servidor
GOA
Ontologias +
Relacionamentos Base de
Intra e Regras
Interontolgicos
Figura 3.2: Arquitetura GOS [6]

A integrao de ontologias no contexto do GOS realizada atravs do casamento das caractersticas

constantes de cada modelo ontolgico, a partir da identificao de relacionamentos entre estes termos
ontolgicos de diferentes domnios tais como relaes de sinnimos (termos que possuem a mesma
semntica), hipnimos (termos que so mais especficos que um outro) e hipernimos (termos que so mais
genricos que um outro ). Atravs destes mecanismos, utilizados em outras abordagens para a integrao de
esquemas heterogneos [10], ontologias de domnio similares podem ser integradas e/ou direcionar as buscas
em um dado domnio para domnios correlatos. O estabelecimento de relaes intra e interontolgicas feito
de modo semi-automtico e usa uma base de regras juntamente com um mecanismo de inferncia para derivar
novas relaes. A seguir so descritos os principais mdulos da arquitetura GOS:
Gerente de Consultas (GC): encarregado de recuperar informaes relacionadas a um determinado

termo de uma ontologia especfica. O GC navega atravs das ligaes entre termos da ontologia, como
sinnimos, hipnimos, hipernimos e apresenta o resultado como um conjunto de termos relacionados.
Caso haja solicitao de verificao em outros domnios (ontologias relacionadas), o GC submete uma
consulta ao GRI, que responsvel por verificar termos de outras ontologias, apresentando assim um
resultado mais abrangente;
Gerente de Relacionamentos Interontolgicos (GRI): Prov informaes sobre os relacionamentos

interontolgicos. Para isso, o GRI gerencia as listas de sinnimos, hipernimos e hipnimos, entre
termos de diferentes ontologias. GRI o mdulo chave que permite arquitetura GOS lidar com
diferentes ontologias criadas de diferentes pontos de vista e semnticas. Os relacionamentos
armazenados no GRI permitem que o GOS mapeie termos de uma ontologia sobre termos da mesma ou
de outra ontologia diferente, desde que haja um relacionamento semntico entre eles;
Gerente de Metadados (GM): Oferece servios para visualizao das ontologias e de seus termos,
criao de ontologias e incluso de termos em uma ontologia;
Mquina de Inferncia (MI): Gera novos relacionamentos intra e interontolgicos, a partir de

relacionamentos ontolgicos j existentes atravs de um conjunto de regras pr-definido. Estas regras
esto armazenadas no Servidor de Objetos GOA 2 [17]. Este processamento depende de uma solicitao
e xplcita do administrador.
3.1 Servios
O GOS recebe solicitaes de servios ontolgicos, como por exemplo, criao de ontologias e incluso de
termos ontolgicos, descoberta de informaes sobre componentes relacionados ao termo ontolgico em
questo e estabelecimento de relacionamentos intra e interontolgicos. Os servios oferecidos pelo GOS so
descritos a seguir:
Adicionar Ontologia: Uma ontologia registrada a partir da informao de seu nome. Vale lembrar que
uma ontologia est associada a um domnio bem especifico, como por exemplo, a ontologia do
Agropecurio que est associado ao Domnio Agropecurio. A ontologia cadastrada com um nome
nico que a identifica;
Incluir Termos em uma Ontologia: A qualquer momento, termos podem ser includos em uma
ontologia. Para adicionar um termo, necessrio fornecer um nome, uma denominao (outras
designaes que o termo possui) e uma descrio (definio deste termo a ser inserido), bem como
associ-lo a uma ontologia. Para que os termos de uma ontologia estejam acessveis para outras
ontologias, os relacionamentos intra e interontolgicos so estabelecidos. Neste caso, assim que o termo
for inserido, so estabelecidos inicialmente, os relacionamentos deste novo termo com os existentes
naquela ontologia. Esse processo, semi-automtico, feito atravs da interface da aplicao. Terminada
essa fase, passa-se para o relacionamento deste termo com termos de qualquer outra ontologia, processo
este semelhante ao anterior;
2
utilizado como repositrio dos modelos ontolgicos e da base de regras utilizada. Alm disso, a sua linguagem de consulta utilizada
para a consulta aos metadados armazenados. Todos os servios providos pelo GOS so realizados atravs de consultas OQL a bases GOA
Relacionar termos em uma mesma ontologia: Co mo mencionado anteriormente, aps a incluso de um

termo em uma ontologia, passa-se para a fase de estabelecimento de relacionamentos intraontolgicos
(sinnimos, hipernimos e hipnimos) atravs de inferncia;
Relacionar termos em ontologias diferentes: Um termo de uma ontologia pode se relacionar com outros
termos da mesma ontologia ou at mesmo de ontologias diferentes. Nesta fase so estabelecidos, atravs
de inferncia, os relacionamentos dos termos includos em uma determinada ontologia com todos os
outros termos de todas as outras ontologias;
Fornecer Ontologia, Termos Ontolgicos, Definio Denominao: Fornece informaes sobre as

ontologias e os termos ontolgicos;
Fornecer Relacionamentos Intra e Interontolgicos: Dado um termo e uma ontologia possvel

visualizar todos os termos que se relacionam com o termo em questo, atravs dos relacionamentos
sinnimo, hipernimo e hipnimo, sejam estes termos pertencentes ou no a mesma ontologia do termo
selecionado.
3.2 A Base de Regras
O GOS utiliza algumas regras para derivar novos relacionamentos entre os termos. Por atender a
necessidade desta proposta, adotou-se o algoritmo Forward Chaining3 para o estabelecimento destes novos
relacionamentos intra e interontolgicos. Uma regra formada a partir de clusulas antecedentes e
conseqentes. Cada clusula por sua vez formada por variveis e condies.
As regras armazenadas no servidor de objetos GOA so utilizadas para o estabelecimento de novos

relacionamentos em uma mesma ontologia, uma vez que o especialista de domnio efetuou o cadastramento
da ontologia, mas pode no ter inserido todos os relacionamentos. Vale mencionar que o estabelecimento de
relacionamentos feito de modo semi-automtico.
A figura 3.3 apresenta algumas das regras definidas e detalhadas em [6] . A terceira regra, por exemplo,
possui duas clusulas antecedentes (Synonymous (A, B), Hypernymous (B, C)) e uma clusula conseqente
que est sendo selecionada (Hypernymous (A, C)) e significa: Se um termo A tem como sinnimo um termo
B e este termo B, por sua vez, tem como hipnimo o termo C, ento o termo A tem como hipnimo C.
Figura 3.3: As regras utilizadas em GOS

3
Processo de inferncia onde um conjunto de regras utilizado para gerar novos fatos a partir de um conjunto inicial de dados
Determinados os novos relacionamentos intraontolgicos, o GOS prope o estabelecimento de novos

relacionamentos entre termos de ontologias diferentes.
4. Uso do GOS no Domnio Agropecurio
Uma das caractersticas desejveis em um mecanismo de busca a possibilidade de se lidar com

vocabulrios diferentes para diferentes tipos de usurios. Para atender a esta necessidade, o SBS-AGRO conta
com o auxlio do sistema GOS.
O sistema de busca SBS-AGRO [5] , com o auxilio do GOS utiliza ontologias e relacionamentos intra e
interontolgicos para a classificao de softwares agropecurios e para permitir aos desenvolvedores de
software a realizao de buscas em repositrios locais ou remotos (neste caso com o auxlio da COMPublish).
A utilizao do GOS e destas tecnologias tem como principal objetivo diminuir o volume de informaes
irrelevantes nas buscas realizadas (o que acontece, por exemplo, com mecanismos baseados em palavras-
chave) e atender as necessidades de um maior nmero de usurios e desenvolvedores (no se concentrando
somente em mtodos de anlise sinttica da interface dos componentes). A vantagem de se utilizar ontologias
neste contexto que elas permitem e reutilizao e o compartilhamento de um vocabulrio comum para a
classificao de softwares de diferentes empresas. Este trabalho foi desenvolvido de forma que a classificao
dos softwares possa ser incrementada medida que os usurios fizerem sua avaliao dos softwares, deste
modo poderemos obter resultados cada vez mais precisos.
Apresentamos a seguir os benefcios da utilizao do GOS e de seus servios inter e intraontolgicos no

domnio agropecurio, no contexto do SBS-AGRO. O uso do GOS promove a integrao de informaes
atravs de mecanismos para traduzir a requisio de informao com o uso de ontologias. Para efetuar o
mapeamento de uma consulta sobre uma ontologia em termos de outras ontologias, o GOS utiliza os
relacionamentos definidos no seu contexto. So mostrados tambm como o estabelecimento semi-automtico
de novos relacionamentos intra e interontolgicos efetuado e o uso da base de regras juntamente com o
mecanismo de inferncia proposto.
O uso de ontologias no setor agropecurio permite a reutilizao e o compartilhamento de um vocabulrio

comum entre desenvolvedores de software agropecurio das mais diversas origens, permitindo assim uma
classificao e busca mais precisa dos mais diversos tipos de componentes de software relacionados ao
domnio. Usurios do domnio agropecurio podem se beneficiar de informaes deste domnio e de outros
relacionados, como o domnio da alimentao, entre outros. importante que informaes pertinentes a todos
os domnios relacionados, que possam ser utilizadas, sejam apresentadas ao usurio, particularmente quando
eles no esto cientes de sua existncia.
Para facilitar o entendimento, ser analisado um exemplo mais detalhadamente. Considere um usurio que
est desenvolvendo uma aplicao no domnio Agropecurio e quer saber informaes sobre componentes
previamente desenvolvidos pertencentes a este domnio. Assim, ele pode usar a interface GOS, no contexto
do sistema SBS-AGRO, para saber sobre a disponibilidade (ou no) deste tipo de informao, e recuperar a
informao certa. Para apresentar o exemplo, consideramos o uso de 2 mediadores, que representam
ontologias no domnio agropecurio e alimentao (Figura 4.1). A cada um destes mediadores, esto
associadas bases de componentes relacionados aos domnios em questo.
Considere que, quando o Mediador do Agropecurio foi registrado, ele foi associado ao Mediador de
Alimentao, uma vez que possuem componentes relacionados, como por exemplo, componentes sobre
alimentao ou nutrio, muito importante atualmente no domnio agropecurio. Assim, quando o usurio
acessa a interface para recuperar informaes (i.e., informaes sobre componentes disponveis ) do domnio
Agropecurio relacionadas, por exemplo, a Nutrio, ele pode querer acessar informaes pertencente no
somente ao prprio domnio, mas tambm dos mediadores relacionados, isto , informaes neste caso,
pertencentes ao domnio de Alimentao. Como pode ser visto a seguir, o sistema GOS permite que isso seja
feito de modo semi-automtico.
GS GOS Servidor GOA

Servidor GOA (Metadados
(Metadados + de Dominio)
Componentes)
Mediador Mediador Servidor GOA

Agropecurio Alimentao (Metadados +
Componentes)
Figura 4.1: Ontologias do domnio Agropecurio e Alimentao
4.1 Relacionamentos Intraontolgicos
Suponha ainda que o usurio decidiu recuperar in formaes relacionadas ao termo ontolgico
Gerenciamento, do Agropecurio. Pela estrutura da arquitetura GOS, usurios podem ento procurar
informaes de um modo transparente e uniforme. Os usurios no tm que saber onde as informaes so
armazenadas e nem saber como ter acesso s fontes de dados.
Num primeiro momento, o especialista que cadastrou a ontologia pode no ter efetuado o estabelecimento
completo de relacionamentos de cada um dos termos desta ontologia, ou seja, alguns relacionamentos de
termos na prpria ontologia ou entre ontologias podem no ter sido descobertos. Com isso, quando o usurio
resolver buscar informaes relacionadas a Gerenciamento do Agropecurio, possivelmente um conjunto
menor de informaes ser encontrado: Gerenciamento tem como sinnimo, o termo Administrao (Fig.4.2).
Agropecurio
Agropecurio
Administrao Administrao
Administrao de
Propriedades Rurais
Comrcio
Comrcio de Animais
Gerenciamento
Gerenciamento de Animais
Gerenciamento de Fazenda
Gerenciamento de
Rebanho
Inseminao
Nutrio
Figura 4.2: Relacionamentos Intraontolgicos antes do uso do GOS

Usando a interface GOS, aps o administrador ter efetuado o estabelecimento de novos relacionamentos,
atravs do mecanismo de inferncia e da base de regras, pode-se obter um conjunto maior de informaes,
pois relacionamentos que num primeiro momento no foram contemplados pelo especialista, podem ser
descobertos (Figura 4.3): Gerenciamento tem como hipnimos os termos Gerenciamento de Anima is,
Gerenciamento de Fazendas, Gerenciamento de Rebanho e Administrao de Propriedades Rurais. Assim o
GOS recupera a informao de componentes relacionados ao domnio de um modo mais completo,
transparente e uniforme.
Agropecurio
Agropecurio
Administrao Administrao
Administrao de
Propriedades Rurais
Comrcio
Comrcio de Animais
Gerenciamento
Gerenciamento de
Rebanho
Inseminao
Nutrio
Administrao de
Propriedades Rurais
Gerenciamento de
Rebanho
Figura 4.3: Relacionamentos Intraontolgicos depois do uso do GOS
4.2 Relacionamentos Interontolgicos
Suponha agora que o usurio decidiu recuperar informaes interontolgicas, relacionadas Nutrio (do
Agropecurio), ou seja, alm das informaes do termo contidas no prprio Mediador do Agropecurio, o
usurio gostaria de verificar a existncia de informaes relacionadas Nutrio no Mediador Alimentao.
Neste caso, acontece o mesmo problema que no anterior. Inicialmente, um conjunto menos completo de
informaes relacionadas Nutrio, do Mediador Agropecurio ser mostrado ao usurio. Alis, neste caso
inicialmente nenhuma informao relacionada existe. Isso acontece pelo mesmo motivo citado acima: no
cadastramento dos termos, nem todos os relacionamentos so mapeados (Figura 4.4).
Agropecurio
Alimentao
Administrao
Administrao de
Propriedades Rurais
Comrcio
Comrcio de Animais
Gerenciamento
Gerenciamento de
Rebanho
Inseminao
Nutrio
Figura 4.4: Relacionamentos Interontolgicos antes depois do uso do GOS
Assim, usando a interface GOS, para obter os relacionamentos interontolgicos, pode-se obter um conjunto
mais completo de informaes, com este novo mapeamento. Pela Figura 4.5, pode-se observar a existncia de
termos pertencentes ao Mediador Alimentao relacionados Nutrio do Mediador Agropecurio: Nutrio
Animal (Sinnimo), Rao, Pastagem (Hipnimo). Isso acontece devido ao estabelecimento de novos
relacionamentos a partir do conjunto de regras e do mecanismo de inferncias mencionado anteriormente.
Agropecurio
Alimentao
Administrao Nutrio Animal

Administrao de
Propriedades Rurais
Comrcio
Comrcio de Animais
Gerenciamento
Gerenciamento de
Rebanho
Inseminao
Nutrio
Rao
Pastagem
Figura 4.5: Relacionamentos Interontolgicos depois do uso do GOS
5. Concluso
Atualmente, desenvolvedores, pesquisadores, pro fessores e pessoas interessadas no setor agropecurio

buscam diminuir a resistncia desta comunidade na adoo de novas tecnologias. Existem, na Web, vrios
web sites onde so apresentados diversos softwares voltados para o setor de software agropecurio. Com o
objetivo de facilitar a obteno destes softwares por parte dos agropecuaristas, alguns destes disponibilizam
sistemas de busca dedicados a este setor. Porm, a maior parte destes mecanismos de busca no muito
eficiente, exigindo um esforo maior do usurio e apresentando uma grande quantidade de resultados
irrelevantes. Um sistema de busca por componentes de software agropecurio mais eficiente pode contribuir
bastante para o processo de informatizao do setor, reduzindo consideravelmente o esforo do usurio na
procura de um produto que o atenda.
O prottipo GOS, baseado em mediadores e ontologias, foi desenvolvido para ajudar na busca e
identificao da informao apropriada. Para auxiliar na identificao de informaes relacionadas aos
componentes de software e seus domnios apropriados, cada mediador inclui uma ontologia e prov o
mapeamento para repositrios de informaes relacionados ao domnio.
Neste artigo, foram apresentados a arquitetura GOS e um exemplo do seu uso junto ao sistema SBS -AGRO
no domnio agropecurio. Usurios podem se beneficiar de informaes deste domnio e de outros
relacionados. Assim, informaes de todos os domnios relacionados, que possam ser utilizadas, so
apresentadas ao usurio.
Usando o GOS, o usurio pode obter um conjunto maior de componentes relacionados, pois informaes
que num primeiro momento no foram contempladas pelo especialista, podem ser descobertas atravs do
mecanismo de inferncia e da base de regras. Assim, o GOS recupera a informao ontolgica de cada
domnio relacionado ao domnio pr -determinado de um modo mais completo, transparente e uniforme.
O sistema GOS est sendo integrado a uma biblioteca de componentes para Educao a Distncia (EAD),
j tendo sido especificada uma ontologia para o domnio [18] e atualmente o trabalho se concentra na
especificao de novas regras mais especificamente ligadas ao domnio de EAD.
[1] Guarino, N., Ontology -Driven Conceptual Modelling: Advanced Concept, ISBN:3-540-44277-4, 2002
[2] Brown, A., Wallnau, K., The Current State of CBSE, IEEE Software, Setembro/Outubro, pgs. 37-46, 1998
[3] COMPONENTSOURCE, Disponvel em www.componentsource.com, (ltimo acesso: 12/12/2003)
[4] Inoue, K., Yokomori, R., Fujiwara, H., Yamamoto, T., Matsushita, M., Kusumoto, S., Component Rank: Relative
Significance Rank for Software Component Search, 25th International Conference on Software Engineering,
Portland, Oregon, Maio, 2003
[5] Silva, A. P., Alves, J. W., Braga, R., Campos, F., SBS-Agro: Sistema de Busca Utilizando Ontologias e Retorno do
Usurio, XXVIII Conf. Latinoamericana (CLEI 2002), Uruguai, Novembro, 2002
[6] Oliveira, A. M., GOS: Servios de Ontologia na Integrao de Banco de Dados, Dissertao de Mestrado,
COPPE/UFRJ, Programa de Engenharia de Sistemas, Rio de Janeiro, Brasil, Maro, 2003
[7] Borgo, S., Guarino, N., Masolo C., Vetere, G., Using a Large Linguistic Ontology for Internet-Retrieval of Object-
Orient ed Components, Proc. of 9 th Int. Conf on Software Engineering e Knowledge Engineering (SEKE 97), pgs.
528-534, Madrid, Spain, 1997
[8] Christophides, V., Houstis, C., Lalis, S., e Tsalpata, H., Ontology-Driven Integration of Scientific Repositories, 4th
Workshop on Next Generation Information Technologies e Systems (NGITS'99), pgs. 190-202, Zikhron-Yaakov,
Israel, Julho,1999
[9] Andrade, H. C. M., Saltz, J., Query Optimization in Kess - An Ontology -Based KBMS, University of Maryland,
College Park, XV SBBD, Disponvel em: http://citeseer.nj.nec.com/388401.html, (ltimo acesso em: 08/04/2003),
Joo Pessoa, PB, Brasil, Out, 2000
[10] Nieto, E. M., Illarramendi, A., Kashyap, V., Sheth, A. P., OBSERVER: An Approach for Query Processing in
Global Information Systems based on Interoperation across Pre-existing Ontologies, International Journal on
Distributed e Parallel Databases (DAPD), ISSN 0926-8782, 8(2): pgs. 223-272, Abril, 2000
[11] Bayardo, R. J., Bohrer, W., Brice, R., Cichocki, A., Fowler, J., Helal, A., Kashyap, V., Ksiezyk, T., Martin, G.,
Nodine, M., Rashid. M., Rusinkiewicz, M., Shea, R., Unnikrishnan, C., Unruh, A., Woelk, D., InfoSleuth: Agent-
Based Semantic Integration of Information in Open e Dynamic Environments, Proceedings of the 1997 ACM
SIGMOD International Conference on Management of Data, pgs. 195-206, Arizona, Estados Unidos, 1997
[12] Erdur, R.C. Dikenelli, O., The Design and Implementation of a FIPA-Compliant Framework with a New Layer for
Ontological Behaviour, EMAG-2001-02, Relatrio Tcnico, Ege University, Turquia, 2002.
[13] Braga, R. M. M., Mattoso, M.L.Q., Werner, C.M.L., The Use of Mediation e Ontology Technologies for Software
Component Information Retrieval, Proceedings of ACM Symposium on Software Reusability (SSR01), pgs. 19-
28, Toronto, Ontario, Canad, 2001
[14] Wiederhold, G., Mediation to Deal with Heterogeneous Data Sources, Proc. Interop'99, pgs. 1-16, Disponvel em:
http://www-b.stanford.edu/pub/gio/1999/Interopdocfigs.html, (ltimo acesso em: 08/04/2003), Zurich, Maro, 1999
[15] Souza, R.P; Costa, M.N; Braga, R.M.M; Mattoso, M; Werner, C.M.L, Software Components Retrieval through
Mediators and Web Search, Journal of Brazilian Computer Society, Vol.8, No.2, pgs 55-63, ISSN 0104-6500,
Brasil, Novembro, 2002
[16] Oliveira, A. M., Souza, R. P., Braga, R. M. M., Mattoso, M. L. Q., Werner, C. M. L, Uso de Mediadores e
Ontologias para Recuperao de Componentes de Software, WDBC 2002, Workshop de Desenvolvimento Baseado
em Componentes, Itaipava, Rio de Janeiro, 2002
[17] GOA, Disponvel em: http://www.cos.ufrj.br/~goa (ltimo acesso: 15/12/2003), 2003
[18] Santos, N., Campos, F. Braga, R., Ontologia para o Domnio da Educao Mediada pela Web, In: 8 Taller
Internacional De Software Educativo, Santiago , 2003
!
!
"
#$%#& '! ()%*&+,
! "
# $ #
# !% "#
" & & # %
' %
( ) ) * +,
-
.
/ 012 3 #) 0 . /30 4 (
5 6 + ! . 7
% " %
" ( # )
) 7 ! % .
# ) # ) . " 89: 5 6 +
" &
# ) # )
. ( " ! "#
$ " % .
$ 0 # ( " # "
!
)
) "# )
. "
; ! 89: ) 7 )
%" ! "
9
( ! + " $0< =63> ?@A6B@ "
! ( ) # !
" .
! # # % #
. 2 ) % - 2
+ ;
! % 0 # ) 2 "
) # ) 89: # )
! ! . # . & # 2
& & " %
% # ) %
; ) " $
7 C=2 *C 6= 2 " ,% ==2 *= = 2 " ,%
=2D *= # ! 2 D #, % 2 / 5 *2 6 /
5 , % C=5D *C 6= 5 D , % C 5$(> *C 5 6 2 $
( # #> , " C=2 2 # - )
+ $( " & E # "
. ) + 89@:
( 5 6 + . 7
% " (
. + #
% "
" ! #
% & # .% .
" # - " ! .
! "
( ! " +
# 7 ; % +
"# . )
( 5 6 + & 7 ; 4
0 # ) * 5 6 0 +, " )
; 4 0 # ) * 5 6 0+,%
; " 56 +
C %( % "C 3 % ; ! &
% "5 * F , )
* , 2 # % D D 0 8@: "
C G ) 89:% # . "
/ . +* 5 6 / +, ( "
# . 7 /+ */ . " ,% /5 */ . ,% $H
* # ,% / */ . # . , "/ */ . F .,
( % 0 + 0+% 8A: %
; " !
5 6 + &
% 5 60 + " 5 60+ !
; ; 5 60 +%
0 +" & .
5 60+% 5 6 + 0+ (
.
" ! . # .
. - " 2
5 60 +
! "# $ %
C=2 8I: - . " -
) 5 " .
" C=2 " ) * ,7 .
" # C=2 7 - %
) ! # %( D
%
J % D % *, *,
. 8?: 5$(> *5 62 $ ( # #
> , 8K:8L: ! . # %
! C=2 "=2D , " !
" # !
M % " ! 5$(>
& ==$( *= 6= $ ( # #, " # ) #
== >+5 *= 6= > + 5 # #, 8N: 5$(>
# 7 C "( # #*
,% $" ( # #* ! ,% "
$" ( # #* ,
" ! . 89:
&
+ # ) +"
.% % . " . + 8O:
+ "
+ # .
++ "
+ +
)
Obtener requisitos del

productos a partir del
modelo derequisitos los GR::Gestion
del dominio(LP) Administrar
adjunto Requisitos
Modelo de
Requisitos
Modelos de Diccionario
Modelo de Modelo de
Aspectos Del
Casos de Uso Objetos
Del Dominio Dominio
!' ! ( %( !' )
!
( # # 9% "
0 +% 0 +% " 0 +
. 0 + 0+%
" 0+ 5 60+ 2 #
# .% # .
# @ % %
! # 7
& ' $ ( ) 89B:

# & .
- $ #
% * +
# & % !
# & % . "#
& # & .
( $
$ (
& ) #
. % " 89B: "
(
* , " * ,
. " (-
)
$
& ) ) %
) % # , 8I: (
. +
) +"
+ (
%
% %
; + (
* - .
/ / ) & % "
% . % " (
& "
# . /5
( 0 +0 # "
D ( #
# & % % "
+% D 5 %
. & . " $0< =63>%
$0< =6 +
"# $ *
' +
( " $0< =63> . .# # "

2 6 . + #
"+ . 3 . "
" .# % . " '
# . " . "
2 )
' # & # " %
#;
D $ . -
. 0 + 5 + " $0< =63>
- +
# " $0< =63>% - "
% # &
) ) $0< =6 +7 $0< = 63>% $0< = 62 "$0< = 4
# %2 . (
# & C# A% ! ; )
% # ) % !
" ! . (
" )
2
! . # %
0 +% 0+ " 899: ( C# I !
! % .%
) 0+ (
% - ) % !
#) % D -%
(=+$% * (- $" $ ,% 0+$ * # # 0 # $" ,% &
. ) ;
" #)
% # % % # "
% % %
!' - "# $ !' / - "# $

.
$ #% " %
) 8I:% & % )
( &
) "
- 5 6 +%
0 +" 0+
" )
0 + 0+ # # ! .
% )
!' , ) (
( " . ) % "
0 +" 0+ ) 7
" % ) )
#; . ) %
% " . %
" * #,
) ) ( $0< =6 +%
) - #
) ! # & %
- . % D& $0< =6 + !
& # $0< =63> - .
+ 0+
/ 01 % ( .
( ) - . %
" 5 6 +
" ! )
# ) 7
-. # ) " . (
% )
& " .
8I: " . $ #
5 6 + .% "
. ( " %
% ) % ! .
" 3 &
- 5 6
0+% ) ! # 5 60 +% ' )
.% # ! D
) ( D @ B" - &
! D 5 6 + (
% )
! .% # "
# ) "
, . 2% ' .
89: %+P< % $ + 7+ + > %D 7 6Q "% @BB@
8@: $ ( # #0 DD0 * "D "D R 0 # , 2 .7

7FF F F
8A: $ ( # #0 C G $ + + I9 2
.7 7FF F F G
8I: E #% E S % $S % S< G% Q SP + % C 6= 2 " *C=2 , C "

$ "* D F $(06OB6356B@9% 2 @A?LN?, + #% + 7 $ ( # #0 % # D
"% 9OOB
8?: / ) C S> % S # % D# P D !% D 0 3& 4 3

5 2+3=0 6036@BB@6BBI D ! % @BB@
8K: / % D *9OOK, T2 ( # # " 5 62 $ ( # #> U

= D # ! % K*L,
8L: %0 S/ % D P %+ G$ 5 7 %+ % =# !
> $ < J G% <J7 Q " # % 9OOL
8N: G% / "S2 % + GSE #% E" SP 3 % $ + " 7 +

0 * D F$(06@BB96356BB9, + #%+ 7 $ ( # #0 % # D "%
@BBB
8O: < # % D 9ONI 3 2 # 0((( 3

$ ( # $(60=% ? *$ ,% ?KI ?LI = # "< # 89ONA:
89B: %0% %D% % + "V # % / *9OO@, T= = $ ( # #7

2 U 6Q "
899: D % S % P 0 > #H " 5 ( # #

$(E(W@BB@ 9L@
89@: G % 2 GD #7 ( # 5 " # + 3 #" 0 $5 @BB@

OA69BN
Aplicacin de una Metodologa de Ingeniera de Requisitos a un Caso

Real1
Alberto Restrepo V., Raquel Anaya de P., Mnica Henao C.

Universidad EAFIT, Medelln-Colombia,
{arestrep,ranaya,mhenao}@eafit.edu.co
Resumen
En este trabajo se presenta la experiencia obtenida con la aplicacin, a un caso real, de una metodologa
de Ingeniera de Requisitos elaborada por Amador Durn en su tesis doctoral[2], junto con su
herramienta de apoyo al proceso. La empresa seleccionada es una casa de desarrollo de software de la
ciudad de Medelln, certificada en el nivel 5 de CMM. La experiencia demostr que la aplicacin de la
metodologa y la herramienta mejor el proceso de desarrollo de software.
Palabras clave: Ingeniera de requisitos, elicitacin de requisitos, gestin de requisitos,

metodologas de ingeniera de requisitos.
1. Introduccin
La Ingeniera de Requisitos es una rama de la Ingeniera de Software, que tiene que ver con el
entendimiento en una forma ordenada de lo que se requiere en un sistema software por parte de clientes y
usuarios. La Ingeniera de Requisitos direcciona el proceso de elicitacin, definicin, modelado, anlisis,
especificacin y validacin de los requisitos de un sistema y de su software, basado en un enfoque
sistemtico, separando el "que" del "como" del diseo. Cada una de estas actividades se considera como
crtica dentro del desarrollo de sistemas de informacin, pues los errores no detectados en las primeras
etapas del proceso de desarrollo pueden tener amplias repercusiones en fases posteriores. Por lo tanto,
disponer de un modelo de procesos acompaado de una herramienta para la gestin de requisitos es un
avance importante.
En este artculo se presenta el caso de estudio y las conclusiones del mismo. Por ltimo se incluye un
numeral con el trabajo futuro y recomendaciones consideradas.
2. El Caso de Estudio
La metodologa y la herramienta fueron utilizadas en un proyecto cuyo objetivo principal fue el de
probar una metodologa de Ingeniera de Requisitos y evaluar la herramienta REM que acompaa la
metodologa frente a la administracin de requisitos en un proyecto real, con fin de validar su aporte en
los proyectos de software.
La empresa proveedora es una de las industrias de software de mayor trayectoria en Colombia

dedicada al desarrollo de aplicaciones tanto genricas como a la medida en el rea financiera; la empresa
cuenta con un proceso de software establecido y ampliamente soportado por las mejores prcticas de
software. Recientemente alcanz la certificacin de CMM nivel 5. Esta empresa utiliza la aproximacin
de orientacin por objetos con UML[3] junto con la propuesta de procesos definido por el RUP(Rational
Unified Process) con sus fases de concepcin, elaboracin, construccin y transicin.
1
Este trabajo ha sido parcialmente financiado por el proyecto internacional WEST de CYTED VII
Por la naturaleza iterativa del proceso, la elicitacin de requisitos se realiza a lo largo de todas las
fases. No obstante, se puede afirmar que la mayor parte del esfuerzo en la definicin de requisitos se
realiza bsicamente en la fase de elaboracin. En este caso, se dedic un 55.53% a este esfuerzo. Es aqu
donde juega un papel fundamental, la metodologa de Ingeniera de Requisitos propuesta para el estudio.
La experiencia de aplicacin, permiti que se hicieran unas observaciones y sugerencias para los
creadores y de la metodologa y de la herramienta,. Adems, a travs de este caso, los investigadores
queran obtener indicadores que permitieran comprobar el grado de contribucin de la metodologa al
proceso de desarrollo de software. Tanto la metodologa como la herramienta de gestin se utilizaron en
un proyecto de banca en lnea. Se sigui un esquema de trabajo complejo ya que tanto clientes como
usuarios no estn radicados en la ciudad sede de la compaa desarrolladora, por lo que las actividades
planteadas en la metodologa se tuvieron que llevar a distancia, salvo algunas visitas en el sitio por parte
de los desarrolladores.
2.1 Alcance del sistema software desarrollado
El proyecto en el cual se hizo la experiencia tena por objetivo el desarrollo de un nuevo producto para
el rea financiera llamado Sistema Banca en Lnea Empresas(BOLE). Dicho sistema consta de tres
mdulos generales. El mdulo de seguridad que permite definir los usuarios y los roles de usuario que
pueden realizar alguna transaccin, adems de las reglas de seguridad para aprobaciones de ciertas
transacciones. El mdulo de bancos en el que se puede realizar la administracin de la informacin
referente a las empresas y grupos de empresas registrados en el servicio de Banca en Lnea, los productos
registrados para cada una de las empresas, usuarios, etc. El mdulo transaccional que permite a las
empresas registradas realizar las transacciones bancarias, como transferencias de fondos, pagos en
lote(nmina, proveedores), pagos a terceros, administrar los productos con los que cuenta la
empresa(tarjetas de crdito, chequeras, etc.), realizar consultas de movimientos y saldos.
El sistema contiene en total 124 casos de uso, clasificados de acuerdo con la funcionalidad que
representan: lgica del negocio, consultas, servicios de apoyo, etc. De estos casos de uso, 13 se
consideraron relevantes a la arquitectura. Uno se consider de alta complejidad mientras que los restantes
se catalogaron como de complejidad media. El de alta complejidad es responsable de las aprobaciones y
maneja el proceso principal.
2.2 Aplicacin de la metodologa
Con base en las actividades planteadas en la metodologa desarrollada por el profesor Durn[2], la
empresa realiz las diferentes actividades y utiliz REM para la documentacin . Posteriormente, los
investigadores elaboraron un instrumento de investigacin que contena una seria de preguntas
relacionadas con las actividades y la herramienta, con el fin de obtener ms informacin referente a los
resultados que las organizaciones obtuvieron de la utilizacin de los elementos de estudio.
2.2.1 Elicitacin. Para la elicitacin de requisitos se trabaj con un cliente y cuatro usuarios. La empresa
proveedora utiliza generalmente diversas tcnicas de elicitacin de requisitos dependiendo del proyecto.
Para este caso relacionado con el desarrollo de la solucin va Internet se utiliz primordialmente la
entrevista y solamente en algunos casos donde el nivel de complejidad y de detalle era mayor, se realiz
workshop de requisitos. En las otras dos empresas, se trabaj con clientes y usuarios internos.
Como resultado, se obtuvo el Documento de requisitos del Sistema(DRS) que genera REM.
En el caso de la empresa desarrolladora de software, segn los analistas, los beneficio obtenidos con la
utilizacin de REM se presentan a continuacin:
Facilita el seguimiento de los requisitos; todo requisito tiene como atributo el estado del mismo,
facilitando de esta forma su seguimiento.
Permite definir la matriz de rastreabilidad utilizando diferentes artefactos para su elaboracin (es
decir, permite cruzar objetivos con requisitos funcionales o no funcionales, con caso de uso,
etc.). Esto posibilita conocer fcilmente el impacto de un cambio en los dems requisitos.
Creacin de archivos html los cuales pueden ser publicados, facilitando de esta forma la consulta
por los usuarios que se encuentren geogrficamente dispersos, a travs de una pgina en Internet.
Los requisitos no siempre son obvios, ni es fcil su documentacin, la herramienta ayuda a la

persona que esta escribiendo un requisito, solicitndole la informacin mnima que debe
considerar al registrar un requisito.
2.2.2 Anlisis. La segunda actividad propuesta en la metodologa corresponde al anlisis de los requisitos
con el fin de detectar si se presentan conflictos entre los requisitos. En este estudio, se utiliz como
tcnica de anlisis el modelado con UML. Se elaboraron diagramas de estado y de casos de uso.
Se pudo evidenciar la dificultad que se presenta en establecer una frontera clara entre el anlisis de
requisitos y el anlisis del sistema y en la necesidad de que las metodologas establezcan objetivos claros
de alcance que diferencie dichas actividades.
2.2.3 Negociacin y gestin. La empresa proveedora utiliza internamente las mejores prcticas para la
negociacin y la gestin segn su experiencia. No hay un resultado explcito al respecto y se ha tomado
como parte del know how de la compaa. Por lo tanto, hemos respetado este factor y nos atenemos a los
resultados presentados.
3. Resultados obtenidos en los casos de estudio
Con el fin de tener unos resultados ms concretos sobre la aplicacin de la metodologa y la

herramienta, preparamos un instrumento de investigacin2 compuesto de un conjunto de preguntas
orientadas a detectar tanto en la elicitacin como en el anlisis el efecto de la aplicacin de la
metodologa y de la herramienta. propuestas en Durn[2].
Esto arroj como resultado lo siguiente:
Se confirma que el glosario de trminos es fundamental en todo proceso de ingeniera de

requisitos. Se reconoce la importancia del glosario de trminos como estrategia para lograr un
acuerdo en el vocabulario comn manejado por los diferentes participantes.
Considera La empresa el glosario de trminos que promueve la metodologa y posee la

herramienta, fue fundamental para que los participantes manejaran un lenguaje comn.
La empresa productora de software maneja un reporte de cambios al software, el cual suministra

informacin muy valiosa como el impacto no solo en el mbito de casos de uso, requisitos
funcionales, sino el impacto al nivel de desarrollo, esfuerzo estimado para el cambio, costos,
cambios en diseo y base de datos, etc.. Adicionalmente entrega tres documentos importantes (1)
la Matriz de Requisitos que es un documento que presenta una especie de sumario de requisitos,
con el estado, la persona responsable, el tipo de requerimiento, propia de la empresa, elaborada
en Excell; (2) la matriz de rastreabilidad y (3) la plantilla las reglas del negocio. Todos estas
plantillas son propias de la metodologa y fueron definidas por la empresa.
Se confirma que la metodologa ofrece la facilidad de realizar la rastreabilidad.
Se observa que la metodologa en estudio no ofrece guas que ayuden al analista en la definicin
de los requisitos no funcionales. Dada la importancia de una correcta definicin de requisitos no
funcionales, se espera que una propuesta del proceso de requisitos aplicable a una empresa debe
recomendar alguna de las clasificaciones de los requisitos dadas por diferentes autores, como
Pohl [5] y Sommerville y Sawyer [4] y establecer una gua prctica para su aplicacin.
Se pudo detectar que la empresas no llevaron a cabo la mayora de tareas de la fase de anlisis de
requisitos, por considerar que dichas tareas forman parte de la fase de anlisis del sistema. En
2
Consignado en el informe final de la investigacin: Aplicacin de una Metodologa de Ingeniera de Requisitos elaborado por
los autores de este artculo
esta fase se present dificultad en establecer una frontera clara entre el anlisis de requisitos y el
anlisis del sistema y en la necesidad de que las metodologas establezcan objetivos claros de
alcance que diferencie dichas actividades.
4. Una medida de mejora en la aplicacin de la metodologa

Dado que la complejidad de los requisitos de los proyectos comparados fue diferente pero los datos
manejados eran similares, se tom como base para comparacin y medicin de resultados, el nmero de
errores por tipo y por pgina al generar el documento de requisitos del sistema. La comparacin se hace
entre el proyecto en estudio donde se aplic la metodologa de Durn y otro proyecto ya realizado donde
se aplic una metodologa propia de la compaa. Weringa[6] ha propuesto algunas propiedades
deseables de los requisitos y son las que se han tomado para hacer la comparacin y aparecen en ambas
grficas en el recuadro. Los resultados se pueden observar en las figuras 4.1 y 4.2. Esta empresa maneja
un indicador basado en el nmero de errores. Consideremos que este indicador es una medida vlida para
determinar el aporte, de aplicar un proceso adecuado de requisitos, junto con sus herramientas, en la
calidad del producto software.
Proyecto previo Caso de estudio

11%Errores por tipo/pgina Errores por tipo/pgina
2% 6%
Incompleto 0%
7% Incompleto
Inconsistente 3% Inconsistente
2% 29%
Ambigo Ambigo
4% 49% Innecesario 31% Innecesario
Incorrecto 8% Incorrecto
25% No estndar No estndar
23% No conciso
No conciso
Figura 4.1 Errores por tipo en proyecto previo Figura 4.2 Errores por tipo en caso de estudio
Se puede observar en la figura 4.1, que el porcentaje de errores de tipo incompleto e inconsistente
corresponda al 74% del total de errores en los requisitos. Al aplicar la metodologa al caso de estudio,
figura 4.2, se encuentra que ese mismo tipo de errores alcanza un 37%. Esto significa que en el caso de
estudio la reduccin en este tipo de errores ha bajado al 50% de lo anterior, lo cual implica un beneficio
no slo de esfuerzo sino econmico.
5. Conclusiones
El reconocimiento en diferentes estudios de que la Ingeniera de requisitos es vital para ello, hace
fundamental el tener educacin formal e informal en este campo. Nuestra labor como investigadores y
educadores ha llevado a que en nuestros programas de pregrado y posgrado ofrezcamos el curso de
Ingeniera de requisitos con el fin de presentar a la comunidad informtica los benficos de una muy
buena Ingeniera de Requisitos. Adicionalmente, es importante continuar explorando y utilizando nuevas
herramientas que hagan que la gestin de requisitos sea ms fcil.
A pesar de que son pocas las organizaciones en nuestro medio que tienen un proceso explcito de
Ingeniera de Requisitos, y ms aun, pocas empresas modelan tanto la organizacin como los procesos,
hemos encontrado una organizacin que lo tiene y lo pone en prctica.
El primer aspecto a resaltar y que favorece los resultados es que las personas involucradas, contrario a
lo que se plantea en [6] no tenan experiencia previa en uno de los subprocesos de Ingeniera de
Requisitos: la elicitacin. Por lo tanto, la metodologa y la herramienta han servido de gua frente al
proceso.
El nivel de satisfaccin en relacin con la aplicacin de la metodologa y de la herramienta REM ha

sido por parte de todos los participantes, porque la forma de organizar y presentar la informacin a travs
de los archivos generados por REM, ha facilitado la comunicacin con cliente y usuarios; Para los
clientes, es muy fcil leer los requisitos y las posibilidades de navegacin dentro de los archivos ayuda al
proceso de revisin y aprobacin de los mismos.
El poder ir desde las caractersticas generales de los requisitos y llegar a las especificaciones
detalladas, facilita su validacin en cuanto a lo que requieren los clientes y los usuarios dada su
posibilidad de rastreabilidad.
Adicionalmente, la facilidad de manejo de un glosario de trminos ,permite manejar un lenguaje

comn y unificado y as evitar conflictos.
Otro aspecto importante de resaltar fue el tiempo de aprendizaje de la metodologa y de la herramienta.

El grupo de trabajo por parte de la empresa desarrolladora se retard en el inicio del proyecto mientras se
lograba una buena ambientacin tanto con el proceso como con el manejo de la herramienta. En la
actualidad, el mismo equipo declara que se ha ganado demasiado tiempo cuando han trabajado en un
proyecto nuevo.
A continuacin se presentan otras conclusiones relevantes que se han obtenido despus de realizar este
proyecto de investigacin. stas son el resultado, tanto del estudio de la Ingeniera de Requisitos como
del entorno metodolgico de Ingeniera de Requisitos para Sistemas de Informacin y de la herramienta
REM y su aplicacin.
A la pregunta: Cul es el beneficio de utilizar una metodologa para la Ingeniera de requisitos?, la

respuesta es que que el enfoque metodolgico, propuesto por Durn[2] y utilizado en este proyecto, es
apropiado para hacer el proceso de Ingeniera de Requisitos de un sistema informtico.
Esta metodologa de Ingeniera de Requisitos], se caracteriza porque est fundamentada en las tcnicas
y estrategias ms aceptadas para hacer la extraccin, el anlisis y la validacin de los requisitos de un
sistema informtico, lo cual garantiza que se pueda aplicar para cualquier tipo de proyecto informtico.
Se pudo comprobar que esta metodologa es buena, en la medida en que: proporciona las herramientas
especficas y apropiadas para la gestin de requisitos, plantea una serie de pasos a seguir e incluso unas
recomendaciones, y permite documentar el proceso utilizando la herramienta REM.
En cuanto a Cul es el beneficio de utilizar una herramienta para la gestin de requisitos?, la

herramienta REM es importante porque ofrece una serie de plantillas y un marco de referencia para la
especificacin de los requisitos independiente del diseo e implementacin del sistema
6. Recomendaciones y trabajo futuro
Aunque la metodologa ofrece un amplio cubrimiento de todas las actividades relacionas con el
proceso de requisitos en trminos de actividades y tareas, consideramos que le falta precisin en el
momento de entrar a sugerir o detallar tcnicas, estndares o guas especficas para el desarrollo de tareas
concretas. Sera importante proponer la estructura de clasificacin de requisitos no funcionales que se
sugiere adoptar a partir de propuestas como la de Sommerville[4] y Pohl[5]. En situaciones reales se
encuentra que los analistas concentran su esfuerzo en la definicin de requisitos funcionales y encuentran
dificultad en distinguir y expresar los requisitos no funcionales relevantes. Por lo tanto una gua precisa
en ese sentido sera muy til.
La seleccin y aplicacin de un modelo de requisitos particular, debe ser consistente con el tipo de
aplicacin o contexto en el cual se propone una solucin informtica. En nuestro caso estamos interesados
en estudiar y aplicar un modelo de IR que puedan ser utilizado en el desarrollo de software de apoyo a los
esquemas de educacin virtual para la educacin superior. La definicin de requisitos en aplicacin
orientadas al trabajo colaborativo requiere la aplicacin de un modelo suficientemente amplio y verstil
que enfatice aspectos como : (a) Diferenciacin entre la captura del requisitos del sistema de informacin
y la captura de requisitos del sistema software. (b) nfasis en la gestin del conocimiento ms que en la
gestin de la informacin. (c) nfasis en el manejo de mltiples vista de usuario. (d) nfasis en la
definicin de requisitos para el desarrollo de frameworks antes que en un desarrollo tradicional
Un trabajo que se puede hacer en un futuro inmediato es poder manejar una herramienta integrada que
combine tanto la gestin como la negociacin. Por supuesto, ya que hay propuestas como las presentadas
en [1] para mejorar el nivel de performance del proceso de Ingeniera de requisitos, es el alcanzar un nivel
de integracin entre diferentes y aisladas herramientas.
7. Referencias
[1] Aurum, A and Wohlin, Claes. Applying Decision-Making Models in Requirements Engineering. Eighth
International Workshop on Requirements Engineering: Foundation for Software Quality, Essen, Germany, 2002.
[2] A. Durn. Un Marco metodolgico para la Ingeniera de requisitos de Sistemas de Informacin. PhD tesis,
Universidad de Sevilla, Espaa. 2000
[3] G. Booch, J. Rumbaugh, and I. Jacobson. The Unified Modeling Languaje User Guide. Addison-Wesley, 1999.
[4] I. Sommerville y P. Sawyer. Requirements Engineering: A Good Practice Guide. Wiley, 1997.
[5] K. Pohl. Requirements Engineering: An Overview. Encyclopedia of Computer Science and Technology, 36,
1997. Disponible en http://sunsite.informatik.rwth-aachen.de/CREWS /reports96.htm.
[6] R. J. Wieringa. Requirements Engineering: Frameworks for Understanding. John Wiley & Sons, 1996.
Functional Entity-Relationship Modeling
Simone Santini
University of California, San Diego
ssantini@ncmir.ucsd.edu
Abstract
Databases containing abstract data types often present a dichotomy between the conceptual model in
which the queries are expressed and the representations that are stored in it. Many a data type, in fact,
are routinely stored using simplified representations (often called features), which are used to efficiently
answer certain classes of queries.
The problem of querying a database with representation is in many ways related to that of querying a
database containing views, but differs in several important details since the entities, relations, and attributes
of the representations are not subsets of those in the model, but are functionally related to these. This
paper presents a functional entity relation model, and shows how this model is adequate to describe the
relations between a conceptual model and its representations, and how these relations can be applied to
query rewriting.
1 Introduction
In this paper, we are interested in a particular area of conceptual modeling, one that comes into existence
when the target of the model is a database system that deals with abstract data types, especially when the
underlying structure of these data is complicated (think, to fix the ideas, of geometric or image data).
This kind of modeling is always subject to a tension between the need to define the model at the conceptual
levelignoring the implementation aspects of the dataon one hand, and, on the other hand, the need to
consider different representations in which these data (which we call the archetypes) come. we shall show
in this paper that by couching the model into a functional language one can create a formalism in which this
tension is resolved quite naturally: it is possible to create the model at the conceptual level (that is, at the
level of the archetypes), delegating much of the concern for representation to an automatic rewriting system.
The main problem is dealing with representations is that they often have a way to percolate at the con-
ceptual level: in many an object oriented model for data bases, for instance, one sees that the attributes of an
object (that is, in a sense, its implementation) are part of the conceptual model. In this sense, classes cease to
be abstract data types, since their definition is open for every-one to see. Such a choice is bound to generate
problems when an object has multiple sets of attributes that interact in a complicated way and many of which
are used just as implementation devices, without any conceptual relevance.
Let us take the rather typical case of an image data type in which, for the purpose of querying efficiently
color distributions, one uses a color histogram [6]. The histogram is, in the sense in which the term is used in
this paper, a representation of the image. Relating the image and the histogram at the level of their attributes,
however, would be a very complicated (and probably futile) task: the elements of the histogram structure
(viz. the bins and their values) are the result of a complicated series of operations performed on the image,
and to find a correspondence with the elements of the image structure (viz. the pixels and their colors) would
be problematic to say the least.
In this paper, we shall assume the position that the suitable way of establishing a correspondence between
the two (and, in general between an archetype and its representations) is at the functional, or algebraic level:
both image and histogram should be considered as abstract data types, to be accessed only through their
algebras, and the correspondence should be established between these algebras.
We shall present a modeling formalism based on this idea, and prove some of its properties that are useful
for deriving, from a model expressed in this formalism, rewriting rules so that access to the elements of the
model can be done through their representations. The paper is couched in the language of data bases mainly
because the model is the brainchild of a data base environment, and of data base research interests; we have,
however, the presumption to believe that the same model can be useful in many different areas of conceptual
modeling.
2 The Model
Our model is essentially an entity-relationship one, derived from that in [3]. The main changes are a more
precise characterization of the role of functions, and a greater attention to the type system involved.
The fundamental type system T p(B) is defined in a rather standard way, starting from a set of (atomic)
data types B = {int, float, char, . . .}, and including functions as first class data types:
i) B T p(B);
ii) t1 , t2 T p(B) t1 t2 T p(B);
iii) t1 , t2 T p(B) t1 t2 T p(B);
iv) t T p(B) ({t} T p(B) {|T }
| T p(B) [t] T p(B) t(t) T p(B))
Here {t} is the data type of sets of elements of type t, [t] is that of their lists, {|t}|is that of bags, and t(t) is
that of trees. Note that t1 (t2 t3 ) (t1 t2 ) t3 through the isomorphism (1 (1 2 )) (2 2 ),
so we shant distinguish between the two, writing t1 t2 t3 or, in the general case, t1 tn , with the
projections 1 , n .
Also, in some cases, we shall use records with names in lieu of cartesian products. we shall write a
record, equivalent to t1 tk , as hn1 : t1 , . . . , nk : tk i, and, if x : hn1 : t1 , . . . , nk : tk i, then x.nh will be
equivalent to h (x).
The first important modeling element in this typing system is the class (or entity):
Definition 2.1. A class C is a data type
type C = int {pmq} hid : int, methods : {pmq}i (1)
where m : int , and , are arbitrary data types. The integer in the definition of C is called the
object identifier for that class, and the pmqs are the names of its methods.
Note:
A function f : can be represented as a member of the set . This element can be defined by a
mapping pf q : 1 such that, given the evaluation function : 1 , one has
1
pf qa
/ (2)
a

f
/
The mapping pf q is called the name of the function f .
Let C = {pmi q} be the set of all method names of the class C, and C = {C} be the set of all classes.
The complete type system can then be defined as T = T p(B) C2
1 The
evaluation function is defined as (f, a) = f (a) and is usually written in infix form: f.a
2 Note
that this type system doesnt allow composition of classes. If one desires them, then it is necessary to work with the system
W = T p(B C), but T will be enough for our purposes here.
S If t is a type, then dom(t) is the set of values for that type and, if T is a set of types, then dom(T ) =
tT dom(t). The definition set for aS function f : is def(f ) = dom()dom(), while the definition
set for a set of function is def{fi } = fi def(fi ).
For a class C, the set of collateral data types is defined as
L(C) = {|m : pmq C (m : m : } (3)
the corresponding domain is l(C) = dom(L(C)) With these quantities, it is possible to define an algebra
AC = (l(C), C ) , (4)
which we call the (multi-sorted) relevant algebra for class C, while

!
[
G = dom(T), C (5)
CC
is the general algebra of the model.
A morphism between classes is a pair [, ] : C C0 defined by the function : int int, and by
the algebra homomorphism : AC AC0 . The function maps identifiers of objects of C into identifiers
of objects of C0 , while maps the class operations.
Morphisms can clearly be composed, and there is an identity morphism, so they make classes into a
category [1] Class
Class.
Classes provide the first element of an entity-relationship model; my next goal will be to introduce rela-
tions into the model. We shall need several types of relations, so I shall introduce them in a rather general
setting. If C is a category, then a (binary) relation on C can be defined as a monic whose domain is C C 3
[7]. Let f be a sub-object classifier in C 4 , that is, loosely speaking, an object of C with two elements that
we can consider as representative of true and false. (we shant proof that the categories in which we am
interested have a sub-object classifier: they do.) Let 1 be the terminal element of C and, for a given object
c C, let !c be the (unique) morphism !c : c 1. A relation is then a pair (r : c C C, r : C C f)
(r monic) such that
c
r / C C (6)
!c r

1 /f
true
(In the following, often, we will only need either r or to characterize a relation. In this case, we shall
commit the imprecision of talking about the relation r or The relation .) The name of the relation,
pr, r q (or, informally, prq and pr q) is defined analogously to the case of functions.
We are interested, by and large, in two types of relations: relations between classes and relations between
objects of these classes. In the first case (the one which we shall mostly consider), C is the category of classes,
C, and the relations are structural relations between classes. In the second case, C is Set Set, and its elements
are sets of identifiers of objects that belong to a given class C.
* * *
Interlude:
In order to build complex functions out of the (atomic) methods in the class algebras, we shall need to
3 We shall only consider binary relations, the extension to n-ary relations being immediate.
4 Traditionally,the sub-object classifier of a category is denoted with the symbol . Since we already needed it to designate sets of
operation names in algebra, we have tried to avoid confusion by reversing it into f for the sub-object classifier.
introduce suitable functional operators to form a function algebra. Before doing so, however, since some of
these operators are based on structural recursion on collection types, a short introductory excursus on these
(a prelude to the interlude, if you want) is in order.
Collection types can be generated by structural recursion and, generally speaking, there are two different
ways of doing this (see [2] for a detailed treatment of this matter). The first way (insert recursion) includes
two operations: creates an empty collection, and +, adds an element to an existing collection. The second
way of generating collections (join recursion) consists of three operations: generates the empty collection,
s generates singletons, on combines two existing collections.
These two forms of recursion give rise to two separate collection algebras (//, , add), and (//, , s, o n
) for the given collection type. These two algebras generate two forms of structural recursion, (f, +), and
(f, s, o
n) for the applications of functions to collections. Let (//, 1 , +1 ), (//, 2 , +2 ), (//, 1 , s1 , o
n1
n2 ) be collection types, and f : . Then the two forms of structural recursion are
), and (//, 2 , s2 , o
defined as (using the operators in their infix form, x : is an arbitrary auxiliary parameter, and g : ):

(f, g, x, +2 )(1 ) = 2
(7)
(f, g, x, +2 )(a +1 x) = f (x, a)+2 (f, g(x), +2 )(x)
and
(f, x, s2 , o
n2 )(1 ) = 2
(f, x, s2 , o
n2 )(s1 (a)) = s2 (f (x, a)) (8)
(f, x, s2 , o
n2 )(x on1 y) =(f, x, s2 , o n2 (f, x, s2 , o
n2 )(x) o n2 )(y)

The operations of the function algebra are defined in Table 1.
Operation Definition
f g (f g)(x) = f (g(x))
hf, gi hf, gi(x) = (f (x), g(x))
f g (f g)(x, y) = (f (x), g(y))
(f, x, g, +) (insert recursion)
(f, x, s, o
n) (join recursion)
if(P, f, g) if P then f else g
Table 1: Operators of the function algebra.
These operations also have names, which can be defined analogously to those of functions. Consider, for
instance, the operation
hf, gi : ( ) ( ) ( ) (9)
which can be considered an element of the power set
()()
T (h, i) = ( ) ( ) (10)
The name of this operation is the function ph, iq : 1 T (h, i) such that
h,iid
1
pf qpgqa
/ ( ) / ( ) (11)
ph,iqpf qpgqa .

T (h, i) / ( ) /

Given a set of function names , one can therefore define the function algebra F = (, ), where
is the set of the names of the functions of table 1. Given a set of variable names X, the term algebra of
F, (X) is the set of expressions that can be built using the names in and the variables in X. Every
assignment q : X , which assigns function names to the variables in X can be extended uniquely to a
homomorphism q : (X) F which evaluates expressions on the given functions.
End of Interlude
Interlude.
Let us now go back to relations between classes. Since the model that we are presenting here has a strong
emphasis on rewriting, we are particularly interested in relations by virtue of which two classes can, in spite
of their superficial differences, be used one in lieu of the other.
Definition 2.2. A class C0 subsumes a class C (C v C0 ) if for every pmq C there is an expression
em (X) (X) (with an assignment s : pmq 7 em (X)) and an assignment f : X C0 such that
1
pmqa
/ / (12)
O
sa u

(X) / /

fid
where u is an isomorphism.
Subsumption is an important concept for query rewriting because it allows one to rewrite (under certain
conditions detailed in the following) queries about entities of class C in terms of entities of class C0 : if one
requires attributes of C then object of class C0 can equivalently be returned, as long as C v C0 . Subsumption
is reflexive and transitive.
f
Two entity types, C and C0 are functionally equivalent (C=C0 ) if C v C0 and C0 v C. It is easy to show
that functional equivalence is, indeed, an equivalence relation.
A strong form of subsumption is inheritance:
Definition 2.3. A class C is said to inherit from a class C0 (C D C0 ) if there is a function i : C0 C such
that, for every pmq C0
pmqa
1 EE / (13)
EE EE
EE EE
E EE
i(pmq)a EE EE
" E"
/
Like subsumption, inheritance is symmetric and transitive.
Classes can be combined by taking the union of their algebras. The Cartesian product of classes C with
metods {m1 , . . . , mn } and C0 with methods {ui , . . . , uk } is defined as the class with methods
{m1 1 , . . . , mn 1 , u1 2 , . . . , uk 2 } (14)
The Cartesian product C C0 subsumes C and C0 and inherits from both.
In our model, we will also need to deal with objects belonging to the various classes. Let x : C be an
object of class C, and [, ] : C C0 a class morphism. This morphism can be applied to the object x,
transforming it into the object of class C0 = [, ](C) with object identifier (x.id). The morphism can be
extended in the obvious way to sets of objects E dom(C). The notions of subsumption and inheritance can
readily be extended to object sets.
In the case of relations between object sets, one can define a form of subsumption:
Definition 2.4. Let r1 : A E1 En and r2 : B F1 Fk be relations between n-tuples (resp.
k-tuples) of objects. The relation r2 subsumes the relation r1 (r1 v r2 ) if there is a monic f : A B and,
for each method m of E1 En there is an expression t (X) and an assignment f : X C1 Ck
(where F1 : C1 , . . . , Fk : Ck ) such that
A
r1
/ E1 E n m /T (15)
O
q g

B / F1 Fk / T0
r2
tf
where g is an isomorphism.
(In the following, as a shortcut, we shall write E1n for E1 En .) Two relations r1 and r2 are
coherent if they are defined on the same Cartesian product. In this case, it is possible to define a stricter
notion of subsumption:
Definition 2.5. Let r1 : A E1n and r2 : B E1n be two relations, then r2 coherently subsumes r1
(r1 - r2 ) if there is a monic q : A B such that
A
r1
/ E1n (16)
} >
}}}
}} r
q
}} 2
B
k
The diagram (15) induces a function r1 ,r2 : E1n 2F1 (we shall omit the subscript r1 , r2 in unless
necessary): for a tuple e E1n , (e) is the set of tuples f F1k that make (15) true. If subsumption is strict,
then such a tuple is unique, and one can write : E1n F1k . in which case, (15) becomes:
E1n
m /T (17)
O
g

F1k / T0
tf
In the case of relation, subsumption entails a criterion of comprehensiveness. In terms of sets, one would
say that the relation r2 is a subset of r1 . In our model, of course, it is not possible to characterize sumsumption
as subsethood, since the two relations may operate on different Cartesian products of entity sets. Never-
theless, a similar principle applies: for every tuple of objects for which the relation r2 holds, it is possible to
find a tuple of objects for which r1 holds and from which all the methods of the first tuple of objects can be
computed.
The following definition is useful to characterize such comprehensiveness.
Definition 2.6. Let r1 : A E1n , r2 : B F1k , r1 v r2 , and let : E1n f be a logic proposition on the
tuples of E1n . The proposition is the defining condition of r2 with respect to r1 if
A
r1
/ E1n
/f (18)
?

q

true
B / Fk
r2 1
where q is a monic.
The importance of the defining condition derives from the following proposition:
Proposition 2.1. Let e1 , . . . , en be a tuple of objects for which the relation r1 holds. Then there is a tuple
of objects q1 , . . . , qk for which the relation r2 holds, and such that (15) holds, if and only if the condition
(e1 , . . . , en ) is true.
Proof. If part:
Assume that (e1 , . . . , en ) is true. Then there is a A such that (r1 (a)) = true, and r1 (a) = e1 , . . . , en .
Since the diagram commutes, it is also true(r2 (f (a))) = true. In this case, r2 (f (a)) is the required tuple of
entities q1 , . . . , qk .
Only if part:
Assume by contradiction that (e1 , . . . , en ) is false, but a tuple q1 , . . . , qa for which (15) is true exists. In this
case, there is b B such that b = f (a) and true(r2 (f (a))) = true. On the other hand, since the condition is
false, it is P (r1 (i)) = f alse, contradicting the hypothesis that the diagram commutes.
Two relations are isomorphic if r1 v r2 and r2 v r1 . It is easy to see that in this case both the defining
conditions of r1 with respect to r2 and of r2 with respect to r1 are tautologies.
At this point, we are ready to give the definition of an entity-relationship model:

Definition 2.7. An entity relationship model is a triple (C, G, R), where C is a set of classes, G is a general
algebra for it, and R is a set of relation names.
Definition 2.8. A database is a triple D = (E, G, R) where E is a set of object sets, G is the general algebra
of their classes, and R is a set of relations. The database is an instantiation of a model (C, G, R) if every set
in E has type in C and every relation in R has name in R.
3 Representations
A model (C , G , R ) is a representation of the model (C, G, R) if the following conditions are true:
i) for every class C C there are C1 , . . . , Cn C in such that C v C1 Cn ; this set is called the
coverage of the entity class C, and is indicated as [C];
ii) for every relation name prq R with r : A Cn1 there is a relation name pr q R with r : B
[C]n1 , with such that r v r .
If all the relations r in point 2 are isomorphic to their relative relations r, the model is said to be faithful,
while if all the relation are strict, the model is also said to be strict. In some cases there can be classes for
which a complete covering does not exist, in the sense that some of their attributes cant be computed starting
from any combination of classes in the representation. In this case, we will say that the representation covers
partially the model. we shall assume that every class that cant be represented completely can be decomposed
as C = C0 C00 , where C0 is covered by the representation. The class C00 is the hopeless portion of C, and any
query involving attributes of C00 cant be answered with the given representations.
A collection of databases {Di = (Ei , G i , Ri )} is unified by establishing correspondences between entities
in the different databases. This can be done, for example, by assigning unique identifiers to corresponding
f
entities or by creating relation between an object eq1 of database q and objects ep1 , . . . , epn such that eq1 =ep1
epn . This correspondence is necessary for the insertion of join conditions in query rewriting [8],
a problem that we shant consider here. We shall just assume that a relation r exists among groups of
representations that refer to the same entity in the virtual dtabase.
A unified collection of databases is a representation of the (virtual) database D = (E, G, R) if the following
conditions hold:
i) for every object set E E there are object sets Eji Ei such that E v Eji ; the object sets Eji are called
the coverage of E, written [E];
ii) for every relation r : A E1 En in R there are relations ri : Ai E1i Eni such that
ii.a) [E1 En ] v i j Eji
S S
ii.b) r v r1 rn r
where r is the join condition that unifies all the representations of the same entities across databases in
the interested sets.
This definition guarantees that a representation allows the computation of all the methods of all the classes
and that the relations in the model are partially preserved, in the sense that, if a group of objects are related
in the representations, the virtual objects that they represent are related in the virtual database.
In order to simplify the notation, we shall ideally collect all the databases Di into a single database
D = (E , G, R ).

4 Query rewriting
In a typical database queries are given in terms of a model M = (C, G, R). The database, on the other hand,
contains but a series of representations {M1 , . . . , Mr }.
In a rather general interpretation, a query can be formally defined as a partial recursive function from
databases to databases [4]. This definition assume that the conceptual model is always isomorphic to its
representation. In our case, this is not true, and we must distinguish between an conceptual query and an
grounded query. A conceptual query is a partial recursive function from the set of models to a result schema
given by the signature of the set of attributes that the query requires. If Sr = (T1 , . . . , Tr ) is the result
schema, a query is a function Q : D Sr , where D = (E; R) is a database that instantiates the model M.
We shall write a query as:
(mi1 k1 (1 ), . . . , miu ku (u )) Rj1 (11 , . . . , 1n ), . . . , Rjp (p1 , . . . , pn ),

c1 (11 , . . . , 1m ), . . . , cv (v1 , . . . , vm ) (19)
where Rj are relations and cj are conditions.

Note that, in order to simplify the notation, we have assumed that all the relations are n-ary, and that all
the conditions depend on m variables. The variables i and ij take values in the set of objects, while the
variables ij take value in the set of methods. The database D = (E, G, R) is virtual: it is an ideal database
implementing the model. What we have in reality is a set of representations of the model Mq = (Cq , G q ; Rq )
and a database D = (E , G, R ) implementing them.
The grounding of a query over the database D consists in a representation morphism and a query
Q : D Sr such that there is a function f for which the following diagram commutes:
0
D
Q
/ Sr (20)
O
f

D / S
Q0 r
Query rewriting consists, given the ideal database D and a query Q, in the determination of a suitable set of
entity representations taken from the database D and a query Q0 which grounds the original query.
One way to transform the query Q into the query Q0 in a way that maintains the commutativity of the
diagram can be sketched as follows:
i) replace one relation of the model M with its representation taken from some of the representations Mi ;
replace all the methods in Sr that can be implemented in Mi with the corresponding representations;
ii) if no relations and no attributes are computed in terms of M, stop, otherwise repeat the previous step.
The substitutions of step 1 come from a set of possible substitutions called legal substitution opportunities,
defined as follows:
Definition 4.1. A legal substitution opportunity is a query fragment including one relation an w constraints:
Rk (k1 , . . . , kn ), c1 (11 , . . . , 1m ), . . . , cw (w1 , . . . , wm ) (21)
for which there is a representation Mq such that:
i) there is a relation Rq such that Rk v Rkq Rkq = q (Rk ),

ii) all the values of the variables that make c1 , . . . , cw true also make the defining condition Pkq true.
The legal substitution of Rk with the representation Rki is written as (Rk , c1 , . . . , cm ) (Rkq , c1 , . . . , cm )
or, if the conditions c1 , . . . , cn can be omitted without causing confusion, as Rk Rkq .
When we rewrite a query using a representation, it is important to guarantee that we dont lose the pos-
sibility of computing attributes. The following definition is related to the conditions under which this is
guaranteed:
Definition 4.2. A legal substitution
(Rk (1 , . . . , n ), c1 , . . . , cm ) (Rkq (1q , . . . , nq ), c1 , . . . , cm )
is non-disruptive if the following condition is true:
for each variable i : Ci that doesnt appear in any other relation but the relation Rk that is
being substituted5 , all the attributes can be computed from the entity types that appear in Rkq ,
that is, if iq : Cqi , then
Ci v Cq1 Cqn (22)
The rationale of this definition is the following: if the only relation in which the entity type Ei appears
is replaced with a representation which does not allow to compute the required attributes, then the attributes
can no longer be computed. Non-disruptiveness guarantees that all the attributes that can only be computed
from the replaced relation will be computable from the representation that replaces it.
The following property is the key for the application of substitution operations:
Q Q0
Proposition 4.1. Let D Sr be a query, and D D Sr be a partial grounding for it. Let
Q00
D D M n Sr be a query obtained from Q0 by a non-disruptive substitution (Rk , c1 , . . . , cm )
(Rk00 , c1 , . . . , cm ), then Q00 is a grounding of Q.
Proof. (sketch) Assume, for the sake of simplicity, that the relation Rk is binary: Rk (1 , 2 ), with 1 E1 ,
and 2 E2 , where E1 and E2 are object sets, and that the substitution contains a single condition c. Also,
assume that the entity classes of E1 and E2 do not appear in any other relation.
The query Q can be written as the composition of two functions: Q0 = f , where is the selection
function which selects the entities that satisfy the query condition, and f is the attribute computation function.
The function , in turn, can be decomposed as = 0 k . The function k produces the set of variable
assignments 1 e1 E1 , and 2 e2 E2 that satisfy (Rk , c1 , . . . , cm ), with their variable bindings,
while 0 will select those entities that satisfy all the other conditions and are compatible with the bindings of
Rk . The function can be written as : E1 E2 En E1 E2 En .
After the substitution, the relation Rk is replaced by Rk , which selects elements in E1 E2 . Because
of the properties of substitution, every pair in E1 E2 which make c true also make the defining condition
of the representation true, therefore, for every pair (e1 , e2 ) which would be selected by k , there is a pair
(e1 , e2 ) in Rk . It is therefore possible to define a function k : E1 E2 E1 E2 which selects the pairs
(e1 , e2 ) corresponding to the pairs (e1 , e2 ) selected by k , that is, a function k such that
E1 E 2
k
/ E1 E2 (23)

E1 E2 / E E
k 1 2
Defining = 0 k , one can show that : E1 E2 En E1 E2 En and that the following

diagram commutes
E1 En
k
/ E1 En (24)
idid

E1 E2 E3 En / E E E E
k 1 2 3 n
5 And, possibly, on join relations.

In other words, the selection function can be rewritten so that the output is composed of the same tuples of
entity, short of a transformation .
Since the transformation is non-disruptive, it is possible to rewrite in the same way the attribute computing
function f as f so that the following diagram commutes:
E1 E n
k
/ E1 En f
/ T1 Tn (25)
idid idid

E1 E2 E3 En / E E E E / T T E E
k 1 2 3 n 1 2 3 n
f
5 Model Instantiation
Given a conceptual model M = (C, G, R) with a corresponding virtual database D, representations Mi =
(Ci , G i , Ri ), and corresponding physical databases Di , the problem of instantiating the model is reduced to
that of replacing all relations named in R with relations named in some Ri using only legal substitutions, in
such a way that all the classes in C (which participate in the relations) are subsumed by one of the classes in
the Ci that have been used in the substitutions.
More formally, one can say that the purpose of rewritinggiven a query D
Q
/ Sr such that U =
{C1 , . . . , Cm } is the set of classes that appear in Q, and V = {R1 , . . . , Rn } is the set of relations that appear
in Qis to find a set (the minimal set, if we pose the related optimization problem)
P = R|Mi : pRq Ri

(26)
such that
i) R V , R : (R = R R P );
ii) R R is non-disruptive;
iii) C U Mi : (Ri P 6= Ci Ci : C v Ci .
What follows is a sketch of an algorithm for rewriting a query we shall described it using Dijkstras
guarded commands notation [5], with the with the addition of the loop forall, which iterates over all the
elements of a set. Moreover, we shall need quite a few additional data structures and functions. Firstly, we
shall assume that a query is a data type (which is left unspecified here) for which the following functions are
defined:
i) var(Q) returns the set of variable names that appear in the query;
ii) relations(Q) returns the set of relation names that appear in the query.
Moreover, if x var(Q), and t is an expression, then Q[x/t] is the query obtained from Q replacing all
occurrences of the variable x with the expression t, and if C is a condition, Q + C is the query obtained from
Q by adding the condition C.
We also need a structure to keep track of the replacements already made. To this end, we define the type
type replacements = {horig : C, repl : {R C}i} (27)
where, for each element of the set, orig is the class that is being replaced, and repl is the set of replace-
ments found so far from it, each one consisting of a representation class and the indication of the relation
where the class is used. The following functions are defined on this structure:
iii) has(A, C, r): returns true if A contains one or more representations for the class C that appear in the
relation r; returns false otherwise;
iv) add(A, C, C0 , r): adds the record hC, {r, C0 }i to the structure A. If a record with C as first element
already exists, adds the element {r, C0 } to the set of its representations;
v) repr(A, C) returns (nondeterministically) one of the representations of the class C; undefined if C hasnt
got any representation in A.
Other miscellaneous functions that we shall use are the following:
vi) cover(C, r) selects a class C0 such that C v C0 , and C0 is a class of the relation r;
vii) qexp(m, C, C0 ); given a method m of C, and a class C0 such that C v C0 , returns the expression (in C0 )
that implements the method m.
With these functions defined, the query rewriting algorithm can be rewritten as follows:
replace(Q : {query}, M : model, rep : {model}) query

A := ;
B := classes(Q);
L := relations(Q);
do L 6= r := elm(L);
r0 := choose(r, rep)
Q := Q[r/r0 ];
forall C in classes(r) do
if has(A, C, r0 ) C0 := repr(A, C, r0 );
forall (x, y) in var(q) var(Q) do
do (type(c) = C type(y) = C0 )
Q := Q +0 x.id = y.id0
od
od
has(A, C, r0 ) C0 := coverC, r0 );
add(A, C, C0 , r0 );
fi
forall pmq in C do
t := qexp(pmq, C, C0 );
Q := Q[m/t];
od;
B := B {C};
od
od
do B 6= error od
return Q
The main loop takes the relations of the conceptual model and replaces them one by one using legal
substitutions. Within this loop, the forall loop replaces all the classe within the relation being replaced
with their representations in r0 (unless the representation has already been introduced in the query before).
The set B contains, at the beginning of the algorithm, all the classes in the query and, each time a class is
replaced by a representation, it is removed from B. At the end of the algorithm, if B is not empty, then some
of the classes that appear in the query could not be represented, and the algorithm signals an error.
6 Conclusions
In this paper we have presented a functional form of the entity relationship model, suitable for expressing
models with abstract data types, especially for use in data modeling directed towards data bases. We have
introduced the concept of representations in such a model and shown how this concept could be used to de-
termine legal substitutions to translate a query from its model form to a query involving only representations.
Many problems in this kind of query rewriting are still open, including fundamental issues like the guar-
antee that legal substitutions will always find a grounding if such a grounding exist, or the determination of
groundings responding to some optimality criterion. All these issues will provide the subject of our future
work in this area.
References
[1] Andrea Asperti and Giuseppe Longo. Categories, Types, and Structures. MIT Press, 1991.
[2] Peter Buneman, Shamin Navqi, Val Tannen, and Limsoon Wong. Principles of programming with com-
plex objects and collection types. Theoretical Computer Science, 149(1):348, 1995.
[3] Andrea Cal, Diego Calvanese, Giuseppe De Giacomo, and Maurizio Lenzerini. Accessing data integra-
tion systems through conceptual schemas. In Proceedings of ER2001, pages 270284, 2001.
[4] A. Chandra and D. Harel. Computable queries for relational databases. Journal of Computer and System
Sciences, 21(2):156178, 1980.
[5] Edsger Wybe Dijkstra. A Discipline of Programming. Pearson Education POD, 1997. (paperback
edition).
[6] Amarnath Gupta and Simone Santini. Towards feature algebras in visual databases: The case for a his-
togram algebra. In Proceedings of the IFIP Working Conference on Visual Databases (VDB5), Fukuoka
(Japan), May 2000.
[7] B. Plotkin. Universal algebra, algebraic logic, and databases. Kluwer Academic Publishers, Dordrecht;
Boston, 1994.
[8] Simone Santini and Amarnath Gupta. Conceptual integration of multiple partial geometric models. In
2002, 21st International Conference on Conceptual Modeling Tampere, Finland, October 2002.
La Jolla, December 2003

Propuestas para Generacin de Cdigo y Diseo de una Herramienta

CASE Usando Tcnicas de Bootstrapping
Jorge Jimnez C.
Gerente de Investigacin y Desarrollo, Empresas TUXPAN, Chile
jota@tuxpan.com
Resumen
Desde 1997el rea de Investigacin y Desarrollo de las Empresas TUXPAN ha construido sus propias
herramientas CASE para apoyar el proceso interno de desarrollo de software. Actualmente se trabaja en el
diseo y construccin de Z4-CASE, en donde se propone nuevos conceptos y tcnicas de modelamiento de
sistemas y generacin de cdigo, basadas en el uso de patrones de diseo y UML. En este trabajo se
presentan esas nuevas tcnicas y se muestra cmo ellas se han usado en el desarrollo de la misma
herramienta CASE, usando tcnicas de bootstrapping. Adems se muestra cmo estas tcnicas mejoran la
productividad y calidad de las aplicaciones desarrolladas y facilitan en gran medida el desarrollo,
reutilizacin e integracin de componentes.
1. CONTEXTO
El proceso de desarrollo de software en las empresas TUXPAN se ha basado en los conceptos de Calidad y
Productividad. En este marco, el desarrollo de herramientas CASE por parte del rea de Investigacin y
Desarrollo de las Empresas, ha intentado satisfacer la siguiente premisa: En cada etapa del proceso de
desarrollo de software se construirn slo los subproductos que son directamente utilizados en alguna de las
etapas siguientes (o iteraciones siguientes) [1]. En la prctica esto significa que las herramientas deben ser
capaces de generar la mayor cantidad posible de cdigo y documentacin automticamente.
Los requerimientos para las herramientas CASE se han satisfecho usando las tcnicas de MDA (Model
Driven Architecture) [2] en donde los elementos de diseo de los sistemas son completados con informacin
especfica para las diferentes plataformas destino para la generacin de cdigo.
Si bien Z4 apoyar el proceso de desarrollo desde el modelamiento y rediseo de procesos de negocio

hasta la implantacin y mantencin de las aplicaciones, este trabajo se centra en la generacin de cdigo a
partir de informacin de diseo y especialmente en cmo se han usado estas nuevas tcnicas en la generacin
de la propia herramienta Z4-CASE.
2. Preparacin del ambiente de trabajo.
2.1. Decisiones iniciales
Uno de los requerimientos de esta nueva herramienta CASE fue su ejecucin en diferentes sistemas
operativos. Por ello se opt por desarrollarla en el lenguaje Java. Se decidi adems usar archivos XML como
repositorio para los datos de los modelos que se desarrollen. Se desech el uso de un repositorio basado en
bases de datos relacionales debido a los tiempos de respuesta requeridos para el despliegue de informacin
grfica y sincronizacin de modelos. El trabajo multiusuario es soportado por un administradores de versiones
concurrentes (CVS), en donde se mantienen versiones tanto de los metadatos (modelos) como de los datos
(cdigo de clases generadas, documentacin, archivos xml de apoyo).
Se decide adems que la herramienta CASE debe desarrollarse basndose en los patrones de diseo del
Model View Controller (MVC), Business Objects (BO), Value Onbjects (VO) y Data Acces Objects (DAO)
[3]. Adems se requiere que las aplicaciones que sean generadas usando Z4-CASE estn tambin basadas en
los mismos patrones de diseo. Para satisfacer ambos requerimientos a la vez (el de aplicar patrones en la
herramienta y en las aplicaciones que con ella se generen) se opta por disear y construir una biblioteca
(framework) que soporte estos patrones y que sea utilizada (extendida) por el cdigo de Z4-CASE y por el
cdigo que ella genere.
El uso de una biblioteca comn fue el primer indicador de que podra utilizarse bootstrapping para el
diseo y generacin de la propia herramienta.
2.2. TAF2: Biblioteca base para Z4-CASE y las aplicaciones generadas.
El objetivo de esta biblioteca es simplificar el desarrollo de aplicaciones que desean basarse en los patrones
de diseo de MVC, BO, VO y DAO. Al integrarse todos estos patrones en un biblioteca comn la interaccin
entre las diferentes capas de una aplicacin puede automatizarse en gran parte, ya que los objetos que
participan en estas capas son conocidos (sus tipos base). Por ejemplo, al desplegarse un objeto que extiende a
Value Object en una vista para su edicin, su controlador asociado es capaz de inhabilitar los controles de
edicin (patrn de Composite View) que despliegan atributos del Value Object que se han definido como
parte de su clave (Oid).
Algunas de las caractersticas principales de esta biblioteca son:

Implementacin del patrn de diseo del MVC, independiente de la plataforma de ejecucin: La
biblioteca incluye una herramienta para el diseo de las vistas y clases base para la
implementacin de los controladores. El diseo de las vistas se almacena como archivos XML
que son interpretados por un motor de ejecucin quien controla el despliegue y ejecucin, tanto
para plataformas de escritorio (java-swt, java-swing) como para ambientes web, con un motor
basado en java-servlets y el patrn de diseo del Front Controller.
Value Objects base (que se extienden en las aplicaciones) con capacidad para representar objetos
compuestos y relaciones de asociacin, capaces de escribirse y leerse desde archivos XML. Los
VO son adems capaces de describir su metadata e invocar indirectamente a sus servicios y el
acceso a sus propiedades.
Data Access Objects. TAF2 ofrece clases DAO que se utilizan como base en las aplicaciones para
implementar la persistencia de los Value Objects en repositorios relacionales. Los DAO ofrecen
servicios de consulta y actualizaciones del repositorio, basados en un lenguaje con caractersticas
de orientacin a objetos (soporte de especializaciones y navegacin por relaciones de agregacin
y asociaciones, con mapeo automtico a modelos relacionales).
3. Z4-CASE.
Z4-CASE se ha desarrollado usando tcnicas de bootstrapping. Esto significa que la herramienta CASE se
ha modelado y generado su cdigo usando la misma herramienta. Para lograr esto, partiendo desde una
versin inicial modelada y codificada manualmente, se hace una ingeniera reversa y se obtienen los modelos
UML de clases que representan al ncleo de la herramienta.
En el diseo de Z4-CASE existe un Package que representa a los Value Objects que sern los elementos de
modelado (artefactos UML) y un ambiente para el acoplamiento dinmico de bibliotecas. Estas bibliotecas o
PlugIns de Z4-CASE contienen los elementos finales de modelamiento y la lgica para la generacin del
cdigo. Por ejemplo, existen PlugIns para UML, Java, J2EE, Bases de Datos relacionales, etc.
3.1 Bees
Z4-CASE introduce el concepto de Bee (del ingls behavior o comportamiento). Un Bee representa a un
objeto activo (no slo agrega propiedades, sino tambin acciones) sobre algn elemento de diseo. Todos los
elementos de diseo (ModelElements) de Z4-CASE que se implementan la interfaz Beeable pueden tener
asociado Bees. Los Bees pueden especializarse y colaborar entre ellos para realizar acciones complejas, como
la generacin de cdigo.
Los diferentes elementos que un Bee puede aportar a un proyecto Z4-CASE son:
Nuevas propiedades para el elemento de diseo sobre el que se aplica. Por ejemplo, en la figura 6
se muestra la ventana de propiedades del Bee Value Object que se ha creado para la clase UML
Organisation. En esta ventana de propiedades, el diseador puede seleccionar los atributos de la
clase que definen el OID o clave de estos objetos.
Acciones. Operaciones especficas que se ejecutan en el objeto Bee y que pueden actuar sobre el
elemento de diseo que contiene al Bee o sobre otros elementos relacionados. Por ejemplo, el Bee
JavaClass publica la accin Generate Java Code. Las acciones publicadas por los Bees se
ofrecen en Z4-CASE como opciones disponibles en los mens de contexto.
Paneles: Editores o Paneles de ayuda que se integran al ambiente de Z4-CASE. Por ejemplo, el
PlugIn Java agrega un Panel para editar cdigo Java desde dentro de la misma herramienta.
Reportes.
Fig. 6: Ejemplo de propiedades que agrega un Bee
La generacin de cdigo Java para las clases en Z4-CASE la realiza el Bee JavaClass, el que se encuentra
en el PlugIn Java.
3.2. Generacin de Cdigo
En su forma bsica, el funcionamiento del generador de clases es el siguiente: El desarrollador indica los
atributos, las operaciones, las implementaciones de interfaces, especializaciones y asociaciones de una clase,
usando diagramas UML y las pginas que ofrece el elemento Class del PlugIn UML. El desarrollador debe
crear el Bee JavaClass dentro elemento de diseo Class, de UML. Despus de crear el Bee, en el men de
contexto aparecen las acciones de generar cdigo y abrir el editor de cdigo.
La accin de generar cdigo recorre cada una de las definiciones UML y genera los atributos de la clase y
los encabezados de sus mtodos. Este funcionamiento es equivalente al que ofrece la mayora de las
herramientas CASE. La diferencia que Z4-CASE ofrece es la utilizacin de otros Bees que aportan ms
informacin de diseo y generacin de cdigo a la clase.
El Bee JavaClass puede actuar en forma colaborativa con otros Bees generadores de clases. Es el Bee
JavaClass quien contiene la lgica de control de generacin de clases y quien invoca al resto de los Bees que
proveen informacin para la generacin.
Fig. 7: Jerarqua de Bees proveedores de informacin de diseo y generacin.
Un ClassBee provee informacin de diseo. sta corresponde a la declaracin de atributos, servicios,

interfaces implementadas y / o clase extendida. Con esta informacin el Bee JavaClass es capaz de generar
slo la declaracin de estos elementos en el cdigo final, pero no el cdigo dentro de los servicios.
Existen muchos casos en que el Bee que extiende a la clase abstracta JavaClassBee slo debe generar los
encabezados de los mtodos y no su cdigo. Por ejemplo, en el PlugIn J2EE se define el Bee EJBClassBee.
Este Bee declara los servicios ejbCreate, ejbRemove, ejbActivate y ejbPassivate, los que son necesarios para
la implementacin de la interfaz SessionBean, que define J2EE. En estos casos Z4-CASE generar slo los
encabezados de estos servicios para que el desarrollador final los codifique de acuerdo al comportamiento
deseado de los EJB de sesin que defina.
El mayor poder de generacin de cdigo se logra usando esta tcnica cuando el Bee generador de cdigo es
capaz de generar adems el cdigo de los servicios de acuerdo a informacin de diseo y a informacin extra
capturada usando sus pginas de propiedades.
Este poder de generacin y colaboracin entre Bees se muestra en el siguiente ejemplo:
Se desea disear una clase EJB (de J2EE) que acte como un DAO de taf2, para administrar la persistencia
de los objetos de un sistema de administracin de informacin empresarial.
El primer paso es crear una clase en un Package UML, por ejemplo MyDAO. A continuacin se crea el
Bee de JavaClass dentro de esa clase, ya que deseamos generar y editar el cdigo Java.
A continuacin se debe agregar a la clase el Bee StatelessEJBSQLDao, que provee el PlugIn de TAF2. Al
agregar este ltimo Bee aparece la accin de generar las interfaces Home y Remote requeridas por J2EE. Al
ejecutar esta accin, se crean dos interfaces dentro del mismo package y se asocian automticamente a la
clase EJB. Esta accin est disponible para el Bee EJBClassBee, y como el Bee StatelessEJBSQLDao lo
extiende, la accin tambin est disponible para el Bee Final.
Fig. 8: Ejemplo de un DAO definido por Bees
Para la clase MyDAOEJB se generan ms de 70 lneas de cdigo (que no se muestran ac por espacio), una
sentencia extends, una implements y varias sentencias import. Con esta generacin se obtiene un DAO TAF2
ejecutable y totalmente funcional, sin necesidad de programar manualmente cdigo Java.
3.3 Bootstrapping
El paso de hacer la ingeniera reversa sobre el cdigo manual se realiz despus de terminar la
programacin de las clases generadoras Java y las modeladoras de clases UML. De esta forma, las clases de
Z4, ahora modeladas en UML y dentro del propio ambiente de Z4, pueden generar su propio cdigo. En esta
primera iteracin del bootstrapping, slo se generan los encabezados de servicios.
El paso siguiente en el bootstrapping fue el diseo y generacin (ya usando Z4-CASE) de un PlugIn
especializado en la generacin de nuevos PlugIns. Un PlugIn Z4-CASE debe proveer una clase que
implemente la interfaz de PlugIn definida en el ncleo de Z4-CASE. El nuevo PlugIn para hacer PlugIns se
denomina z4-extensions y provee un Bee con especificaciones de generacin de clases que permite definir
una clase UML como un PlugIn Z4-CASE. Las propiedades de este Bee capturan la informacin de las
declaraciones que el nuevo PlugIn hace al acoplarse al ambiente de Z4-CASE. Esto es, qu elementos de
diseo provee el nuevo PlugIn, que modelos, que bees, etc.
Otros Bee que se provee en el PlugIn de Extensiones, son ModelElementBee y ModelRelationBee, los que
permiten fcilmente crear nuevos elementos de diseo, dejando para codificacin del usuario los servicios que
dibujan los elementos y relaciones.
Fig. 9: Algunos Bees del PlugIn z4-extensions

El Bee JavaClassGenerator permite definir una clase como generadora de otras clases. Usando este Bee, un
diseador de PlugIns para Z4 puede fcilmente crear generadores de cdigo para partes de una clase.
Fig. 10: Definicin de una Clase como Generadora de Clases
En el ejemplo de la imagen se observa la definicin de la clase StatelessEJBSQLDAO como un Bee

generador de clases que extiende al Bee generador EJBBee definido en el PlugIn z4-j2ee.
El paso siguiente en el bootstrapping fue rehacer el PlugIn de UML usando ahora el PlugIn de extensiones.
Una vez que esto se complet, se sigui con la generacin del resto de los nuevos PlugIns (database, j2ee, ant,
jboss, oc4j, taf2, weblogic, workflow). Para poder trabajar en Z4-CASE desde Z4-CASE, se realiza un control
de versiones y testing que se ocupara de mantener siempre una versin estable, con la que se modela la
siguiente versin. Slo despus de que la nueva versin ha sido probada satisfactoriamente, sta pasa a ser la
versin estable.
Cabe destacar que desde la creacin del PlugIn z4-extension, que permite la creacin de nuevos PlugIns, la
productividad del equipo de desarrollo de Z4-CASE ha aumentado considerablemente.
6. Conclusiones y trabajos futuros
Durante el desarrollo de Z4-CASE la incorporacin de tcnicas de bootstrapping result ser una decisin
muy exitosa. Esto qued demostrado al aumentar notablemente la productividad en comparacin con el
desarrollo manual de las primeras iteraciones. Por otra parte, la introduccin de la idea de los Bees (que en la
prctica se comportan como abejas trabajando colaborativamente en la produccin del software) es un aporte
a las tcnicas de modelamiento, generacin de cdigo e integracin de componentes. Queda pendiente un
trabajo a futuro: Formalizar el concepto de Bee y estudiar su relacin con otros conceptos como Aspect
Oriented Programming y Subject Oriented Programming.
7. Referencias
[1] J.Jimnez, C.Bidart, Metodologa de Desarrollo, documento interno TUXPAN
[2] Richard Soley, MDA, an Introduction, disponible en http://www.omg.org/mda
[3] Craig Larman, Applying UML and Patterns, Hardcover
Lista de Autores
A
Abrahao, Silvia Artculos: Pagina 114
Acuna, Cesar Artculos: Pagina 124
Albert, Manoli Artculos: Pagina 245
Anaya, Raquel Artculos: Pagina 366
B
Barros, Roberto S. M. Artculos: Pagina 22
Baum, Gabriel Artculos: Pagina 175
Bernabe Loranca, Beatriz Artculos: Pagina 263
Bertolami, Mabel Artculos: Pagina 91
Braga, Regina M.M. Artculos: Pagina 349
Brisaboa, Nieves Artculos: Pagina 79
Brogi, Antonio Artculos: Pagina 182
Buccella, Agustina Artculos: Pagina 79
C
Caceres, Paloma Artculos: Pagina 124
Campos, Fernanda Artculos: Pagina 349
Canal, Carlos Artculos: Pagina 182
Castro, Jaelson F. B. Artculos: Pagina 308
Castro, Pablo Artculos: Pagina 175
Cavalcanti Cabral, Maria Izabel Artculos: Pagina 28
Cechich, Alejandra Artculos: Pagina 79
Celma-Gimenez, M. Artculos: Pagina 194
Condori-Fernandez, Nelly Artculos: Pagina 114
Cortes, Marina F. Artculos: Pagina 257
Cota, Renata I. Artculos: Pagina 56
Cruz-Lemus, Jose A. Artculos: Pagina 10
Cuadros-Vargas, Ernesto Artculos: Pagina 9
D
da Silva, Joel Artculos: Pagina 22
Daltio, Jaudete Artculos: Pagina 103
de A. Falbo, Ricardo Artculos: Pagina 257
de Abreu Sisson, Gustavo Artculos: Pagina 206
de Almeida, Diogo Q. Artculos: Pagina 257
de Castro, Valeria Artculos: Pagina 124
de Menezes, Credine S. Artculos: Pagina 257
de Oliveira, Alessandreia Artculos: Pagina 349
del Valle, Mario Artculos: Pagina 294
Deters, Janice Artculos: Pagina 68
do N. S. Monteiro, Ana Alice Artculos: Pagina 234
dos Santos Carvalho, Francisco Artculos: Pagina 308
Daz, Isabel Artculos: Pagina 270
391
E
Edelweiss, Nina Artculos: Pagina 216
Etges, Silvio Artculos: Pagina 68
F
Fagundes de Moraes, Marco Antonio Artculos: Pagina 282
Falbo, Ricardo A. Artculos: Pagina 56, 50
Fons, Joan Artculos: Pagina 228
Fortes, Renata Artculos: Pagina 151
Franceto, Simone Artculos: Pagina 169
Freire, Andre Artculos: Pagina 151
Fuentes, Thaizel Artculos: Pagina 294
Furtado, Joao C. Artculos: Pagina 68
G
Galvao Martins, Luiz Eduardo Artculos: Pagina 169
Garca, Felix Artculos: Pagina 40
Garca, Ignacio Artculos: Pagina 157
Genero, Marcela Artculos: Pagina 10
Giandini, Roxana S. Artculos: Pagina 337
Gonzalez Briones, Gustavo A. Artculos: Pagina 320
Goncalves da Rocha, Flavio Artculos: Pagina 28
Goncalves Kirner, Tereza Artculos: Pagina 320
H
Henao, Monica Artculos: Pagina 366
Holanda, Thiago Artculos: Pagina 68
Hurtado Alegra, Julio Ariel Artculos: Pagina 360
I
Imbert Paredes, Ricardo Artculos: Pagina 136
J
Jmenez C., Jorge Artculos: Pagina 384
K
Katrib, Miguel Artculos: Pagina 4, 142, 294
L
Leal Musa, Daniela Artculos: Pagina 206
Lisboa Filho, Jugurta Artculos: Pagina 103
M
Marcos, Esperanza Artculos: Pagina 124
Marques, Helena M. Artculos: Pagina 326
Matteo, Alfredo Artculos: Pagina 270
Mattoso, Marta Artculos: Pagina 349
Menezes, Credine S. Artculos: Pagina 56
Molz, Rolf Artculos: Pagina 68
Monge, Raul Artculos: Pagina 5
Moreno, Lidia Artculos: Pagina 270
Mota-Herranz, L. Artculos: Pagina 194
Munoz, Javier Artculos: Pagina 228
N
Nunes, Vanessa B. Artculos: Pagina 50
O
Olivas, Jose A. Artculos: Pagina 10
Oliveros, Alejandro Artculos: Pagina 91
Olsina, Luis Artculos: Pagina 7, 263
P
Paiva, Debora Artculos: Pagina 151
Palazzo Moreira de Oliveira, Jose Artculos: Pagina 206
Pastor, M.A. Artculos: Pagina 194
Pastor, Oscar Artculos: Pagina 8, 114, 270, 228
Perez, Gabriela A. Artculos: Pagina 337
Pastrana, Jose Luis Artculos: Pagina 142
Pelechano, Vicente Artculos: Pagina 245, 228
Piattini, Mario Artculos: Pagina 10, 40, 157
Pimentel, Ernesto Artculos: Pagina 142, 182
Polo, Macario Artculos: Pagina 157
Pons, Claudia F. Artculos: Pagina 337
Pow-Sang Portillo, Jose Antonio Artculos: Pagina 136
R
Ramos, Rodrigo T. Artculos: Pagina 326
Restrepo, Alberto Artculos: Pagina 366
Rodrigues Junior, Maurcio Fidelis Artculos: Pagina 103
Romero, Francisco P. Artculos: Pagina 10
Ruiz, Francisco Artculos: Pagina 40
Ruiz, Marta Artculos: Pagina 245
S
Santini, Simone Artculos: Pagina 372
Schreiber, Jacques N. C. Artculos: Pagina 68
Sidnei Wazlawick, Raul Artculos: Pagina 68
Sierra, Iskander Artculos: Pagina 294
Silva, Ismenia G. L. Artculos: Pagina 326
Soares, Andrea O. Artculos: Pagina 50
T
Times, Valeria C. Artculos: Pagina 22
Togneri, Denise F. Artculos: Pagina 257
Torres, Victoria Artculos: Pagina 245
V
Vasconcelos, Alexandre Marcos Lins de Artculos: Pagina 6, 234, 282
Vidal Rojas, Juan Carlos Artculos: Pagina 360
Vieira, Victor Artculos: Pagina 151
W
Wernesback, Bernardo S. Artculos: Pagina 257
Z
Zschornack, Fabio Artculos: Pagina 216
Artculos por pas
Argentina
An Ontology-based Environment to Data Integration
Agustina Buccella; Alejandra Cechich; Nieves Brisaboa; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Proceso de Medicion de Funcionalidad en la Elicitacion de Requerimientos
Mabel Bertolami; Alejandro Oliveros; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Integrando BON con Alloy
Pablo Castro; Gabriel Baum; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Metodos Heursticos para el Analisis de Clasificacion en Sitios E-Commerce
Beatriz Bernabe Loranca; Luis Olsina; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Un Metamodelo para Catalysis basado en el Metamodelo de UML
Gabriela A. Perez; Roxana S. Giandini; Claudia F. Pons; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Criterios y Metodos para Evaluar Calidad en Aplicaciones Web
Luis Olsina; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Brasil
Sistematizacao da Integracao de Servicos na Web
Joel da Silva; Valeria C. Times; Roberto S. M. Barros; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Componentes de Software para a Construcao de Ambientes de Simulacao de Redes de Com-
putadores - Implementacao e Validacao
Flavio Goncalves da Rocha; Maria Izabel Cavalcanti Cabral; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Apoio a Documentacao em um Ambiente de Desenvolvimento de Software
Andrea O. Soares; Vanessa B. Nunes; Ricardo A. Falbo; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Modelagem Organizacional Utilizando Ontologias e Padroes de Analise
Renata I. Cota; Credine S. Menezes; Ricardo A. Falbo; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Analise do Tempo de Navegacao na Composicao de um Modelo para Hipermdia Adaptativa
Jacques N. C. Schreiber; Rolf Molz; Joao C. Furtado; Raul Sidnei Wazlawick; Silvio Etges; Thiago Ho-
landa; Janice Deters; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
ArgoCASEGEO - Uma Ferramenta CASE de Codigo-aberto para o Modelo UML-GeoFrame
Jugurta Lisboa Filho; Maurcio Fidelis Rodrigues Junior; Jaudete Daltio; . . . . . . . . . . . . . . . . . . . . . . . . . . 103
An Academic Web-based Agenda and Its Engineering Process
Renata Fortes; Andre Freire; Victor Vieira; Debora Paiva; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Elicitacao de Requisitos para o Desenvolvimento de uma Ferramenta de Apoio a Metodo-
logia de Elicitacao de Requisitos de Software Baseada na Teoria da Atividade (META)
Simone Franceto; Luiz Eduardo Galvao Martins; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Experiencias no Desenvolvimento e Integracao de um Gerenciador de Alertas para Ambien-
tes de Ensino a Distancia na Internet
Daniela Leal Musa; Gustavo de Abreu Sisson; Jose Palazzo Moreira de Oliveira; . . . . . . . . . . . . . . . . . . . 206
On Evolution of XML Workflow Schemata
Fabio Zschornack; Nina Edelweiss; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
BMW - A Systematic Process for Business Modelling Activity
Ana Alice do N. S. Monteiro; Alexandre Marcos Lins de Vasconcelos; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Gerencia de Conhecimento na Engenharia de Requisitos
Denise F. Togneri; Ricardo de A. Falbo; Credine S. de Menezes; Bernardo S. Wernesback; Diogo Q. de
Almeida; Marina F. Cortes; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
ArcADe: Um Modelo de Processo para Analise e Projeto Baseado em Arquitetura de Soft-
ware
Marco Antonio Fagundes de Moraes; Alexandre Marcos Lins de Vasconcelos; . . . . . . . . . . . . . . . . . . . . . . 282
395
Integrando Gestao do Conhecimento e Modelagem Organizacional

Francisco dos Santos Carvalho; Jaelson F. B. Castro; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Ferramenta de Inspecao de Requisitos de Software em Ambiente Web
Gustavo A. Gonzalez Briones; Tereza Goncalves Kirner; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .320
Adaptacao de um Processo de Desenvolvimento para Fabricas de Software Distribudas
Helena M. Marques; Rodrigo T. Ramos; Ismenia G. L. Silva; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326
GOS: Especificacao de um Mecanismo de Busca e Recuperacao de Componentes
Alessandreia de Oliveira; Regina M.M. Braga; Fernanda Campos; Marta Mattoso; . . . . . . . . . . . . . . . . . 349
Adequando o RUP e o XP para o desenvolvimento de aplicacoes WEB
Alexandre Marcos Lins de Vasconcelos; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Chile
Propuestas para Generacion de Codigo y Diseno de una Herramienta CASE Usando Tec-
nicas de Bootstrapping
Jorge Jmenez C.; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Desarrollo de Aplicaciones Distribudas con J2EE
Raul Monge; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Colombia
Propuesta de un Proceso para el Analisis de una Lnea de Productos dentro del Contexto
del Proceso ARCA-LP
Julio Ariel Hurtado Alegra; Juan Carlos Vidal Rojas; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360
Aplicacion de una Metodologa de Ingeniera de Requisitos a un Caso Real
Alberto Restrepo; Monica Henao; Raquel Anaya; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Cuba
Programacion en la web con la tecnologa .NET
Miguel Katrib; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Composicion y Coordinacion de Componentes mediante Conectores y WebServices
Miguel Katrib; Jose Luis Pastrana; Ernesto Pimentel; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Metaprogramming in .Net
Miguel Katrib; Mario del Valle; Iskander Sierra; Thaizel Fuentes; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .294
Espana
Utilizacion de Tecnicas Basadas en la Logica Borrosa para Predecir el Tiempo de Entendi-
miento de los Diagramas de Estados UML
Jose A. Cruz-Lemus; Marcela Genero; Jose A. Olivas; Francisco P. Romero; Mario Piattini; . . . . . . . .10
Experimento con Profesionales para Evaluar la Calidad de los Modelos de Procesos Soft-
ware
Felix Garca; Francisco Ruiz; Mario Piattini; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
An Ontology-based Environment to Data Integration
Agustina Buccella; Alejandra Cechich; Nieves Brisaboa; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Una Experiencia en la Validacion Teorica de Metricas de Software
Nelly Condori-Fernandez; Silvia Abrahao; Oscar Pastor; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Del Modelo de Casos de Uso al Modelo de Navegacion
Paloma Caceres; Valeria de Castro; Esperanza Marcos; Cesar Acuna; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Estimacion y Planificacion de Proyectos Software con Ciclo de Vida Iterativo-Incremental
y empleo de Casos de Uso
Jose Antonio Pow-Sang Portillo; Ricardo Imbert Paredes; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Composicion y Coordinacion de Componentes mediante Conectores y WebServices
Miguel Katrib; Jose Luis Pastrana; Ernesto Pimentel; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Generacion Automatica de Aplicaciones basadas en Componentes a partir de Bases de Da-
tos
Ignacio Garca; Macario Polo; Mario Piattini; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157

Measuring Component Adaptation
Antonio Brogi; Carlos Canal; Ernesto Pimentel; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Analisis de Restricciones de Integridad en el Nivel Conceptual
M.A. Pastor; M. Celma-Gimenez; L. Mota-Herranz; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Desarrollo de Sistemas Domoticos Guiado por Modelos
Javier Munoz; Joan Fons; Vicente Pelechano; Oscar Pastor; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Un Framework para la Implementacion de Relaciones de Asociacion Agregacion y Compo-
sicion en UML
Marta Ruiz; Manoli Albert; Victoria Torres; Vicente Pelechano; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
Una Aproximacion Lingustica de Ingeniera de Requisitos para OO-Method
Isabel Daz; Oscar Pastor; Lidia Moreno; Alfredo Matteo; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
From conceptual modeling to the semantic web: an Object-Oriented Approach
Oscar Pastor; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Estados Unidos
Functional Entity-Relationship Modeling
Simone Santini; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Italia
Measuring Component Adaptation
Antonio Brogi; Carlos Canal; Ernesto Pimentel; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Mexico
Metodos Heursticos para el Analisis de Clasificacion en Sitios E-Commerce
Beatriz Bernabe Loranca; Luis Olsina; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263
Peru
Estimacion y Planificacion de Proyectos Software con Ciclo de Vida Iterativo-Incremental
y empleo de Casos de Uso
Jose Antonio Pow-Sang Portillo; Ricardo Imbert Paredes; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
Similarity Information Retrieval
Ernesto Cuadros-Vargas; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Venezuela
Una Aproximacion Lingustica de Ingeniera de Requisitos para OO-Method
Isabel Daz; Oscar Pastor; Lidia Moreno; Alfredo Matteo; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

Ideas Main

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Ideas Main

Cargado por

Copyright:

Formatos disponibles

IDEAS 2004

Prohibida la reproduccin total o parcial de esta obra, por cualquier

Libro ISBN: 9972-9876-1-2

Este volumen contiene los artculos aceptados y presentados en el VII Workshop

El workshop IDEAS'2004 ya se ha consolidado como un foro cientfico de discusin y

En la presente convocatoria se han recibido 77 artculos de calidad cientfica para su

Adems de la sesiones tcnicas, el Workshop IDEAS (http://www.spc.org.pe/ideas2004/), ha

A todos los autores, revisores, organizadores, editores y colaboradores en general, francamente,

Luis Olsina Alexandre Vasconcelos Ernesto Cuadros-Vargas

3.11. Una Experiencia en la Validacion Teorica de Metricas de Software

3.36. Propuesta de un Proceso para el Analisis de una Lnea de Productos dentro

Lista de Autores 391

Artculos por pas 395

Tutorial: Programacion en la web con la tecnologa .NET

Tutorial: Desarrollo de Aplicaciones Distribudas con J2EE

Tutorial: Adequando o RUP e o XP para o desenvolvimento de

Tutorial: Criterios y Metodos para Evaluar Calidad en

Tutorial: From conceptual modeling to the semantic web: an

Tutorial: Similarity Information Retrieval

Utilizacin de Tcnicas Basadas en la Lgica Borrosa para Predecir

Jos A. Cruz-Lemus, Marcela Genero, Jos A. Olivas,

Departamento de Informtica, Universidad de Castilla-La Mancha

Tabla 1. Mtricas para diagramas de estados UML

Viendo los alentadores resultados obtenidos al aplicar el proceso de Descubrimiento de Conocimiento

En nuestro caso, los principales objetivos del proceso de prediccin son:

1. La bsqueda y extraccin automtica de prototipos borrosos que caractericen los diagramas de

2. La obtencin de un modelo de prediccin del tiempo de entendimiento de los diagramas de estados

En esta seccin se describen un experimento controlado y su rplica, que se realizaron teniendo en

2.1. Primer experimento

2.1.1. Definicin del experimento

Tabla 2. Objetivo del experimento segn GQM

La planificacin incluye las siguientes actividades:

profesores pertenecen al rea de Ingeniera del Software. El experimento es especfico ya que se

En esta fase se recogen los resultados, e incluye las siguientes actividades:

Diagrama NEntryA NExitA NA NSS NCS NT NE NG McCabe

Diagrama NEntryA NExitA NA NSS NCS NT NE NG McCabe

2.2. Rplica del experimento

3. Construccin del modelo de prediccin del tiempo de entendimiento de los

3.1. Transformacin de los datos

Tabla 4. Tiempos obtenidos (en segundos) en el proceso de transformacin

Diagrama TEAvg TEMin TEMax Diagrama TEAvg TEMin TEMax

3.2. Obtencin de los prototipos usando tcnicas de clustering

Figura 1. Resultados del clustering: (B: tiempo bajo de entendimiento,

Tabla 5. Diagramas agrupados segn el prototipo al que pertenecen

3.2. Definicin paramtrica de los prototipos

Tabla 6.Definicin paramtrica de los prototipos

3.3. Representacin borrosa de los prototipos

Figura 2. Representacin borrosa de los prototipos

Tabla 7. Definicin borrosa de los prototipos

La definicin formal de los prototipos en forma de nmeros borrosos se obtiene mediante la

3.4. Deformacin de los prototipos borrosos para predecir el tiempo de entendimiento de

El proceso a llevar a cabo es el que sigue:

Tabla 8. Valores de las mtricas del diagrama 16

NEntryA NExitA NA NSS NCS NT NE NG McCABE

Tabla 9. Valores normalizados de las mtricas del diagrama 16

2. La media de los valores normalizados es X = 0.53.

Tabla 10. Valor de las afinidades de los prototipos

4. Y finalmente se calcula el tiempo medio correspondiente (Media Estimada) a la prediccin

Tabla 11. Combinacin lineal para el clculo de tiempos medios2

Tabla 12. Datos de la validacin del modelo de prediccin

DIAGRAMA X Af (B) Af (M) Af (A) Valor Estimado Valor Real MRE

3.5 Validacin del modelo de prediccin

Magnitud del Error Relativo (MRE).

MRE se define como: