- Asociación: se establece entre los actores y casos de uso.
- <<include>>: se presenta cuando una instancia del caso de uso origen incluye también el comportamiento descrito por el caso de uso destino; es decir, un caso de uso incluido describe un objetivo de bajo nivel de un caso de uso base (Cockburn, 2000).
- <<extends>>: ocurre cuando el caso de uso origen extiende el comportamiento del caso de uso destino; en otras palabras, el caso de uso a extender invoca el caso de uso base bajo ciertas condiciones (Cockburn, 2000).
- <<inheritance>>: se presenta cuando un caso de uso origen hereda la especificación del caso de uso destino y posiblemente la modifica y/o amplía. Este tipo de relación también se presenta entre los actores.
La representación gráfica de los elementos del diagrama de casos de uso se puede apreciar en la Figura 1. Las principales ventajas de utilizar el diagrama de casos de uso, según Firesmith (2002) son:
- La captura de los requisitos desde el punto de vista del usuario, lo cual permite el correcto desarrollo del sistema.
- La utilización de los casos de uso para elicitar y documentar los requisitos funcionales que se recolectan en la fase de definición del ciclo de vida del software. Estos requisitos también se verifican y validan mediante los casos de uso.
- El manejo de la complejidad en sistemas robustos, donde se descompone el problema en funciones más simples.
Figura 1. Elementos del diagrama de casos de uso.
Figure 1. Elements of the use case diagram.
2.2 Metamodelamiento ]]> Según De Lara y Vangheluwe (2003), el metamodelamiento proporciona los formalismos apropiados para describir los diferentes aspectos o componentes de los modelos que representan sistemas lógicos y físicos. Este proceso se realiza mediante la descripción de las clases, atributos y relaciones que conforman el modelo. Los metamodelos se describen gráficamente mediante metaformalismos (notaciones de modelamiento de alto nivel). El diagrama de clases de UML y el diagrama entidad-relación son algunos de los formalismos que se utilizan.
El metamodelamiento, utilizado en la conversión de modelos, presenta las siguientes ventajas:
- Produce formalismos personalizados creando ambientes propios de metamodelamiento.
- Sirve de base para el análisis de modelos, debido a que facilita la documentación y especificación de los mismos.
- Permite diseñar nuevos formalismos mediante la modificación parcial o total del metamodelo.
Las herramientas que se emplean para el metamodelamiento se denominan metaCASE; algunas de las más conocidas son:
- DOME® (Domain Modeling Environment): es una herramienta gratuita creada por Honeywell Technology Center. El formalismo que utiliza es una modificación del diagrama de clases de UML a nivel gráfico, que se especifica empleando código en los lenguajes Alter y Smalltalk (DOME, 2007a y 2007b).
- MetaEdit®: es un metaCASE comercial desarrollado por la compañía MetaCASE Consulting. Su formalismo es el diagrama entidad-relación (Smolander et al., 1991).
- AToM3®: es una herramienta gratuita desarrollada por Juan F. de Lara, que permite la creación, edición, transformación, simulación y optimización de metamodelos y modelos. Su formalismo es el diagrama entidad-relación y genera código Python (De Lara y Vangheluwe, 2002). ]]>
- Conceptos: es un sustantivo o un sintagma nominal del discurso del interesado.
- Relación estructural: es una relación permanente entre los conceptos. Está asociada con los verbos “es” y “tiene”.
- Relación dinámica: está asociada con los verbos de actividad definidos por Vendler (1967).
- Implicación: sirve para unir relaciones dinámicas o para unir condicionales con relaciones dinámicas, estableciendo entre ellas una relación causa-efecto.
- Condicional: es una relación de causalidad que indica las restricciones que los conceptos deben cumplir.
- Nota: permite especificar los diferentes valores que puedan ser asignados a los sintagmas nominales o conceptos. Este es un elemento nuevo que se viene trabajando en el grupo de Ingeniería de Software para representar las posibles instancias de un determinado concepto del mundo.
- Conexión: permite enlazar los conceptos con las relaciones y las relaciones con los conceptos. Un tipo especial de conexión permite enlazar los conceptos y las notas. ]]>
- Se obtienen fácilmente desde un lenguaje controlado, denominado UN-Lencep (Zapata et al., 2006b), por lo cual su discurso no presenta ambigüedades.
- Agrupan características de los diferentes tipos de diagramas de UML.
- Meta nivel: ambiente de modelamiento con el diagrama entidad-relación.
- Nivel modelo: ambiente de modelamiento con formalismos creados por el usuario.
- Modelo: varias instancias de modelos.
- Se suele utilizar como punto de partida un discurso en lenguaje natural o controlado que describe el “sistema”. Tal es el caso de las especificaciones textuales de los casos de uso o las especificaciones detalladas que se emplean en dos de los trabajos. Si bien este punto de partida permite la obtención del diagrama, un discurso tal sólo se puede obtener cuando ha transcurrido gran parte de la etapa de análisis del problema que se está analizando, e incluso requiere que ya se haya definido una solución al mismo. Si se procura la obtención temprana del diagrama, el punto de partida debería ser una descripción del dominio del problema y no de su solución.
- Casi todos los trabajos requieren una alta participación del analista para tomar las decisiones pertinentes a la generación del diagrama de casos de uso. Tomando en consideración que un trabajo como los planteados se realiza para liberar al analista de trabajos en los que lo podría sustituir de manera adecuada la máquina, sería deseable que las decisiones que debiera tomar para el trazado del diagrama de casos de uso fueran mínimas, o incluso nulas. Esto haría que el papel del analista se especializara hacia una mejor comprensión del mundo, en lugar de tener que conceptualizar los diagramas y además trazarlos de forma asistida en las herramientas CASE actuales.
- Ninguno de los trabajos presentados realiza la identificación completa de los elementos del diagrama de casos de uso. En especial, las relaciones especiales <<include>>, <<extends>> e <<inheritance>>, correspondientes a la superestructura de UML 2.0 (OMG, 2002), son las que menos se identifican.
- El caso de uso incluido es el que se identifica en la triada 2.
- El Actor hijo es el concepto que está en ambas triadas.
- El Actor padre está dado por el concepto origen de la relación estructural.
- El caso de uso padre esta dado por la relación dinámica1 y concepto2.
- El caso de uso padre está dado por la Relación dinámica1 y el Concepto2.
- Los casos de uso hijos están determinados por la Relación dinámica1, el Concepto2 y cada línea o elemento de la nota.
- Cada caso de uso extendido se forma con la relación dinámica y el concepto que tiene asociado
- Se definen, mediante el diagrama entidad-relación disponible en el entorno de AToM3®, los metamodelos del esquema preconceptual y el diagrama de casos de uso, los cuales se pueden observar en las Figuras 3 y 4. A cada entidad de cada uno de los metamodelos se le puede asignar una representación gráfica propia; en el caso de las relaciones estructurales, sólo aceptan las palabras clave ES y TIENE, en tanto que las relaciones dinámicas aceptan cualquier tipo de verbo.
- Se crea la secuencia de aplicación de las reglas de transformación utilizando las reglas definidas en la Sección 4.1. Para ello, se emplea el entorno de AToM3® y se define para cada regla una prioridad, tal como se muestra en la Figura 5; en esta Figura, la secuencia de transformaciones se denomina “EPtoDCU” y está compuesta por cada una de las reglas descritas, en tanto que la prioridad de cada regla es el número que acompaña al nombre de la regla. Además de estas reglas, se implementaron 10 reglas más que permiten eliminar cada uno de los elementos del esquema preconceptual; estas reglas son necesarias puesto que, en el proceso de transformación, los dos metamodelos están activos en la herramienta y deben quedar al final únicamente elementos del diagrama de casos de uso. Cada una de las reglas está compuesta por 4 elementos: LHS, RHS, Condition y Action.
- Se procede a la creación del esquema preconceptual en el entorno suministrado por el AToM3® para ese fin. En ese caso, se debe mantener activo el metamodelo correspondiente.
- Se activa la transformación y aparece el diagrama de casos de uso, que es el resultado de la aplicación de las reglas que se definieron. ]]>
- Se podría comprobar si es posible obtener el último de los diagramas comportamentales que aún no se obtiene automáticamente de los Esquemas Preconceptuales: el diagrama de actividades.
- Igualmente, se podría comprobar si es posible obtener a partir de estos Esquemas el diagrama de secuencias de la versión 2.0 de UML, cuya sintaxis ya lo aleja sustancialmente del diagrama
- de comunicación, que ya es obtenible desde Esquemas Preconceptuales.
- Falta por establecer si existen reglas adicionales que puedan generar variaciones sobre los elementos identificados en el diagrama de Casos de Uso.
- Se debería verificar también si se pueden establecer reglas para generar algún tipo de código de las interfaces gráficas de usuario a partir de los resultados de este artículo.
- Finalmente, un área en la que se podría verificar la aplicación de un método similar al propuesto por este artículo, podría ser el área de los requisitos no funcionales; se podría estudiar si tendencias actuales como los aspectos podrían ser modeladas en Esquemas Preconceptuales o si pueden existir reglas de transformación que posibiliten su modelamiento desde fases tempranas del ciclo de vida del software. ]]>
2.3 Esquemas Preconceptuales
Según Zapata et al. (2006b), los esquemas preconceptuales son diagramas que permiten la representación de la terminología de un dominio para facilitar su traducción posterior a diferentes esquemas conceptuales. En la Figura 2 se muestran los diferentes elementos de los esquemas preconceptuales, cuya descripción es la siguiente (Zapata et al., 2006a, 2006b y 2006c):
Figura 2. Elementos de los esquemas preconceptuales.
Figure 2. Elements of Pre-conceptual schemas.
Las principales ventajas de utilizar Esquemas Preconceptuales en la definición de los requisitos son:
AToM3® es una herramienta usada para describir formalismos de cualquier tipo de esquema conceptual; esta herramienta MetaCASE que permite la creación, edición, transformación, simulación y optimización de metamodelos y modelos, y además la generación de código en lenguaje Python (De Lara y Vangheluwe, 2002). Además, AToM3® utiliza técnicas de reescritura gráfica y gramática de grafos para realizar las transformaciones entre formalismos.
En AToM3®, los metamodelos son creados y editados en un ambiente que emplea como formalismo gráfico el diagrama entidad-relación (Véase la Figura 3). La herramienta MetaCASE AToM3 ® tiene la siguiente estructura de modelamiento:
- ]]>
Metametanivel: metamodelo del diagrama entidad-relación.
Figura 3. Metamodelo de los esquemas preconceptuales en el formalismo entidad-relación en AToM3®.
Figure 3. Pre-conceptual schemas metamodel by using the AToM3® entity-relationship formalism.
La Gramática de Grafos en AToM3® permite expresar restricciones y describir las transformaciones entre grafos de manera gráfica. La Gramática de Grafos está compuesta por reglas que mapean desde el lado izquierdo (LHS) al lado derecho (RHS), condiciones y acciones. En las condiciones, se define cuándo una regla puede ser aplicada; en las acciones, se especifica lo que se va a realizar y pueden tener asociadas una prioridad. El LHS puede ser especificado en un formalismo diferente al RHS, y en este caso se trataría de una transformación entre diagramas, o pueden estar especificados en el mismo formalismo, y en ese caso se podría tratar del refinamiento de un mismo diagrama. Algunos de los trabajos que realizan la conversión entre modelos utilizando la herramienta AToM3® son:
Muñoz et al. (2004) proponen un enfoque metodológico para la transformación de un modelo de relaciones de asociación, agregación y composición de UML a un modelo de diseño de un lenguaje de programación genérico orientado a objetos. En este trabajo, se utiliza la gramática de grafos para realizar una descripción precisa y operativa de las transformaciones entre modelos, debido a que poseen una base formal sólida y una sintaxis gráfica que permite la especificación visual y operativa de transformaciones.
]]> De Lara et al. (2003) realizan la conversión del modelo del diagrama de estados a redes de Petri, para realizar el análisis de sistemas híbridos; los autores se basan en el metamodelamiento y en la Gramática de Grafos para definir formal y visualmente las manipulaciones del modelo.Zapata y Alvarez (2005) establecen una transformación entre el diagrama de procesos y el diagrama de casos de uso utilizando la gramática de grafos y complementándola con la implementación de restricciones en código Python.
Los tres trabajos anteriores son indicios de las capacidades de la Gramática de Grafos para permitir la definición de transformaciones entre modelos, uno de los mecanismos que se requiere en el contexto de este artículo para la obtención del diagrama de casos de uso (incluyendo sus relaciones especiales) a partir de los esquemas preconceptuales.
3. OBTENCIÓN DEL DIAGRAMA DE CASOS DE USO A PARTIR DE DIFERENTES REPRESENTACIONES: ESTADO DEL ARTE
En la generación automática o semiautomática del diagrama de casos de uso a partir de las especificaciones de los requisitos de los interesados, se han realizado diversos trabajos que tienen como punto de partida la descripción de los requisitos en lenguajes naturales o controlados orientados a la solución. Esos trabajos se listan a continuación.
Ben Achour (1998 y 1999), el cual está basado en un diálogo interesado-analista, que se enfoca en identificar o especificar los elementos principales de la descripción de los casos de uso. Para ello, define un conjunto de reglas de clarificación, análisis, completitud, mapeo e integración del discurso, y finalmente obtiene algunos de los actores y los casos de uso. Ninguna de las relaciones especiales <<include>>, <<extends>> o <<inheritance>> se identifica en este trabajo.
De manera similar, Pastor et al. (2003 y 2004) proponen una serie de reglas que, a partir de la descripción textual de los casos de uso, que es una especificación funcional en lenguaje controlado, permite obtener el diagrama de secuencias de UML 1.4. Por medio de estas reglas, es posible extender el esquema definido para obtener los elementos esenciales del diagrama de casos de uso, como lo son los actores y los casos de uso, pero estos trabajos se enfocaron únicamente en el trazado del diagrama de secuencias. Las relaciones especiales <<include>> y <<extends>> deben ser declaradas explícitamente en el lenguaje controlado que sirve de base para la conversión.
Dietz (1999) y Shishkov et al. (2002) toman como punto de partida una especificación detallada a partir de la especificación verbal de los requisitos. La especificación detallada utilizada en este trabajo es determinada por el analista y está orientada a la solución del problema; es decir, existe una transformación, realizada por el analista, de los requisitos especificados por el interesado, antes de su utilización para la generación del diagrama. Con este punto de partida, derivan algunos componentes del diagrama de casos de uso como son los actores, los casos de uso, las relaciones de asociación y las relaciones <<include>>; para ello, utilizan el análisis de responsabilidades, el análisis de las denominadas protonormas, el análisis de disparadores y las normas de especificación; el uso de estos elementos requiere la intervención del analista. Además, la relación <<extends>> y la relacion <<inheritance>> no son identificadas en estos trabajos.
Liu y Dong (2003) y Liu et al. (2004) identifican algunos elementos del diagrama de casos de uso y los utiliza como resultado intermedio para identificar los elementos del diagrama de clases. Las principales falencias de este proceso radican en que no se identifican todos los actores, los casos de uso y las relaciones especiales <<include>>, <<extends>> e <<inheritance>>. Además, se necesita la intervención del analista para validar y completar el modelo.
]]> Por último, Zapata y Alvarez (2005) realizan la conversión de diagramas de procesos en diagramas de casos de uso, mediante la definición e implementación de reglas de consistencia entre los dos modelos. Sin embargo, en el diagrama de casos de uso obtenido no se identifican las relaciones especiales de este diagrama.Si bien se ha trabajado en la generación automática del diagrama de casos de uso, existen aún problemas remanentes que se pueden sintetizar así:
Tomando como base estos problemas, se propone en este artículo una solución que, de manera automática, realice la conversión de una representación del discurso del interesado en los diagramas de casos de uso correspondientes, incluyendo todos sus elementos. En la Sección siguiente se presenta esa solución.
4. UNA PROPUESTA PARA LA CONVERSIÓN DE ESQUEMAS PRECONCEPTUALES EN DIAGRAMAS DE CASOS DE USO
La obtención automática del diagrama de casos de uso requiere, como punto de partida, una representación del dominio del problema; para esta propuesta, esa representación se realiza mediante los esquemas preconceptuales, que se describieron en la Sección 2.3. La lectura de estos esquemas se realiza mediante triadas de información, que son conjuntos de tres elementos así: concepto-relación-concepto. Si la relación es estructural, la triada será estructural, y si la relación es dinámica, la triada será dinámica. El concepto que precede a la relación se denomina concepto origen y el que se ubica después de la relación se denomina concepto destino.
]]> 4.1 Reglas de ConversiónPara llevar a cabo la conversión de esquemas preconceptuales a diagramas de caso de uso, esta propuesta define las nueve reglas que se describen seguidamente.
Regla 1: Actor
En una triada dinámica, el concepto origen es un actor.
Regla 2: Caso de uso
Dada una triada dinámica, el nombre de los casos de uso se obtiene concatenando la relación dinámica y el concepto destino.
Regla 3: Asociación o relación entre el actor y el caso de uso.
El actor y el caso de uso detectados a partir de una misma triada dinámica tienen una relación de asociación entre ellos.
Regla 4: Relación <<include>>
Dadas dos triadas dinámicas 1 y 2, si de la relación dinámica de la triada 2 se inicia una relación de implicación a la relación dinámica de la triada 1, entonces existe una relación <<include>>, formada de la siguiente manera:
- ]]>
El caso de uso base es el que se identifica en la triada 1.
Regla 5: Herencia entre actores
Si se tiene una triada estructural y una triada dinámica en las que el concepto destino de a triada estructural sea el mismo concepto origen de la triada dinámica, entonces existe una relación de herencia entre actores definida de la siguiente manera:
Regla 6: Herencia entre casos de uso
Si se tienen las triadas Concepto1-Relación Dinámica1-Concepto2 y Concepto2-Relación Estructural-Concepto3, entonces existe una relación de herencia entre casos de uso definida de la siguiente manera:
- ]]>
El caso de uso hijo esta dado por la relación dinámica1, el concepto2 y el concepto3.
Regla 7: Otra herencia entre casos de uso
Si se tiene una triada Concepto1-Relación dinámica1-Concepto2 y se tiene una construcción de la forma Concepto2-Nota1 entonces existe una relación de herencia entre casos de uso definida así:
Regla 8: Relación <<extends>>
Cuando un concepto tiene conexiones salientes a varias relaciones dinámicas que poseen el mismo nombre, entonces existe una relación <<extends>>, formada así:
- ]]>
El caso de uso base está dado por el nombre de la relación dinámica.
Regla 9: Escenarios
Si existen tres o más triadas dinámicas unidas por implicaciones, entonces se obtiene un escenario, donde los casos de uso del escenario se determinan aplicando las reglas anteriores, con excepción de la Regla 4, que no generaría un camino de relaciones <<include>>.
4.2 Implementación de las Reglas en AToM3®
La implementación de las reglas anteriores en AToM3®, para obtener automáticamente la conversión entre los dos modelos consta de los siguientes pasos:
Figura 4. Metamodelo del Diagrama de casos de uso en AToM3.
Figure 4. Use cases diagram metamodel in AToM3.
Figura 5. Creación de la transformación “EPtoDCU”.
Figure 5. Creation of the transformation “EPtoDCU”.
Por ejemplo, para la regla createUseCase la implementación gráfica del LHS y el RHS se puede observar en la Tabla 1; el elemento Condition es el siguiente fragmento de código Python:
dName = self.getMatched(graphID, self.LHS.nodeWithLabel(1)).Valor.toString()
cName = self.getMatched(graphID, self.LHS.nodeWithLabel(2)).Nombre.toString() ]]> name = dName + “” + cName
return not self.graphRewritingSystem.existsUseCase(name)
que establece la concatenación de los elementos para conformar el nombre del caso de uso y retornar finalmente ese valor en la imagen del caso de uso. Ahora, el elemento Action es el siguiente fragmento de código Python:
useCase = self.getMatched(graphID, self.RHS.nodeWithLabel(4))
Name = useCase.Name.toString()
Self.graphRewritingSystem.addUseCase(name, useCase)
que finaliza con la creación del caso de uso; éste incluye el nombre y la imagen gráfica del caso de uso. Con las demás reglas, se procede de forma similar, para obtener los elementos restantes del diagrama de casos de uso. Finalmente, se aplican las reglas de borrado de los elementos del esquema preconceptual, con el fin de que queden únicamente en pantalla los elementos correspondientes al diagrama de casos de uso.
Tabla 1. Elementos de la regla createUseCase.
Table 1. Elements of the rule createUseCase.
4.3 Caso de Estudio
A continuación, se presenta un caso de estudio correspondiente al manejo de una biblioteca. El discurso del interesado, expresado en UN-Lencep, es el siguiente:
socio_de_la_biblioteca reserva revista
socio_de_la_biblioteca renueva prestamo
socio_de_la_biblioteca reserva libro ]]> socio_investigador es socio_de_la_biblioteca
cuando socio_de_la_biblioteca presta libro, entonces bibliotecario valida socio
bibliotecario actualiza catalogo
socio_investigador recomienda libro
El esquema preconceptual correspondiente a este discurso se muestra en la Figura 6. En la Tabla 2 se muestra paso a paso la aplicación de las reglas de transformación para el caso de estudio; en dicha Tabla se presenta la porción del esquema preconceptual, las reglas aplicadas y la porción resultante del diagrama de casos de uso.
Figura 6. Esquema preconceptual del caso de estudio.
Figure 6. Pre-conceptual Schema of the case study.
Tabla 2. Aplicación de las reglas para el caso de estudio.
Table 2. Rules application to the case study ]]>
Finalmente, en la Figura 7 se puede observar el diagrama de casos de uso obtenido al ejecutar la transformación.
Figura 7. Diagrama de Casos de uso destino.
Figure 7. Target Use Case Diagram.
5. CONCLUSIONES
En el ámbito de la elicitación de requisitos, vienen cobrando fuerza los intentos por automatizar la elaboración de los diferentes esquemas conceptuales. En este artículo se abordó la problemática del trazado automático del diagrama de casos de uso y se identificaron tres problemas aún no completamente resueltos: se suele partir de representaciones de la solución y no de representaciones del problema, se requiere aún una alta participación del analista en el proceso y no se identifican todos los elementos del diagrama de casos de uso.
En este artículo se propuso un método que parte de la representación del discurso del interesado en esquemas preconceptuales y luego los traduce de manera automática a diagramas de casos de uso. Los tres problemas anotados se solucionan con este método, dado que se admite que el discurso del interesado no se relacione con la aplicación de software (sino que más bien se refiera a los términos del dominio), el proceso es completamente automático y se identifican completamente las relaciones que existen entre actores y casos de uso. Para la solución mediante esquemas preconceptuales se debió complementar la sintaxis básica de dichos esquemas con dos elementos nuevos (la nota y la conexión de la nota con el concepto al que pertenece), con el fin de poder identificar una forma de herencia entre casos de uso.
La implementación en AToM3® presentó las mismas dificultades que se han planteado en otros artículos del grupo: la Gramática de Grafos fue insuficiente para especificar de manera completa las reglas de transformación y se debió recurrir nuevamente al lenguaje Python para complementarlas. Pese a esto, la implementación mostró ser adecuada para las necesidades de transformación y se pudieron hacer los ensayos correspondientes a las diferentes reglas.
]]> De esta manera, se pudo comprobar que efectivamente el diagrama de casos de uso se puede obtener de manera automática (sin intervenciones por parte del analista en el proceso de transformación) a partir de un esquema preconceptual que represente el dominio de un problema particular y no así su solución. Las reglas permiten hallar todos los elementos de dichos diagramas, incluyendo las relaciones especiales <<include>>, <<extends>> e <<inheritance>>, para las cuales existían pocas soluciones en el estado del arte
6. TRABAJO FUTURO
Para este trabajo en particular, se generaron nuevas preguntas a partir de la propuesta realizada y su implementación, que pueden motivar la continuación de los esfuerzos de esta línea:
7. AGRADECIMIENTOS
Este artículo se realizó en el marco de los siguientes proyectos de investigación: “construcción automatica de esquemas conceptuales a partir de lenguaje natural”, financiado por la dime y “definición de un esquema preconceptual para la obtención automática de esquemas conceptuales de uml”, financiado por dinain y administrado por la DIME.
REFERENCIAS
[1] ATOM3 ®. MSDL – ATOM3 ®. Página Web de la herramienta ATOM3 ®. Available: http://atom3.cs.mcgill.ca/. [Citado Febrero 22 de 2007] [ Links ]
[2] BEN ACHOUR, C (1998). Guiding the construction of textual case use specifications. Data & Knowledge Engineering Journal, vol 25 No. 1-2. p. 125–160. [ Links ]
[3] BEN ACHOUR, C. (1999). Extraction des bensoins par analyse of scenarios textuels. Tesis de Doctorado de la Universidad de Paris. [ Links ]
[4] COCKBURN, A. (2000). Writing Effective Use Cases. Addison-Wesley Pub Co. [ Links ]
[5] DE LARA, J., y VANGHELUWE, H. (2002). AToM3: A tool for Multi-Formalism and Meta-Modelling. Proceedings of the Fifth International Conference on Fundamental Approaches to Software Engineering. 174–188. [ Links ]
[6] DE LARA, J., VANGHELUWE, H y ALFONSECA, M. (2003). Using Meta-Modelling and Graph-Grammars to Create Modelling Environments. Electronic Notes in Theoretical Computer Science, Vol. 72, No. 3. [ Links ]
[7] DE LARA, J., GUERRA, E. y VANGHELUWE, H. (2003). Meta-Modelling, Graph Transformation and Model Checking for the Analysis of Hybrid Systems. Juan de Lara, Esther Guerra and Hans Vangheluwe. AGTIVE'2003 (Applications of Graph Transformation with Industrial Relevance), Charlottesville, USA . Lecture Notes in Computer Science 3062. Springer. [ Links ]
[8] DIETZ, J. (1999). ‘Understanding and Modelling Business Processes with DEMO’. Proc: 18th International Conference on Conceptual Modeling. Paris. [ Links ]
[9] DOME Users’ Guide, available from http://www.htc.honeywell.com/dome/support.htm#documentation. [Citado Febrero 22 de 2007a] [ Links ]
[10] DOME. What is Dome. Available: http://www.htc.honeywell.com/dome/description.htm. [Citado Febrero 22 de 2007b]. [ Links ]
[11] FIRESMITH, D. (2002). Use case: the pros and cons. Knowledge Systems Corporation. [ Links ]
[12] FOWLER, M. (2004). UML Distilled: A brief guide to the Standard Object Modeling Language. Addison-Wesley, Reading. [ Links ]
[13] JACOBSON, I. (1999). “UML y patrones. Introducción al análisis y diseño orientado a objetos”. Pretince Hall. [ Links ]
[14] JACOBSON, I., BOOCH, G. y RUMBAUGH, J. (2001). El Proceso Unificado de Desarrollo de Software. Addison Wesley. [ Links ]
[15] LIU, D. (2003). Automating Transition From Use Cases to Class Model. Msc Thesis, University of Calgary. Capítulo 7. [ Links ]
[16] LIU, D. SUBRAMANIAM, K. EBERLEIN, A. y FAR, B. (2004). Natural Language Requirements Analysis and Class Model Generation Using UCDA. IEA/AIE, LNAI 3029. p. 295–304. [ Links ]
[17] MUÑOZ J. (2004). Una Gramática de Grafos para la Transformación de Relaciones de Asociaciación desde Modelos de Análisis hacia Modelos de Diseño. Technical report, DSIC-UPV. [ Links ]
[18] OBJECT MANAGEMENT GROUP, Inc. (OMG). (2002) Unified Modeling Language: Superstructure 2.0. Draft Adopted Specification. p. 511 - 528. [ Links ]
[19] PASTOR O, DIAZ I, MORENO L. (2003). Traducción de casos de uso en patrones de interacción de instancias: una aproximación lingüística. Jornadas Iberoamericanas de Ingeniería de Software e Ingeniería del Conocimiento. [ Links ]
[20] PASTOR O, DIAZ I, LOSAVIO F, MATTEO A. (2004). Specification pattern of use. Information and _Management. Vol 41. p. 961–975. [ Links ]
[21] SHISHKOV, B., XIE, Z., LUI, K., y DIETZ, J. (2002). Using norm analysis to derive use case from business processes. 5th Workshop on Organizations semiotics. June 14-15. Delft the Netherlands . [ Links ]
[22] SMOLANDER, K., LYYTINEN, K. TAHVANAINEN, V. and MARTIIN, P. (1991). Metaedit—A flexible graphical environment for methodology modeling. In Proceedings of Advanced Information Systems Engineering CAiSE'91, Lecture Notes in Computer Science, pages 168-193. [ Links ]
[23] VENDLER, Z. (1967). Verbs and Times. Linguistics in philosophy, Ithaca, Cornell University Press. [ Links ]
[24] ZAPATA, C, y ALVAREZ, C. (2005). Conversión de Diagramas de Procesos en Diagramas de Casos de Uso Usando AToM3. Revista Dyna. Nro 146. 103–113. [ Links ]
[25] ZAPATA, C. y ARANGO, F. (2005). Los modelos verbales en lenguaje natural y su utilización en la elaboración de esquemas conceptuales para el desarrollo de software: Una revisión crítica. Revista EAFIT. Vol 41. No 137. 77–95. [ Links ]
[26] ZAPATA, C., GELBUKH, A. y ARANGO, F. (2006a). Pre-conceptual Schema: a UML Isomorphism for Automatically Obtaining UML Conceptual Schemas. Research in Computing Science: Advances in Computer Science and Engineering, Vol. 19, 3–13. [ Links ]
[27] ZAPATA, C., GELBUKH, A. y ARANGO, F. (2006b). UN–Lencep: Obtención Automática de Diagramas UML a partir de un Lenguaje Controlado. 3er Taller de Tecnologías del Lenguaje Humano. Encuentro Nacional de Ciencias de la Computación, San Luis Potosí, Septiembre. [ Links ]
[28] ZAPATA, C., GELBUKH, A. y ARANGO, F. (2006c). Pre-conceptual Schema: A Conceptual-Graph-Like Knowledge Representation for Requirements Elicitation. Lecture Notes in Computer Science, Vol. 4293, 2006, 17–27. [ Links ] ]]>