En este trabajo presentamos una herramienta que permite a los ingenieros de software realizar ciertas verificaciones sobre diseños arquitecturales. Esta herramienta, llamada Darwin, utiliza como lenguaje de modelado la notación BON, en cuanto las verificaciones son realizadas por medio del lenguaje lógico Alloy. Adicionalmente presentamos algunas de las funcionalidades que agregaremos a la herramienta en un futuro próximo.Eje: Ingeniería en SoftwareRed de Universidades con Carreras en Informática (RedUNCI

Baum, Gabriel Alfredo

Castro, Pablo Francisco

Demasi, Ramiro Adrián

Ponzio, Pablo Daniel

Spanish

SEDICI - Repositorio de la UNLP

Darwin, Una Herramienta para Verificar Disen˜os
Arquitecturales
Pablo Castro Pablo Ponzio
Ramiro Demasi
Universidad Nacional de Rı´o Cuarto
Departamento de Computacio´n
e-mail: {pcastro,pponzio,rdemasi}@dc.exa.unrc.edu.ar
Gabriel Baum
LIFIA - Universidad Nacional de La Plata
e-mail: gbaum@sol.info.unlp.edu.ar
cmr
Resumen
En este trabajo presentamos una herramienta que permite a los in-
genieros de software realizar ciertas verificaciones sobre disen˜os arquitec-
turales. Esta herramienta, llamada Darwin, utiliza como lenguaje de mode-
lado la notacio´n BON, en cuanto las verificaciones son realizadas por medio
del lenguaje lo´gico Alloy. Adicionalmente presentamos algunas de las fun-
cionalidades que agregaremos a la herramienta en un futuro pro´ximo.
1. Introduccio´n
Con la aparicio´n del paradigma de orientacio´n a objetos, surgieron diferentes
lenguajes de modelado para soportar esta nueva tecnolog´ıa. En los u´ltimos tiem-
pos aparecio´ como una alternativa a los lenguajes ma´s reconocidos (por ejemplo,
UML [9]) el lenguaje de modelado BON (Bussiness Object Notation [3]) En [4] se
muestra como este lenguaje permite una aplicacio´n transparente de los me´todos
formales. Esto se debe principalmente a su notacio´n simple, y a que fue disen˜ado
para soportar el me´todo de Disen˜o por Contratos, incluyendo un lenguaje formal
de aserciones. Otras caracter´ısticas importantes de BON son Seamlessness (desar-
rollo sin transiciones), que intuitivamente significa que el paso de una etapa en el
1
desarrollo a la siguiente es directo, y Reversibilidad, que dice que los cambios real-
izados en una etapa del desarrollo son reflejados en las anteriores. Estas favorecen
el reuso y simplifican el mantenimiento del software.
El presente trabajo se basa en la integracio´n de dos herramientas que pueden
ser utilizadas en la etapa de disen˜o del desarrollo de un sistema de software, la
notacio´n BON, y el lenguaje formal Alloy. Basa´ndonos en [4], implementamos una
herramienta, que llamamos Darwin Tool, la cual permite editar diagramas BON y
realizar automa´ticamente la traduccio´n del modelo al lenguaje lo´gico Alloy, lo que
permite verificar propiedades del modelo utilizando la herramienta Alloy Analyzer.
Otra motivacio´n para la realizacio´n de una herramienta CASE para BON es que
actualmente existe una carencia de herramientas que soporten esta notacio´n. La
ma´s importante de ellas es EiffelCase de ISE, la cual es privativa 1.
El presente art´ıculo esta´ estructurado de la siguiente forma. En la seccio´n 2
se presenta el disen˜o de la herramienta. En la seccio´n 3 mostramos un ejemplo
de aplicacion de Darwin. Finalmente, presentamos las conclusiones y los trabajos
futuros.
2. Disen˜o de Darwin
Darwin esta´ dividida en dos modulos principales. Por un lado, posee una inter-
faz gra´fica para la interaccio´n con el usuario, que tiene las caracter´ısticas cla´sicas
de una herramienta CASE. Por otra parte, se encuentra un parser traductor lla-
mado Bon2Alloy el cual permite traducir modelos descritos en la notacio´n textual
de BON a especificaciones Alloy. Ma´s detalladamente:
Darwin Tool: Parte gra´fica de la herramienta, la cual fue constru´ıda utilizan-
do las librer´ıas wxWidgets y OGL (ver [8]). Esta herramienta, adema´s de las
funcionalidades cla´sicas, permite generar co´digo textual BON a partir de un
modelo gra´fico.
Bon2Alloy: Parser traductor que toma como entrada un modelo en notacio´n
textual BON y genera una especificacio´n Alloy correspondiente al modelo
dado. Podemos decir que esta aplicacio´n posee dos partes, por un lado un
parser que construye un conjunto de objetos que son una abstraccio´n de un
modelo BON. Los cuales, adema´s poseen las funcionalidades necesarias para
producir el co´digo Alloy correspondiente.
La figura 1 muestra una intuicio´n sobre la forma en que funciona Darwin. A con-
tinuacio´n daremos una explicacio´n detallada del diagrama:
1Darwin Tool ha sido desarrollada bajo el paradigma GNU.
2
Figura 1: Interaccio´n entre los Componentes de Darwin
1. El usuario edita un diagrama BON en Darwin Tool (1, 2 y 3).
2. Darwin Tool genera el co´digo BON asociado al diagrama (4).
3. Luego realiza una llamada a Bon2Alloy, la cual automa´ticamente traduce el
co´digo BON a una especificacio´n Alloy (5 y 6).
4. Finalmente se realiza una llamada al Alloy Analyzer, con la especificacio´n Al-
loy como entrada, y esta genera un modelo (cuando es posible) que satisface
la especificacio´n dada (7 y 8).
Es importante resaltar la flexibilidad que provee la separacio´n en mo´dulos, ya
que es posible desarrollar ambas partes en paralelo sin afectar la integridad del
programa.
3. Un Caso de Estudio
Hemos testeado el funcionamiento de la herramienta con varios casos de estudio,
en este art´ıculo mostramos so´lo uno de ellos por cuestiones de espacio. El siguiente
gra´fico presenta en detalle un disen˜o BON.
Este disen˜o fue traducido automa´ticamente por Darwin y verificado por la
herramienta Alloy, obteniendo un modelo del disen˜o que asegura su consistencia.
3
Figura 2: Caso de Estudio
4. Conclusiones
Consideramos que este proyecto forma parte de los primeros pasos en la inte-
gracio´n de me´todos formales con las te´cnicas de disen˜o informales, las cuales son
usadas ampliamente en la actualidad. La poca utilizacio´n de los me´todos formales
en la industria se debe a que requiere cierta clase de conocimientos matema´ticos
por parte del usuario, y este tipo de entrenamiento es costoso en tiempo y dinero.
Pero tambie´n sabemos que, en aplicaciones cr´ıticas, los me´todos formales son nece-
sarios si se quiere asegurar el correcto funcionamiento de las mismas. Aqu´ı es donde
Darwin Tool entra en escena, ya que, permite utilizar me´todos formales para veri-
ficar algunas propiedades de un disen˜o realizado en la notacio´n BON, esto implica
que la utilizacio´n de formalismos es intuitiva para el usuario, es decir, no necesita
tener ningu´n tipo de conocimientos adicionales para aplicarlos. Este enfoque es
completamente diferente al de las herramientas existentes en la actualidad, como
por ejemplo, z-eves que permite modelar en el lenguaje Z, Isabelle/HOL, el de-
mostrador semi-automa´tico de teoremas, e inclusive el mismo Alloy, ya que, fueron
pensadas para usuarios con una preparacio´n matema´tica adecuada.
5. Trabajos Futuros
Soportar la forma expandida de las clases BON y los diagramas de secuencia
de la misma notacio´n.
Realizar chequeos sobre las aserciones introducidas por el usuario, como por
ejemplo, que sean correctas en cuanto a tipos.
Permitir mostrar al usuario el resultado del chequeo (mediante Alloy An-
alyzer) del modelo generado por Bon2Alloy, de forma tal que no requiera
4
conocimientos sobre Alloy para poder interpretar los resultados, logrando la
integracio´n completa del me´todo BON con Alloy.
Extender el lenguaje BON para soportar operadores de la lo´gica relacional,
como por ejemplo, la clausura transitiva.
Soportar los cuantificadores existencial y universal en las aserciones BON.
Considerar la traduccio´n de features BON que incluyan para´metros.
Permitir el chequeo de herencia y de invariantes de clase, lo que permitir´ıa
chequear el cumplimiento del principio de subcontratacio´n.
Realizar chequeos de sintaxis y tipos antes de realizar la traduccio´n, para
mejorar la eficiencia, ya que, estos errores actualmente son manejados por el
Alloy Analyzer.
Referencias
[1] D. Jackson. Alloy 3.0 Reference Manual. May 2004.
[2] D. Jackson. Micromodels of Software: Lightweight Modeling and Analisis with
Alloy. February 2002.
[3] Kim Walde´n and Jean-Marc Nerson. Seamless Object-Oriented Software Ar-
chitecture.
[4] Castro Pablo, Baum Grabriel. Integrando BON con Alloy.
[5] Castro Pablo, Baum Gabriel. Utilizando Contratos de Reuso con Alloy. Anales
del CASIC 2001, 2001.
[6] Castro Pablo, Baum Gabriel. Maquinas Evolutivas. Anales del CASIC 2002,
2002.
[7] Castro Pablo, Baum Gabriel. Una Formalizacio´n del Proceso de Desarrollo.
Anales del CLEI 2003, 2003.
[8] Julian Smart, Robert Roebling, Vadim Zeitlin, Robin Dunn. wxWindows
2.4.2: A portable C++ and Python GUI toolkit. September 2003.
[9] J.Rumbaugh G.Booch and I.Jacobson. The Unified Modeling Language User
Guide. Addison-Wesley, 1999.
[10] Richard F. Paige and Jonathan S. Ostroff. A Comparation of Business Object
Language and the Unified Modeling Language.
5


Darwin: una herramienta para verificar diseños arquitecturales

Servicio de Difusión de la Creación Intelectual

Darwin, Una Herramienta para Verificar Disen˜osArquitecturalesPablo Castro Pablo PonzioRamiro DemasiUniversidad Nacional de Rı´o CuartoDepartamento de Computacio´ne-mail: {pcastro,pponzio,rdemasi}@dc.exa.unrc.edu.arGabriel BaumLIFIA - Universidad Nacional de La Platae-mail: gbaum@sol.info.unlp.edu.arcmrResumenEn este trabajo presentamos una herramienta que permite a los in-genieros de software realizar ciertas verificaciones sobre disen˜os arquitec-turales. Esta herramienta, llamada Darwin, utiliza como lenguaje de mode-lado la notacio´n BON, en cuanto las verificaciones son realizadas por mediodel lenguaje lo´gico Alloy. Adicionalmente presentamos algunas de las fun-cionalidades que agregaremos a la herramienta en un futuro pro´ximo.1. Introduccio´nCon la aparicio´n del paradigma de orientacio´n a objetos, surgieron diferenteslenguajes de modelado para soportar esta nueva tecnolog´ıa. En los u´ltimos tiem-pos aparecio´ como una alternativa a los lenguajes ma´s reconocidos (por ejemplo,UML [9]) el lenguaje de modelado BON (Bussiness Object Notation [3]) En [4] semuestra como este lenguaje permite una aplicacio´n transparente de los me´todosformales. Esto se debe principalmente a su notacio´n simple, y a que fue disen˜adopara soportar el me´todo de Disen˜o por Contratos, incluyendo un lenguaje formalde aserciones. Otras caracter´ısticas importantes de BON son Seamlessness (desar-rollo sin transiciones), que intuitivamente significa que el paso de una etapa en el1desarrollo a la siguiente es directo, y Reversibilidad, que dice que los cambios real-izados en una etapa del desarrollo son reflejados en las anteriores. Estas favorecenel reuso y simplifican el mantenimiento del software.El presente trabajo se basa en la integracio´n de dos herramientas que puedenser utilizadas en la etapa de disen˜o del desarrollo de un sistema de software, lanotacio´n BON, y el lenguaje formal Alloy. Basa´ndonos en [4], implementamos unaherramienta, que llamamos Darwin Tool, la cual permite editar diagramas BON yrealizar automa´ticamente la traduccio´n del modelo al lenguaje lo´gico Alloy, lo quepermite verificar propiedades del modelo utilizando la herramienta Alloy Analyzer.Otra motivacio´n para la realizacio´n de una herramienta CASE para BON es queactualmente existe una carencia de herramientas que soporten esta notacio´n. Lama´s importante de ellas es EiffelCase de ISE, la cual es privativa 1.El presente art´ıculo esta´ estructurado de la siguiente forma. En la seccio´n 2se presenta el disen˜o de la herramienta. En la seccio´n 3 mostramos un ejemplode aplicacion de Darwin. Finalmente, presentamos las conclusiones y los trabajosfuturos.2. Disen˜o de DarwinDarwin esta´ dividida en dos modulos principales. Por un lado, posee una inter-faz gra´fica para la interaccio´n con el usuario, que tiene las caracter´ısticas cla´sicasde una herramienta CASE. Por otra parte, se encuentra un parser traductor lla-mado Bon2Alloy el cual permite traducir modelos descritos en la notacio´n textualde BON a especificaciones Alloy. Ma´s detalladamente:Darwin Tool: Parte gra´fica de la herramienta, la cual fue constru´ıda utilizan-do las librer´ıas wxWidgets y OGL (ver [8]). Esta herramienta, adema´s de lasfuncionalidades cla´sicas, permite generar co´digo textual BON a partir de unmodelo gra´fico.Bon2Alloy: Parser traductor que toma como entrada un modelo en notacio´ntextual BON y genera una especificacio´n Alloy correspondiente al modelodado. Podemos decir que esta aplicacio´n posee dos partes, por un lado unparser que construye un conjunto de objetos que son una abstraccio´n de unmodelo BON. Los cuales, adema´s poseen las funcionalidades necesarias paraproducir el co´digo Alloy correspondiente.La figura 1 muestra una intuicio´n sobre la forma en que funciona Darwin. A con-tinuacio´n daremos una explicacio´n detallada del diagrama:1Darwin Tool ha sido desarrollada bajo el paradigma GNU.2Figura 1: Interaccio´n entre los Componentes de Darwin1. El usuario edita un diagrama BON en Darwin Tool (1, 2 y 3).2. Darwin Tool genera el co´digo BON asociado al diagrama (4).3. Luego realiza una llamada a Bon2Alloy, la cual automa´ticamente traduce elco´digo BON a una especificacio´n Alloy (5 y 6).4. Finalmente se realiza una llamada al Alloy Analyzer, con la especificacio´n Al-loy como entrada, y esta genera un modelo (cuando es posible) que satisfacela especificacio´n dada (7 y 8).Es importante resaltar la flexibilidad que provee la separacio´n en mo´dulos, yaque es posible desarrollar ambas partes en paralelo sin afectar la integridad delprograma.3. Un Caso de EstudioHemos testeado el funcionamiento de la herramienta con varios casos de estudio,en este art´ıculo mostramos so´lo uno de ellos por cuestiones de espacio. El siguientegra´fico presenta en detalle un disen˜o BON.Este disen˜o fue traducido automa´ticamente por Darwin y verificado por laherramienta Alloy, obteniendo un modelo del disen˜o que asegura su consistencia.3Figura 2: Caso de Estudio4. ConclusionesConsideramos que este proyecto forma parte de los primeros pasos en la inte-gracio´n de me´todos formales con las te´cnicas de disen˜o informales, las cuales sonusadas ampliamente en la actualidad. La poca utilizacio´n de los me´todos formalesen la industria se debe a que requiere cierta clase de conocimientos matema´ticospor parte del usuario, y este tipo de entrenamiento es costoso en tiempo y dinero.Pero tambie´n sabemos que, en aplicaciones cr´ıticas, los me´todos formales son nece-sarios si se quiere asegurar el correcto funcionamiento de las mismas. Aqu´ı es dondeDarwin Tool entra en escena, ya que, permite utilizar me´todos formales para veri-ficar algunas propiedades de un disen˜o realizado en la notacio´n BON, esto implicaque la utilizacio´n de formalismos es intuitiva para el usuario, es decir, no necesitatener ningu´n tipo de conocimientos adicionales para aplicarlos. Este enfoque escompletamente diferente al de las herramientas existentes en la actualidad, comopor ejemplo, z-eves que permite modelar en el lenguaje Z, Isabelle/HOL, el de-mostrador semi-automa´tico de teoremas, e inclusive el mismo Alloy, ya que, fueronpensadas para usuarios con una preparacio´n matema´tica adecuada.5. Trabajos FuturosSoportar la forma expandida de las clases BON y los diagramas de secuenciade la misma notacio´n.Realizar chequeos sobre las aserciones introducidas por el usuario, como porejemplo, que sean correctas en cuanto a tipos.Permitir mostrar al usuario el resultado del chequeo (mediante Alloy An-alyzer) del modelo generado por Bon2Alloy, de forma tal que no requiera4conocimientos sobre Alloy para poder interpretar los resultados, logrando laintegracio´n completa del me´todo BON con Alloy.Extender el lenguaje BON para soportar operadores de la lo´gica relacional,como por ejemplo, la clausura transitiva.Soportar los cuantificadores existencial y universal en las aserciones BON.Considerar la traduccio´n de features BON que incluyan para´metros.Permitir el chequeo de herencia y de invariantes de clase, lo que permitir´ıachequear el cumplimiento del principio de subcontratacio´n.Realizar chequeos de sintaxis y tipos antes de realizar la traduccio´n, paramejorar la eficiencia, ya que, estos errores actualmente son manejados por elAlloy Analyzer.Referencias[1] D. Jackson. Alloy 3.0 Reference Manual. May 2004.[2] D. Jackson. Micromodels of Software: Lightweight Modeling and Analisis withAlloy. February 2002.[3] Kim Walde´n and Jean-Marc Nerson. Seamless Object-Oriented Software Ar-chitecture.[4] Castro Pablo, Baum Grabriel. Integrando BON con Alloy.[5] Castro Pablo, Baum Gabriel. Utilizando Contratos de Reuso con Alloy. Analesdel CASIC 2001, 2001.[6] Castro Pablo, Baum Gabriel. Maquinas Evolutivas. Anales del CASIC 2002,2002.[7] Castro Pablo, Baum Gabriel. Una Formalizacio´n del Proceso de Desarrollo.Anales del CLEI 2003, 2003.[8] Julian Smart, Robert Roebling, Vadim Zeitlin, Robin Dunn. wxWindows2.4.2: A portable C++ and Python GUI toolkit. September 2003.[9] J.Rumbaugh G.Booch and I.Jacobson. The Unified Modeling Language UserGuide. Addison-Wesley, 1999.[10] Richard F. Paige and Jonathan S. Ostroff. A Comparation of Business ObjectLanguage and the Unified Modeling Language.5

http://sedici.unlp.edu.ar/bitstream/handle/10915/21121/Documento_completo.pdf?sequence=1

Darwin: una herramienta para verificar diseños arquitecturales

Abstract

Similar works

Full text

Available Versions

SEDICI - Repositorio de la UNLP

Servicio de Difusión de la Creación Intelectual