1. Educación

C´
omo abordar el problema de la reutilizaci´
on en
el contexto de MDA y los servicios Web
Nathalie Moreno, Antonio Vallecillo
Dpto. de Lenguajes y Ciencias de la Computaci´
on
Universidad de M´
alaga, Spain
{vergara,av}@lcc.uma.es
Resumen MDA surge como una de las estrategias m´
as prometedoras
para el dise˜
no y desarrollo de aplicaciones software. Unifica y simplifica el
modelado, dise˜
no, implementaci´
on e integraci´
on de aplicaciones convirtiendo el desarrollo software en un proceso de transformaci´
on de modelos.
Este proceso de transformaci´
on parece sugerir una aproximaci´
on descendente (top-down), tal que los PIMs son transformados progresivamente
en PSMs hasta alcanzar la implementaci´
on final del sistema (PSM). Sin
embargo, hay situaciones en las que se requiere una aproximaci´
on ascendente (bottom-up), por ejemplo en aquellos casos en los que se pretenda
reutilizar componentes COTS, servicios Web, o aplicaciones ya operacionales. En este art´ıculo trataremos de se˜
nalar los problemas m´
as relevantes relacionados con la reutilizaci´
on en MDA, identificando l´ıneas de
investigaci´
on abiertas y proponiendo formas de tratarlas, en contextos
concretos como la ingenier´ıa Web.
1.
Introducci´
on
El ritmo acelerado al que evolucionan las tecnolog´ıas software y el deseo
apremiante de la industria de absorver esos cambios, ha planteado nuevos retos en el desarrollo software. Generalmente, las aplicaciones requieren implementaciones que se adapten a los cambios constantes, que faciliten su integraci´on con otros sistemas y que resuelvan picos variables de interacci´on con
un buen rendimiento. Frente a esta necesidad, la realidad es que el precio que
las empresas pagan por lograr la portabilidad, interoperabilidad e independencia
de la plataforma para sus aplicaciones, se traduce actualmente en un aumento
desmesurado en los costes de desarrollo.
La Arquitectura Dirigida por Modelos (MDA) [16,19] es una iniciativa de
OMG orientada a lograr dichos objetivos. Propone, en una primera fase, la
definici´on de modelos de alto nivel de abstracci´on, independientes de cualquier
hardware, sistema operativo o plataforma que finalmente lo soporte (Modelo Independiente de la Plataforma, PIM). Esta caracter´ıstica intenta proteger parte
de la inversi´on de la organizaci´on en el desarrollo del software, aislando la l´ogica de la aplicaci´on y las reglas del negocio, de la tecnolog´ıa y las plataformas
middleware sobre las cuales el sistema ser´a implementado.
En una segunda fase, el PIM es transformado en un modelo PSM que incorpora aspectos relevantes para la implementaci´on y espec´ıficos de la plataforma
seleccionada. En aquellos casos en los que intervengan varias plataformas en la
implementaci´on, se generar´a un PSM por cada una de ellas. De este modo, la implementaci´on del sistema se alcanza finalmente tras aplicar, iterativamente, varios ciclos de transformaci´on entre modelos; entendido el t´ermino implementaci´on
en el contexto de MDA como un PSM m´as, el cual incluye la informaci´on necesaria para construir el sistema y ponerlo a funcionar.
La estrategia descrita parece sugerir un dise˜
no descendente, en el que los
modelos que representan diferentes niveles de abstracci´on del sistema son progresivamente transformados (fusionados y/o refinados) hasta que se genera el c´odigo
de la implementaci´on. En definitiva, una aproximaci´on aparentemente orientada
a la creaci´on de nuevos sistemas y a la generaci´on de c´odigo para plataformas
actuales y futuras. Por el contrario, la pr´actica nos lleva a descomponer la funcionalidad de un sistema en un conjunto de subsistemas independientes; una
estrategia orientada a la reutilizaci´on de m´odulos software ya desarrollados en
proyectos previos o adquiridos por terceras partes (COTS, servicios Web, etc.).
De tal forma que, el desarrollo de la aplicaci´on final se traduce en muchos casos
en un proceso de ensamblado e integraci´on (desarrollo ascendente o bottom-up).
Esto plantea algunos interrogantes que deben ser resueltos en el contexto de
MDA, como son: ¿C´omo hacer frente al problema de la reutilizaci´on dentro del
contexto de MDA? ¿Qu´e beneficios puede aportar MDA frente a otras aproximaciones? ¿C´omo tratar etapas del ciclo de vida del producto software tales como
el mantenimiento o la evoluci´on sin alterar la consistencia entre los modelos y el
c´odigo generado?.
En definitiva, este art´ıculo pretende describir algunos de los problemas m´as
relevantes asociados a la reutilizaci´on software que deben ser abordados en el
contexto de MDA, identificando las l´ıneas de investigaci´on abiertas en este sentido y proponiendo formas de resolverlas en el caso particular de la ingenier´ıa
Web y los servicios Web. Para ello, la estructura de este documento ha sido
organizada de la siguiente forma. Tras la introducci´on, figura la secci´on 2 en
la que ser´an enumerados los principales problemas que surgen cuando tratamos
de reutilizar software en el contexto de MDA. Seguidamente, la secci´on 3 propone una soluci´on basada en un conjunto de suposiciones y analiza su viabilidad
pr´actica conforme a la situaci´on actual. Finalmente, la secci´on 4 presenta algunas
conclusiones y describe l´ıneas de trabajo futuras.
2.
Problemas relevantes para la reutilizaci´
on software en
el contexto de MDA
El ´exito de MDA depende en gran medida, no s´olo de los beneficios derivados de su aplicaci´on en la descripci´on de nuevos sistemas, sino tambi´en de las
facilidades que este nuevo enfoque pueda sugerir para tratar el problema de
la integraci´on de software operacional con nuevas y futuras aplicaciones. Este
objetivo requiere, previamente, resolver algunos problemas relacionados con la
reutilizaci´on en MDA. Muchos de ellos no son s´olo espec´ıficos del dise˜
no bajo
el enfoque de MDA, sino que tambi´en est´an presentes en otras aproximaciones
como el DSBC.
As´ı hacemos notar al lector que no existe, m´as all´a de la pr´actica generalizada,
un consenso sobre la informaci´on que debe contener el modelo de un sistema
software; como tampoco existe un acuerdo sobre la notaci´on o lenguaje m´as
adecuado para representar dicha informaci´on.
Para nuestro prop´osito, consideraremos que el modelo de un sistema incluye:
(a) una descripci´on estructural o funcional del mismo; (b) la especificaci´on de
su comportamiento; (c) y de la coreograf´ıa de sus elementos [20,23].
El dise˜
no estructural de un sistema define los servicios fundamentales que
implementar´a la aplicaci´on en base a un conjunto de clases o componentes, sus
atributos, la signatura de sus operaciones y las relaciones entre ellos. Usualmente,
esta informaci´on es capturada en un diagrama de clases o componentes UML.
El modelado de la sem´antica del comportamiento determina el comportamiento preciso de cada objeto o componente en termino de m´aquinas de estados,
sem´antica de acci´on, o por medio de la especificaci´on de pre y post condiciones
de sus operaciones (ver [14] para una extensa discusi´on sobre las diferentes aproximaciones de modelado del comportamiento).
Finalmente, la coreograf´ıa establece la secuencia de mensajes e interacciones
v´alidas que los diferentes objetos y componentes del sistema pueden intercambiar. Notaciones como los diagramas de interacci´on, lenguajes como BPEL4WS,
o notaciones formales como las redes de Petri o el π-calculus pueden describir
este tipo de informaci´on.
Es importante se˜
nalar que, frente al uso casi extendido de los diagramas
UML (de clases o componentes) para describir la funcionalidad de un sistema,
tampoco existe consenso sobre la notaci´on que debe usarse para modelar el
comportamiento y la coreograf´ıa. Este problema nos impedir´a reutilizar PIMs y
transformaciones entre modelos para futuros dise˜
nos en el contexto de MDA.
2.1.
Problemas espec´ıficos para la reutilizaci´
on de servicios Web en
el contexto de MDA
Al igual que los componentes, los servicios Web son considerados de caja
negra: su funcionalidad puede ser reutilizada sin conocer los detalles espec´ıficos
de la implementaci´on. Sin embargo, a diferencia de ´estos los servicios Web no
son accesibles a trav´es de protocolos espec´ıficos como DCOM, RMI o IIOP. En
su lugar, el acceso se realiza siguiendo protocolos y formatos de datos est´andar,
como SOAP o el lenguaje de marcado extensible XML.
El uso de ´estos est´andares, definidos en su gran mayor´ıa por el consorcio
W3C, los dota de una gran capacidad de comunicaci´on entre aplicaciones; independientemente de la plataforma tecnol´ogica sobre la cual est´en construidos. No
obstante, su reutilizaci´on bajo el enfoque de MDA plantea una serie de consideraciones. As´ı, el tipo de informaci´on que est´e disponible sobre ellos nos permitir´a chequear cu´ando cumplen o no los requisitos del sistema y por tanto evaluar
su adecuaci´on para ser reutilizados. Concretamente, esta informaci´on deber´ıa
permitir:
(a) Modelar el servicio Web atendiendo a los aspectos considerados en nuestra
propuesta: estructura, comportamiento y coreograf´ıa;
(b) Chequear cuando este modelo cumple los requisitos del sistema (tambi´en
conocido como el problema del gap analysis [8]);
(c) Evaluar los cambios y el esfuerzo de adaptaci´on requerido para hacerlo coincidir con los requisitos del sistema (por ejemplo, evaluar la distancia entre
los modelos de los servicios “requeridos” y los servicios “disponibles”, ver
por ejemplo, [15]); e
(d) Idealmente, proporcionar la especificaci´on de un adaptador que resuelva las
posibles incompatibilidades y diferencias (ver [5,6]).
A pesar de la consideraci´on de caja negra, la publicaci´on de un servicio Web
en un directorio require, al menos, el esfuerzo de documentar la interfaz del
mismo en t´erminos de los mensajes que el servicio Web acepta y genera. Este
documento (definido siguiendo la nomenclatura de lenguajes como WSDL, SDL,
SCL, o NASSL) puede ser considerado bajo el enfoque de MDA, como el PSM
del modelo estructural del servicio.
No ocurre igual con el modelado del comportamiento. Generalmente, los directorios de servicios Web aceptan una descripci´on en lenguaje textual y rara vez
encontraremos documentos WSCI o RDF que describan la conducta interna de
los mismos. En caso de existir, este documento constituir´ıa el PSM del modelo
del comportamiento del servicio.
Cuando la complejidad de las aplicaciones requiere conectar varios servicios
Web entre s´ı para crear procesos de negocio de alto nivel, es frecuente encontrar
documentada la orquestaci´on de los objetos implicados a fin de evitar comportamientos indeseados. Descrita en t´erminos de lenguajes de composici´on de
servicios Web como XLANG, WSFL o BPEL4WS, consideraremos la especificaci´on de la coreograf´ıa como un modelo espec´ıfico para la plataforma (PSM) o
lenguaje en el que est´e definido.
Si disponer de documentaci´on precisa sobre la estructura, comportamiento y
coreograf´ıa resulta ya un problema, no menos compleja resulta la tarea de evaluar
si es posible reutilizar el servicio. En este punto conviene recordar el significado
del concepto reutilizaci´
on. Reutilizar implica usar sin cambios, ya que de otro
modo no se considerar´ıa reutilizaci´on. As´ı, si m´as del 80 % de la funcionalidad de
un servicio debe ser modificado para que pueda ser integrado en nuestro sistema,
resulta m´as f´acil (y barato) desarrollarlo desde cero. En definitiva, aplicar una
estrategia de dise˜
no descendente para generar su implementaci´on desde el modelo
independiente de la plataforma o PIM.
De este modo concluimos que, los principales problemas que encontramos
relacionados con la reutilizaci´on de servicios Web son: el conjunto de modelos
del servicio que se requieren (proporcionados/obtenidos) del mismo con objeto
de comprender su funcionalidad, y como reutilizarlo; la evaluaci´on del esfuerzo
requerido para adaptarlo y que cumpla los requisitos del nuevo sistema; y la
generaci´on (semi)autom´atica de adaptadores que eliminen las incompatibilidades
o incongruencias encontradas durante el an´alisis de la sutituibilidad.
3.
Una propuesta para abordar los problemas de la
reutilizaci´
on
Antes de ilustrar nuestra propuesta, es preciso asumir ciertas consideraciones
al respecto como son:
(1) En primer lugar, supondremos que contamos con un modelo del servicio
Web que deseamos reutilizar. Este modelo incluye informaci´on sobre su estructura, comportamiento y coreograf´ıa; dando lugar al PSM objetivo.
(2) Del mismo modo, asumiremos que el PIM de la aplicaci´on que estamos desarrollando describe el sistema como un conjunto de partes que interact´
uan, cada una con informaci´on sobre su estructura, comportamiento, y coreograf´ıa.
(Esta informaci´on puede ser tambi´en modelada individualmente, u obtenida
para cada elemento desde el PIM global usando proyecciones, por ejemplo)
(3) En tercer lugar, asumiremos que hay transformaciones MDA definidas entre
los metamodelos de las notaciones usadas en el PIM para describir la estructura del sistema, el comportamiento y la coreograf´ıa, y aquellos usados
en el PSM. Por ejemplo, transformaciones entre diagramas de secuencias de
mensajes y BPEL4WS.
(4) En cuarto lugar, supondremos que asociada a cada notaci´on para describrir
la estructura, el comportamiento y la coreograf´ıa a nivel de PSM, existen un
conjunto de operadores de emparejamiento que implementar´an los test de
sustituibilidad. Estos test son requeridos para chequear cu´ando un servicio
Web (especificado en el PIM, y “traducido” a PSM) puede ser con toda
seguridad sustituido por el servicio Web existente. Por simplicidad, usaremos
la notaci´on (≤) para referirnos a todos estos operadores.
Por ejemplo, a nivel estructural dadas dos interfaces A y B, diremos que
A ≤ B si A puede reemplazar B, es decir, si A es un subtipo de B usando
las relaciones de subtipado para signaturas de interfaces [21]. A nivel del
comportamiento, este operador puede ser definido para tratar la sem´antica del comportamiento de los servicios, siguiendo las relaciones usuales de
subtipado para pre y post condiciones [22]. El operador ≤ puede ser tambi´en definido para modelos de coreograf´ıas expresados usando ´algebras de
procesos [6,7,17].
(5) Y finalmente, necesitamos contar con la posibilidad de derivar (semi) autom´aticamente adaptadores software que resuelvan las incompatibilidades
encontradas durante el test de sustituibilidad (wrappers)
Bas´andonos en estos cinco supuestos, presentamos una aproximaci´on para
resolver los problemas derivados de la reutilizaci´on en el contexto de MDA. Tal
y como se describe gr´aficamente en la Figura 1, nuestra estrategia parte del
PIM de un servicio del negocio o componente del sistema global. Este PIM se
BUSINESS COMPONENT
STRUCTURAL MODEL
BEHAVIORAL MODE L
CHOREOGRAPHY MODEL
REVIEW
PIM
LANGUAGE
MDA
TRANSFORMATION
MDA
TRANSFORMATION
MDA
TRANSFORMATION
STRUCTURE
NO
NO
ADAPTABLE?
NO
BEHAVIOR
NO
< ?
YES
YES
ADAPTABLE?
NO
NO
< ?
CHOREOGRAPHY
NO
< ?
YES
PSM
LANGUAGE
ADAPTABLE?
WORTH DEVELOPING?
YES
YES
STRUCTURE
BEHAVIOR
CHOREOGRAPHY
WEB SERVICE
SPECIFICATION
MDA TRANSFORMATION/
IMPLEMENTATION
GENERATED
WEB SERVICE
STRUCTURE
BEHAVIOR
CHOREOGRAPHY
ADAPTER
SPECIFICATION
MDA TRANSFORMATION/
IMPLEMENTATION
ADAPTER
STRUCTURE
BEHAVIOR
CHOREOGRAPHY
WEB SERVICE
SPECIFICATION
DOCUMENTATION OR
MDA TRANSFORMATION/ REV.
ENGINEERING
CODE
WEB SERVICE
(BLACK BOX)
Figura 1. Integraci´
on de servicios Web en la cadena de modelado de MDA
obtiene tras aislar, en el PIM global, la funcionalidad que pretendemos implementar reutilizando un servicio Web concreto (recordemos la viabilidad de esta
aproximaci´on pues suponemos un modelo del sistema compuesto de servicios o
componentes independientes que interact´
uan juntos para lograr la funcionalidad
del mismo). El PIM de cada servicio del negocio incluye, al menos, tres modelos
con su estructura comportamiento y coreograf´ıa.
Volviendo a la Figura 1, la parte inferior derecha hace referencia al servicio
Web que pretendemos implementar. Sea en nuestro caso un servicio Web externo
que ofrece los servicios financieros en los que estamos interesados. De la documentaci´on disponible sobre este servicio extraeremos sus modelos de alto nivel,
los cuales constituir´an el PSM del elemento software. Sea P la plataforma para
la que ha sido definido el modelo PSM, y Ms , Mb y Mc los modelos de la estruc-
tura, comportamiento y coreograf´ıa del elemento software que ser´a reutilizado,
respectivamente.
Para poder determinar si el PSM correspondiente al software disponible para
una plataforma P , puede servir como una implementaci´on del PIM, necesitamos
comparar ambos modelos. Esta comparativa precisa que los modelos est´en expresados en la misma plataforma. Es decir, necesitamos transformar los tres
modelos del PIM en tres modelos en P , usando transformaciones MDA. Sean
estas transformaciones Ms , Mb y Mc , respectivamente.
Ya expresadas en la misma plataforma y en lenguajes compatibles, podemos
hacer uso de los operadores de reemplazabilidad y de las herramientas disponibles
para estos lenguajes que chequeen si el elemento software satisface nuestros requisitos. En definitiva, si Ms ≤ Ms , Mb ≤ Mb , y Mc ≤ Mc . Para el caso afirmativo,
concluiremos que el PSM constituye una transformaci´on v´alida desde el PIM
respecto a esa plataforma.
Sin embargo, no es frecuente que los servicios disponibles en la Web puedan
ser reutilizados tal cual, es decir, su PSM generalmente no podr´a reemplazar
satisfactoriamente el PSM obtenido por la transformaci´on del PIM. En su lugar
casi siempre se requerir´a llevar a cabo alg´
un tipo de adaptaci´on. Pero, previamente, ser´ıa conveniente evaluar la viabilidad de esa adaptaci´on, y el esfuerzo
que conllevar´ıa realizarla [5,6,15]. As´ı dada la especificaci´on de un PIM y un
PSM, nuestro objetivo es el de obtener la especificaci´on de un adaptador que
resuelva sus diferencias. Cuando el dise˜
no y la implementaci´on de este adaptador
sean abordables y posibles, el enfoque de MDA nos permitir´a generar su c´odigo
partiendo de los tres modelos de su PSM. En otro caso, la no viabilidad para
derivar el adaptador ser´a indicativo de que es mejor generar la implementaci´on
del servicio siguiendo la t´ecnica est´andar de desarrollo descendente de MDA
desde el PIM del servicio original (v´ease lado izquierdo de la Figura 1).
En u
´ltima instancia, cuando los requisitos del sistema obliguen a reutilizar un
servicio Web concreto para la implementaci´on del mismo (por ejemplo, servicios
financieros ofrecidos por proveedores externos como VISA o AMEX) ser´a necesario acomodar nuestro dise˜
no software (PIM) y la arquitectura de nuestro sistema a los servicios existentes. Quiz´as usando los m´etodos de desarrollo en espiral, tal y como se describe en [18,24].
3.1.
Viabilidad pr´
actica de esta aproximaci´
on
A d´ıa de hoy, no todas nuestras suposiciones son posibles y, convertirlas en
una realidad requiere esfuerzo y trabajo por desarrollar. Sin embargo, la mayor´ıa
de ellas entendemos que son abordables a corto plazo y en ese sentido parece
encaminarse el progreso.
Aunque ya apunt´abamos en otros apartados la falta de documentaci´on disponible
sobre determinados aspectos de los servicios Web, a nivel estructural esta carencia no se presenta: normalmente la signatura de sus interfaces suele estar accesible al usuario, arquitecto o dise˜
nador del sistema como es nuestro caso. Sin
embargo, la situaci´on a nivel de la sem´antica del comportamiento o la coreograf´ıa
no es tan brillante; aunque claramente tanto desarrolladores como vendedores
de software convienen en la necesidad de documentar ambos aspectos a fin de
facilitar la reutilizaci´on de los servicios Web. Es por ello que esta toma de conciencia, nos hace prever la viabilidad de obtener en breve los tres modelos PSM
correspondientes a la estructura, sem´antica del comportamiento y coreograf´ıa de
un servicio Web partiendo de su documentaci´on p´
ublica.
En segundo lugar, considerar la posibilidad de descomponer la funcionalidad
de un PIM en un conjunto de PIMs individuales que encapsulen determinados
aspectos de la l´ogica del negocio, no es s´olo posible, sino tambi´en deseable en
el tiempo. De este modo, MDA garantizar´ıa la reutilizaci´on de modelos y transformaciones que har´ıan de la tarea del dise˜
nador un proceso de ensamblado y
conversi´on de modelos (la mayor´ıa de ellos ya validados e implementados).
Sin embargo, esta descomposici´on a nivel de comportamiento y coreograf´ıa
no es viable a´
un. Una r´apida ojeada a la lista de discusi´on de MDA o WSchoreography, revelan la actividad y la lucha que la comunidad cient´ıfica en el
campo de la ingenier´ıa del software sigue batiendo para tratar de consensuar un
modelo del comportamiento y una notaci´on para expresarla. Esperamos en este
sentido, que UML 2.0 aporte esa unificaci´on haciendo valer la “U” de sus siglas,
e impulsando el desarrollo y la disponibilidad de herramientas que apoyen el
est´andar.
En tercer lugar, nuestra aproximaci´on conf´ıa en la disponibilidad de transformaciones MDA entre los metamodelos de las notaciones usadas en el PIM
para describir la estructura, el comportamiento y la coreograf´ıa, y las empleadas
en la descripci´on del PSM. De hecho, actualmente se han presentado numerosas
propuestas que describen transformaciones entre leguajes como UML (diagrama de clases) y Java (interfaces), EDOC y BPEL4WS, etc. [4]. Sin embargo,
a´
un requieren madurez, resultando m´as prometedoras en un futuro cuando se
consideren desde la perspectiva de MOF/QVT.
Supusimos, en cuarto lugar, la existencia de operadores formales (≤) y herramientas para comprobar la sustituibilidad de dos especificaciones. Nuevamente, a nivel estructural la situaci´on es f´acil de resolver, puesto que implica
verificar una relaci´on de subtipado entre interfaces. Sin embargo, queda mucho
trabajo por desarrollar en los otros dos niveles (comportamiento y coreograf´ıa),
para los cuales existe un conjunto muy limitado de operadores y herramientas
(b´asicamente, los trabajos de Gary Leavens sobre Larch [13,12], y los trabajos
de Carlos Canal et al. para coreograf´ıa [6,7]).
Finalmente, queda tambi´en mucho por hacer respecto respecto a la derivaci´on
(semi)automatizada de adaptadores software. Aunque contamos ya con algunos
resultados iniciales muy prometedores, la mayor´ıa de los problemas que aparecen
est´an sin resolver del todo. Falta definir distancias entre las especificaciones [15],
decidir sobre la posible existencia de un wrapper que resuelva esas incompatibilidades, generar los wrappers a diferentes niveles, etc.
4.
Conclusiones
En este art´ıculo, hemos discutido y presentado una propuesta para tratar
de abordar la reutilizaci´on de servicios Web en el contexto de MDA. Aunque
basada en un conjunto de suposiciones iniciales, el estudio de la viabilidad de
estos supuesto nos ha ayudado a detectar l´ıneas en las que seguir trabajando.
Sin embargo, el problema general de la reutilizaci´on es mucho m´as complejo
de lo que aqu´ı hemos presentado. Nuestra simplificaci´on se ha centrado en tres aspectos de los sistemas: estructura, comportamiento y coreograf´ıa. Estos modelos
nos permiten especificar e implementar la mayor´ıa de las propiedades “operacionales” de los sistemas: b´asicamente, su funcionalidad y algunos requisitos de
seguridad y QoS. Sin embargo, ¿c´omo tratar los requisitos extra funcionales (por
ejemplo, robustez, estabilidad, usabilidad, mantenibilidad, etc.)? Muchos de estos requisitos son m´as importantes que la propia funcionalidad cuando hablamos
de reutilizar o ampliar la funcionalidad de un sistema ya existente. Como de costumbre, esto corresponde a una investigaci´on futura.
Agradecimientos Agradecemos a los revisores sus comentarios, sugerencias
y reflexiones para mejorar nuestra propuesta. Este trabajo ha sido parcialmente
soportado por el proyecto espa˜
nol TIC2002- 04309-C02-02.
Referencias
1. K. Arnout and B. Meyer. Finding implicit contracts in .NET components. In F. S.
de Boer, M. M. Bonsangue, S. Graf, and W.-P. de Roever, editors, Formal Methods for Components and Objects (First International Symposium, FMCO 2002),
number 2852 in Lecture Notes in Computer Science, pages 285–318, Leiden, The
Netherlands, 2003. Springer-Verlag, Heildelberg. http://www.inf.ethz.ch/ meyer/publications/extraction/extraction.pdf.
2. R. Bastide, O. Sy, and P. Palanque. Formal specification and prototyping
of CORBA systems. In Proceedings of ECOOP’99, number 1628 in Lecture
Notes in Computer Science, pages 474–494, Lisbon, Portugal, 14–18 June 1999.
Springer-Verlag, Heildelberg.
3. M. F. Bertoa, J. M. Troya, and A. Vallecillo. A survey on the quality information
provided by software component vendors. In Proc. of the 7th ECOOP Workshop
on Quantitative Approaches in Object-Oriented Software Engineering (QAOOSE
2003), pages 25–30, Darmstadt, Germany, 21 July 2003.
4. J. B´ezivin, S. Hammoudi, D. Lopes, and F. Jouault. An experiment in mapping
web services to implementation platforms. Reserach Report 04.01, University of
Nantes, Mar. 2004.
5. A. Bracciali, A. Brogi, and C. Canal. A formal approach to component adaptation.
Journal of Systems and Software, Special Issue on Automated Component-Based
Software Engineering (in press), 2004.
6. A. Brogi, C. Canal, E. Pimentel, and A. Vallecillo. Formalizing web services
choreographies. In Proc. of the 1st International Workshop on Web Services
and Formal Methods (WS-FM’04), volume 86 of Electronic Notes in Theoretical
Computer Science, pages 1–20, Pisa, Italy, Sept. 2004. Elsevier.
7. C. Canal, L. Fuentes, E. Pimentel, J. M. Troya, and A. Vallecillo. Adding roles to
CORBA objects. IEEE Trans. Softw. Eng., 29(3):242–260, Mar. 2003.
8. J. Cheesman and J. Daniels. UML Components. A simple process for specifying
component-based software. Addison-Wesley, Boston, 2000.
9. IBM. Business Process Execution Language for Web services (BPEL4WS)
1.1.
IBM and Microsoft, May 2003.
Available at http://www106.ibm.com/developerworks/webservices/library/ws-bpel/.
10. ITU-T. Message Sequence Charts. International Telecommunications Union,
Geneva, Switzerland, 1994. ITU-T Recommendation Z.120.
11. ITU-T. SDL: Specification and Description Language. International Telecommunications Union, Geneva, Switzerland, 1994. ITU-T Recommendation Z.100.
12. G. T. Leavens.
Larch-corba.
ens/main.html#LarchCORBA.
http://www.cs.iastate.edu/
leav-
13. G. T. Leavens, A. L. Baker, and C. Ruby. JML: A notation for detailed design.
In H. Kilov, B. Rumpe, and I. Simmonds, editors, Behavioral Specifications of
Businesses and Systems, pages 175–188. Kluwer Academic Publishers, 1999. JML
web page: http://www.cs.iastate.edu/ leavens/JML.html.
14. A. McNeile and N. Simons. Methods of behaviour modelling, Apr. 2004.
http://www.metamaxim.com/download/documents/Methods.pdf.
15. R. Mili, J. Desharnais, M. Frappier, and A. Mili. Semantic distance between
specifications. Theoretical Comput. Sci., 247:257–276, Sept. 2000.
16. J. Miller and J. Mukerji. MDA Guide. Object Management Group, Jan. 2003.
OMG document ab/2003-05-01.
˜
˜
17. O.Nierstrasz.
Regular types for active objects. In O.Nierstrasz
and D. Tsichritzis,
editors, Object-Oriented Software Composition, pages 99–121. Prentice-Hall, 1995.
˜
18. B.Nuseibeh.
Weaving together requirements and architectures. IEEE Computer,
34(3):115–117, Mar. 2001.
19. OMG. Model Driven Architecture. A Technical Perspective. Object Management
Group, Jan. 2001. OMG document ab/2001-01-01.
20. A. Vallecillo, J. Hern´
andez, and J. M. Troya. New issues in object interoperability.
In Object-Oriented Technology: ECOOP 2000 Workshop Reader, number 1964 in
Lecture Notes in Computer Science, chapter 21, pages 256–269. Springer-Verlag,
Heidelberg, 2000.
21. A. M. Zaremski and J. M. Wing. Signature matching: A tool for using software
libraries. ACM Trans. on Software Engineering and Methodology, 4(2):146–170,
Apr. 1995.
22. A. M. Zaremski and J. M. Wing. Specification matching of software components.
ACM Trans. on Software Engineering and Methodology, 6(4):333–369, Oct. 1997.
23. L. Iribarne, J. M. Troya and A. Vallecillo. A Trading Service for COTS Components. The Computer Journal, 47(3):342-357, May 2004.
24. L. Iribarne, J. M. Troya and A. Vallecillo. Describing Architectural Requirements
of COTS Components. In Chapter 2 of Component-based Software Development:Case Studies (Kung-Kiu Lau ed.), pp. 35-56. World Scientific Press, March
2004, ISBN 981-238-828-1.