Technical University of Valencia · iv Agradecimientos Quiero agradecer a cada uno de los miembros...

Tratamiento de Relaciones Taxonómicas enEntornos de Producción Automática de Software

Una Aproximación Basada en Patrones

Vicente Pelechano Ferragud

Departamento de Sistemas Informáticos y ComputaciónUniversidad Politécnica de Valencia

Memoria para optar al Grado de Doctor en Informática

Dirigida por el Dr. Óscar Pastor López

iii

A Mariví, la meua xica

iv

Agradecimientos

Quiero agradecer a cada uno de los miembros de nuestro grupo de investigaciónla contribución que a este trabajo han supuesto las reuniones y trabajos conjuntos delos últimos años. En particular, mi agradecimiento para:Óscar Pastor, director de esta Tesis, que ha sufrido las continuas revisiones del

trabajo y ha contribuido a la consolidación de las ideas desarrolladas.Emilio Insfrán, compañero y amigo, por lo que han signi…cado todos los momentos

pasados en estos últimos años.Eva-Manoli (inseparables), por la simpatía y el apoyo incondicional que me han

proporcionado durante el desarrollo del trabajo.Isidro Ramos, por introducirme en esta área de trabajo tan interesante.Patricio, por aconsejarme tan bien durante algunos momentos de la tesis.

Índice General

1 Introducción 11.1 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Entorno de Desarrollo de la Tesis . . . . . . . . . . . . . . . . . . . . . 51.3 Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3.1 Desarrollo de Sistemas Software y Patrones de Diseño . . . . . 61.3.2 Problemas Detectados . . . . . . . . . . . . . . . . . . . . . . . 71.3.3 Solución Propuesta . . . . . . . . . . . . . . . . . . . . . . . . . 81.3.4 Aplicación a las Relaciones Taxonómicas . . . . . . . . . . . . . 8

1.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.5 Estructura de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Contexto Tecnológico 152.1 Modelado Conceptual OO y Patrones Conceptuales . . . . . . . . . . . 15

2.1.1 Patrones Conceptuales . . . . . . . . . . . . . . . . . . . . . . . 182.1.2 Relaciones Taxonómicas como Patrones Conceptuales . . . . . 21

2.2 Integración de Técnicas Formales y Semi-Formales . . . . . . . . . . . 242.2.1 Lenguajes de Especi…cación Formal . . . . . . . . . . . . . . . . 242.2.2 Integración de Técnicas . . . . . . . . . . . . . . . . . . . . . . 26

2.3 Generación de Código Basada en Modelos . . . . . . . . . . . . . . . . 272.3.1 Enfoques Actuales . . . . . . . . . . . . . . . . . . . . . . . . . 282.3.2 OO-Method y el Enfoque de Traducción . . . . . . . . . . . . . 31

2.4 Patrones Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322.4.1 Origen de los Patrones . . . . . . . . . . . . . . . . . . . . . . . 322.4.2 Tipos de Patrones Software . . . . . . . . . . . . . . . . . . . . 332.4.3 Lenguajes de Patrones . . . . . . . . . . . . . . . . . . . . . . . 36

2.5 Descripción del Trabajo de Tesis . . . . . . . . . . . . . . . . . . . . . 372.5.1 OO-Method: Del Espacio del Problema al Espacio de la Solución 372.5.2 Patrones en el Modelado Conceptual . . . . . . . . . . . . . . . 402.5.3 Patrones en el Modelo de Ejecución . . . . . . . . . . . . . . . 432.5.4 Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

2.6 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3 Trabajos Relacionados 513.1 Relaciones Taxonómicas en el Espacio del Problema . . . . . . . . . . 51

3.1.1 Aspectos Metodológicos . . . . . . . . . . . . . . . . . . . . . . 523.1.2 Modelado Conceptual OO . . . . . . . . . . . . . . . . . . . . . 61

v

vi ÍNDICE GENERAL

3.2 Relaciones Taxonómicas en el Espacio de la Solución . . . . . . . . . . 723.2.1 Programación Conceptual y Extensiones de los Lenguajes de

Programación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.2.2 Patrones de Diseño . . . . . . . . . . . . . . . . . . . . . . . . . 74

3.3 Métodos de Producción Automática de Software . . . . . . . . . . . . 763.3.1 Generación de Código Basada en Modelos . . . . . . . . . . . . 763.3.2 Generación de Código Basada en Patrones de Diseño . . . . . . 78

3.4 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4 Un Marco para el Modelado de Relaciones Taxonómicas 834.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 834.2 Dimensiones del Marco . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.2.1 Interpretación Semántica . . . . . . . . . . . . . . . . . . . . . 864.2.2 Relaciones entre Propiedades . . . . . . . . . . . . . . . . . . . 884.2.3 Restricciones Estáticas . . . . . . . . . . . . . . . . . . . . . . . 914.2.4 Características Temporales y Restricciones Dinámicas . . . . . 924.2.5 Dependencia Existencial . . . . . . . . . . . . . . . . . . . . . . 954.2.6 Multiplicidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 964.2.7 Identidad y Mecanismos de Identi…cación . . . . . . . . . . . . 974.2.8 Criterios de Especialización . . . . . . . . . . . . . . . . . . . . 99

4.3 Dependencias y Cuestiones Metodológicas . . . . . . . . . . . . . . . . 1024.4 Aplicaciones del Marco . . . . . . . . . . . . . . . . . . . . . . . . . . . 1054.5 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5 Un Modelo y una Notación para Relaciones Taxonómicas 1075.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108

5.1.1 Relaciones Taxonómicas en OASIS . . . . . . . . . . . . . . . 1085.1.2 Aspectos Notacionales. OO-Method y UML . . . . . . . . . . . 112

5.2 Particiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.2.1 Propiedades de las Subclases . . . . . . . . . . . . . . . . . . . 1145.2.2 Representación en el Diagrama de Clases . . . . . . . . . . . . 119

5.3 Particiones Estáticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1215.3.1 Propiedades de las Subclases . . . . . . . . . . . . . . . . . . . 1225.3.2 Especi…cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1235.3.3 Representación en el Diagrama de Clases . . . . . . . . . . . . 124

5.4 Particiones Dinámicas . . . . . . . . . . . . . . . . . . . . . . . . . . . 1255.4.1 Propiedades de las Subclases . . . . . . . . . . . . . . . . . . . 1285.4.2 Especi…cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1295.4.3 Representación en el Diagrama de Clases . . . . . . . . . . . . 132

5.5 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1355.5.1 Propiedades de las Subclases . . . . . . . . . . . . . . . . . . . 1375.5.2 Especi…cación . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1415.5.3 Representación en el Diagrama de Clases . . . . . . . . . . . . 142

5.6 Distinción entre Particiones Dinámicas y Roles . . . . . . . . . . . . . 1435.7 Clasi…cación Múltiple y Especialización Múltiple . . . . . . . . . . . . 1445.8 El Modelo Dinámico y la Especialización del Ciclo de Vida . . . . . . 146

5.8.1 Diagramas de Transición de Estados . . . . . . . . . . . . . . . 148

ÍNDICE GENERAL vii

5.8.2 Condiciones de Especialización y Compatibilidad de Compor-tamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

5.8.3 La Especialización como un Mor…smo entre Grafos . . . . . . . 1505.8.4 Condiciones de Especialización para los DTE . . . . . . . . . . 1515.8.5 Especialización del Ciclo de Vida en Subclases Estáticas . . . . 1545.8.6 Especialización del Ciclo de Vida en Subclases Dinámicas . . . 1555.8.7 Especialización del Ciclo de Vida en Roles . . . . . . . . . . . . 1595.8.8 Especialización del Ciclo de Vida y Clasi…cación Múltiple . . . 161

5.9 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

6 Un Lenguaje de Patrones 1676.1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676.2 Aplicación del Marco al Modelo Taxonómico . . . . . . . . . . . . . . 168

6.2.1 Especialización Estática . . . . . . . . . . . . . . . . . . . . . . 1696.2.2 Especialización Dinámica . . . . . . . . . . . . . . . . . . . . . 1696.2.3 Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

6.3 Un Lenguaje de Patrones para el Modelado de Relaciones Taxonómicas 1706.3.1 Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1716.3.2 Estructura del Lenguaje de Patrones . . . . . . . . . . . . . . . 1716.3.3 Desarrollo del Lenguaje. Descripción de los Patrones . . . . . . 172

6.4 Aplicación del Lenguaje a la Etapa de Modelado . . . . . . . . . . . . 1826.4.1 Método de Aplicación . . . . . . . . . . . . . . . . . . . . . . . 182

6.5 De…nición de una Estructura Navegacional Basada en Preguntas . . . 1846.5.1 Presentación de las Preguntas . . . . . . . . . . . . . . . . . . . 184

6.6 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194

7 Generación de Código basada en Patrones 1977.1 Patrones de Diseño y Técnicas de Implementación . . . . . . . . . . . 198

7.1.1 Herencia de los Lenguajes de Programación OO . . . . . . . . . 1987.1.2 Clase Única . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1987.1.3 Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1987.1.4 Clase Separada . . . . . . . . . . . . . . . . . . . . . . . . . . . 1997.1.5 Combinación de Clases utilizando Herencia Múltiple . . . . . . 2007.1.6 Reemplazo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2007.1.7 Delegación a una Clase Oculta . . . . . . . . . . . . . . . . . . 2017.1.8 El Patrón State . . . . . . . . . . . . . . . . . . . . . . . . . . . 2027.1.9 El Patrón Role Object . . . . . . . . . . . . . . . . . . . . . . . 2037.1.10 La Técnica de Object Slicing . . . . . . . . . . . . . . . . . . . 205

7.2 Selección y Especialización de Patrones de Diseño . . . . . . . . . . . . 2057.2.1 Selección de Patrones . . . . . . . . . . . . . . . . . . . . . . . 2067.2.2 Especialización de Patrones . . . . . . . . . . . . . . . . . . . . 208

7.3 Implementación del Comportamiento . . . . . . . . . . . . . . . . . . . 2097.3.1 La Estrategia de Ejecución y el Patrón de Diseño Template

Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2107.4 Las Relaciones Taxonómicas en el Nivel de Aplicación . . . . . . . . . 2187.5 Especialización Estática y Dinámica en el Espacio de la Solución . . . 219

7.5.1 De…nición de la Estructura de Clases . . . . . . . . . . . . . . . 219

viii ÍNDICE GENERAL

7.5.2 Implementación de la Estrategia de Ejecución . . . . . . . . . . 2277.5.3 Creación y Destrucción de Instancias en Particiones Dinámicas.

El Proceso de Migración . . . . . . . . . . . . . . . . . . . . . . 2367.5.4 Creación de Instancias en Particiones Estáticas . . . . . . . . . 2457.5.5 Destrucción de Instancias en Particiones Estáticas . . . . . . . 247

7.6 Roles en el Espacio de la Solución . . . . . . . . . . . . . . . . . . . . 2487.6.1 De…nición de la Estructura de Clases . . . . . . . . . . . . . . . 2487.6.2 Implementación de la Estrategia de Ejecución . . . . . . . . . . 2557.6.3 Creación de Roles . . . . . . . . . . . . . . . . . . . . . . . . . 2607.6.4 Destrucción de Roles . . . . . . . . . . . . . . . . . . . . . . . . 261

7.7 El Nivel de Persistencia . . . . . . . . . . . . . . . . . . . . . . . . . . 2627.7.1 Correspondencia entre Clases y Tablas Relacionales . . . . . . 2637.7.2 Correspondencia entre Particiones y Tablas Relacionales . . . . 2667.7.3 Correspondencia entre Grupos de Rol y Tablas Relacionales . . 2667.7.4 Ejemplo de Aplicación . . . . . . . . . . . . . . . . . . . . . . . 2677.7.5 El Estado del Objeto en el DTE y su Representación en Tablas 2687.7.6 Clases de Acceso a Datos . . . . . . . . . . . . . . . . . . . . . 269

7.8 El Nivel de Presentación . . . . . . . . . . . . . . . . . . . . . . . . . . 2707.8.1 Interfaz de Usuario de la Aplicación . . . . . . . . . . . . . . . 2707.8.2 Las Relaciones Taxonómicas y el Menú de la Aplicación . . . . 2717.8.3 Introducción de Datos en la Creación de Objetos . . . . . . . . 2737.8.4 Observaciones y Navegabilidad . . . . . . . . . . . . . . . . . . 277

7.9 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278

8 Conclusiones 2818.1 Contribuciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2818.2 Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2838.3 Publicaciones Relacionadas con la Tesis . . . . . . . . . . . . . . . . . 286

A Ejemplo de Aplicación 289A.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289A.2 Modelado Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . 291

A.2.1 Aplicación del Lenguaje de Patrones y la Estructura Navegacional291A.2.2 Especi…cación OASIS . . . . . . . . . . . . . . . . . . . . . . . 308

A.3 Generación de Código . . . . . . . . . . . . . . . . . . . . . . . . . . . 315A.3.1 Nivel de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . 315A.3.2 Nivel de Presentación . . . . . . . . . . . . . . . . . . . . . . . 336A.3.3 Nivel de Persistencia . . . . . . . . . . . . . . . . . . . . . . . . 341

B Un Entorno de Generación de Código 347B.1 La Herramienta de Generación . . . . . . . . . . . . . . . . . . . . . . 347

B.1.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347B.1.2 Interfaz de Usuario . . . . . . . . . . . . . . . . . . . . . . . . . 349

B.2 Prototipo Generado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352B.2.1 Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352B.2.2 Funcionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

Bibliografía 356

Capítulo 1

Introducción

El trabajo desarrollado en esta tesis se sitúa en el contexto del Modelado Conceptualy la Generación Automática de Código de Relaciones Taxonómicas. En este contexto,la Taxonomía se de…ne como la capacidad de establecer relaciones de inclusión entreclases, de manera que las clases se ordenan estableciendo que unas son más generalesque otras. Las Relaciones Taxonómicas a las que se re…ere esta tesis son las basadasen un relación de orden parcial conocidas como relaciones es-un o especialización, ygeneralización, siguiendo la de…nición propuesta en [92].La principal contribución del trabajo es la de…nición de un marco metodológico que

proporcionará guías para llevar a cabo la identi…cación, categorización y especi…caciónde relaciones taxonómicas en el modelado conceptual (Espacio del Problema), ysu implementación automática en el Espacio de la Solución.La aproximación que se presenta se basa en la aplicación de patrones software

[198] en el proceso de producción automática de software introducido por el métodoOO-Method [168]. Con este trabajo se pretende incorporar el uso de técnicas basadasen patrones a las fases del desarrollo de software para facilitar el proceso de modeladoy de generación automática de código, proporcionando guías de modelado y, estruc-turando el proceso de generación de código mediante la aplicación de estructuras dediseño de calidad.El uso de patrones ayudará en la construcción de un marco metodológico median-

te la de…nición de un lenguaje de patrones que permitirá identi…car los distintostipos de relaciones taxonómicas presentes en el esquema conceptual, según las carac-terísticas estructurales y de comportamiento que se detecten durante el proceso demodelado. El lenguaje de patrones desarrollado ayudará a especi…car las relaciones ta-xonómicas que proporciona OO-Method; dichas relaciones constituyen una extensiónde las relaciones taxonómicas presentes en OASIS (Open and Active Speci…cationof Information Systems) 2.2 [176] y 3.0 [129], que es el modelo formal de objetossubyacente a OO-Method.Para traducir los patrones conceptuales1 identi…cados en el espacio del pro-

1 Se corresponden con las estructuras conceptuales, conceptos o abstracciones que sirven pararepresentar elementos de un dominio de aplicación y sus relaciones, en el contexto del modelado con-ceptual OO. Constituyen “una solución genérica (de modelado) a un problema (especi…car un patrónestructural y de comportamiento detectado en cualquier dominio de aplicación) en un determinadocontexto”.

1

2 Capítulo 1. Introducción

blema (en este caso las distintas relaciones taxonómicas) al espacio de la solución(su implementación), se seleccionarán y especializarán una serie de patrones dediseño de forma que permitan aproximar la representación software (estructura ycomportamiento) a los patrones conceptuales. A continuación, se de…nirán una seriede correspondencias precisas entre los patrones conceptuales y los patrones de diseño,que permitirán abordar el proceso de generación automática de código. La de…niciónde estas correspondencias entre los elementos de modelado basados en un modeloformal y los patrones de diseño especializados, garantizará que la implementaciónobtenida se corresponda con el esquema conceptual del problema, constituyendo labase para la construcción de generadores que produzcan automáticamente código decalidad.En este capítulo en primer lugar se presentan los motivos que han llevado a la

realización del trabajo de tesis. En el segundo apartado se presenta el entorno detrabajo en el que se ha desarrollado la tesis. En tercer lugar se presenta el problemaque se pretende resolver y se esboza la solución que se desarrolla en los siguientescapítulos. En cuarto lugar, se presentan los objetivos de esta tesis, y por último sepresenta la estructura de la memoria, describiendo el contenido de cada uno de loscapítulos desarrollados.

1.1 Motivación

El principal objetivo de la industria del software es la obtención de productos de cali-dad con una elevada productividad. La construcción de aplicaciones ha sido siempreuna tarea compleja, pero esta complejidad, lejos de reducirse, es cada vez mayor. Estasituación se debe a que las necesidades de los usuarios son cada vez más so…sticadas,y las aplicaciones se construyen utilizando tecnologías de última generación. En mu-chos casos la complejidad tecnológica provoca que el ingeniero de software dediqueun mayor esfuerzo a conocer aspectos técnicos que a entender el problema que deberesolver el sistema software a desarrollar.Una de las tareas críticas en la Ingeniería del Software, y que tiene una mayor

repercusión sobre la productividad y la calidad …nal del software es el modelado con-ceptual. Estudios recientes relacionados con el desarrollo de software en ambientesCliente/Servidor y Orientados a Objetos refuerzan la tesis de que las tareas máscríticas siguen estando en la especi…cación y en el análisis de requisitos [65], y que loserrores introducidos en esta etapa del proceso de producción de software pueden tenerun impacto considerable en la …abilidad, el coste y la seguridad del sistema. Dichoserrores se atribuyen frecuentemente a la falta de herramientas que den un soporte in-tegral y que estén íntimamente ligadas con las siguientes etapas de dicho proceso deproducción. Por ello, se necesitan herramientas de desarrollo que proporcionen cons-trucciones de alto nivel (a las que en esta tesis se llama patrones conceptuales) quepermitan especi…car sistemas de información, usando conceptos próximos al espaciodel problema y no al espacio de la solución. La idea subyacente es elevar el nivelde abstracción de lo que se manipula como lenguaje de programación, siguiendo unproceso similar al que llevó de los lenguajes ensambladores a los lenguajes de progra-mación etiquetados como de tercera generación. En ese proceso se proporcionará aldesarrollador lenguajes cuya notación esté más próxima al espacio del problema (elqué) y menos ligada al espacio de la solución (el cómo).

1.1. Motivación 3

El interés por la producción automática de software está aumentando de for-ma progresiva. En el informe [45] se identi…can los campos de investigación en lasTecnologías de la Información que el gobierno de Estados Unidos y especialmente elgrupo de trabajo PITAC2 consideran como prioritarios. El área de mayor interés hasido el software; se ha detectado el llamado “software gap”, de…nido como una de…-ciencia entre la demanda de software de alta calidad y la capacidad para producirlo.El informe PITAC identi…ca una serie de áreas como prioritarias para la asignaciónde recursos que apoyen la investigación básica. De entre ellas destaca la de: “Métodosde desarrollo de software y tecnologías de componentes, incluyendo herramientas ytécnicas para el desarrollo automático del software y su mantenimiento”.La mayoría de herramientas CASE del mercado ofrecen algún tipo de aportación

en el área del desarrollo automático del software. La tendencia actual consiste enproporcionar herramientas de desarrollo cuyo punto de partida para la generación decódigo es el esquema conceptual. A esta aproximación se le llama Generación de Códi-go basada en Modelos (GCBM) [25]. En la GCBM se distinguen tres aproximaciones:la estructural, la de comportamiento y la de traducción. Estas aproximacionesa la GCBM están soportadas por herramientas CASE que proporcionan soluciones“parciales” al problema de la generación de código. La aproximación estructural ge-nera código a partir del modelo estructural del sistema, la de comportamiento a partirdel modelo dinámico, y la de traducción lo hace a partir de los esquemas conceptualesy de la arquitectura, mediante una serie de patrones y reglas de traducción que eldiseñador debe especi…car utilizando un lenguaje de programación propio. No existensoluciones completas que garanticen que la solución software obtenida se correspondecon el esquema conceptual del sistema a desarrollar.La falta de rigor que presentan los métodos y entornos actuales en la de…nición de

los elementos de modelado di…cultan la obtención de software que sea funcionalmenteequivalente a la descripción capturada en el esquema conceptual. Si se analizan losmétodos de desarrollo más utilizados en la industria del software, se puede observarque muchas veces el esfuerzo invertido en la realización de algunas tareas (como puedeser el modelado conceptual) y en la producción de documentación no tiene ningúnre‡ejo directo en el producto …nal. Estos problemas invitan a replantearse la forma deabordar los procesos de desarrollo orientados a la obtención automática de software.Estos procesos necesitan métodos y herramientas que:

² aborden el proceso de desarrollo con rigor y de forma sistemática, pro-porcionando los modelos y las etapas exclusivamente necesarias para la produc-ción de software

² se centren en la especi…cación precisa del Espacio del Problema² ayuden al analista a tomar decisiones en el proceso de modelado conceptual² proporcionen generación automática de código completa (estructura ycomportamiento) a partir de esquemas conceptuales

² ofrezcan independencia tecnológica, ocultando la tecnología subyacente alos desarrolladores

2Siglas de The President’s Information Technology Advisory Comittee.


² produzcan software de calidad funcionalmente equivalente a su especi…cación

OO-Method [165, 168, 173, 175] es un método de producción automática desoftware basado en el modelo formal de objetos OASIS. Este método desarrolladoen el grupo de investigación al que pertenece el autor de la tesis, da respuesta en granparte a las necesidades mencionadas anteriormente. OO-Method:

² da soporte a las nociones del modelado conceptual orientado a objetos² integra métodos formales con métodos de aceptación industrial² proporciona un entorno de producción de software avanzado que permite cons-truir aplicaciones de forma automatizada a partir de los modelos conceptuales

Los patrones de software se están incorporando a los procesos de desarrollo deaplicaciones y se aplican en las distintas fases del desarrollo del software. Inicialmentesurgieron como patrones de diseño, pero actualmente los patrones constituyen unconcepto más general, representando estructuras conceptuales aplicables durante lasfases de análisis, diseño e implementación. La aplicación de patrones a los métodosde desarrollo de software aporta bene…cios interesantes ya que, entre otras muchasaplicaciones, permiten :

² de…nir guías de modelado mediante lenguajes de patrones [57]² estructurar el proceso de generación de código mediante la utilizaciónde patrones de diseño y arquitectónicos que ayudarán a la construcción degeneradores

² ofrecer soluciones reutilizables y probadas, que sean lo su…cientementeabstractas cómo para ser utilizadas en cualquier lenguaje de programación

OO-Method propugna desde sus inicios una orientación hacia el modelado de pa-trones conceptuales expresivos, con una semántica bien de…nida basada en un modeloformal. Actualmente OO-Method (y en general la mayoría de métodos de modela-do orientado a objetos (OO)) carece de guías precisas que ayuden al analista en laetapa de modelado a detectar los patrones conceptuales (como agregación, especiali-zación/generalización, asociación) que están presentes en el esquema conceptual delsistema. Estos patrones conceptuales son de interés general en el mundo del modela-do, aunque todavía no se ha alcanzado un consenso sobre cuál es su semántica y cómodeben representarse e integrarse en los métodos de modelado y desarrollo de softwareOO.En particular las relaciones taxonómicas en el ámbito del modelado constituyen

unos patrones muy utilizados aunque bastante con‡ictivos en lo que se re…ere a susdistintas interpretaciones semánticas. Parece evidente la necesidad de proporcionarun marco conceptual genérico que identi…que las características esenciales a nivel es-tructural y de comportamiento de las relaciones taxonómicas. Este marco facilitaríala caracterización y el modelado de las relaciones taxonómicas en el entorno de espe-ci…cación en el que se trabaja. En lo que respecta a su implementación, la mayoríade patrones conceptuales no están soportados de forma precisa por los métodos de

1.2. Entorno de Desarrollo de la Tesis 5

desarrollo convencionales, por lo que no se ofrecen pautas claras para obtener su re-presentación software. Si se consigue capturar y representar estos patrones de formano ambigua, se pueden construir procesos de desarrollo automatizables que permitantraducir correctamente los patrones modelados al espacio de la solución. Además,estos patrones conceptuales deben representarse en el espacio de la solución medianteestructuras software de calidad que permitan implementar correctamente la semánticade estos patrones en distintos entornos de producción de software.En resumen, la motivación principal es la de poder proporcionar entornos de mo-

delado y generación automática de código que posean las características enunciadasanteriormente (métodos sistemáticos y rigurosos, centrados en la especi…cación, queayuden al analista, con generación automática de código completa, independientesde la tecnología, que produzcan software de calidad) en el contexto de OO-Method.La incorporación de técnicas basadas en patrones software al método puede ayudar aaportar soluciones a las necesidades expuestas. Los resultados a obtener van más alláde las características particulares de OO-Method y OASIS, ya que se pueden aplicara diversos métodos de producción, siempre que propocionen patrones conceptualesexpresivos con una semántica precisa.

1.2 Entorno de Desarrollo de la Tesis

Este trabajo de tesis se ha desarrollado en el seno del grupo de investigación “Progra-mación Lógica e Ingeniería del Software”, perteneciente al Departamento de SistemasInformáticos y Computación de la Universidad Politécnica de Valencia. Dentro delas principales actividades llevadas a cabo por este grupo durante los últimos años seencuentran el desarrollo del lenguaje de especi…cación OASIS y de OO-Method.El trabajo presentado en esta tesis forma parte de los trabajos realizados en el

contexto de OO-Method por un subgrupo de investigadores, en el cual el autor haparticipado activamente en su concepción y desarrollo a nivel cientí…co y comercial.Los resultados obtenidos en esta tesis se están aplicando en entornos reales de produc-ción, y se están incorporando a herramientas a través de proyectos de investigación.Los trabajos que han posibilitado el desarrollo de esta tesis se enmarcan en los

siguientes proyectos de investigación y desarrollo:

² ”IDEAS: Ingeniería de Ambientes Software” CYTED (Programa Iberoamerica-no de Ciencia y Tecnología para el Desarrollo, subprograma VII) (Desde 1997hasta: 1999).

² ”MENHIR: Métodos, Entornos y Herramientas para la Ingeniería de Requisi-tos” y en el subproyecto “ESPILL (Evolución del software, programación visualimperativa y lenguajes lógicos)” Proyecto CICYT con referencia: TIC 97-0593-C05-01. (Desde Junio 1997 hasta Junio 2000). Proyecto Coordinado con lasUniversidades de Sevilla, Valladolid, Granada y Murcia.

² ”Advanced Modeling and Speci…cation of Distributed Information Systems (AS-PIRE)” Proyecto ESPRIT (Directorate General III -Industry- of the Commis-sion of the European Communities) (Desde 1997 hasta 2000).


² ”Ingeniería de Requerimientos y Generación Automática de Software” DGEUI(Direcció General d’Ensenyaments Universitaris i Investigació, Conselleria deCultura, Educació i Ciència) con referencia: GV97-TI-05-34 (Desde 1998 hasta2000)

² ”Generación Automática de Sistemas Software en Ambientes Orientados a Ob-jetos “ Proyecto CICYT del programa FEDER, con referencia: TIC 1FD97-1102(Desde Octubre 1999 hasta Diciembre 2001).

² ”WEST: WEb-oriented Software Technology” Proyecto CYTED VII-18 (Pro-grama Iberoamericano de Ciencia y Tecnología para el Desarrollo). (DesdeAgosto de 2000 hasta Agosto de 2003).

1.3 Planteamiento del ProblemaEl trabajo presentado en esta tesis se sitúa en el área de trabajo de los entornos de mo-delado y producción de software OO. Con la intención de situar el trabajo y plantearclaramente los problemas que se pretende resolver junto con las soluciones propuestas,se utilizará un estudio presentado en el artículo “A Uni…ed Object Topology” [224].En este artículo se propone un mapa sobre el cual se proyectan una serie de técnicasutilizadas en el desarrollo de software OO, como son elModelado del Dominio, los Pa-trones de Diseño, los Estilos Arquitectónicos3, los Marcos de Trabajo (Frameworks)4

y las Piezas de Ensamble (Kits)5. Los procesos de producción de software actualeshacen uso de estas técnicas y de las relaciones inherentes entre ellas. Estas relacionesinducen una serie de caminos a recorrer para la construcción de sistemas software.Estas técnicas se han “medido” y distribuido en el mapa con relación a los atributosde Implementación y Dependencia del Dominio, relacionándose unas con otras.Este mapa, reproducido en la …gura 1.1, servirá para establecer de forma adecuada elproblema esencial que se pretende abordar en este trabajo, permitiendo detectar losproblemas existentes entre los caminos a recorrer para producir software, y ayudandoa situar adecuadamente las soluciones propuestas.

1.3.1 Desarrollo de Sistemas Software y Patrones de Diseño

Cuando se desarrolla un sistema software existe una gran diversidad de problemas enlos que el desarrollador debe centrarse. De forma simpli…cada debe:

² analizar el dominio de la aplicación,² de…nir una arquitectura,3 Son un conjunto de características operacionales que identi…can a una familia de arquitecturas.

Estilos como el procesado de transacciones on-line, sistemas de soporte a la toma de decisiones,sistemas de tiempo real, son independientes del dominio [29, 205].

4Un framework es un diseño reutilizable de todo o parte de un sistema que está representadopor un conjunto de clases abstractas y por la forma en que interactúan sus instancias [115]. En suforma más genérica es un conjunto integrado de componentes que colaboran para proporcionar unaarquitectura reutilizable para una familia de aplicaciones relacionadas [198].

5 Son objetos lógicamente relacionados que sirven para implementar una aplicación. Éstos poseenun alto detalle del dominio y constituyen implementaciones concretas de conceptos presentes en eldominio del problema [26].

1.3. Planteamiento del Problema 7

Independiente

Dominio

Detallado

Concreto Implementación Abstracto

Aplicación

KitsModelos

delDominio

Patronesde

Diseño

Frameworks

EstilosArquitectónicos

Taxonomíadel Dominio

Figura 1.1: Tecnologías Relacionadas en el Desarrollo OO Actual

² implementar las clases del dominio y² crear un sistema cohesivo con los elementos obtenidos.

Este proceso puede verse como el recorrido de una serie de caminos a través del ma-pa presentado en la …gura 1.1. Se puede observar que en las propuestas de desarrolloactuales los Patrones de Diseño actúan como puente entre los Patrones Conceptualesde los Modelos del Dominio (Elementos de Modelado) y su implementación (lo queen el artículo se llaman “Kits”).

1.3.2 Problemas Detectados

Si se analizan los caminos existentes, surgen una serie de problemas con las técnicasy las rutas que las unen, detectándose líneas de investigación muy interesantes queposeen un enfoque eminentemente aplicado. De la rutas introducidas, el camino queune losmodelos del dominio con su implementación a través de los patrones dediseño (ver …gura 1.1) presenta algunos problemas a los cuáles se va a dar soluciónen esta tesis.Los problemas que se detectan al analizarlo son:

² Los métodos OO existentes no describen los dominios de forma clara y sinambigüedades. La caracterización del dominio del problema para el desarrollo deaplicaciones es extremadamente compleja. Los lenguajes para describir dominiosno son su…cientemente ricos.

² No se proporcionan guías precisas para el Modelado del Dominio.


² Los patrones de diseño son demasiado generales y no son directamente aplicablesa problemas especí…cos.

² No existe una correspondencia precisa entre los modelos del dominio, los patro-nes de diseño y su implementación (”kits”).

² En la mayoría de los procesos de producción de software, la transición entrelos modelos del dominio, los patrones de diseño y los ”kits” se realiza de formamanual. La estructura y el comportamiento de los patrones conceptuales seimplementa de forma ad-hoc por lo que la calidad del producto software …naldependerá del implementador.

Esta serie de problemas di…cultan la construcción de herramientas capaces deproducir sistemas software de forma automática, ya que es imposible automatizar elrecorrido del camino entre los modelos del dominio y su implementación.

1.3.3 Solución Propuesta

Cada uno de los problemas detectados en el proceso de producción de software sepodrían solucionar de la siguiente manera:

² Usando Lenguajes Formales o Modelos basados en Lenguajes Formales para des-cribir Patrones Conceptuales de forma precisa. En el caso de esta tesis se llevaráa cabo mediante la utilización del modelo formal OASIS y la especi…cación depatrones conceptuales.

² Construyendo una guía metodológica mediante un lenguaje de patrones quepermita identi…car los patrones de modelado presentes en la especi…cación delproblema.

² Especializando Patrones de Diseño (State, Composite, Template Method [78],Role Object [22], etc...) para soportar los Patrones Conceptuales usados en elModelado del Dominio.

² De…niendo correspondencias precisas entre los Patrones Conceptuales y los Pa-trones de Diseño.

² De…niendo una estrategia de generación para implementar sistemáticamente laestructura y el comportamiento de los Patrones Conceptuales basada en lascorrespondencias anteriores.

La incorporación de estas ideas a un método de producción de software permi-tirá construir herramientas CASE capaces de generar automáticamente un productosoftware …nal a partir de los patrones conceptuales especi…cados en el Modelo delDominio del Problema.

1.3.4 Aplicación a las Relaciones Taxonómicas

El conjunto de soluciones propuestas conforma un marco metodológico en el cuállos patrones (patrones conceptuales, lenguajes de patrones, patrones arquitectónicos

1.4. Objetivos 9

y patrones de diseño) juegan un papel muy importante para resolver los problemasdetectados. La solución general aportada debería aplicarse a todos los patrones con-ceptuales que se utilicen como constructores de modelado (agregación, asociación yespecialización). Debido a la riqueza expresiva de los patrones conceptuales presentesen OO-Method y a la complejidad de abordarlos todos de forma adecuada y su…cien-temente extensa, este trabajo se centra en aplicar estas ideas sobre un subconjunto dedichos patrones conceptuales: la especialización estática, la especialización dinámicay los roles.Estos patrones conceptuales representan un conjunto de relaciones entre clases a

las que en esta tesis se llamará de forma genérica relaciones taxonómicas. El términotaxonomía, de…nido en [28] como “el estudio de los principios generales de la clasi…-cación cientí…ca o una clasi…cación ordenada de plantas y animales de acuerdo consus relaciones naturales”, se utiliza también en el modelado conceptual [32] y en lainteligencia arti…cial [34]. En el Modelado Conceptual OO [27] se utiliza el términotaxonomía en el siguiente sentido: “el modelador construye una taxonomía en la queuna clase se puede describir por una declaración explícita de su/s clase/s padre/s (re-laciones Es-Un) y sus propiedades diferenciadoras”. En esta área se han desarrolladoaproximaciones que presentan distintas interpretaciones de la relación Es-Un. Al serla relación Es-Un un concepto con tantas acepciones, en esta tesis se ha preferidoutilizar el término genérico relación taxonómica porque permite agrupar en un únicotérmino todas aquellas relaciones utilizadas para la construcción de esquemas con-ceptuales que, pese a sus diversas características, se utilizan en la construcción detaxonomías.

1.4 Objetivos

El objetivo principal de la tesis es de…nir un método de trabajo que incorpore enel proceso de producción de software técnicas basadas en patrones software, propor-cionando guías para llevar a cabo: la identi…cación y especi…cación de relacionestaxonómicas en la etapa de modelado conceptual (Espacio del Problema) y surepresentación software (en el Espacio de la Solución) de forma automática. Esteobjetivo se llevará a cabo, en el contexto de OO-Method, con la consecución de lossiguientes subobjetivos:

En lo que respecta a los trabajos situados en el Espacio del Problema:

1. Estudiar las distintas propuestas que han abordado la de…nición (formal y semi-formal) de relaciones taxonómicas para el modelado conceptual OO, con el …nde determinar las características comunes que poseen las propuestas existentes,para construir un marco general aplicable en la identi…cación y caracterizaciónde relaciones taxonómicas en la etapa de modelado.

2. De…nir de forma precisa los patrones conceptuales presentes en el modeloOASISpara el modelado de relaciones taxonómicas, incorporando este nuevo modelotaxonómico a OO-Method, y proporcionando una notación grá…ca basada enUML.

3. Desarrollar un lenguaje de patrones a partir del marco conceptual y el modelode relaciones taxonómicas introducido. Este lenguaje proporcionará un marco


de trabajo e…caz para guiar al modelador en el proceso de identi…cación y es-peci…cación de relaciones taxonómicas. Se de…nirá un proceso que determinarácómo se aplica de forma sistemática dicho lenguaje de patrones en la etapa demodelado conceptual.

En lo que respecta a los trabajos situados en el Espacio de la Solución:

4. Analizar los distintos patrones de diseño y técnicas de implementación que per-mitan trasladar las relaciones taxonómicas y los conceptos presentes en OO-Method del espacio del problema al espacio de la solución. Haciendo uso delmarco conceptual propuesto, se razonará cuáles se eligen y cómo se especializanpara poder llevar a cabo su implementación.

5. Establecer correspondencias entre los distintos tipos de relaciones taxonómicas ylos patrones de diseño especializados que las implementan, aplicando el Modelode Ejecución Extendido que se presentará en la tesis.

6. Construir una versión preliminar de un entorno de generación de código a partirde modelos conceptuales con relaciones taxonómicas, considerando el modelode ejecución y las equivalencias establecidas entre el patrón conceptual y lospatrones de diseño.

1.5 Estructura de la Tesis

La presentación de esta tesis se ha organizado en los siguientes capítulos:

² Capítulo 1. IntroducciónEl presente capítulo presenta en primer lugar la motivación que ha llevado aabordar el tema de la tesis, seguidamente se presenta el entorno académicoen el cual se ha desarrollado el trabajo, en el tercer apartado se muestra elplanteamiento del problema a resolver y un esbozo de la solución propuesta, acontinuación se presentan los objetivos perseguidos en la tesis, y por último esteapartado.

² Capítulo 2. Contexto TecnológicoEn este capítulo se presenta el contexto tecnológico en el que se sitúa el tra-bajo presentado en esta tesis, mediante la descripción de las técnicas que estándirectamente relacionadas con el trabajo. Entre otras se destaca el ModeladoConceptual y las Relaciones Taxonómicas, la integración de Métodos Formalesy Semi-Formales, la Generación de Código basada en Modelos, y por último losPatrones Software. Tomando estas técnicas como base, en la última parte delcapítulo se describe de forma general el trabajo de tesis desarrollado. El trabajoincorpora técnicas basadas en patrones en las etapas de modelado conceptualy generación de código de OO-Method, centrándose en el tratamiento completode las relaciones taxonómicas, desde su especi…cación hasta su implementación.

1.5. Estructura de la Tesis 11

² Capítulo 3. Trabajos RelacionadosEn este capítulo se analizan los trabajos más relevantes que están relacionadoscon los distintos elementos tecnológicos presentados en este trabajo. Se descri-ben sus características principales y se comparan con la propuesta defendida enesta tesis. Los trabajos que se analizan abarcan aquellos que tratan las rela-ciones taxonómicas desde las etapas iniciales de un proceso de desarrollo OO(situadas en el Espacio del Problema), hasta las etapas de diseño e implementa-ción (situadas en el Espacio de la Solución), y por último se analizan aquellaspropuestas de métodos de producción automática de software comparables enalguna medida a la que se presenta esta tesis.

² Capítulo 4. Un Marco para el Modelado de Relaciones TaxonómicasEn este capítulo se desarrolla un marco de referencia genérico que de…ne laspropiedades esenciales de las relaciones taxonómicas en el modelado conceptualOO. Este marco se construye mediante un proceso de revisión y abstracciónde distintas propuestas de modelos taxonómicos presentes en los métodos demodelado conceptual. El marco identi…ca y clasi…ca las propiedades estructu-rales y de comportamiento asociadas a los patrones conceptuales, de forma queproporciona un conjunto de dimensiones mediante las cuales categorizar adecua-damente los distintos modelos taxonómicos. Este marco multidimensional es degran utilidad y se aplica para ayudar a comprender las características esencia-les y la semántica de los distintos modelos taxonómicos (independientementede los términos utilizados para nombrarlas), para comparar la expresividad dedistintas aproximaciones, e identi…car carencias expresivas y ambigüedades enmodelos existentes. Proporciona guías para la de…nición de nuevos modelostaxonómicos, y permite identi…car patrones estructurales y de comportamientoen el espacio del problema (ayudando en el proceso de modelado conceptual)y en el espacio de la solución (ayudando a de…nir esquemas de generación decódigo). Este capítulo, junto con el estudio realizado en el capítulo anterior,permite alcanzar el primer objetivo de la tesis.

² Capítulo 5. Un Modelo y una Notación para Relaciones TaxonómicasEn este capítulo se de…nen de forma precisa los patrones conceptuales (parti-ciones estáticas, particiones dinámicas y roles) presentes en el modelo formalde OASIS para el modelado de relaciones taxonómicas. Para cada uno delos patrones se detallan sus propiedades estructurales y de comportamiento,su especi…cación en OASIS y se proporciona una notación grá…ca basada enel estándar notacional UML. Esta notación extiende el Diagrama de Clases yel Diagrama de Transición de Estados (DTE), para dar un soporte adecuadoal modelado de la estructura y el comportamiento de las relaciones taxonómi-cas. En la última parte del capítulo se presenta, a nivel metodológico, cómoespecializar el comportamiento de la clase padre. Esta propuesta se desarrollaanalizando cómo se especializa el ciclo de vida (modelado en este caso a travésdel DTE) de forma que los DTE de las subclases se especialicen de forma correc-ta manteniendo un conjunto de propiedades requeridas por cada tipo de relacióntaxonómica. Este capítulo desarrolla completamente el segundo objetivo de latesis.


² Capítulo 6. Un Lenguaje de PatronesEn este capítulo se construye un lenguaje de patrones basado en el marco mul-tidimensional propuesto y en las características de los patrones conceptualesintroducidos en el modelo taxonómico presentado para OASIS. El lenguaje seutiliza como guía para dirigir el proceso de modelado, ayudando a identi…carlos distintos tipos de relaciones taxonómicas existentes y sus características es-tructurales y de comportamiento. El lenguaje de patrones se construye identi…-cando las características de las relaciones taxonómicas presentadas en el modeloOASIS y situándolas en el marco multidimensional de referencia. Cada una delas dimensiones del marco constituirá un patrón del lenguaje de patrones. Cadapatrón describe una propiedad (estructural o de comportamiento) que puedeposeer una relación taxonómica. Utilizando el lenguaje de patrones, el procesode modelado se verá como la aplicación “guiada” de cada uno de los patronesdel lenguaje para dar valor a cada una de las dimensiones del marco. Depen-diendo del valor de las dimensiones detectadas, se modelará un tipo u otro derelación taxonómica. A partir del lenguaje de patrones y de las relaciones entrelos patrones que lo constituyen se construye un algoritmo de aplicación de lospatrones del lenguaje para facilitar su aplicación en la etapa de modelado. Ellenguaje de patrones y el algoritmo inducen una estructura de navegación basa-da en preguntas independientes del dominio que permite guiar al analista en laetapa de modelado. De esta forma se ofrece un soporte metodológico completoal proceso de modelado, obteniendo la información necesaria para especi…caradecuadamente las relaciones taxonómicas en OO-Method. El lenguaje de pa-trones desarrollado y la estructura navegacional asociada permiten cumplir conel tercer objetivo de la tesis.

² Capítulo 7. Generación de Código basada en PatronesEn este capítulo se presenta un proceso completo de generación de código ba-sado en patrones de diseño para las relaciones taxonómicas especi…cadas en laetapa de modelado conceptual de OO-Method. Se realiza un análisis exhaustivode los distintos patrones de diseño y técnicas de implementación que permitenimplementar las relaciones taxonómicas presentes en los métodos de modeladoconvencionales. A partir del estudio realizado y haciendo uso del marco mul-tidimensional propuesto en el capítulo 4, se identi…ca cómo estas técnicas soncapaces de soportar las características estructurales y de comportamiento de lasrelaciones taxonómicas presentadas en el capítulo 5. A continuación, se seleccio-nan aquellos patrones que dan un mejor soporte a las relaciones taxonómicas.Se razona qué patrones se eligen y qué nuevas capacidades expresivas se de-ben incorporar a dichos patrones (a través de un proceso de especialización)para poder acercar las estructuras de diseño a las estructuras conceptuales, yde esta forma proponer un proceso de generación automática de código. Unade las características que los patrones de diseño no soportan directamente esla implementación del comportamiento basado en la estrategia de ejecución deOO-Method. Por ello, una vez seleccionados los patrones de diseño, se presentancada una de las técnicas de implementación que se utilizarán para especializardichos patrones y dar un soporte directo a la implementación de la estrategiade ejecución. Una vez determinadas las técnicas de implementación adecuadas,

1.5. Estructura de la Tesis 13

se establecen de forma precisa las correspondencias entre los distintos tipos derelaciones taxonómicas presentes en OO-Method y los patrones de diseño espe-cializados que permiten implementarlas. La generación de código se lleva a caboen arquitecturas de tres niveles y se utiliza el lenguaje Java para presentar ejem-plos de código generado. La propuesta presentada aborda de forma detalladala generación de los componentes software del nivel de aplicación, que es dondese implementa la lógica de los objetos de negocio, y la generación del nivel depresentación y de persistencia. Este capítulo desarrolla los objetivos cuarto yquinto propuestos en el trabajo de tesis.

² Capítulo 8. ConclusionesEn este capítulo se presentarán las conclusiones del trabajo, las principalescontribuciones de la tesis y las líneas de trabajo futuras de cara a consolidar yampliar el trabajo desarrollado, así como las publicaciones relacionadas con eltrabajo.

Para completar el trabajo se presentan dos apéndices:

² Apéndice A: Ejemplo de Modelado y Generación de Código.En este apéndice se desarrolla un ejemplo completo en el que se aplican de formasistemática cada una de las propuestas presentadas en esta tesis. El ejemplo seaborda desde la etapa de modelado hasta la generación de código Java a travésde los siguientes pasos: (1) aplicando como guía de modelado la estructura depreguntas y el lenguaje de patrones presentado en el capítulo 6, (2) construyendoel esquema conceptual OO-Method siguiendo la notación UML propuesta en elcapítulo 6, (3) obteniendo la especi…cación OASIS del esquema obtenido, (4)aplicando la estrategia de generación de código presentada en el capítulo 7 a laespeci…cación, y obteniendo los componentes software de cada uno de los nivelesde la arquitectura de la aplicación.

² Apéndice B: Prototipo de Entorno de Generación de Código.En este apéndice se presenta un prototipo de entorno de generación de códi-go para esquemas conceptuales que posean los tipos de relaciones taxonómicasintroducidos en esta tesis. Se muestra cómo se ha llevado a cabo su implemen-tación y cuál es la arquitectura del generador, junto con las técnicas utilizadaspara su implementación. De esta forma se plasma cómo se ha llevado a cabo elsexto objetivo de la tesis.

Capítulo 2

Contexto Tecnológico

En este capítulo se introduce el contexto tecnológico en el que se sitúa el trabajo des-arrollado en esta tesis. El contexto tecnológico comprende aquella tecnología softwareasociada al problema que se resuelve. Este capítulo analiza cada una de las áreas deinvestigación con las que está relacionado el trabajo de tesis, estudiando algunos delos problemas existentes en cada área. La combinación adecuada de técnicas presentesen cada una de las áreas permitirá desarrollar la propuesta que se presenta.La estructura del capítulo es la siguiente: en primer lugar, se presenta una intro-

ducción al Modelado Conceptual Orientado a Objetos (OO), los Patrones Concep-tuales y las Relaciones Taxonómicas, que constituyen un caso particular de patronesconceptuales en los que se centra el estudio. En el segundo apartado se presentanaproximaciones que integran Técnicas Formales (como los lenguajes de especi…caciónformal) y Semi-Formales1 (como las técnicas de modelado conceptual convencionales).En el tercer apartado se presenta una visión general de las aproximaciones existentesen el área de la Generación de Código basada en Modelos. En el cuarto apartadose analizan los tipos de Patrones Software existentes, indicando en qué ámbito sonaplicables. En la última parte del capítulo se describe de forma general el trabajode tesis desarrollado y sus aportaciones. La aproximación que se presenta integratécnicas formales (utilizando el lenguaje OASIS como herramienta para la de…niciónprecisa de las relaciones taxonómicas) y semi-formales (notación grá…ca basada enUML), e incorpora técnicas basadas en patrones software en las etapas de modela-do conceptual y generación de código, proporcionando un tratamiento completo delas relaciones taxonómicas (desde su especi…cación hasta su implementación) en elcontexto de OO-Method.

2.1 Modelado Conceptual OO y Patrones Concep-tuales

El proceso de modelado conceptual se inicia normalmente cuando empieza el desarro-llo de un sistema de información y puede considerarse como el proceso de análisis

1 Según [236], por técnicas semi-formales se re…ere a técnicas diagramáticas o tabulares que pre-sentan la información de manera estructurada.

15

16 Capítulo 2. Contexto Tecnológico

de la estructura semántica del Universo de Discurso (UoD) que el sistema debe so-portar. El esquema conceptual de un sistema debe especi…car todas sus propiedades(estáticas y dinámicas) y no debe contener más detalles de implementación que losencontrados en los requisitos [84]. En la actualidad, aunque existen lenguajes de mo-delado bien de…nidos y ampliamente usados en el mundo del desarrollo de sistemas deinformación, surgen continuamente nuevas propuestas que pretenden enriquecer loslenguajes, incorporando nuevas construcciones que sean capaces de captar otros as-pectos del UoD. La aproximación al modelado que se presenta en este trabajo intentaproporcionar construcciones conceptuales expresivas en el ámbito de la orientación aobjetos.Tradicionalmente los sistemas se describen en dos dimensiones: datos y proceso. El

modelo orientado a objetos trata estas dimensiones uniformemente bajo el conceptode objeto, con el que datos y procesos aparecen unidos de forma indisoluble.El marco conceptual de la orientación a objetos facilita el modelado conceptual al

permitir interpretar la realidad tal y como se percibe, de una manera próxima a losmecanismos cognitivos humanos a través de la noción de objeto. Ello permite reducirla complejidad del sistema a especi…car, mejorar la comunicación con los usuarios enla fase de modelado conceptual, representar de forma natural las relaciones existentesentre los elementos constitutivos del sistema (al ser visto el sistema como una sociedadde objetos interactivos), y además, modelar con el mismo énfasis los datos y losprocesos; especi…cando objetos como unidades de ejecución autocontenidas.Los principales conceptos usados en el modelado conceptual orientado a objetos

son los objetos y las clases. Con la intención de ofrecer una perspectiva más ampliade estos conceptos se presentan algunas de…niciones de los mismos. Según Coad yYourdon [50] un objeto es una abstracción de algo en el dominio de un problema quere‡eja las capacidades del sistema para mantener información acerca de él y/o inte-ractuar con él; es una encapsulación de valores de atributos y sus servicios exclusivos(también se le llama instancia). Una clase es una colección de uno o más objetos conun conjunto uniforme de atributos y servicios, incluyendo una descripción de cómocrear nuevos objetos. Según Booch [31] un objeto tiene estado (abarca los valoresactuales de cada uno de sus atributos, representando los resultados acumulados de sucomportamiento), comportamiento (es cómo actúa y reacciona un objeto, en términosde sus cambios de estado y paso de mensajes) e identidad (es aquella propiedad de unobjeto que lo distingue de todos los demás objetos.); la estructura y comportamientode objetos similares están de…nidos en su clase común (los términos instancia y objetoson intercambiables). Una clase es un conjunto de objetos que comparten una estruc-tura y comportamiento común. Por último, el estándar ISO/IEC DIS 10746-2 [109]proporciona un modelo de referencia para ODP2 y constituye una de las referenciasmás actuales en la de…nición de terminología OO. Este estándar aglutina las ideassubyacentes en las de…niciones previas y de…ne un objeto como un modelo de unaentidad que se caracteriza dualmente por su comportamiento y su estado. Un objetoes distinto de cualquier otro objeto. Un objeto está encapsulado por lo que cualquiercambio de estado sólo puede ocurrir a través de una acción interna o como resultadode una interacción con su entorno. Una clase es el conjunto de todos los objetos quesatisfacen un tipo. Un tipo es un predicado que caracteriza a una colección de objeto.El resultado del proceso de modelado conceptual se documenta normalmente me-

2Proceso Distribuido Abierto, del inglés ”Open Distributed Processing”.

2.1. Modelado Conceptual OO y Patrones Conceptuales 17

diante esquemas conceptuales (también se utiliza la palabra modelo3 como sinónimode esquema) que constituyen una abstracción de la realidad. Los objetos no formanparte del esquema, mantienen la información del mismo y son instancias de las cla-ses. El modelado conceptual OO es un proceso centrado en capturar la estructuray el comportamiento del UoD mediante la identi…cación de los objetos y sus relacio-nes a través de las siguientes abstracciones (conceptos introducidos en el trabajo deGoldstein et al. [79]):

² Clasi…cación: los objetos se clasi…can en clases o tipos de objetos.² Generalización: las clases con propiedades comunes se generalizan en una su-perclase. El proceso contrario es la especialización.

² Agregación: Es la composición de un determinado número de objetos en unomás complejo.

Una de las di…cultades más importantes en la etapa de modelado es poseer unconocimiento adecuado del dominio (difícil de conseguir en la mayoría de los casos).El conocimiento del dominio se puede obtener de las personas que trabajan en el UoDanalizado, por lo que es necesaria la cooperación y una buena comunicación entre laspersonas que conocen el dominio y los metodólogos. La necesidad de documentar elproblema modelado y facilitar la comunicación, ha llevado al desarrollo de notacio-nes grá…cas para los lenguajes de modelado conceptual. Los distintos métodos OOproporcionan técnicas y diagramas diversos para representar la estructura, el com-portamiento y la interacción de los objetos. Algunos de los métodos más conocidosy utilizados son las propuestas de OMT [195], OOSE [113], Wirfs-Brock [240], Booch[31], Fusion [51], Syntropy [53], Coad y Yourdon [50], Martin y Odell [140], Catalysis[66] etc.Actualmente el Lenguaje de Modelado Uni…cado (UML) [86] juega actualmente

un papel importante en esta área. UML fue sugerido inicialmente por Booch en unareunión del OOPSLA’934 [141]. Aunque su esfuerzo inicial falló, la contratación deBooch, Rumbaugh y Jacobson por Rational Corporation permitió desarrollar lo quese conoció inicialmente como Método Uni…cado (presentado en OOPSLA’95). Casial mismo tiempo el Object Management Group (OMG) [85] creó un grupo conocidocomo OA&DTF (Object Analysis and Design Task Force) que lanzó en Junio de1996 la primera petición de propuestas (RTF) de lo que actualmente es UML. Booch,Rumbaugh y Jacobson aprovecharon esta situación para enviar su propuesta a OMGque constituyó la base de UML, siendo aceptado como estándar a …nales de 1997. Apartir de dicho momento UML ha recibido la aprobación de facto de la industria ysigue en proceso de revisión.Otra di…cultad añadida es la ausencia de una manera uniforme de representar los

diferentes fenómenos presentes en el UoD, siendo posible adoptar diversas solucionespara representar un mismo fenómeno. Esto requiere un análisis cuidadoso de las ven-tajas y desventajas que posee la elección de una determinada construcción conceptualfrente a otras para modelar un problema en particular. Para superar estas di…cultades

3Según [62] un modelo es un esquema teórico de un sistema o realidad compleja que se elaborapara facilitar su comprensión y el estudio de su comportamiento.

4Conferencia Object Oriented Programming Systems Languages and Applications.


es necesario proporcionar técnicas que evalúen la calidad de los esquemas conceptua-les. En esta área destacan trabajos como el de Lindland et al. [132] que resumeuna serie de criterios o factores de calidad encontrados en la literatura y los agrupaen tres categorías: calidad sintáctica, semántica y práctica. La calidad sintácticase garantiza mediante el uso correcto del lenguaje de modelado, determinando que latotalidad de sentencias usadas en la descripción del esquema sean acordes con la sinta-xis preestablecida. La calidad semántica se re…ere a la correspondencia del esquemacon el UoD que modela. La calidad práctica está relacionada con las consideracio-nes prácticas sobre qué construcción de modelado elegir en el caso de tener diversasposibilidades para representar la misma semántica. De esta forma se pretende que elesquema sea entendido por todos los desarrolladores y usuarios.En muchas ocasiones la baja calidad semántica y práctica de los esquemas concep-

tuales se debe a que las construcciones de modelado utilizadas (a las que en esta tesisse llamará patrones conceptuales) son ambiguas e imprecisas. Además, normalmenteno llevan asociado un componente metodológico que ayude al analista a identi…cardichas relaciones en la etapa de modelado de forma que se obtengan esquemas decalidad. Si a estas de…ciencias se les une la di…cultad de desarrollar código que re-presente …elmente los requisitos funcionales modelados debido a la imprecisión de lasabstracciones conceptuales presentes en el esquema, se obtienen métodos de desarrollode software de baja calidad.

2.1.1 Patrones Conceptuales

En el modelado conceptual de sistemas de información (siguiendo el enfoque OO)aparecen en el espacio del problema una serie de patrones estructurales y de com-portamiento que deben ser especi…cados de forma precisa. El enfoque del proceso demodelado como un proceso de detección de patrones estructurales y de comportamien-to fue introducido por Papazoglou en [160]. Siguiendo estas ideas, si se proporcionanconstrucciones conceptuales expresivas y, se consigue identi…car y representar estospatrones de forma no ambigua, se podrán construir procesos de desarrollo automáticosque permitan traducir los patrones conceptuales al espacio de la solución.Las relaciones como la agregación, asociación y especialización constituyen unos

de los patrones conceptuales más utilizados en el modelado conceptual OO. Estospatrones no están soportados de forma precisa por la mayoría de los métodos de des-arrollo convencionales, debido a que no ofrecen pautas claras para la identi…cación,especi…cación e implementación de dichos patrones. Cuanto más precisos sean losconstructores utilizados para especi…car estos patrones, con mayor nivel de detalle sepodrán capturar los requisitos funcionales de la aplicación. Esto facilitará la construc-ción de esquemas conceptuales de calidad y el desarrollo sistemático de aplicacionesa partir de los patrones detectados en la etapa de modelado.Para justi…car la necesidad de introducir patrones conceptuales precisos en la etapa

de modelado, se presenta a continuación un ejemplo intuitivo cuyo diagrama de clases,en notación UML, se puede ver en la …gura 2.1. El sistema de ejemplo propuesto seanalizará a fondo para extraer toda la información posible (estructura del sistema,relaciones entre componentes, comportamiento asociado a las componentes y a susrelaciones) y entender cómo la mayoría de propuestas de modelado OO (en este casoUML) no son capaces de captar una parte importante de la semántica del problema,


Moroso

ProductoLineas Detalle

0..n 1

Cliente

Factura

Pedido

0..n

1

1

0..n

1..n

1..n

0..n 1

incluye

posee

1

0..n

realiza 1

0..n

1..n

1..n

tiene

Figura 2.1: Diagrama de Clases UML

debido a que no proporcionan un modelo de objetos su…cientemente expresivo. Laespeci…cación propuesta es: “Un sencillo sistema de gestión en el cual una empresaposee una lista de clientes que le hacen pedidos y ésta los sirve. Cada pedido a su vezestá constituido por un conjunto de líneas de detalle, y cada línea de detalle referenciaa un producto. Los clientes pasan a ser morosos si no pagan las facturas que remitela empresa en un periodo de noventa días”.

La Semántica de los Objetos

En este apartado se analizan las clases del diagrama de clases de la …gura 2.1, paraidenti…car qué expresividad es necesaria para obtener una especi…cación completa. Enuna aproximación orientada a objetos es necesario especi…car atributos que de…nanel estado de un objeto, y operaciones que modi…quen dicho estado. Por ejemplo, elcliente tiene nombre y dirección, y hacen falta operaciones para modi…car su dirección;las líneas de detalle tienen una cantidad del producto pedido, y esta cantidad se debepoder modi…car mediante operaciones que se encarguen de ello. Además para losatributos de un objeto se necesita de…nir restricciones sobre su valor, porque seránecesario expresar restricciones como que “la cantidad de una línea de detalle hade ser menor o igual que la reserva (stock en inglés) existente del producto”. Enla especi…cación es posible que se quieran expresar condiciones sobre el estado delos objetos que inhabiliten ciertas operaciones. Por ejemplo, para expresar que nose puedan comprar productos hasta que la reserva no llegue al mínimo. Existensituaciones en las que los objetos reaccionan (realizando peticiones de servicios aobjetos) debido a que se cumplen ciertas condiciones sobre su estado: por ejemplo,cuando la reserva llega al mínimo se envía una petición de compra al objeto encargadode ello. Una tarea esencial para describir completamente los objetos del sistema es


poder especi…car cómo modi…can las operaciones el valor de sus atributos. Tambiénes habitual especi…car atributos derivados cuyo valor se obtiene a partir de otrosatributos, por lo que será necesario especi…car cómo se obtiene su valor. Para …nalizar,los objetos de un sistema muchas veces siguen patrones de comportamiento (secuenciasde operaciones) muy particulares que son interesantes describir y además obligar aque se cumplan durante su vida. Por ejemplo si no se compran productos no se puedenvender, si el cliente no realiza un pedido no debe pagar una factura, y así para grancantidad de casos.

La Semántica de las Relaciones entre Objetos

Las relaciones entre clases en los sistemas reales poseen más semántica de la quemuchos métodos proponen. Si se analiza el esquema y las relaciones modeladas, sepueden observar ciertos patrones estructurales y de comportamiento que enriquecenel modelo construido.En el esquema conceptual presentado existen dos relaciones interesantes: un cliente

realiza uno o varios pedidos, y un pedido posee un conjunto de líneas de detalle. Lasemántica de cada una de las relaciones se puede inferir a partir de cómo se comportanestos objetos de negocio en el mundo real. La relación entre pedido y líneas de detallees un ejemplo típico del patrón maestro/detalle muy común en las aplicaciones degestión. Si se conoce dicho patrón se puede deducir que cuando se crea un pedido,éste puede inicialmente no tener líneas de detalle. El usuario de la aplicación podráañadir de forma dinámica tantas líneas como sean necesarias. También se sabe queuna línea de detalle lo es de un único pedido. Una línea de detalle no puede existirfuera de un pedido. Cuando un pedido se elimina del sistema, se han de eliminar asu vez las líneas de detalle que posee.La relación posee implica claramente una semántica de contención o inclusividad,

expresando que las líneas de detalle no pueden existir fuera del pedido. Tambiénposee una cardinalidad que implica que un pedido puede tener cero o más líneas dedetalle, y una línea de detalle puede formar parte de un solo pedido. La semánticade inclusividad implica un comportamiento claramente determinado, y es el borradode todos los objetos línea de detalle cuando se borra el pedido.El comportamiento asociado a la relación entre cliente y pedido (realiza) es que

un pedido lo ha de realizar un cliente de forma obligatoria, y un cliente puede realizarmuchos pedidos, por lo que el pedido debería conocer qué cliente lo ha efectuado, yal revés, un cliente debe saber qué pedidos ha realizado. La relación entre cliente ypedido no implica inclusividad, porque un cliente no está constituido por sus pedidos.La relación realiza es menos fuerte y es además bidireccional, aunque es una relaciónque sigue un patrón de comportamiento dinámico ya que los pedidos que realiza uncliente pueden variar con el tiempo (el cliente puede ir realizando pedidos conformelos necesita), por lo que se han de ofrecer construcciones que permitan representarestas características inherentes al problema.Además de esta relación, aparece también la relación de agente (como objeto

activo), que determinará qué objetos están autorizados a activar qué servicios deotras clases. Existen objetos del sistema que pueden solicitar servicios de otros objetospor iniciativa propia, por ejemplo es el caso de cliente que por iniciativa propia puederealizar pedidos, pero sin embargo los pedidos por iniciativa propia no pueden solicitar


servicios a otros objetos.Observando las clases cliente y moroso se puede ver que existe una relación de

especialización, pero además se puede observar por el conocimiento del problema queun cliente puede pasar a ser moroso en el momento en el que le ocurra algo (quelo declaren moroso) o que se den ciertas condiciones sobre su estado actual que loconviertan en moroso (por ejemplo que lo que le debe a la empresa que le sirve lospedidos sea mayor que una cantidad), pudiendo además dejar de ser moroso cuandopague lo que debe o le embarguen el material. Es importante destacar que estarelación de especialización es más expresiva que una típica relación Es-Un. Se tratade una especialización temporal o dinámica ya que el cliente puede convertirse enmoroso y dejar de serlo en cualquier momento. Esa especialización además se realizaporque al cliente le ocurren ciertos eventos o se cumplen ciertas condiciones, y deigual manera le ocurre al moroso para dejar de serlo.Probablemente, en este ejemplo no se hayan podido mostrar todos los elementos

necesarios para especi…car correctamente los componentes del sistema, pero es útilpara darse cuenta de la cantidad de elementos expresivos (a pesar de la simplicidaddel sistema estudiado) que debería ofrecer un buen método de modelado capaz deexpresar la mayor semántica posible del problema, mediante la especi…cación de todaslas relaciones estructurales y los patrones de comportamiento que se han observado.

2.1.2 Relaciones Taxonómicas como Patrones Conceptuales

La especialización es un mecanismo de especi…cación que permite introducir informa-ción taxonómica en el esquema conceptual de un sistema, estableciendo un ordena-miento entre clases, unas más generales (superclases) y otras como especializacionesde las primeras (subclases), que heredan sus propiedades y posiblemente añaden nue-vas más especí…cas. En este apartado se analiza el uso que se hace de los conceptosde herencia y especialización para determinar adecuadamente la semántica de las abs-tracciones utilizadas en el ámbito del modelado conceptual, con el …n de modelar lasdistintas relaciones taxonómicas presentes en el Espacio del Problema. El términorelaciones taxonómicas en esta tesis pretende englobar a aquellos patrones concep-tuales que introducen información taxonómica en la especi…cación de un sistema deinformación.

Herencia vs. Especialización

La herencia constituye un mecanismo de abstracción fundamental en los sistemasorientados a objetos, aunque es un concepto controvertido sobre el cual los investiga-dores no se muestran de acuerdo acerca de su semántica y de su aplicación adecuadaen el desarrollo de software. En muchas aproximaciones se confunde el término heren-cia con la especialización. La razón de esta confusión hay que buscarla en la propiaevolución histórica de la OO. La OO partiendo del campo de los lenguajes de pro-gramación ha evolucionado hasta implantarse en todas las etapas del desarrollo desoftware. Esta evolución ha surgido de manera natural en algunas abstracciones, peroen el caso de la herencia no ha sido así.Tradicionalmente se pensaba que herencia y especialización eran diferentes vistas

del mismo concepto, Taivalsaari argumenta en [222] que “la vista clásica considera ala herencia de la programación OO como un mecanismo de estructuración jerárquica


pensado para la especialización conceptual”. Actualmente existen diversos trabajos[9, 230, 231, 244] en los que se indica que la relación entre herencia y especialización noestá bien determinada . La mayoría de problemas surgen del hecho de que los entornosde desarrollo OO no pueden garantizar que la herencia se utilice para implementaradecuadamente la especialización conceptual. Una de las primeras propuestas pararesolver este problema la presenta Madsen et al. en [136], introduciendo la herencia (dela programación OO) como un mecanismo para modelar cierto de tipo de relacionesa las que llaman especialización conceptual. Con la intención de proporcionar reglasque garanticen la correspondencia conceptual entre clases padres e hijas, Wegner etal. en sus trabajos [230, 231] desarrollan las llamadas reglas de compatibilidad, eintroducen el término de herencia estricta para hablar de la herencia que representala especialización conceptual siguiendo las reglas de compatibilidad.De manera contraria a las aproximaciones anteriores, Brachman en su trabajo

sobre redes semánticas [33] sugirió que la herencia sólo debía utilizarse en imple-mentación y no tenía correspondencia directa con ningún elemento en el modeladoconceptual, por lo que no pretendía utilizar la herencia como mecanismo de imple-mentación de la especialización. En posteriores trabajos [9, 10, 54, 159, 183, 187]diversos autores proponen una distinción entre herencia (como un mecanismo de másbajo nivel por el cual los objetos y clases pueden compartir datos y comportamiento)y subtipado (que expresa la especialización conceptual). En este contexto a la he-rencia se le llama herencia de implementación o de representación, y al subtipadose le llama herencia de especi…cación o de interfaz. Algunos trabajos [101] utilizanlos términos herencia sintáctica y semántica para distinguir entre herencia de imple-mentación y de especi…cación respectivamente. Incluso considerando las propuestasanteriores la categorización de los tipos de constructores presentados no era su…cien-temente precisa ya que la herencia de especi…cación o subtipado no se correspondíaexactamente con la especialización conceptual. LaLonde en [123] es quién presentauna categorización más adecuada basada en tres conceptos:

² subclasi…cación: como un mecanismo de implementación para compartir códigoy representación.

² subtipado: como una relación de reemplazabilidad; en la que una instancia deun subtipo puede representar a una instancia del supertipo.

² Es-Un: como relación de especialización conceptual describe un objeto comouna clase especial de otro.

En las aproximaciones presentadas se hace patente la diferencia existente entre laherencia y la especialización. El concepto de especialización presente en la mayoría demétodos de modelado es el de una relación Es-Un según la categorización propuesta.Esta relación se corresponde con la herencia estricta que exige compatibilidad decomportamiento.

Especialización y Generalización: Distintas Vistas de un Proceso Taxo-nómico

Un término que aparece habitualmente vinculado a la especialización es la generali-zación. Para comprender la diferencia entre ambos conceptos es necesario recurrir a


la idea de taxonomía introducida en el primer capítulo. Una taxonomía se puederepresentar grá…camente en forma de grafo acíclico dirigido (o árbol), que según searecorrido da lugar a los dos conceptos de modelado:

² La generalización parte de la existencia de clases menos generales y a partirde ellas de…ne una clase más general que aglutina las características comunes atodas ellas. Supone por tanto un recorrido ascendente en el árbol taxonómico.

² La especialización parte de la existencia de una clase más general y a partir deella de…ne un conjunto de clases más concretas que incluyen las característicasde la clase general, además de ciertas características especí…cas. Supone portanto un recorrido descendente en el árbol taxonómico.

La mayoría de métodos convencionales de modelado OO utilizan la generalizacióncomo un término equivalente a la herencia y suele estar al mismo nivel de abstracciónque la herencia ofrecida por los lenguajes de programación. Esta situación queda ilus-trada en UML, que aglutina la notación de los enfoques semiformales más populares.Sin contar con mayor de…nición al respecto, la generalización de UML se interpretaen la mayoría de los casos como una especialización estática.

Relaciones Taxonómicas: Más Allá de la Especialización

La especialización en el modelado conceptual va más allá de las abstracciones con-ceptuales que presentan los métodos convencionales. La herencia estricta restringe eltipo de re…namiento que se puede llevar a cabo en las subclases. Para que la espe-cialización pueda ser útil en una gama más amplia de situaciones, y posea un mayorpoder expresivo, es necesario que no sea un concepto tan estricto.En la práctica del modelado, la especialización es un patrón conceptual muy ex-

presivo del cual existen diversas caracterizaciones temporales [81, 119, 121, 181, 191,200, 238] que introducen abstracciones como la especialización estática, dinámica, ylos roles. Estas caracterizaciones enriquecen las técnicas de modelado, aunque de estaforma, la especialización posee una naturaleza más compleja a nivel estructural y decomportamiento, que el concepto de especialización proporcionado por la mayoría delas técnicas de modelado semi-formales.La mayoría de las propuestas referenciadas en el párrafo anterior presentan unos ti-

pos de “especializaciones” llamados roles, que manteniendo su naturaleza taxonómica,según comentan Kristensen et al. [119, 121], no son modelados como especializacionesen el sentido de la herencia estricta. Además otras propuestas como la de Gottlob etal. [81] no utilizan mecanismos de herencia estándar para heredar sus propiedades,modelándose los roles como envoltorios de las superclases y utilizando delegación paraacceder a las propiedades “heredadas”. A partir de estos enfoques se observa que laespecialización en la práctica es un concepto que va más allá de la herencia estricta,es por ello que en esta tesis, tal y como se comentó en el primer capítulo, se realiza untratamiento más amplio del concepto, estudiando las características de las relacionestaxonómicas.Esta tesis aporta una solución a la identi…cación y tratamiento de las relaciones

taxonómicas mediante la de…nición de un marco de referencia genérico que permiteidenti…car y categorizar las características esenciales de las relaciones taxonómicas


como una serie de patrones estructurales y de comportamiento. Este marco se de…neestudiando las diversas propuestas existentes en la literatura, y se utiliza para abordarla etapa de modelado conceptual como un proceso de detección y especi…cación depatrones en el espacio del problema.

2.2 Integración de Técnicas Formales y Semi-For-males

La precisión en la de…nición de los patrones conceptuales es una característica necesa-ria para abordar su implementación mediante procesos automatizados. La utilizaciónde técnicas formales permite de…nir de forma clara y no ambigua la semántica de lasconstrucciones a utilizar en el modelado, de…niendo qué son las clases, los objetos,las relaciones entre clases y cómo se comportan e interactúan los objetos. Una técni-ca formal interesante son los lenguajes de especi…cación formal orientados a objetosque proporcionan patrones conceptuales con una semántica bien de…nida. El uso dedichos lenguajes permite concretar las nociones consideradas relevantes a efectos deespeci…car correctamente un sistema de información.Sin embargo, la utilización de técnicas formales conlleva un esfuerzo considera-

ble a asumir por las organizaciones productoras de software. El coste asociado a laconstrucción y ejecución de una especi…cación formal debe estar justi…cado por los be-ne…cios obtenidos al aplicar esta técnica. Una de las formas mediante la cual se puedereducir el esfuerzo y la complejidad inherente a la utilización de técnicas formales esa través de la combinación de estas técnicas con métodos de modelado conceptualconvencionales, utilizando sus intuitivas, sencillas y conocidas notaciones grá…cas. Elacercamiento de ambas aproximaciones puede incluso llegar a hacer transparente eluso de lenguajes de especi…cación formales, obteniendo el bene…cio que proporcionasu utilización, y minimizando el esfuerzo de aprendizaje.

2.2.1 Lenguajes de Especi…cación Formal

Los lenguajes de especi…cación formal poseen una sólida base en lógica, álgebra, teo-ría de conjuntos, etc., proporcionando un marco riguroso para la especi…cación desistemas. Los métodos basados en estos lenguajes aportan ventajas signi…cativas alproceso de desarrollo de software, ya que utilizan notaciones precisas y veri…cables quefacilitan, en algunas ocasiones, la generación automática de prototipos ejecutables.Con la aparición de UML y su lenguaje de de…nición de restricciones para objetos

(OCL), cada vez más, se intenta construir y utilizar lenguajes formales para la especi-…cación de propiedades. UML proporciona el OCL y un metamodelo para especi…carla semántica de sus abstracciones conceptuales. Sin embargo, estas dos herramien-tas no son su…cientes para expresar completamente la semántica de los elementos demodelado, como así lo reconoce la propia propuesta en la sección 2.3 página 2-7 dela especi…cación de UML [86]: “Es importante hacer notar que la descripción actualno es una especi…cación completamente formal del lenguaje ... La semántica de ladinámica se describe utilizando lenguaje natural,...”. Los lenguajes de especi…caciónformal OO constituyen un mecanismo adecuado para la descripción precisa de patro-nes conceptuales, por lo que es adecuado aplicar este tipo de técnicas en la de…nición

2.2. Integración de Técnicas Formales y Semi-Formales 25

de los distintos tipos de relaciones taxonómicas que se presentan en esta tesis. Ade-más, existen herramientas software basadas en lenguajes de especi…cación formalesque pueden ejecutar especi…caciones o derivar propiedades del comportamiento es-peci…cado. Desde el punto de vista del modelado conceptual estas herramientas sepueden utilizar para validar la especi…cación (veri…car que el sistema se comporta taly como se deseaba) antes de su desarrollo e implantación.Algunos de los lenguajes formales más relevantes vienen utilizándose desde hace

tiempo. Entre este tipo de lenguajes se puede destacar lenguajes como OBLOG [204]y TROLL, desarrollados en el marco del proyecto ESPRIT IS-CORE (InformationSystems- Correctness and Reusability). OBLOG dispone de una semántica formali-zada por teoría de categorías. TROLL en su primera versión [102, 117], posee unaexpresividad basada en lógica de predicados de primer orden, lógica temporal (res-tricciones dinámicas, pre/post condiciones) y álgebra de procesos (especi…caciones deciclos de vida), y en su última versión [63] utiliza una lógica temporal distribuidallamada DTL [71]. Con una sintaxis parecida, pero con una semántica de álgebra ini-cial y lógica dinámica, también se ha desarrollado LCM (”Language for ConceptualModeling”) [74]. LCM dispone de un método de desarrollo llamado MCM (”Methodfor Conceptual Modeling”) que combina especi…caciones LCM con ER, DFD y JSP.Albert II [67] es otro lenguaje de especi…cación formal basado en lógica temporalen tiempo real y utilizado en el marco del proyecto ESPRIT CREWS [60] para lavalidación de requisitos. En el ámbito español se encuentra el lenguaje de especi…-cación TESORO [227] desarrollado en la Universidad de Sevilla. Por último se hadesarrollado OASIS [129, 172], un lenguaje de especi…cación formal en el cual sebasa OO-Method. OASIS ha sido utilizado en diversos proyectos de investigaciónentre ellos el proyecto PASO/Esprit “OOAP” y el subproyecto ESPILL dentro delmarco del proyecto coordinado CICYT MENHIR.OASIS constituye un enfoque formal para la especi…cación de modelos concep-

tuales siguiendo el paradigma orientado a objetos. En su primera versión [166] fueformalizado a través de teorías de Primer Orden que evolucionan en el tiempo. Esteenfoque lo situó en un entorno de programación lógica complementado con un moni-tor para la gestión de la perspectiva dinámica del sistema. En las siguientes versiones[129, 176] se cambió el marco formal y se trabajó en el contexto de una variante de laLógica Dinámica [95], permitiendo representar los operadores de obligación, prohibi-ción y permisos usados en Lógica Deóntica [14]. Las líneas de trabajo desarrolladasalrededor de OASIS han sido las siguientes:² Establecimiento de un método de desarrollo basado en OASIS denominadoOO-Method [168].

² Síntesis de programas en entornos de desarrollo industrial [175].² Construcción de herramientas CASE de soporte al modelado conceptual y lageneración automática de código basadas en OO-Method y OASIS [167, 177].

² Generación automática de prototipos orientados a la validación de especi…ca-ciones OASIS, utilizando como técnicas de implementación las Redes de Petri[197] y la Programación Lógica Concurrente [128].

² Formalización de Procesos de Desarrollo y Evolución del software [40, 43].


2.2.2 Integración de Técnicas

Las aproximaciones convencionales y formales poseen sus pros y sus contras. A travésde un proceso de integración que seleccione lo mejor de ambos mundos se puedeobtener una aproximación con los siguientes efectos positivos:

² Las buenas propiedades de los lenguajes de especi…cación formales se puedenutilizar para descubrir y eliminar ambigüedades y, elementos de dudosa utilidad,desde las primeras fases del desarrollo de software; además de proveer un marcoformal y riguroso como parte de un proceso de ingeniería.

² El uso de lenguajes de especi…cación formales, generalmente acompañados deun sistema de inferencia lógica, combinado con métodos de análisis permite dis-poner de herramientas CASE para comprobar propiedades de la especi…caciónobtenida en la fase de modelado.

² El uso de notaciones grá…cas, que capten de forma intuitiva y precisa los aspectosrelacionados con la estructura y comportamiento de los objetos, y el hecho deque dichas notaciones estén intrínsecamente ligadas a una representación formalinterna, permite la obtención automática de especi…caciones formales a travésde mecanismos de traducción bien de…nidos.

² La entrada de los generadores de código queda perfectamente especi…cada alalmacenar los constructores de modelado en un repositorio formal, permitiendoabordar el proceso de generación automática de código.

En esta dirección existen ya algunas propuestas interesantes en las cuales se de-…nen de forma precisa los conceptos de modelado mediante lenguajes formales y sedesarrollan notaciones grá…cas a partir de las construcciones de modelado:

² La aproximación OMTROLL [239] ayuda a los diseñadores a construir la es-peci…cación formal del sistema con una notación grá…ca al estilo OMT. Estaespeci…cación está basada en el lenguaje de especi…cación TROLL [82]. La es-peci…cación textual debe re…narse para poder completar la especi…cación delsistema. La naturaleza formal de TROLL ayuda a conseguir especi…caciones desistemas concisas y no ambiguas, además de facilitar el desarrollo de mejoresherramientas CASE. En particular OMTROLL posee un soporte CASE llamadoTrollWorkbench [83, 122].

² OBLOG CASE [204] es otra aproximación orientada a objetos para el desarrollode software. Existe una notación grá…ca asociada al lenguaje de especi…caciónOBLOG y una herramienta CASE [12, 152] para construir especi…caciones.

² El método Object System Analysis model (OSA) de Clyde et al. [46] es unaaproximación centrada en proporcionar distintos niveles de formalismo al méto-do. Su propósito es desarrollar un método que permita a los diseñadores desistemas trabajar con distintos niveles de formalismo (lo llaman formalismo sin-tonizable (”tunable formalism”)), desde el nivel informal al matemáticamenteriguroso. Los mismos autores analizan las di…cultades encontradas para conse-guir lenguajes que sean equivalentes al modelo [131] y ofrecen una solución en

2.3. Generación de Código Basada en Modelos 27

el contexto de OSA para el lenguaje MELODY en particular. OSA posee unaherramienta CASE de soporte llamada IPOST [111], que genera a partir de unmodelo OSA un prototipo en un entorno declarativo. Este prototipo se utilizapara la validación de los requisitos.

² SOFL (Structured-Object-based-Formal Language) [135] proporciona una apro-ximación diferente a las anteriores. Su propósito es introducir la utilización detécnicas formales en procesos software industriales. La propuesta propugna eluso de los métodos formales mediante la búsqueda de mecanismos de enlaceentre las técnicas estructuradas y OO, y los métodos formales (utilizando unasemántica al estilo VDM [116] para la especi…cación de sus módulos). SOFLtransforma la especi…cación de requisitos en formato estructurado a un diseñoorientado a objetos y estos diseños en programas.

Analizando estas aproximaciones se observa que OBLOG, TROLL y OSA pre-sentan soluciones similares a la integración de técnicas formales y semi-formales, sinembargo poseen una carencia en común: todas son soluciones incompletas porque so-lamente abordan la etapa de especi…cación y prototipado, sin proporcionar solucionesde implementación en entornos de desarrollo comerciales. Debido a esta circunstan-cia, el desarrollador una vez ha veri…cado y validado el prototipo debe implementarel sistema a partir de la especi…cación sin ningún tipo de guía metodológica. En elcapítulo siguiente se analizan con detalle las herramientas CASE que proporcionanlas aproximaciones OBLOG y TROLL. En el caso de SOFL sólo se aborda la eta-pa de especi…cación, sin aportar una herramienta de soporte que permita comprobarla consistencia de los modelos, y además no proporciona un proceso automático detransformación de la especi…cación en programas.Por último es necesario destacar la aproximación OO-Method que integra técnicas

formales y semi-formales, y proporciona un método que da solución a las de…cienciasdetectadas en las aproximaciones anteriores. OO-Method proporciona un tipo dife-rente de formalismo sintonizable en el que la expresividad del lenguaje OASIS sepreserva completamente, pero se le presenta al analista siguiendo una notación grá…caconocida (una extensión de UML). Además refuerza la idea de tener un lenguaje equi-valente al modelo (un lenguaje con una correspondencia uno-a-uno con los elementosde un modelo formal). El modelo se puede ejecutar gracias a que la especi…cación delsistema se puede implementar completamente siguiendo un modelo de ejecución (quese presenta al …nal del capítulo) que garantiza la equivalencia funcional entre la es-peci…cación y el código generado. Esta aproximación constituye una implementaciónoperacional alternativa a la metáfora del lenguaje equivalente al modelo, generandoautomáticamente aplicaciones en entornos de desarrollo industriales.

2.3 Generación de Código Basada en Modelos

Según Balzer [18] (considerado el introductor del paradigma de la programación au-tomática), la programación automática se fundamenta en el uso de métodos y herra-mientas que soporten la adquisición de especi…caciones de alto nivel, la validación delas mismas y, que proporcionen algún mecanismo de traducción que produzca códigoejecutable (ver Figura 2.2). Actualmente esta aproximación ha evolucionado hacia loque se llama Generación Automática de Código basada en Modelos [25].


Adquisición de laEspecificación

CompilaciónAutomática

TraducciónInteractiva

Sintonización

Validación de laEspecif icac ión

Mantenimiento

Especificacióninformal

Especificaciónde Alto Nivel

(Prototipo)

Decisiones

DesarrolloFormal

Especificaciónde Bajo Nivel

Programa Fuente

Figura 2.2: Paradigma de Programación Automática

La Generación de Código basada en Modelos (GCBM) es un área de la Ingenieríadel Software cuyo propósito es elevar el nivel de abstracción del trabajo del desarrolla-dor, concentrándose en el modelado del sistema a desarrollar y dejando el proceso degeneración de código a herramientas de traducción automática. Estas herramientasmantendrán la utilidad de los modelos OO construidos y permitirán reducir el tiempode puesta en el mercado de los productos software.Uno de los problemas que poseen los métodos de modelado OO actuales es cómo

efectuar de forma automatizada la transición de un modelo del dominio (esquemaconceptual en el Espacio del Problema) a un modelo software (implementación en elEspacio de la Solución). La GCBM intenta resolver este problema ofreciendo métodosde Modelado con Generación de Código (ver …gura 2.3). En la GCBM, un conjunto dediagramas modelan la estructura, la comunicación y el comportamiento de los objetosdel sistema. Como complemento a los diagramas, se utilizan lenguajes de alto nivelpara completar la especi…cación del sistema de manera textual. Para hacer efectivaslas ideas que proporciona la GCBM es necesario que la aproximación posea:

² Modelos apropiados para representar el problema.² Constructores de modelado expresivos y precisos.² Traductores capaces de generar código de calidad.² Un método y herramientas para la aplicación efectiva de la GCBM.

2.3.1 Enfoques Actuales

En el resumen de una sesión de debate del OOPSLA’96: “Traslation: Myth or Reality”se presentan dos “escuelas de pensamiento”:

² La “de traducción”5 liderada por Shlaer y Mellor que proponía: “Un modelo dela aplicación y uno de arquitectura que se componen para generar el código”.

² La “iterativa” liderada por Booch, Rumbaugh, Jacobson y Martin que proponía:“Diferentes niveles de abstracción hasta llegar a producir código”.

5Traducido del término inglés: “traslational”.


Compilador

Sistema Ejecutable

CódigoFuente Bibliotecas

Run-TimeOpciones de Código

Compilador

CódigoFuente

EsquemasConceptulaes BibliotecasOpciones de

Arquitectura

DesarrolloTradicional

GCBM

CompiladorCompilador

Sistema Ejecutable

CódigoFuente Bibliotecas

Run-TimeBibliotecasRun-TimeOpciones

de Código

CompiladorCompilador

CódigoFuente

EsquemasConceptulaes BibliotecasOpciones de

Arquitectura

DesarrolloTradicional

GCBM

Figura 2.3: Desarrollo tradicional frente a GCBM

EstructuralDe

ComportamientoDe

Traducción

Modelos Código

Evolución de las Herramientas

EstructuralDe

ComportamientoDe

Traducción

Modelos Código

Evolución de las Herramientas

Figura 2.4: Evolución de los enfoques GCBM

Sin obviar la importancia de la escuela iterativa en el desarrollo de software actual,en este apartado se presentan los distintos enfoques para la GCBM que posee la escuelade traducción, marco en el que se desarrolla el trabajo de esta tesis. La escuela detraducción propone tres enfoques:

² Estructural: Genera plantillas de código a partir del diagrama de clases.² De comportamiento. Genera código usando máquinas de transición de esta-dos y especi…caciones de acciones en un lenguaje de alto nivel.

² De traducción: Utiliza un modelo de arquitectura independiente de la aplica-ción para dar un control total sobre la traducción a código.

Cada tipo de enfoque incluye las características del tipo previo, como se muestraen la …gura 2.4.

Enfoque Estructural

El enfoque estructural es apropiado para los métodos en los que los modelos se elabo-ran mediante una transición gradual entre análisis, diseño e implementación. Algunos


de estos métodos son OMT, Booch, OOSE y últimamente RUP [112] que utiliza UMLcomo notación. Este enfoque:

² Proporciona generación de código a partir de las estructuras estáticas de…nidasen el esquema conceptual (clases y atributos), y de las relaciones entre clases(asociación, agregación, especialización,...)

² No genera código para el comportamiento de los objetos. Aunque se utilicenmáquinas de estado, no se les asocia una semántica ejecutable.

² Ofrece mecanismos para integrar código escrito manualmente junto con la es-tructura generada.

² Obliga a los desarrolladores a completar el código de la aplicación de formamanual. Algunas herramientas protegen el código escrito manualmente paraevitar rescribirlo en sucesivas generaciones.

² Suele ofrecer mecanismos de ingeniería inversa para obtener los modelos (nor-malmente estructurales).

Algunos productos comerciales que siguen este enfoque son: Rational Rose [58](soporta las notaciones Booch, OMT y UML, y posee generadores de código Java,C++ y Visual Basic), Together [226](soporta la notación UML y genera código Java yEJB) y System Architect [15] (soporta las notaciones de Booch, OMT, Shlaer/Mellor,Coad/Yourdon, UML, CRC y genera código en C++, Java, Visual Basic y Smalltalk).Esta aproximación proporciona generación de código parcial, constituyendo una ca-rencia importante de este enfoque. Un hecho destacable es que las herramientasCASE que implementan este enfoque introducen ambigüedad al hablar de generaciónautomática de código sin especi…car exactamente qué tipo de generación ofrecen. Enestas aproximaciones el producto software generado no es completamente operativo ynecesita de un esfuerzo adicional para conseguir un producto totalmente funcional.

Enfoque de Comportamiento

El enfoque de comportamiento genera código a partir de modelos basados en máquinasde estados y de la especi…cación asociada a las acciones. Los métodos que más seutilizan en este enfoque son: Speci…cation and Description Language (SDL) [201],Statecharts de Harel [96] y ROOM [202]. Este enfoque:

² Permite animar y validar el comportamiento del sistema, a partir de los modelos.² Proporciona máquinas de estados extendidas que incluyen: paralelismo, comu-nicación y/o jerarquía.

² Reduce la programación aunque algunos aspectos deben incorporarse manual-mente.

² Proporciona lenguajes de con…guración6 para con…gurar el proceso de genera-ción de código, aunque sólo en algunas herramientas.

6Adaptación del término inglés “script”.


² Ofrece un control limitado sobre la generación de código porque los traductoresson prácticamente cerrados.

Algunos productos comerciales que siguen este enfoque son: Rhapsody de i-Logix[106] (basada en los “statecharts”, soporta UML y genera C++) y ObjectTime [151](basada en el método ROOM).

Enfoque de Traducción

El enfoque de traducción incorpora las características de los dos enfoques anteriores.Además desarrolla modelos de arquitectura mediante una serie de patrones de códigollamados “archetypes”. Estos patrones de…nen reglas de traducción para la generaciónde la arquitectura incluyendo la especi…cación de características como:

² concurrencia (threads, multitarea, sin concurrencia)

² manejo de eventos (colas, comunicación entre procesos, ‡ujos Entrada/Salida)

² datos (estructuras, mecanismos de persistencia).

El modelo de arquitectura que se obtiene en esta aproximación es independien-te del modelo de la aplicación, favoreciendo la reutilización de ambos modelos. Laconstrucción de un modelo de arquitectura es en sí un proyecto complejo. Se utilizaun lenguaje de scripts que manipula la información del modelo de aplicación de…nidopara poder generar la aplicación. Este enfoque también ofrece bibliotecas y mecanis-mos de composición y especialización de arquitecturas existentes. Las herramientasque soportan esta aproximación proporcionan arquitecturas prede…nidas que puedenextenderse mediante lenguajes de con…guración.Algunos productos comerciales que siguen este enfoque son: BridgePoint de Pro-

ject Technology7 basada en el método de Diseño Recursivo de Shlaer y Mellor [207],Intelligent CCG e iUML de Kennedy Carter [44], y OBLOG CASE [12] entre otros.

2.3.2 OO-Method y el Enfoque de Traducción

La aproximación que se propone en el trabajo de tesis se enmarca en el enfoque detraducción, aunque con algunas diferencias respecto a las aproximaciones existentesen la actualidad. En esta propuesta: se parte de una arquitectura prede…nida (trescapas), no se proporciona un lenguaje de con…guración para extender el productosoftware generado y adaptar los generadores, y por último no se permite modi…carel código generado para garantizar que la solución software obtenida se correspondecon el Esquema Conceptual que modela el problema. Es importante destacar, comoaportación del método, que se proporciona un compilador de esquemas conceptuales.Éste toma como entrada un conjunto de patrones conceptuales con una semánticaprecisa y obtiene su implementación completa a través de un proceso de transfor-mación, utilizando patrones de diseño especializados como medio para obtener unarepresentación software bien de…nida.

7 http://www.projtech.com/


2.4 Patrones Software

“Patterns are a starting point, not a destination” 8 Martin Fowler

En la Ingeniería del Software, los patrones software intentan describir solucionesque han resuelto de forma exitosa problemas comunes del software. Los patronessoftware [198] re‡ejan las estructuras conceptuales comunes a dichas soluciones, quepueden aplicarse de forma repetida cuando se está produciendo software (analizando,diseñando, e implementando) en un contexto particular. Representan el conocimien-to y la experiencia que subyacen en muchos esfuerzos de diseño y reingeniería de losdesarrolladores, consiguiendo mayor ‡exibilidad y capacidad de reutilización en susoftware. Además, proporcionan modelos útiles, especi…caciones de cómo utilizarlos,y asunciones y restricciones sobre su utilización. Facilitan la reutilización y la com-partición del conocimiento, de forma que permiten a los desarrolladores aprovecharsoluciones previas y adaptarlas a sus problemas especí…cos. Los patrones existen enlas diversas fases del desarrollo de software. Los desarrolladores no los inventan, sinoque los descubren debido a su experiencia en la construcción de sistemas.Actualmente, el uso de patrones en el proceso de producción de software es uno

de los temas más tratados entre la comunidad objetual, generando un gran interésentre investigadores y desarrolladores. Todavía existen discrepancias entre los inves-tigadores a la hora de de…nir qué es un patrón, por lo que es bastante difícil encontrarde…niciones de patrón que sean idénticas. En el libro de Fowler [75] se encuentracon una de…nición genérica interesante: “Un patrón es una idea que ha sido utiliza-da en un contexto práctico y que probablemente será útil en otros”. El término ideaexpresa que un patrón puede ser cualquier “cosa”. La expresión contexto prácticore‡eja el hecho de que se desarrollan (algunos autores pre…eren: descubren) gracias ala experiencia práctica de proyectos reales.En este apartado, se introduce de forma básica el mundo de los patrones software,

presentando conceptos útiles y necesarios para comprender la propuesta de aplicaciónen el proceso de producción de software que se expone en esta tesis. Durante eldesarrollo del apartado se esbozan las ideas que sustentan la propuesta de generaciónde código mediante patrones de diseño. Ésta se introducirá de forma detallada en lossiguientes capítulos.

2.4.1 Origen de los Patrones

Los métodos de desarrollo han proliferado pero lo único que proporcionan la mayo-ría son lenguajes para describir esquemas conceptuales y diseños; además de ésto,deberían proporcionar diseños prácticos y efectivos. Tal y como comentaron RalphJohnson y Ward Cunningham en [57]: “Los proyectos fallan a pesar de las nuevastecnologías debido a la falta de soluciones comunes”. Una de las soluciones a esteproblema son los patrones de diseño que permiten describir y promover la práctica debuenos diseños.Los patrones han surgido y evolucionado a partir de varias iniciativas: la de Kent

Beck y Ward Cunningham, dos de los pioneros de Smalltalk, también a partir de las

8Se puede adoptar esta frase para entender el papel que juegan los patrones software en estetrabajo. Los patrones no son el objetivo sino un camino, una herramienta para conseguir el objetivo.

2.4. Patrones Software 33

ideas de Christopher Alexander, que desarrolló una teoría y una colección de patronespara el mundo de la arquitectura [6, 7], y de las ideas de Peter Coad [47, 49] en lascuales presenta distintos patrones de análisis y diseño como una serie de relacionesentre elementos (dos o tres) de bajo nivel (clases). Bruce Anderson lideró talleres enOOPSLA a principios de los 90 en los cuales se investigó y se desarrolló un libro sobrearquitecturas software. Jim Coplien en su libro [55] describió modismos9 útiles enC++. Basados en la mayoría de estos trabajos se constituyó el grupo de Hillside parainvestigar estas ideas en un futuro. El empuje más grande para su conocimiento públi-co fue la publicación del libro Design Patterns, Elements of Reusable Object-OrientedSoftware [78] del grupo “Gang of Four” (GoF), y la conferencia PLoP (Pattern Lan-guage of Programming) que inició en 1994 el grupo de Hillside. Los patrones de diseñofueron una de las primeras propuestas que surgieron. Posteriormente sus ideas se hanextendido a la mayoría de las disciplinas del desarrollo de software.

2.4.2 Tipos de Patrones Software

Existen gran cantidad de patrones software y muy distintos criterios de clasi…cacióndefendidos por diversos autores [37, 78, 184]. Entre ellos los tipos más conocidos son:

² Los patrones arquitectónicos que se utilizan al inicio del diseño del sistema,y sirven para especi…car la estructura fundamental de una aplicación.

² Los patrones de análisis que son grupos de conceptos que representan unaconstrucción común en el mundo del modelado conceptual. Pueden ser relevan-tes a un dominio o ser adaptados a muchos dominios.

² Los patrones conceptuales que se pueden ver como las abstracciones a partirde las cuales se construyen los patrones de análisis, constituyendo los elementosconceptuales de menor granularidad de los patrones de análisis.

² Los patrones de diseño que son aplicables en la fases de diseño (preliminar ydetallado) y describen una estructura común de componentes que se comunicanpara resolver problemas generales de diseño en un contexto particular.

En los apartados siguientes se comenta cada uno de estos patrones y el papel quepueden jugar en la propuesta que se presenta en la tesis.

Patrones Arquitectónicos

Un patrón arquitectónico describe a un alto nivel de abstracción la división de unsistema en sus principales subsistemas y las dependencias entre éstos. Expresan losesquemas de organización estructural básicos para los sistemas software. Proporcio-nan un conjunto de subsistemas prede…nidos, especi…cando sus responsabilidades, eincluyendo reglas y guías para organizar las relaciones entre ellos. Básicamente ayudana especi…car la estructura fundamental de una aplicación. Cada patrón arquitectónicoayuda a conseguir una propiedad especí…ca del sistema global, por ejemplo la adap-tabilidad a la interfaz de usuario. Buschmann et al. [37] presentan una clasi…cación

9Del término inglés “idioms”.


de los patrones arquitectónicos que no pretende ser exhaustiva pero que sirve paraconocer los patrones arquitectónicos más utilizados.La selección del patrón arquitectónico adecuado para estructurar una aplicación

debe realizarse dependiendo de las propiedades generales de ésta. La mayor parte delos sistemas software no pueden estructurarse de acuerdo a un único patrón. Es muynormal que se utilicen combinaciones de diversos patrones arquitectónicos.En la propuesta que presenta esta tesis las aplicaciones generadas se estructuran

siguiendo una arquitectura de tres niveles (presentación, aplicación y persistencia)que hace uso de distintos patrones arquitectónicos [1, 35, 37].

Patrones de Análisis

Los patrones de análisis son grupos de conceptos y sus relaciones representando cons-trucciones comunes en el mundo del modelado. Un patrón de análisis puede utilizarseen diversos dominios. En muchas situaciones los analistas después de haber construi-do diversos modelos encuentran que muchos aspectos de un proyecto en particularidenti…can problemas que ya habían visto antes en otros proyectos, por lo que lasideas utilizadas en proyectos anteriores pueden ser útiles en el proyecto actual adap-tándolas a los requisitos del proyecto. Por ejemplo, Fowler en [75] detecta que muchosmodelos de sistemas sanitarios pueden ser aplicables en sistemas de análisis …nanciero.Algunos ejemplos de patrones de análisis son las abstracciones del dominio discutidasen el artículo de Maiden y Sutcli¤e [137], los patrones de análisis de Fowler [75], lospatrones de Coad [47, 49] y los patrones de Modelos de Datos presentados por Hayen [103].El concepto de patrón de análisis es similar al de ontología en la comunidad de

la representación del conocimiento [64, 149]. Una ontología se de…ne como una con-ceptualización explícita, donde una conceptualización está constituida por “objetos,conceptos y otras entidades que se asume existen en algún área de interés, y las rela-ciones que existen entre ellos” [87].Un requisito que han de cumplir los patrones de análisis es que deben ser su…cien-

temente generales para ser aplicados en el modelado de distintos tipos de aplicaciones.Además deben ser fáciles de entender y de aplicar. Para representar la estructura delos patrones de análisis se utilizan notaciones grá…cas estándar del tipo UML. Lospatrones de análisis son de gran utilidad, permitiendo detectar, durante el procesode modelado, estructuras conceptuales de mayor granularidad presentes en el Espaciodel Problema.

Patrones Conceptuales

En la bibliografía existente sobre patrones no aparece asiduamente el tipo de patrónllamado en esta tesis patrón conceptual. Trabajos actuales como el de Wohed [241]utilizan este concepto con el mismo signi…cado con el cuál es utilizado en el enfoquedefendido en esta tesis. El término patrones conceptuales constituye otra forma denombrar a las estructuras conceptuales, conceptos o abstracciones que sirven pararepresentar elementos de un dominio de aplicación, sus relaciones estructurales y sucomportamiento, en el contexto del modelado conceptual. Un antecedente en estalínea de pensamiento aparece en los patrones software de Coad en 1992 [47]. ParaCoad los objetos y las clases se corresponden con los elementos de bajo nivel de los que

2.4. Patrones Software 35

habla Alexander: “para encontrar un patrón sobre los elementos de bajo nivel (cla-ses y objetos) debemos observar las relaciones entre ellos”. Según Coad los métodosorientados a objetos “enfatizan ciertos patrones de relaciones, incluyendo generali-zación/especialización, todo-parte, asociación y envío de mensajes (interacción entreobjetos)”. Estas son las ideas que subyacen a la visión del término patrón concep-tual de este trabajo. Además, estos patrones conceptuales poseen una estructuray comportamiento especí…co del patrón o estructura conceptual que, si se es capazde identi…car y categorizar, servirá de ayuda al proceso de modelado, facilitando ladetección de dichos patrones en el dominio de la aplicación.La introducción del concepto de patrón conceptual constituye una contribución

de la tesis. Los patrones conceptuales desde nuestro punto de vista se ven como loselementos conceptuales de menor granularidad que conforman un patrón de análisis.

Patrones de Diseño

Quizás la de…nición que más se utilice en el mundo de los patrones para describir lo quees un patrón de diseño sea la que proponen Gamma et al. en su libro “Design Patterns,Elements of Reusable Object-Oriented Software” [78] y es la siguiente: “Descripcionesde objetos y clases que se comunican y que se han personalizado para resolver unproblema de diseño general en un contexto particular”.Un patrón de diseño nombra, abstrae, e identi…ca los aspectos clave de una es-

tructura de diseño común que sirve para construir diseños orientados a objetos reuti-lizables. Los patrones de diseño identi…can las clases y las instancias participantes,sus roles y colaboraciones, y la distribución de responsabilidades. Los patrones dediseño proporcionan código de ejemplo en lenguajes como C++, Java y Smalltalkpara ilustrar las implementaciones.Según Gamma un patrón de diseño se de…ne mediante cuatro elementos esenciales:

1. El nombre del patrón que se utiliza para describir un problema de diseño, sussoluciones y sus consecuencias en una o dos palabras. El darle nombre a unpatrón incrementa inmediatamente el vocabulario del desarrollador. Además,permite diseñar a un alto nivel de abstracción. Tener un vocabulario de patro-nes común permite la comunicación con otros desarrolladores e incluirlos en ladocumentación del software de forma natural.

2. El problema que describe cuando aplicar el patrón. Explica el problema y sucontexto. Debe describir problemas especí…cos de diseño. A veces el problemaincluirá una lista de condiciones que se deben cumplir para que se pueda aplicarel patrón.

3. La solución que describe los elementos que constituyen el diseño, sus relacio-nes, responsabilidades, y colaboraciones. La solución no describe un diseño ouna implementación en particular, porque el patrón es como una plantilla quepuede aplicarse en muchas situaciones diferentes. El patrón proporciona unadescripción abstracta de un problema de diseño y la distribución general de loselementos (clases y objetos en este caso) que lo resuelven.

4. Las consecuencias que son los resultados e inconvenientes de aplicar el patrón.Aunque las consecuencias no se comentan normalmente cuando se describen


decisiones de diseño, son muy importantes para evaluar las posibles alternativasde diseño y para entender los costes y los bene…cios de aplicar el patrón. Lasconsecuencias para el software normalmente se re…eren al consumo de espacioy tiempo. Pueden ser fundamentales en la decisión de qué lenguaje o de quétipo de implementación se elige. Además, desde que la reutilización es un factorde calidad de los diseños orientados a objetos, las consecuencias de un patrónincluyen su impacto en la ‡exibilidad, extensibilidad o portabilidad del sistema.Si estas consecuencias se listan de forma explícita, ayudarán a entender y evaluarlos patrones.

Los patrones de diseño juegan un papel muy importante en la producción de soft-ware actual. Son estructuras de diseño de calidad, con una elevada capacidad dereutilización y que están siendo altamente usadas por los desarrolladores. La incorpo-ración de patrones de diseño en los procesos de producción de software proporcionabene…cios considerables. En la propuesta que se presenta, los patrones de diseño sonla clave para:

² estructurar el proceso de generación automática de código,² de…nir correspondencias precisas entre patrones conceptuales y patrones de di-seño que representen dichas abstracciones en el espacio de la solución,

² constituir los elementos constructivos de las aplicaciones. Estos elementos seráncomponentes de alto nivel de abstracción, de calidad probada y bien documen-tados.

2.4.3 Lenguajes de Patrones

Cuando diversos patrones relacionados se utilizan juntos, constituyen un lenguaje depatrones [57, 142]. Éstos ayudan a los desarrolladores a comunicarse mejor, cubriendodominios y disciplinas especí…cos, como por ejemplo concurrencia, distribución, di-seño organizacional, comercio electrónico y diseño de interfaces hombre-máquina. Unlenguaje de patrones no suele ser un lenguaje formal; sin embargo es una colecciónestructurada de patrones relacionados que proporciona un vocabulario para hablarde un determinado problema. Estos lenguajes ayudan a los desarrolladores a comu-nicar su conocimiento sobre arquitecturas software, ayudan a los analistas a evitarproblemas y situaciones que otros han aprendido a partir de su propia experiencia, yayudan a los diseñadores a aprender nuevos diseños o estilos arquitectónicos.Últimamente, los lenguajes de patrones se están aplicando para:

² aprender a diseñar en equipo [232],² enseñar a escribir los propios lenguajes de patrones [144],² documentar soluciones organizacionales (como en el proyecto ELEKTRA [194]),² ayudar al proceso de Análisis de Requisitos10 (como se hace en los lenguajespresentados en [189], y RAPPeL [234]),

10Ésta es la vertiente más interesante para el trabajo que se presenta.

2.5. Descripción del Trabajo de Tesis 37

² traducir esquemas conceptuales a diseños orientados a objetos [118] (Caterpi-llar’s Fate), y

² de…nir procesos de desarrollo [56].Estas aproximaciones rati…can la vía de trabajo emprendida con esta tesis orien-

tada a usar los lenguajes de patrones como herramientas adecuadas para la de…niciónde guías de modelado para OO-Method.

2.5 Descripción del Trabajo de Tesis

Una vez introducido el contexto en el que se enmarca el trabajo de tesis, a continuaciónse presenta cómo se ha desarrollado éste. Para ello, se muestra el estado actual deOO-Method, y se expone cómo se incorporan, de forma disciplinada y sistemática,técnicas basadas en patrones que faciliten la construcción de un enfoque metodológicoque permita guiar el proceso de modelado conceptual y de generación de código deOO-Method, centrándose en el tratamiento completo de las relaciones taxonómicas,desde su especi…cación hasta su implementación.

2.5.1 OO-Method: Del Espacio del Problema al Espacio de laSolución

OO-Method [165, 168, 175] es un método OO de producción automática de soft-ware basado en técnicas de especi…cación formales, que utiliza una notación grá…cabasada en UML. OO-Method proporciona un enfoque metodológico que abarca laconstrucción del esquema conceptual (basado en los patrones conceptuales presentesen OASIS) y su correspondiente representación software en un entorno de desarrollo.Las características más destacables del método son:

² Una notación grá…ca para abordar la etapa de modelado conceptual. Estanotación está basada en el estándar notacional UML para que su uso resultefamiliar a los analistas de sistemas.

² OASIS [129, 176] como lenguaje de especi…cación formal OO que subyace almétodo. Los esquemas conceptuales representan conceptos soportados por ellenguaje. El lenguaje constituye un repositorio de alto nivel del sistema mode-lado.

² Un modelo de ejecución que de…ne el proceso de representación del esquemaconceptual en un entorno de desarrollo de software.

OO-Method aborda la tarea de construcción de software siguiendo dos fases biendiferenciadas (ver …gura 2.5):

1. Construcción de un Esquema Conceptual mediante un lenguaje grá…co queposee la expresividad necesaria para representar adecuadamente los conceptosdel modelo OO usado como soporte formal. Los conceptos asociados al modeloformal de OASIS determinan la información relevante a capturar en la fase demodelado conceptual en la cual se modela el sistema de información analizado


en el espacio del problema. El Esquema Conceptual permite representar laspropiedades estáticas y dinámicas que satisfacen los requisitos funcionales delsistema en desarrollo. Para ello, OO-Method proporciona una notación grá…caconstituida por tres modelos con los que recoger las propiedades relevantes deun sistema de información. Los diagramas asociados a cada uno de esos tresmodelos respetan y extienden la notación UML, aunque su semántica está con-cebida para declarar con precisión sólo aquel conjunto de información que searealmente necesaria para describir el sistema. Debido a la correspondencia exis-tente entre estos elementos grá…cos y el lenguaje de especi…cación subyacente,se puede obtener en cualquier momento una especi…cación formal del sistemaen el lenguaje OASIS. El Esquema Conceptual se sitúa en el Espacio delProblema.

Los tres modelos que proporciona OO-Method para la construcción del esquemaconceptual son los siguientes:

² Modelo de Objetos: es un modelo grá…co en el cual se de…nen las clases delsistema (incluyendo atributos, servicios y relaciones entre clases). Las relacionespueden ser de agregación (parte-de), especialización (es-un), y de agente (intro-ducidas para especi…car qué objetos están autorizados a activar los serviciosofrecidos por cada clase). Se utiliza una extensión del Diagrama de Clases deUML.

² Modelo Dinámico: es un modelo grá…co que permite especi…car las vidasválidas de los objetos de una clase y las interacciones entre objetos. Para ellose utilizan dos tipos de diagramas:

– Diagramas de Transición de Estados. Se utiliza para describir ge-néricamente la secuencia correcta de servicios en la vida de los objetos deuna clase y las precondiciones que habilitan su ocurrencia. Se utiliza unaextensión del Diagrama de Transición de Estados de UML.

– Diagrama de Interacción entre Objetos. Se utiliza para representarlas interacciones entre los objetos del sistema. En este diagrama se de-…nen dos mecanismos básicos de interacción: los disparos (servicios quese activan de forma automática como consecuencia del cumplimiento deuna condición sobre el estado de un objeto) e interacciones globales (tran-sacciones que involucran a servicios de diferentes objetos). Se utiliza unaextensión del Diagrama de Colaboración de UML.

² Modelo Funcional: es un modelo que se utiliza para capturar la semánticaasociada al cambio de estado de un objeto como consecuencia de la ocurrencia deun evento. El efecto de los eventos sobre el estado de los objetos se correspondecon un tipo de fórmula de evaluación en el marco lógico-dinámico en el que seformaliza OASIS, que se especi…ca de forma textual mediante una estrategiade clasi…cación de los atributos en categorías [173], asignándoles valor en funciónde los eventos ocurridos. Ésta es una aportación importante del método, quefacilita la generación de forma automática de una especi…cación completa enOASIS.


ModeladoConceptual

OASIS

Objetos Dinámico

Funcional

Nivel Interfaz (Entornos Visuales, WEB)

Nivel Aplicación (COM/DCOM y CORBA)

Nivel Persistencia (Oracle, SQL Server)

Modelo deEjecución

Espacio del Problema

Espacio de la Solución

Traducción Automática

Figura 2.5: Fases de OO-Method

2. Aplicación de un Modelo de Ejecución al Esquema Conceptual obtenido.Este Modelo de Ejecución …ja los detalles para la implementación de una re-presentación concreta de un Esquema Conceptual en un entorno de desarrollo.Para ello utiliza una estrategia de generación de código que permite obtener pro-gramas que sean funcionalmente equivalentes al esquema conceptual, de…niendouna correspondencia entre los elementos del modelo conceptual y su represen-tación en el lenguaje de programación elegido [80]. El Modelo de Ejecuciónestá situado en el Espacio de la Solución.

Aplicación de Patrones en OO-Method

La aplicación de técnicas basadas en patrones software en las distintas etapas delproceso de desarrollo, a diferentes niveles de abstracción, puede aportar importantesbene…cios a OO-Method. OO-Method es un marco interesante para la búsqueda yaplicación de patrones, ya que los conceptos utilizados para especi…car los sistemas(clases, agregación, especialización, técnicas de comunicación, comportamiento, etc.)poseen una semántica bien de…nida y las aplicaciones que se desarrollan son de undominio especí…co (aplicaciones de gestión). Esto facilita la detección de patrones demodelado, la generación de la arquitectura de la aplicación y, el diseño y desarrollode los componentes software necesarios para implementar completamente el esquemaconceptual, obteniendo una aplicación que cumpla con la funcionalidad especi…cada.


La incorporación de patrones al método ayudará a la construcción de herramientasde modelado activas11 y de generadores de código, proporcionando una estructuracióndel proceso de desarrollo que facilitará su completa automatización. Estas ideas per-mitirán abordar el proceso de desarrollo de software como la aplicación sistemática yde manera automatizada de una serie de técnicas basadas en patrones. Los patronesse aplicarán en las distintas etapas del proceso de desarrollo, y se de…nirán dependen-cias y correspondencias precisas entre los distintos patrones presentes en cada etapa.Estas correspondencias facilitarán la transición automática del espacio del problemaal espacio de la solución.En los dos siguientes apartados se esboza de qué forma se van a incorporar los

patrones en las etapas de Modelado Conceptual y cómo se aplican en el Modelo deEjecución de OO-Method.

2.5.2 Patrones en el Modelado Conceptual

En la etapa de modelado conceptual el analista debe identi…car y capturar las ocurren-cias de patrones estructurales y de comportamiento existentes en el dominio estudiado.En la aproximación que se presenta en esta tesis a estos patrones se les llaman pa-trones conceptuales. Si a este término se le aplica la de…nición genérica de patrón,propuesta por Fowler en [75], en el contexto del modelado conceptual, el concepto depatrón puede considerarse como “una solución genérica (de modelado) a un proble-ma (especi…car un patrón estructural y de comportamiento detectado en cualquierdominio de aplicación) en un determinado contexto (el analista es capaz de detectar yespeci…car el patrón)”. Los patrones conceptuales son los componentes/constructoresbásicos a partir de los cuales se construye un esquema conceptual.Los patrones conceptuales de OO-Method están basados en las abstracciones que

ofrece el lenguaje de especi…cación OASIS. Estas abstracciones poseen una semán-tica bien de…nida [129], por lo que, su utilización como base para determinar y espe-ci…car los patrones conceptuales que proporciona OO-Method, ofrece construccionesconceptuales precisas para modelar los elementos del dominio de aplicación.

Relaciones Taxonómicas como Patrones Conceptuales

Debido a la extensión necesaria y a la complejidad que conlleva el tratamiento com-pleto de cada uno de los patrones conceptuales presentes en la aproximación OO-Method, es recomendable centrarse en un patrón conceptual en concreto y mostrardetalladamente las ideas propuestas. El resultado de este trabajo se extenderá al restode patrones conceptuales con la intención de construir un método de generación decódigo completo.OO-Method proporciona diversos patrones conceptuales, de entre ellos, las relacio-

nes taxonómicas constituyen un patrón interesante de tratar debido a la ambigüedady super…cialidad con la que se trata en la mayoría de métodos de modelado OO. Enesta tesis se introduce un nuevo modelo de relaciones taxonómicas para OO-Method,basado en (una versión extendida de) OASIS 3.0, mucho más expresivo que la exis-tente actualmente (versión OASIS 2.2), y se realiza un tratamiento exhaustivo de11Término introducido por Jarzabeck en [114] y que caracteriza a las herramientas CASE que

ayudan al usuario en el proceso de modelado.


dichas relaciones. El tratamiento aborda todo el proceso de producción de softwareaplicando técnicas basadas en patrones. El hecho de proponer un nuevo patrón con-ceptual en OO-Method, permite presentar como aportación del trabajo de tesis todoel proceso de introducción de un modelo de relaciones taxonómicas a un método OOde producción de software. Esto se llevará a cabo integrando técnicas formales consemi-formales y, adaptando la notación de modelado UML para dar soporte a nivelgrá…co al patrón conceptual.

Lenguajes de Patrones como Guías de Modelado

Los patrones conceptuales necesitan guías precisas que faciliten su identi…cación yespeci…cación detallada durante la etapa de modelado conceptual. Las técnicas basa-das en patrones se están utilizando también para de…nir guías metodológicas. Comoparte del trabajo de tesis se desarrollará una guía de modelado mediante un lenguajede patrones.Para la construcción del lenguaje de patrones se llevará a cabo un proceso de

análisis y abstracción de las características esenciales (a nivel de estructura y com-portamiento) que poseen los distintos tipos de relaciones taxonómicas presentes enlas técnicas de especi…cación formales y semi-formales. A partir del estudio realizadose propondrá un marco de referencia independiente del dominio que identi…cará cadauna de las características que poseen los patrones conceptuales en cuestión.Las características detectadas representarán un conjunto de patrones estructura-

les o de comportamiento básicos, detectables en el dominio de la aplicación. Esteconjunto de patrones servirá para caracterizar los patrones conceptuales, de maneraque el problema de detectar y especi…car un patrón conceptual se convertirá en unproceso de detección y especi…cación de cada uno de los patrones estructurales y decomportamiento que lo de…nen.En esta tesis se desarrolla un lenguaje de patrones para las relaciones taxonómicas

de OO-Method. Los patrones que forman el lenguaje son cada una de las característi-cas detectadas en el marco de referencia. Las características del marco son genéricaspor lo que para que sean aplicables en la identi…cación y especi…cación de las relacio-nes taxonómicas introducidas en esta tesis, se instanciarán para el modelo taxonómicointroducido.El lenguaje de patrones guiará el proceso de especi…cación del patrón conceptual.

De esta forma el proceso de modelado de un patrón conceptual se de…nirá como laaplicación sistemática de un conjunto de patrones que ante un problema de modeladoen un contexto determinado (en este caso, la identi…cación de cierta estructura ocomportamiento existente en el dominio del problema), ofrecerá una solución (demodelado) que determinará cada una de las características esenciales que debe poseerel patrón conceptual.El lenguaje de patrones ayudará a especi…car de forma precisa los patrones con-

ceptuales de OO-Method, facilitando la construcción de herramientas de ayuda a latoma de decisiones en el modelado. En el caso de las relaciones taxonómicas estasherramientas facilitarán la tarea de razonamiento taxonómico [27] o la clasi…caciónautomática12. Un razonador taxonómico encuentra todas las relaciones Es-Un entre

12Es la determinación correcta del espacio en el que se sitúa una clase en una taxonomía, no sedebe confundir con la clasi…cación como mecanismo de abstracción en el modelado conceptual.


Herramienta deModelado

Lenguaje de Patronespara la identificación

de PatronesConceptuales

Especificacióndel Sistema

(Esquema Conceptual)

Especificación dePatrones

Conceptuales

Ayuda al Proceso deModelado

Tomar Decisiones deModelado

Ayuda a

Descripción del Sistema

Análisis de Requisitos


Basado En

Lenguaje deEspecificación

OASIS

Define

CaracterísticasEstructurales y deComportamiento

(MARCO)

Poseen

Constituyen

Figura 2.6: Patrones en la Etapa de Modelado Conceptual

una clase nueva y una taxonomía de clases dada, mediante el descubrimiento de re-laciones Es-Un implícitas en la descripción del dominio. En la …gura 2.6 se observacómo se va a introducir en OO-Method este nuevo enfoque de modelado. Las abstrac-ciones presentes en el lenguaje OASIS de…nen los patrones conceptuales presentesen OO-Method. Éstos a su vez poseen una serie de características estructurales yde comportamiento que constituyen un marco conceptual. El lenguaje de patronesse construye basándose en las características detectadas en el marco. Este lengua-je ayuda al modelador a tomar decisiones de modelado a través de la identi…cacióny especi…cación detallada de patrones conceptuales, ayudando a la construcción delesquema conceptual.

Con esta nueva aproximación el problema de detectar y especi…car un patrónconceptual se convertirá en un proceso de resolución de un determinado número desubproblemas relacionados. Cada subproblema será la detección y especi…cación deuna característica del patrón conceptual. Esta propuesta se puede extender a cadapatrón conceptual presente en OO-Method, de…niendo un lenguaje de patrones queestará constituido por cada una de las posibles características estructurales y decomportamiento detectables de cada patrón conceptual, donde cada característica serepresentará mediante un patrón del lenguaje.

En el siguiente apartado se presenta cómo se introducen las técnicas basadas enpatrones en el Modelo de Ejecución, para mejorar el proceso de generación de códigoy la calidad del código generado.


2.5.3 Patrones en el Modelo de Ejecución

Una vez construido el Esquema Conceptual del sistema a desarrollar, la siguiente eta-pa en el proceso de desarrollo propuesto por OO-Method consiste en la aplicación deun Modelo de Ejecución (ME) a la especi…cación del sistema. La etapa de aplicacióndel ME es esencial para realizar la transición del espacio del problema al espaciode la solución de forma sistemática y automatizada, …jando los detalles para la im-plementación de una representación concreta del Esquema Conceptual en un entornode desarrollo. El ME que se presenta en esta tesis constituye una extensión del modelointroducido inicialmente en OO-Method [171]. El Modelo de Ejecución Exten-dido (MEE) que se propone, establece a partir de la especi…cación del sistema, unarepresentación software completa del esquema conceptual en un entorno de des-arrollo cualquiera, incorporando técnicas basadas en patrones de diseño. Se considerauna representación completa porque aborda la generación de los aspectos estáticos ydinámicos de los esquemas conceptuales.Para conseguir dicho propósito el MEE proporciona dos elementos importantes:

² una arquitectura software para estructurar la aplicación a desarrollar, mediantela utilización de patrones arquitectónicos, y

² una estrategia de generación de código para obtener cada una de las cla-ses13 de la arquitectura. Esta estrategia se basa en:

– La aplicación de un conjunto de patrones de diseño especializados queactúan como puente (mecanismo de enlace) entre los patrones conceptualesy su representación software. La utilización de patrones de diseño introdu-ce estructuras de diseño de calidad en el proceso de producción de software.Estos permitirán representar adecuadamente los patrones conceptuales es-peci…cados en el esquema conceptual. Para la implementación de las clasesque representan a los patrones conceptuales se de…nirán correspondenciasentre cada uno de los elementos estructurales y de comportamiento quede…nen el patrón conceptual y los patrones de diseño especializados. Estascorrespondencias se acompañarán de guías precisas con un nivel de abs-tracción su…ciente para ser aplicadas en distintos entornos de desarrollo.No se asume, de manera implícita, que siempre existen patrones de diseñoque pueden especializarse para implementar el patrón conceptual. En elcaso de no existir, se deben proponer nuevos patrones de diseño.

– La aplicación de una estrategia de ejecución que han de seguir los ob-jetos del sistema para implementar su comportamiento, preservando lasemántica asociada al modelo de objetos subyacente a OO-Method.

Arquitectura de la Aplicación y Patrones Arquitectónicos

El primer elemento del MEE estructura la aplicación mediante un patrón arqui-tectónico que se adapte a las características del tipo de aplicación. Actualmentela arquitectura multinivel es el patrón que se utiliza en la aproximación OO-Method

13La aproximación que se presenta genera código OO. En un aproximación orientada a componentesestas clases se utilizarán para implementar los interfaces objetuales [220] de los componentes software.


por ser uno de los más extendidos en las aplicaciones de gestión. Esta arquitecturaparticiona el sistema en tres niveles lógicos:

² El nivel de presentación: este nivel constituye la representación visual dela aplicación, proporcionando a los usuarios …nales una forma de acceder a losdatos y controlar la funcionalidad. La aproximación que se presenta permitela generación automática de la interfaz de usuario, estableciendo una corres-pondencia entre los elementos de la interfaz y los objetos de negocio [19]. Estaaproximación es interesante si se analizan los estudios realizados sobre desarro-llos reales [124, 125], en los cuales los usuarios ven interesante el poder percibirla estructura del problema en sus ventanas.

² El nivel de aplicación: en este nivel se sitúan las clases14 que implementanel comportamiento de las clases especi…cadas en la fase de modelado concep-tual. La implementación de estas clases se realiza de forma que se asegure laequivalencia funcional entre la descripción del sistema y su rei…cación en unlenguaje de programación, garantizando que se ofrece la funcionalidad especi-…cada en la fase de modelado para cada una de las clases. Se garantizará queel comportamiento del objeto ante una petición de servicio será el de…nido enla especi…cación del problema de acuerdo a la estrategia de ejecución quedeterminará los pasos y las comprobaciones a seguir para ejecutar un serviciode un objeto.

² El nivel de persistencia: en este nivel se sitúan las clases que encapsulanel acceso a los servidores de datos, junto con la base de datos que soporta lapersistencia de los objetos de la aplicación. Actualmente, en las aplicacionesde gestión, los datos se almacenan habitualmente en SGBDR o sus extensionesobjeto-relacionales, por lo que a partir del esquema conceptual construido, segenera un esquema de base de datos de este tipo.

La elección de este patrón se justi…ca gracias al elevado grado de independenciaexistente entre los componentes de los distintos niveles, ya que son arquitecturas cerra-das15[195], reduciendo las dependencias entre niveles y permitiendo que los cambiosse hagan con facilidad porque la interfaz de una de ellas sólo afecta al nivel siguiente.Estas arquitecturas permiten estructurar adecuadamente la aplicación en tres nive-les lógicos con una funcionalidad independiente y bien diferenciada, lo que facilita ladivisión adecuada de los esfuerzos de codi…cación y la especialización del trabajo dedesarrollo.Seleccionar un patrón arquitectónico es sólo el primer paso en el proceso de gene-

ración de código. El patrón arquitectónico es un marco de trabajo estructural para unsistema software que debe ser re…nado. Por ello, es necesario integrar la funcionalidaddentro de la arquitectura y generar automáticamente sus componentes. De esta partese encargará la estrategia de generación de código.

14Estas clases se están utilizando actualmente para implementar los interfaces de “componentesde negocio” (término propuesto por Orfali et al. [157]) del tipo EJB y COM+.15Un nivel sólo utiliza características de su nivel inmediatamente inferior.


Estrategia de Generación de Código

La estrategia de generación de código permite obtener de forma sistemática lasclases que implementan cada uno de los niveles de la arquitectura propuesta, de…nien-do las correspondencias necesarias entre los patrones conceptuales y su representaciónen un entorno de desarrollo determinado. Para de…nir estas correspondencias se uti-lizarán patrones de diseño junto con una estrategia de ejecución, y se explicará cómose integran estas técnicas con el …n de conseguir un producto software funcionalmenteequivalente a la especi…cación del sistema.La entrada de la estrategia de generación de código será la especi…cación (en

modo grá…co y textual) de un conjunto de patrones conceptuales basados en conceptosOASIS (clases simples, agregación, especialización estática y dinámica, clases de rol).Dicha especi…cación es la resultante de la fase de modelado conceptual realizada en elámbito del espacio del problema. La estrategia de generación de código estaráconstituida por las siguientes etapas (ver Figura 2.7):

1. Selección y especialización de patrones de diseño. Una de las premisasmás importantes en el proceso de producción de software a…rma que “se de-be asegurar que el software se estructura de la misma forma que los modelosconceptuales, siempre que sea (prácticamente) posible” [75], por lo que en estaprimera etapa, se buscarán y/o crearán16 patrones de diseño que permitan re-presentar …elmente los patrones conceptuales en el espacio de la solución. Laselección de los patrones de diseño se basará en su grado de adecuación pararepresentar los conceptos OASIS presentes en los patrones conceptuales. Lospatrones de diseño obtenidos se adaptarán/especializarán de forma que se ob-tengan una serie de patrones de diseño especializados que permitan trasladar…elmente los patrones conceptuales a dichas estructuras de diseño. En esta eta-pa es necesario tener un idea clara de las posibles correspondencias entre lospatrones conceptuales y de diseño.

2. Representación de los patrones conceptuales preservando su semán-tica. Se de…nirán un conjunto de correspondencias precisas entre los patronesde diseño especializados y los patrones conceptuales en el espacio del problema,determinando:

(a) La estructura de clases del espacio de la solución que implementan alas clases en el espacio del problema, de…niendo cuál es la distribución deatributos, los métodos que implementarán, y cómo se crearán y destruiránlos objetos.

(b) La implementación del comportamiento asociado a la ejecución de unservicio. Un elemento clave en la estrategia de generación de código es laestrategia de ejecución. La estrategia de ejecución representa detalla-damente el conjunto de acciones a realizar para la ejecución de un servicio.Esta estrategia depende de la semántica del modelo de objetos y determi-na cómo se comportan los objetos de una sociedad de objetos especi…cada

16Es posible que no exista ningún patrón de diseño que permita representar la abstracción con-ceptual, por lo que deberá crearse.


según el modelo OASIS. Esta estrategia constituirá la base para la gene-ración del comportamiento de los componentes del nivel de aplicación, yservirá para garantizar que el resultado de la implementación de un serviciose corresponde con el efecto especi…cado en el esquema conceptual. SegúnOO-Method, la ejecución de un servicio seguirá la secuencia de accionesque se presentan a continuación:

i. Transición válida de estado: se veri…cará en el diagrama de tran-sición de estados (el proceso que de…ne en OASIS las posibles vidasde un objeto) que exista una transición válida para el servicio selec-cionado.

ii. Satisfacción de precondición: se comprobará que se cumpla laprecondición asociada al servicio en ejecución (si existe). Si no secumplen (i) y (ii) se elevará una excepción informando que el serviciono puede ejecutarse.

iii. Evaluaciones: se modi…carán los valores de los atributos afectadospor la ocurrencia del servicio.

iv. Comprobación de las restricciones de integridad: las evaluacio-nes del servicio deben dejar al objeto en un estado válido. Se comprue-ba que no se violan las restricciones de integridad. Si alguna de ellasse viola, se generará una excepción y el cambio de estado producido seignorará.

v. Comprobación de las relaciones de disparo: después de un cam-bio de estado válido, y como acción …nal, se debe veri…car el con-junto de reglas condición-acción que representa la actividad internadel sistema. Si alguna de ellas se cumple, se activará el servicio co-rrespondiente.

Cuando …nalicen con éxito las acciones precedentes, se dará por terminada laejecución del servicio y tendrá lugar de forma irreversible el cambio de estado en elobjeto. Los pasos anteriores guiarán la implementación de cualquier servicio para ase-gurar la equivalencia funcional entre la descripción del sistema recogida en el modeloconceptual y su rei…cación en un entorno de programación de acuerdo con el modelode ejecución.Las etapas de selección y especialización de patrones de diseño (etapa 1) y de

representación de los patrones conceptuales preservando su semántica (etapa 2), sedesarrollan en esta tesis para las relaciones taxonómicas de OO-Method. Estas etapasconstituyen la estrategia de generación de código que sirve como base para la construc-ción de generadores de código que automaticen el proceso de producción de software.Los generadores de código tomarán un esquema conceptual como especi…cación fuentey generarán código que sea consistente con la semántica de los patrones conceptualespresentes en el esquema. El código se obtendrá aplicando a los patrones conceptua-les incluidos en un esquema conceptual, los patrones de diseño especializados y lascorrespondencias de…nidas.En este trabajo, se presenta cómo obtener las clases de los distintos niveles de

la arquitectura propuesta, centrándose en la generación de las clases del nivel deaplicación, que implementan de forma completa la estructura y el comportamiento delos patrones conceptuales especi…cados en el modelo conceptual. La implementación


ESPACIO DEL PROBLEMA(Especificación de Patrones Conceptuales)

ESPACIO DE LA SOLUCIÓN(Implementación de Patrones Conceptuales)

PATRONESDE DISEÑO

Detección dePatrones Conceptuales

Relaciones Estructurales y de Comportamiento

OASIS

Especialización,Extracción yAdaptación

PATRONESDE DISEÑO

ESPECIALIZADOS

DefinirCorrespondencias

Obtener

Estrategiade Ejecución

Basados en

RelacionesEstructurales

Comportamiento

Figura 2.7: Aplicación de Patrones de Diseño en el Proceso de Generación de Código

del nivel de aplicación constituye una parte muy importante del software de un sistemaporque es donde se implementan los requisitos funcionales de la aplicación. El procesode desarrollo que se introduce en la tesis pretende dar solución a la falta de rigorque presentan los métodos y entornos actuales en la de…nición de los elementos delmodelado conceptual, y a la incapacidad de generar automáticamente los objetos delnegocio, garantizando que dicha implementación es funcionalmente equivalente a ladescripción capturada en el esquema conceptual.

2.5.4 Contribuciones

Una vez se ha esbozado el trabajo que se desarrolla en esta tesis, para …nalizar elcapítulo se presentan las principales contribuciones que aporta.El trabajo de tesis:

² Desarrolla un marco de referencia que sirve para caracterizar los distintos ti-pos de relaciones taxonómicas existentes a nivel de modelado conceptual OO.Para su construcción se han estudiado las características esenciales de los distin-tos tipos de relaciones taxonómicas y se han analizado las diversas propuestasexistentes.


² Introduce en OO-Method un nuevo modelo formal de relaciones taxonómicasbasado en OASIS. Éstas constituyen un conjunto de patrones conceptualesque permiten describir de forma no ambigua elementos del dominio presentesen los esquemas conceptuales OO.

² Integra técnicas formales (OASIS) y semi-formales (UML) desarrollando unanotación grá…ca basada en UML para dar soporte grá…co (a nivel estructural yde comportamiento) a los nuevos patrones conceptuales.

² Propone un lenguaje de patrones que sirve como guía precisa de ayuda al mo-delado de relaciones taxonómicas. Este lenguaje se construye basándose en elmarco propuesto y en las características del modelo taxonómico de…nido.

² Construye una estructura navegacional basada en preguntas que guiará la espe-ci…cación completa de las relaciones taxonómicas ofreciendo un soporte meto-dológico a OO-Method. Esta estructura de navegación se inducirá a partir dellenguaje de patrones propuesto.

² Analiza el conjunto de técnicas de implementación y patrones de diseño que sepueden aplicar para abordar la generación de código de las relaciones taxonómi-cas.

² De…ne un proceso de selección y especialización de patrones de diseño parala implementación de relaciones taxonómicas en la estrategia de generación decódigo.

² Propone un proceso completo de generación automática de código utilizandotécnicas basadas en patrones de diseño. En este proceso se de…nen correspon-dencias precisas entre los distintos tipos de relaciones taxonómicas presentes enel espacio del problema y un conjunto de patrones de diseño especializados. Deesta forma se obtendrá código de calidad que represente …elmente a las relacionestaxonómicas en el espacio de la solución.

En la …gura 2.8 se presenta una visión general del trabajo de tesis en cada una delas etapas de OO-Method.Con estas contribuciones el trabajo de tesis pretende automatizar el proceso de

producción de software, desde el modelado conceptual (mediante técnicas de ayuda ala toma de decisiones de modelado) hasta la implementación (mediante generadoresde código). Esto permitirá orientar el proceso de desarrollo de software hacia tareasde alto nivel de abstracción ocultando adecuadamente la complejidad tecnológica.

2.6 Conclusiones

En este capítulo se ha presentado el contexto tecnológico en el que se sitúa el trabajoque se desarrolla en esta tesis. A lo largo del capítulo se ha analizado la tecnologíasoftware relacionada directamente con el problema que se resuelve, con la intenciónde facilitar el entendimiento de la solución propuesta.En primer lugar se ha estudiado la importancia que tiene el Modelado Conceptual

OO en el desarrollo del software. En la etapa de modelado se ha detectado la necesidad

2.6. Conclusiones 49

Modelado Conceptual

OASIS IGU

Elicitación de Requisitos(Casos de Uso)

Repositorio

Modelo deNegocio

Modelo dePresentación

ModeloNavegacional

Patrones deInteracción

yVistas

Objetos Dinámico

FuncionalUsa

Obtiene

Nivel Interfaz (Entornos Visuales, WEB (HTML, Applets))



Modelo deEjecución



Marco Metodológico parala Identificación de


Documentación y Especificación de


Especialización yAdaptación de

Patrones de Diseño

Implementación SW

Definir Correspondencias

Modelado Conceptual

OASIS IGU

Elicitación de Requisitos(Casos de Uso)

Repositorio

Modelo deNegocio

Modelo dePresentación

ModeloNavegacional

Patrones deInteracción

yVistas

Objetos Dinámico

FuncionalUsa

Obtiene

Nivel Interfaz (Entornos Visuales, WEB (HTML, Applets))



Modelo deEjecución



Marco Metodológico parala Identificación de


Documentación y Especificación de


Especialización yAdaptación de

Patrones de Diseño

Implementación SW

Definir Correspondencias

Figura 2.8: El trabajo en cada una de las fases de OO-Method


de ofrecer patrones conceptuales expresivos que faciliten el proceso de modelado. Eneste contexto, las Relaciones Taxonómicas constituyen un conjunto de patrones con-ceptuales interesantes de estudiar, debido a la gran cantidad de modelos taxonómicosexistentes en la literatura que no ayudan a entender y aplicar adecuadamente dichaabstracción.Para abordar de forma precisa el estudio de las relaciones taxonómicas se ha

considerado adecuado utilizar Técnicas Formales como herramientas para de…nir susemántica, aunque en la práctica estas técnicas no se utilicen ampliamente. Una delas aproximaciones que favorece su utilización es la integración de Técnicas Formales(como los lenguajes de especi…cación formal) y Semi-Formales (como las técnicasde modelado conceptual convencionales). Debido a la importancia que tiene en latesis esta combinación de técnicas, en este capítulo se han analizado un conjunto depropuestas conocidas en el ámbito del modelado conceptual OO, y se ha esbozado lapropuesta que se sigue, integrando OASIS y OO-Method.La siguiente área tecnológica en la que también se enmarca el trabajo de tesis es

la Generación de Código basada en Modelos. Para situarlo adecuadamente, se hapresentado una visión general de las aproximaciones existentes. Una de las técnicassobre las que se sustenta el nuevo proceso de generación de código propuesto en latesis son los Patrones Software. Para conocer mejor este tipo de técnicas y en quéámbito son aplicables, se ha realizado un estudio indicando los bene…cios que puedeaportar su incorporación en un método de producción de software.Para …nalizar, se ha presentado de forma general el trabajo desarrollado en la tesis

y sus aportaciones, explicando cómo se combinan adecuadamente las técnicas analiza-das en este capítulo para conseguir los objetivos propuestos. La aproximación integratécnicas formales (utilizando el lenguaje OASIS como herramienta para la de…niciónprecisa de las relaciones taxonómicas) y semi-formales (notación grá…ca basada enUML), incorpora técnicas basadas en patrones software en las etapas de modeladoconceptual y generación de código, proporcionando un tratamiento completo de lasrelaciones taxonómicas (desde su especi…cación hasta su implementación) en el con-texto de OO-Method. Para cerrar el capítulo, es importante resaltar que las ideasque introduce esta tesis están orientadas a facilitar la construcción de generadoresde código, aunque se pueden utilizar cómo una propuesta sistemática de proceso dedesarrollo no necesariamente automatizado.

Capítulo 3

Trabajos Relacionados

En este capítulo se analizan las características de los trabajos relacionados, conside-rados más relevantes en las áreas de trabajo que trata esta tesis, y se comparan conlas soluciones y aportaciones propuestas. La solución desarrollada en este trabajoabarca el tratamiento de las relaciones taxonómicas desde las etapas iniciales de unproceso de desarrollo OO (situadas en el Espacio del Problema) hasta las etapas dediseño e implementación (situadas en el Espacio de la Solución), proporcionando unmétodo de producción automática de software basado en patrones. Siguiendo estaslíneas de trabajo, el capítulo se estructura en tres apartados. El primero presentaaquellas aproximaciones que tratan las relaciones taxonómicas en el Espacio del Pro-blema, analizando los trabajos realizados a nivel metodológico y a nivel de modeladoconceptual OO. El segundo apartado presenta aquellas aproximaciones que abordanel tratamiento de las relaciones taxonómicas en áreas de trabajo cercanas el Espaciode la Solución, como son las técnicas de implementación basadas en patrones de di-seño, y los lenguajes de programación OO y sus extensiones. Por último, el tercerapartado revisa aquellas propuestas de métodos de producción automática de soft-ware que proporcionan enfoques que podrían considerarse similares al introducido eneste trabajo.

3.1 Relaciones Taxonómicas en el Espacio del Pro-blema

El tratamiento de las relaciones taxonómicas en el Espacio del Problema abarca di-versas áreas de estudio como la Ontología1 , la Representación del Conocimiento, losMétodos Formales y el Modelado Conceptual OO. El análisis de los trabajos másrelevantes en estas áreas se va a realizar centrándose en dos aspectos importantes: losaspectos metodológicos (en el sentido del conjunto de métodos, reglas o postuladosempleados por la disciplina del modelado conceptual OO para identi…car y especi…caradecuadamente relaciones taxonómicas) y la de…nición de los distintos modelos derelaciones taxonómicas presentes en los métodos de modelado conceptual OO.

1Según [13] es la rama de la …losofía que trata con el orden y la estructura de la realidad en elsentido más amplio posible.

51

52 Capítulo 3. Trabajos Relacionados

3.1.1 Aspectos Metodológicos

En la literatura existen diversas propuestas que aportan un contenido metodológicoal tratamiento de las relaciones taxonómicas en el espacio del problema.Desde una perspectiva …losó…ca, en el área de la Ontología existen trabajos que

analizan de forma abstracta la naturaleza y las características esenciales de las rela-ciones taxonómicas, incorporando reglas de modelado y técnicas de clasi…cación paraayudar a construir modelos taxonómicos de calidad (a nivel semántico y práctico).En este ámbito los trabajos de Guarino constituyen un marco interesante para

comprender la naturaleza de las relaciones taxonómicas. En [92] las relaciones taxo-nómicas se analizan desde una perspectiva ontológica. Comenta Guarino que “unataxonomía bien de…nida posee importantes implicaciones para su entendimiento y re-utilización, aunque la especialización parezca una relación simple e intuitiva, se hausado de forma errónea en muchísimas situaciones, lo que ha llevado a la necesidadde proponer técnicas de análisis rigurosas que propugnen un uso adecuado de la rela-ción”. Este análisis se basa en cuatro nociones de la Ontología Formal introducidasen [89, 90, 91]: identidad, dependencia, rigidez, y unidad. Estas nociones se utilizanpara fundamentar un método para el modelado conceptual que incorpora una seriede preguntas a realizar por el modelador. Estas preguntas analizan las relacionestaxonómicas presentes en un esquema conceptual desde el punto de vista ontológico,reestructurándolas para mejorar su calidad semántica. Esta aproximación posee unadiferencia de enfoque respecto a la que se propone en la tesis, porque el análisis serealiza sobre una estructura taxonómica ya construida. El proceso introducido en estatesis, además de permitir el análisis de una estructura existente, ayuda al modeladoren la construcción de estructuras taxonómicas, teniendo en consideración no sólo fac-tores basados en la naturaleza de las relaciones, sino también factores estructurales yde comportamiento de las clases participantes en la relación.En estas propuestas se destaca el tratamiento que Guarino hace de las nociones de

identidad y rigidez, proporcionando un marco conceptual para entender la naturalezade la relación de identidad entre objetos. Este marco se utiliza en la tesis para resolveralgunos problemas existentes en la identi…cación de las subclases, por ejemplo, cuandose dan situaciones de modelado en las que un objeto puede especializarse en más deun objeto de una subclase al mismo tiempo. En estas situaciones es necesario quelas subclases proporcionen su propio identi…cador diferente al de la superclase, peroesto no es conceptualmente posible ya que un mismo objeto no puede identi…carse deforma distinta. Esto lo justi…ca Guarino de…niendo una relación de identi…caciónllamada Condición de Identidad (CI) que pueden “llevar” o “proporcionar” los obje-tos, junto a la noción de rigidez. Intuitivamente, un objeto persona es rígido porqueserá instancia de la clase Persona en cualquier estado posible; un estudiante normal-mente no es rígido, ya que un objeto puede abandonar la clase Estudiante siendo elmismo objeto. En esta formulación es necesario distinguir entre proporcionar una CIo llevar una CI: las clases no-rígidas como Estudiante sólo llevan sus CI, heredandolas CI proporcionadas por las propiedades rígidas de Persona. En el caso del ejemplopropuesto, como una misma persona puede ser estudiante en diferentes ocasiones yen diferentes escuelas, entonces el CI que lleva Estudiante sólo podrá ser local (enuna cierta experiencia como estudiante), y además Persona deberá proporcionar unacondición global de identi…cación heredándola Estudiante.Guarino en otro de sus trabajos [88] desarrolla las ideas de Sowa [212] introdu-

3.1. Relaciones Taxonómicas en el Espacio del Problema 53

ciendo una distinción entre los conceptos ontológicos de rol y tipos naturales. Estetrabajo se utiliza como marco de referencia para comprender la naturaleza de lassubclases estáticas y dinámicas, y de los roles del modelo de relaciones taxonómicasintroducido en esta tesis. Un rol según Guarino es un concepto fundado que carecede rigidez semántica. Por ejemplo, para que un concepto sea un rol se requiere quesus individuos estén en relación con otros individuos, y que puedan participar y dejarla extensión del concepto sin perder su identidad. Un tipo natural por otra parte secaracteriza por tener rigidez semántica y no ser un concepto fundado: un individuo deun tipo natural no puede cambiar su tipo sin perder su identidad y para un individuoque pertenezca al tipo no se le exige que esté relacionado con otros. Por ejemplo, unaPersona es un tipo natural, debido a que un individuo cualquiera si es una persona,permanecerá siempre siendo una persona, y el ser una persona es independiente de laexistencia de cualquier relación. Estudiante por otro lado es un rol debido a que serequiere que una Persona para ser estudiante se debe matricular en la universidad,y el hecho de …nalizar los estudios no le lleva a perder la identidad como persona.Es importante destacar que Adolescente y Adulto no poseen ni rigidez semántica nifundamento, son estados o fases de la vida de un individuo (lo que en la propuestapresentada en esta tesis se llaman subclases dinámicas).Se detecta, como puntos débiles de esta aproximación, que no trata de profundizar

en la semántica de las relaciones, por lo que no proporciona modelos de relacionestaxonómicas expresivos, no trata las relaciones estructurales y de comportamientoentre los objetos relacionados (a los que llama propiedades), y por último, estas ideasno se aplican a métodos de modelado conceptual actuales, ni se analiza la repercusiónde sus propuestas en el diseño del sistema a implementar.Continuando en el mundo de las ontologías aplicadas al modelado conceptual,

Parsons y Wand han desarrollado trabajos interesantes en el ámbito de la teoría dela clasi…cación.En [161], los autores recurren a la psicología cognitiva, la ontología y los trabajos

en redes semánticas, para proponer reglas que ayuden a abordar el proceso de clasi…-cación. En estos trabajos se presentan principios interesantes como los de abstraccióna partir de instancias y de abstracción maximal para identi…car clases, y principioscomo la completitud y la no redundancia para ayudar en la construcción de estructu-ras de clases y especializaciones. Además, introducen conceptos como la inferencia yla economía cognitiva para medir la calidad de los esquemas conceptuales.En [162] se analizan los conceptos básicos de la orientación a objetos desde un

punto de vista ontológico. Se determina la naturaleza de conceptos como la identi-dad, encapsulación, persistencia, homogeneidad, clasi…cación/instanciación, especia-lización/herencia, composición, comunicación/interacción, concurrencia, relaciones,polimor…smo, enlace dinámico, y sus implicaciones en el proceso de modelado con-ceptual, constituyendo un buen punto de partida para que el modelador comprendacómo utilizar estos conceptos y el efecto que puede tener su correcta utilización en lacalidad del modelo obtenido.De nuevo, al igual que en las propuestas anteriores, en éstas no se presentan aplica-

ciones de la ideas introducidas sobre métodos de modelado conocidos. Se introducenmarcos conceptuales en los que los modelos taxonómicos no poseen una gran riquezaexpresiva en lo que se re…ere a la capacidad para especi…car propiedades estructuralesy de comportamiento. Es importante destacar que algunas de las ideas presentadas


por los autores (inferencia y economía cognitiva) han sido estudiadas y adaptadaspara ser aplicadas en el marco metodológico presentado en esta tesis.Además de la perspectiva …losó…ca, el tiempo constituye una dimensión importan-

te en el estudio, a nivel metodológico, de las relaciones taxonómicas. En el modeladoconceptual OO se han desarrollado diversos trabajos que caracterizan las relacionestaxonómicas centrándose en aspectos temporales. De entre dichas propuestas se con-sideran relevantes las siguientes:Olivé et al. en su trabajo sobre la evolución de los objetos en jerarquías Es-Un

[156] presentan un enfoque metodológico basado en las características temporales delos objetos. Este trabajo se centra en de…nir formalmente a través de un marco tem-poral la Con…guración de Tipos Válida de los Objetos (conjunto de tipos a los cuálespuede pertenecer un objeto en un momento dado), y las Transiciones Válidas entreTipos. El marco temporal propuesto permite clasi…car las especializaciones según lanaturaleza dinámica de las clases y subclases que las forman, introduciendo una solu-ción general que soporta la clasi…cación múltiple y dinámica. Los autores de…nen tresrestricciones de evolución en las especializaciones (estática absoluta, estática relativay dinámica) que sirven para determinar las posibles evoluciones de la población de unsubtipo y un supertipo. La restricción estática relativa de…ne las restricciones de evo-lución presentes en la especialización dinámica presentada en esta tesis. La restriccióndinámica es menos restrictiva que la estática relativa y se asemeja al concepto de rolintroducido en la tesis. A nivel metodológico es importante destacar que la propuestatrabaja (al igual que se propone en esta tesis) con particiones, y justi…ca su utilizacióna nivel metodológico. Además, introduce el concepto de transiciones entre tipos en lasparticiones estáticas relativas y dinámicas. Este concepto se utiliza para especi…car elorden en el cual las entidades cambian de subtipo. En su propuesta las transicionesadmisibles se de…nen mediante diagramas de transición entre estados (igual que sehace en esta tesis con el diagrama de migración). Por último, identi…ca los tipos detransiciones que pueden existir entre tipos: reclasi…cación, continuación activa, sus-pensión, continuación de la suspensión y reactivación. Esta caracterización temporalconstituye un buen punto de partida para identi…car patrones de comportamiento enlas especializaciones cuando se tiene en cuenta el tiempo.Este trabajo proporciona una solución metodológica genérica para el modelado de

especializaciones dinámicas. Esta solución, al ser genérica, puede incorporarse a laaproximación presentada en la tesis como una guía de alto nivel que ayude a la especi-…cación de especializaciones dinámicas. El trabajo desarrollado en esta tesis extiendeen algunos aspectos esta aproximación, incluyendo el tratamiento de las relacionesestructurales (tipos de relaciones entre clases y subclases, la herencia de propieda-des, las restricciones estáticas y la multiplicidad) y de comportamiento (tratando laherencia de comportamiento y de los ciclos de vida, los eventos de migración, y loscriterios de especialización) entre clases y subclases. Esta aproximación debería pro-porcionar una guía para la aplicación del marco metodológico propuesto, e introducirun proceso de generación de código que determinara como trasladar estos patrones decomportamiento al espacio de la solución, tal y como se se lleva a cabo en esta tesis.De nuevo Olivé, en otra propuesta basada en un modelo temporal [155], estudia

las relaciones existentes entre las restricciones de…nidas en una taxonomía y los tiposderivados (especi…cados mediante reglas de derivación). El estudio es genérico yse puede aplicar en la veri…cación del esquema conceptual, para asegurar que las


reglas de derivación implican algunas restricciones de…nidas en la taxonomía, y quela taxonomía incluye todas las restricciones implicadas por las reglas de derivación.Este estudio también es aplicable durante el diseño del sistema para determinar quérestricciones taxonómicas se deben hacer cumplir mediante código y cuáles hacencumplir las reglas de derivación, no siendo necesario forzar su cumplimiento mediantecódigo. El trabajo presenta una clasi…cación de los tipos derivados, un análisis delas restricciones que implican las reglas de derivación y que deben cumplirse en lataxonomía, y un análisis de las posibles formas de cumplimiento de las restriccionestaxonómicas en presencia de tipos derivados.La propuesta introduce una clasi…cación de los tipos de entidades derivadas por:

² especialización (la subclase se obtiene según una regla de derivación, lo que enla propuesta de la tesis se llama criterio de especialización),

² exclusión (la subclase será aquella que tendrá como población los objetos queno pertenecen a ninguna subclase de un conjunto de subclases especializadas elmismo nivel jerárquico, en la propuesta de la tesis sería la clase que completauna partición),

² especialización pasada (la subclase se obtiene según una regla de derivacióntemporal; en este caso el marco temporal permite especi…car subclases “históri-cas”, que constituye una expresividad novedosa, no proporcionada por nuestromodelo taxonómico),

² unión (la clase es una generalización de un conjunto de clases) y² unión con tipos implícitos (la clase es una generalización de un conjunto declases, alguna de ellas derivada).

Es importante destacar a nivel metodológico que en la especialización se introducela necesidad de la existencia de al menos dos subclases de una superclase para quetenga sentido la especialización, al igual que se propugna en el trabajo de tesis.En el trabajo de Olivé se introduce de forma explícita que la semántica de las rela-

ciones taxonómicas impone algunas reglas de derivación, y viceversa. Esta propuestaes útil en el contexto de la tesis porque permite conocer qué restricciones se debenimplementar para mantener la semántica de una taxonomía. El modelo taxonómicoque se presenta en la tesis incorpora sus propias restricciones taxonómicas, y en elproceso de implementación se genera código para forzar su cumplimiento.En línea con lo introducido por Olivé en el primer trabajo, aunque de manera

especí…ca para un modelo taxonómico en particular, Wieringa et al. en [238] presentanun marco metodológico para un modelo formal de relaciones taxonómicas. En dichomarco se proporcionan reglas para distinguir entre clases estáticas, clases dinámicasy roles. Estas reglas están basadas en propiedades de la extensión de una clase, laidentidad y el principio de conteo por el cual un objeto puede tener más de un rol deuna misma subclase de rol2 .De manera especí…ca, los trabajos de Su y Spaccapietra et al. se centran en el

estudio de las transiciones entre subclases dinámicas.2En el apartado de Modelado Conceptual OO se analizan con mayor detalle cada uno de los

conceptos presentados en esta aproximación.


Su en [219] presenta una propuesta en la que de…ne las restricciones de migraciónde un objeto como un conjunto de secuencias de subclases dinámicas, donde cadasecuencia representa la traza de un objeto a través de los subespacios de su espacio deestados de…nido por las particiones dinámicas de las clases del esquema conceptual.Los resultados de Su se pueden aplicar en el estudio y especi…cación de los diagramasde migración de…nidos para las subclases dinámicas. Este es un trabajo que pro-porciona una solución muy especí…ca a un problema concreto (la especi…cación de lamigración de un objeto entre subclases dinámicas) por lo que es una solución parcialen el contexto del trabajo de tesis presentado, aunque posee una gran importancia anivel metodológico que debe resaltarse.Spaccapietra et al. en su trabajo sobre modelos temporales aplicados al Modela-

do Conceptual [213] presenta algunos conceptos interesantes para la caracterizacióntemporal de los tipos de especialización. Spaccapietra introduce de forma sencillatérminos como la clasi…cación estática y dinámica, la migración, las relaciones detransición: “una relación de transición modela la migración de los objetos de un tipofuente a otro destino” y la reclasi…cación: “es una relación de transición que conlle-va una semántica de convertirse en”. Estas relaciones de transición son un “enlacedinámico” entre objetos que comparten la misma identidad, exigiendo además quelas clases fuente y destino participen en (sean miembros de) la misma jerarquía deespecialización dinámica. Según el autor existen dos tipos de transiciones: evolucióny extensión. La evolución se produce cuando el objeto que migra cesa de existir en laclase origen y se crea en la clase destino. La extensión se produce cuando no deja deexistir en la clase origen. El modelo objetual utilizado para tratar la especializaciónes genérico (en ningún momento trata las propiedades), aunque es una aproximacióninteresante a nivel metodológico porque es capaz de capturar algunos patrones decomportamiento de los objetos en las subclases cuando se considera el tiempo. Estetrabajo, de nuevo aporta algunos conceptos como los tipos de transiciones (evolu-ción y extensión) que han sido incorporados al marco general para el modelado derelaciones taxonómicas que se presenta en esta tesis. La aportación, al igual que Su,es parcial pero por ello no deja de ser relevante gracias a la introducción de nuevospatrones de comportamiento cuando se considera el tiempo.A nivel metodológico la herencia del comportamiento es otro aspecto que ha sido,

y se sigue tratando. Siguiendo este enfoque, existe una gran cantidad de propuestascentradas en caracterizar las relaciones taxonómicas desde la perspectiva de la heren-cia del comportamiento (estudiando cómo heredan y modi…can el comportamiento lassubclases). De entre las aproximaciones existentes, destacan los trabajos clásicos deWegner y Zdonik [231], Liskov y Wing [134], y Meyer [145], aplicados al diseño y a laprogramación orientada a objetos. Estos trabajos proporcionan enfoques metodológi-cos para el tratamiento de los mecanismos de herencia a nivel de comportamiento quese han aplicado también a nivel de modelado conceptual OO. Estas aproximacionestratan la herencia como un mecanismo válido (si se utiliza disciplinadamente) pararepresentar la especialización conceptual.Wegner y Zdonik en [231] presentan la herencia como un mecanismo de modi…-

cación incremental que transforma un objeto padre en un objeto hijo a través de unmodi…cador. Los autores categorizan los tipos de modi…cación incremental en:

² compatibilidad de comportamiento, consistente en que el comportamiento de lasubclase es compatible con el de la clase padre. Se entiende como comportamien-


to compatible aquel en el que las instancias de la clase hija se comportan comoinstancias de la clase padre para todas las operaciones y argumentos de…nidosen la clase padre considerada.

² compatibilidad de signatura, que requiere una compatibilidad sintáctica entrelas signaturas de la clase padre y la clase hija. Este tipo de compatibilidades utilizada en los lenguajes de programación OO como una restricción en lassignaturas de las clases participantes, revisada en tiempo de compilación. Anivel estructural la compatibilidad de signatura se preserva con extensiones ho-rizontales (añadiendo nuevos componentes a la signatura considerada) y conextensiones verticales (restringiendo a un subtipo el tipo asociado a componen-tes de la signatura).

² compatibilidad de nombre, donde los nombres de las operaciones de la clasepadre se mantienen en la clase descendiente, aunque las operaciones puedenser modi…cadas (en el sentido de ser especializadas). La rede…nición de unaoperación está totalmente permitida: una operación rede…nida puede tener unnúmero diferente de argumentos, así como un efecto extremadamente diferentede la correspondiente operación con el mismo nombre perteneciente a la clasepadre.

² cancelación, donde la modi…cación de atributos de la clase padre está permitidasin ningún tipo de restricción, siendo incluso posible borrar algunos de los atri-butos heredados teniendo, de hecho, clases descendientes con menos atributosque sus correspondientes clases padres (herencia ‘con olvido’).

La propuesta de Wegner y Zdonik introduce además el principio de reemplazabi-lidad por el cual una instancia de un subtipo siempre puede ser usada en cualquiercontexto en el que se esperaría una instancia del supertipo.Liskov y Wing en [134] caracterizan a nivel de comportamiento la relación de sub-

tipado, argumentando que los objetos de un subtipo deben comportarse de la mismamanera que los del supertipo, para cualquier programa u objeto que los utilice comolo haría con el supertipo. La restricción que han de cumplir los subtipos es que laspropiedades que se puedan probar de un objeto de un tipo determinado, se debenseguir cumpliendo cuando el objeto sea miembro de un subtipo de éste. En el trabajose presenta un estudio completo de las propiedades que deben preservarse en el com-portamiento de los objetos (invariantes y propiedades históricas). Las condiciones quese exige que cumplan las relaciones de subtipo son fáciles de aplicar, y se proporcionaun proceso para la comprobación de estas propiedades sobre las especi…caciones delos tipos. Una aportación interesante es la aplicación de su propuesta a dos tipos deejemplos: (1) subtipos que extienden al supertipo y (2) subtipos que lo restringen;detectando situaciones típicas que no se pueden especi…car con la relación de subtipoque han de…nido.Por último, Meyer en [145] propone que las aserciones de un método en una sub-

clase deben garantizar un rango de comportamientos aceptables. Para conseguirlo lasprecondiciones pueden ser iguales o más débiles que las de…nidas en la clase padre(signi…cando que el método puede aceptar más peticiones de servicio de los objetosclientes sin perjudicar a los clientes que ya utilizaban dichos métodos), y las post-condiciones pueden ser iguales o más fuertes (esto implica que los métodos pueden


extender su comportamiento garantizando al menos lo mismo que se garantizaba enla superclase).Existen diversas propuestas (Ebert y Engels [70], Saake et al. [196], Cook y Daniels

en Syntropy [53], Sourrouille [211], Stumptner y Schre‡ [218] y Preuner et al. [185]),que han tratado también a nivel de comportamiento la especialización del ciclo devida de un objeto, trasladando el principio de reemplazabilidad a los ciclos de vidade un objeto. La idea subyace en que cualquier diagrama de ciclo de vida de…neel conjunto de trazas posibles, donde cada traza es una secuencia de ocurrencias deeventos que constituye una historia permitida en el diagrama. Así pues “una traza deun objeto de una subclase restringida a los eventos de…nidos en la superclase podráocurrir en cualquier contexto en el que se esperaba una traza de un objeto de lasuperclase”.La mayoría de las ideas presentadas por estas aproximaciones (en especial la com-

patibilidad de comportamiento y el principio de reemplazabilidad) han constituidola base para la caracterización adecuada del comportamiento del modelo taxonómi-co propuesto en esta tesis. En la tesis se han adaptado y extendido para abordarel tratamiento de la compatibilidad de comportamiento para las precondiciones, res-tricciones de integridad, evaluaciones sobre atributos, y disparos de un objeto. Esimportante resaltar como aportación del trabajo de tesis, que en los disparos se hatratado la compatibilidad de comportamiento desde el punto de vista del objeto comocliente activo y no como servidor. Por último, decir que algunas de las ideas de Meyerno son aplicables para el re…namiento de aserciones en los ciclos de vida, ya que alproponer relajar en la subclase las precondiciones de las transiciones de…nidas parala clase padre, se permiten nuevas activaciones de eventos heredados para los objetosde la clase hija. Estas activaciones no están contempladas para los objetos de la clasepadre, lo que viola el principio de reemplazabilidad.Otra línea de trabajo interesante a nivel metodológico, la constituyen una serie

de propuestas que proporcionan marcos conceptuales para caracterizar las relacionestaxonómicas. Esta caracterización se basa en la identi…cación de propiedades quedeben cumplir las relaciones taxonómicas y las subclases.Goldstein y Storey, en un trabajo sobre abstracciones de datos en el Modelado de

Sistemas de Información [79], introducen un Modelo Abstracto de siete dimensiones.Estas dimensiones se utilizan para analizar las características de las abstraccionesconceptuales de un modelo semántico y determinar su representación en el Mode-lado Relacional. A diferencia de la propuesta de la tesis, centrada en relacionestaxonómicas, el marco que proponen es un marco general para el tratamiento decualquier abstracción de datos. Este marco de…ne siete dimensiones para caracterizaruna abstracción: interpretación semántica (especi…ca el signi…cado de la abstracción),conjuntos de propiedades (propiedades que posee la abstracción a nivel de relacionesy atributos derivados y/o emergentes), roles (cuando dos clases están relacionadasalguna de ellas juega un papel determinado en la abstracción), transitividad (si unaabstracción es transitiva), correspondencias (restricciones sobre cardinalidades per-mitidas, sobre si las entidades de las superclases tienen al menos una entidad en unasubclase y solapamiento de subclases), dependencia existencial (¿puede una entidadde la subclase existir independiente de la existencia de una entidad en la superclase yviceversa?) y homogeneidad (¿son los objetos de la subclase del mismo tipo que losde la superclase?). Con estas dimensiones se caracteriza lo que llaman inclusión (o


relación de especialización) y se presenta cómo implementar dichas abstracciones enun sistema de base de datos relacional. El marco tiene puntos en común con la pro-puesta de esta tesis, pero, al pretender abordar todos los tipos de abstracciones, éstecaracteriza de forma menos precisa las relaciones taxonómicas. Esta aproximaciónno proporciona guías para su aplicación. Está in‡uenciada por modelos semánticosrelacionales por lo que presenta una caracterización estructural de las abstraccionesde datos y no incorpora propiedades temporales y de comportamiento como se haceen esta tesis.La propuesta anterior constituye un intento de introducir un marco multidimen-

sional genérico para caracterizar adecuadamente todas las abstracciones de modelado.Kristensen y Osterbye en [119, 121] proponen un marco especí…co para la carac-

terización de los roles basado en seis atributos: visibilidad (la visibilidad de un roly el acceso a un objeto puede restringirse a los métodos de un rol, incluyendo losmétodos y propiedades del objeto y excluyendo los de los otros roles), dependencia (elrol es dependiente del objeto intrínseco, no puede existir sin el objeto), identidad (unobjeto y sus roles actuales tienen una identidad única), dinamicidad (un rol puede serañadido y eliminado durante la vida de un objeto), multiplicidad (varias instanciasde un rol pueden existir a la vez para un mismo objeto) y capacidad de abstracción(los roles pueden clasi…carse y pueden organizarse en jerarquías de generalización yagregación).Esta caracterización sirve como marco metodológico para determinar patrones de

comportamiento y estructurales en los roles, sin embargo los autores no de…nen ningu-na guía metodológica para su aplicación. Simplemente se utilizan como característicasa evaluar la adecuación de las distintas representaciones que se utilizan en el modela-do conceptual (agregación, asociación y especialización) para simular el concepto derol. Esta propuesta es menos completa que la caracterización presentada en la tesismediante el marco de referencia multidimensional que proporciona nueve dimensio-nes y las relaciones entre ellas. A nivel estructural presentan un tratamiento de lasrelaciones entre las propiedades del objeto intrínseco (de la superclase) y de los roles,determinando los distintos tipos de propiedades que puede tener un rol: propiedadesintrínsecas (propiedades de un objeto intrínseco son accesibles a través de las ins-tancias de roles como si fueran propiedades heredadas), propiedades extrínsecas (laspropiedades de los roles son propiedades emergentes, son visibles por los roles pero nopor los objetos; pueden existir propiedades extrínsecas con el mismo nombre que laspropiedades intrínsecas, sólo se tendrá acceso desde el rol a la propiedad extrínseca“repetida”) y propiedades de tipo rol (una propiedad de una instancia de rol puedeser un rol de una propiedad del objeto intrínseco, constituyendo los que se llama unapropiedad combinada, una especie de unión de la propiedad intrínseca y extrínseca).Esta aproximación utiliza un modelo de rol intuitivo y poco preciso, ofreciendo untratamiento muy particular de los roles, contrariamente a lo que se ha desarrolladoen esta tesis.Estos marcos presentados necesitan de técnicas sencillas que ayuden en la práctica

del modelado a identi…car las propiedades especí…cas de las relaciones taxonómicas.En esta área de trabajo se están introduciendo técnicas basadas en preguntas y res-puestas, y lenguajes de patrones, que constituyen un intento inicial de construir guíasde modelado.Snoeck y Dedene en [209] presentan un modelo formal de especialización / generali-


zación y de rol que se analizará más adelante en el apartado de Modelado Conceptual.Esta aproximación se incluye en este apartado porque además proporciona un enfoqueinteresante para caracterizar las relaciones de especialización. Concretamente tratala herencia de comportamiento en las subclases y proporciona un marco metodológicobasado en preguntas y respuestas que permiten caracterizar los tipos de relacionestaxonómicas dependiendo de características estructurales (si tiene la subclase másatributos) y de comportamiento (si la subclase tiene diferentes restricciones sobre losatributos que la superclase, si la subclase posee más eventos, si posee otra secuenciade restricciones, si pertenece permanentemente o temporalmente a la superclase). Laaproximación construye una tabla de decisión que permite encontrar contradicciones,decisiones innecesarias y especi…caciones incompletas. El modelo formal de objetospresentado sólo posee eventos, atributos con sus restricciones de integridad y la es-peci…cación del ciclo de vida del objeto mediante un álgebra de procesos. La guíametodológica basada en preguntas no se parece a la propuesta navegacional basadaen preguntas que se presenta en esta tesis, a pesar de ello, esta aproximación puedeconsiderarse que ha in‡uido en el desarrollo de la tesis porque su enfoque metodo-lógico, constituyó la idea inicial a partir de la cual se ha construido el lenguaje depatrones y la propuesta navegacional que se presentan en esta tesis.

Uno de los último trabajos en esta línea, es el de Wohed [241]. Wohed, en su tra-bajo sobre reutilización de patrones conceptuales, propone un método para la iden-ti…cación de patrones conceptuales, en el que ofrece una estructura de navegaciónpara sugerir durante el proceso de modelado cuáles son los patrones conceptuales másadecuados. Wohed ha desarrollado un prototipo de herramienta CASE que incorpora360 patrones de un dominio determinado. La estructura de navegación se construyea partir de preguntas sobre las características de las relaciones entre las clases poten-ciales del modelo. Las preguntas intentan obtener las cardinalidades entre las clasesy determinar la naturaleza de las relaciones (si son agregaciones o especializaciones).El usuario responderá a las preguntas comentadas anteriormente (una detrás de otra)y después de la respuesta, la herramienta re…nará el esquema conceptual de acuer-do a lo que se haya respondido. El usuario puede renombrar las clases y relacionesobtenidas durante el proceso de modelado. Esta aproximación es interesante aunqueuno de los principales inconvenientes es su dependencia del dominio. Además, el tra-tamiento realizado para comprender la naturaleza y los patrones estructurales y decomportamiento existentes entre los patrones conceptuales es pobre. Esto es debidoa que el modelo formal de objetos que utiliza como referencia para dar semánticaa los patrones conceptuales es muy sencillo (sólo presenta atributos y operaciones, ycardinalidad entre las asociaciones y agregaciones). De hecho el patrón conceptual es-pecialización (generalización) sólo se trata como una especialización estática sin teneren consideración el tiempo. Por último, es importante destacar que no se presentanunas guías para la aplicación de estas ideas en diferentes dominios. La aproximacióndefendida en esta tesis presenta una solución independiente del dominio, en la que seestudia a fondo la naturaleza de las estructuras taxonómicas y se proporciona un mar-co conceptual y un lenguaje de patrones que constituyen la base para la construcciónde la estructura navegacional de preguntas.

Por último, Rawsthorne [189] y Whitenack [234] utilizan por primera vez los len-guajes de patrones como guías para la ayuda a la recolección de requisitos y al mo-delado OO de sistemas de información. En estos trabajos los autores presentan una


serie de patrones relacionados que sirven como ayuda al proceso de modelado con-ceptual. Estos lenguajes de patrones constituyen un recetario compuesto por recetas(patrones) que ayudan a abordar problemas especí…cos de la tarea de modelado. Laspropuestas no tratan con detenimiento la etapa de modelado, basándose en técnicasde modelado que proporcionan abstracciones conceptuales poco expresivas. De he-cho, el patrón que ayuda a identi…car las relaciones de especialización en un esquemaconceptual trata con el concepto de generalización propuesto por UML y no contem-pla ningún tipo de especialización dinámica. Aunque la idea no está su…cientementedesarrollada, estos trabajos han servido como punto de partida para la construcciónde la propuesta metodológica que se presenta en la tesis. Estas propuestas con…rmanque los lenguajes de patrones son útiles también para de…nir procesos de modeladoespecí…cos.El trabajo que se presenta extiende e integra los aspectos presentados en este apar-

tado para construir un marco metodológico que guíe al modelador en la identi…cacióny especi…cación de relaciones taxonómicas.

3.1.2 Modelado Conceptual OO

Las relaciones taxonómicas constituyen un amplio campo de investigación en el ámbitode los métodos de modelado conceptual OO y los métodos formales de especi…cación.La especialización o relación Es-Un es la abstracción conceptual de naturaleza taxo-nómica que está presente en la mayoría de métodos de modelado conceptual OO. Sinembargo, cada uno de los métodos proporciona una interpretación particular de laespecialización, algunos lo hacen formalmente (de manera precisa) y otros de manerainformal (frecuentemente ambigua). En este apartado se analizan los distintos mode-los de especialización introducidos por diversas aproximaciones formales e informales.De forma genérica se puede observar que, atendiendo a una caracterización tem-

poral, los métodos ofrecen dos tipos de abstracciones: la especialización estática yla dinámica. La especialización dinámica es la que más interpretaciones semánticaspresenta y la más problemática de tratar, debido a la di…cultad de encontrar un únicotérmino y una semántica consensuada que la de…na. Por ejemplo, dicha abstracción(como se verá a continuación) recibe nombres como especialización temporal, dinámi-ca, estática relativa, rol, aspecto, modo, tipo estado, subclase dependiente del estado,etc. En ocasiones existen métodos que utilizan los mismos términos para referirse aconceptos totalmente distintos, como es el caso del uso que se hace del término rol.Dada la importancia que tiene el tratamiento de los roles en la actualidad, y debido

a que no existe un consenso sobre cómo deben representarse e integrarse en los métodosde modelado actuales, este apartado se divide en dos subapartados. En el primero seestudian y comparan los trabajos más representativos sobre relaciones Es-Un con laaproximación de la tesis, analizando aquellos métodos que tratan los distintos tiposde relaciones de especialización (estática, dinámica y roles). En el segundo se analizanaquellas propuestas que se centran exclusivamente en el tratamiento de los roles.

Modelado de Relaciones de Especialización

En el ámbito de las técnicas de modelado conceptual OO semi-formales existe unnúmero considerable de aproximaciones que introducen las relaciones de especializa-ción como mecanismos de modelado. De entre las técnicas existentes se ha selec-


cionado para su análisis aquellas que son relevantes a nivel práctico (UML por suaceptación industrial) y teórico (Syntropy, y Martin y Odell por introducir relacionesde especialización más expresivas que la mayoría de métodos convencionales).UML [86] es actualmente el lenguaje de modelado OO estándar. UML trata el

concepto de generalización. La generalización es la relación taxonómica entre unaclase más general y otra más especí…ca que es totalmente consistente con la primeray que le añade información. En UML una clase puede generalizarse según ciertoscriterios. Cada criterio de la generalización se indica asociando un discriminador ala relación de generalización. Dicho discriminador es el nombre de una partición delos subtipos de la superclase. Este discriminador puede ser un atributo de la clasegeneralizada o el nombre de la partición.Pueden aplicarse diferentes restricciones a las relaciones de generalización para

distinguir entre sus diversas formas. La restricción {disjoint} indica que dado unconjunto de subclases de una superclase, una instancia de la superclase sólo puedeespecializarse en una (y sólo una) de las subclases. La restricción {overlapping} esconceptualmente opuesta a la restricción {disjoint}. La restricción {complete} indicaque todos las subclases de la generalización se han especi…cado en el modelo y nose permite añadir subclases; inversamente, la restricción {incomplete} designa unageneralización extensible a la que se pueden añadir subclases adicionales. Puedenrepresentarse grupos de generalizaciones semánticamente relacionados como árbolescon un segmento compartido. Si se añade una etiqueta a este segmento compartido,ésta se aplica a todo el grupo de generalización.UML utiliza un único término (generalización) para tratar con las relaciones ta-

xonómicas. En esta tesis, se trata con la especialización que a su vez se categorizade acuerdo a su naturaleza temporal; en UML no se distingue explícitamente es-ta categorización, en general, se entiende como estática. La falta de de…nición enla semántica de la generalización que presenta UML impide, en cierto modo, poderrealizar una correspondencia clara entre conceptos UML y los presentados en estetrabajo. Las especializaciones estáticas y dinámicas son particiones (completas y dis-juntas) en la aproximación de la tesis, y los roles disjuntos e incompletos. En la tesisel discriminador de UML se extiende mediante estereotipos para poder especi…carlos criterios de especialización, permitiendo de…nir particiones mediante condicionessobre atributos constantes (estáticas) y sobre atributos variables (dinámicas) de lasuperclase. Además, para identi…car los roles y las subclases dinámicas se introducenlos estereotipos <<jugado_por>> y <<dinámica>> respectivamente. Los rolesposeen eventos activadores del rol que también se especi…can introduciendo nuevosestereotipos. Por último, una característica muy importante que no posee UML y queintroduce esta tesis es la completa caracterización del comportamiento de todos lostipos de subclases (a nivel de herencia de propiedades, ciclos de vida y compatibilidadde comportamiento y signatura).Syntropy [53] es una propuesta interesante que presenta un método orientado a

objetos semi-formal. Es uno de los primeros métodos “convencionales” que da granimportancia a la conformidad de comportamientos en las subclases. Syntropy intro-duce las relaciones taxonómicas mediante el concepto de subtipo y exige que el subtipoherede el comportamiento del supertipo de forma conforme (básicamente el subtipopodrá extender las capacidades del supertipo pero no las podrá restringir). La con-formidad de comportamiento al heredar un subtipo es uno de los tratamientos más


interesantes que realiza esta aproximación. La propuesta hace uso de los “statecharts”de Harel [96] para describir el comportamiento, y de las operaciones de anidamien-to y ortogonalidad para soportar las operaciones de re…namiento y combinación enla herencia. Otro aspecto muy importante de esta propuesta es la introducción delconcepto de tipos estado o subtipos dinámicos (state-types) para modelar subclasesdinámicas. Una subclase dinámica contendrá en cada momento a los objetos de susuperclase que se encuentren en un estado concreto de la máquina de estados quede…ne el comportamiento de la superclase. De esta forma se aprovecha la especi…ca-ción de comportamiento (el diagrama de estados3) de la clase padre para modelar lapertenencia a una determinada subclase estado, en particular, un estado del diagramade estados de la clase padre representará la condición de pertenencia a una subclasedinámica. Los tipos estado comparados con la aproximación defendida en esta tesis,son muy parecidos a las subclases dinámicas. Esta aproximación es parecida a ladefendida en la tesis en lo que respecta al modelado de las subclases dinámicas y lasrelaciones transición entre éstas, debido a que en las dos se introduce un diagramade transición entre estados (en nuestro caso el diagrama de migración) para especi…-car la migración entre subclases dinámicas. La principal diferencia es que Syntropyno proporciona una guía metodológica de ayuda al modelado, ni ofrece generaciónautomática de código a partir del esquema conceptual.Martin y Odell [138, 139], introducen en su propuesta de método de modelado

OO semi-formal los conceptos de partición (completa e incompleta) y, clasi…caciónmúltiple y dinámica. No son los primeros en hablar de particiones4, aunque si son lapropuesta OO que con más fuerza promueve sus bene…cios a nivel de modelado. Estapropuesta no va más allá de una notación y de una de…nición informal de los conceptos,pero es interesante destacarla porque algunos de los conceptos que se presentan enesta tesis surgen inicialmente en esta aproximación.Además de estas técnicas de modelado, en el ámbito de los lenguajes de especi…-

cación formal existe un conjunto de propuestas que deben analizarse por considerarseque van en la línea del modelo de relaciones taxonómicas que se presenta en esta tesis.TROLL [117] es un lenguaje de especi…cación formal que presenta como estructu-

ras taxonómicas los roles y la especialización para dar cuenta de aspectos temporalesy permanentes de los objetos respectivamente. En esta aproximación el concepto derol describe una especialización dinámica, pero no en el sentido que se propone en estatesis, porque no introduce el concepto de partición y no proporciona ninguna técnicapara especi…car la migración entre los objetos de las subclases. En este modelo unobjeto puede jugar diferentes roles (de distintas clases de rol) a la vez, y no puedejugar el mismo rol de la misma clase varias veces al mismo tiempo. El rol poseeeventos de creación y destrucción del rol. Además, posee compatibilidad de compor-tamiento según las reglas de…nidas en [231]. La especialización se considera un casoespecial de un rol. Es un rol que juega el objeto durante toda su vida, por lo que nose dispone de eventos especí…cos de creación y destrucción del rol. Los roles se creanmediante la ejecución de eventos, mientras que la especialización está basada en elvalor de ciertos atributos. Igual que sucedía en el caso de los roles, un objeto puedepertenecer a diferentes clases especializadas al mismo tiempo. Como caso especial delos roles, a la especialización se le exigen las mismas condiciones excepto la existencia

3Del término inglés “statechart”.4Lenzerini en [127] ya introdujo anteriormente estos conceptos.


de eventos de creación y destrucción especí…cos. De la misma manera, las reglas decompatibilidad de comportamiento para una clase especializada se trans…eren de losroles. Esta aproximación está bien formalizada pero obvia alguna de las caracterís-ticas esenciales de los roles presentes en la aproximación de la tesis, debido a queno permite múltiples roles de una misma clase de rol, no proporciona identi…cacióna las subclases y no permite ‡exibilizar la compatibilidad de comportamiento con lacompatibilidad de signatura.

Snoeck y Dedene en [209] distinguen entre especializaciones y roles. Sin embar-go, la noción de rol di…ere de la mayoría de las propuestas existentes sobre roles enque extiende el comportamiento de una clase y no permite la de…nición de una nue-va subclase a partir del rol. Los roles extienden el comportamiento añadiendo a lasclases nuevos tipos de eventos y nuevas secuencias, pero no permiten añadir nuevosatributos ni nuevos métodos asociados a eventos existentes. Los roles se utilizan paramodelar aspectos temporales y las especializaciones para aspectos permanentes. Lasespecializaciones pueden añadir atributos y métodos. Una característica particularde esta aproximación es que de…nen tres tipos de subclases (dependientes de atribu-tos, de existencia y de estado). Las subclases de…nidas por el estado son parecidasa la especialización dinámica propuesta en esta tesis. Los roles según esta propuestaaparecen como especi…caciones parciales de tipos, por lo que no pueden tener instan-cias propias. El modelo formal de objetos que introduce esta propuesta está basadoen el álgebra de procesos que utiliza el lenguaje formal M.E.R.O.D.E. Un aspectorelevante de este trabajo es que trata la especialización de los procesos en las sub-clases de forma precisa. Esta aproximación está enfocada a caracterizar formalmenteel comportamiento de las subclases mediante álgebras de procesos, en cambio, noproporciona, como lo hace la propuesta de la tesis, una caracterización estructuraly temporal de las subclases. Además, no propone ninguna implementación de lasespecializaciones y roles en lenguajes imperativos.

El trabajo de Wieringa et al. [238] constituye la base de la propuesta de relacionestaxonómicas que se presenta en esta tesis para el modelo formal OASIS. La pro-puesta introduce tres tipos de relaciones taxonómicas ortogonales entre sí: subclasesestáticas, dinámicas y roles. Wieringa introduce el concepto de partición como pilarfundamental de su propuesta. Las subclases estáticas poseen la misma semántica queel concepto de especialización permanente en otras aproximaciones (manteniendo lacompatibilidad de comportamiento). Lo más destacable de esta propuesta es la di-ferenciación entre roles y subclases dinámicas basada en el problema del conteo (unobjeto puede jugar más de un rol a la vez, incluso de la misma subclase de rol). Cadarol declara una relación jugado-por con otra clase o rol. Esta relación une un rol consu jugador. Una instancia de rol es un objeto que se “agrega” al jugador y que poseeuna identidad propia separada de la del objeto jugador (esto soluciona el problemadel conteo). Los roles heredan del jugador mediante un mecanismo de delegación ylas subclases dinámicas heredan mediante un mecanismo de herencia estándar. Laaproximación de Wieringa se centra en la representación precisa de su modelo taxo-nómico tomando como marco formal la lógica dinámica, aunque no profundiza en eltratamiento de las características estructurales y de comportamiento de las relacio-nes taxonómicas. No aborda la herencia de atributos, eventos y su comportamientoasociado, así como las restricciones sobre las propiedades (restricciones estáticas yprecondiciones). En ningún momento trata cómo afecta la especialización a la acti-


vidad del objeto (viéndolo como cliente peticionario de servicios) como se hace en lapropuesta de la tesis con la herencia de las condiciones de disparo. Esta aproximaciónsólo trata temas de especi…cación, sin abordar su implementación como se proponeen esta tesis.La propuesta de ROSES [59] se apoya en los conceptos de clases derivadas y

clases seleccionadas por eventos para introducir las relaciones taxonómicas en unmodelo OO. En esta aproximación una clase derivada contiene a aquellos objetos de susuperclase que cumplen una condición. Esta condición se basa en atributos de la clase.Una clase seleccionada por eventos contiene aquellos objetos de su superclase que hansido insertados en ella mediante un evento de entrada, y no han sido eliminadosmediante un evento de salida. En esta aproximación las clases derivadas son similaresa las que en este trabajo se llaman subclases dinámicas, y las clases seleccionadas poreventos pueden ser subclases dinámicas o roles en nuestra aproximación.El lenguaje TESORO [227] en los trabajos [228, 229], introduce un tratamiento

exhaustivo de las relaciones taxonómicas. En esta aproximación se presentan dos ti-pos de especializaciones: permanente y temporal. La especialización permanente secorresponde con las subclases estáticas que se introducen en esta tesis. La especia-lización temporal constituye una aproximación muy general cuya semántica dependede los criterios de clasi…cación especi…cados sobre la especialización. Debido a estacircunstancia, se pueden incluir en ella las subclases dinámicas y roles de…nidos enesta tesis. La propuesta presenta un trabajo completo sobre criterios de clasi…cación(estáticos y dinámicos). Los criterios de clasi…cación propuestos por TESORO son:(1) criterios sobre el estado actual (será especialización permanente si el criterio sede…ne sobre atributos constantes, y temporal si se de…ne sobre atributos variables),(2) criterios dependientes de la extensión (se de…nen condiciones sobre la poblaciónde los objetos), (3) criterios dependientes de eventos, (4) creación directa. Por últi-mo, la propuesta presenta un trabajo sobre conformidad de comportamientos que esperfectamente trasladable a este trabajo, aunque no trata en ningún momento consituaciones en las que no se exija la conformidad de comportamiento como ocurre conlos roles de esta tesis.Por último, se revisa la aproximación de la versión 2.2 del lenguaje OASIS en la

que está basada actualmente OO-Method. Antes de empezar, es importante destacarque el modelo de relaciones taxonómicas introducido en esta tesis constituye unaextensión de la versión 3 [129], en la cual se abordan con mayor detalle los aspectosmetodológicos y la herencia de propiedades y ciclos de vida.Las relaciones taxonómicas en OASIS (v2.2) [176] se especi…can por medio de

dos operadores de clase: la especialización (trata la herencia descendente o derivaciónde clases hijas a partir de una clase padre) y la generalización (la inversa del anterioroperador y se utiliza para tratar la herencia ascendente o generación de clases padresagrupando propiedades comunes de clases de…nidas con anterioridad). Una especia-lización puede ser temporal o permanente. Es temporal cuando la clase descendientetiene su propio evento de creación, que está en la signatura de eventos de la clasepadre. Una vez este evento haya ocurrido, el objeto ‘juega el papel’ correspondiente ala clase especializada. Una especialización temporal también puede de…nirse especi…-cando una condición, la cual al ser satisfecha, produce el mismo efecto que el eventode creación. Es especialización permanente si un objeto pertenece a una clase especia-lizada desde el momento mismo de su creación, debido a que se cumple una condición


de especialización. Esta condición de especialización debe especi…carse obligatoria-mente. El objeto será en todo momento miembro de las dos clases, la clase padre yla clase hija. En este caso, cuando se destruye un objeto de una especialización per-manente, también implica la destrucción de la instancia de la clase padre asociada.La generalización puede ser disjunta o no disjunta. En la especialización permanen-te se exigirá compatibilidad de comportamiento y en la temporal compatibilidad designatura según la caracterización propuesta por [231].Esta aproximación posee algunas de…ciencias respecto a la nueva propuesta pre-

sentada en este trabajo. En esta aproximación no existe el concepto de partición,una clase debe poder subclasi…carse en diversas taxonomías, según los criterios deespecialización. En OASIS 2.2 no hay distinción entre taxonomías, se puede decirque a nivel de especi…cación si los criterios de especialización son los mismos o estánbasados en los mismos atributos, estas subclases forman parte de una partición, pe-ro no se garantiza que las condiciones de especialización no sean disjuntas. En estaaproximación no se pueden de…nir restricciones de multiplicidad en los roles. En elenfoque de OASIS 2.2 el término rol se utiliza en muchas situaciones para describirespecializaciones dinámicas y roles a la vez. Esta sobreexpresividad es problemáticay entra en con‡icto con dos principios básicos que la mayoría de aproximaciones com-parten: (1) las especializaciones (sean estáticas o temporales) heredan las propiedadesde la superclase mediante un mecanismo estándar de herencia y manteniendo la com-patibilidad de comportamiento, (2) las instancias de una clase pueden jugar múltiplesroles de una misma clase de rol. Esto implica la necesidad de proporcionar a los rolesun identi…cador distinto al de la superclase y que la herencia de las propiedades seapor delegación (esto permitirá relajar la compatibilidad de comportamiento con lacompatibilidad de signatura). Como ejemplo de este problema se puede ver: si desdeun objeto especializado temporalmente (en OASIS 2.2 ) se ejecuta un evento deespecialización, no se crearía otro objeto que jugase el mismo rol (por los problemasde identi…cación), y aunque los problemas de identi…cación estuviesen resueltos, es lasuperclase la que ha de crear el rol y no el mismo rol. Con la nueva propuesta (condelegación e identi…cación) el rol delegaría en el objeto de la superclase (el jugador)para que ejecute el evento de creación del nuevo rol.

Modelado de Roles

Actualmente existen diversas interpretaciones del concepto de rol que se pueden ca-tegorizar en cuatro tipos: (1) como nombres de los …nales de las asociaciones entreclases, (2) como ranuras en las colaboraciones (concepto propugnado por OOram[190]), (3) como una forma de especialización dinámica, y por último (4) como ins-tancias separadas unidas a un objeto (el jugador). Los tres primeros tipos encajancon las de…niciones que UML proporciona del concepto de rol.En este apartado se van a analizar los distintos tipos de aproximaciones. Esta

tesis apuesta por el papel del rol como relación taxonómica de naturaleza dinámica,con propiedades y comportamiento propios.Una de las primeras propuestas, y probablemente la más conocida de entre aquellas

que consideran a los roles como nombres de los …nales de las asociaciones, es la deFalkenberg [73]. En su modelo de objetos-roles (ORM), los objetos y los roles son lasúnicas primitivas de modelado a partir de las cuales se derivan los tipos de objetos


y de asociaciones. ORM permite de…nir asociaciones anidadas (asociaciones sobreasociaciones). El modelo que se presenta es puramente extensional porque de…ne lostipos exclusivamente en términos de las instancias y de los roles que juegan éstas.De…niendo los roles como nombres en asociaciones, la potencia expresiva de los rolesse limita porque se está reconociendo que los roles sólo existen en el contexto de unaasociación. Esta aproximación es de…ciente porque los roles poseen propiedades ycomportamiento propio que no se modelan únicamente con un nombre de asociación.Esta de…ciencia se resuelve viendo a los roles como tipos, tal y como se presenta enla siguiente propuesta.Entre las aproximaciones que apuestan por la utilización de los roles como ranuras

en una colaboración, la más relevante es OOram [190]. Esta aproximación es unmétodo orientado a objetos con énfasis en el modelado y la síntesis de roles. Elmétodo se centra en la creación y representación de una estructura organizada deobjetos que colaboran. El concepto de rol representa las responsabilidades de unobjeto en la estructura de objetos colaboradores. Para poder explotar los objetos queson útiles en distintos contextos es necesario distinguir entre las capacidades de losobjetos y su posición en la estructura de la colaboración. Esta distinción es importanteporque los objetos del mismo tipo pueden ser reutilizados en distintas posiciones. Elrol especi…ca qué capacidades son necesarias, y puede aparecer en distintas posiciones.El modelado de roles presenta dos etapas: (1) el análisis que descompone el problemaen subproblemas para crear un modelo de cada subproblema, y (2) la síntesis paracombinar pequeños modelos con otros más grandes. Los roles aparecen en diagramasde roles, donde la interacción se representa mediante contratos (grupos de mensajesaceptables por los roles). Los roles modelan las responsabilidades que son necesariasen una determinada posición de la estructura de colaboración. Pueden combinarsemediante operaciones de unión, mezcla, y/o ocultación para constituir los objetos.Un rol se considera como un aspecto de un objeto, en el sentido de que contiene lasreferencias y las secuencias de acciones de un objeto que participa en una determinadaresponsabilidad.En el subapartado anterior se han estudiado diversas propuestas (TROLL [117],

Snoeck y Dedene en [209] y OASIS (v2.2) [176]) que tratan a los roles como espe-cializaciones dinámicas.La visión del rol como una instancia separada unida a un objeto ha sido tratada

por gran cantidad de autores, entre ellos destacan:Bachman y Daya [17] que en 1977 lo introdujeron en el contexto del modelo de

red. El descubrimiento se basó en la observación de que los tipos de registros exis-tentes parecían roles de otros, por ejemplo tenían que almacenar empleados, clientes,pacientes o estudiantes que eran roles de otro registro como persona. Para Bachmany Daya un rol es “un patrón de comportamiento que puede ser asumido por entidadesde diferentes tipos”. Los autores permitían que un rol fuese jugado por instanciasde diferentes tipos de entidades pero lo confundían con la posibilidad de que un rolpudiera ser jugado por diversas entidades a la vez. No consideraban la posibilidadde que los roles pudieran ser jugados por otros roles y no incorporan el concepto deidenti…cador de rol, como en la propuesta introducida en esta tesis.Kristensen y Osterbye en sus trabajos [119, 121], presentan una propuesta com-

pleta sobre roles. Esta propuesta, contrariamente a otras, propugna que el conceptode rol no es equivalente al de especialización dinámica. Los roles permiten especi…car


perspectivas especiales de un fenómeno (modelado por un objeto). Una perspectiva seutiliza por otros objetos del modelo como una forma restringida y selectiva de cono-cer y acceder a un objeto. Una perspectiva es un conjunto de métodos y propiedadesseleccionadas del objeto. Estas perspectivas se modelan mediante roles y puedencambiar dinámicamente. Estos trabajos presentan el concepto de rol como una nuevaabstracción conceptual distinta de las abstracciones como la especialización, la agre-gación y la asociación. Según los autores, el conocimiento se organiza en términos deroles, en términos de las diferentes perspectivas de un fenómeno y en la dinamicidadde sus propiedades. La extensión de un rol es un subconjunto de la extensión delobjeto asociado (como la especialización). Los roles se pueden especializar. Puedenser jugados por objetos y por otros roles. Pueden cambiar y pueden existir de ma-nera simultánea, pudiendo existir relaciones entre roles. El concepto de rol en estaaproximación es intuitivo y está poco formalizado. El objeto al cual se asocia un rolse le llama objeto intrínseco y sus métodos se denominan métodos intrínsecos. Losmétodos de un rol se de…nen cómo métodos extrínsecos y las instanciaciones de losroles se denominan instancias de rol.

La propuesta presentada por Kristensen y Osterbye introduce un tratamiento com-pleto a nivel estructural y de comportamiento, aportando además una notación grá…capropia en la cual se presentan los roles como adornos sobre la notación grá…ca querepresenta a los objetos. A nivel estructural un objeto visto a través de un rol tendrátodas las propiedades del objeto más las del rol. Desde una perspectiva conceptual elrol no oculta propiedades del objeto. En los roles se heredan las propiedades de losobjetos pero no pueden ser modi…cadas por los roles. Los autores presentan (como seha visto en el apartado metodológico) las relaciones entre las propiedades del objetointrínseco y de los roles (propiedades intrínsecas, propiedades extrínsecas y propieda-des de tipo rol). A nivel dinámico presentan una notación grá…ca para la descripciónde la dinámica de los roles para representar: secuencias de roles (las instancias delos roles existirán en una secuencia determinada), solapamiento (las instancias de losroles existirán de forma solapada), iteración y duplicación (de…nen casos especialespara el secuenciamiento y el solapamiento). Una de las características destacables quepresenta esta aproximación es la capacidad para transferir roles. Los roles se puedentransferir de un objeto a otro (un rol puede cambiar de objeto intrínseco) pero nopueden existir sin el objeto intrínseco.

Pernici en [181] describe un modelo de roles en el que un objeto puede jugar dis-tintos roles durante su ejecución y, enviar y recibir mensajes diferentes en las distintasetapas de su evolución. El concepto de rol se usa para modelar comportamientos deun objeto de forma separada. Un objeto puede jugar diferentes roles en momentosdiferentes y también puede jugar más de un rol a la vez. Pernici divide la especi…-cación de un objeto en diversas secciones llamadas roles. Cuando se crea el objetoentonces se crea un objeto especial llamado rol base y se instancian un número de-terminado de roles. Los roles pueden añadirse y eliminarse dinámicamente según sehaya de…nido en la especi…cación. No permite de…nir roles de roles, y no se consideraexplícitamente la cardinalidad de los roles ni su identi…cación. Permite la de…niciónde restricciones para modelar y determinar las posibles interacciones entre roles con-currentes. La asunción básica del modelo de roles es que las instancias de los rolesde un objeto evolucionan de forma independiente una de otra. Sin embargo, estaasunción debe restringirse para tener en cuenta posibles interacciones, coordinación y


con‡ictos entre mensajes realizados en diferentes roles, y entre distintos estados. Eltrabajo es muy interesante en este último aspecto. La interacción entre roles es unode los temas que la mayoría de aproximaciones no han tratado.Además de éstas, existen aproximaciones que combinan las distintas interpreta-

ciones. Steiner y Norrie presentan en [217] un modelo temporal para roles de objetos(”Temporal Object Role Model”). En esta propuesta los roles de objetos son agrupa-ciones de objetos representados por colecciones. Las asociaciones modelan relacionesentre objetos de ciertos roles y se representan mediante colecciones. Las colecciones seagrupan en estructuras taxonómicas que describen los roles relacionados en términosde grafos de especialización. Esta aproximación conjuga el papel de los roles en aso-ciaciones con su papel como subclases en una estructura taxonómica. Este enfoque esel defendido en esta tesis, ya que el hecho de formar parte de una estructura taxonómi-ca se debe compaginar con su participación en asociaciones. El modelo introducidosoporta la evolución de los objetos, en la que los objetos pueden cambiar sus roles enel tiempo. La evolución provoca la inserción en colecciones y cambios en los tipos.Mediante operaciones especí…cas de “vestir/desvestir” el objeto adquiere/deja nuevaspropiedades al tomar/abandonar el rol. A este fenómeno se le llama metamorfosis delobjeto, que implica un cambio de tipo cuando se adquiere un determinado rol. Losobjetos sólo pueden migrar en una misma estructura taxonómica. El modelo tem-poral permite “marcar” los objetos con un valor temporal introduciendo el conceptode oid temporal que permite conocer en qué momento ha existido un determinadoobjeto. La propuesta se centra en identi…car los efectos que se producen sobre lascolecciones al tomar o dejar un rol. En esta tesis, esto ayuda a identi…car patronesde comportamiento especí…cos. El trabajo no desarrolla cómo se adquiere o deja undeterminado tipo, ni analiza el efecto que tiene sobre su comportamiento. Otro as-pecto que diferencia la tesis de esta propuesta, es que en la tesis se estudia con mayordetalle cómo se produce la evolución, detectando patrones de comportamiento comola evolución horizontal y la extensión vertical.La propuesta que se presenta en la tesis interpreta el rol como una relación ta-

xonómica de naturaleza dinámica representada a través de una instancia separadaunida a un objeto (el jugador del rol). Siguiendo esta interpretación, se presentan acontinuación aqlgunas de las propuestas que apoyan esta línea de trabajo.MOSES [191] es un método orientado a objetos que se ha extendido para incor-

porar el concepto de rol, con la intención de introducir la clasi…cación dinámica ymúltiple en un método de modelado OO. Los roles se proponen como solución a lacomplejidad de los dominios de las aplicaciones de gestión. En esta propuesta los rolesson clases, y se presenta una notación grá…ca propia para especi…car que las clasesse están utilizando para modelar roles de otra clase. La utilización de los roles seincluye como una actividad adicional del método. Además incluyen patrones para suimplementación en EIFFEL. La propuesta es incompleta respecto a la propuesta enla tesis porque no soporta la especialización de los roles, ni que los roles puedan serroles a su vez de otros roles.ADOME [130] es un entorno que integra un sistema basado en reglas con un sis-

tema de gestión de bases de datos OO comercial (ITASCA). Esta propuesta extiendela capacidad de gestionar requisitos más complejos incorporando sistemas de reglaspara la gestión del conocimiento. En este caso se intenta capturar más semántica alnivel del sistema de reglas introduciendo el concepto de rol e implementándolo en el


sistema de reglas. Este concepto de rol está basado en la aproximación de Wieringa[238]. Aún tomando como referencia el modelo de Wieringa, esta aproximación intro-duce una característica no soportada por la aproximación de la tesis: el que un rolpueda ser adquirido por diversos objetos de clases no relacionadas por una relaciónde especialización. Los roles no se almacenan como objetos de la base de datos, sólolo hacen los objeto jugadores. En el sistema de reglas se encuentran de…nidos losatributos, los métodos de los roles y las reglas de transición entre estados al estilo dela propuesta introducida por Pernici. Esta es una aproximación compleja ya que pre-senta una arquitectura de implementación (sistema basado en reglas en combinacióncon SGBDOO), que di…culta la implementación de los roles.DOOR [242] es una aproximación similar a ADOME, aunque incorpora la idea de

la transferencia de roles introducida por Kristensen y Osterbye. DOOR ve los rolescomo puentes entre propietarios de roles y jugadores de roles. El propietario de un roles un objeto con un atributo del tipo del rol. Las propiedades de un rol pueden serespeci…cadas por el propietario sin que el objeto (jugador) esté asignado al rol. Estaspropiedades las adquiere el objeto una vez asume el rol y las pierde cuando deja elrol. En ese momento el rol está vacante y preparado para ser jugado por otro objeto.MON [143] es una notación grá…ca que incorpora roles. Los roles son clases y

están relacionadas con la clase que juega el rol mediante una relación de rol. Los rolesheredan de sus clases jugadoras. La relación de rol puede tener aserciones asociadas:precondiciones, postcondiciones e invariantes. La notación grá…ca permite asociar res-tricciones sobre la asociación dinámica de los roles a los objetos, pudiendo especi…carsi los roles pueden ser mutuamente exclusivos o se pueden jugar simultáneamente.Es importante destacar que dos de las mayores diferencias existentes entre estas

propuestas y la propuesta de la tesis son: el amplio tratamiento a nivel metodológicoy de implementación que se da en ésta a los roles.Para …nalizar se analizan tres de las últimas aproximaciones que han aparecido

en esta área de estudio y cuya interpretación del concepto de rol no se enmarcadirectamente en ninguna de las cuatro categorías detectadas inicialmente.LODWICK [214] es un lenguaje formal orientado al modelado de roles. Esta

aproximación propone un lenguaje lógico de tipos ordenados para especi…car roles.La propuesta formal es básica, siendo la intención del autor la construcción de unaaproximación que sea fácilmente integrable en UML. Propone que los roles ocupenlos lugares de las relaciones, y la intensión del rol captura en qué relaciones puedeparticipar un objeto para ser considerado un rol. Esta propuesta introduce a losroles como tipos que no pueden ser instanciados. Las propiedades de los roles lasheredan los tipos que juegan dicho rol en una relación. Un objeto puede jugar distintosroles simultáneamente, ya que puede jugar tantos roles como asociaciones en las queparticipe. Además puede jugar el mismo rol simultáneamente tantas veces comorelaciones de la misma asociación se permitan (dependiendo de la cardinalidad). Enesta aproximación no se pueden de…nir roles de roles. Un objeto jugando un rol semodela como un objeto participando en una relación en el lugar del rol. Se especi…caráun rol y se le asociará una lista de todos los tipos que puedan jugar dicho rol, sede…nirá una jerarquía de roles independiente de la jerarquía de tipos. Esta es unaaproximación compleja de modelar por la necesidad de declarar jerarquías de rolesindependientes que es una práctica poco habitual en el modelado. Otro inconvenientees la incorporación de estas ideas a UML (en UML el término rol se utiliza para


tres propósitos como se ha comentado anteriormente, el propósito 1 y 3 entran encon‡icto porque LODWICK no distingue entre nombres de …nales de asociaciones yespeci…cadores de tipo en colaboraciones (llamados “classi…er roles”)). El problemasurge cuando se intenta especi…car una colaboración UML con LODWICK porque los…nales de las asociaciones no coinciden con los clasi…cadores de roles. En el trabajose muestra un ejemplo del problema que se resuelve modelando los clasi…cadores deroles como subroles de los nombres de asociación en los que participan.

Steimann (el mismo autor de LODWICK) ha publicado recientemente un trabajo[215] que sigue la línea del anterior. En este trabajo equipara los roles a los interfaces,y propone una modi…cación del metamodelo de UML para llevar a cabo su propuesta.Las ideas introducidas son ambiciosas pero implican un cambio importante en la no-tación, por lo que parece difícil su aceptación por parte de la comunidad de modeladoOO. El autor sugiere que los roles sean especi…caciones parciales de los objetos que losjuegan y que los roles clasi…can a los objetos de forma dinámica y múltiple (clasi…ca-ción basada en roles). Los objetos pueden jugar diversos roles de acuerdo a diversasespeci…caciones parciales. Estas especi…caciones juntas, constituyen la especi…cacióntotal de las clases de las cuales los objetos son instancia. También sugiere que un rolpueda ser jugado por instancias de clases diferentes que no estén relacionadas por he-rencia, siendo la relación de rol independiente de la implementación. De esta forma elautor justi…ca que los roles y los interfaces son el mismo concepto. En esta propuestael autor requiere que todas las asociaciones terminen en roles, lo que puede causar unaacumulación masiva de nombres en los …nales de asociación que complique el modelo.Además, existirán clases que tendrán un solo rol que especi…que completamente a laclase. Esto hará difícil entender porqué son necesarios dos nombres (uno para la clasey otro para el rol). Al ser el rol un interfaz, no se podrá de…nir un estado especí…co(y separado) para cada rol que juega el objeto, incluso para distintas ocurrencias delmismo rol. Otro inconveniente es que las clases que implementan muchos roles seránmuy grandes y poco reutilizables. Por último, es importante resaltar que la utiliza-ción de interfaces, hace que esta propuesta se pueda considerar como una solución dediseño e implementación y no de modelado conceptual.

Por último, en el estándar ISO/IEC 15414 del modelo de referencia ODP [110]introduce conceptos para la especi…cación de sistemas de información desde el puntode vista de la empresa. En este marco se introduce otra de…nición del concepto de rol.Según el marco, un rol identi…ca la abstracción de un comportamiento determinadoen una comunidad de objetos. Todas las acciones de un rol se asocian con el mismoobjeto. Cada acción es parte del comportamiento de un rol. Los roles se utilizanpara descomponer el comportamiento en partes que pueden ser desempeñadas porun objeto. Para que un objeto desempeñe un determinado comportamiento debeasignársele un rol. Durán y Vallecillo en su trabajo [68] modelan/implementan losconceptos presentados en el marco de referencia anterior sobre el lenguaje Maude. Enesta aproximación un rol se modela mediante una clase de Maude, cuyas instanciasson objetos que exhiben el comportamiento asignado al rol. Los objetos de un sistemason modelados por objetos de clases Maude. En Maude cada objeto pertenece a unaclase. La clase de un objeto se obtiene por la composición mediante herencia múltiplede todas las clases que modelan los distintos roles que un objeto puede jugar. En estaaproximación, al utilizar la herencia múltiple para de…nir la clase de un objeto, dichoobjeto posee todas las propiedades de todos los roles aunque no los esté jugando, no


pudiéndose de…nir estados especí…cos para cada rol.

3.2 Relaciones Taxonómicas en el Espacio de la So-lución

En este apartado se revisan algunas técnicas de diseño e implementación que tratan derepresentar en el Espacio de la Solución los distintos tipos de relaciones taxonómicas.Estas propuestas se pueden dividir en dos grupos:

1. Trabajos pertenecientes a lo que se ha llamado programación conceptual [120],en la que la programación se ve como “un proceso de modelado donde las abs-tracciones se presentan como construcciones del lenguaje de programación”. Es-tas aproximaciones introducen extensiones a nivel de lenguaje de programaciónpara dar soporte a las abstracciones conceptuales presentes en las técnicas demodelado conceptual.

2. Técnicas basadas en patrones de diseño que proponen estructuras de diseñocomplejas, utilizadas para representar en el Espacio de la Solución todo tipo derelaciones taxonómicas.

3.2.1 Programación Conceptual y Extensiones de los Lengua-jes de Programación

En esta área de trabajo la mayoría de extensiones de los lenguajes de programaciónintentan ofrecer nuevos modelos de subclases dinámicas y roles, ya que la especia-lización estática puede soportarse directamente con la herencia de los lenguajes deprogramación OO.Gottlob et al [81] presentan una extensión de SMALLTALK para incorporar roles

en dicho lenguaje. En esta extensión las jerarquías de roles se enlazan con las clasesde la jerarquía de clases del sistema. Las instancias de una clase o de sus subclasespueden asumir o dejar dinámicamente los roles. Se ha introducido una modi…caciónde la prueba de identidad de SMALLTALK que permite a los roles (como entidadesseparadas) sustituir a los objetos de los cuales son roles. Los roles pueden exhibircomportamientos especí…cos. Los roles restringen el acceso a un contexto en particu-lar, por ejemplo, un atributo de un rol no es accesible si se accede a la superclasecomo otro rol distinto. En la misma clase de rol un objeto puede jugar a la vez distin-tos roles. Esta propuesta presenta una re‡exión interesante sobre la identidad de losobjetos debido a que las entidades del mundo real se representan mediante diversosobjetos. Introduce la identidad de la entidad y la identidad del rol con la intención depoder identi…car a los roles de forma distinta. Estos conceptos se unen en lo que llamaequivalencia de entidades (dos instancias son equivalentes si se corresponden con lamisma entidad en el mundo real, esto se deduce en el sistema si ambas compartenuna instancia raíz en la jerarquía). Ésta es una buena aproximación para entender elproblema del conteo y de la identi…cación de los roles en la propuesta presentada en latesis, aunque no permite especi…car múltiples grupos de roles y no de…ne restriccionesde cardinalidad sobre el rol y el objeto que lo juega.

3.2. Relaciones Taxonómicas en el Espacio de la Solución 73

Subjects, la aproximación que presentan Harrison y Ossher [100] introduce un con-cepto muy parecido al signi…cado real del término rol (la conducta que un grupo esperade cada uno de sus miembros según la forma cómo se produce su inserción en él). Estaaproximación modela cómo los distintos agentes de un sistema pueden ver al mismoobjeto desde distintas perspectivas. Los agentes tienen una visión …ltrada del objeto,y alguno de los métodos del objeto están allí simplemente porque constituyen una delas perspectivas de un agente. Normalmente el criterio para decidir qué propiedadesde los fenómenos del mundo real se incluyen en un modelo está basado en una únicaperspectiva. En esta aproximación, el objeto visto desde distintas perspectivas escomo si adquiriera un rol distinto por cada tipo de agente.Albano et al. [2] introducen el concepto de subclase dinámica bajo el nombre

de rol en su lenguaje de modelado de datos Fibonacci. Cada tipo de objetos es laraíz de una jerarquía de roles llamada familia de roles. Un objeto está constituidopor un conjunto de roles. Los roles se pueden adquirir dinámicamente pero sólo unopor tipo de rol. Un gestor de mensajes resuelve los mensajes que le llegan al objetoenviándolos al rol adecuado. Si el mensaje no lo puede responder ninguno de los roles,el sistema busca el rol más especí…co debajo del objeto en la jerarquía de herencia. Sihay más de un rol se elige para responder el mensaje el rol que se ha adquirido másrecientemente. Los tipos de roles se pueden de…nir en Fibonacci de forma dinámica.Los roles especi…can sólo signaturas, no implementaciones, por lo que la adquisiciónde un rol requiere la especi…cación de una implementación de la signatura. Así puesinstancias diferentes del mismo tipo de rol pueden comportarse de forma distinta.Taivalsaari [221] de…ne el modo de una clase como una implementación de las

operaciones proporcionadas por la clase. Cada clase puede tener varios modos, enlos cuales reacciona de forma diferente a los mensajes que le llegan. Por ejemplo laclase VENTANA puede tener los modos ABIERTA, CERRADA e ICONO, y cadauno de estos modos reaccionará de forma diferente a los mensajes abrir, refrescar yconvertir_en_icono. Los modos pueden proporcionar operaciones especí…cas de losmodos que no estén de…nidas en la clase de la cual es modo. Hay dos formas de cambiarun modo: (1) mediante eventos explícitos de transición entre modos y (2) mediantetransiciones de modos implícitas generadas por el efecto de otras operaciones. Lassubclases heredan los modos de sus superclases. Sólo se permite herencia simpledebido a la complejidad de la interacción entre las clases y los modos de una jerarquíade herencia. Los modos básicamente son equivalentes a lo que en la aproximación deesta tesis se llaman especializaciones dinámicas.En el trabajo de Richardson y Schwarz [192] se presenta una nueva construcción

del lenguaje de programación llamada aspect. Los aspectos son como roles en elsentido de que se asocian a los objetos de forma dinámica y sirven para modelar laclasi…cación dinámica de los objetos. Los aspectos se presentan como construccionesdel lenguaje de programación sin tratar ningún aspecto de modelado y de diseño. Elaspecto no hereda las propiedades del objeto jugador (llamado intrínseco). Si existenpropiedades del objeto intrínseco a las que el objeto debe tener acceso, entonces debenexportarse explícitamente al aspecto. Los aspectos en este enfoque más que un tipo deespecialización (como pueden verse los roles) parecen un tipo especial de agregación,en la cual se pueden añadir partes nuevas al objeto existente. Aunque no de…nenidenti…cadores explícitamente, los aspectos y los objetos tienen distintos criterios deidenti…cación. Se permite que los aspectos tengan aspectos pero no que un objeto


pueda jugar múltiples aspectos de un mismo aspecto a la vez. La instanciación de unaspecto siempre requiere de una instancia de la clase que extiende.Sciore en [200] introduce los roles en un sistema basado en prototipos. En el

lenguaje que presenta no hay nombres de clases y los objetos deben crearse clonándolosa partir de una plantilla. Todos los objetos del sistema se consideran roles. Losobjetos están relacionados unos con otros mediante una especie de relación jugado-por. Un rol puede delegar la respuesta a un mensaje a su objeto jugador en el árbol derelaciones. El analista puede de…nir objetos que actuarán como una especie de claseque se utilizará como plantilla para la creación de otros objetos. La cardinalidad decada rol es como mucho uno (un objeto sólo puede jugar un rol de cada clase), porlo que no permite cardinalidad múltiple. La aproximación de Sciore presenta unaestructura de objetos muy compleja. En la aproximación de esta tesis se utiliza unsistema basado en clases y se incorpora la delegación, como se usa en los sistemasbasados en prototipos.

3.2.2 Patrones de Diseño

Peter Coad en una entrevista sobre su libro Java Design [48] decía “...los objetosserán recordados por constituir un paso esencial en el camino hacia el cambio en laforma de desarrollar software ‘de la construcción desde la nada’ hacia ‘la construccióna partir de partes’..... La composición es más ‡exible y resistente a los cambiosque la herencia. Si heredamos responsabilidades tenemos que cargar con ellas, sicompongo sobre responsabilidades, yo puedo desconectarlas y conectarlas con otrascomponentes”. Este párrafo re‡eja cómo la herencia como mecanismo de diseño eimplementación genera dudas razonables sobre su utilidad porque en muchas ocasionesproduce desarrollos poco ‡exibles. Esto hace que muchas técnicas de diseño (como seve a continuación y a lo largo de la tesis) utilicen la composición para implementarla especialización conceptual. A pesar de todo, estos razonamientos no ponen enduda la aplicabilidad y la utilidad de la especialización como mecanismo esencial enel modelado conceptual OO.Además de las aproximaciones vistas en el apartado anterior, en el mundo de los

patrones de diseño se están desarrollando diversos patrones que intentan representarlos distintos patrones conceptuales mediante estructuras de diseño independientes dellenguaje de programación. Los patrones de diseño constituyen en el ámbito de estatesis una herramienta esencial para abordar el proceso de generación automática decódigo. No pueden aplicarse de forma directa al proceso propuesto en este trabajo,pero mediante un proceso de especialización se adaptan para dar soporte a las caracte-rísticas estructurales y de comportamiento de las relaciones taxonómicas introducidasen esta tesis. A continuación se revisan algunas de las aproximaciones relacionadascon el trabajo desarrollado en la tesis.En el libro de Fowler [75] se presenta una primera introducción a las técnicas

comúnmente utilizadas en la implementación de patrones conceptuales como la espe-cialización (banderas, delegación a una clase oculta, State), la asociación y la agre-gación. El patrón State [78] es un patrón de comportamiento que permite simularla alteración del comportamiento de un objeto si se producen cambios internos en suestado, con lo que se puede simular que el objeto cambie de clase. Ésta es la solu-ción más elegante y que mejor se ajusta a la semántica de la especialización dinámica

3.2. Relaciones Taxonómicas en el Espacio de la Solución 75

presente en la aproximación introducida en la tesis. El patrón State además poseediversas extensiones [69] (owner-driven transitions, data members) y algunas varia-ciones [154] que integran el patrón con otros existentes para construir estructuras dediseño más complejas. Estas aproximaciones pueden servir para especializar el patrónhasta construir una estructura de diseño que se adapte totalmente a las necesidadesde implementación. En ocasiones el patrón State será adecuado para implementarciertos tipos de roles cuya semántica es más cercana a la especialización dinámicapresentada en esta tesis.Otro patrón interesante es el Decorator [78] cuyas clases participantes se corres-

ponden con los conceptos de objeto jugador (ConcreteComponent) y rol (Decorator).Este patrón resuelve la necesidad de asociar responsabilidades adicionales a un objetode forma dinámica. Esto se consigue “envolviendo” (mediante agregación) el objetocon un nuevo objeto (el decorador) que le proporciona las nuevas responsabilidades.Este patrón puede servir para implementar el concepto de rol presentado en esta tesis,aunque debe extenderse para garantizar que no se instancien las clases decoradorasindependientemente de la existencia de un componente concreto.En el trabajo de Schoenfeld [199] aparece por primera vez un patrón de diseño para

la implementación de roles en un dominio especí…co: el de las Personas y los roles queéstas pueden jugar. Mejorando estas aproximaciones Baumer et al [22] introducen elpatrón Role Object, que constituye el punto de referencia en patrones de diseño para laimplementación de los roles. Este patrón pretende adaptar un objeto a las diferentesnecesidades de los clientes, mediante roles asociados de forma transparente al objetojugador. El objeto jugador gestionará su conjunto de roles de forma dinámica. Estepatrón se adapta perfectamente a las necesidades de implementación del concepto derol de esta tesis. Los autores presentan posibles variaciones para solucionar diversosproblemas que pueden surgir al intentar captar en la implementación toda la semánticade los roles. Esta aproximación se ha utilizado de forma exitosa en el desarrollo degrandes proyectos software como el sistema bancario GEBOS [20, 72]. El patrónExtension Object [77] también puede ser una solución interesante a la implementaciónde roles. De hecho Zhao y Foster [245] lo utilizan en el desarrollo de un sistema detransporte, aunque no resuelve el tratamiento de forma transparente del rol y eljugador. Fowler en [76] proporciona cinco variaciones del patrón Role Object paraadaptarlo a los diferentes tipos de semántica que poseen los roles existentes en elmodelado conceptual. De forma paralela a estos trabajos Doug Lea en [126] presentauna serie de patrones de diseño para la implementación de roles, aunque basados enla propuesta de OOram [190].Uno de los últimos trabajos importantes en la implementación de roles es el que

presentan Zhao y Foster [246]. En este trabajo, su experiencia en el desarrollo de sis-temas de redes de transporte público les ha llevado a la utilización masiva de técnicasbasadas en roles (Extension Object y Role Object) para implementar sus sistemas.En esta aproximación se justi…ca que las técnicas utilizadas no son su…cientementepotentes cuando tienen jerarquías de roles de varios niveles y relaciones entre rolesde la jerarquía a distintos niveles. La solución es el patrón Cascade, que es unaextensión del patrón Composite [78]. El patrón Cascade es una abstracción que re-presenta objetos en una estructura de árbol, donde cada nivel del patrón es un patrónComposite.Éstas son las aproximaciones más relevantes para la implementación de especiali-


zaciones dinámicas y roles. Estas técnicas se pueden adaptar de forma sencilla paraimplementar las especializaciones estáticas porque se pueden considerar como un casoparticular de la especialización dinámica. Además de los patrones de diseño presen-tados en este apartado, en la aproximación que se presenta en la tesis se incorporaránotros patrones de diseño como el Template Method y el Mediator [78] para poderimplementar la estrategia de ejecución de OO-Method.Para …nalizar este apartado es conveniente re‡exionar sobre el uso que se hace en

estas técnicas de la composición (o agregación) y de la herencia. Estas técnicas propor-cionan herramientas para representar a los distintos tipos de relaciones taxonómicasen el espacio de la solución. El denominador común de éstas es el uso exhaustivode la composición como técnica de implementación. Esta situación a efectos prác-ticos provoca que muchas veces los desarrolladores confundan la composición con laespecialización a nivel conceptual. La tesis también aporta claridad en este contextoporque apuesta por el uso a nivel conceptual de las abstracciones adecuadas (en estecaso las relaciones taxonómicas), proporcionando implementaciones de calidad quehacen uso de la composición de forma transparente al modelador.

3.3 Métodos de Producción Automática de Soft-ware

Los dos primeros apartados de este capítulo han introducido aquellos trabajos rela-cionados con las relaciones taxonómicas en el Espacio del Problema y el Espacio dela Solución. Para …nalizar queda por revisar aquellos trabajos que al igual que éste,proporcionan métodos para la producción automática de software, abordando cómollegar de forma automatizada del Espacio del Problema al Espacio de la Solución.Este apartado se divide en dos secciones: la primera analiza aquellos métodos de

generación de código basada en modelos relacionados con la aproximación introducidaen esta tesis, y el segundo apartado se centra en propuestas más especí…cas que,proporcionando generación de código, utilizan patrones de diseño como mecanismode ayuda a la producción automática de software.

3.3.1 Generación de Código Basada en Modelos

En el campo de la generación automática de código basada en modelos existen, como seha comentado previamente, tres aproximaciones: estructural (genera código a partirde modelos estructurales), de comportamiento (genera código a partir de modelosdinámicos) y de traducción. En esta última categoría se sitúa la propuesta de la tesis,por lo que a continuación se analizan las propuestas más relevantes de dicha categoría.Una de las aproximaciones que sigue el enfoque de traducción es OBLOG CASE

[152] una herramienta basada en el lenguaje de especi…cación formal OBLOG, quepropone un proceso de generación automática de código basado en la reescritura dereglas en un determinado lenguaje que el diseñador debe conocer. El proceso quepresenta OBLOG CASE para implementar un sistema se descompone en tres dimen-siones: (1) el dominio del problema a resolver, (2) la arquitectura del sistema elegidapara su implementación y (3) el entorno software. OBLOG es el lenguaje de modeladodel dominio y ofrece independencia de las otras dos dimensiones. El modelo concep-

3.3. Métodos de Producción Automática de Software 77

tual en el lenguaje OBLOG se almacena en un repositorio. Las otras dos dimensionesse llevan a cabo mediante un conjunto de reglas (en un lenguaje de script) que de…nencómo navegar a través del modelo almacenado en el repositorio, permitiendo extraerla información relevante y producir la implementación del sistema software en un de-terminado lenguaje de programación y en una determinada arquitectura. Aparte delas diferencias expresivas entre OBLOG y OASIS, la utilización de reglas hace queésta sea una aproximación muy diferente a la propuesta en esta tesis. Ésta es unaaproximación abierta en la cual los diseñadores desarrollan su propio proceso de gene-ración, el problema es que la herramienta no puede garantizar la calidad del softwareproducido, y el resultado …nal depende de muchos factores, entre ellos que los des-arrolladores entiendan bien la semántica de los elementos del lenguaje OBLOG y quesean unos buenos arquitectos e implementadores. Además un problema adicional esque las reglas embeben conjuntamente aspectos de arquitectura y de implementación.La aproximación de esta tesis es general y cerrada, garantizando una representaciónsoftware funcionalmente equivalente al modelo conceptual.TBench es la herramienta CASE asociada a TROLL. TBench proporciona un pro-

ceso de prototipado que permite la generación de prototipos ejecutables a partir deuna especi…cación grá…ca. El prototipo generado es un programa C++ que incorporalos aspectos dinámicos y estáticos del sistema. Esta aproximación comparte con OO-Method que posee un lenguaje de especi…cación formal OO como base de la notación(OASIS para OO-Method, TROLL para OMTROLL). La principal diferencia es queTBench se centra en la validación de especi…caciones y en el desarrollo de una herra-mienta para la comprobación de modelos; mientras que en esta tesis se proporcionauna implementación de un modelo de ejecución abstracto para obtener un productosoftware preparado para su implantación.Otra aproximación interesante es el Diseño Recursivo de Shlaer y Mellor [207]

soportado por la herramienta BridgePoint. Este método no utiliza un lenguaje deespeci…cación formal. Propone el modelado del dominio del problema y el modeladode la arquitectura de la aplicación con la misma notación. A partir de los modelosconceptuales del dominio y de la arquitectura se desarrollan una especie de patronesque llaman “archetypes” (una especie de macros) que el diseñador debe especi…carutilizando un determinado lenguaje de programación (puede ser el lenguaje de pro-gramación destino) mediante los cuales se de…nen plantillas que en el proceso degeneración de código se aplicarán a los modelos almacenados. La generación de códi-go es un nuevo proceso que debe de…nir el desarrollador a través de un script. Denuevo este tipo de herramientas permiten generar código aunque es el desarrolladorel que ha de incorporar las reglas de traducción. De nuevo ésta es una aproximaciónabierta en la que la calidad del producto generado depende del desarrollador.Una de las últimas propuestas en este campo es el método xUML y su herramienta

CASE iUML [44]. xUML es un subconjunto de UML que incorpora un lenguaje deespeci…cación de acciones. Este lenguaje proporciona toda la lógica condicional y lasacciones primitivas para manipular el modelo de objetos de UML, permitiendo a losdesarrolladores construir modelos del sistema que sean ejecutables, y utilizar estosmodelos para producir código. xUML exige que los modelos estén completos parapoder ejecutar satisfactoriamente un conjunto de pruebas asociadas. xUML es unper…l5 ejectuable para UML. Para construirlo se ha elegido un subconjunto de UML

5del inglés ”pro…le”.


para el cual es posible asociar una semántica ejecutable. Con ello se pretende que losdesarrolladores sólo utilicen un subconjunto de las técnicas que proporciona UML.Desde este último punto de vista xUML es muy parecido a OO-Method aunque esteúltimo proporciona un “lenguaje de especi…cación de acciones declarativo” (OASIS).Las mayores diferencias se sitúan en cómo aborda xUML el proceso de generación decódigo. xUML con la información de modelado consigue producir prototipos ejecuta-bles con el propósito de ser validados. Estos prototipos no son evolutivos, si se deseaproducir código …nal, los modelos se deben enriquecer con información de diseño, porlo que se exige que el modelador construya modelos de diseño (basados en patronesde diseño) y los enlace con los modelos conceptuales, instanciando adecuadamente di-chos modelos; todo ello de forma manual. iUML proporciona herramientas para queel desarrollador pueda construir generadores de código para tipos de proyectos espe-cí…cos. La propuesta de la tesis mejora esta etapa realizando de forma automática lageneración de código, incorporando e instanciando los patrones de diseño necesariospara producir software de calidad totalmente operativo.En la propuesta Extreme Modeling [30] se aplican las ideas de la programación

extrema [23] a la etapa de modelado conceptual para construir un método que generaprototipos en un intérprete de Redes de Petri. Esta aproximación utiliza los modelosde UML para generar automáticamente prototipos ejecutables para su validación rápi-da. Un compilador de modelos que traduce a Redes de Petri especializadas toma losdiagramas UML como entrada para la generación del prototipo. Este trabajo di…erede la aproximación de la tesis en que la generación de código no obtiene un productosoftware …nal en entornos de desarrollo industriales, realizándose la validación sobreprototipos declarativos y de naturaleza desechable.Harel en [97] presenta sus experiencias con la ejecución de modelos y la genera-

ción automática de código utilizando herramientas como: Statemate de I-Logix, yactualmente ObjectTime y Rhapsody. Debido a su larga experiencia con el modeladoconceptual y con el desarrollo de notaciones formales ejecutables, el autor augura queen un futuro muy próximo se podrán conseguir métodos de generación automáticade software, que a partir del modelado de casos de uso y de escenarios, y utilizan-do notaciones formales como LSC6 (una extensión de los Diagramas de Secuencia)[61] podrán producir software de forma automática. Aunque Harel se centra en lageneración de código basada en el comportamiento de sistemas de tiempo real, es-ta referencia se considera relevante porque augura el camino hacia el cual se estádirigiendo actualmente OO-Method.

3.3.2 Generación de Código Basada en Patrones de Diseño

En el campo de la generación de código existen algunas propuestas que basan su méto-do de generación en la aplicación de patrones de diseño. Algunas de las propuestasmás interesantes se analizan a continuación.Altermeyer et al. [8] proponen un método para el desarrollo de software basado en

generadores y con soporte para la reutilización. El entorno asociado a este método sellama MOOSE (Model Based Object Oriented Software generation Environment). Lapropuesta es un método de desarrollo de software especí…co del dominio. Los dominiosen los que se aplica la propuesta son restringidos para poder de…nir estrictamente la

6Del término inglés Live Sequence Chart

3.3. Métodos de Producción Automática de Software 79

semántica de los modelos utilizados. El método no proporciona generación de códigoal 100%. El enfoque que sigue es el siguiente: es un método centrado en el modelado yen la reutilización, que proporciona generación automática de código de forma parcial.Los modelos con los que trabaja son:

² un modelo base: constituye las partes generales de un dominio de aplicación queson compartidas por todas las aplicaciones del dominio especí…co, es indepen-diente de la aplicación,

² un modelo componente: representa en una determinada notación (ER7, DTE8)un aspecto del sistema (estático, dinámico)), el modelo base estará compuestopor distintos modelos componentes,

² la cola de pegar (”glue”): modela las interrelaciones entre los modelos compo-nentes. Estas interrelaciones se dan mediante agregaciones, asociaciones, espe-cializaciones o mediante patrones de diseño. El propósito es documentar lasinteracciones existentes entre los componentes,

² un modelo de aplicación: incluye todos los modelos componentes de una apli-cación. Consiste de un modelo derivado del modelo base junto otras partesnecesarias para modelar completamente la aplicación.

² las características: contienen todos los cambios que se han realizado sobre elmodelo base para conseguir el modelo de la aplicación.

El proceso de desarrollo ha de generar estos modelos a la herramienta de gene-ración, junto con una biblioteca de primitivas dependientes del problema a resolver,un modelo de arquitectura y unas heurísticas para la selección apropiada de estruc-turas. Con ello genera unas plantillas de clases con constructores y destructores deobjetos, métodos de acceso, de comparación entre objetos, de creación y destrucciónde relaciones, y de recuperación y almacenamiento de datos. El código generadodebe modi…carse a mano para que sea funcional, debiendo implementar el resto delcomportamiento.La aproximación presentada mejora las aproximaciones estructurales pero no ge-

nera el comportamiento. Es una solución dependiente del dominio y orientada a lareutilización de modelos, no propone una notación de modelado estándar por lo queel generador depende de los modelos utilizados. Además sólo genera C++ y VisualWorks.Siguiendo los trabajos de MOOSE existe un generador llamado PSiGene (Pattern

Based Simulator Generator) [104] que permite generar código en dominios reducidosy bien de…nidos, a base de especi…car patrones muy concretos mediante un lenguajeformal, con la intención de almacenarlos en un repositorio y aplicarlos en el procesode generación. Estos patrones se instancian en el proceso de generación de código apartir de la información de modelado. El entorno es un generador de código altamentedependiente del dominio (en este caso centrando en la construcción de simulaciones entiempo real). Para un dominio muy limitado consigue generar el 100% de código. Estegenerador combina los objetos de simulación modelados en el modelo de clases con

7Entidad Relación8Diagrama de Transición de Estados


funciones de simulación, bibliotecas grá…cas, modelos de arquitectura, etc... La uniónde estos distintos modelos se realiza a través de lo que llaman cola de pegar (”glue”en inglés), que es un conjunto de patrones de simulación (parecidos a patrones dediseño) que de…nen cómo se relacionan los distintos modelos y que están especi…cadoscomo plantillas en Smalltalk. PSiGene genera código en Visual Works. La utilizaciónque hacen de los patrones en esta propuesta es diferente a la aproximación presentadaen esta tesis, porque para poder realizar el enlace entre los elementos de modeladocon los patrones de simulación, éstos deben tener la misma estructura que el modeloconceptual. Además de ser dependientes completamente del dominio, los patronesutilizados no son patrones estándares.Una diferencia importante de ambas aproximaciones con la que se presenta en

este trabajo, es que proporcionan generadores en dominios muy especí…cos (a lo quellaman generadores de componentes), por lo que la aproximación de la tesis se situaríaen el mundo de los generadores universales orientados a aplicaciones de gestión.Budinsky en [36] propone una herramienta para la generación de código a partir de

patrones de diseño. Ésta es simplemente una herramienta de ayuda a la instanciaciónde patrones, siendo además necesaria la codi…cación manual para su utilización en laimplementación de sistemas. El trabajo describe la arquitectura y la implementaciónde una herramienta que automatiza el proceso de implementación de patrones dediseño. El usuario proporciona a la herramienta información especí…ca del dominio dela aplicación para un determinado patrón y a partir de dicha información genera todoel código posible extraído de las especi…caciones presentadas en el libro de Gamma etal. [78].En el campo de la generación de código basada en el comportamiento, el trabajo

Statelator [24] combina la transformación de modelos con la utilización de patronesde diseño. En esta aproximación el autor representa un diagrama de transición entreestados de UML (”statechart”) mediante una microarquitectura basada en el patrónde diseño State. A partir de esta solución especí…ca, el autor induce un algoritmogenérico de transformación y lo especi…ca mediante OCL, capturando las reglas quetransforman un modelo de más alto nivel de abstracción a uno de menor. Estaaproximación es interesante y se puede trasladar a la propuesta introducida en latesis, aunque en ésta no se utiliza OCL para documentar la transformación. Estasolución sólo genera el comportamiento de una clase basándose en el diagrama detransición entre estados, algo que está presente en Rhapsody y que introdujo Harelen [98].

3.4 Conclusiones

Este capítulo ha presentado los trabajos más recientes y relevantes en el tratamientode las relaciones taxonómicas a nivel conceptual (en el Espacio del Problema) y anivel de implementación (en el Espacio de la Solución), así como aquellos métodosde producción automática de software que poseen enfoques similares al propuesto enesta tesis.La principal conclusión que se obtiene es que, pese a la cantidad de trabajo refe-

renciado, actualmente no existen aproximaciones como la que se propone en esta tesis,que sean capaces de cubrir adecuadamente todo el proceso de producción de software.La propuesta que se presenta permite abordar completamente la transición automáti-


ca de las relaciones taxonómicas desde el Espacio del Problema hacia el Espacio dela Solución, mediante la aplicación de técnicas basadas en patrones como elementosclave en el proceso de modelado y de generación de código. Los trabajos revisadosintroducen propuestas que sólo tratan de dar solución a problemas en un determinadonivel de abstracción, algunas centradas en problemas del Espacio del Problema (sinconsiderar el Espacio de la Solución) y otras centradas en el Espacio de la Solución(sin considerar el Espacio del Problema).En el Espacio del Problema se presentan trabajos que proporcionan soluciones

metodológicas y a nivel de modelado conceptual que introducen nuevos modelos derelaciones taxonómicas.En lo que concierne a las soluciones metodológicas se hace patente la necesidad de

proporcionar guías que ayuden a construir modelos taxonómicos de calidad, aunqueno existe un consenso sobre qué tipo de mecanismos utilizar para trasladar a la prác-tica habitual este tipo de guías. Las aproximaciones más teóricas no se preocupan pordesarrollar mecanismos que pongan en práctica sus ideas, y las aproximaciones másaplicadas no proporcionan guías bien fundamentadas. En esta tesis se da solución aestas carencias conjugando propuestas teóricas con aplicadas, mediante el desarrollode un marco conceptual de referencia que sirve para determinar las propiedades esen-ciales de las relaciones taxonómicas. Además, se introduce una guía de modelado quefacilita la aplicación de un lenguaje de patrones mediante una estructura navegacionalbasada en preguntas, ambos construidos haciendo uso del marco conceptual propues-to. Estos elementos ayudarán al analista en el proceso de modelado de relacionestaxonómicas.En lo que respecta al modelado conceptual OO y los modelos de relaciones ta-

xonómicas, se presentan aproximaciones informales y formales, unas más expresivasfrente a otras menos expresivas, unas más complejas y menos aplicadas frente a otrassencillas y muy aplicadas. En esta área de trabajo se detecta la necesidad de ofre-cer patrones conceptuales expresivos y precisos a la vez, haciendo uso de notacionesestándar para que puedan aplicarse en la práctica. Esto es consecuencia de la existen-cia de un número considerable de aproximaciones que utilizan términos distintos paraexpresar el mismo concepto y viceversa, por lo que se necesita llegar a un consensoque proponga un modelo taxonómico único (cosa poco probable) o proporcionar unmarco de referencia (solución aportada en esta tesis) que permita caracterizar, utili-zando una terminología única, las propiedades estructurales y de comportamiento delas subclases, para comparar la expresividad de las distintas aproximaciones. Parasolucionar estas necesidades, en esta tesis se presenta un modelo de relaciones taxo-nómicas que pretende ser preciso y expresivo, proporcionando guías claras de cómodebe ser utilizado en la etapa de modelado conceptual, y haciendo uso de la notaciónestándar UML para facilitar su aplicación en la práctica.Una característica común de todas las propuestas situadas en el Espacio del Pro-

blema que se han presentado es que ninguna de ellas proporciona procesos completosde generación de código como lo hace esta tesis.En el Espacio de la Solución se presentan trabajos en el área de la programa-

ción conceptual, donde se analizan lenguajes de programación que incorporan nuevasconstrucciones conceptuales para elevar el nivel de abstracción de los lenguajes deprogramación. También se analizan aquellos patrones de diseño que se utilizan pararepresentar en el espacio de la solución todo tipo de relaciones taxonómicas.


Las propuestas basadas en la programación conceptual ofrecen soluciones a nivelde lenguaje de programación que la mayoría de veces no poseen una base formalni un soporte metodológico necesario para usar adecuadamente las nuevas abstrac-ciones introducidas en el lenguaje. Estas propuestas también poseen los problemascomentados anteriormente a nivel del Espacio del Problema.Las técnicas basadas en patrones de diseño ofrecen soluciones genéricas y poco

precisas para implementar diversos tipos de relaciones taxonómicas. Con la propues-ta introducida en esta tesis se llevan a cabo procesos de especialización en los quese adaptan los patrones de diseño a la estructura y comportamiento del patrón con-ceptual. Los patrones de diseño se extienden añadiendo nuevos elementos que sonnecesarios para representar …elmente en el Espacio de la Solución las relaciones ta-xonómicas introducidas en esta tesis. De esta forma el proceso de especializaciónproporciona una semántica precisa a los patrones de diseño especializados.Para que estas propuestas sean útiles en el contexto de un proceso de producción

automática de software, deben proporcionar estructuras de diseño precisas cuya re-presentación se “acerque” a la de los patrones conceptuales. Esto permitirá de…nircorrespondencias precisas entre las construcciones del Espacio del Problema y las delEspacio de la Solución. Ésta es una de las claves para la construcción de un métodode producción automática de software.En el tercer apartado de este capítulo se analizan un conjunto de aproximaciones

que poseen alguna similitud con la aproximación introducida en esta tesis para lageneración automática de código. Las propuestas estudiadas se pueden categorizaren aquellas que proporcionan:

² generación de código “casi completa” abordando dominios muy reducidos,² generación de código parcial o incompleta (sólo se genera a partir de algúnsubconjunto de diagramas del esquema conceptual),

² generación de código abierta (programable mediante lenguajes de script),² generación de código semi-automática (necesita de la ayuda del modelador paracompletar la implementación) y

² generación de código en entornos declarativos no comerciales.El método de desarrollo que se introduce en este trabajo proporciona un proce-

so de generación de código independiente del dominio, completo (estructura y com-portamiento), cerrado (generador universal que no necesita ser programado por elmodelador), automático (sin necesidad de intervenir el modelador), y produce soft-ware en arquitecturas y entornos industriales. Este método concentra el trabajo deldesarrollador en la etapa de Modelado Conceptual, proporcionando ayuda a nivelmetodológico y un catálogo prede…nido de patrones conceptuales con una semánticaprecisa. Esta aportación contrasta con la falta de rigor en la especi…cación de lospatrones conceptuales que presentan la mayoría de los métodos actuales. Una de lascaracterísticas claves en este método es que el conjunto de patrones conceptuales po-see una representación software correcta, de…nida mediante correspondencias precisasentre los patrones conceptuales y un conjunto de patrones de diseño especializados.Esto garantiza que la representación software obtenida …nalmente es funcionalmenteequivalente al esquema conceptual.

Capítulo 4

Un Marco para el Modeladode Relaciones Taxonómicas

En este capítulo se presenta un marco multidimensional para el modelado de relacio-nes taxonómicas. El marco se ha desarrollado mediante un proceso de abstracción delas características esenciales (a nivel estructural y de comportamiento) presentes enlas relaciones taxonómicas que proporcionan los métodos de modelado conceptual OOactuales. El resultado del trabajo constituye un marco genérico y abstracto que puedeser utilizado para comparar la expresividad de distintas aproximaciones, introducirnuevos modelos de especialización o extender existentes, identi…car patrones estruc-turales y de comportamiento, ayudar en el proceso de modelado, y de…nir esquemasde traducción para generar código. Para …nalizar se introduce cómo se va a aplicar elmarco en los capítulos siguientes.

4.1 Introducción

Henderson-Sellers et al., en su trabajo sobre la caracterización de los distintos tiposde agregación existentes [105], a…rman: “Concepts must be determined …rst, nomen-clature second”. En el caso de la especialización o relación Es-Un cada método OOproporciona una interpretación particular de su semántica, unos lo hacen formalmente(de manera precisa) y otros de manera informal (frecuentemente ambigua). Indepen-dientemente de la precisión del concepto, algunos métodos utilizan términos distintospara referirse a la misma abstracción; por ejemplo, las especializaciones dependientesdel tiempo reciben diversos nombres según la aproximación en la que estén basadas(especialización temporal, dinámica, estática relativa, rol, aspecto, modo, tipo estado,subclase dependiente del estado, subclase derivada, etc,...). Otros utilizan los mismostérminos para referirse a conceptos distintos, por ejemplo, el término rol. Si se anali-za el signi…cado de estos términos se observa que algunos de ellos no representan deforma precisa el concepto que pretenden describir. Los términos temporal y dinámicaestán asociados con el tiempo y proporcionan una visión general de la abstracción:“el que los objetos cambien (de clase) con el tiempo”. Al analizar los términos estado,modo, aspecto y rol en el diccionario [62], se observa que el signi…cado de estado

83

84 Capítulo 4. Un Marco para el Modelado de Relaciones Taxonómicas

es la “situación en que se encuentra alguien o algo, y en especial cada uno de sussucesivos modos de ser o estar”. En [182], según la …losofía Aristotélica el estado “esla cualidad que constituye una manera de ser estable y duradera de un ser o de unacosa y que di…ere de la disposición1 por su mayor duración o estabilidad”. El modoes “aspecto que ante el observador presenta una acción o un ser”. El rol es la “funciónque alguien o algo cumple”, en [182] “es la conducta que un grupo espera de cada unode sus miembros según la forma en que se produce su inserción en él” y aspecto es la“apariencia de las personas y los objetos a la vista”. Analizando esta última de…niciónse observa que no concuerda con la de…nición de aspecto que proponen Richardsonet al. [192] “Un aspecto extiende a un objeto con estado y comportamiento adicionalcompartiendo la misma identidad. Un objeto puede tener muchos aspectos que vieneny van en el tiempo”. La primera frase de esta de…nición puede considerarse comouna de…nición estándar de especialización y la segunda la caracteriza como dinámica,por lo que un aspecto podría denominarse también especialización dinámica. Estetipo de situaciones implican una sobrecarga semántica muy problemática cuando seutiliza la especialización en las etapas de modelado e implementación, di…cultando laaplicación de la abstracción y utilizando dichos términos de forma incorrecta.Una solución a este problema puede ser disponer de un marco de referencia ge-

nérico que determine las propiedades esenciales de las relaciones taxonómicas. Estemarco identi…cará y clasi…cará las propiedades estructurales y de comportamientoasociadas a la abstracción, de forma que proporcione un conjunto de dimensionesmediante las cuales categorizar adecuadamente las distintas interpretaciones de la re-lación de especialización existentes en el modelado OO. Este marco multidimensional,entre otras aplicaciones, ayudará a comprender las características esenciales y la se-mántica de las relaciones taxonómicas, independientemente de los términos utilizadospara nombrarla, permitirá comparar la expresividad de distintas aproximaciones, pro-porcionará guías para la construcción de nuevos modelos de especialización y servirápara identi…car posibles carencias expresivas y ambigüedades en modelos taxonómicosexistentes.

4.2 Dimensiones del Marco

Ofrecer un marco general que sea capaz de caracterizar los distintos tipos de estructu-ras taxonómicas existentes en el modelado conceptual es una tarea compleja debido ala di…cultad que tiene poder garantizar su completitud2. El marco a desarrollar seráde gran utilidad en muchas áreas de aplicación, permitiendo:

1. Evaluar modelos de relaciones de especialización y realizar análisis comparativosentre distintas propuestas.

2. Detectar carencias expresivas y ambigüedades en los distintos modelos de espe-cialización.

1Cualidad no permanente. Cuali…cación especí…ca que una realidad recibe por su relación dialéc-tica con las que le rodean.

2El marco será completo si permite obtener toda la información relativa a las distintas relacionestaxonómicas existentes en el modelado conceptual OO.

4.2. Dimensiones del Marco 85

3. Identi…car patrones estructurales y de comportamiento en las relaciones exis-tentes.

4. Proporcionar guías para la identi…cación y caracterización de relaciones de es-pecialización.

5. Ofrecer guías para la introducción de nuevos modelos de especialización.

6. Ayudar al proceso de modelado y especi…cación de las relaciones de especializa-ción.

7. Determinar las estructuras de diseño necesarias para la implementación de cadauna de las características propuestas en el marco y guiar el proceso de generaciónde código.

El marco conceptual que se desarrolla en este trabajo es consecuencia de un procesode revisión y abstracción de distintas propuestas de modelos de especialización en elárea del modelado conceptual OO. En este proceso se han identi…cado las siguientescaracterísticas como propiedades esenciales para de…nir un modelo taxonómico:

² Interpretación Semántica: Estudia la semántica de la abstracción medianteuna caracterización básica del concepto de clase y objeto, introduciendo losconceptos de especialización y generalización.

² Relaciones entre Propiedades: Estudia cómo se heredan las propiedades(incluyendo cómo se puede especializar el comportamiento) y cuál es la visibili-dad existente entre ellas.

² Restricciones Estáticas: Trata las restricciones estáticas que se pueden darsobre la población de las subclases y la de la superclase que participan en larelación. Se introducen los conceptos de completitud y disyunción, y el departición.

² Características Temporales y Restricciones Dinámicas: Estudia las ca-racterísticas temporales de las especializaciones y las restricciones dinámicas quepermiten caracterizar el comportamiento de los objetos de las subclases respectoal tiempo.

² Dependencia Existencial: Determina si los participantes de la relación de-penden uno de la existencia del otro y viceversa.

² Multiplicidad: Determina la multiplicidad existente entre las clases partici-pantes de una relación de especialización.

² Identidad: Estudia las relaciones existentes entre la identidad de los objetosde la superclase y la de los objetos de la subclase. Además, se revisa la nociónde identidad en diversas situaciones en las que interviene el tiempo.

² Criterios de Especialización: Estudia algunos principios básicos que guíenel proceso de clasi…cación y el modelado de relaciones de especialización, deter-minando las propiedades y los tipos de criterios de especialización en los que sebasa el particionamiento de una clase en un conjunto de subclases.


Estas características constituyen un conjunto de patrones estructurales y de com-portamiento que pueden poseer los distintos tipos de especializaciones existentes. Es-tos patrones se pueden ver como un conjunto de dimensiones que constituyen unmarco multidimensional que permitirá categorizar los tipos de relaciones de espe-cialización existentes en el modelado conceptual OO. En los siguientes apartados sepresentan cada una de estas dimensiones.

4.2.1 Interpretación Semántica

La interpretación semántica pretende especi…car de forma precisa el signi…cado de lasabstracciones utilizadas en este marco. La caracterización que se presenta en esteapartado constituirá la base para determinación de las demás dimensiones. Para queel marco propuesto sea lo su…cientemente general, se utilizará en la caracterizaciónsemántica un modelo de objetos básico en el cual se tienen clases que poseen unconjunto de propiedades (atributos y operaciones) y una serie de restricciones sobrelas propiedades.

Clases y Objetos

Una clase describe un conjunto de objetos. Los objetos de una clase son el conjunto deposibles instancias de la clase, que poseen un estado y un comportamiento local. En elmodelado conceptual los objetos describen entidades del mundo real. La especi…caciónde una clase es una descripción abstracta que se aplica a todos los objetos del conjunto.Los objetos de una clase comparten características generales, expresadas en la claseen forma de propiedades y restricciones.Dado un instante cualquiera t del sistema, el conjunto existencia (población)

de una clase, extt(C), es el conjunto de todas las instancias (posiblemente vacío) dela clase que existen en el sistema en dicho instante.Los siguientes dos conjuntos son independientes del tiempo:

² La intensión de una clase, int(C), es el conjunto de todas las propiedades queson compartidas por todas las instancias de la clase. Representa la plantilla otipo de la clase C.

² La extensión de una clase es el conjunto de todos los posibles objetos de laclase. A los objetos de la extensión se les denominan objetos de la clase. Laextensión de una clase C se denota por ext(C) = [textt(C). La extensiónde una clase es siempre el mismo conjunto de objetos, independientemente delmomento en que se evalúe. Sin embargo, el conjunto de existencia de una clasevaría dependiendo del momento en el que se observe.

Especialización

La especialización parte de la existencia de una clase más general (superclase) ya partir de ella se de…ne un conjunto de clases más concretas (subclases o clasesespecializadas) que incluyen las características de la clase general, además de ciertascaracterísticas especí…cas. Las subclases son menos generales o más especializadas(son un re…namiento de la superclase). En una visión intensional de las subclases sepuede decir que la especialización es la construcción de una nueva clase añadiendo


propiedades a otra clase existente [161, 233]. La extensión de la clase especializadaes un subconjunto de la extensión de la clase general, implicando una inclusión entreextensiones.En esta aproximación una clase Ci 2 fC1; :::; Cng es subclase de CP si se cumple

que ext(Ci) µ ext(CP ). Además, existe una relación de subconjunto opuesta a laanterior entre las intensiones de las clases, cumpliéndose que ext(Ci) µ ext(CP ) !int(CP ) µ int(Ci).

Ejemplo 1 Ejemplo de las clases Coche y Vehículo.

La clase Coche es una subclase de la claseVehículo porque ambas cumplen estasdos relaciones de inclusión: int(V eh¶{culo) µ int(Coche) y ext(Coche) µ ext(V eh¶{culo).La relación int(V eh¶{culo) µ int(Coche) indica que un coche tiene todas las pro-piedades de…nidas para los vehículos y algunas más. La relación ext(Coche) µext(V eh¶{culo) indica que cualquier objeto de la clase Coche es también un objetode la clase Vehículo.Si existen subclases que son especialización de dos o más clases a la vez se está

ante una especialización múltiple. Esta situación implica que una instancia de unasubclase Ci será una especialización de dos o más superclases distintas.

Generalización

La generalización parte de la existencia de clases menos generales y a partir de ellasde…ne una clase más general que aglutina las características comunes a todas ellas.De manera más precisa la intensión (propiedades) de una generalización CG sobre lasclases fC1; :::; Cng se de…nirá de la siguiente manera int(CG) = int(C1)\int(C2)\:::\int(Cn) y la extensión de CG será ext(CG) = ext(C1) [ ext(C2) [ :::[ ext(Cn).

Ejemplo 2 Ejemplo de la clase Vehículo como generalización de Coche y Camión

De esta forma la clase Vehículo respecto a las clases Coche y Camión cumplenlas siguientes relaciones de inclusión: int(V eh¶{culo) = int(Coche) \ int(Cami¶on)y la extensión de V eh¶{culo será ext(V eh¶{culo) = ext(Coche) [ ext(Cami¶on). Larelación int(V eh¶{culo) = int(Coche) \ int(Cami¶on) indica que un Vehículo tie-ne las propiedades que tienen en común los coches y los camiones. La relaciónext(V eh¶{culo) = ext(Coche) [ ext(Cami¶on) indica que cualquier objeto de una delas clases Coche o Camión es un objeto de la clase Vehículo, en otras palabras, losobjetos de la clase Vehículo son todos los coches y todos los camiones.

Especialización vs. Generalización desde una Perspectiva Taxonómica

Una taxonomía se puede representar grá…camente en forma de estructura jerárquica,representada por un grafo acíclico dirigido o árbol, que según sea recorrido da lugara los dos conceptos presentados:

² La especialización supone un recorrido descendente en el árbol taxonómico.² La generalización supone un recorrido ascendente en el árbol taxonómico.


La especialización y la generalización son dos puntos de vista distintos de lamisma relación entre clases, llamada comúnmente en el ámbito del modelado concep-tual OO relación Es-Un.

4.2.2 Relaciones entre Propiedades

En este apartado se analiza, en el ámbito del modelado conceptual OO, qué tipos depropiedades se pueden de…nir en una subclase especializada y la visibilidad que setiene de las propiedades desde una subclase y una superclase.

Herencia de Propiedades

En la literatura se distinguen cuatro tipos de relaciones entre una propiedad de laclase general (o propiedad intrínseca [121]) y de la clase especializada:

² propiedad heredada: la propiedad de la clase general es la misma que la de laespecializada.

² propiedad modi…cada: la propiedad está más elaborada en la clase especiali-zada. Dependiendo de si son atributos u operaciones, este tipo de propiedadespueden clasi…carse en:

– atributos re…nados: esta relación entre atributos se introduce en diversaspropuestas. Wegner et al [231] introducen la modi…cación vertical en laque el tipo de un atributo (re…nado) en la subclase se puede restringira un subconjunto de su dominio. Esta clase de modi…cación también seformula exigiendo que el tipo del atributo re…nado sea un subtipo del tipoasociado al atributo en la clase padre. Una propuesta muy similar a éstala introducen Anality et al. en [11], donde el re…namiento de los atributosse interpreta como una restricción de sus posibles valores. Kristensen yOsterbye introducen en [121] una propuesta nueva aunque no muy utilizadaen el modelado conceptual OO. Según los autores, el re…namiento de unatributo signi…ca que un atributo de una subclase extiende a un atributodel objeto de la superclase y que la unión de ambos constituye el atributo dela subclase. Un ejemplo de este tipo puede ser el atributo datos_personalesde una Persona, que almacene sus datos personales. Datos_personales seráun atributo re…nado (también llamado combinado) de la clase Empleado(subclase de Persona) si cuando el objeto se especializa como Empleado,el valor del atributo datos_personales se considera como una unión de losdatos datos_personales como Persona y los nuevos datos como Empleado.

– operaciones re…nadas o especializadas: Son operaciones que re…nanoperaciones existentes utilizando la implementación de las ya existentes yañadiéndoles comportamiento.

² propiedad nueva3: signi…ca que la propiedad es nueva en la clase especializada.Se pueden de…nir propiedades nuevas con el mismo nombre que las propiedades

3En algunas aproximaciones se utiliza el término emergente aunque su signi…cado en [62]: ”Quenace, sale y tiene principio de otra cosa”, presupone que la propiedad surge a partir de otra clase.


heredadas. A este tipo de propiedades se les llama repetidas, y ocultan laspropiedades heredadas con el mismo nombre. Por ejemplo, los estudiantes oempleados pueden tener sus propios números de teléfono.

² propiedad cancelada: signi…ca que se permite incluso borrar alguna de laspropiedades heredadas, teniendo clases descendientes con menos propiedadesque las clases padre (a esta situación se le llama herencia ‘con olvido’).

Herencia del Comportamiento

Las propiedades de una clase de…nen el estado y el comportamiento de los objetos dela clase. Un caso a tratar en el contexto de las relaciones entre propiedades son laspropiedades modi…cadas, y en especial el re…namiento de las operaciones que puedenmodi…car el comportamiento heredado.Los métodos de modelado OO de…nen el comportamiento de las clases a través de

la especi…cación de operaciones y adicionalmente suelen utilizar técnicas grá…cas co-mo los “statecharts”, las redes de Petri o los diagramas de transición de estados, paramodelar la evolución de los objetos a través del tiempo, de…niendo lo que se llamaciclo de vida del objeto4 . Las técnicas de especi…cación de operaciones y diagramas detransición de estado son las más utilizadas para especi…car el comportamiento de lasclases, por ello es interesante estudiar cómo se heredan y modi…can el comportamientoen las clases especializadas. Para ello se va a proponer un marco lo su…cientemen-te abstracto que permita comprender cómo puede heredar el comportamiento unasubclase.En lo que respecta a las operaciones, la cuestión más importante a determinar

es qué criterios deben cumplir las operaciones de…nidas en las subclases para que segarantice que el comportamiento de la subclase es una especialización del de la super-clase. La mayoría de las aproximaciones que caracterizan a nivel de comportamientola relación de especialización provienen de la cultura del diseño y la programaciónorientada a objetos. Éstas tratan la herencia como un mecanismo para implementarla especialización conceptual, por lo que sus resultados son perfectamente aplicablesen el modelado conceptual OO. En este tipo de aproximaciones se encuentran entreotras las propuestas de Liskov y Wing [134], Wegner y Zdonik [231] y Meyer [145] queargumentan, cada uno desde su propia perspectiva, que los objetos de una subclasedeben comportarse de la misma manera que los de la superclase, para cualquier objetoque los utilice como lo haría con la superclase. Este principio es una forma generalde lo que se ha llamado compatibilidad de comportamiento.Liskov y Wing [134] argumentan que la restricción que han de cumplir las subclases

es que las propiedades (invariantes y propiedades históricas5) que se puedan probar deun objeto de una clase determinada, se deben seguir cumpliendo cuando el objeto seamiembro de una subclase de ésta. Para Meyer [145] las aserciones de una operaciónen una subclase deben garantizar un rango de comportamientos aceptables. Paraconseguirlo las precondiciones pueden ser iguales o más débiles que las de…nidas en laclase padre (signi…cando que la operación puede aceptar más casos al requerir menos),

4Es el conjunto de secuencias posibles de operaciones que pueden ocurrirle a un objeto durantesu existencia.

5Propiedades que se evalúan a verdadero en todas las secuencias de estados.


y las postcondiciones pueden ser iguales o más fuertes (esto implica que se puedenhacer más cosas garantizando al menos lo mismo que se garantizaba en la superclase).Wegner y Zdonik [231] presentan la herencia como un mecanismo de modi…cación

incremental que transforma una entidad padre en una entidad hija a través de unmodi…cador. De los tipos de modi…cación que se pueden dar, la compatibilidadde comportamiento es la recomendada en la especialización conceptual. La com-patibilidad de comportamiento consiste en que el comportamiento de la subclase escompatible con el de la clase padre. Se entiende como comportamiento compatibleaquél en el que las instancias de la clase hija se comportan como instancias de la clasepadre para todas las operaciones y argumentos de…nidos en la clase padre conside-rada. Además de éste, se introducen otros tipos de modi…caciones (más frecuentesen la programación OO), como son la compatibilidad de signatura, que requiere unacompatibilidad sintáctica entre las signaturas de la clase padre y la clase hija, y lacompatibilidad de nombre, donde los nombres de las operaciones de la clase padre semantienen en la clase descendiente, aunque las operaciones pueden ser modi…cadasen el sentido de ser rede…nidas. La rede…nición de una operación está permitida pu-diendo tener un número diferente de argumentos, así como un efecto diferente al de laoperación que rede…ne en la clase padre. La compatibilidad de comportamiento en lapropuesta de Wegner y Zdonik viene motivada por el principio de reemplazabili-dad6 , por el cual una instancia de una subclase siempre puede ser usada en cualquiercontexto en el que se esperaría una instancia de la superclase.En lo que respecta a la especialización del ciclo de vida de un objeto, se han

desarrollado de forma paralela diversas propuestas (Stumptner y Schre‡ [218], Eberty Engels [70] y Saake et al. [196]) que trasladan el principio de reemplazabilidad a losciclos de vida de un objeto. La idea es que cualquier diagrama de ciclo de vida de…neel conjunto de trazas posibles, donde cada traza es una secuencia de ocurrencias deeventos que constituye una historia permitida en el diagrama. Si de una traza deun ciclo de vida especializado se omite el conjunto de eventos que no se han de…nidoen la superclase, entonces se obtendrá una traza posible de la superclase. La vidade un objeto especializado visto como una instancia de la clase padre será una vidaválida. Esta propuesta interpreta el principio de reemplazabilidad como sigue: “Unatraza de un objeto de una subclase, restringida a los eventos de…nidos en la superclasepuede ocurrir en cualquier contexto en el que se esperaba una traza de un objeto dela superclase”.Nierstrasz en [150] extiende el principio de reemplazabilidad introducido por Weg-

ner y Zdonik, presentando una aproximación más restrictiva que estas últimas aproxi-maciones. Este trabajo ve al objeto como un sistema de transición que puede aceptaruna secuencia peticiones de servicio a la que llama protocolo. Nierstrasz a…rma queno sólo es necesario que las subtrazas sean válidas, sino también que los “fallos” seanlos mismos, es decir, el objeto cliente debe esperar que todas las peticiones que acepteun objeto de la superclase sean aceptadas por la subclase, y que todos los serviciosque hubiera rechazado la subclase sean también rechazados por la superclase.Cook y Daniels en Syntropy [53] aplican las ideas propuestas por Meyer [145]

sobre el re…namiento de aserciones, a las transiciones en el diagrama de transiciónde estados. En este caso, al relajar las precondiciones y reforzar las postcondicionesde las transiciones de…nidas para la clase padre, se permiten nuevas activaciones de

6Del término inglés “substitutability”.


eventos heredados para los objetos de la clase hija, que no están contempladas para losobjetos de la clase padre, al igual que ocurre también con la propuesta de Nierstrasz.Las interpretaciones del principio de reemplazabilidad presentadas se pueden ca-

tegorizar en dos tipos (siguiendo la nomenclatura propuesta por Ebert y Engels [70]):(1) basándose en lo que el usuario (cliente) observa (consistencia de observación)y (2) basándose en lo que el usuario (cliente) invoca (peticiones de servicio) sobreel objeto servidor (consistencia de invocación). La propuesta que sigue UML yla mayoría de técnicas de diseño e implementación es la (2), a la cual se le llamasubtipado (página 2-157, sección 2.12.5.3 de [86]).De forma general los ciclos de vida se especializan mediante la “combinación” de

operaciones de extensión y re…namiento de las máquinas de estado. La extensión secorresponde con la adición de nuevos estados y eventos, y el re…namiento se re…e-re a la descomposición de estados en subestados (en este contexto se entiende comoconsiderar las propiedades heredadas a un mayor nivel de detalle). La extensión y elre…namiento deben emplearse de manera que se respete el principio de reemplazabi-lidad, siguiendo al menos uno de los dos enfoques presentados.

Visibilidad

La visibilidad de propiedades determina el acceso que desde un objeto determina-do se tiene a las propiedades de los objetos con los que está relacionado. Cuandose especializa una subclase de una superclase la visibilidad que se puede dar es lasiguiente:

² La visibilidad de un objeto de la subclase se restringe a sus propiedades nuevasy a las propiedades heredadas de la clase padre. El objeto no tiene accesoa las propiedades nuevas de objetos pertenecientes a subclases en su mismonivel jerárquico. El objeto sólo tiene acceso a su contexto en particular. Porejemplo, dada una persona especializada en estudiante y empleado, el salariode un empleado no es accesible si se accede a la persona como un estudiante.

² La visibilidad de un objeto de la superclase en el contexto de una especializaciónse restringe a sus propiedades. El objeto cuando es visto como instancia de lasuperclase no tiene acceso a las propiedades como instancia de cualquiera de sussubclases.

² La visibilidad de un objeto de la superclase en el contexto de una generalizaciónse restringe a las propiedades que tienen en común las clases que han sidogeneralizadas.

4.2.3 Restricciones Estáticas

En un contexto general en el que se da una relación de especialización (o genera-lización) entre una clase y un conjunto de subclases, se puede de…nir una serie derestricciones sobre la población de las subclases participantes y sobre la de la super-clase. Estas restricciones se denominan estáticas7 si restringen la población dedos o más clases en el mismo instante de tiempo. Las restricciones estáticas que sepueden de…nir sobre una especialización (o generalización) son las siguientes:

7Término introducido por Olivé en [156].


² Completitud: Una especialización es completa (o cubierta [161]) si al menosen un instante dado, un objeto de una superclase siempre será instancia de unasubclase en el conjunto de subclases especializadas (similarmente una generali-zación es completa si una instancia de la superclase es al menos instancia de unasubclase). En caso contrario será una especialización (generalización) incomple-ta o no exhaustiva. De forma intuitiva, dada una clase especializada en diversassubclases se dirá que esta especialización es completa si todos los objetos de lasuperclase forman parte de alguna(s) de sus subclases. De esta situación se pue-de deducir que cualquier especialización completa que se haga de una clase parade…nir nuevas subclases deberá tener al menos dos subclases. Es importantedestacar que esta restricción es más expresiva que la restricción introducida porUML donde la completitud sólo signi…ca que “Todas las subclases se han espe-ci…cado (aunque se muestren o no). No se esperan subclases adicionales en elmodelo” (sección 3.48.2, página 3-79). En este caso si se cumple la completitudintroducida implicaría el cumplimiento de la restricción propuesta por UML,pero dicha implicación no se daría en caso contrario.

² Disyunción: Una especialización es disjunta si un objeto de la superclase enun instante cualquiera es instancia de una única subclase en el conjunto desubclases especializadas (una generalización es disjunta si una instancia de lasuperclase es como mucho instancia de una subclase). En caso contrario (sies instancia de más de una subclase) esta especialización (generalización) serásolapada.

El concepto de partición surge en este contexto como una especialización (ge-neralización) completa y disjunta. Según diversos autores [156, 238], es más fácildesarrollar, trabajar, analizar y razonar sobre esquemas conceptuales cuando sólose consideran particiones (especializaciones completas y disjuntas). Toda especiali-zación (generalización) se puede transformar en una partición, a través del uso declases y especializaciones (generalizaciones) auxiliares. Las particiones incompletas yno disjuntas se pueden convertir en particiones completas y disjuntas sin pérdida deinformación (en el sentido de que la información del esquema no cambia), siguien-do las pautas de…nidas por Olivé et al. en [156]. Esta última a…rmación permitirátrabajar con particiones sin pérdida de generalidad, por lo que cualquier resultadoobtenido sobre particiones, será perfectamente aplicable a cualquier especialización(generalización).Para cada clase se pueden de…nir tantas particiones como se desee (particiona-

miento múltiple). De esta forma un mismo objeto puede estar especializado a lavez en más de una subclase (una por cada partición que tenga la superclase). Estoimplica la posibilidad de una clasi…cación múltiple. Con la clasi…cación múltiple unobjeto puede pertenecer a diversas clases sin necesidad de estar conectado por ningunarelación de especialización entre dichas clases.

4.2.4 Características Temporales y Restricciones Dinámicas

Uno de los factores importantes para la caracterización de las relaciones de especiali-zación es el tiempo. Las características temporales de las especializaciones permiten


de…nir una serie de restricciones dinámicas que caracterizan el comportamiento delos objetos de las subclases respecto al tiempo.Siguiendo un enfoque temporal, la clasi…cación de los objetos en una jerarquía

de especialización puede ser de dos tipos: estática si un objeto no puede cambiar desubclase con el paso del tiempo y dinámica en caso contrario. En una especializaciónestática los objetos de una subclase se mantienen en dicha subclase durante toda suexistencia. Desde el punto de vista ontológico [92] este tipo de especialización vienecaracterizado por el concepto de rigidez (una subclase estática será rígida, ya que unobjeto de la subclase lo será de ésta en cualquier estado posible sin tener posibilidadde cambiar de subclase). En una especialización dinámica los objetos de una subclasepueden “cambiar” durante su vida desde una subclase a otra. La especializacióndinámica se basa en la característica ontológica de la no rigidez semántica [92]. Unasubclase dinámica carece de rigidez semántica por lo que sus instancias pueden dejary entrar en la extensión de la subclase sin perder su identidad.El “cambio” de clase según Spaccapietra [213] se puede llevar a cabo mediante las

siguientes restricciones dinámicas:

² evolución: se produce cuando el objeto que cambia de clase cesa de existiren la clase origen y se crea en la clase destino. La evolución es una propiedadhorizontal ya que se producirá entre subclases de un mismo nivel jerárquico. Aeste fenómeno también se le llama migración [238] o (re)clasi…cación dinámica[214, 238]. En las especializaciones dinámicas con evolución horizontal se detec-ta un patrón de comportamiento que determina un orden en el cual los objetoscambian de subclase. Este orden puede restringir la secuencia de transicionesentre subclases. Las transiciones admisibles se pueden de…nir mediante diagra-mas de transición entre estados y/o restricciones de migración [156, 219, 238].Estas notaciones modelan la migración de los objetos de una clase fuente a otradestino, especi…cando una relación de transición que conlleva una semánticade “convertirse en”. Las relaciones de transición constituyen un enlace virtualentre objetos que comparten la misma identidad8 y que se encuentran en lamisma jerarquía de especialización.

² extensión: se produce cuando el objeto de una clase se instancia en otra sindejar de existir en la clase origen. La extensión es una propiedad vertical (ins-tanciación de subclases desde la superclase). La extensión vertical es el patrónde comportamiento más utilizado en la literatura, donde ciertas aproximacionesal modelado de roles [81, 130, 181, 238, 242] introducen la dinamicidad medianteextensión vertical.

Esta caracterización de la especialización dinámica (evolución vs. extensión) sepuede fundamentar en el análisis ontológico propuesto por Guarino [88] en el que sepresentan las subclases dinámicas como conceptos sin rigidez semántica y que puedenser fundados o no:

² Una clase “no fundada” es aquella en la que sus individuos no están relacionadoscon otros. Guarino en [88] presenta como ejemplo de este tipo a las subclases

8En las subclases dinámicas se admite que un objeto puede permanecer siendo el mismo aunqueexhiba distintas propiedades en momentos distintos.


Persona

Hombre Mujer

Figura 4.1: Especialización de Persona en Hombre y Mujer

Adolescente y Adulto que son estados o fases de la vida de un individuo de laclase Persona, implicando una evolución horizontal.

² Una clase “fundada” es aquella en la que sus individuos están en relación conotros. A este concepto Guarino le llama rol de un objeto en el contexto deuna relación. Por ejemplo, un Empleado puede ser un rol de Persona porquela Persona se relaciona con una Empresa que lo contrata, y en ese momentopasa a ser Empleado. Desde una perspectiva taxonómica esta situación implicauna extensión vertical al “tomar el rol/especializarse” una persona en empleadocuando una empresa lo contrata.

Distinción entre Clasi…caciones Estáticas y Dinámicas

Existen dos criterios que permiten distinguir entre clasi…caciones dinámicas y estáti-cas:

1. Criterio de las extensiones iguales: Si en el modelo se quiere permitir quetodas las posibles instancias de una clase puedan ser instancias de alguna de sussubclases se está ante una subclasi…cación dinámica. Si no es así, se está anteuna subclasi…cación estática. Este criterio se enuncia de la siguiente manera:

Sea Ci 2 fC1; :::; Cng una subclase de CP entonces:

² Si Ci es una subclase estática de CP entonces ext(Ci) ½ ext(CP ):² Si Ci es una subclase dinámica de CP entonces es potencialmente posible queext(Ci) = ext(CP ):

En las Figuras 4.1 y 4.2 se pueden observar dos ejemplos de subclasi…cación es-tática y dinámica. Las subclases Hombre y Mujer son subclases estáticas de Personaporque la extensión de Hombre y de Mujer siempre será un subconjunto de la exten-sión de Persona. Sin embargo, las subclases Soltero, Casado, Divorciado y Viudo, sique pueden tener una extensión igual a la extensión de Persona. En otras palabras, enel primer caso se sabe seguro que no todas las Personas van a ser Hombres (Mujeres),y en el segundo caso, se sabe que todas las Personas pueden ser Solteras9 (Casadas,Viudas, Divorciadas).

9Al nacer todos son Solteros.


Persona

Soltero Casado Viudo Divorciado

Figura 4.2: Especialización de Persona en Soltero, Casado, Viudo y Divorciado.

Empleado

Temporal Fijo

Figura 4.3: Especialización de Empleado en Temporal y Fijo

2. Criterio del cambio independiente de la población (o conjunto de exis-tencia): Si se pueden extender los conjuntos de existencia (incrementar elnúmero de instancias de la población) de una subclase, sin crear instancias dela superclase entonces la subclase es una subclase dinámica de la superclase. Encaso contrario será una subclase estática. Sea Ci 2 fC1; :::; Cng una subclase deCP entonces Ci es una subclase dinámica de CP sii10 el conjunto de existenciade Ci puede cambiar sin que cambie el conjunto de existencia de CP .

En las Figuras 4.1 y 4.3 se puede observar una subclasi…cación estática y unadinámica detectadas siguiendo el criterio anterior. La primera subclasi…cación esestática porque no se puede crear una instancia de la clase Hombre, sin a la vez,crear una instancia de la clase Persona. En otras palabras, no puede aumentar lapoblación de Hombre o Mujer sin aumentar la de Persona. Sin embargo, la segundasubclasi…cación es dinámica porque la población de la clase Fijo puede aumentar sinnecesidad de que aumente la población de Empleado, simplemente haciendo que unempleado Temporal pase a ser Fijo (migre a la clase Fijo).Estos criterios se pueden utilizar para determinar si una relación de especialización

es estática o dinámica, analizando los patrones de comportamiento y las propiedadesque debe cumplir la población de las subclases.

4.2.5 Dependencia Existencial

En las abstracciones conceptuales en las que participan dos o más elementos (porejemplo agregación, asociación y especialización) existen dependencias existenciales

10 si y sólo si.


entre los participantes. Snoeck y Dedene en [210] introducen una relación entre clasesllamada dependencia existencial que, de manera sencilla, captura gran parte de lasemántica del concepto de agregación. De forma intuitiva, la dependencia existencialdetermina si dadas dos clases, la existencia de las instancias de una de las clasesdepende de la existencia de una (y siempre la misma) determinada instancia de la otraclase. En la misma línea Goldstein y Storey en [79] desarrollan un marco conceptualen el cuál proponen la dependencia existencial como una dimensión que determinasi en una abstracción de dos participantes, uno de ellos depende de la existenciadel otro y viceversa. Con esta aproximación más genérica se extiende la dependenciaexistencial propuesta por Snoeck y Dedene a la especialización, y se hace evidente queen la especialización está presente una dependencia existencial de la subclase con lasuperclase por la naturaleza intrínseca de la abstracción. En este apartado se analizay extiende esta dependencia existencial para ofrecer un tratamiento exhaustivo de lasposibles dependencias entre superclases y subclases, y entre subclases de un mismonivel jerárquico.En el contexto de una relación taxonómica, la dependencia existencial se de…ne

de la siguiente manera:

² De la subclase respecto a la superclase. La existencia de un objeto de la subclasedepende de la existencia de un objeto de la superclase del cual se especializa.Esta dependencia siempre se da por la naturaleza intrínseca de la relación. Porejemplo, en las aproximaciones donde existe extensión vertical, la instanciaciónde las subclases requiere la existencia de un objeto padre asociado. No se puedeninstanciar de forma aislada.

² De la superclase a la subclase. La existencia de un objeto de la superclase:

– en el caso de la especialización, no depende de la existencia de un objetode la subclase.

– en el caso de la generalización, existirá dependencia en esta dirección de-bido a que el objeto generalizado dependerá de la existencia de objetos delas clases más especí…cas.

² De una subclase respecto a otra subclase en su mismo nivel jerárquico. Estetipo de dependencia existencial es de naturaleza diferente a las presentadasanteriormente. Se da cuando para la existencia de un objeto en una subclase,previamente (en un estado anterior) debería existir un determinado objeto enuna subclase de su mismo nivel jerárquico. Esta situación se da frecuentementeen cierto tipo de especializaciones dinámicas con evolución horizontal (aquellasque modelan estados sucesivos de un objeto) donde se observa la existenciade una dependencia entre subclases. Esta dependencia determina las posiblestransiciones (migración) entre subclases.

4.2.6 Multiplicidad

La multiplicidad existente entre los participantes en una relación de…ne con cuán-tos objetos se relaciona un determinado objeto. Esta propiedad está directamenterelacionada con la dependencia existencial.


En el caso de una especialización (o de una generalización), se podrán dar lassiguientes restricciones en cuanto a la multiplicidad asociada con la relación entre lasuperclase y las subclases:

² Una instancia de una subclase podrá estar relacionada con una y sólo una ins-tancia de la superclase (clase generalizada).

² Una instancia de la superclase podrá estar relacionada– con exactamente una instancia de una subclase.

– con cero o una instancia de una subclase.

– con cero o más instancias de la subclase. Esta multiplicidad se da ensituaciones en las que varias instancias de una misma subclase puedenexistir a la vez para un mismo objeto. Por ejemplo, un empleado puedeser pluriempleado teniendo tantos trabajos como desee. Como un casoparticular de éste se pueden dar situaciones en las que:

¤ la superclase pueda estar relacionada con una o más instancias de lasubclase.

¤ la cota superior de la multiplicidad sea un número en particular. Porejemplo que un estudiante pueda estudiar como máximo tres carrerasuniversitarias a la vez.

En el caso especial de una partición fC1; :::; Cng de…nida sobre una clase CP , seasumirán implícitamente dos restricciones en cuanto a la multiplicidad asociada conla relación de especialización:

² Cada instancia de cada subclase de la partición fC1; :::; Cng está relacionadacon una y sólo una instancia de la superclase CP .

² Cada instancia de la superclase CP está relacionada con exactamente una instan-cia de una subclase Ci de la partición fC1; :::; Cng. A partir de esta informaciónse deduce que la multiplicidad deberá ser cero o uno, porque al ser la particióndisjunta y completa, el objeto padre estará especializado solamente en un objetode una subclase de la partición, por lo que en dicho instante el objeto padre noestará relacionado con ningún objeto de las demás subclases de la partición.

4.2.7 Identidad y Mecanismos de Identi…cación

La identidad está relacionada con el problema de distinguir una instancia especí…cade una clase de otras instancias por medio de una propiedad característica que esúnica. Para poder implementar un sistema de información que represente objetos delmundo real, se necesita almacenar una representación de dichos objetos. Esto puededar lugar a que objetos diferentes puedan ser representados como si estuviesen en elmismo estado, de manera que, lo único que puede distinguirlos en el modelo es unnombre propio que según Wieringa [238] debe ser único y debe persistir a la existenciade los objetos para poder mantener información histórica sobre las identidades delos objetos. Por lo tanto, si se quiere representar a los objetos del mundo real, sedebe simular la identidad de los objetos. La única manera de simular el conjunto


potencialmente in…nito de identidades es utilizando nombres propios globalmenteúnicos, los cuales reciben el nombre de identi…cadores de objetos (oid11).La noción de identidad debe ser revisada en diversas situaciones:

1. Cuando el tiempo está implicado en la noción de identidad. En esta situación seadmite que un objeto puede permanecer siendo el mismo aunque exhiba distintaspropiedades en momentos distintos.

2. Cuando existen objetos que se pueden especializar en más de un objeto deuna misma subclase al mismo tiempo. A está situación también se le llama elproblema del conteo. Como ejemplo se puede presentar la especialización dePersona en Empleado donde una misma persona puede ser empleada muchasveces al mismo tiempo.

En la segunda situación, las subclases deben proporcionar identi…cadores diferentesal de la superclase para poder distinguir entre los objetos de la subclase sin violar elprincipio de unicidad del oid. Según esto se identi…can dos tipos de relaciones entrela identidad de los objetos de una superclase y la de los de cualquier subclase de ésta:

1. Un objeto de la superclase comparte su identidad con los objetos de la subclaseque lo especializan. Esta relación no viola la unicidad y es perfectamente apli-cable aunque limita la expresividad al reducir a uno el número de objetos de lasubclase en la que se puede especializar un objeto.

2. Un objeto de la superclase tiene una identidad propia, diferente a la de losobjetos de la subclase que lo especializan. Esta relación no viola la unicidady permite que un objeto de la superclase se especialice a la vez en dos o másobjetos de la misma subclase.

A nivel conceptual parece contradictorio que un mismo objeto al especializarsetenga identidades (oid) distintas, lo que implica que es un objeto distinto cuando enrealidad es el mismo objeto especializado en varias ocasiones. Para adoptar esta solu-ción manteniendo la coherencia se debe proporcionar un principio de identidad [238]que sea capaz de distinguir entre objetos de cualquier clase y que pueda determinarcuando dos o más objetos distintos se corresponden con el mismo objeto del mundoreal. Existen distintas aproximaciones que aportan soluciones a este problema:Gottlob et al. en su propuesta sobre roles [81] revisan la noción de identidad para

modelar situaciones en las que las entidades del mundo real se representan mediantediversos objetos, para ello introducen las nociones de: identidad del objeto, en la quetodo objeto del mundo real se identi…cará mediante un identi…cador único que loproporciona la clase a la que pertenece; identidad del rol, en la que cada rol particularde un objeto del mundo real tendrá su identi…cador único proporcionado por la clasede rol a la que pertenece el objeto; y equivalencia de objetos, en la cual se dice quedos objetos son equivalentes si se corresponden con el mismo objeto en el mundo real.Esto se puede deducir si ambos comparten un objeto raíz en la jerarquía de clases.Guarino en [91, 92] introduce una relación de identi…cación llamada Condición de

Identidad (CI) que pueden “llevar” o “proporcionar” los objetos. En esta propuesta

11Del inglés object identi…er


se a…rma que las subclases dinámicas llevan una CI propia, heredando las CI propor-cionadas por las superclases a las que se llama condiciones globales de identi…cación.Mediante las condiciones globales de identi…cación siempre se conoce cuál es el objetopadre de cualquier objeto especializado, pudiendo saber si dos objetos de una subclaseque llevan su propia CI se corresponden con el mismo objeto real.A nivel de especi…cación se utilizan los alias o claves como mecanismos de

identi…cación basados en atributos del objeto de los cuales se debe garantizar su uni-cidad y persistencia. Un mecanismo de identi…cación12 es una función que establececorrespondencias entre valores de atributos de un objeto y su oid. De esta forma losmecanismos de identi…cación pueden sustituir a los oid en el espacio del problema,pudiéndose de…nir las siguientes relaciones entre los mecanismos de identi…cación deuna clase y los de sus subclases:

1. Dependencia de identi…cación, si el mecanismo de identi…cación utilizado parareferirse a los objetos de la clase especializada:

(a) es el mismo que el de la clase padre,

(b) se compone del mecanismo de identi…cación heredado y alguno nuevo enla subclase.

2. Independencia de identi…cación, si un objeto hijo tiene su propio mecanismo deidenti…cación totalmente nuevo e independiente del de la superclase.

Si se utilizan los mecanismos de identi…cación como sustitutos de los oid, cuan-do la subclase deba poseer una identidad propia, se exigirá que su mecanismo deidenti…cación sea:

² totalmente nuevo (independencia de identi…cación), o² compuesto por el mecanismo heredado más un mecanismo nuevo que permitaidenti…car de forma única los objetos de las subclases (dependencia de identi…-cación).

Cuando la subclase deba poseer una identidad compartida con la superclase, seconseguirá utilizando el mecanismo de identi…cación de la clase padre (dependencia deidenti…cación) o también de las dos maneras introducidas anteriormente para simularla identidad propia.

4.2.8 Criterios de Especialización

La división de una clase en un conjunto de subclases especializadas se basa en laexistencia de un criterio de especialización (también llamado en otras aproximacio-nes principio de clasi…cación [238]). La identi…cación y aplicación de criterios deespecialización es una cuestión importante en el modelado de relaciones taxonómicas,por lo que debe proporcionarse algún soporte metodológico que ayude a identi…carcriterios de especialización y aplicarlos de forma correcta para construir estructurastaxonómicas de calidad.12Un objeto puede tener más de un mecanismo de identi…cación, aunque cada vez que se haga

referencia a un objeto se utilizará sólo uno de ellos.


En este apartado se presentan de manera genérica los tipos de los criterios deespecialización (más conocidos e intuitivos) y las técnicas utilizadas para su especi…-cación.Los criterios de especialización se pueden categorizar en:

² Estáticos: dependen exclusivamente de características constantes de los ob-jetos, de manera que su evaluación en cualquier instante de la vida del objetosiempre dará el mismo resultado. Así dada una clase C, un objeto de dicha clasepertenecerá a la subclase Ci; si es cierta una característica constante pi evaluadasobre el estado de dicho objeto. La especi…cación de criterios de especializaciónse hace a través de predicados que pueden ser:

– Disjuntos (o No Disjuntos): de…nen un criterio que solamente se cum-ple para una subclase a la vez. Si los predicados son disjuntos se estánde…niendo especializaciones disjuntas.

– Completos (o Incompletos): de…nen un criterio que siempre se cumplepara alguna subclase. Si los predicados son completos se están de…niendoespecializaciones completas.

² Dinámicos: se utilizan para modelar especializaciones dinámicas y tienen lapropiedad de no evaluarse siempre en el mismo sentido para un mismo obje-to (garantizando que el criterio se evalúa de forma distinta en al menos dosestados), por lo que éste podrá pertenecer de forma temporal a las subclases ca-racterizadas por este tipo de criterios. Los criterios dinámicos se pueden dividiren dos:

– Dependientes del estado: se evaluarán o bien sobre el estado actual delobjeto o sobre algún estado anterior (utilizando lógica temporal como en[155, 217]). Dentro de los criterios dinámicos que dependen del estado, elmás conocido es el que se especi…ca mediante predicados sobre atributosvariables. En este caso la especi…cación del predicado depende de atribu-tos variables. Por ejemplo si se tiene una clase Persona con un atributovariable edad, se puede caracterizar a las personas que pertenecen a lasubclase Joven con el siguiente criterio Edad>=18 and Edad <=30. Ladinamicidad no está asociada a los atributos variables en sí; será dinámicosi se puede garantizar la existencia de al menos dos estados en los que elcriterio se evalúe de forma distinta.

– Dependientes de la vida del objeto: se evaluarán teniendo en cuentala ocurrencia de un determinado evento o la secuencia de eventos en los queel objeto ha participado hasta cierto instante (este último caso se presentaen [228]). Dentro de los criterios dinámicos que dependen de la vida delobjeto, el más conocido es el que se especi…ca mediante eventos de cambiode clase. Estos criterios especi…can cuándo ha de cambiar de clase un objetoante la ocurrencia de un evento. Con esta nueva aproximación lo que sehace es que el criterio dependa directamente de la causa (evento) en lugarde hacerlo de la consecuencia o efecto (cambio de estado). Por ejemplo enel caso de la clase Persona y su papel de Estudiante, se puede pensar quelos eventos matricularse y recoger_título delimitan el comienzo y el …nal


del período durante el cual el objeto de la clase Persona juega el papel deEstudiante.

Estos dos criterios dinámicos no poseen expresividades disjuntas; es decir, habráespecializaciones que podrán caracterizarse desde el punto de vista del estado ytambién desde el punto de vista de la ocurrencia de eventos, ya que el estadoes consecuencia del efecto de los eventos. La diferencia entre estos dos tipos decriterios hay que buscarla en su aplicabilidad. Habrá algunas situaciones que sepresten más a ser especi…cadas mediante criterios basados en el estado, mientrasque para otras resultará más natural utilizar los basados en eventos.

Propiedades de los Criterios

Los criterios de especialización deben poseer una serie de propiedades deseables quein‡uyen en el proceso de especialización de clases mediante la imposición de restriccio-nes sobre dichos criterios. Estas propiedades ayudan a construir modelos conceptualesde calidad.El criterio utilizado para especializar una clase en subclases debe ser:

² No redundante: Situar un objeto en una de las subclases de una especializa-ción, debe aportar más información sobre éste que la que da la clasi…cación ensí. Parsons y Wand [161] introducen en las relaciones de especialización el prin-cipio de la no redundancia como una extensión de los principios de clasi…cacióneconomía cognitiva e inferencia.

– La economía cognitiva signi…ca que la clasi…cación proporciona la máxi-ma información con el mínimo esfuerzo cognitivo. En otras palabras, laformación de clases debe equilibrar la tendencia a maximizar el conocimien-to sobre instancias (clasi…cándolas) frente a la necesidad de minimizar elconocimiento de detalles que son irrelevantes en la mayoría de las situacio-nes. Este equilibrio se conseguirá imponiendo condiciones sobre la utilidadde una clase. Una clase será útil cuando posea diferencias signi…cativasrespecto a las demás clases del sistema.

– La inferencia signi…ca que identi…cando una instancia como miembro deuna clase es posible deducir propiedades que no se han observado, a partirde las propiedades identi…cadas.

Así pues, la no redundancia dice que una clase especializada de otra/s clase/s,debe ser de…nida por al menos una propiedad que no esté en ninguna de su/ssuperclase/s, por lo que la nueva subclase debe introducir alguna propiedad adi-cional que no posean sus superclases. Esta a…rmación implica que las subclasesno deben de…nirse sólo por el valor de una propiedad (“todos los profesores queviven en Valencia”) o por intersección (“profesores que son estudiantes de doc-torado”), si en las subclases resultantes no se incluyen más propiedades. A esteprincipio también se le llama principio de la falta de información.

² Claro: Si el criterio se de…ne sobre una propiedad de la clase que puede serevaluable. Una división de personas, en personas con dotes interpretativos y sin


dotes interpretativos. El criterio del dote interpretativo no parece un criteriomuy claro, ya que dependiendo del observador puede tomar distintos valores,además de que es difícil identi…car una propiedad evaluable que pueda describirlos dotes interpretativos.

² Preciso o No Ambiguo: El criterio debe tener una única interpretación cuan-do se especializa un determinado objeto. Si el criterio es ambiguo, el objeto pue-de pertenecer a dos o más subclases especializadas siguiendo un mismo criterio.Una división de documentos según el tipo de documento, en aquellos que sonsobre economía, los que son sobre estadística y otros, es una división ambiguaporque algunos documentos de economía poseen estadísticas, y viceversa.

² Simple: La división en subclases debe realizarse siguiendo un único criterio. Porejemplo, la división de documentos en libros, revistas no prestables y revistasprestables. Lo que en realidad existe en este caso son dos criterios (divisiónmúltiple), no uno. La división de documentos en libros y revistas, y la derevistas en prestables y no prestables.

² Uniforme: El criterio se ha de evaluar siempre sobre una misma propiedady del mismo dominio. Por ejemplo, una división, siguiendo como criterio deespecialización “la localización del lugar de nacimiento de una persona”, quedivida a las personas en aquellas que viven en Valencia, las que viven en Chinay otras, no es uniforme porque en un caso se están especializando unos objetossegún su ciudad de nacimiento y en otro caso según su país. El mismo caso seríadividir los empleados por su sueldo y que el sueldo en las distintas subclasesestuviera en monedas diferentes.

Existen otras propuestas [161, 238] que introducen propiedades que han de cum-plir los criterios de especialización. Éstas no se han incluido en este apartado porser demasiado subjetivas. Un ejemplo de estas propuestas es el principio del rangocomparable que obliga a que todos los miembros de una especialización sean de rangocomparable, en el sentido que no exista una diferencia considerable entre los valoresextremos que puede tomar la población de cada una de las subclases.Con el conjunto de propiedades recomendables que deben cumplir los criterios de

especialización introducidos, se considera que la propuesta es su…ciente para disponerde unos criterios de especialización prácticos.

4.3 Dependencias y Cuestiones Metodológicas

Las características presentadas constituyen una serie de dimensiones que el analistapuede detectar mediante la observación, en el dominio del problema, de una serie depatrones estructurales y de comportamiento que siguen las estructuras taxonómicas.Estas dimensiones conforman un marco multidimensional que va a permitir cate-gorizar de forma precisa, y situar adecuadamente, los distintos tipos de relacionestaxonómicas existentes al abordar la fase de modelado conceptual. El marco propues-to se presenta de forma esquemática en las tablas 4.1, 4.2 y 4.3. Las dimensionespresentadas no son ortogonales por lo que existen dependencias entre algunas de lasdimensiones. Esta dependencias pueden aportar un contenido metodológico al marco

4.3. Dependencias y Cuestiones Metodológicas 103

Interpretación Semántica

8>><>>:Especialización

½Simple

Múltiple

¾Generalización

9>>=>>;

Herencia de Propiedades

8>>>>>>>>>><>>>>>>>>>>:

Heredadas

Modi…cadas

8>>>><>>>>:A. Re…nados

Op. Re…nadas

8<: C. Comportamiento

C. Signatura

C Nombre

9=;

9>>>>=>>>>;Nuevas

Canceladas

9>>>>>>>>>>=>>>>>>>>>>;

Visibilidad

8>><>>:Superclase

½P. Propias

P. Propias + P. Comunes Subclases

¾Subclase

©P. Nuevas + P. Superclase

ª9>>=>>;

Restricciones Estáticas

8>>>><>>>>:Disyunción

½Disjunta

Solapada

¾

Completitud

½Completa

No Exhaustiva

¾9>>>>=>>>>;

Características Temporalesy Restricciones Dinámicas

8>><>>:Estática

Dinámica

8<: Evolución©

Horizontalª

Extensión©

Verticalª

9=;9>>=>>;

Tabla 4.1: Un Marco Multidimensional para el Modelado de Estructuras Taxonómi-cas. Esquema 1/2


Multiplicidad

8>>>><>>>>:De Subclase a Superclase

©1ª

De Superclase a Subclase

8<: 1

[0,1]

[0,N]

9=;

9>>>>=>>>>;

Dependencia Existencial

8>>>>>>>><>>>>>>>>:

Subclase de Superclase©

Dependeª

Superclase de Subclase

½Depende

No Depende

¾

Subclase de Subclase

½Depende

No Depende

¾

9>>>>>>>>=>>>>>>>>;

Identidad

8>>>><>>>>:OID Compartido

8<: Heredado

Heredado + Nuevo

Nuevo

9=;OID Propio

½Heredado + Nuevo

Nuevo

¾9>>>>=>>>>;

Tabla 4.2: Un Marco Multidimensional para el Modelado de Estructuras Taxonómi-cas. Esquema 2/2

Criterios de Especialización

8>>>>>>>>>>>>>>>><>>>>>>>>>>>>>>>>:

Propiedades

8>>>><>>>>:No Redundante

Claro

Preciso

Simple

Uniforme

9>>>>=>>>>;

Tipos

8>>>><>>>>:Estáticos

½Disjuntos/No Disjuntos

Completos/Incompletos

¾

Dinámicos

½Dep. Estado

Dep. Vida Objeto

¾9>>>>=>>>>;

9>>>>>>>>>>>>>>>>=>>>>>>>>>>>>>>>>;Tabla 4.3: Aspectos Metodológicos

4.4. Aplicaciones del Marco 105

propuesto, facilitando la comprensión de la semántica de las relaciones taxonómi-cas y ayudando a derivar información en el proceso de modelado. Las dependenciasdetectadas son:

² La Visibilidad depende de forma directa de la Interpretación Semántica ya quela especialización y la generalización inducen una visibilidad determinada entrelas subclases y las superclases. De esta forma la Visibilidad se puede derivar apartir del tipo de relación existente (especialización o generalización).

² Las Restricciones Estáticas dependen de la Multiplicidad (y viceversa) ya que unaespecialización disjunta requiere una multiplicidad [0; 1] de la superclase a lasubclase, porque existirán subclases en las que un objeto no podrá estar espe-cializado; y una especialización completa requiere al menos una multiplicidad 1de una subclase hacia la clase padre.

² La Multiplicidad depende de la Dependencia Existencial (y viceversa) ya que alexistir dependencia existencial de la subclase hacia la superclase, implica unamultiplicidad 1 hacia la clase padre, y al revés. Por transitividad la DependenciaExistencial depende de las Restricciones Estáticas.

² La Dependencia Existencial depende de las Restricciones Dinámicas porque sedetectan dependencias entre subclases del mismo nivel jerárquico cuando setrata con subclases dinámicas con extensión vertical, y se detectan dependenciasde la subclase respecto a su superclase cuando existe evolución horizontal.

² Los Criterios de Especialización dependen de las Características Temporales (yviceversa), debido a que los criterios (estáticos o dinámicos) dependen de lascaracterísticas temporales (estática o dinámica) de las relaciones taxonómicas.

² Las Restricciones Dinámicas dependen de las Características Temporales. Portransitividad, los Criterios de Especialización dependen de las Restricciones Di-námicas.

² Las Restricciones Estáticas dependen de los Criterios de Especialización (y vice-versa), ya que de los criterios seleccionados puede depender el cumplimiento derestricciones como la completitud y la disyunción.

² La Identidad depende de la Multiplicidad, si la multiplicidad es [0; N ] la subclasedebe proporcionar un identi…cador propio.

El marco propuesto junto con estas dependencias va a permitir construir en estatesis un lenguaje de patrones que ayude a especi…car las propiedades esenciales de lasestructuras taxonómicas en la etapa de modelado conceptual.

4.4 Aplicaciones del Marco

Este marco multidimensional se va a aplicar en los siguientes capítulos de la tesispara:

² Desarrollar un modelo de relaciones taxonómicas para el lenguaje de especi…ca-ción OASIS e incorporarlo a OO-Method.


² Construir un lenguaje de patrones que ayude a la identi…cación y el modela-do de las relaciones taxonómicas de OO-Method, basándose en los patronesestructurales y de comportamiento que introducen las dimensiones presentadas.

² Analizar técnicas de implementación y patrones de diseño existentes para eva-luar cómo cada técnica da soporte directo (implementa) a cada una de las di-mensiones del marco.

² Facilitar la construcción de generadores de código, proporcionando correspon-dencias precisas entre las dimensiones del marco presentado y los patrones dediseño que las implementen.

Además de estas aplicaciones, el marco también se puede utilizar para:

² Comparar las diversas aproximaciones al modelado de relaciones de especializa-ción presentes en la literatura, detectando:

– carencias expresivas

– ambigüedades semánticas

– similitud entre aproximaciones y términos que inicialmente eran distintos

² Proporcionar un marco de referencia para la extensión de modelos de especiali-zación y generalización basados en UML.

El marco propuesto es de gran utilidad porque permite “hablar” un idioma ge-nérico y uni…cado basado en las características esenciales de la mayoría de propuestasde relaciones de especialización existentes. Este marco ayuda a abordar todo tipo deestudios a nivel de modelado, diseño e implementación siguiendo un único marco dereferencia.

4.5 Conclusiones

En este capítulo se ha presentado un marco multidimensional para el modelado derelaciones taxonómicas. Este marco se ha construido a través de un proceso de abs-tracción de las características estructurales y de comportamiento presentes en la ma-yoría de relaciones de especialización del modelado conceptual OO actual. Cada unade las dimensiones del marco ha sido presentada, detectándose posibles dependenciassemánticas entre ellas que permiten entender la naturaleza de la especialización. Porúltimo, se han presentado algunas aplicaciones del marco conceptual que han sido lle-vadas a la práctica en el contexto de este trabajo de tesis y otras que pueden llevarsea cabo en contextos académicos e industriales.El marco presentado está abierto a la incorporación de nuevas dimensiones, a la

sintonización de las existentes, y a su aplicación en áreas de investigación relacionadascon el tratamiento de la especialización a nivel de modelado conceptual que todavía nohayan sido consideradas. Este marco pretende incorporar las características esencialesde la mayoría de relaciones de especialización presentes en la literatura, aunque existenalgunos patrones de comportamiento, que no han sido tratados por ser éste un enfoquebasado en clases y no en objetos o prototipos. Por ejemplo, no se han detectado


patrones de comportamiento como la transferencia de objetos [121, 242], que es unaespecie de clasi…cación dinámica en la que el objeto de la subclase permanece …jo yel objeto de su superclase puede cambiar.

Capítulo 5

Un Modelo y una Notaciónpara Relaciones Taxonómicas

En este capítulo se presenta un modelo de relaciones taxonómicas para el lenguaje deespeci…cación OASIS, y en consecuencia para su método de producción de softwareasociado OO-Method. El modelo desarrollado constituye una evolución del presentadoen la versión 2.2 [176] y una extensión1 del de la versión 3 [129]. Asociado al modelotaxonómico se presenta una notación grá…ca, basada en el estándar notacional UML,para representar en OO-Method los conceptos introducidos.

El capítulo se estructura de la siguiente forma: en primer lugar, se introducenbrevemente los tipos de relaciones taxonómicas que proporciona OASIS y se analizala conveniencia de adoptar UML como notación estándar. A continuación se presen-ta cada una de las relaciones taxonómicas, introduciendo los conceptos de partición,particiones estáticas, particiones dinámicas y roles. Para cada una de las relaciones sedetallan sus propiedades más relevantes, su especi…cación en OASIS y su representa-ción grá…ca en el Diagrama de Clases extendiendo la notación UML. Posteriormentese analizan las diferencias existentes entre las particiones dinámicas y los roles, y semuestra cómo el modelo presentado da soporte a la clasi…cación múltiple.

En la parte …nal del capítulo se aborda el tema de la especialización del ciclode vida de un objeto, especi…cado textualmente en OASIS mediante un proceso ygrá…camente en OO-Method mediante un Diagrama de Transición de Estados (DTE).Este tratamiento proporciona un contenido metodológico a OO-Method, determinan-do cómo se debe especializar en las subclases el comportamiento de la clase padre(modelado en el DTE), de forma que se mantengan las propiedades (compatibili-dad de comportamiento o de signatura) exigidas para las relaciones taxonómicas delmodelo.

1En el sentido de profundizar en el modelo inicial presentado, tratando de forma detallada cómolas subclases heredan y modi…can las propiedades de la superclase.

109

110 Capítulo 5. Un Modelo y una Notación para Relaciones Taxonómicas

5.1 Introducción

En este apartado se presenta a modo de introducción los tipos de relaciones taxonómi-cas que proporciona el modelo2 OASIS y se introducen algunos conceptos básicosde OASIS para comprender mejor la propuesta que se desarrolla en este capítulo.Para …nalizar se analiza la conveniencia de adoptar UML como notación estándar quepermita representar grá…camente los conceptos introducidos.

5.1.1 Relaciones Taxonómicas en OASISEl modelo OASIS considera tres tipos de relaciones taxonómicas ortogonales entresí:

² Especialización Estática.² Especialización Dinámica.² Rol.Estas relaciones son patrones de modelado conceptual incorporados como cons-

tructores ofrecidos por el lenguaje OASIS. Las relaciones de especialización y derol constituyen mecanismos de modi…cación incremental a través de relaciones deorden entre las plantillas de las clases. Las relaciones taxonómicas que se presentanestán inspiradas en el trabajo de Roel Wieringa [238]. Para comprender mejor cómolas subclases pueden especializar las propiedades de la superclase, es importante in-troducir de forma básica qué es una clase en el modelo OASIS y cuáles son suspropiedades.

Conceptos Básicos de OASISEn OASIS, una clase está compuesta de un nombre de clase, una o más funcionesde identi…cación para las instancias (objetos) de la clase y un tipo o plantilla quetodas las instancias comparten.Cada objeto posee un identi…cador único (oid) proporcionado implícitamente por

el sistema. A nivel de especi…cación, el objeto es referenciado mediantemecanismos deidenti…cación pertenecientes al espacio del problema. Una función de identi…caciónestablece correspondencias entre los mecanismos de identi…cación y el oid del objeto.La función de identi…cación caracteriza el mecanismo de nombrado utilizado por losobjetos. Proporciona un conjunto de valores que pertenecen a un género prede…nidoo de…nido por el usuario (los llamados dominios en OASIS). Los dominios sonimportados en la de…nición de clases. Los más importantes son prede…nidos como:int, nat, real, bool, char, string y date, y representan números, valores booleanos,caracteres, cadenas de caracteres y fechas. Se pueden introducir nuevos dominios enuna especi…cación de…niendo el tipo abstracto de datos (TAD) correspondiente.Un tipo es una plantilla que recoge todas las propiedades (estructura y compor-

tamiento) compartidas por los objetos de una clase. Sintácticamente el tipo de unaclase puede formalizarse como:

2Se llama modelo OASIS al modelo formal de objetos en el cual se basa el lenguaje de especi…-cación OASIS.

5.1. Introducción 111

² una signatura, que contiene géneros, funciones, atributos (constantes, variablesy derivados) y eventos (constructores, destructores, propios y compartidos) aser usados;

² un conjunto de axiomas, que son fórmulas de una variante de la lógica di-námica presentada en [146];

² una consulta a procesos (process query), que es un conjunto de ecuaciones convariables del género proceso, resueltas en un álgebra de procesos dada. Cuandoestas variables se instancian, se tienen los términos básicos que representan lasposibles vidas de los objetos.

La semántica y el tipo de una clase OASIS se pueden ver de forma completa en[129, 176]. Este capítulo se centra en de…nir cómo se heredan y se pueden modi…carlas fórmulas que constituyen el conjunto de axiomas de la clase y la consultaa procesos que permiten especi…car el comportamiento de las subclases. Esto llevanecesariamente a profundizar en la descripción de los axiomas de la clase y de cómose especi…can los procesos.En OASIS se tienen las siguientes clases de fórmulas dinámicas (conjunto de

axiomas de la clase):

² Evaluaciones: son fórmulas de la forma © [e] ©0 cuya semántica viene dadapor una función ½ que, a partir de un evento (e) devuelve una función entremundos posibles.3

½(e) µW !W (5.1)

En el entorno de lógica dinámica un mundo posible representa una estructurade interpretación de las fórmulas dinámicas, por lo que la función ½ determi-na qué transiciones entre mundos de un objeto son válidas tras la ejecucióndel evento e. La fórmula © se evalúa en el mundo wi 2 W , y ©0 se eva-lúa en el mundo wf , siendo ½(e)(wi) = wf el mundo del objeto después dela ejecución en wi del evento e. Como ejemplo se presentan dos evaluaciones.En la evaluación de la fórmula 5.2 de la clase Vendedor (ver Apéndice A4),cuando ocurre el evento vender, si se cumple bonificacion<100000 (mundoantes de la ejecución del evento) entonces se alcanza un mundo que satisfacela postcondición bonificacion=bonificacion+n_productos*10. El resultadoconstituirá el nuevo mundo del objeto. En la evaluación de la fórmula 5.3 dela clase Persona, cuando ocurre el evento cumplir_años se alcanza un mundoque satisface la postcondición edad=edad+1 porque es independiente del estadoanterior (valor a true). En las fórmulas ©0 se utilizará el operador “:=” en vezde “=” para proporcionar una interpretación más restrictiva, aunque intuitivade la semántica de las evaluaciones. Si no se especi…ca la fórmula © se asumeque es verdadera.

3El estado de un objeto se de…ne como el conjunto de sus atributos evaluados. Un atributoevaluado es un par <nombre,valor>, donde nombre es el identi…cador del atributo y valor perteneceal conjunto de valores que puede tomar el atributo.

4En este apéndice se desarrolla un ejemplo completo en el que se incluyen los ejemplos que sepresentan en esta sección.


boni¯cacion < 100000 [vender(n_productos)]

boni¯cacion := boni¯cacion+ n_productos ¤ 10 (5.2)

true [cumplir_a~nos] edad := edad+ 1 (5.3)

² Derivaciones: son fórmulas del tipo ©! ©0. Permiten de…nir atributos deri-vados (©0) en términos de una expresión de derivación dada (declarada en ©).Las derivaciones di…eren principalmente de las fórmulas de evaluación en el he-cho de que esta evaluación derivada se hace en un único estado. Un ejemplo sepuede ver en la fórmula de derivación 5.4 donde el valor del atributo derivadofechaFin_Servicio (de …nalización del servicio militar o social) se calcula apartir de la fecha de inicio del servicio (fechaIni_Servicio) y los meses quedure (DuracionMeses).

fechaFin_Servicio := inc (fechaIni_Servicio; DuracionMeses) (5.4)

² Restricciones de Integridad: son fórmulas que deben satisfacerse en todoslos mundos. Se distinguirá entre restricciones estáticas y dinámicas.

– Las restricciones estáticas son aquellas válidas en todo mundo posible ydeben cumplirse siempre.

– Las restricciones dinámicas son aquellas que relacionan mundos diferen-tes. Requieren el uso de una lógica temporal, con sus correspondientesoperadores temporales.

Un ejemplo de restricción de integridad estática es la fórmula 5.5 donde se exigeque el sueldo_base de un Empleado siempre sea mayor que 60000 pesetas.

sueldo_base > 60:000 (5.5)

² Precondiciones: son fórmulas con el esquema :© [e] false, donde © es unafórmula que debe cumplirse en el mundo anterior a la ejecución del evento e.Sólo en los mundos donde © se cumple, se permite que ocurra e. Si se cumple:©, la ocurrencia de e no genera ningún estado sucesor válido. En la fórmula5.6 se presenta una precondición del evento dar_a_luz de la clase Mujer en laque se especi…ca que una mujer no puede dar a luz si no está embarazada.


:(estado = \embarazada") [dar_a_luz ] false (5.6)

De forma equivalente, se escribirá la precondición en un estilo más convencionalde la siguiente manera:

dar_a_luz if estado = \embarazada" (5.7)

² Disparos: son fórmulas de la forma © [:e] false, donde :e es la negacióndel evento5. Si se cumple © y ocurre otra acción distinta a e entonces no haymundo sucesor. Esto fuerza a que e ocurra si se cumple © o el sistema perma-nece bloqueado. En sentido genérico, en OASIS 3.0 un evento es consideradocomo una tripleta <Cliente, Servidor, Servicio>, de esta forma la semántica deun disparo posee dos posibles acepciones: (1) visto desde la perspectiva cliente,se obliga a que el cliente active un determinado evento (enviándolo a un objetoservidor), y (2) desde la perspectiva servidora, se obliga a que un servidor recibauna petición de un determinado evento (se bloquea hasta que no le llegue). Eneste trabajo se trata únicamente la primera acepción, así pues, los disparos seconsideran eventos activados cuando las condiciones declaradas en © se cum-plen. La diferencia principal entre precondiciones y disparos viene dada por elhecho de que en los disparos hay una obligación de activar un evento cuando lacondición sea satisfecha. Los disparos permiten de esta forma introducir activi-dad interna en la sociedad de objetos que está siendo modelada. En la fórmuladinámica que especi…ca el disparo se incluirá información sobre el destino delevento a disparar, por ejemplo la fórmula 5.8 hace que un objeto Persona sedispare a sí mismo el evento revision_medica si tiene 45 o 65 años de edad:

edad = 45 or edad = 65 [:(self :: revision_medica)] false (5.8)

De forma equivalente, se escribirá el disparo en un estilo más convencional dela siguiente manera:

self :: revision_medica when fedad = 45 or edad = 65g (5.9)

En cualquiera de las fórmulas dinámicas presentadas anteriormente, © y ©0 sonfórmulas bien formadas en una lógica de primer orden que se re…eren a un mundo delsistema, caracterizado por un conjunto de valores ligados a atributos de objetos endicho mundo.En OASIS, un objeto se de…ne como un proceso observable [188]. La espe-

ci…cación de procesos en una clase permite especi…car la dinámica de los objetos(la vida de un objeto) y determinar las relaciones de acceso entre los estados6 de las

5Signi…ca que e no ocurre, y no se especi…ca qué ocurre.6A partir de ahora en el documento hablaremos de estado como la caracterización de un mundo.


instancias. Los procesos se construyen usando eventos como acciones atómicas. Eldiseñador también tiene la posibilidad de agrupar eventos en unidades de ejecuciónllamadas transacciones. Las transacciones son unidades moleculares que tienen dospropiedades particulares:

² siguen una política de todo o nada con respecto a la ejecución de los eventos quela constituyen: cuando ocurre un fallo durante la ejecución de una transacción,el estado resultado es el inicial.

² la no observabilidad de estados intermedios.La especi…cación de proceso se representa con términos en un álgebra de procesos

de…nida de forma precisa, que está basada en el enfoque presentado en [235]. Ellopermite declarar vidas posibles de objetos como términos cuyos elementos son tran-sacciones y eventos. Cada proceso puede ser reescrito a un término en un ÁlgebraBásica de Procesos BPA±², con las operaciones elementales de procesos: ² (secuencia)y + (alternativa). Como ejemplo, a continuación se presenta el proceso que describela vida de un objeto de una clase Persona, en él se pueden observar las variables detipo proceso Persona y Persona0.

Persona = crear²Persona0;Persona0 = (cambiar_direccion(ndir) + cambiar_telefono(ntel) +incrementar_edad + revision_medica + contratar + matricular )²Persona0 +eliminar;

Es importante destacar que los eventos, acciones (evento con agentes) y tran-sacciones (composición de eventos) constituyen unidades de ejecución atómicas quellamaremos de forma genérica servicios. Con la intención de no complicar la presen-tación del trabajo de tesis, a partir de ahora se va a tratar siempre con eventos. Losresultados presentados se podrán extender a las acciones y transacciones de formadirecta cambiando el término evento por acción o transacción.Hasta aquí se ha presentado de una manera general las características más re-

levantes de OASIS, en [129, 176] se puede obtener una descripción completa dellenguaje.

5.1.2 Aspectos Notacionales. OO-Method y UML

UML (Lenguaje de Modelado Uni…cado) [86] es un lenguaje para visualizar, especi…-car, construir y documentar sistemas software. En un corto período de tiempo, UMLse ha convertido en el lenguaje de modelado dominante en la industria del software.Este lenguaje ha encontrado numerosos usos en distintos dominios de aplicación (apli-caciones de gestión, tiempo real, comercio electrónico, juegos, etc...). Se utiliza parael modelado del negocio, y para describir arquitecturas y patrones software. UMLha in‡uenciado considerablemente en la industria de las herramientas CASE, mejo-rando su calidad y disponibilidad para facilitar el proceso de modelado. De hecho,actualmente la mayoría de herramientas CASE permiten la especi…cación de sistemasde información utilizando la notación que proporciona UML, y se están proponiendoprocesos de desarrollo de software como RUP [112], basados en UML.UML combina los conceptos comúnmente aceptados por muchos de los métodos de

análisis y diseño orientado a objetos de primera y segunda generación, presentándose


como la uni…cación de las notaciones de Booch, Rumbaugh (OMT) y Jacobson. UMLha sido aprobado por el Object Management Group (OMG) como estándar notacionalpara el modelado conceptual orientado a objetos. En su estado actual está de…nidopor un conjunto de documentos controlados por OMG. Estos documentos son: unresumen de UML (UML Summary), la semántica de UML (UML Semantics), la guíade la notación UML (UML Notation Guide), dos per…les estándares (UML StandardPro…les), una interfaz a un repositorio para crear, almacenar y recuperar modelosUML, de…nida mediante CORBA IDL (UML CORBA Facility Interface De…nition),un formato para el intercambio de modelos UML entre distintas herramientas CA-SE (UML XMI DTD Speci…cation) y un lenguaje para especi…car reglas mediantefórmulas bien formadas (Object Constraint Language).Es muy importante destacar que muchos autores reconocen algunas de…ciencias y

problemas del UML, sobre todo con respecto a la de…nición precisa de la semántica(especi…cada mediante un metamodelo, el lenguaje OCL y la utilización del idiomainglés) y a la introducción de elementos redundantes (idénticos pero denotados connotaciones y/o descripciones distintas). Por último, es interesante comentar que UMLno está asociado con ningún proceso de desarrollo en particular, por lo que en elestándar no se incluye una descripción detallada de un proceso de producción desoftware especí…co que esté asociado a UML.Para la supervivencia de los métodos OO de desarrollo existentes, parece casi obli-

gatorio adoptar una notación basada en UML. En la aproximación que se presentaen esta tesis, los conceptos asociados al modelo formal de OASIS determinan lainformación relevante a capturar en la fase de modelado conceptual. Para facilitarel proceso de modelado, se va a proporcionar una notación grá…ca que recoja laspropiedades relevantes de un sistema de información. Como diagramas se utilizaránlos tres modelos que incorpora OO-Method. Estos modelos respetarán y extenderánla notación UML, aunque su semántica se concebirá para declarar con precisión sóloaquel conjunto de información que sea realmente necesaria para describir el sistema.La notación UML se adaptará para que pueda expresar visual e intuitivamente losconceptos de…nidos en el lenguaje de especi…cación. En el caso de no poder de…nirgrá…camente todos los conceptos se utilizará la propia sintaxis del lenguaje de especi-…cación asociada a estereotipos perfectamente determinados. Es importante resaltarque se excluye de la notación grá…ca aquellos elementos que no sean necesarios paradar soporte a la expresividad que aporta el modelo formal de objetos. Con ello seevita la sobrecarga semántica asociada a la notación UML, en la que lo mismo sepuede expresar de muchas maneras diferentes.De los modelos que presenta OO-Method, el Modelo de Objetos y el Modelo Di-

námico (más concretamente su Diagrama de Transición de Estados) deben adaptarsepara representar adecuadamente las relaciones taxonómicas (particiones estáticas, lasdinámicas y los roles) que se introducen en el modelo formal de OASIS. El Diagramade Interacción y el Modelo Funcional no se ven afectados por los cambios introducidosen el modelo taxonómico, así que pueden utilizarse directamente como se presentan enOO-Method [165, 168]. Debido a esta circunstancia, en los apartados siguientes se vaa presentar cómo extender el Modelo de Objetos para representar a nivel estructurallas relaciones taxonómicas, y en la parte …nal del capítulo se presenta cómo se puedenespecializar los DTE de las subclases (estáticas, dinámicas y roles) para mantenerla compatibilidad de comportamiento exigida por las particiones, y la de signatura


exigida por los roles.

Una vez se han presentado los conceptos básicos deOASIS y se conoce qué diagra-mas de OO-Method se ven afectados por las relaciones taxonómicas, a continuación,se van a presentar los conceptos que de…nen el modelo de relaciones taxonómicas. Enprimer lugar se introduce el concepto de partición, y posteriormente las particionesestáticas (para dar cuenta de la especialización estática), particiones dinámicas (paradar cuenta de la especialización dinámica) y los roles. Para cada una de las rela-ciones se detallan sus propiedades más relevantes, su especi…cación en OASIS y surepresentación grá…ca en el Diagrama de Clases, extendiendo la notación UML.

5.2 Particiones

Siguiendo la terminología propuesta en el marco de referencia, donde se han de…nidolos conceptos de intensión (int(C)), extensión (ext(C)) y población (o conjuntode existencia) de una clase C en un determinado instante t (extt(C)), se presenta acontinuación el concepto de partición que constituye un pilar básico en el modelo derelaciones taxonómicas que se propone.

De…nición 1 Una partición establece una relación de especialización entre una su-perclase y las subclases formadas por subconjuntos de instancias de la superclase. Unapartición divide todo el espacio de objetos de la superclase en subconjuntos completosy disjuntos. Es decir, siendo S1; :::; Sn subclases de una clase P entonces fS1; :::; Snges una partición de P si se cumple que:

extt(P ) = [extt(Si); 8i = 1; :::; n (5.10)

extt(Si) \ extt(Sj) = ;; i 6= j;8i; j = 1; :::; n (5.11)

Las expresiones 5.10 y 5.11 representan respectivamente las propiedades de com-pletitud y disyunción que posee una partición. Se pueden de…nir diversas particionessobre una misma clase. En una partición cada objeto es instancia a la vez de la su-perclase y de una (y sólo una) de las subclases. Las propiedades de la superclase y delas subclases de la partición (y de los roles como se verá más adelante) se especi…canseparadamente en sus respectivas plantillas de clase.

5.2.1 Propiedades de las Subclases

Dada una partición de la superclase P; constituida por las subclases fS1; :::; Sng, seexigirá que en la especi…cación de cada subclase Si 8i = 1; :::; n de la partición, secumplan las siguientes condiciones:

² La subclase podrá introducir un conjunto de atributos nuevos a los que se deno-minará AtrNSi . Así, los atributos de la subclase serán AtrSi = AtrP (atributospropios de P ) [ AtrNSi .

5.2. Particiones 117

² La subclase heredará los mecanismos de identi…cación de la clase P (llamadosAtrIdP , tal que AtrIdP 2 AtrP ), aunque en Si se podrán de…nir, de maneraopcional, mecanismos de identi…cación adicionales a los heredados (AtrIdSi 2AtrNSi). Es muy importante hacer notar que en las particiones las subclasessiempre heredan el oid de la superclase.

² La subclase podrá introducir un conjunto de eventos nuevos (a los que se llamaráEvNSi). Cada subclase Si tendrá sus eventos propios más los que hereda de lasuperclase. Por lo que los eventos de la subclase serán EvSi = EvP (eventos deP ) [ EvNSi .

En lo que respecta a los axiomas y al proceso que determinan el comportamientode las subclases, se exigirá compatibilidad de comportamiento entre P y Si. Enesta aproximación se entiende como comportamiento compatible aquél en el que lasinstancias de la clase hija Si se comportan como instancias de la clase padre P paratodos los eventos y argumentos de…nidos en la clase padre. En la especialización, laspropiedades de…nidas en las clases pueden ser re…nadas en las subclases. Desde unpunto de vista lógico, un objeto se corresponde con una teoría en lógica dinámicade…nida como consecuencia de una serie de axiomas, y la especialización signi…caañadir nuevas proposiciones manteniendo todas las consecuencias lógicas (haciendolas condiciones más restrictivas).Para mantener la compatibilidad de comportamiento, en cualquier subclase Si de

la partición se cumplirán las siguientes restricciones sobre sus axiomas:

² Las fórmulas de evaluación que se de…nan en Si (llamadas EvalNSi , por serevaluaciones nuevas de Si) se podrán especi…car para eventos nuevos y heredadosde Si.

– los eventos nuevos podrán modi…car atributos nuevos (AtrNSi) de Si oheredados (AtrP ) si éstos últimos no han sido modi…cados por ningúnevento de P . A este tipo de evaluaciones se les llamará EvalEvNSi ; porser evaluaciones especi…cadas sobre eventos nuevos de Si:

– los eventos heredados podrán modi…car cualquier atributo nuevo (AtrNSi)de la subclase Si. A este tipo de evaluaciones se les llamará EvalEvP ;por ser evaluaciones especi…cadas sobre eventos heredados de P: La modi-…cación de atributos nuevos por eventos heredados puede verse como unaextensión que preserva el comportamiento heredado de la superclase.

Así pues, las evaluaciones de Si serán EvalNSi = EvalEvP [ EvalEvNSi : Unejemplo donde se aplica la propuesta puede ser:

Ejemplo 3 La especi…cación del evento subir_sueldo de un Empleado tienecomo efecto en el empleado, el incrementar su sueldo_base en una determinadacantidad ([subir_sueldo(Incremento)] sueldo_base = sueldo_base + Incremento),y tiene efectos en la subclase Vendedor inicializando su bonificacion a 0 ([su-bir_sueldo(Incremento)] boni…cacion:=0). Según lo presentado la evaluación delevento en la subclase Vendedor será:


[subir_sueldo(Incremento)] sueldo_base = sueldo_base + Incremento;

[subir_sueldo(Incremento)] boni…cacion:=0;

En algunas aproximaciones [158] se permite la modi…cación de atributos here-dados que posean evaluación en la superclase, siempre que se respete el espaciode estados7 determinado por las restricciones de integridad (que actúan comopostcondiciones). Esta opción no se considera en la aproximación presentadapara evitar problemas e inconsistencias, ya que en tiempo de especi…cación nose puede evaluar con facilidad si la rede…nición de la evaluación va a respetar elespacio de estados de…nido en la superclase.

² Las precondiciones de un evento, que se de…nan en Si (denominadas PrecNSi ,por ser precondiciones nuevas de Si) podrán ser:

– precondiciones de…nidas sobre eventos nuevos (denominadas PrecNSiEvNSi).

– precondiciones de…nidas sobre eventos heredados (denominadas PrecNSiEvP ).Éstas a su vez podrán ser:

¤ precondiciones nuevas (denominadas PrecNuevasNSiEvP ): son pre-condiciones de…nidas sobre eventos heredados que no tenían precondi-ción asociada. Estas precondiciones respetarán la compatibilidad decomportamiento porque un evento sin precondición siempre es acti-vable (precondición a verdadero) y cualquier precondición nueva quese le de…na en la subclase siempre será más restrictiva, por lo queimplicará verdadero.

¤ precondiciones rede…nidas (denominadas PrecRedefNSiEvP ): son re-de…niciones de precondiciones asociadas a eventos de la clase padre P .Éstas deben implicar lógicamente la precondición en P para mante-ner la compatibilidad de comportamiento. Dada la compatibilidad decomportamiento, si una subclase rede…ne una precondición de un even-to de la clase padre, entonces prevalece la precondición de la subclase,sobrescribiendo la de la clase padre.

Así pues, el conjunto de precondiciones de Si será PrecSi = (PrecP(precondiciones de P )¡PrecRedefNSiEvP )[PrecNSiEvNSi[PrecNuevas-NSiEvP [PrecRedefNSiEvP , signi…cando (PrecP ¡PrecRedefNSiEvP )aquellas precondiciones de P que no han sido rede…nidas en Si. EntoncesPrecSi será la unión de las precondiciones de la clase padre que no hansido rede…nidas y las que se han de…nido en la subclase Si. Un ejemplodonde se aplica la propuesta puede ser:

Ejemplo 4 En una clase Empleado se ha especi…cado la siguiente precondiciónpara el evento subir_sueldo: subir_sueldo(incremento) if (( hoy - fecha_ultima-_revision >= 12 ). Ésta habilita el incremento del sueldo cuando el Empleadolleve trabajando 12 o más meses desde la última revisión salarial. En la subclaseResponsable, la precondición se ha rede…nido haciéndola más restrictiva de estamanera: subir_sueldo(incremento) if (( hoy - fecha_ultima_revision>= 12 ) and (

7 Según [158], el espacio de estados de una clase es el conjunto de todos los estados permitidospara un objeto de dicha clase.


nClientes > 100 )). Según lo presentado, la precondición del evento en la subclaseResponsable será la rede…nida por implicar lógicamente a la de la superclase.

² Las restricciones de integridad cumplirán las mismas propiedades que las pre-condiciones, prevaleciendo siempre la condición más restrictiva. Éstas se podránespeci…car sobre atributos heredados y nuevos. Las restricciones de integridadnuevas que se de…nan en Si (denominadas RestNSi) podrán ser:

– restricciones nuevas (denominadas RestNuevasNSi). Son nuevas restric-ciones de…nidas sobre atributos nuevos (AtrNSi) y heredados (AtrP ), conla condición de que estos últimos no deben tener ninguna restricción de in-tegridad de…nida sobre ellos. Se podrán de…nir restricciones sobre este tipode atributos heredados respetando la compatibilidad de comportamientoporque al ser siempre condiciones más restrictivas (ya que en la superclaseno tenían de…nida ninguna restricción) entonces se garantizará que cuandose cumplan en la subclase, siempre se cumplirán en la superclase, por loque siempre se podrá llevar a cabo el cambio de estado.

– restricciones rede…nidas (denominadas RestRedefNSi). Son rede…nicio-nes de restricciones heredadas de P (llamadas RestP ). Deberán implicarlógicamente la restricción en P para mantener la compatibilidad de com-portamiento.

El conjunto de restricciones de Si será RestSi = (RestP ¡ RestRedefNSi) [RestNuevasNSi [RestRedefNSi , signi…cando que las restricciones de integri-dad de Si serán la unión de aquellas restricciones de P que no han sido rede…ni-das en Si (RestP¡RestRedefNSi), de las restricciones nuevas (RestNuevasNSi)y de las restricciones rede…nidas (RestRedefNSi) sobrescribiéndo las de P . Unejemplo donde se aplica la propuesta puede ser:

Ejemplo 5 En la clase Empleado se ha especi…cado la siguiente restricción deintegridad edad >= 16 en la que se exige que una persona para poder trabajartenga 16 o más años. En Responsable, la subclase de Empleado, se rede…ne larestricción heredada haciéndola más restrictiva. Esta restricción será edad >=24 por la cual se exige que un vendedor sólo podrá pasar a responsable a partirde los 24 años de edad. Según lo presentado, la restricción de integridad quedeberá cumplirse para un objeto de la subclase Responsable será edad >= 24.

² Las condiciones de disparo que se de…nan en Si (denominadas DispS, que apartir de ahora se llamarán disparos) podrán activar eventos nuevos en Si oheredados de P , además de eventos de otras clases del sistema. Los disparosque se especi…quen en Si podrán ser:

– disparos nuevos (denominados DispNuevosSi): son aquellos que activaneventos nuevos de Si (EvNSi), eventos heredados de P (EvP ) o de otrasclases del sistema EvC ; siendo C cualquier clase del sistema tal que C 6=Si;8Si 2 fS1; :::; Sng y C 6= P , siempre que alguno de éstos dos últimostipos de eventos no participen como evento a activar en un disparo heredadode P . En este caso, las condiciones de disparo se podrán de…nir (sin ningún


tipo de restricción) sobre atributos nuevos (AtrNSi) y heredados (AtrP ).En esta situación la subclase Si extiende el comportamiento de P .

– disparos rede…nidos (denominados DispRedefSi): son aquellos que acti-van eventos heredados de P (EvP ) o de otras clases del sistema (EvC)que participan como evento a activar en disparos de…nidos en P (DispP ).La compatibilidad de comportamiento y el principio de reemplazabilidad sehan estado aplicando desde una perspectiva servidora, es decir, en todomomento se trata de los eventos que puede aceptar una subclase y de lascondiciones que se han de cumplir sobre el estado del objeto servidor paraque se comporte como un objeto de la superclase. Sin embargo, los dis-paros forman parte de la perspectiva cliente de las clases. Las propuestasexistentes sobre compatibilidad de comportamiento no tratan la perspec-tiva cliente de los objetos, por lo que en los disparos deberá extenderse.La especialización se considera un proceso de extensión, que preserva laspropiedades especi…cadas en la superclase, y un proceso de restricción, ha-ciendo más especí…cas las propiedades de la clase especializada. Así pues,parece lógico que en la perspectiva cliente se deban cumplir las premisasde extensión y restricción comentadas anteriormente. Para que se cumplanestas premisas en las rede…niciones, los disparos de P se podrán rede…niren una subclase Si si se cumplen las dos condiciones siguientes:

¤ Restricción: las condiciones de disparo rede…nidas para un determina-do evento deben implicar lógicamente a las condiciones de disparo dela superclase para el mismo evento. De esta forma las condiciones dedisparo se hacen más especí…cas en la subclase y así cuando se cum-pla la condición de disparo en la subclase se cumplirá también en lasuperclase.

¤ Extensión: se pueden añadir nuevas condiciones a un disparo here-dado o rede…nido, siempre que no inter…era en el cumplimiento de lacondición heredada.

En ambos casos el nuevo disparo podrá rede…nir el disparo heredado so-brescribiéndolo.

Así el conjunto de disparos de Si será DispSi = (DispP ¡ DispRedefSi) [DispNuevosSi[ DispRedefSi ; es decir, la unión de aquellos disparos de P queno han sido rede…nidos en Si;con los disparos nuevos especi…cados en Si y losdisparos de P que han sido rede…nidos en Si;sobrescribiendo los de P . Unosejemplos representativos de esta situación de modelado para cada una de lascondiciones propuestas pueden ser:

Ejemplo 6 A todo Empleado se le quita la boni…cación acumulada mensual-mente si tiene 5 bajas. Al empleado que trabaja como Responsable se le qui-tará si se cumple dicha condición y además tiene menos de 10 clientes. Estassituaciones se modelan a través de los siguientes disparos.

triggers {clase Empleado}

self:quitar_boni…cacion if {bajas=5};


triggers {clase Responsable}

self:quitar_boni…cacion if {bajas=5 and nClientes<10};

En este caso el disparo de la subclase Responsable implica lógicamente al dela superclase Empleado. El responsable restringe su comportamiento desde laperspectiva cliente.

Ejemplo 7 Toda Persona debe hacerse una revisión médica a los 45 y 65 años,pero además todas aquellas personas que sean Mujeres y tengan 35 años sin ha-ber tenido hijos también deberán hacerse una revisión médica obligatoria. Estassituaciones se modelan a través de los siguientes disparos.

triggers {clase Persona}

self::revision_medica() if {edad=45 or edad=65};

triggers {clase Mujer}

self::revision_medica() if {edad=45 or edad=65 or (edad = 35 and hijos=0)};

En este caso el disparo de la subclase Mujer añade una nueva condición al disparode la superclase Persona. De esta forma la mujer extiende su comportamientodesde la perspectiva cliente sin interferir en el cumplimiento de las condicionesheredadas.

² El tratamiento de la especialización del ciclo de vida de un objeto, especi…cadoen OASIS mediante un proceso, se llevará a cabo en un apartado posterior.En este apartado se abordará este tema a través de la especi…cación de los ciclosde vida en el modelo dinámico de OO-Method.

En este apartado se han presentado las propiedades que debe cumplir una subclasede una partición. A continuación, se presenta una propuesta de notación grá…ca paralas particiones basada en el Diagrama de Clases de UML.

5.2.2 Representación en el Diagrama de Clases

En este apartado se introducen algunas extensiones e interpretaciones semánticasal Diagrama de Clases de UML con la idea de ofrecer una notación que sea capazde dar soporte al modelado estructural de las particiones. Utilizando esta notaciónel especi…cador no necesitará tener conocimiento de la existencia del lenguaje deespeci…cación, ya que se le ofrecerá una sintaxis visual como interfaz al modelo deobjetos.La relación de especialización/generalización en UML se representa mediante una

‡echa que apunta de la subclase a la clase padre. La punta de la ‡echa tiene laforma de un pequeño triángulo vacío, lo que permite diferenciarla de la ‡echa abiertaque es el símbolo de la propiedad de navegación. En el ejemplo de las Figuras 5.1 y5.2 las clases B, C y D son una especialización de la clase A. En UML, en el casode que existan múltiples subclases de una clase, las ‡echas pueden agregarse en unasola o representarse de manera independiente. Estos dos tipos de representacionesno fuerzan una semántica en particular. Sin embargo, en la nueva notación de OO-Method se les proporcionará una semántica particular. Las subclases cuyas ‡echasse unan en una única ‡echa constituirán una partición, de este modo por ejemplo en


Figura 5.1: Representación de una Partición

Figura 5.2: Representación de tres particiones

la …gura 5.1 las clases B, C y D serán subclases de una única partición de A: Lassubclases que tengan su propia ‡echa (no compartida con otras subclases) constituiránuna partición por ellas mismas, así pues en la …gura 5.2 cada clase constituirá unapartición de A.En el modelo de objetos que se presenta, se exige que una subclase sea un ele-

mento de una partición de su superclase inmediatamente superior en la jerarquía.La pertenencia a una partición obliga a que la partición sea completa lo que implicaque cualquier partición que se haga de los elementos de una clase para de…nir nuevassubclases deberá tener al menos dos elementos, tal y como se puede ver en la …gura5.3. De este modo se persigue que cualquier criterio de clasi…cación escogido parade…nir las subclases no sea ambiguo.Si se observa el ejemplo de la …gura 5.3, toda Persona será Estudiante o no

pero, en cualquier caso, siempre será instancia de alguna de las subclases de…nidasde acuerdo al criterio de especialización escogido. En este caso el criterio podrá ser“estar o no matriculado” en algún centro educativo.La restricción de la completitud es una solución interesante a nivel metodológico

pero a nivel notacional conlleva un mayor esfuerzo para el analista ya que debe adoptarrepresentaciones grá…cas de jerarquías de especialización/generalización que no estáacostumbrado a manipular. La notación grá…ca que se propone mantendrá toda laexpresividad y las restricciones que impone el modelo formal introducido, tratandoalgunas restricciones de forma transparente al analista.En OO-Method se especi…cará si una partición es completa o no mediante las

5.3. Particiones Estáticas 123

Figura 5.3: Partición de Persona en Estudiante y No Estudiante

Figura 5.4: Partición de Vehículo Incompleta

restricciones {completa}8 e {incompleta} respectivamente. Por defecto, se supondráque en el diagrama de clases todas las particiones serán completas si el analista noespeci…ca nada en concreto, lo que implicará que no será necesario incluir la restricción{completa} en aquellas particiones que sean completas. Por cuestiones metodológicas ycon la intención de respetar el modelo presentado, las particiones incompletas tendránuna subclase adicional oculta al analista que representará a todos aquellos objetos queson de la superclase y no pertenecen a ninguna subclase de la partición. Esta claseoculta convertirá la partición incompleta en completa como exige el modelo. Enlas …guras 5.4 y 5.5 se presenta un ejemplo de partición. Sea cual sea el tipo departición las clases que posean una única subclase siempre constituirán una particiónincompleta. En estas condiciones, el ejemplo de la Figura 5.4 es equivalente al de laFigura 5.5.

5.3 Particiones Estáticas

De…nición 2 Sean S1; :::; Sn subclases de una clase P , entonces fS1; :::; Sng es unapartición estática de P si se cumple que:

8No en el estricto sentido de la propuesta UML, sino con la semántica de la restricción estáticapropuesta en el marco conceptual del capítulo 4.


Figura 5.5: Partición de Vehículo Completa

ext(P ) = [ext(Si); 8i = 1; :::; n (5.12)

ext(Si) \ ext(Sj) = ;; i 6= j;8i; j = 1; :::; n (5.13)

Cada Si será una subclase de la partición estática (llamada subclase estática) de laclase P . Intuitivamente, en una partición estática las instancias de las subclasesde…nidas están asociadas a una partición a partir de su creación, y se mantienen enella durante toda su existencia. Existe una multiplicidad implícita asociada a cadapartición por la que cada instancia de la subclase está relacionada con exactamenteuna instancia de la superclase. Así si un objeto es instancia de P entonces es instanciaexactamente de una subclase de cada partición de P a lo largo de toda su vida.


En este apartado se de…nen las propiedades especí…cas de las subclases de una parti-ción estática, que complementan a las propiedades esenciales que deben satisfacer lassubclases de una partición.En el modelo formal OASIS, la creación de un objeto de una subclase en una

partición estática se puede producir mediante creación directa, en la cual los objetos secrean activando directamente los eventos constructores de la subclase correspondientede la partición, o a través del cumplimiento de una condición de…nida sobre el valor deatributos constantes. A continuación se analiza cómo se representan estos dos casosen el modelo:

1. Creación Directa: Cada subclase Si de la partición estática fS1; :::; Sng poseeráal menos un evento constructor EvnewSi tal que EvnewSi 2 Si. La creacióndirecta de los objetos de las subclases garantiza la completitud, ya que de estaforma no se puede crear una instancia de la superclase que no sea instanciade ninguna de sus subclases en la partición. La disyunción de las particionesestáticas se debe garantizar comprobando que, en la creación de un objeto deuna subclase, no exista en la partición un objeto con el mismo oid que el que

5.3. Particiones Estáticas 125

se va a crear. Esto puede verse como una precondición sobre la población de laclase especi…cada en el evento constructor EvnewSi de la subclase.

2. Creación basada en condiciones sobre atributos constantes: La creación directapuede ser vista en algunas situaciones como un proceso de creación restrictivo.Dentro del modelo presentado se puede adoptar la aproximación basada en cri-terios de especialización de…nidos sobre el valor de atributos constantes de laclase padre. Esta propuesta está presente en muchas aproximaciones formalespara especializaciones estáticas. La creación basada en condiciones sobre atri-butos puede considerarse en este modelo como un caso particular de la creacióndirecta. Esta técnica de creación de subclases se representará en el modelo,permitiendo que se creen instancias de la superclase utilizando sus constructo-res propios. Los constructores de la superclase tendrán la naturaleza de unatransacción que comprobará la condición de especialización y creará el objetode la subclase estática correspondiente.

En esta aproximación se debe garantizar que las condiciones de especializaciónde…nidas abarquen todo el rango de valores posible para que de…nan en realidaduna partición completa. En el caso de que no fuese completa, se generará unasubclase virtual que representará a todos aquellos objetos que no cumplen lascondiciones de especialización o que no se han creado directamente. Un ejemplode esta situación podría darse en la partición estática de Vehículo en Coche,Camión y Otros presentada anteriormente. Si no se hubiese especi…cado la claseOtros, la partición sería incompleta por lo que para garantizar su completi-tud, se debería generar de forma transparente una nueva subclase que incluyeraaquellos vehículos que no son coches ni camiones.

En este tipo de partición cuando se destruye el objeto en la subclase también esdestruido como instancia de la superclase y viceversa.

5.3.2 Especi…cación

La sintaxis en forma BNF que se utiliza para especi…car una partición estática enOASIS es la siguiente:———————————————————————————————<def_particion_estatica> ::= <def_estatica_creacion_directa>

j <def_estatica_atributo>———————————————————————————————La especi…cación de las subclases con sus nuevas propiedades se realizará siguiendo

la plantilla utilizada para la especi…cación de cualquier clase OASIS.

Particiones Estáticas de Creación Directa.

Para especi…car una partición estática de creación directa se utiliza la siguiente sin-taxis:———————————————————————————————<def_estatica_creacion_directa> ::= <lista_id_subclase>

static specialization of<id_clase>


———————————————————————————————donde <lista_id_subclase> son subclases de la misma partición estática sobre la clasedeterminada por <id_clase>. Como ejemplo de especi…cación de dos particionesestáticas de este tipo se puede ver:

Ejemplo 8 Dos particiones estáticas de la clase vehiculo.

camion, coche, otro_vehiculostatic specialization of vehiculo;

gasolina, dieselstatic specialization of vehiculo;

En el ejemplo anterior una instancia de vehiculo debe pertenecer obligatoriamen-te a una de las tres subclases: camion, coche u otro_vehiculo y a otra de las dossubclases: gasolina o diesel.

Particiones Estáticas de…nidas mediante Atributos Constantes.

La sintaxis que se utiliza para especi…car una partición estática de…nida sobre el valorde un atributo constante es la siguiente:——————————————————————————<def_estatica_atributo> ::= <lista_def_subclase_estatica>

static specialization of<id_superclase>

<def_subclase_estatica> ::= <id_subclase>where ‘{’<fórmula>’}’

——————————————————————————donde <id_subclase> son subclases de la misma partición estática de la clase <id_su-perclase> y cada subclase va acompañada de una fórmula de…nida sobre atributosconstantes de la superclase. El valor del atributo constante en la creación del objetodetermina la subclase de la partición estática en la cual se especializa la superclase deforma permanente. Como ejemplo de especi…cación de una partición estática de…nidamediante atributos constantes se puede ver:

Ejemplo 9 Dos particiones estáticas de la clase vehiculo.

gasolina where {tipo_combustible=’’gasolina’’}diesel where {tipo_combustible=’’gasoleo’’}

static specialization of vehiculo;

Este ejemplo especi…ca de nuevo el ejemplo presentado anteriormente en la queuna instancia de vehiculo puede especializarse en las subclases: gasolina o diesel.Aquí se de…ne dependiendo del atributo tipo_de_combustible que utilicen.


Para representar las particiones estáticas se introduce la siguiente notación:

5.4. Particiones Dinámicas 127

Figura 5.6: Partición Estática de Vehículo

² Para las particiones estáticas de creación directa se utilizará la misma notaciónque la introducida para las particiones. En la …gura 5.5 se presenta un ejemplode una partición estática de creación directa para la clase Vehículo. A partirde la de…nición de partición estática, la interpretación del modelo grá…co de la…gura sería la siguiente: un coche no puede convertirse en camión o viceversa.

² Para las particiones estáticas basadas en condiciones sobre atributos constantesse introducirá un estereotipo << condición de especialización >> asociado a lalínea que une una subclase estática con la ‡echa que apunta a la superclase.La condición de especialización será una fórmula bien formada, evaluada so-bre atributos constantes que explicitará la forma en la que se especializa unainstancia de la superclase en dicha subclase. En la …gura 5.6 se puede ver unaespeci…cación basada en condiciones sobre atributos de una partición estática devehículo. El criterio de especialización elegido es dependiente del tipo de com-bustible. Un vehículo es de gasolina si el atributo combustible=’gasolina’, yes diesel si el combustible=’diesel’.

5.4 Particiones Dinámicas

De…nición 3 Sean S1; :::; Sn subclases de una clase P , entonces fS1; :::; Sng es unapartición dinámica de P si para cada instante t se cumple que:

extt(P ) = [extt(Si); 8i = 1; :::; n (5.14)

extt(Si) \ extt(Sj) = ;; i 6= j;8i; j = 1; :::; n (5.15)

Donde cada Si será una subclase de la partición dinámica (o subclase dinámica)de la clase P . Con este tipo de partición puede haber instantes del sistema t1 y t2con t1 6= t2 tales que se cumple lo siguiente:


extt1(Si) \ extt2(Sj) 6= ;; i 6= j;8i; j = 1; :::; n (5.16)

Y por lo tanto se tiene que:

9t; extt(Si) = extt(P ); 8i = 1; :::; n (5.17)

Las fórmulas 5.14 y 5.15 son idénticas a las que satisfacen las particiones estáticaspero particularizadas a instantes dados. La fórmula 5.16 implica que se pueden solaparen distintos instantes los conjuntos de existencia de las subclases, es decir, que puedenexistir al menos dos instantes distintos tal que al cambiar del uno al otro, al menosun objeto “migra” de una subclase a otra. La fórmula 5.17 es consecuencia de que,en principio, en un instante dado potencialmente cualquier objeto, puede llegar aestar en cualquiera de las subclases de la partición. Este no sería el caso del ejemploanterior de la partición estática de la clase vehículo, en el que una instancia de laclase camión no puede pasar a serlo de la clase coche o viceversa.La fórmula 5.17 es consecuencia del principio por el cual la identidad de un objeto

es independiente de su estado. Para observar este principio se notará que fS1; :::; Sngparticiona exhaustivamente en subespacios disjuntos el espacio de estados de cualquierinstancia. Así pues, se asumirá que en una partición dinámica existe al menos unobjeto que se puede mover por cada uno de dichos subespacios, para el cual existeal menos un instante dado en el cual es instancia de Si 8i = 1; :::; n. Si no existeuna instancia de P que pueda ser en algún momento instancia de una subclase Si8i = 1; :::; n entonces se debería eliminar la clase Si de la partición. Así pues seexigirá a la partición dinámica que siempre deberá existir una instancia de P quepueda moverse por cada subespacio. Como no se realiza ninguna asunción sobre laidentidad de esta instancia y como no existe ninguna relación entre la identidad delobjeto y su estado, todas las instancias de P pueden moverse por las subclases segúnse ha comentado. Esto signi…ca que 9t; extt(Si) = extt(P ); 8i = 1; :::; n.Para proporcionar un ejemplo se puede observar que cualquier instancia de Persona

puede moverse a la subclase dinámica Estudiante, entonces, en principio, todas lasinstancias de Persona pueden moverse a esta subclase (incluso aunque esto no se dépara muchas personas).Las particiones dinámicas proporcionan una solución a problemas que modelan

clases cuyas instancias pueden pasar por determinados estados lógicos. En estassituaciones es útil reducir el número de estructuras de control necesarias para modelarel comportamiento de los objetos de dichas clases (representados en muchos casoscomo “variables de estado”).En este modelo no se permitirá particionar una subclase dinámica en particiones

estáticas. Mediante esta restricción se obtienen modelos más sencillos sin reducir elpoder expresivo. En la …gura 5.7 se puede observar un ejemplo que sirve para justi…careste tipo de restricción. La …gura presenta una partición dinámica de Empleado (enlas subclases Vendedor y Responsable), y la subclase Vendedor se especializa de formaestática en Vendedor de Deportes y de Bisutería.Según la fórmula 5.14 aplicada al ejemplo de la …gura 5.7 ext(V endedor) =

ext(Deportes)[ext(Bisuter¶{a), y aplicando la fórmula 5.17, ext(V endedor) = ext(Em-


Empleado

Vendedor Responsable

Deportes Bisutería

<<dinámica>>

Figura 5.7: Ejemplo de partición estática de…nida sobre subclase dinámica

pleado) (potencialmente en algún momento todas las instancias de Empleado pue-den ser instancias de V endedor) se deduce que ext(Empleado) = ext(Deportes) [ext(Bisuter¶{a), lo que implica que, potencialmente, cada instancia de Empleado esuna instancia de Deportes o de Bisuter¶{a, pero según la taxonomía presentada en la…gura 5.7 una instancia de Deportes o de Bisuter¶{a no será nunca una instancia deResponsable, porqueDeportes yBisuter¶{a son subclases estáticas que una vez creadaspermanecen en dicha subclase hasta su destrucción, lo que según el modelo imposi-bilita la migración. De esto se deduce que las instancias potenciales de Empleadono podrán migrar a la subclase dinámica Responsable. Esto signi…ca que Responsablepodría no tener ninguna instancia, lo que viola la condición 5.17. Así pues, no se per-mitirán este tipo de estructuras taxonómicas. Por tanto se puede concluir que si sedesciende en una estructura taxonómica, una vez encontrada una partición dinámicaya no se podrá encontrar una partición estática.

Migración de Objetos

En una partición dinámica las instancias pueden “migrar” (en el sentido de una evolu-ción horizontal según el marco propuesto) desde una subclase a otra. A esta caracte-rística también se le llama subclasi…cación dinámica [75, 238]. Por ello la intersecciónpresentada en 5.16 puede ser distinta al conjunto vacío. En esta aproximación, lamigración de un objeto a una subclase se modelará como que un objeto cambia desubclase en una partición dinámica de una clase determinada. La migración de unobjeto entre las subclases de la partición se podrá producir a través de la ocurrenciade eventos (especi…cado mediante un proceso de migración como se verá más adelan-te) o el cumplimiento de una condición sobre el valor de un atributo variable. Unhecho importante es que un objeto nunca cambia su oid al migrar a una subclase. Aeste fenómeno se le llama herencia por identidad.Una diferencia importante entre las particiones dinámicas y las estáticas es que en

las dinámicas la población de alguna subclase puede cambiar sin que cambie en la su-


Estropeado

Activo

ext(Vehículo)

ext(Coche)

ext(Camión)

ext(Otros)

(a) (b)

Estropeado

Activo

Estropeado

Activo

ext(Vehículo)

ext(Coche)

ext(Camión)

ext(Otros)ext(Coche)

ext(Camión)

ext(Otros)

(a) (b)

Figura 5.8: Subespacios Disjuntos vs. Extensiones Disjuntas

perclase. En cambio, si la población cambia en una subclase estática entonces cambiatambién en el de la superclase (por ejemplo, como consecuencia de eliminar/destruirun objeto). Así, en el ejemplo de la partición estática de vehículo la creación deuna instancia de coche es también la creación de una instancia de vehículo. Estacaracterística de…ne el criterio del cambio independiente del conjunto de exis-tencia presentado en el capítulo 4 que permite distinguir claramente entre subclasesestáticas y dinámicas.

Dualidad entre Particiones Estáticas y Dinámicas

Existe una dualidad interesante entre las particiones estáticas y las dinámicas:

² Una partición dinámica divide el espacio de estados de las instancias de lasuperclase exhaustivamente en subespacios disjuntos.

² Una partición estática divide la extensión de su superclase exhaustivamente ensubclases de extensiones disjuntas.

Esta dualidad permitirá identi…car a nivel de modelado los distintos tipos de par-ticiones dependiendo de las características que deban cumplir las instancias de lassubclases en cuanto a la distribución de su población y de sus propiedades.Para comprobar esta dualidad, supongamos que la clase Vehículo se particiona en

una partición estática cuyas subclases son coche, camión y otros, y en una particióndinámica cuyas subclases son estropeado y activo. Si se observa la …gura 5.8 a)se puede ver que, el espacio de estados de la clase vehículo está dividido en dossubespacios disjuntos, el de los vehículos activos y el de los estropeados. En la …gura5.8 b) se puede observar que la extensión de vehículo se divide en tres subextensionesdisjuntas: las extensiones de los coches, camiones y otros.


Las subclases de una partición dinámica fS1; :::; Sng representan las distintas subcla-ses de las que puede formar parte, durante su existencia, un objeto perteneciente ala clase particionada (P ). La especialización de dichas subclases vendrá determinadapor eventos de migración de…nidos en un proceso de migración o por condiciones de


migración de…nidas sobre atributos variables de la superclase. En ambos casos lasuperclase P tendrá su(s) evento(s) constructor(es) (EvnewP 2 P ) y destructor(es)(EvdestroyP 2 P ), y cuando el objeto es destruido en la subclase (no existiendo mi-gración) también es destruido en la superclase y viceversa. A continuación se analizacómo se presentan estos dos casos en el modelo:

1. Migración mediante eventos

(a) En las subclases de la partición 9 Si 2 fS1; :::; Sng; Si es la clase inicialde la partición a la que se llamará Sinicial. El evento constructor EvnewPde P será el evento inicial en la especi…cación del proceso de migración.Este evento creará un objeto perteneciente a la subclase Sinicial de la par-tición dinámica (será un constructor especial de Sinicial) e inicializará susatributos (los heredados de P y los suyos propios).

(b) Las subclases de la partición dinámica poseerán eventos (Evmig) que cau-sarán la migración entre dos subclases de la partición. Estos eventos sellamarán eventos de migración que ejecutarán los papeles portador y libe-rador. A nivel de especi…cación estos eventos se declararán en la subclaseorigen de la migración Sorigen. La migración se producirá debido a la ac-tivación de dichos eventos. Los eventos Evmig cambiarán el estado delobjeto activo a través de sus evaluaciones asociadas y liberarán (actuandocomo destructores especiales9) la parte del estado del objeto que pertenecea la subclase activa en la partición. Estos eventos actuarán a su vez comoportadores (o constructores especiales) que llevarán el objeto a la subclasedestino en el proceso de migración, creando la parte del estado del objeto(inicializando sus atributos) que pertenece a la nueva subclase activa.

2. Migración mediante condiciones sobre atributos variables :

(a) En este caso el proceso migratorio está de…nido en función del estado delobjeto. La restricción implícita en el modelo presentado es que la particiónque se haga del conjunto de estados del objeto a partir de las condicionesde especialización de…nidas sobre los valores de los atributos, debe ser com-pleta y disjunta. Con la intención de conseguir un modelo homogéneo lamigración basada en condiciones sobre atributos variables puede conside-rarse como un caso especial de la migración por evento. De esta formase tendrán eventos de creación y eventos portadores/liberadores, que seránaquellos eventos que modi…can el estado del objeto, afectando a los atri-butos variables que de…nen las condiciones de migración. Estos eventossólo actuarán como creadores o portadores/liberadores cuando se cumplala condición de migración de…nida en la especi…cación.


La sintaxis que se utiliza para especi…car una partición dinámica en OASIS es lasiguiente:

9 Son especiales porque su funcionalidad es parecida a la de los destructores pero en realidad nocrean ni destruyen un objeto nuevo, sólo se encargan de llevar a cabo el proceso de migración.


————————————————————————————< def_particion_dinamica> ::= <def_dinamica_migracion>

j <def_dinamica_atributo>————————————————————————————Como se ha comentado anteriormente la migración de un objeto entre las subclases

de la partición se puede producir a través de:

² la ocurrencia de eventos (especi…cado en OASIS mediante un proceso de mi-gración que seguirá la sintaxis de…nida por <def_dinamica_migracion>)

² el valor de un atributo (especi…cado en OASIS mediante condiciones sobre elvalor de un atributo variable que seguirán la sintaxis de…nida por<def_dinamica-_atributo>).

Partición Dinámica Basada en la Ocurrencia de Eventos. En este caso elproceso de migración se de…ne mediante una especi…cación de proceso que utilizala misma sintaxis que los procesos de OASIS. El poder expresar dicho procesode migración aporta al lenguaje una riqueza expresiva considerable. Los eventosimplicados en la especi…cación del proceso pertenecerán a alguna de las subclases dela partición que se abandona y desde donde se migra a una subclase destino. Lasvariables de tipo proceso utilizadas para especi…car el proceso se corresponden conlos nombres de las subclases de la partición. Por defecto, el evento constructor de lasinstancias es el evento especi…cado al comienzo del proceso de migración.La sintaxis en forma BNF que se utiliza para especi…car el proceso de migración

en una partición dinámica en OASIS es la siguiente:———————————————————————————< def_dinamica_migracion > ::= <lista_id_subclase>

dynamic specialization of<id_superclase>

migration relation is<expresion_migracion>

< expresion_migracion > ::= < sec_def_estado >———————————————————————————

donde:

² <lista_id_subclase> son subclases de la misma partición dinámica de la clase<id_superclase> y <expresion_migracion> expresa las restricciones asociadasal proceso de migración entre las subclases de la partición dinámica.

² <expresion_migracion> se de…ne utilizando la misma sintaxis usada al espe-ci…car un proceso. Sin embargo, en este caso, los identi…cadores de estado<def_estado> (variables del tipo proceso) se corresponden con nombres de sub-clases de la partición. El evento de creación de instancias debe estar incluido enla de…nición de la superclase y será el evento inicial de la expresión de migración.

Como ejemplo de especi…cación de una partición dinámica basada en la ocurrenciade eventos se puede ver:


Ejemplo 10 Una partición dinámica de la clase vehiculo determinada por la ocu-rrencia de los eventos crear, reparar y estropear puede ser:

activo, estropeadodynamic specialization of vehiculomigration relation isvehiculo = crear.activo;activo = estropear.estropeado;estropeado = reparar.activo;

Según lo dicho, la creación de una instancia de vehiculomediante el evento crearimplica comenzar perteneciendo a la subclase activo. Cuando sea una instancia deactivo le ocurrirán eventos de la signatura de vehiculo y además, posiblemente,otros eventos de la subclase activo. Entre ellos está el evento estropear que perte-nece a la signatura de activo. Su ocurrencia implica migrar desde la subclase activohacia la subclase estropeado. Desde un punto de vista teórico, el proceso que repre-senta la vida de una instancia de la clase Vehiculo es la composición de los distintossubprocesos de las subclases y los puntos de enlace entre ellos vienen dados por loseventos especi…cados en el proceso migratorio. Otro ejemplo típico de este tipo departición dinámica es el siguiente:

Ejemplo 11 Una partición dinámica de la clase persona basada en su estado civilcomo criterio de especialización puede ser: soltero, casado, divorciado, viudo

dynamic specialization of personamigration relation is

persona = nacer.soltero;soltero = casarse.casado;casado = divorciarse.divorciado + enviudar.viudo;viudo = casarse.casado;divorciado = casarse.casado;

Tal como ocurría en el ejemplo anterior, los eventos incluidos en la especi…cacióndel proceso de migración no pertenecen a la clase persona. El evento nacer está en lasignatura de persona, el evento casarse en la de soltero, divorciado y viudo,el evento divorciarse sólo pertenece a casado, y así sucesivamente.

Partición Dinámica Basada en el Estado. En este caso el proceso de migraciónse de…ne en función del estado de cada objeto. Cada vez que el objeto alcanza unestado determinado, puede migrar de una subclase a otra en la partición.La sintaxis OASIS que se utiliza para especi…car la migración basada en atributos

variables es la siguiente:——————————————————————————< def_dinamica_atributo> ::= <lista_def_subclase_dinamica>

dynamic specialization of<id_superclase>

<def_subclase_dinamica> ::= <id_subclase>where ‘{’<fórmula>’}’

——————————————————————————donde:


² <id_subclase> son subclases de la misma partición dinámica de la clase <id_su-perclase> y cada subclase va acompañada de una fórmula de…nida sobre losatributos variables de la superclase. La modi…cación del estado del objeto de-termina el proceso de migración entre las subclases de la partición dinámica.

En el modelo presentado, una partición siempre está constituida por un conjuntodisjunto y completo de clases especializadas, por lo que en las particiones dinámicasbasadas en valores de atributos se debe garantizar que estas propiedades se cumplansiempre. Para conseguirlo se exigirá que: (1) el rango de valores que puede tomar elatributo en cada condición de especialización asociada a una determinada subclasesea disjunto con respecto a los valores de las demás condiciones, (2) las condiciones deespecialización cubran el rango de todos los posibles valores del atributo que participaen la condición.Como ejemplos de especi…cación de una partición dinámica de…nida mediante

atributos vaiables se pueden ver:

Ejemplo 12 Una partición dinámica de la clase cuenta en función del atributosaldo puede ser:

no_rentable where {saldo<100000},rentable where

{saldo>=100000 and saldo<1000000},muy_rentable where {saldo>=1000000}

dynamic specialization of cuenta;

En el ejemplo, la subclase de la partición dinámica a la cual pertenece un objetode la clase cuenta se determina implícitamente a partir del valor del atributo saldo.

Ejemplo 13 Una partición dinámica de la clase Persona en función del atributoedad puede verse a continuación:

niño where {edad<14},adolescente where {14<=edad and edad<18},adulto where {18>=edad}

dynamic specialization of persona;

Dicha jerarquía tiene como atributo relevante la edad de la persona cuyo valor secalcula como diferencia entre la fecha_actual y la fecha_nacimiento de la persona.En este caso, independientemente de las acciones que lleven a la modi…cación delatributo edad, ha sido necesario poder representar la migración en función de dichoatributo y no de eventos que le acontezcan.


Para representar las particiones dinámicas se utilizará la notación propuesta paralas particiones, asociando además un estereotipo <<dinámica>>.a la ‡echa de cadapartición (ver …guras 5.9, 5.11 y 5.13).En una partición dinámica las transiciones (o migración) entre subclases pueden

ser causadas por la ocurrencia de eventos o por el cambio de valor de atributos varia-bles. La notación que se propone para modelar las restricciones de migración en unapartición dinámica es la siguiente:


Figura 5.9: Partición Dinámica de Vehículo

² En el caso de la ocurrencia de eventos: Por cada partición dinámica, seespeci…cará en el modelo dinámico un diagrama de transición de estados espe-cial llamado diagrama de migración. Este diagrama modelará el proceso demigración, y en él se especi…cará cualquier restricción que se quiera imponerrespecto a las transiciones permitidas entre subclases de una misma particióndinámica. Los eventos etiquetarán las transiciones entre los estados del dia-grama de migración. Cada uno de los estados del diagrama de migración secorresponderá con una de las subclases de la partición. En las …guras 5.10 y5.12 se pueden ver los diagramas de migración de las particiones dinámicas quese muestran en las Figuras 5.9 y 5.11.

² En el caso de migración por el valor de atributos variables: Se puedenasociar restricciones de migración a cada una de las subclases de la partición enel diagrama de clases mediante un estereotipo que incluya una condición sobreun atributo variable (<< condicion_especialización >>). Un objeto migraráa una subclase en la partición cuando se cumpla la restricción asociada a lasubclase destino (ver Figura 5.13).

En las …guras 5.9, 5.3 y 5.13 se pueden ver ejemplos de particiones dinámicaspara la clase Vehículo y Empleado respectivamente. En la …gura 5.9 se representaque cualquier vehículo debe estar obligatoriamente activo o estropeado. Según eldiagrama de migración de la …gura 5.10, el Vehículo cuando se crea está activo yestando activo si se estropea pasa a estar estropeado, de estropeado puede pasar aactivo si lo reparan. Según la especi…cación sólo se pueden estropear coches activosy sólo se reparan coches estropeados.En las …guras 5.11 y 5.13 se pueden ver dos diagramas de clases (siguiendo la

notación propuesta) que modelan una partición dinámica de la clase Empleado. Am-bos ejemplos están modelando que cualquier Empleado puede ser un Vendedor o unResponsable. En la …gura 5.11 cuando se crea un Empleado éste empieza perte-neciendo a la subclase Vendedor. El evento promocionar implica dejar la subclaseVendedor y migrar hacia la subclase Responsable. Un Gerente puede ser rebajado;este evento produce la migración del objeto hacia la subclase Vendedor. Esta semán-tica se especi…ca en el DTE de la …gura 5.12. Este DTE representa el diagrama demigración de la partición dinámica de la …gura 5.11.En el diagrama de clases de la …gura 5.13 se de…nen las restricciones de migración


Activo Estropeadocrear

estropear

reparar

Figura 5.10: Diagrama de Migración de la Partición Dinámica de la Figura 5.9

<<dinámica>>pue sto

VendedornVentas

vender()promocionar()

Empleadocod_empleadoseccionpuestosalariosueldo_basetele fonofecha_contratacionfecha_revision_sueldobonificacion

cambiar_seccion()cambiar_puesto()incrementar_salario()subir_sue ldo()pagar()despedir()contratar()iniciar_mes()faltar_al_trabajo()

ResponsablenVendedores

asignar_vendedores()quitar_vended ores()reba ja r()

Figura 5.11: Partición Dinámica de la Clase Empleado

Vendedor

Responsable

contratar promocionar

rebajar

Figura 5.12: Diagrama de Migración de la partición dinámica de la …gura 5.11

5.5. Roles 137

Emp le ad ocod_empleadoseccionpuestosalariosueldo_basetelefonofecha_contratacionfecha_revision_sueldobonificacionbajas

cambiar_seccion()cambiar_puesto()bonificar()subir_sueldo()pagar()despedir()contratar()iniciar_mes()faltar_al_trabajo()

p ue sto

Vendedorn Venta s

vende r()

<<puesto="vendedor">>

Resp onsab lenVendedores

asignar_vendedores()quitar_vendedores()

<<pue sto=re sp on sab le ">>

Figura 5.13: Partición Dinámica de…nida sobre el atributo puesto.

utilizando la notación basada en atributos variables. En dicho modelo, cuando se creaun Empleado éste pertenecerá a la subclase Vendedor o Responsable dependiendodel puesto de trabajo asignado. Si su puesto cambia por la ocurrencia del eventocambiar_puesto entonces podrá migrar de una subclase a otra dependiendo del nuevopuesto que se le asigne.

5.5 Roles

El uso de roles asociados a los objetos permite la representación de comportamientosdiferentes de un objeto y la evolución dinámica de dicha conducta. Un rol puedeconsiderarse como una vista de un determinado objeto jugando dicho rol [20, 22].

De…nición 4 Un rol es un como un objeto excepto que tiene una relación especialcon otro objeto (o rol10) que es el que desempeña el rol. Al objeto que desempeña elrol se le denomina jugador. Una subclase de rol es aquella cuyas instancias son roles.

En esta aproximación se considera la función jugado_por, tal que si R es unasubclase de rol, entonces existe una superclase P tal que en cada instante t se cumpleque:

jugado_por : extt(R)! extt(P )

10 Se permiten roles de roles.


Así, P representa la clase de los objetos (jugadores) que desempeñan el rol. En-tonces, 8r 2 extt(R), jugado_por(r) es el objeto de la clase P que desempeña el rolpara r. Además 8r 2 extt(R) siempre se cumple lo siguiente:² Existe exactamente un objeto o rol jugado_por(r) asociado a cada rol r.² La existencia de r está supeditada a la existencia de jugado_por(r). Por lo quecuando el objeto jugado_por(r) es destruido, r se destruye en la subclase derol. Sin embargo, el jugador puede seguir existiendo cuando un rol asociado esdestruido ya que la destrucción del objeto que representa el rol no implica ladestrucción del objeto jugador.

² Pueden existir varios roles activos para un mismo jugador. Estos roles puedenser instancias de distintas subclases de rol e incluso serlo de la misma clase derol. Por ello, a cada subclase de rol se le podrá asignar una multiplicidad, deforma que se limite el número de roles de una determinada subclase de rol quepuede asumir el jugador a la vez. La ausencia de multiplicidad indica que eljugador puede asumir de 0 a 1 roles.

² Se pueden de…nir particiones estáticas y dinámicas o nuevos grupos de rol apartir de una subclase de rol.

De…nición 5 Un grupo de rol representa un conjunto de roles mutuamente exclusi-vos. Si R1; :::;Rn son roles de una clase P; entonces fR1; :::; Rng es un grupo de rolde P si para cada instante t se cumple que:

extt(Ri) \ extt(Rj) = ;; 8i 6= j;8i; j = 1; :::; n (5.18)

Es decir, dentro de cada grupo de rol un jugador puede desempeñar de formasimultánea como máximo roles de una de sus subclases de rol. En general, cadaclase (incluyendo las subclases de rol) puede especializarse siguiendo un determinadocriterio en uno o más grupos de rol.A diferencia de las particiones pueden existir instancias de la clase jugadora (la

superclase) que no desempeñen ningún rol en un grupo de rol.

extt(P ) ¸ [extt(Ri); 8i = 1; :::; n (5.19)

De esta forma el grupo de rol no será exhaustivo o completo. Esto permite que ungrupo de rol pueda tener un solo rol. Este relajamiento en la restricción de completitudse explica por la naturaleza de los roles, en la que un objeto jugador no necesita entodo momento estar instanciado en alguna subclase de rol.Los grupos de roles al igual que las particiones dinámicas poseen la propiedad de

la dinamicidad, por lo que en los grupos de roles puede haber instantes del sistemat1 y t2 con t1 6= t2 tales que se cumpla lo siguiente:

extt1(Ri) \ extt2(Rj) 6= ;; 8i 6= j;8i; j = 1; :::; n (5.20)

5.5. Roles 139

Esta fórmula implica que se pueden solapar en distintos instantes los conjuntos deexistencia de las subclases de rol pertenecientes a la clase P , de forma que un objetopuede dejar de jugar un determinado rol y empezar a jugar otro rol de una subclasede rol distinta.


En la relación entre el rol y el jugador no se exigirá compatibilidad de comportamientoentre ambos, y además se permitirá la existencia de múltiples roles para un mismojugador, aunque se requerirá al menos compatibilidad de signatura. La compatibili-dad de signatura no distingue entre comportamientos distintos con la misma interfazsintáctica, por lo que externamente la interfaz del objeto hijo se debe mantener iguala la del objeto padre asociado.Los mecanismos de herencia estándar no son adecuados para simular la relación de

rol presentada debido a la multiplicidad de los roles. El problema surge porque cuandoexisten dos o más roles de un mismo objeto, el mecanismo de herencia estándar no sepuede aplicar para que los roles compartan las propiedades del objeto jugador. Unasolución es utilizar la delegación [216]. La herencia por delegación es un conceptoútil para expresar la compartición de propiedades entre determinados objetos. Estemecanismo es adecuado para dar soporte a la relación entre el rol y el objeto jugador,permitiendo de…nir delegación de roles a jugadores. Por ejemplo, si se modela unempleado e como un rol de persona p, y la edad es un atributo de las personas“heredándolo” los empleados, entonces cuando se acceda a la edad de un empleado e sedelegará en el jugador para acceder a dicho atributo (e:edad = jugado_por(e):edad =p:edad). La delegación también se de…ne para los eventos.Dado un grupo de rol fR1; :::; Rng de la clase P (siendo P la clase jugadora de

los roles), se exigirá que en la especi…cación de una subclase de rol Ri 8i = 1; :::; n secumplan las siguientes condiciones:

² La subclase de rol podrá introducir un conjunto de atributos nuevos (AtrNRi).Además, se podrán de…nir atributos con el mismo nombre que los atributos he-redados (respetando la compatibilidad de signatura). Por ejemplo, una Personapuede tener un atributo número de teléfono, y éste puede ser un nuevo atribu-to del rol Empleado. Cuando el objeto juegue el rol de empleado, el signi…cadodel atributo número de teléfono será el número de teléfono del trabajo. Asílos atributos del rol serán AtrRi = (AtrP (atributos de P )¡(AtrP \AtrNRi))[AtrNRi , es decir la unión de aquellos atributos de P que no han sido de…nidoscon el mismo nombre en Ri (se heredan mediante delegación) y los atributosnuevos de Ri.

² Las subclases de rol deben poseer identi…cadores propios para distinguir losroles unos de otros, aún cuando diversos roles sean desempeñados por el mismoobjeto. Cuando la multiplicidad del rol respecto al jugador sea mayor que uno, lasubclase de rol deberá de…nir de forma obligatoria mecanismos de identi…caciónadicionales a los heredados. En el caso de que la multiplicidad sea 0 ó 1, podráncompartir identi…cadores.

² La subclase de rol Ri podrá introducir un conjunto de eventos nuevos (EvNRi).


Cada subclase tendrá sus eventos propios más los que hereda de la superclase.Los eventos de la subclase de rol serán EvRi = EvP (eventos de P ) [ EvNRi :

² En la clase jugadora P existirá al menos un evento EvnewRi 2 EvP que de-terminará el comienzo del desempeño del rol (es decir representará el eventoconstructor de Ri). El evento EvnewRi podrá tener sus propias evaluaciones yprecondiciones en P y en Ri. La ejecución correcta de EvnewRi deberá garan-tizar:

– que la multiplicidad existente entre el jugador y su subclase de rol permitala creación del rol, y

– que no exista un rol creado en otra subclase del mismo grupo de rol.

Cuando ocurra EvnewRi sobre un objeto de la subclase de rol Ri se ejecutaránsus evaluaciones y delegará su ejecución en el jugador. De esta forma siem-pre será el jugador el que activa el rol y el que comprueba las precondicionesimplícitas en P .

² En la subclase de rol Ri podrán existir, opcionalmente, uno o más eventos dedestrucción del rol EvdestroyRi =2 EvP que no pertenezcan a P: Se encargaránde …nalizar el desempeño del rol sin destruir el objeto jugador.

² Las fórmulas de evaluación de…nidas en Ri (a las que se llamará EvalNRi ,por ser evaluaciones nuevas de Ri) se podrán especi…car para eventos nuevos(EvNRi) y heredados (EvP ) de Ri.

– los eventos nuevos podrán modi…car cualquier atributo heredado (AtrP )o nuevo (AtrNRi) de la subclase de rol Ri:A este tipo de evaluaciones seles llamará EvalEvNRi por ser evaluaciones especi…cadas sobre eventosnuevos de Ri:

– los eventos heredados podrán modi…car cualquier atributo heredado (AtrP )o nuevo (AtrNRi) de la subclase de rol Ri: A este tipo de evaluacionesse les llamará EvalEvP por ser evaluaciones especi…cadas sobre eventosheredados de P:

¤ La modi…cación de atributos heredados se podrá llevar a cabo sinnecesidad de respetar el espacio de estados al no exigir compatibi-lidad de comportamiento. A este tipo de evaluaciones se les llamaráEvalRedefEvP por modi…car atributos heredados rede…niendo su eva-luación.

Así pues, las evaluaciones deRi seránEvalRi = (EvalP ¡EvalRedefEvP )[EvalNuevasEvP[EvalRedefEvP , siendo (EvalP ¡EvalRedefEvP ) aque-llas evaluaciones de P que no han sido rede…nidas en Ri:

² Las precondiciones que se de…nan para los eventos de Ri (PrecRi) podrán ser:

– precondiciones de…nidas sobre eventos nuevos (a las que se les llamaráPrecERiEvERi).

5.5. Roles 141

– precondiciones de…nidas sobre eventos heredados (a las que se les llamaráPrecERiEvP ). Éstas a su vez podrán ser:

¤ precondiciones nuevas (a las que se les llamará PrecNuevasERiEvP ):son precondiciones de…nidas sobre eventos heredados que no teníanninguna precondición asociada en la clase jugadora P .

¤ precondiciones rede…nidas (a las que se les llamará PrecRedefRiEvP ):son rede…niciones de precondiciones existentes en la clase jugadora P .Al no exigir compatibilidad de comportamiento no será necesario queestas precondiciones impliquen lógicamente a las existentes en P . Estasprecondiciones sobrescriben las de la clase jugadora.

Así pues, el conjunto de precondiciones de Ri será PrecRi = (PrecP (precondi-ciones de P )¡ PrecRedefRiEvP )[PrecERiEvERi [PrecNuevasERiEvP [PrecRedefRiEvP , signi…cando la ex-presión (PrecP ¡PrecRedefERiEvP ) aquellas precondiciones de P que no hansido rede…nidas en Ri.

² Las restricciones de integridad cumplirán las mismas propiedades que las pre-condiciones. Se podrán especi…car para atributos heredados y nuevos. Lasrestricciones de integridad que se de…nan en Ri (a las que se llamará RestERi)podrán ser:

– restricciones nuevas (a las que se les llamará RestNuevasERi): son nuevasrestricciones de…nidas sobre atributos nuevos (AtrERi) y atributos here-dados (AtrP ) sobre los cuales no se había de…nido ninguna restricción deintegridad en P .

– restricciones rede…nidas (a las que se les llamará RestRedefERi): sonrede…niciones de restricciones existentes en la clase jugadora P (llamadasRestP ). Al no exigir compatibilidad de comportamiento no será necesarioque impliquen lógicamente a las restricciones existentes en P .

Así pues, el conjunto de restricciones de Ri será RestRi = (RestP ¡RestRedefERi) [RestNuevasERi [ RestRedefERi , signi…cando que las restricciones deintegridad de Ri serán la unión de aquellas restricciones de P que no hansido rede…nidas en Ri (RestP ¡ RestRedefERi), de las restricciones nuevas(RestNuevasERi) y de las restricciones rede…nidas (RestRedefERi) sobrescri-biéndo las de P .

² Los disparos que se de…nan en Ri (a los que se les llamará DispRi) podránactivar eventos nuevos o heredados de P , además de eventos de otras clases delsistema. Los disparos que se especi…quen en Ri podrán ser:

– disparos nuevos (a los que se les llamará DispNuevosRi): son aquellosde…nidos sobre eventos nuevos de Ri (EvERi), sobre eventos heredados deP (EvP ) o de otras clases del sistema (EvC ; siendo C cualquier clase delsistema tal que C 6= P y C 6= Ri;8Ri 2 fR1; :::;Rng) sobre los cuales no sehaya de…nido un disparo en la clase jugadora. En este caso las condicionesde disparo se podrán de…nir (sin ningún tipo de restricción) sobre atributosnuevos (AtrERi) y heredados (AtrP ).


– disparos rede…nidos (a los que se les llamará DispRedefRi): son aquellosde…nidos sobre eventos heredados de P (EvP ) o de otras clases del sistema(EvC) que participen como evento a activar en disparos de…nidos en P(DispP ). En este caso el nuevo disparo rede…nirá el disparo heredadosobrescribiéndolo. En los roles no es necesario garantizar la compatibilidadde comportamiento por lo que no se restringirá el tipo de rede…nición.

Así el conjunto de disparos de Ri será DispRi = (DispP ¡ DispRedefRi ) [DispNuevosRi [ DispRedefRi , es decir, la unión de aquellos disparos de Pque no han sido rede…nidos en Ri con los disparos nuevos especi…cados en Ri ylos disparos de P que han sido rede…nidos en Ri sobrescribiendo los de P .

² Al no exigir compatibilidad de comportamiento, el proceso que representa lavida de una instancia de la subclase de rol se de…nirá de forma independienteal proceso de la clase jugadora P . Las únicas restricciones sobre dicho procesoserán que el primer y el último evento del proceso serán los eventos de creaciónEvnewRi y de destrucción EvdestroyRi del rol. La secuencia en la cual los rolespueden adquirirse y abandonarse puede de…nirse en el proceso que de…ne la vidadel objeto jugador.

² Por último, en línea con lo expuesto, las subclases de rol heredan tanto laspropiedades de la superclase como los roles que ésta puede desempeñar.

Es importante destacar que si el analista detecta en el espacio del problema laexistencia de compatibilidad de comportamiento entre los roles y la clase jugadora,esta situación se considerará un caso particular de lo expuesto para los roles.

Expresividad de los Roles

La aproximación presentada incorpora las características esenciales que la mayoría delas propuestas existentes sobre roles introducen a nivel de modelado e implementación.Aunque no permite modelar las siguientes características:

² Objetos de clases que no están relacionadas por herencia pueden jugar el mismorol [17, 215]. Esta característica no la reconocen la mayoría de autores.

² Un rol puede ser transferido de un objeto jugador a otro [121, 242]. La idea de latransferencia de objetos puede verse como una especie de clasi…cación dinámicaen la que el objeto de la subclase permanece …jo y el objeto de su superclasepuede cambiar. Puede ser útil en situaciones en las que un rol abandonadopor un objeto pueda ser adquirido por otro. Además, se pueden especi…car laspropiedades de una subclase (o rol) en concreto, sin necesidad de conocer lascaracterísticas del objeto jugador o propietario del rol.

² Los roles pueden restringir el acceso a propiedades [81, 121, 181, 242]. Los rolespueden hacer algunas propiedades del jugador invisibles. El modelo presentadono ofrece esta posibilidad porque violaría la compatibilidad de signatura.

Las dos primeras características no se pueden especi…car en sistemas basados enclases. En general, estas aproximaciones son poco relevantes desde el punto de vistasemántico, lo que ha hecho que la mayoría de aproximaciones de modelado conceptualOO no las soporten.

5.5. Roles 143


La sintaxis que se utiliza para especi…car los grupos de roles en OASIS es la siguiente:———————————————————————————————–<def_roles> ::= <lista_def_rol> role of <id_clase_jugadora><def_rol> ::= <id_clase_rol>

[towards ‘(’<card_min>’,’<card_max>’)’]<id_evento_creacion_rol>’,’[<id_evento_terminacion_rol>]

———————————————————————————————–donde:

² <id_clase_rol> son clases del grupo de rol cuya superclase está especi…cadapor <id_clase_jugadora>.

² Con <card_min> y <card_max> se indica cuántos roles como mínimo y comomáximo puede desempeñar una instancia de la clase <id_clase_jugadora>. Sino se especi…ca towards se asume towards(0,1).

² El evento <id_evento_creacion_rol>, que pertenece a <id_clase_jugadora>determina el comienzo del desempeño del rol (es decir representa el new endicha clase de rol).

² El evento <id_evento_terminacion_rol>, que pertenece a <id_clase_rol> de-termina la …nalización del desempeño del rol (es decir representa el destroy endicha clase de rol).

Como ejemplo de especi…cación de un grupo de rol se puede ver:

Ejemplo 14 Un ejemplo de un grupo de rol de…nido sobre la clase persona.

estudiante towards(0,3) matricular, terminarempleado towards(0,1) contratar, despedir

role of persona;

Con la multiplicidad se representa que una instancia de la clase persona puededesempeñar, simultáneamente, como máximo un rol de empleado o, alternativamente,como máximo tres roles de estudiante. También es posible que una instancia depersona no desempeñe ningún rol (ni de estudiante, ni de empleado).El evento de creación es enviado a la clase persona. Posteriormente, si ocurre el

evento matricular (que representa el activador del rol de estudiante), entonces lapersona pasa a desempeñar el rol de estudiante. Si se destruye el objeto de persona,automáticamente se destruye el objeto estudiante, sin embargo si se destruye unobjeto estudiante con el evento terminar, no tiene por qué destruirse el objetopersona que juega dicho rol.Si se desea que una persona desempeñe el rol de empleado y de estudiante de

forma simultánea se separará la de…nición de cada grupo de rol de la siguiente manera:

estudiante towards(0,3) matricular, terminar role of persona;empleado towards(0,1) contratar, despedir role of persona;


Persona

Estud iante Empleado

<<contratar/despedir>><<matricular/terminar>>

<<jugado_por>>

<<0,3>>

Figura 5.14: Grupo de Rol de la clase Persona constituido por los roles Estudiante yEmpleado


La notación propuesta para representar los grupos de roles es parecida a la presentadapara las particiones. En los grupos de roles se pueden utilizar de forma opcional dis-criminadores para modelar el criterio de especialización asociado al grupo de rol. Unestereotipo << jugado_por>> se asociará a la ‡echa que de…ne la relación de sub-clasi…cación. Este estereotipo permitirá distinguir el grupo de rol de las particiones.Asociado a la línea que une una subclase de rol con la ‡echa que apunta a la clasejugadora se incluirá el estereotipo << evento de activación / evento de terminación>>que representará a los eventos activador y terminador del rol respectivamente. Esteestereotipo especi…cará mediante dos eventos de qué forma se toma y se deja el rol.Es muy importante resaltar que los eventos de activación serán eventos de la clasejugadora (siendo a su vez eventos especiales de creación del rol) y los eventos de des-activación del rol serán eventos de la clase de rol. A cada subclase de rol se le podráasociar, de forma opcional, una multiplicidad mínima y máxima que se especi…caráen el modelo mediante el siguiente estereotipo << cardmin, cardmax>>. Si no seespeci…ca multiplicidad se asume << 0, 1>>.La notación grá…ca propuesta se ilustra mediante dos ejemplos que aparecen en

las …guras 5.14 y 5.15. De la …gura 5.14 se deduce la siguiente información: tan-to Estudiante como Empleado se han modelado como subclases de rol de la clasePersona. Además, ambas subclases pertenecen al mismo grupo de rol, esto signi…caque una persona no podrá jugar a la vez roles de Empleado y Estudiante porqueal pertenecer al mismo grupo de rol las subclases son mutuamente excluyentes. Unapersona puede jugar simultáneamente cero o un rol de Empleado (multiplicidad pordefecto) o, alternativamente, podrá jugar de cero a tres roles de Estudiante. UnaPersona juega el papel de Empleado cuando le contratan y deja de jugar dicho papelcuando le despiden. Una Persona juega el papel de Estudiante cuando se matriculay deja de jugarlo cuando termina los estudios. Un segundo ejemplo se presenta en eldiagrama de la …gura 5.15. De esta …gura se deduce la siguiente información: igualque en el anterior ejemplo, tanto Estudiante como Empleado se han modelado como

5.6. Distinción entre Particiones Dinámicas y Roles 145

Persona

Estudiante Empleado


<<jugado_por>>

<<0,3>>

<<jugado_por>>

Figura 5.15: Dos Grupos de Rol de la clase Persona constituido uno por el rol Estu-diante y el otro por el rol Empleado

clases de rol de Persona, sin embargo, en este caso, cada clase pertenece a un grupode rol distinto. Esto signi…ca que una persona podrá jugar a la vez roles de Empleadoy Estudiante.

5.6 Distinción entre Particiones Dinámicas y Roles

Las particiones dinámicas y los roles constituyen dos aproximaciones a la especializa-ción dinámica de clases. Estos dos conceptos poseen una serie de características quelos diferencian:

² La multiplicidad: Un objeto puede jugar varios roles (desde 0 hasta N) deuna misma subclase de rol. La de…nición de roles incluye la multiplicidad comoforma de representar que un objeto puede jugar más de un papel de la mismaclase. Un objeto sólo puede especializarse, en un momento dado, en una únicainstancia de una subclase de una partición dinámica.

² La identidad: Para poder dar soporte a la multiplicidad de roles es necesarioque los roles activos de un objeto puedan identi…carse inequívocamente respectoal objeto jugador. Esto implica proporcionar a los roles un identi…cador distintoal de la superclase jugadora. Así pues, si Ri 8i = 1; :::; n es una subclase de rolde P entonces una instancia de Ri no puede ser idéntica a cualquier instanciade P . Sin embargo si Ri es una subclase estática o dinámica de P entonces unainstancia de Ri es idéntica a una instancia de P .

– El problema del conteo: Al permitir que un objeto pueda jugar diversosroles de una misma clase de rol (multiplicidad) y que sus roles puedan teneridenti…cadores distintos (identidad), se cumplirá que si Ri 8i = 1; :::; n esuna subclase de rol de P , entonces, si se cuenta el número de objetos de Rique hay en la clase Ri, se obtendrá una respuesta diferente que si se cuentael numero de objetos de P que hay en el mismo conjunto. Sin embargo en


las particiones dinámicas, si Ri es una subclase de P , entonces, si se cuentael número de objetos de Ri que hay en un conjunto de Ri (en la subclaseRi), se obtendrá la misma respuesta que si se cuentan los P que hay en elmismo conjunto.

² La completitud: Los roles no son exhaustivos, sin embargo las particionesdinámicas han de ser completas.

² La compatibilidad de comportamiento: En las particiones se exige com-patibilidad de comportamiento y en la temporal se exigirá compatibilidad designatura según la caracterización propuesta por Wegner et al. [231].

² El cambio de clase: El cambio de clase a través del tiempo se produce deforma distinta en las particiones dinámicas y en los roles. En las particionesdinámicas se produce una migración o evolución (como se ha comentado enel capítulo anterior), ya que cuando el objeto que migra cesa de existir en lasubclase origen, éste se crea en la subclase destino. Esta migración es horizontalporque que se produce entre subclases del mismo nivel en la jerarquía. En losroles se produce una extensión porque el objeto no deja de existir en la claseorigen. La extensión es vertical, ya que las subclases se instancian desde lasuperclase (el jugador empieza a jugar el rol).

² El tipo de herencia: Los roles heredan las propiedades mediante un me-canismo de delegación; sin embargo, las particiones las heredan mediante unmecanismo estándar de herencia.

Éstas son las diferencias más importantes entre ambas aproximaciones. Se puedeobservar que las particiones dinámicas son más restrictivas que los grupos de roles,dando estos últimos un mayor grado de libertad al analista en el proceso de especi…-cación.

5.7 Clasi…cación Múltiple y Especialización Múlti-ple

En la especialización múltiple una subclase es especialización de dos o más clases ala vez. En la clasi…cación múltiple un objeto puede ser simultáneamente instancia dedos o más clases, debido a que la clase de dicho objeto puede especializarse en diversasjerarquías ortogonales. Por ejemplo, en la …gura 5.16 se puede ver un objeto de laclase vehículo que puede ser instancia de la subclase coche, de la subclase gasolinay de la subclase estropeado al mismo tiempo (subclases pertenecientes a particionesdistintas).El modelo de relaciones taxonómicas presentado en este capítulo permite la cla-

si…cación múltiple. Para simular la clasi…cación múltiple en los modelos que sólopermiten clasi…cación simple es necesario de…nir clases auxiliares (en muchas situa-ciones de manera forzada) mediante especialización múltiple y así poder representarcada combinación posible entre clases.En el modelo presentado en este trabajo se puede llegar a situaciones en las que la

especialización múltiple sea equivalente a la clasi…cación múltiple. Esto puede darse si

5.7. Clasi…cación Múltiple y Especialización Múltiple 147

Vehículo

OtrosCamiónCoche

Diesel

Gasolina

V-6785-HA

Estropeado

Funcionando

Vehículo

OtrosCamiónCoche

Diesel

Gasolina

V-6785-HA

Estropeado

Funcionando

Vehículo

OtrosCamiónCoche

Diesel

Gasolina

V-6785-HA

Estropeado

Funcionando

Figura 5.16: Ejemplo de Clasi…cación Múltiple

se considera que las especies forman parte del modelo presentado aunque no aparezcanen la especi…cación del problema. Las especies (término introducido por Wieringaet al. en [237]) son clases obtenidas mediante la combinación de las subclases de lasparticiones de más bajo nivel en la misma jerarquía. Cada especie involucra a variassubclases de particiones distintas y conlleva la herencia de las propiedades de cada unade ellas, de forma que las propiedades de la especie son la unión de las propiedadesde cada una de las clases que constituyen la especie. Las clases que forman unaespecie tienen una superclase como antecesor común que está particionada más deuna vez. Si en el modelo existen especies y se supone que todos los objetos poseenun mismo antecesor último, se puede a…rmar que la especialización múltiple y laclasi…cación múltiple son conceptos equivalentes en el modelo de objetos presentado.Es importante destacar que añadir una subclase de rol, en el modelo presentado,no genera nuevas especies, esto es debido a que sólo habrá especies si se introducenparticiones. Sin embargo, particiones de dicha clase de rol sí que implicarán nuevasespecies.Las especies no se incluyen en la especi…cación del problema excepto si es necesario

especi…car nuevas propiedades de la clase que constituye una determinada especie.Las especies se especi…can en OASIS siguiendo la plantilla de la clase y su nombreserá la concatenación mediante el símbolo ¤ de los nombres de las subclases queforman la especie. En la …gura 5.16 se pueden ver las particiones que se han de…nidoen los ejemplos anteriores. Además se muestra una representación grá…ca de unobjeto vehículo (cuyo mecanismo de identi…cación es la matrícula y tiene como valorV-6785-HA) que es instancia de una subclase de cada una de las particiones, es decir,en este caso es instancia de la especie estropeado*coche*gasolina. El conjuntode propiedades asociadas a la especie es la unión de las propiedades de las clasesestropeado, coche y gasolina.Las especies constituyen el soporte que la propuestaOASIS da a la especialización

múltiple. Este soporte no es completo pero es su…cientemente expresivo, siendo suutilización más natural (menos forzada) que el uso que muchas veces se hace de laespecialización múltiple. Si fuera necesario el uso de la especialización múltiple, se


Figura 5.17: Especialización Múltiple

puede modelar y después convertir en una especialización simple siguiendo las pautaspropuestas por Rodríguez et al. en [193].A nivel notacional, si es necesario modelar especies, se utilizará la notación grá…ca

de la especialización múltiple con el propósito de crear explícitamente una clase querepresente a la especie. La especialización múltiple se dibujará mediante varias ‡echasque parten de la subclase hacia las diferentes superclases. Se puede ver un ejemploen la …gura 5.17 en el cual se desea añadir nuevas propiedades a los coches diesel, conlo cuál se representa explícitamente la especie coches*diesel.

5.8 El Modelo Dinámico y la Especialización del Ci-clo de Vida

Como se ha comentado, en el Modelo dinámico de OO-Method se representan losaspectos del sistema referentes al control, a las posibles secuencias de eventos quepueden ocurrir en la vida de los objetos, y a la interacción entre éstos. A nivel grá…cose utilizan dos diagramas para modelar la dinámica del sistema: el Diagrama deTransición de Estados y el Diagrama de Interacción. De estos dos diagramas, es elDiagrama de Transición de Estados (DTE) el que requiere un tratamiento especial enlo que respecta al modelado de relaciones de especialización, donde se debe determinarcómo heredan las subclases el comportamiento de la clase padre de forma que semantenga la compatibilidad de comportamiento exigida. El tratamiento que se vaa presentar a continuación se puede extender fácilmente al modelo formal OASIS,debido a que el DTE utilizado en la etapa de modelado está concebido como unmecanismo que permite representar grá…camente el proceso que de…ne la vida de unobjeto y sus precondiciones. Esto además garantizará que las secciones process ypreconditions de una especi…caciónOASIS se podrán obtener de forma automática

5.8. El Modelo Dinámico y la Especialización del Ciclo de Vida 149

a partir del DTE según se presenta en [174].

El comportamiento de los objetos se puede especi…car operacionalmente, por ejem-plo, construyendo un autómata de transición de estados, o declarativamente, especi-…cando restricciones sobre el comportamiento de los objetos (precondiciones, restric-ciones de integridad dinámicas). Algunos ejemplos de especi…caciones operacionalesde los ciclos de vida de los objetos son los diagramas de transición de estados deOO-Method, los diagramas de estado (”statecharts”) [96, 98] presentes en UML, Syn-tropy, etc, los diagramas de diclo de vida (”Life Cycle Diagrams” (LCD)) de OMTroll[196, 239] o los diagramas de objetos (”objectcharts”) de Fusion [52]. Algunos ejem-plos de especi…caciones declarativas del ciclo de vida son el uso de lógica dinámica yálgebra de procesos para describir el comportamiento de los objetos como se realizaen OASIS, o el uso de lógica temporal para describir las propiedades del ciclo devida en Troll [102], Oblog [203, 204] y TESORO [228]. La mayoría de las propuestasque modelan declarativamente el ciclo de vida de un objeto, utilizan la idea de que elcomportamiento de un objeto puede modelarse como un conjunto de trazas de ocu-rrencias de eventos. Estas trazas son modelo de los axiomas lógicos que describen elcomportamiento del objeto. En estos casos, la especialización se modela como unarelación de subconjunto en los conjuntos de trazas.

En esta sección se va a tratar la especialización del ciclo de vida de un objeto,utilizando los diagramas de transición de estados (DTE) de OO-Method. La espe-cialización del ciclo de vida se llevará a cabo respetando la compatibilidad de com-portamiento exigida para las particiones. Para ello se extiende la compatibilidad decomportamiento a los ciclos de vida de un objeto, basándose en el principio de reem-plazabilidad propuesto por Wegner y Zdonik, siguiendo el enfoque de consistencia deobservación introducido por Ebert y Engels [70]. La idea es que cualquier diagrama deciclo de vida de…ne el conjunto de trazas posibles, donde cada traza es una secuenciade ocurrencias de eventos que constituye una historia permitida en el diagrama. Si deuna traza de un ciclo de vida especializado se omite el conjunto de eventos que no sehan de…nido en la superclase, entonces se obtendrá una posible traza de la superclase.Así la vida de un objeto especializado visto como una instancia de la clase padre seráuna vida válida. Esta propuesta interpreta el principio de reemplazabilidad comosigue: “Una traza de un objeto de una subclase restringida a los eventos de…nidos enla superclase puede ocurrir en cualquier contexto en que se esperaba una traza de unobjeto de la superclase”. Existen diversas propuestas desarrolladas que se basan enesta idea: Stumptner y Schre‡ [218], Ebert y Engels [70], Saake et al. [196], Harel[99], así como la que se desarrolla a continuación, que constituye una adaptación de[196] para OO-Method.

La propuesta que se presenta propone dos técnicas complementarias que puedenimplementarse en herramientas CASE comerciales: la demostración de compatibili-dad y las transformaciones de comportamientos seguras. Estas técnicas permitiránconstruir en las subclases ciclos de vida especializados que respeten la compatibilidadde comportamiento, e incluirán algoritmos que permitan comprobar el cumplimientodel principio de sustitutibilidad. Una vez de…nido cómo se especializa el ciclo de viday cómo construir ciclos de vida compatibles, se propondrá cómo construir el ciclo devida de las subclases de las particiones estáticas, dinámicas y los roles.


Sfabricar

vender

destruir

Figura 5.18: DTE de la clase Vehículo

5.8.1 Diagramas de Transición de Estados

El conjunto de las vidas posibles de…ne un proceso que es la descripción formal delcomportamiento de un objeto. Dicho conjunto de vidas posibles es lo que se llamaconjunto de trazas y puede representarse mediante un autómata …nito de estados.En el modelo dinámico de OO-Method cada clase posee un diagrama de transiciónde estados (DTE) que representa dicho autómata. El DTE permite modelar losposibles ciclos de vida de las instancias de dicha clase, con una semántica similar ala introducida por los LCD de Saake et al. [196]. El DTE de una clase cualquiera Cpuede verse como un grafo dirigido G = (E;T ) tal que:

² E es un conjunto de estados posibles del objeto, representados mediante nodosdel grafo, y

² T es un conjunto de transiciones de estado representadas por ‡echas etiquetadas.

Una transición de estados t 2 T es una tupla (ei; ej ; ev; p; cc) 8i; j = 1; :::; n donde

² ei es el estado inicial de t,² ej es el estado …nal de t,y la transición t irá etiquetada por

² ev es un evento de la signatura de la clase C,² p es una precondición opcional asociada a ev, y² cc es una condición de control opcional de la transición t

siguiendo la sintaxis: evento j accion j transaccion [if precondicion] [when condicion-de-control].Un ejemplo de un DTE puede verse en la …gura 5.18. Este DTE es el de la

clase Vehículo, y describe un comportamiento muy simple: los vehículos puedenfabricarse y destruirse, y durante su vida sólo pueden ser vendidos.

5.8.2 Condiciones de Especialización y Compatibilidad de Com-portamiento

Dada una subclase cualquiera Si; 8i = 1; :::; n, de la clase P , las condiciones queafectan a la especialización del DTE y que se deben cumplir en Si; son las siguientes:


² Todos los atributos y eventos de…nidos para las instancias de la clase P sonatributos y eventos de las instancias de la clase Si. La subclase Si puede enri-quecerse de…niendo tanto nuevos atributos como eventos.

² Las precondiciones de P; si se rede…nen en Si, serán más restrictivas (más fuer-tes). Así, si ev es un evento de…nido en la clase P y ev ocurre en la vida de unainstancia o de la clase Si, entonces también es una ocurrencia de evento válidaen la vida de o visto como instancia de P .

² El tratamiento de las condiciones de control será el mismo que el presentadopara las precondiciones. Las condiciones de control sirven para determinar elpróximo estado a alcanzar en el DTE cuando para un mismo evento existenmúltiples alternativas (más de una transición etiquetada con el mismo eventopartiendo del mismo estado). En este caso una condición sobre atributos delobjeto debe determinar exactamente el camino a seguir, eliminando de estaforma el posible no-determinismo del DTE. Dependiendo de las condicionesde control, se podrá ir a estados diferentes y cambiar la secuencia posible deeventos en la vida de un objeto. Así, si ev es un evento de…nido en la clase P yev ocurre en el DTE de una instancia o de la clase Si a través de la transición(ei; ej ; ev;_;_) 8i; j = 1; :::; n, entonces también existe dicha transición en elDTE de o visto como instancia de P . Las condiciones de control están presentesen la especi…cación OASIS como guardas de los eventos que participan en lade…nición del proceso que de…ne la vida de un objeto [168].

² El ciclo de vida se especi…ca en OASIS como un proceso que representa la vidade una instancia de una clase. La especi…cación de proceso de una subclase Sidebe cumplir la compatibilidad de comportamiento aplicada al ciclo de vida.Por ello se debe de cumplir que, si se restringe el ciclo de vida especi…cadopara las instancias especializadas a los eventos de…nidos solamente para la clasepadre, se obtendrá un subconjunto del ciclo de vida de…nido para las instanciasde la clase padre. Así pues, la vida de un objeto especializado visto comouna instancia de la clase padre será una vida válida. Esta condición es unainterpretación particular del principio de reemplazabilidad aplicado a los ciclosde vida e interpretado de la siguiente manera: “Una traza de un objeto de unasubclase Si, restringida a los eventos de…nidos en la superclase P , puede ocurriren cualquier contexto en que se esperaba una traza de un objeto de la superclaseP”.

Éstas son las condiciones que debe cumplir la especi…cación del ciclo de vida deuna clase especializada. Para comprobar cómo se aplican estas condiciones, se abordala especi…cación de un ejemplo. Tomando como referencia la clase Vehículo presen-tada anteriormente, ésta se puede especializar en una subclase Coche. En el ciclode vida de Coche, se podrán introducir nuevos eventos y nuevos estados, además dehacer que las transiciones existentes sean más restrictivas (se debe asegurar que si semodi…can las precondiciones (y las condiciones de control si existen), la precondiciónde la superclase implique lógicamente a la nueva precondición), para garantizar quese respeten siempre las condiciones de especialización del ciclo de vida enunciado an-teriormente. Así pues, un Coche además de los eventos que le podían ocurrir a un


S

U

Tfabricar

vender

encontrar robar

reparar

accidentar

destruir

destruir

Figura 5.19: DTE de la subclase Coche

Vehículo, puede ser robado y encontrado o retirado, puede accidentarse y des-pués arreglarse o ser destruido. En la Figura 5.19, se puede ver el DTE de la claseCoche. Intuitivamente, a simple vista parece que la clase Coche es una especializaciónde la clase Vehículo, ya que un Coche visto como Vehículo se comporta como unVehículo. En el siguiente apartado se presenta la formalización de este concepto tanintuitivo de especialización.

5.8.3 La Especialización como un Mor…smo entre Grafos

Para comprobar si se especializan correctamente los conjuntos de ciclos de vida, sedebe cumplir que “Cada nuevo ciclo de vida de la clase especializada, restringido alos eventos heredados de la clase padre, debe de estar contenido en el conjunto de losposibles ciclos de vida de la clase padre”. Esta propiedad de…nida sobre el conjuntode trazas se puede demostrar haciendo uso de los DTE, mediante mor…smos entreDTE. Para ello es necesario determinar la existencia de una relación entre los DTEy las trazas de eventos que estos de…nen implícitamente, de manera que el procesode comprobación de la compatibilidad de comportamiento se pueda trasladar a losDTE. El razonamiento que se va a seguir es determinar en primer lugar la relaciónentre los DTE y las trazas, y a continuación a través de dicha relación, se trasladarála comprobación de la compatibilidad resuelta a nivel de trazas al nivel de los DTE.Así pues, dado un diagrama de transición de estados DTEi de la clase Ci, una

traza de eventos tr satisface dicho DTE, si se corresponde con un camino en el grafo,partiendo del estado inicial del mismo. Así pues, se de…nirá el conjunto Trazasi comoel conjunto de trazas de eventos tr que satisfacen el DTEi.Dados dos diagramas de transición de estados DTE1 y DTE2, diremos que DTE2

especializará el comportamiento de DTE1(o que el comportamiento que describe serácompatible con DTE1) si se cumple que Trazas02 ½ Trazas1;siendo Trazas02 el con-


DTE 1

aplanar

trazas 2trazas 1

DTE 2

aplanar

morfismo de herencia

herencia entre DTEs

Figura 5.20: Relación entre trazas y DTE

junto de trazas que se obtiene si se eliminan los eventos nuevos (en C2) de las trazasde Trazas2. La restricción sobre los eventos heredados se corresponde con la funciónde proyección sobre las trazas en donde los nuevos eventos desaparecen y la inclusiónse de…ne como una función inyectiva. Estos conceptos anteriores de…nen la nociónde mor…smo de herencia sobre el comportamiento de los objetos introducido en [203],y permiten demostrar si dos comportamientos son compatibles haciendo uso de lastrazas de eventos.La relación entre el conjunto posible de trazas (Trazasi) y los DTE permitirá

trasladar la comprobación de la compatibilidad de comportamiento al nivel de losDTE. El conjunto de todas las trazas puede generarse “aplanando-desplegando” elDTE. Como las trazas pueden verse como grafos dirigidos especiales, entonces la fun-ción inyectiva que sirve para de…nir el mor…smo de herencia entre conjuntos de trazasserá un mor…smo entre los grafos que de…nen las trazas. Así pues, se puede volvera formular de forma equivalente la relación de especialización utilizando mor…smosentre grafos: “Una traza satisface un DTE, si existe un mor…smo de inclusión quepreserva los eventos proyectando la traza sobre el DTE”.En el diagrama de la …gura 5.20 se representa que de…nir un mor…smo de herencia

entre conjuntos de trazas es equivalente a de…nir un mor…smo de herencia entre dosDTE (una proyección seguida de un mor…smo entre grafos).A continuación se presentan dos técnicas basadas en los DTE para garantizar las

condiciones de especialización entre dos DTE cualquiera.

5.8.4 Condiciones de Especialización para los DTE

Se puede asegurar de dos maneras una adecuada relación de especialización entre dosDTE:

1. De…niendo un algoritmo que compruebe las condiciones de especialización

2. Ofreciendo un conjunto de manipulaciones sobre el DTE que garanticen el cum-plimiento de las condiciones de especialización


Comprobación de las Condiciones de Especialización

A continuación se presenta un procedimiento de comprobación de las condiciones deespecialización que analizará dos DTE para comprobar si el segundo es una especiali-zación del primero. Este procedimiento puede ser útil como parte de una herramientade modelado visual orientado a objetos.El procedimiento de comprobación consiste en dos fases:

² el análisis de la estructura y² el análisis de las precondiciones y las condiciones de control

La entrada del procedimiento de comprobación son dos DTE; uno el dte1 quedescribe los posibles ciclos de vida de las instancias de la clase C1 y otro el dte2 de laclase C2, donde la signatura de C2 es un superconjunto de la signatura de C1.

Análisis de la Estructura. Para analizar la estructura se llevarán a cabo lossiguientes pasos:

1. Unir los nodos de dte2 que estén conectados por transiciones etiquetadas connuevos eventos de…nidos en dte2 (que no han heredado de C1) en uno solo.Ajustar las ‡echas a los nuevos nodos.

2. Eliminar las ‡echas etiquetadas con eventos que no se han heredado de C1.El DTE resultante se llamará dte2C1 (signi…cando dte2 restringido a C1). Lospasos 1 y 2 aplican el operador de proyección comentado anteriormente sobredte2.

3. dte2 hereda la estructura de dte1 si existe un mor…smo de inclusión entre grafosde dte2C1 a dte1. Un mor…smo de inclusión entre grafos hace correspondernodos con nodos y ‡echas con ‡echas tal que se respeta la estructura del grafo.Además, las etiquetas de las transiciones deben ser respetadas, y los estadosinicial y …nal no deben identi…carse con otros nodos.

En el ejemplo del Vehículo (ver …gura 5.18) y el Coche (ver …gura 5.19), el dte1será el DTE de Vehículo y dte2 será el DTE de Coche. En el paso 1 del algoritmo seunen el estado U y el estado T . En el paso 2 se eliminan las transiciones accidentar,reparar, robar, encontrar y retirar. Con ello se obtiene un dte2V eh¶{culo que secorresponde perfectamente con dte1.

Análisis de las Precondiciones y las Condiciones de Control. El análisis delas precondiciones (condiciones de control) ha de comprobar si las precondiciones (con-diciones de control) de dte2 son más restrictivas que las precondiciones (condicionesde control) de dte1, para ello:

1. Se identi…carán pares de transiciones (ei; ej ; ev1; p1; cc1) en dte1 y (ei; ej ; ev2; p2;cc2) en dte2 8i; j = 1; :::; n, donde el evento ev2 se corresponde con el evento ev1en el mor…smo de inclusión entre los dos grafos.


2. Comprobar si la precondición p2 (condición de control cc2) de ev2 implica lógi-camente la precondición p1(condición de control cc1) de ev1, por lo que se debecumplir:

p2 =) p1 (cc2 =) cc1)

Así se comprueba que las nuevas precondiciones (o en su caso condiciones de con-trol) son más restrictivas que las precondiciones (condiciones de control) heredadas.Para automatizar la comprobación de si una fórmula implica a otra es necesario el

uso de razonadores como el presentado en [93]. Existen productos comerciales comoILOG OPL Studio y su motor de inferencia ILOG Solver [107] basados en la progra-mación basada en restricciones que permiten comprobar si una fórmula lógica implicaa otra. Este producto puede ser utilizado por una herramienta CASE para automa-tizar la comprobación de la compatibilidad de comportamiento para precondiciones,restricciones de integridad y disparos. La resolución de estos problemas tiene asociadoun coste computacional elevado por lo que se exige utilizar heurísticas que acoten elrango de valores posibles que las variables de la fórmula pueden tomar.

Manipulaciones seguras del DTE

Otra forma de abordar el problema es ofrecer un método constructivo del DTE espe-cializado, de manera que si se utilizan en su construcción transformaciones que man-tengan la compatibilidad no será necesario demostrar ningún predicado para saber siun DTE especializa a otro cumpliendo las condiciones de especialización presentadas.Así pues, como alternativa al procedimiento de comprobación de las condiciones de es-pecialización, se ofrecen una serie de manipulaciones seguras del DTE que garanticenlas condiciones de especialización. Para ello se distinguirá entre manipulaciones pri-mitivas vistas como manipulaciones básicas y manipulaciones derivadas vistas comouna secuencia de manipulaciones primitivas. Estas manipulaciones podrán incorpo-rarse en una herramienta de Modelado OO como ayuda a la construcción de DTE, deforma que se garantice de manera automática su correcta especialización.

Manipulaciones primitivas del DTE Las manipulaciones primitivas que garan-tizan las condiciones de especialización son:

² AñadirTransición: Añade una nueva transición desde un nodo e hacia él mis-mo, etiquetada con un nombre de evento nuevo.

² DividirNodo: Divide un nodo en varios nodos donde se les copiarán todos losarcos que tenía conectados éste. También se copiarán los ciclos y se conectarántodos los nodos nuevos entre sí en ambas direcciones con las transiciones quetenía el nodo dividido.

² EliminarTransición: Se elimina una transición.

² EliminiarNodoSolitario: Eliminar un nodo que no esté unido a ningún otropor ninguna transición.

² ReforzarPrecondición: Se hará más restrictiva una precondición. Eliminar-Transición puede verse como un caso especial de esta operación donde precon-dición=falso.


Se puede comprobar fácilmente que con estas operaciones primitivas se mantienela condición de especialización entre los DTE.

Manipulaciones derivadas del DTE El conjunto de operaciones primitivas escompleto pero no tienen la granularidad adecuada para constituir operaciones de unaherramienta de diseño (por ejemplo, para formar parte de un editor para manipu-lar DTE especializados). Así pues, se de…nen a continuación algunas operacionesderivadas que serán útiles.Como manipulaciones derivadas compuestas de una serie de operaciones básicas

se tienen las siguientes transformaciones:

² ExpandirNodo: Un nodo de un DTE puede reemplazarse por un subgrafo com-pleto de la siguiente manera:

– Las transiciones del subgrafo estarán etiquetadas sólo con nombres de even-to nuevos introducidos al especializarse.

– Se distribuirán copias de las transiciones heredadas que llegaban o salíanal/del nodo expandido, sobre los nuevos nodos (respetando la dirección delas transiciones).

² CopiarSubgrafo: Igual que dividir un nodo, se puede copiar un subgrafo com-pleto (doblando los arcos que entran y salen de éste).

² EliminarSubgrafoSolitario: Análogamente a como se hacía eliminando no-dos solitarios, también se puede eliminar subgrafos que no sean alcanzablesdesde el estado inicial del DTE. Como está permitido borrar arcos, se puedendejar subgrafos “solitarios” por lo que se permitirá eliminarlos.

Las transformaciones ExpandirNodo y CopiarSubgrafo están constituidas por unasecuencia de operaciones primitivas (por ejemplo ExpandirNodo realiza los siguientespasos: en primer lugar añade arcos cíclicos con los nuevos eventos al nodo que seva a expandir, después divide dicho nodo en los nodos que formarían el subgrafo y…nalmente elimina transiciones hasta dejar el subgrafo que se pretendía).En los siguientes apartados se presentan ejemplos de aplicación de este tipo de

manipulaciones para la construcción de los DTE de las subclases estáticas y dinámicas.

5.8.5 Especialización del Ciclo de Vida en Subclases Estáticas

En una partición estática los ciclos de vida más complejos se encuentran en las sub-clases. Las subclases estáticas heredan el DTE de la superclase, y pueden modi…carsu comportamiento añadiendo transiciones (eventos) y estados, siempre de forma quese cumplan las condiciones de especialización enunciadas anteriormente. Estas con-diciones se cumplirán de una de las siguientes maneras: (1) permitiendo cualquiermanipulación del DTE de la clase padre y aplicando después algoritmos que com-prueben si la estructura del grafo resultante es “conforme” con la del grafo de laclase padre (es decir, si respeta la compatibilidad de comportamiento), o (2) evitandomanipulaciones no permitidas sobre el grafo que representa el ciclo de vida.


Sfabricar

vender

V

destruir

cambiar_aceite

cambiar_filtro

terminar_mantenimiento

Figura 5.21: DTE de la subclase Diesel

En las …guras 5.18, 5.19 y 5.21 se pueden ver los DTE de la clase Vehículo, y desus subclases Coche y Diesel, en las cuales se puede observar que las subclases hanespecializado el DTE de la clase padre y han incluido nuevos estados y transiciones,cumpliendo las condiciones de especialización mencionadas. En concreto, en el casode la subclase Diesel (ver …gura 5.21), se ha expandido el nodo S, añadiendo ar-cos cíclicos al nodo S con los eventos terminar_mantenimiento, cambiar_aceite ycambiar_filtro, dividiendo el nodo en S y V ,y por último eliminando transicioneshasta dejar el DTE como en la …gura.

5.8.6 Especialización del Ciclo de Vida en Subclases Dinámi-cas

En las particiones dinámicas además de representar los DTE de las clases padre e hijas,se modelará (como se ha visto anteriormente) el diagrama de migración asociado a lapartición dinámica, en el caso de una especialización basada en eventos. El diagramade migración no será de la superclase, ni de las subclases dinámicas. Se asociará deforma exclusiva a las particiones dinámicas, existiendo uno por partición dinámica deuna clase; de esta forma además se fomenta la reutilización a nivel de especi…cacióndel comportamiento, porque se consigue que la especi…cación del comportamiento dela superclase no dependa de las particiones dinámicas que tenga.Desde un punto de vista teórico, el DTE que representa la vida de un objeto

cualquiera en una partición dinámica es la unión (realizada a través del proceso mi-gratorio) de los distintos DTE de…nidos en cada subclase de la partición. Teniendoen cuenta la semántica de los eventos de migración, la construcción del DTE de unasubclase dinámica se llevará a cabo de la siguiente manera:

² Del estado inicial (o de creación) saldrá una ‡echa etiquetada con el nombredel evento/s portador/es, representando que cuando se produce dicho evento secrea un objeto de dicha subclase de la partición (migrando a dicha subclase). Enel caso de que la subclase sea la inicial en el proceso de migración, éste eventoserá el constructor de la superclase.


² Al estado …nal llegarán ‡echas etiquetadas con eventos destructores y (si exis-ten) evento/s de migración a otra subclase de la misma partición dinámica(evento liberador), representando que dichas transiciones destruyen al objeto olo hacen migrar a otra subclase dinámica (subclase para la cual existirá unatransición en el diagrama de migración).

² Por lo que respecta a los demás estados y transiciones, el DTE se construirá de lamisma manera que cualquier DTE de una subclase estática, incluyendo estadosy transiciones etiquetadas con eventos heredados y nuevos de la subclase.

Una vez construido el diagrama de migración y los DTE de cada una de las subcla-ses de la partición, si se expande cada uno de los estados del diagrama de migraciónen el DTE de…nido para cada subclase, se obtendrá un diagrama …nal que represen-tará las vidas posibles que puede tener un objeto de la partición dinámica. El DTEexpandido se obtendrá de la siguiente manera:Sea fS1; :::; Sng una partición dinámica de P , DSi el DTE de una subclase Si

8i = 1; :::; n, y Dmig el diagrama de migración de la partición dinámica cuyos estadosEDmig = fe1; :::; eng se corresponden con los nombres de cada una de las subclasesde la partición siendo ei = nombre(Si)11 8i = 1; :::; n,: El DTE expandido (al que sellamará DUnion) será la unión de los DTE de la partición (DS1 [ :::[ DSn) realizadade forma consecuente con el proceso migratorio de…nido por Dmig. Dicha unión sellevará a cabo como sigue a continuación:

² EDUnion = EDS1[ ::: [EDSn

, son los estados de DUnion.

² TDUnion = TDS1[ :::[TDSn

, son las transiciones de DUnion, donde 8t 2 TDUnion

/ 9 ev que participa en una transición t0 = (_; Si; ev;_;_) 2 TDmig8i = 1; :::; n

cuyo estado …nal Si es un estado con el nombre de una subclase de la partición,a la transición t se le cambiará su estado …nal por el estado inicial del DTE dela subclase Si de forma que t = (_; einicial; ev;_;_) tal que einicial 2 EDSi

y9 t00 2 TSi = t00 = (ecreacion; einicial; ev;_;_); donde ecreacion es el estado deprecreación del DTE.

Intuitivamente, lo que se pretende es que las transiciones de cada uno de losDTE de las subclases dinámicas, que estén etiquetadas con eventos que poseanalguna transición en el diagrama de migración, cambien su estado …nal por elestado inicial del DTE de la subclase destino en la migración. De esta forma,usando los estados (que se corresponden con cada una de las subclases de lapartición) y los eventos del diagrama de migración, se enlazan los DTE de lassubclases para constituir el DTE expandido.

El proceso de construcción de los DTE fDS1 ; :::;DSng de las subclases y la obten-ción del DTE expandido DUnion; garantizan la compatibilidad de comportamiento,ya que se puede asegurar que el ciclo de vida de un objeto en una subclase de la par-tición (visto como una traza de eventos) se comporta como el ciclo de vida de…nidopor DUnion; porque un traza de su vida siempre será un subconjunto de la traza de lavida del objeto en la partición. A su vez, DUnion también respetará la compatibilidadde comportamiento respecto al DTE de la superclase (DP ).

11Función que devuelve el nombre de la subclase Si:


Empleado0contratar

cambiar_telefono cambiar_seccioncambiar_puesto

cambiar_direcc ion

eliminar

despedir

pagar

incrementar_edad matricular if edad>=18

subir_sueldobonificar

inic iar_mes

faltar_al_trabajo

Figura 5.22: DTE de la clase Empleado

Empleado0



cambiar_telefono cambiar_seccion

cambiar_puesto

cambiar_direccion

eliminar

despedir

cambiar_telefono

promocionar

venderiniciar_mes

faltar_al_trabajo

pagar

contratar

Figura 5.23: DTE de la subclase dinámica Vendedor

Para entender la propuesta se desarrolla el ejemplo de la …gura 5.11, en el cualse presenta la partición dinámica de la clase Empleado y sus subclases Vendedor yResponsable. En la …gura 5.22 se presenta el DTE de la clase Empleado, y en la …gura5.12 se presenta el diagrama de migración para la partición dinámica de Empleado.El DTE de la clase Vendedor (ver …gura 5.23) es un diagrama que cumple las

condiciones de especialización respecto al DTE de la clase Empleado. Es importantedestacar que la transición promocionar llega al estado …nal por ser el evento demigración a la clase Responsable. En este caso un Vendedor se comporta como unEmpleado que además puede promocionar.En la …gura 5.24 se presenta el DTE de la clase Responsable. Es importan-

te destacar que la transición promocionar sale del estado inicial por representar laocurrencia del evento portador que lleva el objeto hacia la clase Responsable. Latransición rebajar llega al estado …nal por representar el evento de migración a laclase Vendedor. El DTE anidado representa que como responsable le pueden ocurrirlos eventos que entran al estado Empleado0 y, estando en ese estado, también puedeseguir el DTE anidado (es cómo realizar la operación CopiarSubgrafo).


Empleado0

Responsable1

incrementar_edadmatricular if edad>=18

subir_sueldo

bonificar

promocionar

cambiar_telefono

cambiar_seccioncambiar_puesto

cambiar_direccion

faltar_al_trabajo

iniciar_mespagar

Responsable1

asignar_vendedoresquitar_vendedores

asignar_vendedores

quitar_vendedores(n) if nVendedores=n

eliminar

despedir

rebajar

Figura 5.24: DTE de la subclase dinámica Responsable

Siguiendo la propuesta presentada en este apartado, a partir del diagrama de mi-gración y a través de un proceso de unión de los DTE especializados se consigue elDTE de la …gura 5.25. Este DTE representa la vida de un objeto de la particióndinámica según se ha comentado anteriormente. Observando el diagrama de migra-ción, los eventos promocionar y rebajar son los que producen la migración. Según lapropuesta de unión presentada: (1) la transición del evento promocionar en el DTEde la subclase Vendedor cambiará su estado …nal por el estado inicial del DTE deResponsable (que será Empleado0), y (2) la transición del evento rebajar en el DTEde la subclase Responsable cambiará su estado …nal por el estado inicial del DTE deVendedor (que será Empleado0).Este DTE no es necesario construirlo explícitamente en la etapa de modelado,

aunque es importante presentarlo para mostrar que los DTE de las subclases, al estarincluidos en éste, respetan las condiciones de especialización presentadas.En el caso de que la especialización dinámica esté basada en el cumplimiento de

condiciones sobre atributos variables, la condición de especialización se cumplirá alcrear el objeto o al ocurrir un evento que modi…que el/los atributo/s implicado/s enla condición de especialización. Al no existir explícitamente eventos de migración,los DTE de las subclases dinámicas se construirán siguiendo las pautas propuestaspara las subclases estáticas. Aunque para aplicar de manera homogénea la soluciónpresentada anteriormente es necesario un diagrama de migración, que en este caso noestá presente.Este problema se puede resolver analizando la especi…cación, en concreto las eva-

luaciones de los eventos. De esta forma se pueden obtener aquellos eventos que modi…-can los atributos variables participantes en las condiciones de especialización. A estoseventos se les llamará eventos de posible migración porque, cuando ocurren, pueden


Empleado0

Responsable1


subir_sueldo

bonificar

contratar

cambiar_telefono


cambiar_direccion

faltar_al_trabajo

iniciar_mespagar

Responsable1


asignar_vendedores

quitar_vendedores(n)[ nVendedores=n ]

promocionar

rebajar

eliminar

despedir

Figura 5.25: DTE unión de los DTE de Vendedor y Responsable

causar la migración del objeto a otra subclase de la partición. Con esta informaciónse pueden construir diagramas de migración implícitos (transparentes al usuario) queposean, como estados los nombres de las subclases de la partición dinámica y, comotransiciones los eventos de posible migración. La condición de especialización se aso-ciará a dichas transiciones como una condición de control (guarda) del evento. Enel caso de no cumplirse la condición de control, no ocurrirá nada. De esta forma seobtendrá un diagrama de migración que podrá utilizarse para aplicar adecuadamentela propuesta presentada. Como ejemplo, se presenta la partición dinámica de la …gura5.13 en la que, cuando se crea un Empleado, éste empieza a pertenecer a la subclaseVendedor o Gerente, dependiendo del puesto de trabajo. Cuando su puesto cambiapor la ocurrencia del evento cambiar_puesto entonces el objeto podrá migrar de unasubclase a otra dependiendo del valor del atributo puesto. El diagrama de migraciónimplícito será el de la …gura 5.26.

5.8.7 Especialización del Ciclo de Vida en Roles

En los roles no se obliga a que se cumpla una compatibilidad de comportamiento, sólose exige que se cumpla la compatibilidad de signatura entre las clases jugadoras y susroles, por lo que no será necesario que, en la construcción de los DTE de las clases derol, se cumplan las condiciones de especialización enunciadas anteriormente en esteapartado.El DTE de las clases de rol se especi…cará de forma “independiente” al de la

superclase (clase jugadora) de la cual derivan. Para construir dicho DTE se utilizaránlos eventos de la superclase y los propios del rol, con la única restricción de que el


Vendedor

Responsable

cambiar_puesto[ puesto="Vendedor" ]

cambiar_puesto[ puesto="Responsable" ]

crear[ puesto="Vendedor" ]

crear[ puesto="Responsable" ]

Figura 5.26: Diagrama de Migración generado a partir de las condiciones de especia-lización y de las evaluaciones de los eventos

Persona0

crear eliminar

cambiar_direccion cambiar_telefonoincrementar_edad revision_medica

matricular if edad>=18contratar if edad>=16

Figura 5.27: DTE de la clase Persona del diagrama de clases de la …gura 5.14 (Versión1)

evento de creación del rol (activador) será el que lleve al rol al estado inicial de suDTE y su evento/s de destrucción (…nalizador) llevará el rol al estado …nal del DTEde la subclase de rol. Una forma sencilla de construir dicho DTE será heredando elde la clase jugadora (cambiando la transición inicial por el evento activador del rol)y permitiendo cualquier modi…cación de éste en la subclase de rol. El analista podrárespetar o no las condiciones de especialización para los DTE. Si las respeta el roltendrá compatibilidad de comportamiento y sino, mantendrá la compatibilidad designatura.En las …guras 5.27 y 5.28 se presentan dos versiones posibles del DTE de la clase

Persona que se muestra en la …gura 5.14. En la …gura 5.27 se puede observar queuna Persona cualquiera podrá adquirir cualquier rol (el de Estudiante o Empleado)en cualquier orden, teniendo en cuenta las restricciones de multiplicidad especi…cadasy la propiedad de disyunción asociada al grupo de rol.En la …gura 5.28 se puede observar que en el DTE además se explicita un de-

terminado orden en la toma de los roles, exigiendo que primero se tome el rol deEstudiante y después el de Empleado. Se han presentado estas dos versiones paradestacar la potencia expresiva del DTE, ya que mediante su utilización adecuada sepueden especi…car restricciones sobre el orden en el que los objetos jugadores adquie-ren los roles.En la …gura 5.29 se presenta el DTE de la subclase de rol Estudiante (especializa-

do del DTE de la …gura 5.27) en el cual se observa que el evento matricular es el ac-tivador, y su transición sale del estado inicial del DTE. El evento terminar_estudios


Persona0

crear


matricular if edad>=18

contratar if edad>=16

Persona1 Persona2

matricular if edad>=18

eliminar

eliminareliminar

Figura 5.28: DTE de la clase Persona del diagrama de clases de la …gura 5.14 (Versión2)

Estudiante0matricular

Estudiante1

eliminar

matricular_asignatura


examinar if NumAsignaturasMatriculadas>=1

terminar_estudios

eliminar

Figura 5.29: DTE de la clase Estudiante (subclase de rol de la clase Persona en eldiagrama de clases de la …gura 5.14)

es el evento de …nalización del rol, y por ello su transición se dirige hacia el estado…nal del DTE.

5.8.8 Especialización del Ciclo de Vida y Clasi…cación Múlti-ple

La propuesta de modelo taxonómico introducido en esta tesis soporta la clasi…caciónmúltiple. En el contexto de OO-Method, la clasi…cación múltiple tiene implicacionesen la especi…cación del comportamiento (a nivel de DTE). Esto es debido a que sepueden modelar diversas particiones (estáticas o dinámicas) de una misma clase. Enla propuesta presentada, el comportamiento de un objeto con diversas particiones lodescriben de forma “independiente” cada una de las especi…caciones de comporta-miento de las subclases activas12 en cada partición. Ante esta situación se plantea elproblema de cómo se combinan las especi…caciones de comportamiento de cada unade las subclases a las que pertenece el objeto para que éste se comporte tal y como se

12Aquellas en las que está instanciado el objeto.


ha especi…cado. A este problema se le conoce como el problema de la ortogonalidadde los DTE.

Ortogonalidad

Uno de los métodos de modelado que ha tratado este problema es Syntropy [53]. Lasolución adoptada por Syntropy permite combinar diagramas de estados ortogonalesque de…nen comportamientos que no poseen estados en común. Este tipo de diagramasse combinan permitiendo la ejecución en paralelo de las distintas máquinas de estadoy manteniendo para cada una su estado actual, por lo que el estado del objeto seráel conjunto de sus estados en cada una de las máquinas ortogonales. Esta soluciónes aplicable al modelo OASIS, proponiendo que el DTE de un objeto clasi…cadomúltiplemente sea la composición AND de Harel [96] (o la composición paralela jj enel álgebra de procesos que utiliza OASIS) de cada uno de los DTE de las subclasesactivas. Es importante recordar que en OO-Method el DTE constituye un mecanismopara representar grá…camente el proceso de una clase (la especi…cación de procesoen OASIS) por lo que los resultados que se presenten en este apartado son aplicablesal modelo OASIS.La solución de ortogonalidad del DTE presentada es factible cuando los estados de

los distintos DTE de las subclases son disjuntos. Sin embargo, debido a la forma enla que se construyen los DTE para garantizar la compatiblidad de comportamiento,los estados de los distintos DTE no serán disjuntos porque poseerán en común losestados de…nidos en el DTE de la superclase. Si se aplica esta solución a subclasescon estados no disjuntos, las subclases seguirán manteniendo la compatibilidad decomportamiento, porque si se proyecta una traza de una subclase sobre los eventosde la clase padre se obtendrá una traza o vida permitida en la clase padre.Para ilustrar este razonamiento se puede observar el diagrama de clases de la …gura

5.16, y los DTE de las subclases Coche (…gura 5.19) y Diesel (…gura 5.21). En la…gura 5.16 se presenta un modelo con clasi…cación múltiple. En este modelo es muyprobable que existan objetos que sean coches de motor diesel (que pertenecen a lassubclases Coche y Diesel a la vez). Si se supone que los DTE de ambas subclases sonortogonales y se permite la ejecución concurrente de ambos DTE, se pueden obtenerlas siguientes trazas de eventos:

² Para el objeto como instancia de Coche:fabricar.vender.robar.encontrar.accidentar.reparar.accidentar.destruir

² Para el objeto como instancia de Diesel:fabricar.vender.cambiar_aceite.cambiar_filtro.terminar_reparacion.destruir

Si se proyectan ambas trazas sobre los eventos de la clase Vehículo se obtieneen ambos casos la traza fabricar.vender.destruir. Esta traza es una vida válidadel objeto visto como instancia de Vehículo. Esto induce a pensar que esta soluciónes correcta, pero cuando se trabaja sobre un mismo objeto especializado en diversassubclases a la vez, pueden existir dependencias y relaciones entre los nuevos estadosy eventos que introducen las subclases.Sobre el ejemplo presentado se pueden observar este tipo de dependencias. Existen

al menos dos posibles semánticas asociadas al modelo:


1. Desde el punto de vista del taller : si se tiene un objeto coche diesel y ocurreel evento robar, el coche no estará accesible en el taller porque lo han robado,así pues, a continuación no se le podría cambiar_aceite. En esta situación elcoche se queda en un estado en el cual no se le debería poder cambiar el aceite.La solución de ortogonalidad propuesta permite el cambio de aceite lo que norepresentaría adecuadamente el comportamiento exigido por el problema.

2. Desde el punto de vista del vehículo: si se tiene un objeto coche diesel y ocurreel evento robar, el coche no estará accesible en el taller porque lo han robado,aunque al coche siempre se le podrá cambiar_aceite. La solución de orto-gonalidad propuesta permite el cambio de aceite lo que permitirá representaradecuadamente el comportamiento exigido por el problema.

Éste es un caso claro en el que la naturaleza del problema puede hacer adecua-da o no la solución de ortogonalidad. En esta aproximación se tomará por defectoque existe ortogonalidad entre los DTE de subclases en distintas particiones. Si elmodelador detecta que debe especi…carse una dependencia entre estados de distintosDTE correspondientes a subclases que constituyen una especie, entonces se tendráque modelar un DTE “unión” de los DTE de las subclases a las que puede pertenecerel objeto simultáneamente. Sobre este DTE se añadirán/eliminarán13 las transicionesnecesarias para modelar el comportamiento esperado. El DTE unión inicial se pue-de obtener de forma automática mediante un proceso de integración de DTE que sepresenta a continuación.

Integración

La unión de los DTE que se propone se llama integración porque las ideas utiliza-das en el proceso de unión son una adaptación restringida de un trabajo de Preuneret al. [185] sobre integración de vistas de comportamiento descritas por Diagramasde Comportamiento. Se basa en la existencia de objetos que son descritos indepen-dientemente por diversos diagramas de transición de estados. Estas descripciones seconsideran vistas de los objetos. La aproximación propone construir un único DTEque integre todas las vistas que se de…nan sobre el objeto (estas vistas serán, en elmodelo presentado, los distintos comportamientos de…nidos en las distintas subcla-ses). La propuesta introduce dos tipos de integración: mediante especialización ymediante generalización. La generalización no es aplicable en este caso porque lo quese obtiene es un DTE intersección de los DTE de las subclases que coincidirá con elde la clase padre. La integración mediante especialización intuitivamente construyeun DTE que posee los estados y transiciones comunes de las subclases junto con losestados y transiciones propios de las subclases.Así pues, dado un DTE D1 de una subclase SPartiC (subclase de la partición i de

la clase C) y un DTE D2 de una subclase SPartjC (subclase de la partición j de laclase C) donde i 6= j, y siendo D el DTE de la especie SPartiC ¤ SPartjC , entoncesD = D1 [ D2, siendo la unión un proceso de integración de los DTE medianteespecialización, en el que D se construirá de la siguiente forma:

² ED = ED1 [ ED2 , donde ED es el conjunto de estados posibles de D, y ED1yED2 los de D1 y D2 respectivamente, y

13Manteniendo la compatibilidad de comportamiento.


S

U

T

vender

encontrar

accidentar

fabricar destruir

destruir

V

cambiar_filtro

terminar_mantenimientorobar

reparar

cambiar_aceite

Figura 5.30: DTE que une el DTE de la subclase Coche y el de la subclase Diesel

² TD = TD1[ TD2 , donde TD es el conjunto de transiciones de estado de D, y

TD1y TD2 las de D1 y D2 respectivamente.

Se llama integración mediante especialización porque D, el DTE …nal obtenido,constituye una especialización de D1 y D2 (al ser una extensión que cumple la com-patibilidad de comportamiento). Es importante destacar que aplicar esta solución noimplica a nivel metodológico la construcción de los DTE de las subclases de forma“bottom-up”. El proceso seguido en OO-Method es “top-down”, y el DTE resultantemediante la integración de…ne un posible ciclo de vida que podrían seguir los objetosque pertenecen a la vez a distintas subclases de distintas particiones. En la …gura5.30 se puede ver el DTE que integra los DTE de las …guras 5.19 y 5.21. Éste es elDTE de un coche diesel en el cual se puede observar que se hace explícita la primerainterpretación semántica (desde el punto de vista del taller) en la que si roban uncoche no se le puede cambiar el aceite hasta que lo encuentren.

5.9 Conclusiones

En este capítulo se ha presentado un modelo de relaciones taxonómicas para el lengua-je de especi…cación OASIS y una notación grá…ca para OO-Method. Esta notaciónpermite representar los conceptos introducidos en el modelo taxonómico usando elestándar notacional UML.Se ha presentado cada una de las relaciones taxonómicas que proporciona el modelo

OASIS, introduciendo los conceptos de partición, particiones estáticas, particionesdinámicas y roles. Para cada una de las relaciones se han detallado sus propiedadesmás relevantes, se ha estudiado cómo se pueden heredar éstas y cómo se especi…can


en OASIS. Para cada tipo de relación se ha propuesto una representación grá…caespecí…ca en el Diagrama de Clases, según la notación UML. Las dos propuestas deespecialización dinámica que presenta el modelo (particiones dinámicas y roles) se hananalizado detectándose las diversas características que las diferencian. Para …nalizarla presentación del modelo taxonómico, se ha presentado cómo soporta de formanatural la clasi…cación múltiple, pudiendo en algunas situaciones ser equivalente a laespecialización múltiple.Para completar la presentación del modelo taxonómico se ha tratado la especiali-

zación del ciclo de vida de un objeto, especi…cado textualmente en OASIS medianteun proceso, y grá…camente utilizando un Diagrama de Transición de Estados (DTE),que constituye parte de la notación grá…ca que OO-Method posee para construir elModelo Dinámico del sistema. El tratamiento desarrollado proporciona un contenidometodológico a OO-Method, determinando cómo se debe especializar el comporta-miento de la clase padre (modelado en el DTE), de forma que se mantengan laspropiedades exigidas para las relaciones taxonómicas del modelo (compatibilidad decomportamiento en el caso de las particiones y de signatura en los roles).

Capítulo 6

Un Lenguaje de Patrones

En este capítulo se propone una guía para el modelado de las relaciones taxonómicasde OO-Method. Esta guía se presenta en forma de lenguaje de patrones. El len-guaje se basa en las dimensiones de…nidas en el marco y en el modelo taxonómicointroducidos en esta tesis. Dichas dimensiones constituyen patrones estructurales yde comportamiento que deben detectarse en la etapa de modelado conceptual paraespeci…car completamente las clases especializadas. El lenguaje de patrones ofreceuna estructura navegacional determinada por las relaciones y las dependencias exis-tentes entre cada uno de los patrones que componen el lenguaje. Esta estructurasirve para dirigir el proceso de modelado, proporcionando un método de aplicación delos patrones del lenguaje. El método permite identi…car los distintos tipos de espe-cializaciones existentes en un modelo del dominio y sus características estructuralesy de comportamiento, facilitando la aplicación sistemática del lenguaje de patronesen la etapa de modelado. Los patrones y la estructura navegacional inducida por ellenguaje de patrones se utilizarán para proponer un conjunto de preguntas que per-mitirá guiar al analista durante el modelado. En dicha etapa el analista responderá,siguiendo el método propuesto, a una serie de preguntas que le ayudarán a construiruna taxonomía de forma guiada.

6.1 Introducción

Las técnicas basadas en patrones son aplicables a situaciones en las que se pretendedescribir un procedimiento con muchos pasos o una solución a un problema complejo.Utilizando los patrones se factorizará el procedimiento o problema complejo en undeterminado número de problemas relacionados con sus respectivas soluciones. Cadapar problema/solución se representará mediante un patrón que se incluirá en un len-guaje de patrones. Cada patrón resolverá un problema especí…co en el contextodel lenguaje. Además, se garantizará que el patrón podrá utilizarse de forma aisladao en combinación con algún subconjunto de los patrones que forman el lenguaje depatrones.Los lenguajes de patrones, tal y como se ha presentado en el capítulo 2, se están

aplicando cada vez más como herramientas para la de…nición de marcos metodológi-cos que guíen los procesos de modelado y diseño. Siguiendo esta línea de trabajo,

169

170 Capítulo 6. Un Lenguaje de Patrones

se desarrolla a continuación un lenguaje de patrones para ayudar en el proceso demodelado de las relaciones taxonómicas de OO-Method.

6.2 Aplicación del Marco al Modelo Taxonómico

El modelo taxonómico de OASIS lo constituyen un conjunto de patrones conceptua-les con unas características bien de…nidas a nivel estructural y de comportamiento.Una forma de identi…car estas características se puede llevar a cabo situando adecua-damente las características de los distintos tipos de relaciones taxonómicas deOASISen el marco presentado en el capítulo 4. Esto se llevará a cabo estudiando las pro-piedades intrínsecas de las relaciones y dando valor a cada una de las dimensionesdel marco propuesto (seleccionando de entre los valores posibles presentados en elmarco). De esta forma se consigue un marco instanciado que se utilizará como basemetodológica para construir un lenguaje de patrones que ofrezca guías precisas quefaciliten la especi…cación completa de las relaciones taxonómicas en OO-Method.La instanciación del marco para cada tipo de relación se presentará a modo de

resumen en una tabla donde cada una de las dimensiones del marco podrá tener lossiguientes valores:

² IS (Interpretación Semántica): ES si soporta la Especialización Simple y EM sisoporta la Especialización Múltiple.

² HP (Herencia de Propiedades): H si las subclases pueden tener propiedadesHeredadas, M si pueden tener propiedades Modi…cadas con la restricción decompatibilidad de comportamiento (CC ) o signatura (CS ) respecto a la clasepadre y N si pueden tener propiedades Nuevas.

² V (Visibilidad): Sp si la clase especializada puede tener acceso a las propie-dades de la superclase, y Sb si la clase especializada puede tener acceso a laspropiedades de las subclases de su mismo nivel en la jerarquía.

² RE (Restricciones Estáticas): D si la especialización de una clase en un conjuntode subclases es Disjunta, ND si No es Disjunta, C si es Completa, e I si esIncompleta.

² CT (Características Temporales): E si la especialización es Estática, y D si esDinámica.

² RD (Restricciones Dinámicas): EvH si se puede producir una Evolución Hori-zontal, ExV si se puede producir una Extensión Vertical.

² DE (Dependencia Existencial): Sp si la subclase especializada depende existen-cialmente de su superclase, y Sb si depende existencialmente de una subclase desu mismo nivel en la jerarquía.

² M (Multiplicidad): La multiplicidad de la subclase a la superclase siempre será1, por lo que al ser …jo, en esta dimensión se incluirá la multiplicidad de lasuperclase hacia la subclase que podrá tener los siguientes valores: 1, [0,1] y[0,N].

6.2. Aplicación del Marco al Modelo Taxonómico 171

² I (Identidad): C si el identi…cador de la subclase es el mismo que el de lasuperclase (compartido), y P si se le permite a la subclase que tenga su propioidenti…cador.

² CE (Criterio de Especialización): DE si el criterio de especialización es Depen-diente del Estado, y DV si el criterio es Dependiente de la Vida del objeto.

A continuación se presenta la caracterización de cada una de las relaciones ta-xonómicas del modelo OASIS aplicando el marco propuesto. En la tabla 6.1 sepresentan los valores de cada una de las dimensiones del marco propuesto para cadarelación taxonómica presente en OO-Method.

6.2.1 Especialización Estática

La especialización estática del modelo OASIS soporta la especialización simple (IS=ES ). Las propiedades de la subclase pueden ser heredadas, modi…cadas (ya que sepuede extender el comportamiento siempre que sea de forma compatible con el de laclase padre) y nuevas (HP=H,M,N ). En la subclase, para las propiedades modi…cadasse exige compatibilidad de comportamiento respetando el principio de reemplazabi-lidad (CC ). Una subclase estática tiene acceso a sus propiedades emergentes y a lasde su superclase (V=Sp). Las especializaciones estáticas deben formar parte de unapartición estática que deberá ser disjunta y completa (RE=D,C ). Una especializaciónestática como su nombre indica será estática (CT=E) y no se le podrán aplicar restric-ciones dinámicas (RD=No). Un objeto de una especialización estática dependerá de laexistencia de un objeto de la superclase (DE=Sp), y un objeto de la superclase podráespecializarse en 0 o 1 objetos de la subclase (M=0,1 ). En la especialización estáticael objeto especializado comparte el identi…cador de objetos con la superclase (I=C ).En cuanto a los criterios de especialización utilizados para especializar estáticamenteuna clase, se utilizan criterios dependientes del estado (CE=DE).

6.2.2 Especialización Dinámica

La especialización dinámica del modeloOASIS posee la mayoría de las característicasde la especialización estática, aunque cambia en su caracterización temporal. Comosu nombre indica será dinámica (CT=D). Los cambios de clase a través del tiempose hacen, entre subclases del mismo nivel en la jerarquía y de la misma partición,mediante un proceso de evolución horizontal (RD=EvH ), por lo que la creación de unobjeto en una subclase depende de la existencia de un objeto en una subclase origen(para que pueda producirse la migración). En cuanto a los criterios de especializa-ción utilizados para especializar dinámicamente una clase, se utilizan indistintamentecriterios dependientes del estado y de la vida del objeto (CE=DE, DV ).

6.2.3 Roles

Los roles del modelo OASIS soportan la especialización simple (IS=ES ). Las pro-piedades de la subclase de rol pueden ser heredadas, modi…cadas (ya que se puedeextender el comportamiento sin necesidad de que sea compatible con el de la clase


Relación IS HP V RE CT RD M DE I CE

E. Estáticas ES H,M (CC),N Sp D,C E No 0,1 Sp C DE

E. Dinámicas ES H,M (CC),N Sp D,C D EvH 0,1 Sp,Sb C DE,DV

Roles ES H,M (CS),N Sp D,I D ExV 0,N Sp P DV

Tabla 6.1: Características de las Relaciones Taxonómicas según el Marco Multidi-mensional propuesto

padre) y nuevas (HC=H,M,N ). En la subclase de rol se exige compatibilidad de sig-natura (CS). Una subclase de rol tiene acceso a sus propiedades emergentes y a lasde su superclase (V=Sp). Las subclases de rol deben formar parte de grupos de rolque deben ser disjuntos e incompletos (RE=D,I ). Una subclase de rol será dinámica(CT=D). La superclase (o clase jugadora) a través del tiempo puede jugar distintosroles mediante un proceso de extensión vertical (RD=ExV ) en el que el objeto jugadorcrea un rol de sí mismo (sin producirse migración, solamente se crea un nuevo rol),por lo que la creación de un rol depende de la existencia de un objeto en la clasejugadora (DE=Sp), y un objeto jugador podrá tomar entre 0 y N roles (M=0,N ). Enuna subclase de rol, el rol posee un identi…cador propio distinto al que posee el objetode la clase jugadora (I=P). En cuanto a los criterios de especialización utilizados paracrear roles, se utilizan criterios dependientes de la vida anterior, especi…cados a travésde eventos creadores y destructores del rol (CE=DV ).

6.3 Un Lenguaje de Patrones para el Modelado deRelaciones Taxonómicas

Analizando el resultado de aplicar el marco conceptual a las relaciones taxonómicasque presenta el modelo OASIS, se detectan una serie de patrones estructurales y decomportamiento que deben identi…carse y especi…carse durante la etapa de modeladoconceptual:

² La Interpretación Semántica (IS) en este modelo taxonómico es siempre la es-pecialización simple (ES).

² La Herencia de Propiedades (HP) puede llevarse a cabo de diversas formas (H,M(CC o CS),N).

² Se pueden de…nir distintas Restricciones Estáticas (D,C,I) sobre la especializa-ción.

² La especialización según sus Características Temporales (CT) puede ser de dostipos (D,E).

² Se pueden de…nir dos tipos (EvH, ExV) de Restricciones Dinámicas (RD) sobreespecializaciones dinámicas.

² Se pueden de…nir dos tipos (Sp,Sb) de Dependencia Existencial (DE).² Se pueden de…nir dos tipos ([0,1],[0,N]) deMultiplicidad (M) entre la clase padrey la clase hija.

6.3. Un Lenguaje de Patrones para el Modelado de Relaciones Taxonómicas 173

² La relación de Identidad (I) de un objeto de la subclase respecto a uno de laclase padre puede ser de dos maneras (C,P).

² Los Criterios de Especialización (CE) utilizados para especializar subclases pue-den ser de dos tipos (DE,DV).

La Visibilidad (V) no se ha incluido en los patrones anteriores por ser una propie-dad derivable a partir del tipo de relación modelada.A partir de estos patrones detectados se puede construir un lenguaje de patrones

que ayude en el proceso de modelado de las relaciones taxonómicas. Los patronesque constituyan dicho lenguaje proporcionarán soluciones al problema de cómo iden-ti…car y especi…car cada una de las propiedades que caracterizan a una determinadarelación taxonómica del modelo OASIS. En los siguientes subapartados se presentael lenguaje de patrones siguiendo la estructura propuesta por Meszaros en [144].

6.3.1 Motivación

El lenguaje de patrones surge con la intención de ayudar a la identi…cación y espe-ci…cación de cada una de las relaciones taxonómicas de OO-Method. Cada uno delos patrones permitirá determinar de forma precisa las características esenciales queposeen las subclases participantes en dicha relación. Con la información recopilada seinstanciarán las dimensiones del marco conceptual propuesto, por lo que la relacióntaxonómica detectada se podrá identi…car comparando los valores obtenidos con losde la tabla 6.1. De esta forma la relación podrá catalogarse como una especializaciónestática, dinámica o un rol.

6.3.2 Estructura del Lenguaje de Patrones

Según se presenta en [144], un patrón debe contener los siguientes elementos de maneraobligatoria:

² Nombre del Patrón: Un nombre para identi…car el patrón.² Contexto: Las circunstancias en las cuales se va a resolver el problema. Sepresenta normalmente mediante una situación. A veces se describe en términosde los patrones que se han utilizado anteriormente.

² Problema: El problema especí…co a resolver. Debe ser independiente del con-texto.

² Restricciones: Consideraciones que se deben tener en cuenta cuando se eligeuna solución al problema.

² Solución: Se detalla la solución propuesta. La adecuación de la solución pro-puesta se ve afectada por el contexto en el que el problema ocurre y tiene encuenta las consideraciones presentes en la sección Restricciones.

Y además una serie de elementos opcionales de los cuales se ha elegido:

² Ejemplos: Ejemplos concretos que ilustran la aplicación del patrón.


² Patrones Relacionados: Otros patrones que pueden ser de interés para ellector. Entre ellos se incluyen: (1) otras soluciones al mismo problema, (2)variaciones más generales del patrón, (3) patrones que resuelven algunos pro-blemas en el contexto y la solución propuesta por el patrón.

El Nombre del Patrón se incluirá de forma implícita al nombrar la sección dondese presenta cada patrón. En la sección de Ejemplos de los patrones se utilizará laespeci…cación del ejemplo presente en el apéndice A. En este caso en la sección Pa-trones Relacionados se incluirá aquellos patrones del lenguaje que están relacionadosdirectamente con el patrón en cuestión porque resuelven algunos problemas presentesen su solución o contexto, o porque dependen del patrón.Para darle al lenguaje de patrones una identidad propia, se le debe proporcionar

un nombre por el cual será conocido y podrá referenciarse. El lenguaje de patronespropuesto se llamará “Modelado de Relaciones Taxonómicas”, y su estructura se pre-senta en la …gura 6.1 siguiendo la notación propuesta por [144]. En dicha notaciónlos patrones que constituyen el lenguaje se representan como cajas y mediante ‡echasse dibujan las dependencias existentes entre ellos. Esta estructura se ha de…nido apartir de las dimensiones del marco multidimensional propuesto y de las dependenciasexistentes entre ellas.El lenguaje de patrones está constituido por el conjunto de patrones (representados

como cajas) que se puede ver en la …gura 6.1. En dicha …gura se presenta el patrónDeterminar Relaciones Taxonómicas que constituye el punto de entrada al lenguaje.Dicho patrón está constituido por un conjunto de patrones (Determinar Propiedadesde la Subclase (a su vez compuesto por el patrón Especi…car Comportamiento de laSubclase), Determinar Criterio de Especialización, Determinar Características Tempora-les, Determinar Restricciones Dinámicas, Determinar Dependencia Existencial, DeterminarRestricciones Estáticas, Determinar Multiplicidad, Determinar Relación de Identidad) cu-ya aplicación permite identi…car y especi…car las relaciones taxonómicas de una clasedeterminada. Los patrones están relacionados entre ellos por medio de relacionesde dependencia representadas mediante ‡echas. La dirección de las ‡echas implicaque existe una dependencia en el sentido de la ‡echa, así por ejemplo se observaque el patrón Determinar Relación de Identidad depende de Determinar Multiplicidad.Las dependencias pueden ser bidireccionales como lo es la que existe entre los pa-trones Determinar Multiplicidad y Determinar Restricciones Estáticas, debido a que lamultiplicidad puede implicar una restricción estática determinada y viceversa. Lasdependencias también son transitivas como la existente entre Determinar Restriccio-nes Dinámicas y Determinar Criterio de Especialización, a través del patrón DeterminarCaracterísticas Temporales.

6.3.3 Desarrollo del Lenguaje. Descripción de los Patrones

En este apartado se presentan cada uno de los patrones que constituyen el lenguajede patrones “Modelado de Relaciones Taxonómicas”. Los patrones se relacionaránunos con otros utilizando referencias legibles en las secciones Solución y PatronesRelacionados1 .

1No se incluyen los patrones relacionados de forma transitiva.


Determinar Relación deIdentidad

Determinar DependenciaExistencial

Determinar Multiplicidad

Determinar RestriccionesDinámicas

Determinar Criterio deEspecialización

Determinar CaracterísticasTemporales

Determinar RestriccionesEstáticas

Especificar Comportamientode la Subclase

Determinar RelacionesTaxonómicas

Determinar Propiedades de la Subclase

Figura 6.1: Lenguaje de Patrones


Patrón Determinar Relaciones Taxonómicas

Problema: Durante el proceso de construcción de un esquema conceptual OO sedesea de…nir relaciones taxonómicas entre una clase y un conjunto de subclases quepueden existir o no en el esquema.

Contexto: Se detecta que existe una clase que puede dividirse en diversas categoríassegún un determinado criterio o que existen objetos del sistema que necesitan: co-nocer información similar, realizar operaciones similares, jugar los mismos roles en elsistema, o representar a un objeto en un estado particular. Se conocen las propiedadesy el comportamiento de la clase candidata a ser especializada.

Restricciones: Cada una de las subclases que se de…nan debe introducir alguna pro-piedad adicional que no posea su superclase, cumpliendo los principios de no redun-dancia y economía cognitiva, de forma que aporte más información sobre los objetospertenecientes a dicha subclase que la categorización en sí proporciona. La divisiónde la clase en subclases especializadas debe basarse en un criterio bien de…nido.

Solución: La especialización (relación taxonómica que se pretende especi…car) partede la existencia de una clase más general y a partir de ella se de…ne un conjunto declases más concretas que incluyen las propiedades de la clase general, además de ciertaspropiedades especí…cas. Se identi…carán y/o crearán clases concretas (subclases) sise detecta que la clase puede dividirse en subclases, siempre que se cumplan lasrestricciones y se esté en el contexto enunciado en este patrón. Para caracterizaradecuadamente la relación taxonómica se aplicarán los patrones:

² Determinar Propiedades de la Subclase.² Determinar Restricciones Estáticas.² Determinar Características Temporales.² Determinar Restricciones Dinámicas que se aplicará sobre subclases dinámicas.² Determinar Dependencia Existencial.² Determinar Multiplicidad.² Determinar Relación de Identidad.² Determinar Criterio de Especialización que especializa la clase en subclases.Es importante destacar que esta presentación de los patrones no pretende inducir

un orden especí…co en su aplicación, aunque cuando se apliquen, se deberán teneren cuenta las dependencias existentes entre ellos. Esto es así para que cada usuariodel lenguaje de patrones proponga un método propio de aplicación de los patronesadaptado a su enfoque de modelado.El resultado de aplicar este patrón y sus patrones componentes permitirá carac-

terizar las relaciones taxonómicas que se de…nen sobre una determinada clase. Com-parando las características detectadas con los valores de la tabla 6.1 se determinarási las relaciones taxonómicas son especializaciones estáticas, dinámicas o roles.

Ejemplos: La subclase Empleado es una especialización de Persona y cumple lasrestricciones exigidas porque posee propiedades adicionales como salario, puesto


de trabajo, etc. Aplicando los distintos patrones se determinará que Empleado esun rol de Persona, y si se aplica a su vez este patrón a Empleado, se detectará que larelación existente con las subclases Vendedor y Responsable es una especializacióndinámica.

Patrones Relacionados: Este patrón es el punto de entrada a la especi…caciónde relaciones taxonómicas. Los patrones relacionados son Determinar Propiedades dela Subclase, Determinar Restricciones Estáticas, Determinar Características Temporales,Determinar Restricciones Dinámicas, Determinar Dependencia Existencial, DeterminarMultiplicidad, Determinar Relación de Identidad y Determinar Criterio de Especialización.El presente patrón está relacionado con estos patrones porque necesita de su aplicaciónpara determinar adecuadamente las relaciones taxonómicas de…nidas sobre una clase.

Patrón Determinar Propiedades de la Subclase

Problema: Se desea especi…car las propiedades de una subclase especializada de unadeterminada clase padre.

Contexto: Se puede determinar qué propiedades debe poseer la subclase para repre-sentar adecuadamente la abstracción en el modelo del dominio. Se podrán identi…carlas necesidades de almacenamiento de información y las operaciones que debe ofrecerun objeto de la subclase.

Restricciones: Las propiedades que se pueden de…nir en una subclase deben ser deltipo nuevas y/o modi…cadas respetando la compatibilidad de signatura.

Solución: Se especi…cará una propiedad nueva cuando se detecte una característica(atributo u operación (eventos en el modelo OASIS)) propia de la subclase que noposee la superclase. Se especi…cará una propiedad modi…cada si se detecta que existeuna propiedad en la superclase que la subclase debe re…nar porque debe elaborarsemás en la clase especializada. En la aproximación presentada sólo se permite mo-di…car eventos cuando se desea extender o restringir el comportamiento de…nido enla superclase. La especi…cación del comportamiento asociado a los eventos se pre-senta en el patrón Especi…car Comportamiento de la Subclase; dicho patrón como sepuede ver en la …gura 6.1 se considera un patrón componente de éste, por estar elcomportamiento “ligado” a los eventos.

Ejemplos: La clase Empleado como subclase de Persona tiene propiedades nuevascomo salario y puesto de trabajo. El evento subir_sueldo de Empleado tiene comoefecto en el empleado el incrementar su sueldo_base en una determinada cantidad(incremento), y en la subclase Vendedor extiende su comportamiento inicializandoademás su bonificacion a 0.

Patrones Relacionados: El patrón Especi…car Comportamiento de la Subclase, porser un componente de éste.

Patrón Determinar Restricciones Estáticas

Problema: Se deben de…nir una serie de restricciones sobre la población de lassubclases participantes y la de la superclase en una relación taxonómica en un instantedeterminado.


Contexto: Se puede determinar qué instancias se especializan en qué subclases encada momento de su existencia ante un criterio de especialización especí…co.Restricciones: Cualquier relación taxonómica de una clase con un conjunto de sub-clases será siempre disjunta. Para de…nir las restricciones estáticas serán necesariasal menos dos subclases.Solución: Si un objeto de una superclase es en todo instante instancia de una subclaseen el conjunto de subclases especializadas según el mismo criterio de especialización,entonces se está ante una especialización completa, en caso contrario será incompleta(o no exhaustiva). Una especialización es disjunta si un objeto de la superclase enun instante cualquiera es instancia de una única subclase en el conjunto de subclasesespecializadas, en caso contrario será solapada.Ejemplos: Las especializaciones de la clase Persona en Mujer y Hombre, y deEmpleado en Vendedor y Responsable son completas y disjuntas porque un obje-to de la superclase siempre es instancia de una de las subclases y, además no puedeser instancia de dos o más de las subclases a la vez. Las subclases de rol Estudiantey Empleado son incompletas porque un objeto de la superclase no es necesariamentesiempre instancia de Empleado o Estudiante.Patrones Relacionados: Está relacionado el patrón Determinar Criterio de Espe-cialización porque el criterio de especialización elegido puede inducir una restricciónestática determinada. El patrón Determinar Multiplicidad está relacionado con estepatrón porque una determinada multiplicidad puede implicar el cumplimiento o node una restricción estática asociada a la relación taxonómica.

Patrón Determinar Características Temporales

Problema: Se debe caracterizar el comportamiento de los objetos de las subclasesde una relación taxonómica a través del tiempo.Contexto: Se conocen las propiedades temporales de los objetos de las subclases, yse puede determinar si un objeto de una clase puede cambiar de clase o no con el pasodel tiempo.Restricciones: Las relaciones taxonómicas no pueden caracterizarse como estáticasy dinámicas al mismo tiempo.Solución: La clasi…cación de los objetos en una taxonomía puede ser de dos tipos:estática y dinámica. En una subclase estática los objetos se mantienen en dichasubclase durante toda su existencia y no pueden cambiar de subclase con el pasodel tiempo. En una subclase dinámica los objetos de una subclase pueden crearsey destruirse con el paso del tiempo sin dejar de existir en la superclase. En unasubclase dinámica se determinará cómo se puede producir en el tiempo esta creacióny destrucción de objetos (ver patrón Determinar Restricciones Dinámicas).Ejemplos: En la …gura 6.11 se pueden ver las clases Persona y Empleado. La primeraposee dos subclases estáticas porque cuando se crea un objeto de la clase Persona, éstees Hombre o Mujer y se mantiene en dicha subclase hasta el …n de su existencia. Sinembargo, en la segunda son dinámicas porque la población de la subclase Responsablepuede aumentar sin necesidad de que aumente la población de Empleado, se puedencrear responsables haciendo que un Vendedor pase a ser Responsable destruyendo elobjeto de Vendedor.


Patrones Relacionados: Está relacionado con el patrón Determinar Criterio de Es-pecialización porque las características temporales pueden depender del criterio deespecialización elegido.

Patrón Determinar Restricciones Dinámicas

Problema: Se debe identi…car una serie de restricciones sobre la población de lassubclases y la de la superclase que participen en una relación taxonómica de natura-leza dinámica. Estas restricciones permitirán caracterizar el comportamiento de losobjetos de las subclases a través del tiempo.

Contexto: Se puede identi…car las posibles restricciones dinámicas que puedan de…-nirse en el contexto de una relación taxonómica, determinando de forma precisa cuáles el patrón de comportamiento que siguen los objetos que evolucionan cambiando desubclase o extendiendo su comportamiento a través del tiempo.

Restricciones: No pueden de…nirse restricciones dinámicas en especializaciones es-táticas. La migración se realiza entre objetos que comparten la misma identidad. Lamigración o la extensión se realizará entre clases que deben estar relacionadas por re-laciones de especialización o rol, o participar en el mismo nivel de la jerarquía dentrode un conjunto de subclases especializadas siguiendo el mismo criterio.

Solución: Las restricciones dinámicas especi…can cómo “cambian” de subclase losobjetos, y cómo se puede restringir la secuencia de transiciones entre clases. Estasrestricciones de…nen una relación de transición que introduce dos tipos de transicio-nes: la evolución (horizontal) y la extensión (vertical). En las situaciones en las queun conjunto de subclases dinámicas del mismo nivel jerárquico modelen los distintosestados o fases por los que pasa un objeto, se determinará que existe una evoluciónhorizontal como patrón de comportamiento especí…co. Cuando un objeto de una clasedeterminada se instancia en una subclase de ésta sin dejar de existir en la clase origense identi…ca un patrón de comportamiento similar a la extensión vertical.

Ejemplos: Una Persona durante su existencia puede ser Estudiante y Empleado; esimportante destacar que se produce una extensión vertical ya que si deja de estudiarno tiene porqué pasar a Empleado, pero de Persona si que puede pasar a estudiar y/o aemplearse. Un objeto de la clase Empleado especializado en las subclases Vendedor yResponsable evoluciona de manera horizontal ; inicialmente es instancia de la subclaseVendedor, y después puede pasar a Responsable. De esta subclase puede pasar aVendedor si se le rebaja del cargo.

Patrones Relacionados: El patrón está relacionado con Determinar CaracterísticasTemporales, porque para poder aplicarlo es necesario que la relación taxonómica seadinámica.

Patrón Determinar Dependencia Existencial

Problema: Se desea determinar si en las relaciones taxonómicas, la existencia dealguno de los objetos de las clases participantes (clase padre, hija y hermana en elmismo nivel jerárquico) depende de la existencia de un objeto en otra clase y viceversa.


Contexto: Dadas dos clases relacionadas a través de una relación taxonómica sepodrá determinar en qué grado la existencia de una instancia de una clase dependede la otra.Restricciones: Siempre existe una dependencia existencial de la subclase con lasuperclase por la naturaleza intrínseca de las relaciones taxonómicas. La dependenciaexistencial entre subclases en el mismo nivel de la jerarquía se de…ne entre objetosque comparten la misma identidad.

Solución: En una relación taxonómica la existencia de un objeto de la subclasedepende de la existencia de un objeto de su superclase (en el caso de las especializa-ciones) y la existencia de un objeto de la superclase depende de la existencia de unobjeto de la subclase (en el caso de la generalización). Las dependencias existentesentre subclases del mismo nivel jerárquico se dan en especializaciones cuya restriccióndinámica es la evolución horizontal (ver patrón De…nir Restricciones Dinámicas). Es-ta dependencia viene determinada por las posibles transiciones entre subclases de lapartición (ver patrón Determinar Criterio de Especialización).

Ejemplos: La existencia de un objeto de la clase Mujer u Hombre depende de laexistencia de una Persona. La existencia de un objeto de la subclase Responsabledepende de que dicho objeto haya existido anteriormente en la clase Vendedor yademás de que dicho objeto pertenezca a la clase Empleado.

Patrones Relacionados: Este patrón está relacionado con De…nir Multiplicidad yaque la multiplicidad implica una determinada dependencia existencial de la subclaserespecto a la clase padre. Está relacionado con Determinar Restricciones Dinámicasporque cuando se trata con subclases dinámicas con extensión vertical, se detectandependencias entre subclases del mismo nivel jerárquico, y cuando existe evoluciónhorizontal, se detectan dependencias de la subclase respecto a su superclase.

Patrón Determinar Multiplicidad

Problema: Se desea determinar si en las relaciones de especialización o rol en dondeparticipan superclases y subclases, existen restricciones en cuanto a la multiplicidadasociada con la relación entre la superclase y sus subclases.

Contexto: Se puede identi…car algún tipo de restricción de multiplicidad entre sub-clases y sus superclases participantes en una relación taxonómica.

Restricciones: La multiplicidad de la subclase respecto a la superclase siempre será1. Sólo las subclases dinámicas con extensión horizontal podrán tener una multiplici-dad mayor que 1.

Solución: En el modelo taxonómico de OASIS una instancia de una subclase siem-pre estará relacionada con una y sólo una instancia de su superclase (multiplicidad1). Una instancia de una superclase podrá estar relacionada con:

² cero o una instancia de una de sus subclases (multiplicidad [0; 1]).² cero o más instancias de una de sus subclases (multiplicidad [0; N ]).

Ejemplos: Una Persona puede estudiar como máximo tres carreras en una mismauniversidad por lo que la multiplicidad entre la clase Persona y Estudiante será


[0; 3]. Sin embargo, una Persona será Hombre o Mujer una única vez por lo que lamultiplicidad será [0; 1], lo mismo ocurre con la relación existente entre Empleado ylas subclases Vendedor y Responsable.

Patrones Relacionados: Este patrón está relacionado con Determinar DependenciaExistencial porque la dependencia existencial de la subclase hacia la superclase implicauna multiplicidad 1 hacia la clase padre (esta situación siempre se da en el modelotaxonómico introducido). También está relacionado con Determinar Restricciones Es-táticas porque las restricciones estáticas limitan la multiplicidad posible (si es disjuntarequiere una multiplicidad [0; 1] de la superclase a la subclase, si es completa requiereal menos una multiplicidad 1 de la subclase hacia la clase padre).

Patrón Determinar Relación de Identidad

Problema: Se desea determinar cuál va a ser la relación entre la identidad de losobjetos de una clase y la de los de una subclase de ésta, así como la relación existenteentre los mecanismos de identi…cación a utilizar.

Contexto: Se conoce cuál es la multiplicidad existente entre una clase y su subclase.Se es capaz de determinar cuál es el mecanismo de identi…cación más adecuado parauna subclase y qué relación tiene con el mecanismo de la superclase.

Restricciones: El mecanismo de identi…cación debe cumplir los principios de unici-dad y persistencia.

Solución: Los objetos de una subclase heredarán el identi…cador de la superclasepor lo que compartirán su oid. Esta relación de identidad limita a uno el número deobjetos de la subclase en la que se puede especializar un objeto para poder cumplir larestricción de unicidad. Las subclases con multiplicidad mayor que uno (ver Determi-nar Multiplicidad) deben utilizar un identi…cador propio, distinto al de la superclase.A nivel de especi…cación, las subclases que compartan el identi…cador de su clasepadre podrán utilizar el mecanismo de identi…cación de su clase padre (dependenciade identi…cación). Las subclases que posean su identi…cador propio utilizarán un me-canismo de identi…cación distinto al de su clase padre. Esto se podrá llevar a cabode dos formas (1) de…niendo un mecanismo de identi…cación nuevo en la subclaseque estará constituido por el mecanismo heredado y alguno nuevo (dependencia deidenti…cación), o (2) de…niendo un mecanismo de identi…cación completamente nuevoe independiente del de la superclase (independencia de identi…cación).

Ejemplos: Una clase Persona puede ser Estudiante en 3 carreras universitarias co-mo máximo. Con esta información se deduce que la clase Estudiante debe poseer unidenti…cador propio. En este caso un objeto de la clase Persona tendrá como meca-nismo de identi…cación su dni, y Estudiante como subclase de Persona podrá tenercomo mecanismo de identi…cación un código propio de la Universidad (independenciade identi…cación) o podrá componer el dni con un código especí…co del Centro dondeestudia (dependencia de identi…cación).

Patrones Relacionados: Está relacionado con Determinar Multiplicidad porque sila multiplicidad máxima es N , será necesario que la subclase posea un identi…cadorpropio.


Patrón Determinar Criterio de Especialización

Problema: Se desea especializar una clase en un conjunto de subclases (una o másde una) en el proceso de construcción de un esquema conceptual orientado a objetos,y se debe determinar el criterio de especialización en el cuál se basa la especializaciónde la clase en subclases.

Contexto: Se conocen las propiedades (atributos y eventos) que pueden causar laespecialización de un objeto.

Restricciones: El criterio de especialización a utilizar deberá cumplir las siguientespropiedades: será no redundante, claro, no ambiguo, simple y uniforme.

Solución: La elección del criterio de especialización está directamente ligada con lascaracterísticas temporales de la especialización (ver Determinar Características Tem-porales). Se elegirá un criterio de especialización estático si la división en subclasesdepende de características constantes de los objetos, por lo que su evaluación siempredará el mismo resultado. Su especi…cación se hace a través de fórmulas bien forma-das de…nidas sobre atributos constantes de la clase padre. Se elegirá un criterio deespecialización dinámico si la división en subclases depende de propiedades cuyaevaluación depende del tiempo (garantizando que al menos en dos estados distintosde un objeto el criterio se evalúa de forma distinta) o de la ocurrencia de ciertasacciones en el tiempo, de esta manera el objeto podrá pertenecer de forma temporala alguna de las subclases. La utilización de criterios dinámicos sirve para especi…carla evolución o extensión de objetos (ver patrón Determinar Restricciones Dinámicas).Los criterios dinámicos pueden ser:

1. dependientes del estado: se evalúan sobre el estado actual del objeto yse especi…can mediante fbf de…nidas sobre atributos variables que se evalúansobre el estado actual del objeto. En las particiones dinámicas determinan laevolución horizontal o migración de los objetos de las subclases. A estos criteriostambién se les llama restricciones de migración. Las fbf que de…nen el criteriose cumplirán para una subclase a la vez (disyunción), y siempre para algunasubclase (completitud) (ver patrón Determinar Restricciones Estáticas).

2. dependientes de la ocurrencia de un evento: se evalúan teniendo en cuentala ocurrencia de eventos para llevar a cabo la evolución horizontal o la exten-sión vertical a una determinada subclase (ver patrón Determinar RestriccionesDinámicas). La evolución horizontal de…ne un conjunto de transiciones admi-sibles entre subclases que se especi…carán mediante eventos que producen laevolución a otra subclase del mismo nivel jerárquico. Esta evolución se modelaa nivel grá…co utilizando diagramas de transición entre estados en los cuales loseventos etiquetan las transiciones entre los estados del diagrama. Dichos esta-dos se corresponden con cada una de las subclases que determinan los posiblesestados por los cuáles puede migrar el objeto, modelando así el proceso de mi-gración. En la extensión vertical existirá un evento (de creación) pertenecientea la superclase que hará que el objeto se instancie en la subclase, y un evento(de destrucción) perteneciente a la subclase que se encargará de destruir dichoobjeto en la subclase (su existencia no es obligatoria).


Ejemplos: Las personas que pertenecen a la subclase Mujer se caracterizan porcumplir la condición sexo=”M” y los Hombres por la condición sexo=”H” (criteriodependiente del estado). La dinamicidad del criterio no está asociada a los atributosvariables en sí; será dinámico si se puede garantizar al menos dos estados en los queel criterio se evalúe de forma distinta. En el caso de la clase Persona y su subclaseEstudiante, los eventos matricular y terminar determinan el comienzo y el …naldel período durante el cual el objeto de la clase Persona juega el papel de Estudiante(criterio dependiente de la ocurrencia de un evento). Lo mismo ocurre con Empleadoy los eventos contratar y despedir. La creación de instancias de las subclasesVendedor y Responsable también se realiza a través de la ocurrencia de eventos, unEmpleado pasa a Vendedor cuando se le contrata o cuando siendo Responsable sele rebaja, un Vendedor pasa a Responsable cuando se le promociona.

Patrones Relacionados: Este patrón está relacionado con Determinar CaracterísticasTemporales porque el tipo de criterio y su especi…cación depende de las característi-cas temporales de la relación taxonómica. También está relacionado con el patrónDeterminar Restricciones Estáticas porque los criterios seleccionados deben cumplir lasrestricciones estáticas que se hayan identi…cado.

El último patrón del lenguaje constituye un componente del patrón DeterminarPropiedades de la Subclase (ver …gura 6.1). Para aplicar adecuadamente este patrónse necesita identi…car el tipo de relación taxonómica que se está modelando. De estaforma estarán perfectamente delimitadas las modi…caciones que se pueden introduciren la especi…cación del comportamiento asociado a los eventos en las subclases.

Patrón Especi…car Comportamiento de la Subclase

Problema: Se desea especi…car el comportamiento de una subclase existente en unesquema conceptual OO-Method.

Contexto: Se puede identi…car y especi…car detalladamente el comportamiento dela subclase. Se conocen las precondiciones, evaluaciones, diagramas de transición deestado, restricciones de integridad y disparos, de acuerdo con el modelo de ejecuciónque propone OO-Method.

Restricciones: El tipo de modi…caciones que se pueden introducir en la especi…cacióndel comportamiento de una subclase depende del tipo de relación taxonómica. Sila subclase forma parte de una partición (estática o dinámica) deberá cumplirse elprincipio de reemplazabilidad (en el caso de los diagramas de transición de estado) y lacompatibilidad de comportamiento respecto a la superclase. Si la subclase forma partede un grupo de rol sólo se exige el cumplimiento de la compatibilidad de signatura.

Solución: El comportamiento de un objeto viene determinado por las acciones quese llevan a cabo en la ejecución de un evento. Dicha ejecución sigue una estrategiade ejecución propuesta por OO-Method. Esta estrategia está constituida por una se-cuencia de pasos. Estos pasos son: la comprobación de la existencia de una transiciónválida para dicho evento en el diagrama que modela el ciclo de vida, la comprobacióndel cumplimiento de sus precondiciones asociadas al evento, el cambio de estado de-bido al efecto del evento sobre el estado del objeto, la comprobación de la integridaddel nuevo estado obtenido, y el disparo de eventos si se cumple alguna condición de


disparo. Cada uno de estos pasos se especi…cará en la etapa de modelado siguiendolas pautas propuestas en el capítulo 5.

Ejemplos: Ejemplos detallados de aplicación de este patrón se presentan en el caso deestudio del Apéndice A, incluyendo la especi…cación de precondiciones, evaluaciones,restricciones de integridad y disparos, y la construcción de diagramas de transiciónde estado.

Patrones Relacionados: Ninguno

El lenguaje de patrones debe aplicarse de forma metódica de manera que faciliteel proceso de identi…cación y modelado de las relaciones taxonómicas. Además, debeproporcionarse ayuda para resolver situaciones en las que la aplicación del lenguajeidenti…ca un conjunto de características incompatibles con el modelo taxonómico pre-sentado. Esto se produce porque existen características que no posee ninguna relacióntaxonómica del modelo o porque la combinación de algunas de ellas no está permiti-da. En el siguiente apartado se desarrolla un método que proporciona una solución aestas necesidades aplicando sistemáticamente el lenguaje de patrones.

6.4 Aplicación del Lenguaje a la Etapa deModelado

El lenguaje de patrones se ha desarrollado como una guía de ayuda al modeladode las relaciones taxonómicas del modelo OASIS. Este lenguaje debe utilizarse deforma disciplinada siguiendo una determinada secuencia de pasos que permita aplicaradecuadamente sus patrones en la etapa de modelado.

6.4.1 Método de Aplicación

Los patrones del lenguaje se deben utilizar en la etapa de modelado siguiendo unmétodo de aplicación determinado. El método que se desarrolla propone un proce-so de modelado que tiene en cuenta la naturaleza de las abstracciones que se estánmodelando (en este caso las relaciones taxonómicas del modelo OASIS), y las de-pendencias existentes entre los patrones del lenguaje. El método de aplicación que sepropone es el siguiente:Para cada clase del esquema conceptual susceptible de ser especializada se aplicará

el patrón Determinar Relación Taxonómica obteniendo un conjunto de subclases quela especialicen. Se comprobará que las subclases cumplen los requisitos necesariospara ser consideradas subclases (aportan más información, etc.), a continuación seaplicarán los patrones del lenguaje de la siguiente manera:

1. Aplicar, a cada subclase identi…cada, el patrón Determinar Características Tem-porales para conocer de qué tipo es la especialización (estática o dinámica).Esto determinará (por la relación existente entre patrones) la categoría de loscriterios de especialización (dinámicos o estáticos) que deben especi…carse.

2. Aplicar a las subclases el patrón Determinar Criterio de Especialización, identi…-cando los distintos tipos de criterios de especialización (estáticos y dinámicos),comprobando sus propiedades (ambigüedad,...) y especi…cándolos según la sin-taxis de OASIS.

6.4. Aplicación del Lenguaje a la Etapa de Modelado 185

(a) Si la especialización es dinámica en primer lugar se aplicará el patrón De-terminar Restricciones Dinámicas para conocer la naturaleza de la dinami-cidad. Una vez se ha determinado si existe una evolución horizontal ouna extensión vertical se especi…cará el criterio asociado a cada tipo deespecialización. Si existe una evolución horizontal es porque existe una de-pendencia entre subclases del mismo nivel jerárquico, entonces se aplicaráel patrón Determinar Dependencia Existencial.

3. Seleccionar aquellas subclases que cumplan el mismo criterio y aplicar el patrónDeterminar Restricciones Estáticas para comprobar si:

(a) El criterio sólo se cumple para una clase a la vez (disyunción).

(b) Siempre existe algún objeto que lo cumple (completitud).

4. Aplicar a las subclases dinámicas el patrón Determinar Multiplicidad.

5. Aplicar el patrón Determinar Relación de Identidad para de…nir cómo se va aidenti…car la subclase.

Los patrones Determinar Propiedades de la Subclase y su componente Especi…carComportamiento de la Subclase se podrán aplicar en cualquier paso del proceso de…nidoanteriormente (de forma iterativa), porque en alguno de los pasos podrá ser necesariala introducción de propiedades y comportamiento nuevo y/o rede…nido.Una vez …nalizado este proceso se obtienen los grupos de subclases en los que se ha

especializado la clase seleccionada y las características de las relaciones taxonómicasidenti…cadas. Aplicando la tabla 6.1 se determina si constituyen alguna partición(estática o dinámica) o grupo de rol. En algunas situaciones se pueden dar respuestasincompatibles con respecto al modelo taxonómico presentado. Algunas de ellas puedenser:

² en una subclase con evolución horizontal no se puede dar multiplicidad N , nitener identi…cador propio, ni ser estática, y no se pueden de…nir condicionessobre atributos constantes.

² si el grupo de subclases es incompleto no se puede estar ante una particiónestática o dinámica. Esta situación puede deberse a que: (1) el criterio deespecialización elegido no posee las características deseadas o (2) se está anteun grupo de rol.

² si existe un solapamiento entre subclases, se estará de nuevo ante: (1) un criteriode especialización inadecuado, o (2) la partición o grupo de rol en consideraciónconstituyen en realidad dos grupos de rol o dos particiones.

² en el caso de que la especialización tenga todas las características de una parti-ción y no sea completa, según el modelo taxonómico, se de…nirá obligatoriamenteuna subclase adicional que la convertirá en una partición (completa).

Ante estas situaciones el analista deberá tomar la decisión de modelado adecua-da según las propiedades que desee representar en el esquema conceptual. Una vez


detectado el tipo de relación podrán existir propiedades o especi…caciones de compor-tamiento incompatibles con el tipo de relación modelado que deberán ser revisadas.El método introducido propone un orden de aplicación de los patrones del lengua-

je “recorriendo” los patrones en una dirección de…nida por dicho orden. Este ordenpodrá ser parcialmente modi…cado para cambiar el proceso de modelado. Estos cam-bios se realizarán teniendo en cuenta las relaciones existentes entre los patrones yque el patrón Determinar Relaciones Taxonómicas es el punto de entrada al proceso demodelado. Por ejemplo, de…nir primero la relación de identidad y a continuación lamultiplicidad no es una solución e…ciente porque ante una multiplicidad N , puede sernecesario deshacer el camino recorrido, si no se había incluido un identi…cador nuevoen la subclase.

6.5 De…nición de una Estructura Navegacional Ba-sada en Preguntas

El lenguaje de patrones y el método de aplicación inducen una estructura de nave-gación que permitirá guiar al analista durante el proceso de modelado, para ayudara especi…car los patrones estructurales y de comportamiento de…nidos en el lenguaje.Esta estructura navegacional viene inducida por la semántica de la abstracción y lasdependencias existentes entre las dimensiones presentadas en el marco.Revisando las pautas de…nidas por cada uno de los patrones del lenguaje se pueden

deducir una serie de preguntas independientes del dominio, que ayudarán a identi…caradecuadamente las características especí…cas de las estructuras taxonómicas. Estaspreguntas se aplicarán siguiendo la secuencia de acciones propuestas por el métodode aplicación.

6.5.1 Presentación de las Preguntas

En este subapartado se presentan las preguntas con sus posibles respuestas y se aplicala propuesta al ejemplo del apéndice A. En este ejemplo una persona se especializaen hombre y mujer, y puede jugar los roles de estudiante y empleado; además, unempleado puede ser un vendedor o un responsable de ventas, pudiendo el vendedorpasar a responsable a través de una promoción, y al contrario siendo rebajado elresponsable.

Pregunta 1: Identi…cación de Subclases

La primera pregunta que debe efectuarse tiene como objetivo detectar la existenciade subclases en el modelo, de forma que se determine si una clase puede dividirse enuna o varias subclases.¿Todos los objetos de la clase tienen el mismo carácter o se pueden dividir en

algunas categorías?.

Respuestas Posibles:

² Se pueden dividir en distintas categorías

6.5. De…nición de una Estructura Navegacional Basada en Preguntas 187

Persona

Mujer Hombre Estudiante Empleado

Figura 6.2: Detección de subclases de Persona

Empleado


Figura 6.3: Detección de subclases de Persona

² Tienen el mismo carácter

Si se ha elegido la primera opción se le pedirá al analista que identi…que las sub-clases mediante el siguiente requerimiento:

Identi…que cada una de las subclases (categorías) en las que se puede dividir laclase

Acción: El modelador debe introducir el nombre de cada una de las categorías querepresenta a cada una de las subclases.En el ejemplo del apéndice A se parte inicialmente de una clase Persona. Una

vez realizada la primera pregunta se detectan las siguientes subclases: Hombre, Mujer,Estudiante, Empleado (ver Figura 6.2). Si se aplica la pregunta de forma recursivaa cada subclase, se detecta que la subclase Empleado se puede dividir en Vendedor yResponsable (ver Figura 6.3).

Pregunta 2: Comprobación de la No Redundancia y Economía Cognitiva

Para cada subclase detectada se comprobará, mediante las cuestiones siguientes, sicumple los principios de no redundancia y economía cognitiva.

La subclase, ¿Introduce alguna propiedad adicional (atributo o comportamientonuevo) que no posea su superclase?, ¿Aporta más información sobre los objetos per-


Personadnin ombreapell idosdi recciontelefonoedadsexo

cambiar_direccion()cambiar_telefono()incrementar_edad()revision_medica()crear()el iminar()matricular()contratar()

Mujerhi josestado

quedar_embarazada()dar_a_luz()

HombrefechaIni_ServiciofechaFin_ServicioServicioDuracionMeses

comenzar_Servicio()finalizar_Servicio()sortear()

Estu diantecod_estudiantecreditosTotalesCarreracursonAsignaturasMatriculadasTotalCreditosAprobados

examinar()matricular_asignatura()terminar_estudios()matricular()

E mpleadocod_empleadoNombre_empresapuestosalariote lefonofecha_contratacionfecha_revi sio n_salariobonificacion

cambiar_empresa()cambi ar_puesto()i ncrementar_sal ario()subir_salario()pagar()despedir()con tratar()

VendedornVentas


ResponsablenClientesnVendedores

captar_cl ientes()perder_clientes()asignar_vendedores()quitar_vendedores()rebajar()

Figura 6.4: Identi…cación de atributos y operaciones emergentes

tenecientes a dicha subclase que la categorización en sí proporciona?.


² Sí.² No.

Si se elige la respuesta a…rmativa, el modelador podrá introducir en dicho momentoatributos y eventos nuevos.En todos los casos del ejemplo se detecta que las subclases poseen atributos y

eventos nuevos, lo que indica que cumplen los principios de no redundancia y econo-mía cognitiva (ver Figura 6.4).

Pregunta 3: Identi…cación de Características Temporales

La siguiente pregunta a realizar servirá para detectar las características temporalesde las subclases.¿Los objetos de la subclase se mantienen en ésta durante toda su existencia o pue-

den crearse y destruirse con el paso del tiempo sin dejar de existir en la superclase?.



Persona

Mujer Ho mbre Estudiante Empleado


Estáticas

Dinámicas

Figura 6.5: Identi…cación de subclases estáticas y dinámicas

² Se mantienen durante toda su existencia.

² Pueden crearse y destruirse con el paso del tiempo sin dejar de existir en lasuperclase.

Si se elige la primera respuesta se está ante una subclase estática, en caso contrarioserá una subclase dinámica.Para todas las subclases del ejemplo se realiza esta pregunta y el resultado es el

siguiente: las subclases Mujer y Hombre serán estáticas y las demás dinámicas (verFigura 6.5).

Pregunta 4: Especi…cación de Criterios Estáticos

En las subclases estáticas se preguntará ¿Se debe cumplir alguna condición basada enatributos constantes en la superclase, por la cuál ésta se especializa en la subclase?.


² Sí.

² No.

Si se elige la respuesta a…rmativa el modelador introducirá una fórmula bien forma-da en la que participarán atributos constantes de la superclase (siguiendo la sintaxispropuestas por OASIS). Si la respuesta es negativa puede ser por dos causas: (1)no existirá el criterio de especialización, por lo cual debería eliminarse la subclase, o(2) es necesario de…nir nuevos atributos en la superclase que ayuden a identi…car yespeci…car el criterio.En el caso de Hombre y Mujer la condición se basa en el atributo constante sexo.

Una persona será Hombre si sexo=”H”, y será Mujer si sexo=”M” (ver Figura 6.6).


Persona

Mujer Hombre

sexo="M" sexo="H"

Figura 6.6: Criterios de especialización estáticos

Pregunta 5: Identi…cación de Restricciones Dinámicas

Para conocer la naturaleza de la especialización dinámica, en las subclases dinámicasse efectuará una pregunta que permita detectar cómo se produce la creación de unobjeto de una subclase en el tiempo. La pregunta se formulará de la siguiente mane-ra: La creación de una instancia de una subclase dinámica, ¿se lleva a cabo mediantemigración desde una subclase en su mismo nivel jerárquico o creándose a partir delobjeto de la superclase?.


² Mediante un proceso de migración, en el que un objeto de una subclase secrea porque un objeto de una subclase de su mismo nivel migra hacia la nuevasubclase. (Indica evolución horizontal).

² Creándose a partir del objeto de la superclase, en un proceso de extensión enel que un objeto de la clase padre se extiende creando un nuevo objeto en lasubclase. (Indica extensión vertical).

Si la subclase se crea a través de un proceso de extensión vertical, no se podránutilizar (según el modelo OASIS) criterios de especialización basados en condicionessobre atributos variables para especi…car cómo se produce dicha extensión.Realizando esta pregunta sobre las subclases del ejemplo, se obtiene que los objetos

de las subclases Estudiante y Empleado se crean a partir un objeto de la clasePersona, y los objetos de las subclases Vendedor y Responsable, se crean desde elinicio (como Empleado) o mediante un proceso de evolución horizontal (ver Figura6.7).Una vez se sabe si es un proceso de evolución horizontal o extensión vertical se

pedirá al usuario que determine los criterios de especialización dinámicos. En el casode evolución horizontal se le preguntará por condiciones sobre atributos variables oeventos de migración, y en el caso de extensión vertical se le preguntará por los eventosde activación y …nalización.

En la especi…cación de criterios dinámicos se introducen dos preguntas para de-tectar, qué criterios se van utilizar cuando se dan restricciones dinámicas de evoluciónhorizontal y extensión vertical.


EstudianteEmpleado Vendedor Responsable

Extensión Vertical

Evolución Horizontal

Figura 6.7: Identi…cación de la Evolución y Extensión

Vendedor

Responsable


rebajar

Figura 6.8: Diagrama de Migración de la subclase Empleado

Pregunta 6: Especi…cación de Criterios Dinámicos en Subclases con EvoluciónHorizontal

A cada subclase dinámica con evolución horizontal se le preguntará: ¿Se debe cumpliralguna condición (basada en atributos variables) o, debe ocurrir algún evento para quese cree un objeto de la subclase?.


² Se debe cumplir una condición sobre atributos variables.

² Debe ocurrir un evento en la subclase origen de la migración.

Una vez determinado el criterio, si se eligen las condiciones sobre atributos varia-bles, el modelador introducirá la fbf que de…ne el criterio de especialización, y si seeligen los eventos se solicitará dicho evento. Además identi…cará también a la sub-clase origen en la que se debe cumplir la condición o producir el evento causante dedicha migración. Si el origen de la migración es la superclase, será porque se está enla subclase inicial de la migración. Esta información servirá para construir de formaautomática el diagrama de migración asociado a una partición dinámica (si al …naldel proceso de modelado se identi…ca como tal).


Persona

Estudiante Empleado


Figura 6.9: Eventos de creación y destrucción de subclases

En el ejemplo propuesto, la migración está basada en eventos (ver diagrama demigración de la partición dinámica de Empleado en la …gura 6.8). Un Empleado cuan-do lo contratan pasa inicialmente a ser Vendedor, éste después puede promocionar ala subclase Responsable, y el responsable puede ser rebajado de nuevo a Vendedor.

Pregunta 7: Especi…cación de Criterios Dinámicos en Subclases con ExtensiónVertical

En el caso de las subclases dinámicas con extensión vertical se determinarán los even-tos de creación y destrucción del objeto de la subclase. Para obtener dicha informaciónse preguntarán las siguientes cuestiones: ¿Debe ocurrir algún evento en la superclasepara que se cree un objeto de la subclase? y ¿Debe ocurrir algún evento para que unobjeto abandone la sublase?.


² Se introducirá el evento de creación (o …nalización en el caso de la segundacuestión).

En el caso de las subclases Estudiante y Empleado, la Persona se especializaen Estudiante cuando se matricula de una carrera Universitaria y …naliza comoEstudiante cuando termina los estudios, o se especializa en Empleado cuando locontratan y …naliza su trabajo cuando lo despiden (ver Figura 6.9).

Una vez realizadas las preguntas anteriores, se agruparán aquellas subclases quecumplan el mismo criterio y aquellas entre las cuales se produzcan migraciones deobjetos, con la intención de detectar particiones o grupos de rol. Para ello se le pediráal modelador que agrupe las subclases y, que especi…que textualmente el criterio porel cuál han sido agrupadas.Las subclases Hombre y Mujer constituyen un grupo porque se han especializado

siguiendo el mismo criterio que es el sexo de la Persona. Estudiante y Empleadose han especializado a partir de la ocurrencia de un evento. Estas dos subclases,aunque pertenecen a dos categorías que no tienen relación una con otra y no deberíanagruparse, si se agruparan no pasaría nada porque las preguntas que se realizan a


Persona



Figura 6.10: Identi…cación de Grupos de Subclases

continuación detectarán que forman un grupo incompleto y no disjunto, con lo quese deben separar constituyendo dos grupos. Por último, Vendedor y Responsableson dos subclases de Empleado que se han especializado según el tipo de trabajo querealizan en la empresa, por lo que es adecuado agruparlas (ver Figura 6.10).Sobre estos grupos de subclases se comprobarán las restricciones estáticas de

completitud y disyunción mediante las siguientes preguntas:

Pregunta 8: Identi…cación de la Completitud

Para conocer si se da la completitud, para cada grupo de subclases se preguntará: unobjeto de la superclase, en un instante dado, ¿siempre es instancia de una subclaseen el conjunto de subclases especializadas?.


² Sí. (Es Completa)² No. (Es Incompleta)Si el conjunto de subclases es incompleto es debido a que el criterio de especiali-

zación elegido no posee las características deseadas, o se tiene un grupo de rol. Si esincompleta y tiene todas las características de una partición, según el modelo taxo-nómico, se de…nirá obligatoriamente una subclase adicional que hará que la particiónsea completa.En el ejemplo propuesto, un objeto de la clase Persona siempre será Mujer u

Hombre, por lo que este grupo de subclases es completo. En el caso de Estudiante yen el de Empleado no tiene porque pertenecer en cualquier instante a dichas subcla-ses, por lo que serán incompletas en ambos casos. La especialización de Empleado enVendedor y Responsable será completa.


Pregunta 9: Identi…cación de la Disyunción

Para conocer si se da la disyunción, para cada grupo de subclases se preguntará: unobjeto de la superclase en un instante dado, ¿siempre es instancia de una única sub-clase en el conjunto de subclases especializadas?.


² Sí. (Es Disjunta)² No. (Es Solapada)Si existe un solapamiento entre subclases es porque se habrá de…nido un criterio

de especialización incorrecto o porque la partición o el grupo de rol en consideraciónson en realidad dos grupos de rol o dos particiones, por lo que el grupo tendrá quedividirse.En el ejemplo propuesto un objeto de la clase Persona no podrá ser a la vez Mujer

y Hombre, por lo que este grupo de subclases es disjunto. En el caso de Estudiante yen el de Empleado, como el grupo está formado por una subclase, también serán dis-juntos ambos casos. Si anteriormente el modelador hubiera decidido que Estudiantey Empleado constituían un único grupo, en este paso se detectaría que el criterio deespecialización era incorrecto, o que en realidad eran dos grupos o particiones. Laespecialización de Empleado en Vendedor y Responsable es disjunta porque un res-ponsable no puede ser vendedor a la vez y viceversa.

A continuación, se deberá determinar para cada subclase la multiplicidad y larelación existente entre el mecanismo de identi…cación de la superclase con respectoa la subclase.

Pregunta 10: Identi…cación de Multiplicidad

La multiplicidad se determinará mediante la cuestión siguiente: ¿En cuántas instan-cias de una subclase puede especializarse un objeto de la superclase?.


² En cero o una [0; 1].² En cero o más [0; N ]. Si es N se preguntará ¿cuál es la cota superior?

En el caso del ejemplo las subclases tendrán una multiplicidad [0,1] exceptuandola subclase Estudiante la cual podrá ser [0,3], ya que un estudiante podrá estudiarcomo máximo 3 carreras universitarias a la vez en la misma Universidad.

Pregunta 11: Identi…cación de Relación de Identidad. Mecanismos de Identi…ca-ción

La relación entre la identidad de la subclase respecto a la superclase se preguntarámediante la cuestión siguiente: ¿La subclase utiliza el mismo identi…cador de la su-perclase o posee uno propio?.


Persona

Mujer Hombre

Estudiante

Empleado

Vendedor Responsable<<sexo="M">> <<sexo="H">>

sexo

<<dinámica>>trabajo

<<jugado_por>>

<<contratar/despedir>>

<<matricular/terminar>>

<<0,3>>

Figura 6.11: Diagrama de Clases Resultante


² identi…cador propio.

² identi…cador compartido

Contestar esta pregunta por parte del analista puede ser una tarea difícil debidoa que los identi…cadores son conceptos que no forman parte del espacio del proble-ma. Esta pregunta se puede rescribir, haciendo uso del concepto de mecanismo deidenti…cación, de la siguiente forma: ¿La subclase utiliza el mismo mecanismo deidenti…cación de la superclase o posee uno propio?.


² Utiliza el mecanismo de identi…cación de la superclase.

² Introduce un mecanismo de identi…cación propio.

– Basado en el de la superclase

– Completamente nuevo

Si la multiplicidad detectada en la pregunta anterior es mayor que uno, no se lepermitirá seleccionar la primera respuesta, en caso contrario podrá elegir entre lasdos primeras. Si elige la segunda, se le pedirá que determine si está basado en el dela superclase o es nuevo.Es evidente que la subclase Estudiante, por su multiplicidad respecto a Persona,

debería tener un identi…cador propio, en el caso de estudio del apéndice A se utilizaráun identi…cador completamente nuevo que dependerá de la Escuela o Facultad en laque esté matriculado.


Pregunta 12: Evaluación de los Criterios de Especialización

Por último, se introducen una serie de preguntas para comprobar las propiedades delos criterios de especialización seleccionados y evaluar la adecuación. En el métodopropuesto existen dos situaciones donde deben aplicarse cuando se de…ne el criteriode especialización y cuando se agrupan subclases según un determinado criterio. Laspropiedades que se comprueban se introdujeron en el capítulo 4 (no redundancia,claridad, precisión, simplicidad y uniformidad). Para comprobar el cumplimiento dedichas propiedades se de…nen las siguientes preguntas:

² No Redundancia: ¿Existe en la/s subclase/s alguna propiedad que no esté ensu superclase?.

² Claridad: ¿El criterio se de…ne sobre una propiedad evaluable?.² Precisión: ¿Existe algún objeto que pueda cumplir el criterio propuesto parados o más subclases?. La restricción de disyunción en las particiones obliga aque los criterios de especialización sean precisos.

² Simplicidad: ¿El criterio elegido es único o está constituido por la unión dediversos criterios?.

² Uniformidad: ¿El criterio se evalúa (en las distintas subclases) sobre unamisma propiedad y el mismo dominio?.

Es muy importante destacar que estos criterios deben evaluarse en particiones o engrupos de rol de más de una subclase. En el caso de especializaciones por eventos enparticiones dinámicas y roles siempre existirá (al menos) un criterio implícito por elcuál se especializan. Por ejemplo, en una partición dinámica de Persona en Soltera,Casada y Divorciada se puede deducir, aunque sea por eventos (nacer, casarse ydivorciarse), que el criterio implícito se basa en el estado civil.Para la especi…cación completa de las propiedades y el comportamiento de las

subclases, esta serie de preguntas se complementará con la aplicación de los patronesEspeci…car Propiedades y Especi…car Comportamiento tal y como se ha comentado enel método propuesto.Siguiendo la notación presentada en el capítulo 5, en la …gura 6.11 se puede ver el

esquema conceptual resultante del proceso de modelado.

6.6 Conclusiones

En este capítulo se ha desarrollado una guía para el modelado de las relaciones ta-xonómicas de OO-Method. Esta guía se ha presentado siguiendo una aproximaciónnueva en el mundo del modelado conceptual, y la técnica utilizada ha sido un lenguajede patrones. El lenguaje propuesto en este capítulo está basado en las dimensionesde…nidas en el marco, y en el modelo taxonómico que se han introducido en capítulosanteriores. Los patrones del lenguaje se corresponden con los patrones estructuralesy de comportamiento identi…cados en las relaciones taxonómicas del modelo OASISsegún las dimensiones del marco propuesto.


Las relaciones y las dependencias existentes entre los patrones que componen ellenguaje han inducido una estructura navegacional que se ha utilizado para dirigir elproceso de modelado, proporcionando un método de aplicación de los patrones dellenguaje. El método obtenido permite identi…car los distintos tipos de especializa-ciones existentes en el modelo del dominio, y sus características estructurales y decomportamiento. Este método propone la aplicación sistemática del lenguaje de pa-trones en la etapa de modelado. Además, la propia estructura navegacional impuestapor el método se ha utilizado para construir una serie de preguntas que permiten guiaral analista en la etapa de modelado. El analista respondiendo a dichas preguntas enel orden propuesto por el método podrá obtener la especi…cación de una taxonomíaa partir de la descripción del sistema.La estructura navegacional propuesta se puede usar de formal manual, aplicando

el método en la etapa de modelado sin ninguna herramienta de soporte, o de formaautomática, mediante el desarrollo de un asistente para una herramienta CASE queguíe al modelador en el proceso de construcción de la taxonomía. Actualmente seestá desarrollando un asistente [42] para la herramienta CASE Rational Rose.Las ideas introducidas en este capítulo pueden ser perfectamente aplicables a otros

tipos de relaciones taxonómicas, instanciando adecuadamente el marco conceptualpropuesto, modi…cando los patrones y sus dependencias, y adaptando la estructuranavegacional al nuevo modelo taxonómico.

Capítulo 7

Generación de Código basadaen Patrones

En este capítulo se presenta un proceso completo para la generación de código delas relaciones taxonómicas especi…cadas en la etapa de modelado conceptual de OO-Method. Este proceso aplica una estrategia de generación de código propuesta porel Modelo de Ejecución Extendido (MEE) que se basa en la utilización de patronesde diseño. Para abordar adecuadamente la generación de código, en primer lugar seestudian los distintos patrones de diseño y las técnicas de implementación de relacionestaxonómicas existentes. Este estudio identi…ca, utilizando el marco propuesto en elcapítulo 4, cómo dan soporte estos patrones a las características estructurales y decomportamiento de cada uno de los tipos de relaciones taxonómicas. A continuación,se lleva a cabo un proceso de selección y especialización de patrones, en el cual serazona qué patrones se eligen y qué nuevas capacidades expresivas se deben incorporara dichos patrones para implementar completamente la semántica de las relacionestaxonómicas introducidas en esta tesis. Una de las capacidades que se incorpora alos patrones de diseño es la estrategia de ejecución, que determina cómo implementarel comportamiento del objeto. Una vez seleccionados y especializados los patronesde diseño adecuados, se de…nen correspondencias precisas entre los distintos tipos derelaciones taxonómicas (particiones estáticas y dinámicas, y roles) y los patrones dediseño que permiten implementarlas, ofreciendo un proceso de generación automáticade código de calidad. La generación de código se lleva a cabo sobre arquitecturasde tres niveles. Este capítulo aborda, con todo nivel de detalle, la generación de loscomponentes software del nivel de aplicación, que implementan la lógica de los objetosde negocio. En la última parte, se presenta la generación del nivel de persistencia,explicando la generación el esquema de la base de datos, y para …nalizar, se presenta lageneración del nivel de presentación donde se explica cómo generar la interfaz grá…cade usuario.

199

200 Capítulo 7. Generación de Código basada en Patrones

7.1 Patrones de Diseño y Técnicas de Implementa-ción

Para implementar los patrones conceptuales presentes en un esquema conceptual sedeben proporcionar técnicas que:

1. aseguren que la estructura y la funcionalidad del software se corresponde con loespeci…cado en los esquemas conceptuales.

2. ofrezcan guías precisas para construir el software, de forma que puedan serutilizadas como base para la construcción de generadores de código.

La estrategia de generación de código, que introduce el MEE de OO-Method,propone como prerrequisito para la generación de código, una etapa previa en la quese busquen y seleccionen patrones de diseño que permitan obtener una representaciónsoftware precisa de los patrones conceptuales.En este apartado, se analizan las técnicas más utilizadas en la práctica para la

implementación de relaciones taxonómicas. Este análisis permitirá identi…car los pa-trones más adecuados para implementar cada una de las relaciones taxonómicas delmodelo OASIS.

7.1.1 Herencia de los Lenguajes de Programación OO

En la mayoría de métodos orientados a objetos, la especialización/generalización sepresenta como una abstracción conceptual que soporta únicamente la subclasi…caciónsimple y estática. Este tipo de abstracción es fácilmente implementable utilizando laherencia de los lenguajes de programación OO (LPOO). Las desventajas de utilizar laherencia de los LPOO son que no soporta clasi…cación dinámica, ni múltiple. Además,esta técnica no se puede utilizar en lenguajes de programación no OO.

7.1.2 Clase Única

Existen situaciones en las que sólo es necesario un indicador para distinguir unasubclase de entre las subclases de un mismo nivel jerárquico (porque son muy parecidasa nivel estructural y de comportamiento). En estas circunstancias se puede utilizaruna única clase que combine todas las características de las subclases. El indicadorservirá para conocer a qué subclase pertenece un objeto de dicha clase. Por ejemplo,para un Empleado categorizado en Ingeniero, Vendedor, Gerente y Contable sóloserá necesario conocer el tipo de trabajo que realiza para distinguirlo. Esta solución nosoporta de forma adecuada la clasi…cación múltiple y, aunque parece sencilla a primeravista, puede llevar a la obtención de clases muy complejas (con las propiedades dediversas subclases juntas en una única clase).

7.1.3 Indicadores

Esta propuesta es una generalización de la propuesta anterior, que se aplica siempreindependientemente de la cantidad de características comunes que posean las sub-clases. El indicador1 de estado es un esquema de representación muy utilizado para

1Adaptación del inglés “‡ag”.

7.1. Patrones de Diseño y Técnicas de Implementación 201

Figura 7.1: Implementación mediante Indicadores de la jerarquía de especializaciónEmpleado, Vendedor y Responsable

implementar la herencia en lenguajes no OO. Proporciona una forma sencilla de so-portar la clasi…cación múltiple y dinámica (por ejemplo, en la …gura 7.1 se utilizaun indicador para distinguir el tipo de empleado). Esta solución se utiliza para im-plementar los cambios de estado en los programas OO que no utilizan clasi…cacióndinámica. En esta propuesta se debe garantizar mediante codi…cación que si el objetoreceptor del mensaje no es una instancia de una subclase determinada, éste no podráutilizar las operaciones de…nidas para dicha subclase. Además, el programador tendráque implementar la selección de métodos (mediante sentencias condicionales tipo if,case o switch) si existe comportamiento polimór…co. En dicho caso el programadeberá detectar la situación y ejecutar el código correspondiente a la subclase.Las desventajas de esta aproximación son: (1) que no se utiliza la potencia de la

herencia para la selección de métodos, por lo que todas las operaciones del interfazde la subclase deben de situarse en el interfaz de la superclase, y (2) que el espaciode memoria utilizado es la unión del espacio necesario para cada clase, por lo que nose aprovecha adecuadamente.

7.1.4 Clase Separada

Si se está ante una situación contraria a la anterior, en la que cada subclase po-see características totalmente distintas (aunque se presupone que tienen alguna encomún por el hecho de pertenecer a la misma jerarquía), se podrán utilizar clasesdistintas para implementar cada una de las subclases. Esta solución conlleva algunosproblemas:

² Las características comunes que heredan de la superclase se duplicarán en cada


Figura 7.2: Clasi…cación Múltiple

subclase.

² Si se produce algún cambio que afecte a dichas características, al duplicarselas características comunes, éste se debe propagar a todos los objetos (que re-presentan el mismo objeto). A este problema en [75] se le llama pérdida de laintegridad. Con esta solución no se puede hacer explícito, de ninguna manera,que dos objetos de distintas clases son el mismo. Éste es un problema importan-te cuando existen interacciones entre varios objetos que representan al mismoobjeto conceptual.

Esta solución es sencilla a simple vista, aunque cuando existe clasi…cación múltiplese complica considerablemente al tener que mantener la integridad de los datos enmuchas clases, por lo que no se recomienda su utilización.

7.1.5 Combinación de Clases utilizando Herencia Múltiple

La clasi…cación múltiple se puede implementar mediante la combinación de claseshaciendo uso de la herencia múltiple. Para abordar el ejemplo de la …gura 7.2 se crea-rán clases para las combinaciones Empresa*Prioritaria y Persona*Prioritario,además de para las clases Cliente, Empresa, Persona y Prioritario. Median-te herencia múltiple, las clases pueden capturar todos los interfaces requeridos. Estaaproximación posee algunas desventajas: (1) una clase puede tener muchas particioneslo que puede causar la aparición de un conjunto de clases combinación de gran ta-maño. Esta situación puede hacer inviable el uso de esta técnica, por ejemplo, cuatroparticiones completas, cada una con dos subclases, requieren de 24 clases combina-ción, (2) sólo soporta clasi…cación estática, y (3) existen gran cantidad de lenguajesOO y no OO que no poseen herencia múltiple.

7.1.6 Reemplazo

Una forma de manejar la clasi…cación dinámica en el proceso de reclasi…cación, eseliminar el objeto antiguo (origen) y cambiarlo por un objeto nuevo de la subclasedestino. Esto permite al programador mantener las ventajas de la herencia y de laselección de métodos mientras proporciona clasi…cación dinámica. El procedimientoadecuado para llevar esto a cabo debe crear un objeto en la nueva clase, copiar toda la


Figura 7.3: Especialización de Empleado en Ejecutivo

información común del objeto antiguo al nuevo objeto, cambiar todas las referenciasque apuntan al viejo objeto para que apunten al nuevo objeto, y para …nalizar, borrarel objeto viejo. En muchos entornos de desarrollo el problema principal consiste enencontrar todas las referencias al viejo objeto y pasarlas al nuevo objeto. Esto esprácticamente imposible sin una gestión de memoria adecuada. Cualquier referenciaque no se cambie puede llevar a errores de ejecución difíciles de depurar. Esta apro-ximación es interesante y puede llevarse a cabo si se puede asegurar que se capturany cambian todas las referencias, pero posee algunas desventajas: (1) el consumo detiempo para copiar la información común y buscar e intercambiar las referencias, y(2) no soporta clasi…cación múltiple.

7.1.7 Delegación a una Clase Oculta

En esta aproximación se implementa una clase para representar la superclase y unaclase por cada subclase especializada. Estas últimas estarán ocultas a las demás clasesdel sistema, exceptuando a la clase que implementa a la superclase. Por cada subclaseque se de…na se incluirá un atributo objeto-valuado en la superclase. Este atributoreferenciará a un objeto de la subclase. En esta solución deben moverse de nuevotodas las operaciones de la subclase al interfaz de la superclase. Las operaciones de lasuperclase que provienen de la subclase, delegan su ejecución mediante una llamadaa la operación en la subclase que implementa el método.Tomando como ejemplo el esquema conceptual de la …gura 7.3, una instancia de la

clase Empleado en realidad estará compuesta por dos instancias, una de Empleado yotra de Ejecutivo (ver …gura 7.4). A las operaciones del objeto ejecutivo no puedeacceder ningún otro objeto que no sea de la clase Empleado. Cuando se le envíe elmensaje pagar()a un objeto empleado con un ejecutivo “asociado”, el método sobreempleado llamará al método pagar() del ejecutivo. La selección de métodos paralas operaciones polimór…cas se implementa a través de sentencias condicionales quecomprueban en qué subclase/s está especializado el objeto, realizándose una llamadaal método de ejecutivo si éste existe. Otra variante de esta aproximación sería situartodos los métodos en Empleado y hacer que la clase Ejecutivo sólo funcione comouna estructura de datos.


Figura 7.4: Aplicación de la Delegación a una Clase Oculta a la especialización deEmpleado en Ejecutivo

7.1.8 El Patrón State

Una aproximación que mejora la técnica anterior es el patrón de diseño State, pro-puesto por Gamma et al. en [78]. En la …gura 7.5 puede observarse en su formagenérica.Mediante el patrón State, se puede simular el cambio del comportamiento de un

objeto debido a la migración de una subclase a otra de la misma partición. Este patrónestá basado en la técnica de la delegación a una clase oculta, en la cual las diferentesclases ocultas poseen un superclase común abstracta (clase Estado ver …gura 7.5),también oculta. En este patrón el objeto padre delegará en un objeto de otra claseoculta (que simula el comportamiento de la subclase) la ejecución de las operacionesque no son propias, por lo cual la clase padre debe ofrecer en su interfaz el conjuntode operaciones de sus subclases y el acceso a sus atributos a través de métodos deconsulta. En la …gura 7.5 la clase Contexto delega el método operacion a un objetode una de las subclases ocultas EstadoConcreto. Cualquiera de las subclases de la claseabstracta que esté presente responderá adecuadamente, porque en cualquier momentoexistirá una instancia de una de las subclases, asociada a una variable del tipo de laclase abstracta. Cualquier comportamiento especí…co de las subclases se declarará enla clase abstracta como un método abstracto que se implementará en las subclases.Existen diversas variaciones del patrón State introducidas por Dyson et al. en [69]

que extienden la expresividad del patrón y que son aplicables en la propuesta que sepresenta en este capítulo. De entre las variaciones propuestas las más interesantespara este trabajo son State Member (resuelve el problema de en qué clase del patrón(en la clase padre, en la clase abstracta o en las subclases) se sitúan los atributosde las clases que componen la relación taxonómica), Owner-Driven Transitions (seutiliza cuando se usan objetos estado para implementar una máquina de estados y se


Cliente

EstadoConcretoA

operacion()

EstadoConcretoB

operacion()

Estado

operacion()

Contexto

operacion()

estado

estado -> operacion

Cliente

EstadoConcretoA

operacion()

EstadoConcretoB

operacion()

Estado

operacion()

Contexto

operacion()

estado

estado -> operacion

Figura 7.5: Estructura de clases del patrón State.

desea que la superclase sea quién inicie la transición entre estados) y Default-State(se utiliza para exigir que cuando se cree un objeto de la superclase, esto conlleve lacreación de un determinado objeto estado inicial).

7.1.9 El Patrón Role Object

En el patrón State, un objeto sólo podía tener activo un objeto de una de las subclasesde forma simultánea, por lo cual se podía acceder a dicha instancia especializada desdela clase padre. En las situaciones en las cuales un objeto pueda especializarse en másde un objeto de la misma subclase será necesaria otra solución.El patrón Role Object es similar al patrón State. La estructura de las clases

utilizada para implementar el patrón se puede ver en la …gura 7.6. Las clases y susrelaciones incluidas dentro del cuadrado de la …gura, son las que se implementanrealmente en el patrón. El patrón está constituido por:

² Una clase Componente que especi…ca el interfaz de las operaciones que deberíaposeer la clase jugadora y sus roles. En concreto aquellas operaciones necesariaspara añadir, eliminar, comprobar y solicitar roles.

² Una clase Jugador que implementa el interfaz público de la clase Componente.Esta clase será la encargada de la gestión de los roles creando los roles, con-trolando las cardinalidades, ejecutando el código necesario para que se eliminenlos roles, controlando que no se puedan crear roles de subclases disjuntas y porúltimo será la encargada de eliminarlos a todos en el caso de la destrucción deljugador. Esta clase poseerá como atributo una colección de roles surgida por surelación de agregación con la clase Rol con multiplicidad muchos . En este casono será posible acceder directamente desde esta clase a los atributos y serviciosde los roles, dado que pueden existir simultáneamente muchos roles activos dela misma clase de rol. Por esto, en este patrón se obtendrá la instancia del rolcon la que se desea trabajar y posteriormente se ejecutarán, directamente sobreel rol, todos los servicios que se deseen.

² Una clase Rol que almacenará una referencia a un objeto de la clase Jugador eimplementará el interfaz de la clase Componente enviando mediante delegaciónlas peticiones al objeto Jugador.


Cliente

Roles

Componente

operacion()anyadirRol()TieneRol()eliminarRol()obtenerRol()

RolConcretoAestadoAnyadidoA

nuevaOperacionA()

RolConcretoB

nuevaOperacionB()

Jugadorestado


Rol


0..*0..*

Jugador

jugador->operacion

jugador->TieneRolCliente

Roles

Componente


RolConcretoAestadoAnyadidoA

nuevaOperacionA()

RolConcretoB

nuevaOperacionB()

Jugadorestado


Rol


0..*0..*

Jugador

jugador->operacion

jugador->TieneRol

Figura 7.6: Patrón Role Object

² Existirán tantas subclases RolConcreto como roles se necesite implementar. Es-tas subclases implementarán las operaciones y poseerán los atributos especí…cosde los roles. En el caso de que se desee acceder a una operación o atributo queno esté en el rol (por ser de la clase jugadora), se delegará en el jugador. Parasu correcta instanciación se les asignará obligatoriamente un objeto jugador.

En este patrón, a diferencia del State, los roles no están ocultos a los demáscomponentes del sistema que utilicen sus servicios. Para trabajar con ellos, se lespuede preguntar directamente u obtenerlos a través del objeto jugador mediante laoperación obtener_rol.

El patrón Role Object permite la clasi…cación dinámica ya que los objetos de rolpueden ser añadidos y eliminados dinámicamente. Además, soporta la clasi…caciónmúltiple eludiendo la explosión combinatoria de clases que aparecerían si se hubieseutilizado la herencia múltiple para crear diferentes roles mediante una sola clase.

Este patrón está basado en el patrón Decorator [78] (viendo al rol como un en-voltorio de la clase jugadora que añade a ésta su comportamiento propio) y en elProduct Trader [21]. El patrón Extension Object [77] también se ha utilizado parala implementación de roles [199, 245, 246] aunque en esta solución el rol no decorade forma transparente al jugador. En las situaciones en las que existan jerarquíasde roles de varios niveles y relaciones entre roles de distintos niveles de la jerarquía,se puede utilizar un patrón llamado Cascade propuesto en [246]. Este patrón es unaextensión del patrón Composite [78] y representa objetos en una estructura de árbol,donde cada nivel del patrón es, a su vez, un patrón Composite.

7.2. Selección y Especialización de Patrones de Diseño 207

Relación IS HP V RE CT RD M DE I CE

Estáticas ES H,M (CC),N Sp D,C E No 0,1 Sp C DE

Dinámicas ES H,M (CC),N Sp D,C D EvH 0,1 Sp,Sb C DE,DV

Roles ES H,M (CS),N Sp D,I D ExV 0,N Sp P DV

Tabla 7.1: Características de las Relaciones Taxonómicas según el Marco Multidi-mensional propuesto

7.1.10 La Técnica de Object Slicing

Existe una técnica llamada object-slicing [153] que permite dar soporte a la clasi…ca-ción dinámica y múltiple. En esta técnica un objeto con clasi…cación múltiple puedeverse como un objeto dividido en múltiples partes. Cada parte la constituyen cadauna de las subclases a las que puede pertenecer simultáneamente un objeto. Porejemplo, si un objeto de la clase Persona puede subclasi…carse a la vez en Empleado yFutbolista, para representar estas dos facetas en un LPOO con clasi…cación simple,una parte de dicho objeto será instancia de una Persona Empleada y la otra seráinstancia de Persona Futbolista. Cada objeto, a nivel conceptual, será una instanciade una clase que mantendrá referencias a los diversos objetos que constituyen suspartes. Las instancias de las subclases serán las partes de dicho objeto y pertenecerána una clase oculta, por lo que para acceder a sus propiedades se seguirá la estrategiade delegación a una clase oculta.Es obvio que los objetos a nivel conceptual no pueden ser “partidos” en instancias

de diversas clases. Las partes del objeto se considerarán también como dicho objeto,de forma que se cumpla que un objeto siempre es instancia de una única clase. Loscambios de subclase se llevarán a cabo añadiendo o eliminando objetos que formanlas partes. Los constructores y destructores deben mantener las restricciones de clasi-…cación múltiple de forma que garanticen que un objeto no puede estar en dos clasesque son totalmente disjuntas (por ejemplo Empleado y No Empleado a la vez).Esta propuesta se puede considerar como una extensión aplicable a las técnicas

basadas en agregación y delegación, como la delegación a una clase oculta y los patro-nes State y Role Object, para dar un soporte adecuado a la clasi…cación múltiple. Dehecho se considera que estas técnicas ya incorporan en su de…nición el Object Slicing.

7.2 Selección y Especialización de Patrones de Di-seño

En este apartado se realiza un análisis exhaustivo de las técnicas presentadas en elapartado anterior. Este análisis se lleva a cabo aplicando el marco multidimensionalpropuesto en la tesis para identi…car a qué características del marco da soporte directocada una de las técnicas de implementación presentadas. El resultado se presenta enlas tablas 7.2 y 7.3. Este análisis servirá para:

1. Seleccionar el patrón o técnica más adecuado para dar soporte a nivel de imple-mentación a cada una de las relaciones taxonómicas presentadas.


Implementación IS CM HP V RE CT RD

Herencia ES No H,M (CS),N Sp No E No

Clase Única ES No H,M (CS),N Sp,Sb D D No

Clase Separada ES No H,M (CS),N Sp No E No

Herencia Múltiple ES Sí H,M (CS),N Sp No E No

Indicadores ES Sí H,M (CS),N Sp,Sb No D No

Delegación C. Oculta ES Sí H,M (CS),N No No D No

State ES Sí H,M (CS),N No D,C D EvH

Reemplazo ES No H,M (CS),N Sp No D EvH

Role Object ES Sí H,M (CS),N Sp No D ExV

Object Slicing ES Sí H,M (CS),N No D D No

Tabla 7.2: Características soportadas por las técnicas de Implementación (1 de 2)

2. Detectar aquellas dimensiones que no están soportadas directamente por lastécnicas de diseño presentadas. Esto permite determinar cómo se pueden es-pecializar estas técnicas de forma que representen completamente los patronesconceptuales en el espacio de la solución.

Cuando se hayan llevado a cabo ambos pasos, se podrán de…nir correspondenciasentre las relaciones taxonómicas y las estructuras de diseño para conseguir un procesode generación automática de código completo.Aparte de las dimensiones2 introducidas por el marco, se ha añadido la dimensión

CM que determina si la técnica da soporte a la clasi…cación múltiple. Además se hanañadido tres nuevas dimensiones que sirven para analizar las técnicas de implemen-tación desde el punto de vista de los recursos que consumen, la complejidad de suimplementación y la e…ciencia de las técnicas aplicadas. Estas dimensiones ayudaránen el proceso de selección a elegir soluciones de mayor calidad. Los valores de estasdimensiones serán:

² R (Recursos): Medirá el grado de consumo de recursos (memoria, tiempo deproceso). Valdrá A si es alto, M si es medio y B si es bajo.

² C (Complejidad): Medirá la complejidad que tiene llevar a cabo dicha imple-mentación. Valdrá A si es alta, M si es media y B si es baja.

² E (E…ciencia): Medirá la e…ciencia de la solución y valdrá Sí o No si la soluciónes e…ciente o no. Se considerará e…ciente si consume los recursos exclusívamentenecesarios.

Los valores de las dimensiones R y C se han obtenido de manera relativa analizandocada una de las técnicas propuestas y ordenándolas entre ellas.

7.2.1 Selección de Patrones

Los resultados obtenidos en las tablas 7.2 y 7.3 se van a analizar y comparar con losvalores de las dimensiones en la tabla 7.1 que de…nen la expresividad de las relaciones

2Las dimensiones no soportadas por las técnicas de implementación tienen como valor No.

7.2. Selección y Especialización de Patrones de Diseño 209

Implementación M DE I CE R C E

Herencia 0,1 Sp C No B B Sí

Clase Única 0,1 Sp,Sb C No A B No

Clase Separada 0,1 Sp C No A A No

Herencia Múltiple 0,1 Sp C No A A No

Indicadores 0,1 Sp,Sb C DE,DV A M No

Delegación C. Oculta 0,1 Sp C DE,DV M M Sí

State 0,1 Sp,Sb C DE,DV B M Sí

Reemplazo 0,1 Sp C No B A No

Role Object 0,N Sp C DE,DV B A Sí

Object Slicing 0,1 Sp C DE,DV M M Sí

Tabla 7.3: Características soportadas por las técnicas de Implementación (2 de 2)

taxonómicas introducidas, para seleccionar la técnica de implementación de mayorcalidad que se adecue a las características intrínsecas de las relaciones.El modelo de relaciones taxonómicas presentado proporciona clasi…cación múltiple

(CM) por lo que parece adecuado descartar aquellas aproximaciones que no soportendirectamente la CM. Estas técnicas son la Herencia, Clase Única, Clase Separada yReemplazo. La técnica Object Slicing se descarta porque se supone que las técnicas dedelegación a una clase oculta y los patrones State y Role Object ya la utilizan cuandoexiste clasi…cación múltiple.Las técnicas no descartadas se van a analizar para cada una de las relaciones

taxonómicas, seleccionando las más adecuadas a cada tipo de relación:

² Especialización Estática: Las técnicas que pueden dar soporte a este patrónconceptual son la Herencia Múltiple, los Indicadores, la Delegación a una ClaseOculta, y los patrones State y Role Object. El patrón Role Object se descartapor ser demasiado complejo para representar la especialización estática, ya queofrece más características expresivas de las necesarias. La Herencia Múltiple nopermite de…nir restricciones estáticas, ni criterios de especialización de formadirecta. Además, el consumo de recursos es elevado, no siendo una implemen-tación e…ciente. De las tres técnicas que quedan, los Indicadores desperdicia elrecurso de la memoria y no facilita la implementación directa de criterios deespecialización. Por lo que queda la Delegación a una Clase Oculta y el pa-trón State. Ambas soluciones parecen ser las más adecuadas. Si se ha de elegiruna, el patrón State parece idóneo porque es una mejora de la técnica ante-rior y soporta directamente la implementación de las restricciones estáticas dedisyunción y completitud, ya que sólo puede existir un objeto estado por cadapartición (disyunción), existiendo siempre un objeto estado por defecto (comple-titud mediante la extensión Default State). Este patrón se puede utilizar paraimplementar especializaciones estáticas ya que éstas pueden considerarse comoun caso particular de las dinámicas. Además, como se verá a continuación, estepatrón permite tratar de forma homogénea el proceso de generación de códigocuando existe clasi…cación múltiple por combinación de particiones estáticas ydinámicas.


² Especialización Dinámica: Para este tipo de relación no existen tantos pro-blemas a la hora de decidirse por una técnica de implementación. El patrónState y el Role Object son los candidatos ideales. El Role Object de nuevo pro-porciona demasiado poder expresivo, por lo que si se utiliza, deberían de nousarse ciertas facilidades que proporciona, en cambio, el patrón State se adaptaperfectamente a las restricciones estáticas y dinámicas (evolución horizontal).

² Roles: En cuanto a los roles, el patrón que mejor se adapta a las necesidadeses el Role Object, ya que permite la multiplicidad de roles, la dinamicidad yla extensión vertical (con los métodos de inserción y borrado de roles) que soncaracterísticas esenciales de los roles.

Los patrones State y Role Object han sido los seleccionados para representar,en el espacio de la solución, las relaciones taxonómicas del modelo OASIS. Sinembargo, estos patrones no son perfectos porque que existen algunas característicasque no soportan directamente. Para dar un soporte completo, estos patrones necesitanextenderse a través de un proceso de especialización.

7.2.2 Especialización de Patrones

Si se comparan las características de las relaciones taxonómicas que los patrones dediseño seleccionados soportan, se observa que existen algunas a las cuales no dansoporte directo, lo que signi…ca que si no se extienden dichos patrones, no seráncapaces de representar en el espacio del problema dichas relaciones de forma completa.En este apartado se detectan las características no soportadas y, se propone qué tipode especialización (adaptación) deben sufrir los patrones para extender su capacidadexpresiva.

Especialización del Patrón State

Comparando los valores de las dimensiones que el patrón State soporta directamentecon los que caracterizan a las especializaciones estáticas y dinámicas, se observa que:

1. Los objetos de las subclases no poseen visibilidad (V) respecto a las propiedadesde la superclase.

2. En la herencia de propiedades (HP) cuando las propiedades son modi…cadas(M), deben modi…carse manteniendo la compatibilidad de comportamiento. Lacompatibilidad de comportamiento (CC) no está soportada por ningún patrón.

3. Se supone que algunas de las extensiones del patrón permiten dar soporte a loscriterios de especialización (CE) aunque no lo hacen de forma completa, por loque esta característica se debe incorporar al patrón para dar un soporte directo.

Así pues, se debe extender el patrón State con técnicas que den soporte a lavisibilidad, compatibilidad de comportamiento y a los criterios de especialización, ca-racterísticas necesarias para implementar las especializaciones estáticas y dinámicas.

7.3. Implementación del Comportamiento 211

Especialización del Patrón Role Object

Al comparar el patrón Role Object con los roles conceptuales se observa que:

1. La restricción estática de Disyunción (RE) en los grupos de roles no está sopor-tada.

2. La gestión de identidades (I) propias para los roles no está soportada directa-mente por el patrón. En este patrón distintos roles pueden compartir el mismoobjeto conceptual pero necesitan de identi…caciones distintos.

3. La restricción de multiplicidad (M), que en el caso de los roles puede ser de unrango especi…cado por el usuario, no está soportada directamente por los roles.

El patrón Role Object se deberá especializar para dar soporte a la restricciónestática de disyunción, a la posibilidad de tener una identidad propia y a la restricciónde multiplicidad, todo ello para representar en el espacio de la solución los roles delmodelo presentado.Por último, existe una característica muy importante relacionada con el comporta-

miento. Esta característica es el soporte que dan los patrones de diseño seleccionadosa la estrategia de ejecución de OO-Method. La estrategia de ejecución describe una se-cuencia de pasos a ejecutar para implementar el comportamiento asociado a un eventode un objeto. Esta estrategia de ejecución debe incorporarse a los patrones de diseñoseleccionados, por lo que se deben especializar de manera que soporten directamentela estrategia de ejecución. Esta especialización se desarrolla en el siguiente aparta-do, presentando un conjunto de técnicas que, combinadas adecuadamente, permitenimplementar dicha estrategia de ejecución.

7.3 Implementación del Comportamiento

El comportamiento asociado a la ejecución de los eventos está basado en la estrategiade ejecución de…nida en elModelo de Ejecución. La estrategia de ejecución presentadade…ne detalladamente la siguiente secuencia de acciones a realizar para la ejecuciónde un evento de cualquier clase del sistema:

² Comprobación de Transición de Estado válida en el DTE² Comprobación de Precondiciones² Realización de la Evaluación² Comprobación de Restricciones² Comprobación de DisparosEste conjunto de acciones constituyen un algoritmo genérico a aplicar en la ejecu-

ción de un evento para garantizar que los objetos de las clases del esquema conceptualse comportan según el modelo de ejecución subyacente al modelo OASIS. Este al-goritmo será siempre el mismo, sólo cambiará la implementación de las acciones arealizar que podrán rede…nirse en las subclases, manteniendo o no la compatibilidadde comportamiento dependiendo de la naturaleza de la relación taxonómica.


7.3.1 La Estrategia de Ejecución y el Patrón de Diseño Tem-plate Method

Las características de la estrategia de ejecución de…nen un patrón de comportamientomuy parecido (de forma genérica) al que resuelve el patrón de diseño Template Method[78]. El patrón Template Method es un patrón de comportamiento que de…ne elesqueleto de un algoritmo en una operación, dejando a las subclases que puedanrede…nir algunos pasos sin cambiar la estructura del algoritmo, por lo que es adecuadopara la implementación de la estrategia de ejecución.El patrón Template Method se incorporará a los patrones de diseño seleccionados

para poder implementar la ejecución de los eventos. Se aplicará del siguiente modo(para documentar la propuesta se utiliza el lenguaje de programación Java):

² Los eventos especi…cados en el esquema conceptual se implementarán mediantemétodos públicos que implementarán la estrategia de ejecución utilizando elalgoritmo que sigue la secuencia de pasos de dicha estrategia (como ejemplo sepresenta la implementación del evento evento1 de una clase Cualquiera):

public void evento1();{

comprobar_transicion_estado(evento1);comprobar_precondicion_evento1(arg_evento1);eval_evento1(arg_evento1); //evaluación de evento1comprobar_restricciones_integridad();comprobar_disparos();

}

² Se de…nirán como métodos protegidos aquellos que implementen cada una de lasacciones de…nidas en la estrategia de ejecución. Estos métodos se rede…nirán encada una de las subclases de la partición si en la especi…cación se ha rede…nidoalguna precondición, evaluación, restricción de integridad, disparo o proceso.

public class Cualquiera{

...protected void comprobar_transicion_estado(Eventos3 evento);protected void comprobar_precondicion_evento1(ArgumentosEvento14);protected void comprobar_precondicion_evento2(ArgumentosEvento2);...protected void comprobar_restricciones_integridad();protected void comprobar_disparos();//se implementan las evaluaciones de evento1 y evento2protected void eval_evento1(ArgumentosEvento1);protected void eval_evento2(ArgumentosEvento2);...

}

Cada uno de los pasos de la estrategia de ejecución debe implementar un algo-ritmo especí…co. La implementación de estos pasos se basa en la especi…cación del

3Tipo Enumerado.4 Se incluirán los argumentos del evento.


comportamiento de la clase. Este comportamiento debe cumplir las precondiciones,restricciones de integridad, condiciones de disparo, evaluaciones y el ciclo de vida deun objeto de…nidos en la etapa de modelado. Para implementar cada uno de los pasosde la estrategia de ejecución se utilizan una serie de técnicas que se presentan en lossiguientes subapartados.

Comprobación de Transición de Estado Válida en el DTE

El primer paso en la estrategia de ejecución de un evento, es comprobar que existeuna transición válida (etiquetada con el nombre del evento a ejecutar) en el DTE ob-tenido durante la etapa de modelado conceptual. Existen básicamente tres técnicaspara implementar la comprobación de la transición de estados: la lógica condicional,el patrón State y la implementación de un intérprete de máquinas de estados quese ejecuta utilizando un conjunto de reglas de transición entre estados de…nidas enuna tabla construida a partir del DTE. De esta última aproximación existen diversasimplementaciones, de entre las que se puede destacar el patrón State Machine pro-puesto por Yourdon et al. [243] (basado en las ideas de Shlaer y Mellor [206]), y laimplementación de las tablas en C++ presentada por Cargill en [41].La solución basada en el uso de la lógica condicional utiliza valores de datos

para de…nir los estados en el DTE del objeto y de…ne sentencias condicionales quecomprueban de forma explícita los valores de esos datos. Con esta técnica se puedetener una gran cantidad de sentencias condicionales que pueden hacer que el códigosea difícil de mantener y entender.El patrón State localiza el comportamiento especí…co del estado en un objeto de

una determinada subclase y particiona el comportamiento en distintos estados. Sinembargo, el patrón State introduce otro tipo de problema, porque al distribuir elcomportamiento dependiente del estado en diversas clases se incrementa el núme-ro de clases del sistema, es menos compacto y consume más recursos, aunque estadistribución es más elegante que muchas sentencias condicionales, ya que sentenciascondicionales largas no son deseables en programación. Con el patrón State las tran-siciones de estado tienen una representación explícita gracias a la introducción deobjetos separados para distintos estados.La última alternativa utiliza tablas para de…nir correspondencias entre las entradas

de la tabla y las transiciones de estados. Para cada estado, la tabla almacena cadaposible transición a un estado destino. Esta aproximación convierte el código de lalógica condicional o las llamadas a métodos virtuales (en el caso del patrón State) enbúsquedas en una tabla. La principal ventaja de las tablas es su extensibilidad ya quese pueden cambiar las transiciones modi…cando los datos de la tabla sin necesidadde cambiar el código del programa, lo que facilita su mantenimiento. Sin embargocomo desventajas se puede considerar que la búsqueda en una tabla es menos e…cienteque una llamada a un método virtual, el formato de tabla hace menos explícitas lastransiciones en el código por lo que dicha lógica es más difícil de comprender, y esdifícil añadir acciones (algoritmos asociados) que acompañen a la transición de estadospor lo que debería extenderse para que se puedan realizar computaciones asociadas ala transición.Para la comprobación de la transición de estados de un DTE en OO-Method no

es necesario asociar un comportamiento especí…co a cada transición. Debido a ésto


el patrón State no es totalmente adecuado por ser demasiado expresivo y consumirmás recursos que las otras aproximaciones. Las técnicas de lógica condicional y tablasson las opciones más adecuadas, por lo que se recomienda utilizar cualquiera de lasdos, de hecho ambas se están aplicando en los procesos de generación propuestos eneste trabajo. Se elegirá la lógica condicional si se requiere una solución más explícita,aunque más difícil de mantener que las tablas. La técnica basada en tablas se elegirási se pre…ere una solución menos explícita y e…ciente, y de fácil mantenimiento. Enel contexto de la tesis se elige la lógica condicional porque con esta aproximación lastransiciones se hacen más explícitas en el código y la lógica de los DTE de ejemplo,utilizados para documentar la aproximación, es más fácil de comprender.Así pues, la implementación de la comprobación de la existencia de una transición

válida en el DTE se llevará a cabo de la siguiente manera:

² Se añadirá a cada clase un atributo5 al que se llamará EstadoDTE, que servirápara mantener el estado actual del objeto en el DTE.

² Se añadirá a cada clase, un método comprobar_transicion_estado con elnombre del evento como argumento. Este método se encargará de validary permitir el cambio de estado del objeto, actualizando el valor del atributoEstadoDTE al nuevo estado. El cuerpo de este método se obtendrá de la siguien-te forma:

Para cada estado ei=i=0::n 2 E, donde E es el conjunto de estados del DTE vistoscomo nodos de un grafo G = (E;T ) que representa el DTE (como se vió en elcapítulo 5), se tiene que generar una estructura condicional que compruebe siel estado actual del objeto en el DTE (EstadoDTE) es igual a ei, y para cadaevento ev tal que 9 t 2 T/t = (ei; ej ; ev;_; cc) se generará:

1. Una sentencia condicional que compruebe si el argumento evento es igual a evy se cumple la condición de control cc (si existe) de ev.

2. Una sentencia de asignación que asigne el valor ej=j=0::n al estado actual delobjeto (EstadoDTE) si se cumple la condición del paso anterior.

² Si no existe una transición válida en el DTE (es decir si no se cumple la condicióndel paso 1) se generará una excepción que informará de la no existencia de unatransición para el evento pasado como argumento. Esta excepción mostrará elmensaje “violación de transición de estado”.

Para ofrecer un ejemplo de generación de este método, a continuación se generael método de comprobación del DTE de la clase Vehículo que se construyó en elcapítulo 5 (ver …gura 7.7):

protected void comprobar_transicion_estado(Eventos6 Evento)throws EventoNoPermitidoEnDTE{switch(EstadoDTE)

5En el caso de que una clase posea diversos DTE concurrentes se utilizará un vector cuyo rangoserá el número de DTE que posee la clase.

6Para utilizar adecuadamente la sentencia switch los eventos y los estados del DTE se de…niráncomo tipos enumerados.


Sfabricar

vender

destruir

Figura 7.7: DTE de la clase Vehículo

{case S_INICIAL:switch(Evento){

case fabricar:EstadoDTE=S;break;

default:throw new EventoNoPermitidoEnDTE;}break;case S:switch(Evento){case vender:

EstadoDTE=S;break;

case destruir:EstadoDTE=S_DESTRUIDO;break;

default:throw new EventoNoPermitidoEnDTE;}break;}}

En el código generado se observa que, para cada estado especi…cado en el DTEde la …gura 7.7 (en esta caso serían los estados inicial y S, ya que para el estado…nal destruido no se genera código de comprobación), se ha declarado una estructuracondicional. Esta estructura comprueba si existe una transición válida para el eventoque está siendo activado, si es así se lleva a cabo el cambio de estado correspondiente,si no existe dicha transición entonces se genera una excepción.

Comprobación de Precondiciones

La comprobación de precondiciones es el siguiente paso en la estrategia de ejecución.Dado un evento, sus precondiciones son las condiciones (fbf ) sobre el estado del ob-jeto que se han de cumplir para poder ejecutar dicho evento. Las precondicionesetiquetan las transiciones en el DTE, precedidas por la palabra reservada if. La im-plementación de la comprobación de la precondición, asociada a la ejecución de undeterminado evento, se llevará a cabo a través de la implementación de un método


comprobar_precondicion_evento por cada evento de la clase que tenga una precon-dición asociada. Los argumentos de este método serán los argumentos del evento.Este método veri…cará si se cumple su precondición. Así pues, para cada evento ev deuna clase que posea una precondición p asociada, se generará un método cuyo cuerpose obtendrá de la siguiente forma:

1. Una sentencia condicional que compruebe si se cumple p de ev.

2. Una excepción que mostrará un mensaje de error “violación de precondición”cuando no se cumpla la precondición.

Para ofrecer un ejemplo de generación de este método, a continuación se presentael método de comprobación de la precondición asociada al evento promocionar dela subclase dinámica Vendedor (del ejemplo del Apéndice A) que se especi…ca de lasiguiente manera (notación OASIS) promocionar if nVentas >300.

protected void comprobar_precondicion_promocionar()throws ViolacionPrecondicion{

if (!(ventas > 300)) throw new ViolacionPrecondicion;// comprueba si no se cumple la precondicion de promocionar

}

En este ejemplo la precondición de promocionar especi…ca que no se puede promo-cionar a un Vendedor si no ha realizado más de 300 ventas. Como se puede observar enel ejemplo, en el código generado se comprobará si no se cumple dicha precondición7

(si se cumple la precondición no se debe realizar ninguna acción).

Realización de Evaluación

La evaluación de los eventos se ve re‡ejada en el modelado conceptual mediante laespeci…cación de las fórmulas de evaluación asociadas a los eventos. Estas fórmulasespeci…can el cambio de estado provocado por el efecto de un evento sobre los valoresde los atributos, según su categorización en el Modelo Funcional (MF ). La implemen-tación de la evaluación debe representar …elmente la semántica de la fórmula ©[e]©0,la cual representa que si ocurre un evento e y el objeto está en el estado ©, el efectode la ejecución del evento e dejará al objeto en el estado ©0. La fórmula © debe serverdadera en el estado previo a la ocurrencia del evento e. La fórmula ©0 especi…cael efecto que el evento ejecutado tiene sobre los valores de los atributos del objeto.Así pues la evaluación de un determinado evento se llevará a cabo a través de laimplementación de un método eval_evento cuyos argumentos serán los argumentosdel evento. Para cada evento e de una clase, se generará un método cuyo cuerpo seobtendrá de la siguiente forma:

1. Una sentencia condicional que compruebe si el objeto se encuentra en el estado©: Si esta fórmula no está especi…cada signi…ca que se cumplirá siempre, por loque no será necesario generar la sentencia condicional.

2. Un conjunto de sentencias de asignación que modi…carán los atributos del objetosegún se especi…ca en la fórmula ©0.

7 Lo mismo se asumirá con las restricciones de integridad.


En la clase Empleado se ha especi…cado la siguiente evaluación para el eventopagar (notación OASIS):

valuations {De Empleado}[pagar] salario:=sueldo_base+boni…cacion;{el empleado cobra el sueldo base más la boni…cación}

La implementación de la evaluación especi…cada en el ejemplo según la propuestade generación, se implementará mediante el método:

protected void eval_pagar(){

salario=sueldo_base+bonificacion;}

Comprobación de Restricciones de Integridad

Tras la realización de las evaluaciones, se debe comprobar que los cambios producidossobre los atributos no violan ninguna restricción de integridad (RI) establecida sobreel estado del objeto, ya que las RI deben cumplirse en cada estado admisible delobjeto. La implementación de la comprobación de las RI se llevará a cabo a través dela implementación de un método comprobar_restricciones_integridad por cadaclase. Este método no tendrá argumentos, y se encargará de veri…car que la evaluaciónrealizada lleva al objeto a un estado válido. El cuerpo de este método se obtendrá dela siguiente forma:Para cada fórmula © que de…ne una RI, se generará:

1. Una sentencia condicional que compruebe si se cumple la RI ©.

2. Una excepción que mostrará un mensaje de error “violación de restricción deintegridad” cuando no se cumpla la RI.

Las restricciones a comprobar pueden ser estáticas y dinámicas. La comprobaciónde las restricciones dinámicas es más compleja de implementar que la de las estáticas,ya que las dinámicas se deben comprobar durante toda la vida del objeto. La im-plementación en entornos OO industriales del proceso de comprobación que se utilizase presenta de manera detallada en [179, 180]. Las ideas de este proceso adaptan aOASIS el trabajo presentado por Lipeck en [133]. De forma resumida e intuitiva,esta propuesta se basa en la construcción de un grafo de transición que describirá losciclos de vida válidos del objeto con respecto a sus RI dinámicas. Para la construc-ción del grafo se presentan una serie de equivalencias que permiten descomponer unafórmula temporal, en una parte temporal y una atemporal. Los arcos del grafo detransición que se generará estarán etiquetados con una fórmula atemporal y los nodosdestino con una fórmula temporal, de manera que cada vez que ocurra un cambiode estado8, la comprobación de las RI se reducirá a la comprobación de una condi-ción estática representada por la fórmula atemporal del grafo. La monitorización delcumplimiento de las restricciones de integridad dinámicas a lo largo de la vida delobjeto, se realizará mediante los algoritmos de monitorización que se ejecutarán en lacomprobación de la RI.

8Los cambios de estado que puede sufrir el objeto en este caso se pueden clasi…car en: de creación,modi…cación o destrucción.


Continuando con la clase Empleado, en ella se ha especi…cado la restricción deintegridad: sueldo_base > 60.000 en la que se exige un mínimo salarial de 60.000pesetas para los empleados. El método comprobar_restricciones_integridad seimplementará en la clase Empleado de la siguiente manera:

protected void comprobar_restricciones_integridad()throws ViolacionRestriccion{if (!(sueldo_base > 60.000)) throw new ViolacionRestriccion;}

En la solución presentada, la implementación de la comprobación de las restric-ciones de integridad se lleva a cabo en el nivel de aplicación. Ésta no es la únicasolución ya que se puede implementar en el nivel de persistencia utilizando la poten-cia de los Sistemas Gestores de Bases de Datos (SGBD), e incluso la comprobación,en algunos casos, se puede situar en el nivel de presentación. La solución adoptadapretende concentrar en el nivel de aplicación toda la lógica de los objetos de negocioconstituyendo una solución portable a distintos SGBD.

Comprobación de Disparos

Una vez se ha comprobado que el nuevo estado del objeto no viola ninguna restricciónimpuesta sobre el objeto, para …nalizar la estrategia de ejecución se debe comprobarsi en el nuevo estado alcanzado, se cumple alguna condición de disparo.El tratamiento de los disparos ha sido tradicionalmente un tema de investigación

en la comunidad de las bases de datos, en especial en el contexto de las bases de datosactivas. Una propuesta muy conocida en esta área de trabajo ha sido el mecanismo delas reglas evento-condición-acción (ECA). Estas reglas están compuestas por un eventoque dispara la regla, una condición que describe una situación concreta, y una acciónque deberá realizarse si la condición se satisface. Los disparos del modelo OASISpueden ser vistos como un subconjunto de las reglas ECA.Así pues, un disparo en OASIS se de…ne como una regla activa cuya representa-

ción en lógica dinámica se especi…ca de la siguiente manera: © [:e] false. Como seha visto en el capítulo 5, esta fórmula signi…ca que si © se cumple, la activación delevento e se debe producir de forma obligatoria. Si © se cumple y ocurre otro eventoque sea distinto de e, el sistema se bloquea, forzando a que ocurra e: Los disparos soneventos que deben activarse cuando la condición, especi…cada en ©; se cumpla. En elmodelo OASIS se pueden ver como reglas activas donde el evento de la regla es elevento que está siendo activado actualmente (el que ha producido que el cambio deestado del objeto haga que la fórmula © sea verdadera), la condición es la fbf © quedebe evaluarse, y la acción es el evento e que debe activarse si se cumple la condición.Para la implementación de los disparos se propone una estrategia, en la cual los

disparos se comprueban mediante un método comprobar_disparos sin argumentos.Este método comprobará si la/s condiciones de disparo se cumplen y si es así lanzaráel/los eventos correspondientes. Para cada clase se generará un método cuyo cuerpose construirá de la siguiente forma:Para cada fórmula que de…ne una condición de disparo se generará:

1. Una sentencia condicional que compruebe si se cumple la condición de disparo©


2. Una sentencia que llame al evento e cuando se cumpla ©.

OO-Method permite especi…car distintos cali…cadores para de…nir el alcance delos disparos, self, object y class, por lo que se tendrá que implementar la semánticade cada uno de los tipos de disparos.Como ejemplo, se tiene para la clase Vendedor el siguiente disparo self::bonificar-

(-bonificacion) when {bajas=5} que le quita la boni…cación si tiene 5 bajas. Se-gún lo propuesto en este apartado, el método comprobar_disparos se implementaráen la clase Vendedor como sigue:

protected void comprobar_disparos(){

if (bajas==5) bonificar(-bonificacion);// si se cumple la condición de disparo// se debe activar el evento boni…car

}

La especi…cación e implementación de disparos según el modelo OASIS es un te-ma complejo cuyo estudio no es un objetivo primordial de esta tesis. En este contexto,el autor ha participado en el desarrollo de un trabajo [39] en el cual se presenta unacaracterización completa de los disparos a nivel de especi…cación y de ejecución. Eltrabajo introduce propuestas para su análisis estático, estudiando propiedades comolas terminación y la con‡uencia. Además, se han estudiado distintos factores de deci-sión que permiten de…nir de forma precisa un modelo de ejecución para los disparos.Se ha caracterizado su modo de acoplamiento, el orden de ejecución y la plani…cación,así como, la resolución de con‡ictos en el caso de tener varios disparos en espera deejecución y la resolución de errores. Por último, el citado trabajo también proporcionauna solución de implementación basada en colas de prioridad.

Optimización de Acciones en la Estrategia de Ejecución

La presentación de las técnicas utilizadas para la implementación de la estrategia deejecución, se ha intentado hacer de forma clara y sencilla con la intención de ofreceruna solución general a la implementación del comportamiento de una clase especi…ca-da según el modelo formal OASIS. Es importante destacar que el interés del trabajode tesis se centra en analizar cómo se ven afectadas estas acciones en el contexto delnuevo modelo de relaciones taxonómicas introducido. De todas formas se han des-arrollado algunos trabajos que permiten optimizar la comprobación de restriccionesde integridad [180] y de disparos [39]. Estas propuestas serán aplicables más adelantecuando se presente el proceso de generación de código para las relaciones taxonómicas.Con la solución presentada, los métodos de comprobación de restricciones y de

disparos, en cada ejecución de un evento, realizan la comprobación de si se cumplentodas las restricciones y todas las condiciones de disparo especi…cadas en la clase delobjeto receptor del evento. Esta solución en ocasiones puede llegar a sobrecargar elsistema y realizar operaciones de comprobación innecesarias si los atributos de lasrestricciones de integridad no se han visto modi…cados por el evento o las condicionesde disparo no se cumplen y no se efectúan realmente los disparos. Para evitar estosinconvenientes, sería deseable que la comprobación de restricciones y disparos sólo sellevara a cabo cuando el evento modi…que algún atributo que forme parte de algunarestricción de integridad o condición de disparo. Para conseguir esto, se pueden


de…nir métodos de comprobación de restricciones y disparos de forma individual, esdecir, se tendrán tantos métodos de comprobación como restricciones y disparos sehayan especi…cado. Se creará un método por cada evento que realizará llamadas alos métodos de comprobación de las restricciones o condiciones de disparos que se venafectadas por dicho evento. Este método será el que se llamará en la implementaciónde la estrategia de ejecución del evento.Para poder implementar esta optimización antes de generar el código se deberá

analizar la especi…cación para conocer qué eventos son los que pueden modi…car cadarestricción de integridad o condición de disparo. Esta información se extrae del modelofuncional en el cual se especi…ca declarativamente qué atributos modi…ca cada evento.Un ejemplo de la optimización presentada se puede ver a continuación en la im-

plementación de un nuevo evento trasladar de Empleado que modi…ca los atributospoblación y telefono, con lo cual se comprobarán las restricciones de integridad enlas que participan estos atributos.

public void trasladar(String nueva_poblacion, String nuevo_telefono){...//Resto de estrategiacomprobar_restricciones_trasladar()...//Resto de estrategia}protected void comprobar_restricciones_trasladar(){comprobar_restriccion_poblacion();comprobar_restriccion_telefono();}

7.4 Las Relaciones Taxonómicas en el Nivel de Apli-cación

Una vez seleccionados y especializados los patrones de diseño, se lleva a cabo el procesode generación de código propuesto por el Modelo de Ejecución Extendido. En estaetapa se de…nen de forma precisa una serie de correspondencias entre los patrones dediseño especializados y las distintas relaciones taxonómicas. Estas correspondenciastrasladan la estructura y el comportamiento asociado al patrón conceptual a unaestructura de diseño especializada. Este proceso es completamente automatizabley se realiza de forma que la implementación …nal preserve la semántica del patrónconceptual según se he de…nido en el modelo OASIS.Las correspondencias a de…nir determinarán:

² Las clases y su estructura que implementan en el espacio de la solución el patrónconceptual del espacio del problema. Esta etapa proporciona:

– La distribución de atributos en cada clase de la estructura de diseño.

– Los métodos que implementarán los eventos.

² La creación y destrucción de instancias.

7.5. Especialización Estática y Dinámica en el Espacio de la Solución 221

² La implementación de los criterios de especialización.² La implementación de las restricciones estáticas y dinámicas.² La implementación de las restricciones de multiplicidad.² La implementación del comportamiento especializado de…nido por la estrategiade ejecución.

En los siguientes apartados se presenta cómo se de…nen dichas correspondenciaspara los tres tipos de relaciones taxonómicas presentadas: especialización estática ydinámica, y roles. Estas correspondencias proporcionarán los componentes softwaredel nivel de aplicación en la arquitectura propuesta. El proceso de generación decódigo se documenta utilizando el lenguaje de programación Java.

7.5 Especialización Estática y Dinámica en el Espa-cio de la Solución

El patrón State se ha seleccionado como la estructura de diseño adecuada para repre-sentar …elmente los patrones conceptuales: especialización estática y especializacióndinámica. Estos patrones poseen a nivel de implementación diversas característicascomunes, por ello en este apartado se ha optado por presentar de forma conjuntacómo se de…nen las correspondencias que permiten representarlos en el espacio de lasolución.

7.5.1 De…nición de la Estructura de Clases

El patrón State es un patrón de comportamiento que permite a un objeto alterar sucomportamiento cuando su estado interno cambia. De este modo parecerá que cambiade clase. Como se ha presentado anteriormente, esta solución se basa en la técnica dela delegación a una clase oculta. La delegación es posible porque todos los métodosde las subclases se sitúan en el interfaz de la superclase, y se de…ne una variable deinstancia en la superclase para referenciar a un objeto de una de las subclases. Elpatrón State, como se puede ver en la …gura 7.5, se caracteriza porque en él participantres tipos de clases: EstadoConcreto, Estado y Contexto. Las clases EstadoConcretoson subclases de la clase Estado. Cada subclase implementa el comportamiento de-pendiente del estado de la clase Contexto. La clase Estado es una clase abstracta quede…ne un interfaz para encapsular el comportamiento asociado con cualquier estadode la clase Contexto. El interfaz de la clase Contexto posee todos los métodos detodas las subclases EstadoConcreto. Esta clase mantiene un atributo objeto-valuadoque sirve para almacenar una instancia de una de las subclases EstadoConcreto. Esteatributo se llama Objeto Estado y de…ne el estado actual de un objeto de la claseContexto. Un objeto de la clase Contexto delegará su comportamiento especí…co delestado al Objeto Estado.Dada una partición (estática o dinámica) fS1; :::; Sng de la clase P , su represen-

tación estructural vendrá determinada por las clases (ver …gura 7.8) CP (Contexto),CA (Estado) y fC1; :::; Cng (EstadoConcreto), tal que:


CP CA

C1 CN..........

Figura 7.8: Estructura de clases que implementan el Patrón State

² CP poseerá:

– Un conjunto de atributos AtrCP propios de P (no modi…cados por ningunasubclase de la partición), y un atributo ACA (llamado Objeto Estado) quealmacenará un objeto de una de las subclases de fC1; :::; Cng:

– Un conjunto de métodos públicos MCP que implementarán los eventosEvP [EvS1 [ ::: [EvSn .¤ Los eventos EvP se implementarán en CP . Estos eventos en las parti-ciones dinámicas se llamarán eventos independientes del estado.

¤ Los métodos que implementen los eventos EvS1 [ ::: [ EvSn lo haránmediante delegación sobre el objeto ACA . Este conjunto de eventos enlas particiones dinámicas se llamará eventos dependientes del estado.

² CA será una clase abstracta que poseerá:

– Un conjunto de atributos AtrCA = AtrS1\:::\AtrSn . Estos atributos seránlos que tienen en común las subclases de la partición y que son modi…cadosen alguna de las subclases.

– Un conjunto de métodos públicos abstractos MCA que de…nirán el interfaznecesario para implementar el conjunto de eventos EvCA = EvS1 [ ::: [EvSn . Cada una de las subclases de fC1; :::; Cng rede…nirá estos métodos.

² fC1; :::; Cng serán subclases de CA y cada Ci poseerá:

– Un conjunto de atributos AtrCi para almacenar AtrSi (atributos nuevosde Si).

– Un conjunto de métodos públicos MCi que implementarán EvSi (eventosnuevos de Si) mediante rede…nición de los métodos de CA.

La solución adoptada para saber qué atributos posee cada clase se basa en unavariación del patrón State llamada State Members. Este patrón ayuda a determinarsi un atributo debe estar en CP , CA o en una clase perteneciente a fC1; :::; Cng. El


patrón State aplicado sin ninguna modi…cación no permite que la subclases tenganacceso a los atributos de la superclase, por lo que la visibilidad se reduce a laspropiedades de la subclase. Para conseguir acceder a las propiedades de la superclaseCP desde CA y las subclases fC1; :::; Cng el patrón se debe especializar de una de losdos formas siguientes:

² Se exigirá que los métodos de CA y fC1; :::; Cng posean un argumento adicionalque será una referencia al Contexto (es decir al objeto de la clase CP con el queestán relacionados). Este argumento se pasará en las llamadas a dichos métodos,por lo que a través de dicha referencia se podrá acceder a las propiedades deCP .

² Se convertirá la relación de agregación existente entre la clase Contexto y Estadoen una asociación para permitir la navegabilidad desde la clase Estado haciala clase Contexto. De esta forma en el diseño de CA se incluirá un atributoque referenciará a CP . En la construcción del objeto estado (en el métodoconstructor) se la pasará una referencia al objeto Contexto.

Para un mejor seguimiento se van a utilizar dos modelos de ejemplo desarrolladoscompletamente en el Apéndice A: una partición estática en la que la clase Persona seespecializa en Hombre y Mujer (ver …gura 7.9), y una partición dinámica en la que unaclase Empleado9 se puede especializar dinámicamente en Vendedor y Responsable(ver …gura 7.11).La …gura 7.10 muestra el diseño (en notación UML) después de aplicar las corres-

pondencias propuestas. La implementación Java de dicho diseño es la siguiente:

public class Persona{

String dni;String nombre;String apellidos;String direccion;String telefono;int edad;String sexo;int revisiones;// Atributos de la claseEstadoPersona obj_estado_sexo;// Objeto Estado que representa a la ParticionEstadosDTE EstadoDTE= E_INICIAL;// estado actual en el DTEpublic Persona();// método constructor Javapublic void crear();// método que implementa el evento constructorpublic void eliminar();// método que implementa el evento destructorpublic void incrementar_edad();

9Empleado, en el ejemplo del Apéndice A, es a su vez subclase de rol de Persona, aunque parasimpli…car la presentación, este aspecto no se trata en este apartado.


Personadninombreapellidosdirecciontelefonoedadsexorevisiones

cambiar_direccion()cambiar_telefono()incrementar_edad()revision_medica()crear()eliminar()matricular()contratar()

se xo

<<sexo=M>>

Mujerhijosestado


<<sexo = H>>

HombrefechaIni_ServiciofechaFin_ServicioServicioDuracionMesesDestino


Figura 7.9: Partición Estática de la Clase Persona


HombreServiciofecha_iniServiciofecha_finServicioDuracionMeses

finalizar_servicio()comenzar_servicio()sortear()

Mujerhijosestado

dar_a_luz()quedar_embarazada()

Personadninombreapellidosdirecciontelefonoedadsexorevisiones

crear()incrementar_edad()eliminar()dar_a_luz()quedar_embarazada()cambiar_telefono()comenzar_servicio()finalizar_servicio()sortear()matricular()contratar()revision_medica()cambiar_direccion()

EstadoPersona

dar_a_luz()quedar_embarazada()comenzar_servicio()finalizar_serivicio()sortear()

Figura 7.10: Diseño de la Partición Estática de Persona

public void comenzar_servicio(date fechaI, fechaF);public void finalizar_servicio();public void dar_a_luz(int num_hijos);public void quedar_embarazada();public void cambiar_direccion(String nueva_direccion);public void cambiar_telefono(String nuevo_telefono);public void revision_medica();public void sortear(String Serv, int Duracion, String Dest);public void matricular();public void contratar(int s_base);...// además de estos métodos se generarán automáticamente...// métodos de consulta

}

public abstract class EstadoPersona{

Persona padre;EstadosDTE EstadoDTE= E_INICIAL;// estado actual en el DTEpublic void abstract comenzar_servicio(date fechaI, fechaF);public void abstract finalizar_servicio();public void sortear(String Serv, int Duracion, String Dest);public void abstract dar_a_luz(int num_hijos);public void abstract quedar_embarazada();

}


public class Hombre extends EstadoPersona{

String Servicio;long duracionMeses;date fecha_iniServicio;date fecha_finServicio;String Destino;public Hombre();public void comenzar_servicio(date fechaI);public void finalizar_servicio();public void sortear(String Serv, int Duracion, String Dest);

}

public class Mujer extends EstadoPersona{

int hijos;String estado;public Mujer();public void dar_a_luz(int num_hijos);public void quedar_embarazada();

}

<<dinámica>>puesto

Empleadocod_empleadoseccionpuestosalariosueldo_basetelefonofecha_contratacionfecha_revision_sueldobonificacionbajas


Ve nd ed ornVentas


ResponsablenVendedores

asignar_vendedores()quitar_vendedores()rebajar()

Figura 7.11: Partición Dinámica de la clase Empleado basada en Eventos de Migración


Vendedorn_ventas

promocionar()vender()

Responsablen_vendedores

rebajar()asignar_vendedores()quitar_vendedores()

Empleadosalariobonificacioncod_empleadoseccionsueldo_basetelefonofecha_contratacionfecha_revision_sueldopuestobajas

pagar()despedir()contratar()subir_sueldo()inciar_mes()faltar_al_trabajo()bonificar()cambiar_puesto()cambiar_seccion()vender()promocionar()rebajar()asignar_vendedores()quitar_vendedores()

EstadoEmpleado

vender()promocionar()rebajar()asignar_vendedores()quitar_vendedores()

Figura 7.12: Diseño de la Partición Dinámica de Empleado


La …gura 7.12 muestra el diseño (en notación UML) después de aplicar las corres-pondencias propuestas. La implementación Java de este diseño es la siguiente:

public class Empleado{

String cod_empleado;long salario;long bonificacion;String seccion;int sueldo_base;String telefono;Date fecha_contratacion;Date fecha_revision_sueldo;String puesto;int bajas;// Atributos de la claseEstadoEmpleado obj_estado_tipoEmpleado;// Objeto EstadoEstadosDTE EstadoDTE= E_INICIAL;// estado actual en el DTEpublic Empleado();// método constructor Javapublic contratar(int s_base);// método que implementa el evento constructorpublic despedir();// método que implementa el evento destructorpublic void pagar();public void cambiar_seccion(String NuevaSeccion);public void cambiar_puesto(String NuevoPuesto);public void cambiar_telefono(String NuevoTelefono);public void subir_sueldo(long incremento);public void iniciar_mes();public void faltar_al_trabajo();public void bonificar(long Cantidad);public void promocionar();public void rebajar();public void asignar_vendedores(int Num_Vendedores);public void quitar_vendedores(int Num_Vendedores);public void vender(int n_productos);public String nombre_clase();// método clasi…cador -> devuelve el nombre de la clase// del Objeto Estado actual

}

abstract public class EstadoEmpleado{

EstadosDTE EstadoDTE= E_INICIAL;Empleado padre;...public abstract void promocionar();public abstract void rebajar();public abstract void vender(int n_productos);


public abstract void asignar_vendedores(int Num_Vendedores);public abstract void quitar_vendedores(int Num_Vendedores);public abstract String nombre_clase();// devuelve el nombre de la clase del Objeto Estado actual

}

private class Vendedor extends EstadoEmpleado{

int n_ventas;...public Vendedor();// método constructor Javapublic void promocionar();public void vender(int n_productos);public String nombre_clase();

}

private class Responsable extends EstadoEmpleado{

int n_vendedores;...public Responsable();// método constructor Javapublic void rebajar();public void asignar_vendedores(int Num_Vendedores);public void quitar_vendedores(int Num_Vendedores);public String nombre_clase();

}

7.5.2 Implementación de la Estrategia de Ejecución

El patrón Template Method se incorporará al patrón State para implementar la estra-tegia de ejecución. La aplicación del patrón Template Method se realizará de formaque se sigan las pautas de…nidas en el capítulo 5 para garantizar la compatibilidad decomportamiento.La implementación de la estrategia de ejecución para eventos de particiones (es-

táticas y dinámicas) se llevará a cabo de la siguiente manera:

² En CP , CA y en las subclases fC1; :::; Cng se de…nirán aquellos métodos que im-plementen cada una de las acciones de la estrategia de ejecución. Esos métodosen CP sólo serán visibles por las subclases (protegidos) y en CA serán públicos,aunque sólo accesibles a través de CP (por ser una clase oculta).

– En CP se implementarán las acciones de la estrategia de ejecución especi-…cadas en P .

– En CA los métodos que implementan las acciones de la estrategia de eje-cución se declararán cómo métodos abstractos.


– Cada subclase Ci 2 fC1; :::; Cng;8i = 1; :::; n implementará los métodosabstractos de CA (comentados en el punto anterior) cuando en la espe-ci…cación se haya añadido o rede…nido alguna precondición, evaluación,restricción de integridad, disparo, o se haya extendido el proceso que de…-ne el ciclo de vida.

² CP es la clase del patrón que contendrá la implementación de los métodosMCP

que implementarán los eventos EvP [EvS1 [ :::[EvSn . La implementación deestos métodos se llevará a cabo dependiendo de la especi…cación del evento:

– Los eventos especi…cados en P que no extienden su comportamiento enlas subclases, se implementarán en CP mediante métodos que ejecutaránsecuencialmente las acciones de la estrategia de ejecución implementadasen CP .

– Los eventos nuevos especi…cados en alguna subclase Si 2 fS1; :::; Sng;8i =1; :::; n; que sólo añaden comportamiento sin modi…car ni rede…nir propie-dades heredadas, se implementarán en CP delegando su ejecución en elObjeto Estado que llamará al método que implementa dicho evento en lasubclase Ci. Este método ejecutará las acciones de la estrategia de ejecu-ción implementadas en Ci.

– Los eventos especi…cados en P que en alguna de las subclases de la particiónfS1; :::; Sng re…nan su comportamiento mediante un proceso de extensiónañadiendo nuevas precondiciones, evaluaciones, o modi…cando atributos delas restricciones y condiciones de disparo, se implementarán en CP ejecu-tando secuencialmente las acciones de la estrategia de ejecución. En estecaso la implementación en CP de cada una de las acciones de la estrategiade ejecución tendrá en cuenta que la subclase extiende el comportamientode forma compatible, por lo que ejecutará localmente las acciones especi…-cadas en P y delegará en el Objeto Estado para ejecutar las nuevas accionesespeci…cadas en la subclase Ci.

– Los eventos especi…cados en P o en alguna subclase Si 2 fS1; :::; Sng;8i =1; :::; n que re…nan en la subclase el comportamiento heredado de P , seimplementarán en CP ejecutando secuencialmente las acciones de la estra-tegia de ejecución. En este caso cada una las acciones de la estrategia deejecución tendrá en cuenta si la subclase:

¤ extiende el comportamiento, añadiendo nuevas evaluaciones, nuevasprecondiciones (si el evento no tenía de…nidas), restricciones de in-tegridad y disparos cuya fórmula está constituida por algún atributomodi…cado por la nueva evaluación. Cada método de la estrategia, eje-cutará las acciones implementadas en CP (si tenía especi…cada alguna)y a continuación delegando sobre el Objeto Estado en ACA ejecutará lasacciones implementadas en la subclase activa Ci. Por ejemplo, cuandose de…nen en la subclase nuevas evaluaciones para un evento heredado,la evaluación de dicho evento será la unión de las evaluaciones de…nidaspara la superclase y la subclase activa.

¤ rede…ne el comportamiento de forma compatible. Si es así se ejecu-tarán directamente a través de la delegación sobre el Objeto Estado


en ACA , las acciones de la estrategia de ejecución implementadas enla subclase activa Ci. Al ser las rede…niciones más restrictivas éstasprevalecerán.

Una vez se ha presentado lo que deben implementar las acciones de la estrategiade ejecución, queda por de…nir cómo se aplican estas ideas a cada una de las accionesde la estrategia de ejecución, de forma que se sigan las pautas de…nidas para respetarla compatibilidad de comportamiento.


El proceso de construcción de los DTE de las subclases estáticas y dinámicas propues-to en la tesis, garantiza que los DTE se especializan de forma adecuada cumpliendoel principio de compatibilidad de comportamiento aplicado a los DTE. Como las par-ticiones son completas se presupone que siempre existirá un objeto de alguna de lassubclases de la partición y que no existirá nunca un objeto que pertenezca solamentea la clase padre. La restricción de completitud y la garantía de que el ciclo de vidade la subclase se especializa correctamente, permitirán simpli…car la implementaciónde la comprobación de la transición de estado en el DTE, porque sólo será necesarioimplementar en cada una de las subclases fC1; :::; Cng el método de comprobacióndel DTE utilizando la especi…cación del DTE especializado. La implementación deeste método se llevará a cabo adaptando la propuesta de generación presentada an-teriormente. El método comprobar_transicion_estado de CP se implementará dela siguiente manera:

protected void comprobar_transicion_estado(Eventos Evento)throws EventoNoPermitido{

ObjetoEstado.comprobar_transicion_estado(Evento);}

Dicha propuesta será válida en el caso de que exista ortogonalidad los DTE, si noes así se debe una solución de implementación a la integración de los DTE propuesta.En la solución conceptual presentada se propone que el DTE de la especie será

la unión de los DTE de las subclases de las cuales es instancia (una subclase porpartición), este DTE poseerá los estados y transiciones comunes de las subclasesjunto con los estados y transiciones propios de cada subclase. Así pues, cuando unobjeto esté en un estado que tengan en común las subclases, podrá recibir eventospresentes en la signatura de cualquiera de las subclases que comparten dicho estado.Si está en un estado del DTE propio de una determinada subclase, entonces las demássubclases (de particiones diferentes cada una) no podrán activar eventos hasta que elobjeto vuelva a un estado que compartan (heredado de la superclase).Una solución para implementar una comprobación del DTE que re‡eje adecua-

damente la propuesta presentada consiste en que las subclases fC1; :::; Cng puedanleer y modi…car el atributo estadoDTE de la clase CP . Para conseguirlo CA tendráun atributo ObjetoClasePadre que referenciará al objeto de la clase CP con el quese relacionan las instancias de las subclases fC1; :::; Cng. Inicialmente sería su…ciente


Persona

incrementar_edad

crear

Embarazada

destruir

dar_a_luz

quedar_embarazada destruirincrementar_edad

Figura 7.13: DTE de la subclase estática Mujer

con que cada una de las subclases de las distintas particiones modi…caran el atri-buto estadoDTE del ObjetoClasePadre sin necesidad de poseer su propio atributoestadoDTE, pero esta solución no es escalable ni homogénea debido a que, si cual-quiera de las subclases de la partición fuera especializada de nuevo, las subclases deésta no tendrían acceso al estadoDTE de su clase padre. Una solución adecuada esque todas las clases posean el atributo estadoDTE, en este caso lo tendrán CP y CA(heredándolo las subclases fC1; :::; Cng). Este atributo almacenará en las subclases elvalor del atributo estadoDTE de CP .Para implementar la comprobación de transiciones en el DTE, se seguirá utilizando

la técnica de implementación presentada anteriormente, exceptuando que cuando seproduzca el cambio de estado en el DTE, el nuevo estado se asignará al atributoestadoDTE del ObjetoClasePadre. Para mantener en todo momento actualizado elvalor del atributo estadoDTE de cada una de las subclases de las particiones que tengala clase padre se aplicará el patrón Observer [78], donde la clase CP será el Sujetoobservado y las subclases activas de cada partición serán los objetos Observadores. Elatributo observado será el estadoDTE del Sujeto y el atributo a actualizar serán losatributos estadoDTE de cada una de las subclases activas de la partición. Así pues,cuando el atributo observado sea modi…cado por alguna subclase, el objeto observadonoti…cará esta modi…cación a cada uno de los objetos observadores, actualizando elvalor de su atributo estadoDTE con el valor actual de estadoDTE del objeto de CP .Como ejemplo de aplicación de la propuesta de implementación se presenta a

continuación la implementación del método comprobar_transicion_estado basadoen el DTE de la subclase Mujer10 (ver …gura 7.13) que es una especialización del DTEde la clase Persona.

public void comprobar_transicion_estado(Eventos Evento)throws EventoNoPermitido{switch(estadoDTE){

case E_INICIAL :

10DTE simpli…cado. Se han eliminado algunos eventos para no complicar el ejemplo en exceso.


switch(Evento){

case crear:ObjetoClasePadre.actualizar_estado_DTE(E_Persona);break;

default: throw new EventoNoPermitido();}

case E_Persona:switch(Evento)

{case incrementar_edad:

ObjetoClasePadre.actualizar_estado_DTE(E_Persona)break;case quedar_embarazada:

ObjetoClasePadre.actualizar_estado_DTE(E_Embarazada)break;case destruir:

ObjetoClasePadre.actualizar_estado_DTE(E_DESTRUIDO)break;

default: throw new EventoNoPermitido();}

case E_Embarazada:switch(Evento){

case incrementar_edad:ObjetoClasePadre.actualizar_estado_DTE(E_Embarazada)

break;case dar_a_luz:

ObjetoClasePadre.actualizar_estado_DTE(E_Persona)break;

case destruir:ObjetoClasePadre.actualizar_estado_DTE(E_DESTRUIDO)

break;default: throw new EventoNoPermitido();}

}}

En este método, cuando se actualiza el atributo EstadoDTE del ObjetoClasePadre(porque se permite una determinada transición), se efectuará, dentro del mismo méto-do de actualización de la clase padre, una llamada al método actualizar_estado_DTEde cada una de los objetos activos en cada partición (objetos observadores) cuyo ar-gumento de entrada será el estado actual en el DTE, de esta manera se actualizarántodos los estados de todas las subclases activas. A continuación se presenta comoejemplo el método actualizar_estado_DTE de la clase Persona.

public void actualizar_estado_DTE(EstadosDTE NuevoEstado){

estadoDTE=NuevoEstado;obj_estado_sexo.actualizar_estado_DTE(estadoDTE);//aquí se realizarían las llamadas a todos los objetos estado “observadores”


//(uno por subclase activa) en cada una de las particiones//.............

}


El método comprobar_precondicion_evento de un determinado evento de una sub-clase, se implementará en CP de diversas formas, dependiendo de las siguientes con-diciones:

² si el evento es heredado y no se ha rede…nido su precondición en la subclase,entonces en CP se implementará la comprobación de la precondición especi…cadaen P según se ha visto anteriormente.

² si el evento es heredado y se ha rede…nido (manteniendo la compatibilidad decomportamiento) o añadido una precondición en la subclase (porque no teníaninguna especi…cada en P ), entonces la implementación en CP ejecutará la com-probación de la precondición implementada en la subclase mediante delegaciónsobre el Objeto Estado.

² si el evento es nuevo y se ha de…nido una precondición sobre éste, entonces suimplementación será la ejecución mediante delegación sobre el Objeto Estadode la comprobación de la precondición implementada en la subclase.

En el ejemplo de la …gura 7.11, el evento subir_sueldo posee en la clase Empleado(ver especi…cación en Apéndice A) la siguiente precondición subir_sueldo(N) if ((hoy- fecha_revision_sueldo) >= 12). En la subclase Responsable se ha rede…nido dichaprecondición haciéndola más restrictiva (compatibilidad de comportamiento) de lasiguiente manera subir_sueldo(N) if ((fecha_actual - fecha_ultima_revision >= 12)and nVendedores>100).Siguiendo las pautas de…nidas en este apartado el método comprobar_precondicion-

_subir_sueldo se implementará en la clase Empleado de la siguiente manera:

protected void comprobar_precondicion_subir_sueldo()throws ViolacionPrecondicion{

if (obj_estado_tipoEmpleado.nombre_clase().equals(‘‘Responsable’’))// el objeto está especializado en la subclase Responsable

obj_estado_tipoEmpleado.comprobar_precondicion_subir_sueldo();// ejecutar el método de la subclase porque el evento subir_sueldo// ha rede…nido la precondición en la subclase Responsable

break;}

Y en la subclase Responsable tendrá la siguiente implementación:

protected void comprobar_precondicion_subir_sueldo()throws ViolacionPrecondicion{


if (!((DiferenciaFechas(new Date()11,fecha_ultima_revision) >= 12)&& (nVendedores>100))

throw new ViolacionPrecondicion();// comprueba la precondición del evento subir_sueldo

}

Realizar Evaluación

El método eval_evento se implementará en CP para cada evento (EvP [EvS1 [ :::[EvSn). Su implementación dependerá de las siguientes condiciones:

² Si no se han de…nido nuevas evaluaciones en Si, el método implementará laevaluación especi…cada en P para dicho evento.

² Si se han de…nido nuevas evaluaciones en Si para dicho evento, el método im-plementará la evaluación especi…cada en P y a continuación delegará sobre elObjeto Estado la ejecución del método que implementa el efecto de la nuevaevaluación especi…cada en la subclase. Así se cumplirá que las evaluacionesserán la unión de las evaluaciones de…nidas para la subclase y su superclase.Un caso particular de éste será aquél en el que el evento sólo modi…ca atribu-tos nuevos en Si. En este caso el método eval_evento únicamente delegarásobre el Objeto Estado la ejecución del método que implementa el efecto de laevaluación nueva especi…cada en la subclase.

Como ejemplo de aplicación de esta propuesta, se puede ver el código de los méto-dos que implementan algunas de las evaluaciones especi…cadas en el modelo funcionalpara las clases Empleado y Vendedor (ver especi…cación en Apéndice A). Algunas deestas evaluaciones son:

valuations {De Empleado}[pagar] salario:= sueldo_base + boni…cacion;[subir_sueldo(Incremento)] sueldo_base = sueldo_base + Incremento;[subir_sueldo(Incremento)] fecha_revision_sueldo = hoy;....

valuations {De Vendedor}[vender(n_productos)] nVentas = nVentas + n_productos;

{cuando vende, nVentas se incrementa en el número de productos vendidos}boni…cacion <100000 and (boni…cacion + n_productos*10) <=100000[vender(n_productos)] boni…cacion = boni…cacion + n_productos*10;

{cada vez que realiza una venta se le boni…ca en 10 pesetas por producto}boni…cacion <100000 and (boni…cacion + n_productos*10) >100000[vender(n_productos)] boni…cacion = 100000;

{si se realiza una venta y la boni…cación excede de 100000}{la boni…cación será 100000}

[subir_sueldo(Incremento)] boni…cacion:=0;{cuando se le sube el sueldo se inicializa la boni…cación}

11Crea la fecha de hoy


Según la propuesta presentada, los métodos que realizan las evaluaciones serán lossiguientes:En la clase Empleado:protected void eval_pagar(){

salario=sueldo_base+bonificacion;// implementa la evaluación de Empleado

}

protected void eval_subir_sueldo(int incremento){

sueldo_base=sueldo_base+incremento;fecha_revision_sueldo = new Date();if (obj_estado_tipoEmpleado.es_clase().equals(‘‘Vendedor’’))

obj_estado_tipoEmpleado.eval_subir_sueldo(nIncremento);// implementa las evaluaciones de Empleadoobj_estado_tipoEmpleado.eval_subir_sueldo(incremento);// delega en el Objeto Estado para realizar la evaluación// especi…cada en Vendedor que inicializa boni…cación a 0

}

protected void eval_vender(int n_productos){

if (obj_estado_tipoEmpleado.es_clase().equals(‘‘Vendedor’’))obj_estado_tipoEmpleado.eval_vender(n_productos);

// el evento es de la subclase Vendedor y// sólo modi…ca atributos nuevos,// por lo que delega en el Objeto Estado

}

En la clase Vendedor:protected void eval_vender(int n_productos){

nVentas= nVentas+n_productos;if ((bonificacion <100000) && ((bonificacion + n_productos*10) <=100000))

bonificacion = bonificacion + n_productos*10else if ((bonificacion <100000) &&

((bonificacion + n_productos*10) >100000))bonificacion = 100000;

}

protected void eval_subir_sueldo(int incremento){

bonificacion=0;}

Comprobación de las Restricciones de Integridad en el Nuevo Estado

El método que comprobará si se cumplen las restricciones será el método comprobar_-restricciones_integridad. El código a implementar en CP se obtendrá según lassiguientes condiciones:


² Si la subclase no ha rede…nido o añadido restricciones de integridad entonces elmétodo comprobar_restricciones_integridad de CP implementará las res-tricciones de P según se ha visto anteriormente.

² Si la superclase posee una serie de restricciones de…nidas y en la subclase se hanespeci…cado restricciones nuevas, entonces el método implementará la compro-bación de las restricciones especi…cadas en P y a continuación, delegará sobreel Objeto Estado la ejecución del método que implementa en la subclase dichacomprobación sobre las restricciones nuevas. Así se cumplirá que las restriccio-nes serán la unión de las restricciones de…nidas para la subclase y su superclase.

² Si la subclase rede…ne algunas de las restricciones de la superclase, entoncesse ejecutará el método comprobar_restricciones_integridad implementa-do en la subclase. En este caso si existen muchas restricciones de integridadsería adecuado aplicar la optimización presentada anteriormente. De este mo-do el método de comprobación de restricciones implementado en CP llamarásecuencialmente al método de comprobación de cada una de las restricciones es-peci…cadas en P que no han sido rede…nidas y a continuación llamará mediantedelegación sobre el Objeto Estado a aquellas que han sido rede…nidas junto alas nuevas restricciones si se han de…nido.

En el ejemplo de la …gura 7.11, se ha especi…cado en la clase Empleado la restricciónde integridad12 boni…cacion <=100000. Esta restricción la ha heredado la subclaseVendedor, y la subclase Responsable la ha rede…nido de la siguiente manera boni-…cacion <=200000. En esta rede…nición existe compatibilidad de comportamientoporque la restricción especi…cada en la subclase Responsable implica lógicamentea la restricción de la superclase Empleado. El método comprobar_restricciones_-integridad se implementaría siguiendo las pautas propuestas de la siguiente manera.

En la clase Empleado:protected void comprobar_restricciones_integridad()throws ViolacionRestriccion{

if (obj_estado_tipoEmpleado.nombre_clase().equals(‘‘Responsable’’))// el objeto está especializado en la subclase Responsable

obj_estado_tipoEmpleado.comprobar_restricciones_integridad();else if (!(bonificacion<=100000))// el objeto está especializado en la subclase Vendedor// por lo que se comprueba la restricción especi…cada en Empleadothrow new ViolacionRestriccion();

}

En la clase Responsable:protected void comprobar_restricciones_integridad()throws ViolacionRestriccion{

if !(bonificacion<=200000) throw new ViolacionRestriccion();// comprueba la restricción de integridad rede…nida}

12Para simpli…car se supone que las clases solamente tienen especi…cada una restricción de inte-gridad. En el ejemplo del Apéndice A se presenta la implementación completa.



El método comprobar_disparos se implementará en CP dependiendo de las siguientescondiciones:

² Si la subclase no ha rede…nido o añadido ningún disparo entonces el métodocomprobar_disparos de CP implementará las comprobación de los disparos deP según se ha visto anteriormente.

² Si la superclase tiene disparos de…nidos y la subclase tiene además disparosnuevos, entonces el método implementará la comprobación de los disparos es-peci…cados en P y, a continuación, delegará sobre el Objeto Estado la ejecucióndel método que implementa la comprobación de los disparos nuevos especi…ca-dos en la subclase. De esta forma los disparos serán la unión de los disparosde…nidos en la subclase y en la superclase.

² Si la subclase rede…ne los disparos heredados, entonces la implementación eje-cutará el método comprobar_disparos implementado en la subclase. Éste esel mismo caso que en las restricciones por lo que será adecuado utilizar la opti-mización propuesta de la misma manera que se ha hecho en las restricciones deintegridad.

Como ejemplo de aplicación se puede tomar la implementación del método compro-bar_disparos de la subclase Vendedor de la partición dinámica de Empleado, pre-sentada en el apartado donde se introdujo la implementación de disparos para clasessimples.

Una vez se ha …nalizado este apartado se debe presentan cómo se crean y destruyeninstancias en particiones. En primer lugar se introducirá la creación y destrucciónde instancias en particiones dinámicas, y a continuación se tratará lo mismo para lasestáticas. Este orden en la presentación se debe a que la solución a adoptar en el casode las estáticas, constituye un caso particular de la solución que se presenta para lasdinámicas.

7.5.3 Creación y Destrucción de Instancias en Particiones Di-námicas. El Proceso de Migración

La creación y destrucción de instancias de una partición dinámica vendrá determinadapor el proceso migratorio de…nido sobre los eventos de migración o por los valores dealgunos atributos variables. A continuación se presenta cómo implementar estos dostipos de creación y destrucción a partir de la especi…cación.

Creación y Destrucción de Instancias Basada en Eventos de Migración

La implementación del proceso de migración se realizará adaptando una variacióndel patrón State llamada Owner-Driven Transitions [69]. Esta variación se utilizapara implementar una máquina de estados …nita utilizando objetos estado. El patrónOwner-Driven Transitions propone que sea la superclase (Contexto) quien inicie ycontrole la transición entre estados. La clase CP poseerá un conjunto demétodos de


Vendedor

Responsable


rebajar

Figura 7.14: Diagrama de Migración de la subclase Empleado

migración Mmig que implementarán los eventos de migración. Estos métodos utili-zarán la información del diagrama de migración para crear y destruir las instanciasEstado pertinentes para simular el proceso de migración entre subclases. Como ejem-plo de proceso de migración se presenta a continuación la especi…cación en OASISdel proceso obtenido a partir del diagrama de migración de la …gura 7.14.

Vendedor, Responsabledynamic specialization of Empleadomigration relation isEmpleado = contratar.Vendedor;Vendedor = promocionar.Responsable;Responsable = rebajar.Vendedor;

Semántica de los Eventos de Migración. En el proceso de migración se puedendistinguir dos tipos de eventos:

² De Creación: Es el evento inicial en el proceso de migración. Este evento creaun objeto perteneciente a la subclase inicial de la partición dinámica, e inicializasus atributos constantes. A nivel de especi…cación, en OASIS será un eventoconstructor propio de la superclase. En el ejemplo de la …gura 7.11 contratarserá el evento de creación de la clase Empleado.

² Liberadores/Portadores: Son eventos que provocan la migración entre dossubclases de la partición dinámica. A nivel de especi…cación se declaran en lasubclase origen de la migración. Estos eventos modi…can el estado del objetoactivo a través de la ejecución de la estrategia de ejecución, y a continuación “li-beran”13 al objeto de la parte del estado correspondiente a la subclase activa dela partición. Además, también actuarán como eventos portadores (o construc-tores especiales) que “llevan” al objeto a la subclase destino especi…cada en elproceso migratorio. Estos eventos crearán la parte del estado correspondiente ala nueva subclase activa en la partición (inicializando sus atributos constantes).A nivel de especi…cación no se declararán en la subclase destino. En el ejemplode la …gura 7.14, promocionar y rebajar son eventos Liberadores/Portadoresque se han especi…cado en las subclases Vendedor y Responsable respectiva-mente.

13No son en sí eventos destructores aunque ”eliminen” parte del estado. Sirven para simular lamigración entre las subclases.


Implementación de los Eventos de Migración. Los eventos especi…cados en elproceso de migración se implementarán siguiendo la estrategia de ejecución al igualque los demás eventos. Sin embargo, debido a su semántica migracional serán respon-sables de implementar la migración entre subclases. Para implementar está semán-tica se incluirá en la clase CP ; un método privado especial (uno por cada particióndinámica) llamado especializador. Este método creará y destruirá los objetos Esta-do necesarios para simular adecuadamente la migración entre subclases. El métodoespecializador poseerá como argumento el nombre del evento para poder determinaradecuadamente la migración entre subclases.El tipo del evento de migración determinará la implementación del método espe-

cializador y su participación en la estrategia de ejecución. Así pues, los dos tipos deeventos presentados anteriormente se implementarán como sigue:

² Eventos de Creación: Cuando se crea un objeto de CP , se crea un objeto dela clase Ci; i 2 f1; :::; ng; tal que Ci es la subclase que implementa a la claseinicial del proceso de migración (Si) obtenida a partir de la especi…cación delproceso. El objeto de la subclase Ci (Objeto Estado) se asigna a ACA . Esta es lasemántica que el método especializador debe implementar cuando reciba comoargumento de entrada el evento de creación. En la implementación del patrónState, la clase CP (Contexto) tendrá un método constructor (representando alconstructor de P ) que implementará la estrategia de ejecución que inicializarálos atributos de CP y creará el Objeto Estado pertinente. Al …nal del algoritmoque implementa la estrategia de ejecución se situará una llamada al métodoespecializador cuyos argumentos serán el nombre del evento de creación y losargumentos14 de éste. A continuación se presenta como ejemplo el métodoque implementa el evento contratar de la clase Empleado y la aplicación delmétodo especializador llamado especializar_por_evento:

public void contratar(int s_base){

comprobar_transicion_estado(contratar);comprobar_precondicion_contratar(s_base);eval_contratar(s_base);// evaluación que inicializa los atributos de Empleadocomprobar_restricciones_integridad();comprobar_disparos();// inicializar la hashtable mediante argumentos = new Hashtable();especializar_por_evento(‘‘contratar’’,

argumentos.put(‘‘s_base’’, new int(s_base));// método especializador

}

Es importante destacar algunas cuestiones sobre la implementación de eventosconstructores. En los ejemplos que se presentan, el constructor que impone Java (pordefecto) será el constructor de la clase y se llamará igual que la clase a la que pertenece.Este método servirá para crear la instancia de la clase en memoria. Los constructores14 Se utiliza una Hashtable para pasar los argumentos. De esta forma el método especializador

puede ser genérico para cualquier tipo de evento con un número variable de parámetros.


propios de las clases OASIS serán métodos de clase públicos incorporados a la claseJava en el proceso de generación de código. Estos métodos implementarán a losconstructores declarados en la especi…cación y realizarán la creación e inicializacióndel objeto según la especi…cación (siguiendo la estrategia de ejecución). Los atributosconstantes, se incluirán como argumentos implícitos15 de estos métodos constructores,así como aquellos atributos variables que, en la etapa de modelado conceptual, hayansido especi…cados con la propiedad “pedir al crear”. Esta última propiedad no seespeci…ca en el lenguaje de especi…cación OASIS, sino que constituye una extensiónproporcionada por la herramienta CASE que da soporte a OO-Method.

² Eventos Liberadores/Portadores: Estos métodos poseen la responsabilidadde destruir16 el Objeto Estado activo, y crear a continuación un objeto nuevo dela subclase destino en el proceso de migración. Este nuevo objeto se le asignaráal atributo ACA (el Objeto Estado). Ésta es la semántica que debe implemen-tar el método especializador cuando recibe un evento liberador/portador comoargumento de entrada. En la implementación del patrón State, la clase CP(Contexto) tendrá un método que delegará su ejecución en un método de la sub-clase activa, ya que este tipo de métodos pertenecen a una de las subclases de lapartición. La llamada al método especializador con el evento liberador/portadorcomo argumento se realizará después de la llamada al método delegado. Estose realiza así para que se ejecute en primer lugar la estrategia de ejecución dedicho método y después se produzca la migración. A continuación se presenta laimplementación de los eventos promocionar y rebajar en la clase Empleadoa través de sus respectivos métodos, y la aplicación del método especializadorsegún se ha comentado:

public void promocionar(int nVendedores) throws EventoNOPermitido{

if (obj_estado_tipoEmpleado.nombre_clase.equals(‘‘Vendedor’’){

// si el objeto activo es un Vendedorobj_estado_tipoEmpleado.promocionar(nVendedores);// delega la ejecución del evento promocionar// en el objeto de la subclase// se inicializará la hashtableespecializar_por_evento(‘‘promocionar’’,

argumentos.put(‘‘nVendedores’’,new int(nVendedores));// método especializador

}else throw new EventoNOPermitido();// el evento promocionar pertenece a la subclase Vendedor

}

public void rebajar() throws EventoNOPermitido

15Estos argumentos no se han incluido en los diseños iniciales16En lenguajes como Java no existe la necesidad de de…nir un método destructor. En esta apro-

ximación, es necesario un destructor especial debido a que se necesita eliminar los recursos que estáutilizando el objeto (por ejemplo en una arquitectura de tres niveles, el nivel de aplicación debeencargarse de eliminar el objeto de la base de datos).


{if (obj_estado_tipoEmpleado.nombre_clase.equals(‘‘Responsable’’)){

// si el objeto activo es un Responsableobj_estado_tipoEmpleado.rebajar();// delega la ejecución del evento rebajar// en el objeto de la subclase// se inicializará la hashtable, aunque rebajar no posee argumentosespecializar_por_evento(‘‘rebajar’’,argumentos);// método especializador

}else throw new EventoNOPermitido();// el evento rebajar pertenece a la subclase Responsable

}

Teniendo en cuenta la semántica de…nida para el efecto de los eventos de creacióny los liberadores/portadores, la implementación del método especializador de esteejemplo será la siguiente:

private void especializar_por_evento(String Evento, Hastable Argumentos){

if (obj_estado_tipoEmpleado==null){

// no hay ningún objeto activo porque// se está en el proceso de creación de un Empleadoif (Evento.equals(‘‘contratar’’)){

obj_estado_tipoEmpleado= new Vendedor(this);// crea un Vendedor y lo asigna al objeto estadoobj_estado_tipoEmpleado.contratar((int)

(Argumentos.get(‘‘s_base’’)).intValue());// se inicializan los atributos de Vendedor si es necesario// ejecutando el método constructorreturn;

}}if (obj_estado_tipoEmpleado.nombre_clase().equals(‘‘Vendedor’’){

if (Evento.equals(‘‘promocionar’’)){

// si ocurre el evento promocionarobj_estado_tipoEmpleado.free();// se destruye el objeto activoobj_estado_tipoEmpleado= new Responsable(this);// crea un objeto de la subclase Responsableobj_estado_tipoEmpleado.promocionar((int)

(Argumentos.get(‘‘nVendedores’’)).intValue());// se inicializan los atributos de Responsable si es necesario// ejecutando el método constructor

return;}


return;}if (obj_estado_tipoEmpleado.nombre_clase().equals(‘‘Responsable’’){

if (Evento.equals(‘‘rebajar’’)){

// si ocurre el evento rebajarobj_estado_tipoEmpleado.free();// se destruye el objeto activoobj_estado_tipoEmpleado = new Vendedor(this);// crea un objeto de la subclase Vendedorobj_estado_tipoEmpleado.rebajar();// se ejecuta el constructor y se inicializan los atributos de// Vendedor si es necesarioreturn;

}return;

}}

En este ejemplo, no existe la necesidad de incluir las sentencias que compruebande qué clase es el Objeto Estado en la implementación del método especializador.Esto es debido a que, en el ejemplo de la …gura 7.14, sólo existe una transiciónposible y una clase destino por cada evento liberador/portador. Sin embargo, estascomprobaciones deberán incluirse cuando existan dos o más transiciones etiquetadascon eventos distintos que lleven a dos o más subclases destino.

Creación y Destrucción de Instancias Basada en Valores de Atributos Va-riables

La implementación del proceso de migración basado en valores de atributos varia-bles se lleva a cabo de forma similar a la que se ha propuesto en la sección anterior.Se introducirá un método especializador para implementar la semántica migracionalde las condiciones de migración de…nidas sobre atributos variables. Este método seimplementará como un método privado de la clase CP ; que creará y destruirá los ob-jetos estado adecuados dependiendo de la clase del Objeto Estado activo y del valorde alguno de sus atributos variables. El método especializador debe situarse al …naldel algoritmo de la estrategia de ejecución de los siguientes métodos:

² el/los método/s constructor/es de la clase CP y² aquellos métodos de CP que modi…quen el valor de los atributos variables quetomen parte en las condiciones de migración. A estos métodos se les llamarámétodos de posible migración.

Para comprender mejor la propuesta, se puede rescribir el ejemplo de la claseEmpleado, especializada dinámicamente en Vendedor y Responsable de forma quese convierta en una especialización dinámica basada en condiciones sobre atributosvariables (ver …gura 7.15). En este ejemplo, el objeto de la clase Empleado se especia-liza en una u otra subclase dependiendo del puesto que le asignen. A continuación se


Emp le ad ocod_empleadoseccionpuestosalariosueldo_basetelefonofecha_contratacionfecha_revision_sueldobonificacionbajas


Vendedorn Venta s

vende r()

Resp onsab lenVendedores

asignar_vendedores()quitar_vendedores()

<<dinámica>>p ue sto

<<puesto="vendedor">><<pue sto=re spon sab le ">>

Figura 7.15: Partición Dinámica de la clase Empleado basada en Valores de Atributos


puede ver la especi…cación OASIS de las condiciones de migración de esta particióndinámica.

Vendedor where {puesto=‘‘Vendedor’’}Responsable where {puesto=‘‘Responsable’’}

dynamic specialization of Empleado;

Teniendo en cuenta esta especi…cación, la implementación del método especiali-zador especializar_por_atributo_variable del ejemplo de la …gura 7.15 será lasiguiente:

private void especializar_por_atributo_variable(Hashtable Argumentos){

if (obj_estado_tipoEmpleado.nombre_clase().equals(‘‘Vendedor’’){

// el objeto activo es un Vendedorif (puesto.equals(‘‘Responsable’’)){

obj_estado_tipoEmpleado.free();// destruye el objeto activo (un Vendedor)obj_estado_tipoEmpleado= new Responsable(this);// crea un objeto de la subclase Responsableobj_estado_tipoEmpleado.crear(Argumentos);// se inicializan los atributos de Responsable si es necesario// es un constructor oculto para simular la migraciónreturn;

}return;}if (obj_estado_tipoEmpleado.nombre_clase().equals(‘‘Responsable’’){

// el objeto activo es un Responsableif (puesto.equals(‘‘Vendedor’’)){

obj_estado_tipoEmpleado.free();// destruye el objeto activo (un Responsable)obj_estado_tipoEmpleado = new Vendedor(this);// crea un objeto de la subclase Vendedorobj_estado_tipoEmpleado.crear(Argumentos);// se inicializan los atributos de Vendedor si es necesario// es un constructor oculto para simular la migración

return;}

return;}if (obj_estado_tipoEmpleado==null)){

// no hay ningún objeto activo porque// se está en el proceso de creación de un Empleadoif (puesto.equals(‘‘Responsable’’)){


obj_estado_tipoEmpleado= new Responsable(this);// crea un objeto de la subclase Responsableobj_estado_tipoEmpleado.crear(Argumentos);// se inicializan los atributos de Responsable si es necesario// es un constructor oculto para simular la migraciónreturn;

}obj_estado_tipoEmpleado = new Vendedor(this);// crea un objeto de la subclase Vendedorobj_estado_tipoEmpleado.crear(Argumentos);// se inicializan los atributos de Vendedor si es necesario// es un constructor oculto para simular la migraciónreturn;

}}

Al igual que ocurre con el método especializador por eventos, en este caso, tam-bién habrá que pasarle como argumentos los valores de los argumentos que permitaninicializar a los objetos. A continuación se presenta la implementación del métodocontratar de la clase Empleado y la aplicación del método especializador:

public void contratar(int s_base, String p_puesto){

comprobar_transicion_estado(contratar);comprobar_precondicion_contratar(s_base, p_puesto);eval_contratar(s_base,p_puesto);// evaluación que inicializa los atributos de Empleadocomprobar_restricciones_integridad();comprobar_disparos();// inicializar la hashtable mediante argumentos = new Hashtable()// insertar argumentos argumentos.put(‘‘s_base’’,new int(s_base))// insertar argumentos argumentos.put(‘‘p_puesto’’,p_puesto)especializar_por_atributo_variable(argumentos);// método especializador

}

El método cambiar_puesto de la clase Empleado cambia el valor del atributopuesto. Éste es un método de posible migración. La implementación de este métodoy la aplicación del método especializador especializar_por_atributo_variable sepresenta a continuación:

public void cambiar_puesto(String NuevoPuesto){

obj_estado_tipoEmpleado.cambiar_puesto(NuevoPuesto);// delega en el Objeto Estadoespecializar_por_atributo_variable(argumentos);// método especializador

}


En este tipo de especialización existen situaciones como la que presenta la activa-ción de un evento de posible migración (como es el caso de cambiar_puesto) en elque no se conoce si el objeto migrará y a qué subclase de la partición lo hará. Enestas situaciones, si se cumple la condición, el constructor pedirá al usuario los valoresde los atributos nuevos de las subclases para inicializar su valor, o será el nivel depresentación el que los solicitará en el momento de activar el evento17.

7.5.4 Creación de Instancias en Particiones Estáticas

La creación de instancias de una partición estática vendrá determinada por los valoresde atributos constantes proporcionados en el proceso de creación de una instancia dela superclase o, por la creación directa de una instancia de una subclase de la partición.

Creación de Instancias basada en Valores de Atributos Constantes

La creación de instancias, en una partición estática cuyo criterio de especializaciónestá basado en el valor de atributos constantes, puede considerarse un caso especial delmismo proceso presentado en las particiones dinámicas. Así pues, su implementaciónse llevará a cabo de forma similar a la propuesta para las dinámicas. Se introduciráun método especializador para implementar la creación de los objetos de la subclasedependiendo de las condiciones de especialización de…nidas sobre atributos constantes.Este método se implementará como un método privado de la clase CP y se encargaráde crear el objeto estado de la subclase correspondiente (dependiendo de la condiciónespeci…cada). El método especializador se situará al …nal del algoritmo de la estrategiade ejecución del/de los método/s constructor/es de la clase CP . A continuación sepresenta la especi…cación OASIS de la partición estática de la …gura 7.9:

Hombre where {sexo=‘‘M’’}Mujer where {sexo=‘‘F’’}static specialization of Persona;

Teniendo en cuenta las condiciones de especialización presentes en esta especi…ca-ción, la implementación del método especializador especializar_por_atributo_-constante será la siguiente:

private void especializar_por_atributo_constante(Hashtable Argumentos)throws ErrorCondicionEspecializacion{if (sexo.equals(‘‘masculino’’))

{obj_estado_sexo= new Hombre(this);//crea un objeto de la subclase Hombreobj_estado_sexo.crear(Argumentos);// se inicializan los atributos de Hombre si es necesarioreturn;

}if (sexo.equals(‘‘femenino’’))

17En el nivel de presentación se puede simular la evaluación para conocer si se va a producir lamigración.


{obj_estado_sexo = new Mujer(this);//crea un objeto de la subclase Mujerobj_estado_sexo.crear(Argumentos);// se inicializan los atributos de Mujer si es necesarioreturn;

}throw new ErrorCondicionEspecializacion();

}

A continuación se presenta la implementación del método crear de la clase Personay, la aplicación del método especializador especializar_por_atributo_constante:

public void crear(String p_dni, String p_nombre, String p_apellidos,String p_direccion, String p_telefono, int p_edad, String p_sexo,Hashtable argumentos){

comprobar_transicion_estados(crear);comprobar_precondicion_crear(p_dni,p_edad,p_sexo);eval_crear(p_dni, p_nombre, p_apellidos, p_direccion, p_telefono, p_edad,

p_sexo);// evaluación que inicializa los atributos de Personacomprobar_restricciones_integridad();comprobar_disparos();especializar_por_atributo_constante(argumentos);// método especializador

}

Dependiendo del sexo (argumento p_sexo) en el argumento argumentos se pasaránlos valores de los argumentos int p_hijos, String p_estado (en el caso de crearuna Mujer) o los valores Date fechaIni,Date fechaFin, String servicio, intdurmeses en el caso de crear un Hombre).

Creación Directa

Las subclases estáticas pueden de…nir sus propios constructores. De esta forma sepueden crear instancias directamente mediante la activación de dichos constructores.A nivel de implementación, en la clase CP se de…nirán los eventos constructores delas subclases como métodos con el mismo nombre18 y como argumentos los atribu-tos constantes (y variables si son requeridos) de la clase padre, junto con los de laclase especializada que se va a crear. Estos métodos crearán inicialmente la partede estado de la clase padre P (siguiendo la estrategia de ejecución) y, a continuacióncrearán el Objeto Estado de la subclase que se ha elegido crear de forma directa. Acontinuación, mediante delegación se llamará a un método constructor (con el nombredel constructor de la subclase) que inicializará el estado propio de la subclase. En el

18Pueden existir situaciones en las que distintas subclases posean constructores con el mismonombre, en dicho caso al nombre del método correspondiente se le concatenará el nombre de la claseal …nal del nombre del evento, como es el caso del ejemplo introducido en en el método crear_Mujer


proceso de creación de instancias de la subclase se debe garantizar la disyunción, esdecir, que no exista otro objeto igual de la misma partición.Para ilustrar este modo de creación se presenta un ejemplo que utiliza la partición

estática presentada en la …gura 7.9. Se supone que las subclases Hombre y Mujer tienenambas un constructor propio llamado crear. La implementación del constructor dela clase Mujer en la clase Persona según lo visto sería:

public void crear_Mujer(String p_dni, int p_edad, string p_sexo,int p_n_hijos, String p_estado){

crear(p_dni,p_edad,p_sexo);obj_estado_sexo = new Mujer(this);obj_estado_sexo.crear(p_n_hijos, p_estado);

}

7.5.5 Destrucción de Instancias en Particiones Estáticas

La destrucción se realizará directamente a través de los eventos destructores. La des-trucción de instancias (destruyendo completamente el objeto y sus especializacionesactivas) hará uso de dos tipos de eventos destructores:

1. Destructores especi…cados en la clase padre. El método que implementa el eventodestructor debe ejecutar la estrategia de ejecución, a continuacion debe destruirel Objeto Estado y por último a él mismo ejecutando un método especial queliberará los recursos que esté utilizando (por ejemplo borrando la tabla o tablasque representan al objeto en el nivel de persistencia). A continuación se presentala implementación en la clase Persona del evento eliminar (destructor de laclase Persona).

public void eliminar(){

comprobar_transicion_estado(eliminar);comprobar_precondicion_eliminar();eval_eliminar();comprobar_restricciones_integridad();comprobar_disparos();obj_estado_sexo.destruir();//destruye el Objeto Estado (Hombre o Mujer)free();// se destruye él mismo

}

2. Destructores especi…cados en la subclase. Su implementación en la clase padredelegará en el objeto estado la ejecución de la estrategia de ejecución y porúltimo se destruirá él mismo como en el caso anterior. A continuación se presentala implementación en la clase Persona del método que implementa el eventodestruir (destructor de la clase Hombre).


public void destruir(){

obj_estado_sexo.destruir();//destruye el Objeto Estado (Hombre o Mujer)free();// se destruye él mismo

}

7.6 Roles en el Espacio de la Solución

El patrón Role Object ha sido seleccionado como la estructura de diseño adecuadapara representar …elmente los grupos de rol.

7.6.1 De…nición de la Estructura de Clases

El patrón Role Object, como se ha visto anteriormente, se caracteriza porque enél participan cuatro tipos de clases: Componente, Jugador, Rol y RolConcreto (ver…gura 7.6). El patrón especi…ca las operaciones básicas que debe poseer la clasejugadora y sus roles mediante una clase base llamada Componente. En concreto,estas operaciones básicas sirven para añadir, eliminar, comprobar y solicitar roles. Laclase Jugador es la que implementa el interfaz público de la clase Componente. Estaclase será la encargada de la gestión de los roles ya que, creará los roles, controlará lascardinalidades, ejecutará el código necesario para que se eliminen los roles, controlaráque no se puedan crear roles de subclases disjuntas y será la encargada de eliminarlostodos en el caso de la destrucción del jugador. Esta clase poseerá como atributo unacolección de roles debido a su relación de agregación de multiplicidad muchos con laclase Rol. En este caso no será posible acceder directamente desde esta clase a losatributos y servicios de los roles, dado que pueden existir simultáneamente muchosroles activos de la misma clase de rol. Por esto, en este patrón se propone obtenerla instancia del rol con la que se desea trabajar y posteriormente ejecutar todos losservicios que se deseen ejecutar directamente sobre el rol. La clase Rol almacenaráuna referencia a un objeto de la clase Jugador e implementará el interfaz de la claseComponente enviando mediante delegación las peticiones al objeto Jugador. Existirántantas subclases RolConcreto como roles sea necesario implementar. Estas subclasesimplementarán los eventos y poseerán los atributos especí…cos de los roles. En el casode se desee acceder a un evento o atributo que no esté en el rol (por ser de la clasejugadora), se delegará en el jugador. Para su correcta instanciación se les deberáasignar obligatoriamente un objeto jugador.Dado un grupo de rol fR1; :::; Rng de la clase P (siendo P la clase jugadora de

los roles) su representación estructural vendrá determinada por las clases (ver …gura7.16) CComp (Componente), CJug (Jugador), CR (Rol) y fC1; :::; Cng (RolConcreto),tal que:

² CComp poseerá:– un conjunto de métodos públicos MCComp abstractos que servirán para de-…nir la interfaz que las clases CJug y CR deberán implementar. De entre

7.6. Roles en el Espacio de la Solución 251

C1 CN

Cjug Cr0..*0..*

1 11 1

........

Ccomp

Figura 7.16: Patrón Role Object Genérico

estos métodos se pueden distinguir dos tipos: los métodos esenciales y losadicionales.

¤ Los métodos esenciales (MCComp esenciales

) son aquellos métodos que

representan a EvP (eventos de P ).¤ Los métodos adicionales (MC

Comp adicionales) son aquellos métodos que

facilitan la tarea de manipulación de roles. No se deducen de la espe-ci…cación ni del modelo de roles presentado. En este tipo de métodosse encuentran dos que están presentes en la propuesta del patrón RoleObject :

¢ Un método tiene_rol que permite conocer si un objeto está ju-gando o no un determinado rol.

¢ Un método obtener_rol que permite recuperar un rol dado unidenti…cador de rol determinado. Esto facilita el poder trabajardirectamente con el rol.

² CJug poseerá:

– Un conjunto de atributos AtrCJug propios de P , y una colección ColRolespara almacenar los roles de una de las subclases del grupo de rol fR1; :::; Rngque está jugando un objeto de P:

– Un conjunto de métodos públicos MCJug , que implementarán los métodosesenciales a los que se llamará MC

Jugesencialesy los métodos adicionales

llamados MCJugadicionales

.

² CR poseerá:


– Un atributo Ajug que se llamará ObjetoJugador y será de tipo CJug. Esteatributo almacenará el objeto jugador del rol, lo que va a permitir a losroles que deleguen en el objeto jugador cuando sea requerido.

– El mismo interfaz público que la clase CJug heredado de CComp , es de-cir MCR = MCJug .CR implementará dicho interfaz enviando mediantedelegación las peticiones a Ajug (el ObjetoJugador).

² fC1; :::; Cng serán subclases de CR y servirán para representar a las subclasesde rol fR1; :::; Rng. Cada Ci poseerá:– Un conjunto de atributos AtrCi para almacenar AtrRi (los atributos nuevosde Ri ).

– Un conjunto de métodos públicos MCi constituido por aquellos méto-dos heredados19 de CR (ya implementados en CR) es decir MCR ; y porMCinuevos los métodos que implementan EvRi (los eventos nuevos de lasubclase de rol Ri ). Así pues MCi = MCR [MCinuevos . Al heredar Cilos métodos MCR y ser MCR = MCJug entonces Ci hereda la interfaz dela clase jugadora CJug, lo que garantizará la compatibilidad de signaturatambién de las clases que implementan los roles fC1; :::; Cng con la claseCJug que implementa la clase jugadora.

Al contrario que con el patrón State, el patrón Role Object permite que las sub-clases fC1; :::; Cng tengan acceso a los atributos y métodos de la superclase jugadoraCJug mediante delegación a través del atributo Ajug, por lo que la visibilidad delas subclases no se ve reducida. Sin embargo CJug no tendrá acceso directo a losmétodos y los atributos de las subclases fC1; :::; Cng, debido sobre todo a la posibi-lidad de que el objeto jugador pueda estar relacionado con múltiples instancias deuna misma subclase. Si desde el rol se solicita el acceso a algún atributo (a través deun método de lectura) de la clase jugadora, para obtener su valor se delegará en eljugador. Por ejemplo, si se desea obtener el valor del nombre de un empleado e sellamará al método obtener_nombre de la clase Empleado (e:obtener_nombre). Estemétodo, como se puede ver a continuación, delegará en el jugador porque nombre noestá de…nido en la clase Empleado.

public void obtener_nombre(){

Jugador.obtener_nombre(); // delega en el Objeto Jugador}

Para un mejor seguimiento, se van a utilizar, como ejemplo, dos grupos de rolde la clase Persona que tienen como subclases de rol a Estudiante y a Empleado(ver …gura 7.17). Se han modelado dos grupos de rol porque se pretende que unaPersona pueda jugar el rol de Estudiante y Empleado a la vez. Las subclases a suvez tendrán sus relaciones de agregación con clases como CarreraUniversitaria,Asignatura (en el caso de Estudiante) y Empresa en el caso de Empleado.La …gura 7.18 muestra el diseño (en notación UML) después de aplicar las corres-

pondencias que se han propuesto.Su implementación Java es la siguiente:

19 Se declararán de nuevo si rede…nen el método heredado de CR:


Personadninombreapellidosdirecciontelefonoedadsexo

cambiar_direccion()cambiar_telefono()incrementar_edad()revision_medica()crear()eliminar()matricular()contratar()

<<jugado_por>>

<<contratar() / despedir()>>

Empleadocod_empleadoseccionpuestosalariosueldo_basetelefonofecha_contratacionfecha_revision_sueldobonificacionbajas

cambiar_seccion()cambiar_puesto()bonificar()subir_sueldo()pagar()despedir()iniciar_mes()faltar_al_trabajo()

Estudiantecod_estudiantecreditosTotalesCarreracursonAsignaturasMatriculadasTotalCreditosAprobados

examinar()matricular_asignatura()terminar_estudios()

<<matricular() / terminar()>>

<<0,3>>

<<jugado_por>>

Figura 7.17: Diagrama de Clases con dos grupos de roles de la clase Persona(Estudiante y Empleado)


Estudiantecod_estudiantecreditosTotalesCarreracursoTotalCreditosAprobadosnAsignaturasMatriculadas

examinar()terminar_estudios()matricular_asignatura()

Empleadocod_empleadopuestoseccionbonificacionbajastelefonosalariosalario_basefecha_cotratacionfecha_revision_sueldo

pagar()bonificar()faltar_al_trabajo()despedir()cambiar_seccion()cambiar_puesto()subir_sueldo()iniciar_mes()

Componente

crear()eliminar()matricular()contratar()cambiar_direccion()cambiar_telefono()incrementar_edad()revision_medica()tiene_rol()obtener_rol()

0..3

RolPersona


Personanombreapellidosdirecc ióntelefonodniedadsexo


GrupoRolEstudiante

Jugador

GrupoRolEmpleado

Figura 7.18: Diseño de los grupos de rol de Persona


abstract public class Componente{

public abstract crear(String v_dni, v_nombre, v_apellidos, v_sexo);public abstract eliminar();public abstract void matricular();public abstract void contratar(int s_base);public abstract void cambiar_direccion(String nueva_direccion);public abstract void cambiar_telefono(String nuevo_telefono);public abstract void incrementar_edad();public abstract void revision_medica();// métodos esencialespublic abstract boolean tiene_rol(String NombreSubclaseRol);public abstract Rol obtener_rol(RolId Id);// métodos adicionales

}

public class Persona extends Componente{

String nombre;String apellidos;String direccion;String telefono;int edad;String dni;String sexo;// atributos de la clase PersonaEstadosDTE EstadoDTE= E_INICIAL;// estado actual en el DTEVector GrupoRolEstudiante=new Vector(3);Vector GrupoRolEmpleado=new Vector(1);public Persona();public crear(String v_dni, v_nombre, v_apellidos, v_sexo);// método constructorpublic eliminar();// método destructorpublic void matricular(String Carrera);public void contratar(int s_base);public void cambiar_direccion(String nueva_direccion);public void cambiar_telefono(String nuevo_telefono);public void incrementar_edad();public void revision_medica();public boolean tiene_rol(String NombreSubclaseRol);public Rol obtener_rol(RolId Id);...public String obtener_nombre();...// métodos de consulta de atributos

}

public class RolPersona extends Componente{

// atributos de la clase PersonaEstadosDTE EstadoDTE= E_INICIAL;


Persona Jugador;// almacena el objeto jugadorpublic Persona();public crear();// método constructorpublic eliminar();// método destructorpublic void matricular(String Carrera);public void contratar(long s_base; String v_puesto,v_seccion);public void cambiar_direccion(String nueva_direccion);public void cambiar_telefono(String nuevo_telefono);public void incrementar_edad();public void revision_medica();public boolean tiene_rol(String NombreSubclaseRol);public Rol obtener_rol(RolId Id);...public String obtener_nombre();...// métodos de consulta de atributos

}

public class Estudiante extends RolPersona{String cod_estudiante;long creditosTotalesCarrera;String curso;long TotalCreditosAprobados;long nAsignaturasMatriculadas;// atributos de la subclase de rol Estudiantepublic void examinar(String Cod_Asignatura; float v_nota);public void matricular_asignatura(String v_asignatura, v_curso);public void terminar_estudios();// método destructor que …naliza la etapa como estudiante

}public class Empleado extends RolPersona{

String cod_empleado;long salario;int sueldo_base;String puesto;String seccion;long bonificacion;int bajas;String telefono; // en el trabajodate fecha_contratacion;date fecha_revision_sueldo;// atributos de la subclase de rol Empleadopublic void pagar();public void bonificar(long incremento);public void faltar_al_trabajo();public void cambiar_seccion(String nueva_seccion);public void cambiar_puesto(String nuevo_puesto);public void subir_sueldo(long incremento);


public void iniciar_mes();public void despedir();// método destructor que …naliza la etapa como Empleado

}

Los métodos de la clase RolPersona se implementan mediante delegación sobre elobjeto Jugador. Por ejemplo, ésta sería la implementación del método matricular:

public void matricular(String Carrera){

Jugador.matricular(Carrera); // delega en el Objeto Jugador}

7.6.2 Implementación de la Estrategia de Ejecución

La aplicación del patrón Template Method para implementar la estrategia de ejecuciónen el caso de los roles, se realizará de forma que se sigan las pautas de comportamientode…nidas para los roles en el modelo OASIS, con la intención de garantizar que losroles se comportan según lo especi…cado.

² En CComp se de…nirán aquellos métodos que implementen en CJug, CR y en lassubclases Ci 2 fC1; :::; Cng;8i = 1; :::; n cada una de las acciones de la estrategiade ejecución. Esos métodos serán protegidos, y se implementarán de la siguientemanera:

– En CJug se implementarán las acciones de la estrategia de ejecución espe-ci…cadas únicamente en P .

– En CR la implementación de las acciones de la estrategia de ejecucióndelegará a través del objeto jugador (almacenado en Ajug) en la imple-mentación realizada en CJug:

– Cada una de las subclases Ci 2 fC1; :::; Cng;8i = 1; :::; n de CR rede…nirá20los métodos de la estrategia de ejecución heredados de CR si se ha añadi-do o rede…nido alguna precondición, evaluación, restricción de integridad,disparo o se ha extendido el proceso en la subclase de rol Ri.

² En el patrón Role Object la delegación se lleva a cabo desde el rol hacia eljugador (al revés que con el State). Esto hace que la implementación de losmétodos que implementan los eventos de P y fR1; :::; Rng se lleve a cabo de lasiguiente manera:

– Los eventos especi…cados en P , se implementarán en CJug mediante méto-dos que ejecutarán secuencialmente las acciones de la estrategia de ejecu-ción implementadas en CJug.

– Los métodos de una subclase de rol Ri 2 fR1; :::; Rng;8i = 1; :::; n seimplementarán en la subclase Ci 2 fC1; :::; Cng;8i = 1; :::; n de la siguientemanera:

20No se exige mantener compatibilidad de comportamiento.


¤ Los métodos MCinuevos , que implementan los eventos nuevos de lasubclase de rol (EvRi), se implementarán en Ci como sigue:

¢ si los eventos no modi…can atributos heredados y sólo añaden com-portamiento (precondiciones, restricciones de integridad o dispa-ros, se consideran comportamiento porque, en este modelo, in‡u-yen en el comportamiento asociado a un evento), se ejecutarántodos los métodos de la estrategia de ejecución implementados enCi:

¢ si los eventos modi…can atributos heredados, el método ejecutará laestrategia de ejecución haciendo llamadas a los métodos propios dela estrategia de ejecución (implementados en Ci) cuyo comporta-miento haya sido rede…nido. El comportamiento que no haya sidorede…nido, se ejecutará delegando en las acciones de la estrategiade ejecución del ObjetoJugador.

¤ Los métodos que implementan eventos heredados de la clase jugado-ra se implementarán siempre cómo métodos del tipo presentado en elpunto anterior. Se consideran de este tipo porque se supone al me-nos que los roles siempre rede…nen el proceso (el DTE) ya que nose exige compatibilidad de comportamiento, y debido a la multiplici-dad, los roles deben poseer cada uno un proceso independiente, por loque en la implementación de la rede…nición del evento se ejecutará lacomprobación del DTE implementada en Ci. Los demás pasos de laestrategia de ejecución (si no se han rede…nido) delegarán su ejecuciónen el ObjetoJugador.

Una vez se ha presentado lo que deben implementar las acciones de la estrategiade ejecución, queda por de…nir cómo se aplican estas ideas a cada una de las accionesde la estrategia de ejecución, de forma que se sigan estas pautas. A continuación sedetalla cómo se implementa el comportamiento de un objeto para cada una de lasacciones de la estrategia de ejecución en el contexto de las subclases de rol.


Al no exigir compatibilidad de comportamiento y ser además objetos distintos al juga-dor, los roles poseen cada uno un proceso independiente, por lo que para comprobarel DTE especi…cado para el rol Ri; en la subclase Ci se implementará el métodocomprobar_transicion_estado rede…niendo el heredado de CR. La implementaciónde este método se llevará a cabo utilizando la propuesta de generación presentadaanteriormente para las clases simples.


El método comprobar_precondicion_evento se implementará en Ci dependiendo delas siguientes condiciones:

² Si se debe comprobar la precondición de un evento heredado de la superclaseentonces su implementación será la siguiente:


– si el evento no ha rede…nido su precondición en la subclase entonces simple-mente se utiliza el método comprobar_precondicion_evento heredado deCR, que realiza una llamada mediante delegación sobre el Objeto Jugadora la implementación del método en CJug.

– si el evento ha rede…nido o añadido una precondición (porque no tenía nin-guna especi…cada en P ) se rede…ne el método comprobar_precondicion_e-vento heredado de CR y se implementa la comprobación de la nueva pre-condición en Ci.

² Si se debe comprobar la precondición de un evento especi…cado en una subcla-se entonces se implementará el nuevo evento de comprobación de…nido en Cimediante la técnica de implementación presentada en este capítulo.

En el ejemplo de grupos de rol propuesto en la …gura 7.17, la precondición delevento contratar de la clase Persona es que edad>=16. Esta precondición no se harede…nido en las subclases por lo que su implementación en Estudiante y Empleadoserá la que heredan de la clase RolPersona que se puede ver a continuación:

protected void comprobar_precondicion_contratar(int s_base)throws ViolacionPrecondicion{

Jugador.comprobar_precondicion_contratar(s_base);// delega en el Objeto Jugador

}

Realizar Evaluación

El método eval_evento se implementará en Ci para cada evento perteneciente a P[ Ri: Su implementación dependerá de las siguientes condiciones:² Si en Rise han de…nido evaluaciones nuevas para un evento heredado de P , laimplementación en Ci de la evaluación será:

– si la evaluación se realiza sobre atributos nuevos de Ri, el método imple-mentará la evaluación especi…cada en Ri y a continuación, si en P se habíanespeci…cado evaluaciones, delegará sobre el Objeto Jugador la ejecución delmétodo que implementa el efecto de la evaluación especi…cada en la clasejugadora P .

– si la evaluación se realiza sobre atributos heredados de P; el método im-plementará la evaluación especi…cada en Ri.

– si la evaluación se realiza sobre atributos de P rede…nidos en Ri, comosería el caso del atributo telefono en la subclase de rol Empleado (ver…gura 7.17), el método implementará en Ci la evaluación que se especi…cóen P sobre el atributo de Ri, ocultando (no llevando a cabo) el efecto delevento sobre el atributo de la clase P .

² Si en Ri no se han de…nido nuevas evaluaciones para un evento heredado deP , entonces se utilizará el método eval_evento heredado de CR, que realizauna llamada mediante delegación sobre el Objeto Jugador a la implementación


del método en CJug. De esta forma el método implementará la evaluaciónespeci…cada en P para dicho evento.

² Si en Rise han de…nido evaluaciones para un evento nuevo de Ri el métodoimplementará la evaluación especi…cada en Ri.

En la subclase de rol Empleado se ha rede…nido el atributo telefono que represen-ta el teléfono de la Persona en el trabajo. En la subclase del patrón que representaa Empleado se implementará la evaluación del evento cambiar_telefono sobre elatributo telefono de Empleado como se muestra a continuación:

protected void eval_cambiar_telefono(String nuevo_telefono){

telefono= nuevo_telefono;}

De este modo no se modi…ca el teléfono del objeto como Persona.

² Si es la evaluación de un evento nuevo de Ri (aplicada sobre atributos nuevos oheredados de Ri), el método implementará la evaluación especi…cada en Ri.

Comprobación de las Restricciones de Integridad en el Nuevo Estado

El método comprobar_restricciones_integridad se implementará en Ci depen-diendo de las siguientes condiciones:

² Si la subclase Ri no ha rede…nido o añadido restricciones de integridad enton-ces se utilizará el método comprobar_restricciones_integridad heredado deCR. Este método implementará la comprobación de las restricciones de P reali-zando un llamada al método implementado en CJug mediante delegación sobreel Objeto Jugador.

² Si en la subclase Ri se han especi…cado restricciones nuevas, entonces el métodocomprobar_restricciones_integridad de Ci implementará la comprobaciónde las restricciones especi…cadas enRi. A continuación, si la clase jugadora teníade…nidas restricciones propias, delegará sobre el Objeto Jugador la ejecución delmétodo de CJug que implementa dicha comprobación sobre las restricciones dela clase jugadora P .

² Si la subclase rede…ne algunas de las restricciones de la superclase, entonces seutilizará la optimización presentada anteriormente. De este modo el métodocomprobar_restricciones_integridad implementado en Ci llamará secuen-cialmente al método de comprobación de cada una de las restricciones especi-…cadas en Ri. A continuación, mediante delegación sobre el Objeto Jugador,llamará a aquellos métodos de CJug que comprueban las restricciones que nohan sido rede…nidas. Lo mismo ocurrirá en el siguiente apartado de disparos.

En el ejemplo de la …gura 7.17, se ha especi…cado en la subclase de rol Empleado(entre otras) la restricción de integridad nueva edad >=18. Con esta restricción seexige que las personas que se empleen deben tener 18 o más años. Según las pautaspropuestas, el método comprobar_restricciones_integridad se implementará enla subclase del patrón que representa a Empleado a través del siguiente método:


protected void comprobar_restricciones_integridad()throws ViolacionRestriccion {{

if (!(Jugador.obtener_edad>=18))// se comprueba la restricción especi…cada en Empleado// accediendo al atributo edad a través de delegación sobre// Jugador, ya que Empleado no lo tiene explícitamente// no comprueba las restricciones de Persona porque no tienethrow new ViolacionRestriccion();

}


El método comprobar_disparos se implementará en CP dependiendo de las siguientescondiciones:

² Si la subclase Ri no ha rede…nido o añadido ningún disparo, se utilizará elmétodo comprobar_disparos heredado de CR que implementará la comproba-ción de los disparos de P realizando una llamada al método implementado enCJug mediante delegación sobre el Objeto Jugador (si P tenía de…nidos disparospropios).

² Si en la subclase Ri se han especi…cado disparos nuevos, el método comprobar_disparos de Ci implementará la comprobación de los disparos especi…cados enRi y a continuación delegará sobre el Objeto Jugador la ejecución del métodode CJug que implementa la comprobación de las condiciones de disparo de laclase jugadora P (si ésta tenía de…nidos disparos propios).

² Si la subclase rede…ne los disparos heredados, se utilizará la optimización presen-tada anteriormente. De este modo el método comprobar_disparos implemen-tado en Ci llamará secuencialmente al método de comprobación de cada uno delos disparos especi…cados en Ri y a continuación llamará, mediante delegaciónsobre el Objeto Jugador, a aquellos métodos de CJug que comprueban los dis-paros que no han sido rede…nidos, al igual que se ha hecho en la comprobaciónde las restricciones de integridad.

En la especi…cación de la subclase de rol Empleado del ejemplo de la …gura 7.17,se ha de…nido un disparo que activa el evento bonificar si el número de días que elempleado ha estado de baja es igual a 5 (self:bonificar(-10000) when bajas=5).Según las pautas propuestas, el método comprobar_disparos se implementará en laclase de diseño Empleado a través del siguiente método:

protected void comprobar_disparos(){

if (bajas=5) bonificar(-10000);// se comprueba la condición de disparo especi…cada en Empleado// no comprueba las de Persona porque no tiene

}


7.6.3 Creación de Roles

La creación de los roles de un objeto implica una extensión vertical de los objetosjugadores. Esta creación se lleva a cabo a través de los eventos activadores del rol. Loseventos activadores en la aproximación presentada se implementan mediante méto-dos activadores Mactivadores 2 MCJug . Estos métodos hacen la función del métodoanyadir_rol presente en el patrón Role Object (ver …gura 7.16), ya que cada uno deellos sirve para crear y añadir nuevos roles al jugador. Para implementar adecuada-mente la semántica asociada a la creación de un rol, los métodos activadores deberánrealizar las siguientes acciones:

1. Comprobar si se cumple la restricción estática de la disyunción en el grupo rol,es decir, comprobar que no existe ya un rol activo del objeto jugador que seainstancia de otra subclase de rol que pertenezca al grupo de rol.

2. Comprobar si no se viola la restricción de cardinalidad.

Si se cumplen las condiciones 1 y 2 entonces:

3. Se ejecutará la estrategia de ejecución para dicho evento en la clase jugadora.

4. Se creará una instancia de la subclase Ci (que representará un rol concreto dela subclase de rol Ri cuyo evento de activación se corresponde con el método deactivación ejecutado). En la creación de la instancia de rol se ejecutará el métodoque implementa la estrategia de ejecución del evento activador especi…cada en elrol Ri: Este método activador actúa como un método constructor del rol por loque inicializará los atributos nuevos del rol Ri. Con la intención de preservar lapropiedad por la cual se exige que los roles no se creen de forma independiente,los roles son creados siempre por el objeto jugador (evolución vertical), lo queevita que el rol exista independientemente de la existencia del objeto jugador.Esta propiedad está soportada directamente por la solución propuesta porque lasubclase Ci hereda de CR la implementación del método activador. Este métodolo que hace es delegar en el objeto jugador la ejecución del método activador,por lo que, aunque se solicite a un rol especí…co la activación, siempre seráel objeto jugador el que se encargue de crear el rol. Esto puede causar unproblema, porque si el método activador de Ci delega en el objeto jugadorentonces no ejecutará su estrategia de ejecución. Para conservar la delegación ypoder ejecutar la estrategia de ejecución del evento en Ri, se creará un métodocon el nombre del evento activador al que se le añadirá un pre…jo r_ (que lomarcará como constructor del rol). Este método implementará la estrategia deejecución asociada al evento activador en Ri y será el método que llamará elobjeto jugador en la creación del rol.

5. La instancia creada asociará el rol con el objeto jugador que lo crea, es decir,asignará a su atributo ObjetoJugador el objeto jugador. Esto se llevará a cabopasando, en la creación de la instancia de rol, una referencia al objeto jugador.Para ello en el método de activación pre…jado con r_ hará falta un argumentoadicional al que se le pasará el objeto jugador.

6. El objeto jugador añadirá a su colección de roles ColRoles el rol creado (unainstancia de Ci).


Para entender el proceso de creación de roles presentado, se introduce a continua-ción la implementación del evento activador matricular en la clase Persona y enEstudiante. En la clase Persona se implementa el método:

public void matricular(String Carrera, int p_creditos){

Estudiante RolEstudiante;// comprobación de la restricción de disyunciónif (!GrupoRolEstudiante.isEmpty() &&!(RolPersona)(GrupoRolEstudiante.firstElement()).tiene_rol(‘‘Estudiante’’))

// si el grupo de rol no está vacío, sólo con comprobar cuál es la clase// del primer elemento ya se sabe si se viola la disyunciónthrow new NoPuedeCrearRol(‘‘Violación de Disyunción’’);// comprobación de la restricción de cardinalidadif ( !(GrupoRolEstudiante.size()>= 0 && GrupoRolEstudiante.size()<= 3))

throw new NoPuedeCrearRol(‘‘Violación cardinalidad’’);// ...// estrategia de ejecución del Jugador para este evento// ...// creación del objeto EstudianteRolEstudiante= new Estudiante;// estrategia de ejecución del evento matricular en el rol creadoRolEstudiante.r_matricular(this, carrera, p_creditos);// añade el rol a la colección de roles del grupo de rol EstudianteGrupoRolEstudiante.addElement(RolEstudiante);

}

En la clase Estudiante se implementa el método:public void r_matricular(Persona ObjJugador; String Carrera, int p_creditos){

// ...// estrategia de ejecución del Rol para este evento// ...if ObjJugador!=null Jugador=ObjJugador;// si al método lo llama el objeto jugador// entonces está creando un rol

}

7.6.4 Destrucción de Roles

La destrucción de los roles se puede llevar a cabo de dos maneras distintas:

1. Mediante la ejecución de un evento de …nalización del rol. Este evento seráun destructor propio de la subclase de rol. El evento …nalizador podrá o noexistir en el rol. Para implementar el evento de …nalización se implementaráun método mdestrucci¶onRol 2 MCinuevos con su mismo nombre, que destruiráel rol ejecutando en primer lugar la estrategia de ejecución correspondientea dicho evento, y a continuación se eliminará el rol de la colección de roles(ColRoles) del objeto jugador. Para poder eliminar el rol de dicha colecciónserá necesario un método en CJug que realice dicha operación. Éste método se


llamará eliminar_rol y recibirá un objeto rol como argumento. El métodoeliminar_rol está presente en el patrón Role Object genérico (ver …gura 7.16).En la aproximación que se presenta se restringirá su utilización para podercaptar adecuadamente la semántica del modelo. Este método no se especi…caráen la clase Componente CComp , sólo lo incorporará a la clase CJug y su accesoestará restringido a las subclases fC1; :::; Cng (como disciplina de diseño), por loque sólo se podrá llamar desde la ejecución del método …nalizador, con el únicopropósito de liberar el rol de la colección de roles que mantiene el objeto jugador.A continuación se presenta la implementación del evento terminar_estudiosdel rol Estudiante:

public void terminar_estudios(){

// estrategia de ejecución del evento destructor// ...Jugador.eliminar_rol(this);

}

2. Mediante la ejecución del evento destructor21 de la clase jugadora P . En estecaso el efecto de dicho evento será eliminar el objeto jugador y todos los roles queeste objeto esté jugando. Por de…nición si el jugador deja de existir se destruyentambién todos sus roles. Este proceso se llevará a cabo en el método encargadode implementar el evento destructor. A continuación se presenta como ejemplola implementación del evento destructor eliminar de la clase Persona:

public void eliminar(){

// estrategia de ejecución del evento destructor// ...// para cada grupo de rol (ahora para Estudiantes)while (!GrupoRolEstudiante.isEmpty()){

((Estudiante)GrupoRolEstudiante.elementAt(0)).terminar_estudios();GrupoRolEstudiante.removeElementAt(0);

}//.... para Empleados

}

7.7 El Nivel de Persistencia

El nivel de persistencia se encarga de asegurar la persistencia de los objetos del ne-gocio presentes en el nivel de aplicación. Para garantizar la persistencia es necesarioobtener una representación de las clases del modelo conceptual a través de un diseñoadecuado (relacional, objeto-relacional u orientado a objetos), dependiendo del SGBDutilizado para almacenar a los objetos del sistema. En la aproximación que se pre-senta, el modelo de datos utilizado es un modelo relacional. Además de la obtención

21Puede existir más de un evento destructor

7.7. El Nivel de Persistencia 265

del diseño relacional, se deben proporcionar componentes software que sirvan paraque los objetos del nivel de aplicación interactúen con el SGBDR. Estos componentesnormalmente llamados mediadores22, proporcionan servicios para recuperar los datosy convertir …las de tablas de la base de datos en objetos, para manipular estos objetosen el nivel de aplicación, aplicándoles eventos que modi…quen su estado, haciéndolospersistentes después de la …nalización de la ejecución de un evento. Estos compo-nentes software permiten independizar el nivel de aplicación del nivel de persistencia,ofreciendo una serie de servicios independientes del tipo de SGBD utilizado. Losentornos de desarrollo comerciales y algunos marcos de trabajo proporcionan compo-nentes de persistencia que pueden adaptarse para implementar el enlace entre el nivelde aplicación y el de persistencia.En este apartado se presentan un conjunto de técnicas necesarias para obtener

el diseño relacional de un esquema conceptual obtenido en la etapa de modelado deOO-Method. Este trabajo se centrará en la de…nición de correspondencias de losdistintos tipos de particiones (estática y dinámica) y las subclases de rol presentadasanteriormente. El objetivo va a ser proporcionar una serie de transformaciones quepermitan abordar de forma automática la obtención de un esquema de base de datosrelacional a partir de las clases del esquema conceptual.

7.7.1 Correspondencia entre Clases y Tablas Relacionales

En este apartado se presentan brevemente algunas de las técnicas utilizadas en lamayoría de los métodos orientado a objetos [31, 113, 195], para realizar la correspon-dencia entre las clases del esquema conceptual y tablas relacionales. Sobre la base deestas técnicas se presentan en los apartados siguientes una serie de correspondenciaspara convertir particiones estáticas, dinámicas y subclases de rol en tablas relacionalesy relaciones de clave ajena.

Correspondencia entre Clases y Tablas

La correspondencia más e…ciente consiste en hacer corresponder una clase con unatabla relacional. En el contexto de un esquema conceptual OO-Method se de…nen lassiguientes correspondencias:

² Cada clase se representa como una tabla dentro de su propio esquema.² Para cada atributo, se genera un campo en la tabla correspondiente a la clase.Las columnas de esta tabla serán cada uno de sus atributos constantes y varia-bles, el tipo de estos vendrá dado por la información adicional que sobre ellos seda en la especi…cación. Tan sólo se almacenarán en la Base de Datos aquellosatributos que no sean derivados, ya que estos serán calculados en tiempo deejecución.

² Cada objeto de la clase será una …la en la tabla.² Los atributos que componen el identi…cador de los objetos de la clase se re-presentarán como la(s) columna(s) que constituye(n) la clave primaria de latabla.

22Del inglés ”mediators”.


² Los atributos constantes por de…nición serán not null.² Las restricciones de integridad estáticas se pueden representar como restriccio-nes de la tabla, que se validarán sobre los atributos del objeto. En la técnicaintroducida en este capítulo se representan y validan en el nivel de aplicaciónpara poder evaluar restricciones de integridad más complejas como pueden serlas dinámicas.

Correspondencia entre Relaciones Binarias y Tablas

Dependiendo del tipo de la relación, de la cardinalidad, y de las preferencias deldiseñador de la base de datos en lo que respecta a la extensibilidad, número de tablas,y criterios de rendimiento, los desarrolladores poseen diversas opciones para traducirasociaciones y agregaciones a tablas relacionales:

² Utilizar una tabla diferente para la relación: En esta aproximación larelación se representa mediante una tabla diferente a la de las clases relacionadas.Esta aproximación proporciona gran ‡exibilidad, pero un rendimiento más bajosi se ha de recorrer muy a menudo. Esta opción se utiliza para traducir relacionesmuchos-a-muchos.

² Introducir una clave ajena: Es la aproximación más común para traducirrelaciones uno-a-uno y uno-a-muchos. En esta ocasión se incluye como claveajena la clave primaria de la que posee cardinalidad uno en la tabla de la clasede uno (en el primer caso) o de muchos (en el segundo caso). Esta soluciónmejora el rendimiento de la propuesta anterior.

² Embeber las clases en una sola tabla: En esta aproximación las dos clasesrelacionadas se mezclan en una sola tabla. Esta aproximación mejora el rendi-miento pero viola la normalización. Suele utilizarse algunas veces en relacionesuno-a-uno.

En el proceso de generación de código de OO-Method según la naturaleza de larelación se utilizan estas aproximaciones:

² Una cardinalidad de 1:M genera una clave ajena en la clase que participa concardinalidad M en la relación.

² Una cardinalidad 1:1 genera (al menos) una clave ajena.² Una cardinalidad M:N genera una tabla nueva cuya clave ajena será la com-puesta por las claves de las clases componentes. En este caso dicha clave podráser clave candidata (no siendo obligatorio que sea clave primaria). Las clavesajenas que representan a las clases componentes se de…nirán como atributos notnull en la tabla agregada, si la cardinalidad mínima es 1.

Una vez conocido el tipo de relación (en el caso de OO-Method la categoría de laagregación), se manejará la cardinalidad como se hace en [223], y se etiquetará la res-tricción de clave ajena con null, restrict o cascade para las operaciones de actualizacióny borrado según corresponda. Esta conversión se explica con detalle en [169].


Correspondencia entre Relaciones de Especialización y Tablas

Al igual que ocurre con las relaciones, la forma en que se realice la correspondencia dela especialización con la base de datos puede tener un gran impacto en el rendimien-to. Analizando algunas de las propuestas más relevantes [16, 94, 208] se identi…canesencialmente tres enfoques para convertir las relaciones de especialización en tablas:

² Particionado vertical: Esta técnica consiste en que las subclases y superclasesse corresponden cada una con una tabla. La identidad del objeto a través de unarelación de especialización se mantiene mediante un identi…cador compartidoen el que la clave primaria de la tabla que representa a la clase padre será unaclave ajena de la tabla de la clase hija. Este enfoque es limpio y extensible.Sin embargo, implica en algunas situaciones muchas tablas, y la navegaciónde superclases a subclases puede resultar lenta debido a los múltiples enlacesnecesarios para acceder a objetos de jerarquías profundas.

² Particionado horizontal: Es una técnica mucho más optimizada y su uso serecomienda cuando la especialización es completa. El particionado horizontalpropone que sólo se correspondan las subclases con tablas y que éstas incluyantodos los atributos heredados de la clase padre.

² Particionado por tipos: Esta técnica hace corresponder todas las clases deuna jerarquía de especialización en una sola tabla, utilizando una columna enla que se de…ne un campo subclase que almacena el nombre de la subclase a laque pertenece el objeto que representa la tupla. Esto permite la recuperaciónde objetos que pertenecen a muchas subclases (objetos que se encuentran enla parte inferior de la jerarquía) en una consulta sencilla, aunque esta soluciónviola la normalización y consume espacio en la tabla que puede no ser utilizado,requiriendo un uso extensivo de “null”.

La propuesta que se aplique en esta tesis debe: (1) implementar las restriccio-nes estáticas que poseen las particiones (completitud y disyunción) y los grupos derol (disyunción), (2) mantener la relación de identidad y (3) controlar la multiplici-dad, para asegurar que la transformación propuesta implementa adecuadamente lasemántica de las relaciones taxonómicas.De las propuestas existentes la solución más elegante es el particionado vertical.

El particionado horizontal necesita de una compleja codi…cación para mantener lacompletitud y la disyunción, y el particionado por tipos es poco elegante, además deconsumir muchos recursos en el caso de jerarquías profundas con gran cantidad deinformación asociada a cada subclase. Recientemente Rahayu et al. en su trabajo[186] han propuesto una extensión al particionado vertical. En dicho trabajo demues-tran de manera quantitativa que el rendimiento de su propuesta es superior al de laspropuestas más conocidas. En esta tesis se va a adaptar esta última propuesta al tipode requisitos que la semántica de las relaciones taxonómicas presentadas exige. Lanueva propuesta se llamará Particionado Vertical Extendido (PVE). En los siguientesapartados se presenta cómo se aplica esta técnica a las particiones y los grupos de rol.


7.7.2 Correspondencia entre Particiones y Tablas Relacionales

El PVE propone la creación de una tabla por cada superclase y subclase. Se añadirá unatributo (campo) adicional a la tabla de la superclase por cada partición que ésta posea(SubclaseParticion). Este atributo tendrá una restricción asociada en su creaciónque le obligará a ser not null. Esta restricción garantizará que los objetos de lasuperclase están siempre especializados en un objeto de una subclase de la partición(completitud) y que no existen ningún objeto de la superclase que pertenezca a másde una subclase de la partición (disyunción).El identi…cador de la subclase (clave primaria) será también clave ajena referen-

ciando a la superclase. Esto se exige para garantizar que el identi…cador de la subclaseexiste como identi…cador de la superclase. La restricción de integridad referencial aso-ciada al identi…cador será delete cascade y update restrict. Esto implica que cuando seelimina un registro de la superclase se debe eliminar el registro correspondiente en latabla que representa a la subclase, y que no se permite actualizar el identi…cador dela superclase cuando éste existe en la tabla de alguna subclase. En el caso de que elmodelador decida especi…car un mecanismo de identi…cación propio para la subclase,en la tabla de la subclase seguirá incluyéndose el identi…cador de la clase padre comoclave ajena y clave alternativa.En las particiones no se permitirá insertar registros sólo en la tabla de la super-

clase. La creación de un objeto de la subclase deberá implementarse mediante unatransacción que llevará a cabo las siguiente acciones: en primer lugar insertará losdatos de la tabla de la clase padre (inicializando el atributo SubclaseParticion conel nombre de la subclase a la que pertence el objeto a crear) y a continuación seinsertarán los datos de la tabla de la subclase correspondiente. El borrado de objetosde la superclase no estará permitido. Cuando se quiera eliminar un objeto de unasubclase, como se ha incluido la restricción delete cascade, se eliminará el registro dela superclase y el de la subclase activa.En las particiones dinámicas la simulación de la migración se realizará como una

transacción en la cual se borrará el registro de la tabla que representa a la subclaseorigen y se insertará un registro en la tabla que representará la subclase destino, porúltimo se actualizará el atributo SubclaseParticion (de la tabla de la superclase)con el nombre de la subclase destino.Con esta solución la restricción de multiplicidad se cumple por la relación exis-

tente entre las claves de la superclase y la subclase, además de que el atributoSubclaseParticion sólo puede almacenar un valor, lo que garantiza que un obje-to no se podrá estar especializado a la vez en más de una ocasión.

7.7.3 Correspondencia entre Grupos de Rol y Tablas Relacio-nales

El PVE propone la creación de una tabla por cada superclase (clase jugadora) ysubclase de rol. Se añadirá un atributo (campo) adicional a la tabla de la superclasepor cada grupo de rol que ésta posea (SubclaseRol). Este atributo podrá ser null,por lo que se permitirá que un objeto de la superclase no tengan ningún rol activo.La existencia de este atributo garantiza la disyunción al no permitir la existencia deningún objeto de la superclase que pertenezca a más de una subclase del grupo derol.


El identi…cador de la subclase (clave primaria) será también clave ajena referen-ciando a la superclase. Esto se exige para asegurar que el identi…cador de la subclaseexiste como identi…cador de la superclase. La restricción de integridad referencial serádelete cascade y update restrict. Esto implica que cuando se elimina un registro de lasuperclase se debe eliminar el registro correspondiente en las tablas que representana la subclase, y que no se permite actualizar el identi…cador de la superclase cuandoéste existe en las tablas de alguna subclase. En el caso de que el modelador decidaespeci…car un mecanismo de identi…cación propio para la subclase de rol, en la tablade la subclase seguirá incluyéndose el identi…cador de la clase padre como clave ajenay clave alternativa. En el caso de que la multiplicidad sea mayor que uno, dichoidenti…cador sólo será clave ajena.En los grupos de rol se permitirá insertar registros sólo en la tabla de la superclase

(inicializando el atributo SubclaseRol a null). La creación de un objeto de unasubclase de rol insertará un registro en la tabla de la subclase y actualizará el atributoSubclaseRol (de la tabla de la superclase) con el nombre de la subclase de rol. Elborrado de objetos de la superclase no estará permitido. En los grupos de rol se puedeeliminar un objeto de una subclase de rol porque ocurra el evento de …nalización delrol, en dicho caso se eliminará el registro en la tabla de la subclase y se actualizaráel atributo SubclaseRol a null, si no existen más roles activos del mismo objeto (simultiplicidad > 1). En el caso de la destrucción del objeto jugador se eliminaráel registro de la superclase y como se ha de…nido la restricción delete cascade seeliminarán los registros de la subclase de rol activa.En la solución propuesta por la tesis, el control de una multiplicidad mayor que

1 lo implementan las clases del nivel de aplicación. Si se quisiera implementar en elnivel de persistencia se podría incorporar un campo extra en la tabla de la superclasepara cada grupo de rol que almacenara la multiplicidad actual y en el momento dela activación de un rol (inserción de un registro en la tabla de la subclase de rol)se comprobaría el número de roles activos y se compararía con la cota almacenada(de…niendo una restricción de integridad estática), si la cota es menor se crea el rol y seincrementa el contador. Cuando se destruya un rol se decrementará dicho contador..

7.7.4 Ejemplo de Aplicación

En el ejemplo utilizado durante el desarrollo de la tesis se ha especi…cado (ver …gura7.19) una partición estática (de Persona en Hombre y Mujer), dos grupos de rol (dePersona en Estudiante y Empleado), y una partición dinámica (de Empleado enVendedor y Responsable). Si se aplican las correspondencias presentadas, se creará:

1. Una tabla para la clase Persona con sus atributos propios y los atributosSubclaseParticion (para almacenar el nombre de la subclase activa de la par-tición Hombre-Mujer), SubclaseRolEmpleado y SubclaseRolEstudiante (paraalmacenar el nombre de los roles activos de Empleado y Estudiante).

2. Una tabla para cada una las subclases estáticas Mujer y Hombre con sus atributosnuevos.

3. Una tabla para cada una de las subclases de rol Estudiante y Empleado. Es-ta última incluirá un atributo adicional llamado SubclaseParticion para al-


Persona

Mujer Hombre

Estudiante

Empleado

Vendedor Responsable<<sexo="M">> <<sexo="H">>

sexo

<<dinámica>>trabajo

<<jugado_por>>

<<contratar/despedir>>

<<matricular/terminar>>

<<0,3>>

Figura 7.19: Diagrama de Clases del Ejemplo

macenar el nombre de la subclase activa de la partición dinámica Vendedor-Responsable.

4. Una tabla para las subclases Vendedor y Responsable.

El diseño lógico relacional resultante se puede ver en la …gura 7.20. Donde la siglaCP signi…ca clave primaria, la sigla CE signi…ca clave ajena y la sigla U signi…ca claveúnica que con el atributo not null representa una clave alternativa. En el apéndice Ase desarrolla el ejemplo con mayor nivel de detalle.

7.7.5 El Estado del Objeto en el DTE y su Representación enTablas

La estructura de base de datos que hasta el momento se ha presentado todavía noestá completa. Del Diagrama de Clases se ha extraído toda la información necesariapara crear la estructura de tablas y los atributos, sin embargo la estructura de tablasse debe completar con información extraída de los DTE de las clases.Aunque el DTE está más relacionado con la dinámica del sistema, contiene infor-

mación que afecta a la generación de la lógica de datos. Se trata de los estados enlos que se pueden encontrar cada uno de los objetos de una clase y las transiciones deestado válidas que pueden acontecer.Cuando se crea una clase en el Diagrama de Clases no se declara de forma explícita

ningún atributo que represente el estado en que se encuentre un objeto de la misma enel DTE, sin embargo, cuando se generen en la base de datos las tablas correspondientesa las clases, se les debe añadir un campo más al que se puede llamar “estadoObj”. Estecampo se utilizará para representar el estado del Diagrama de Transición de Estadosen el que se encuentran las instancias de la clase, de forma que la lógica de aplicaciónpueda comprobar antes de lanzar ningún evento en qué estado se encuentra la clasey si el evento va a provocar una transición válida o no.


Persona

CP dni

nombreapellidossexodirecciontelefonoedadrevisionesSubclaseParticionSubclaseRolEmpleadoSubclaseRolEstudiante

Estudiante

CP cod_estudiante

totalCreditosAprobadoscursonumAsignaturasMatriculadas

CE1 dni

Empleado

CP cod_empleado

seccionpuestosalariosueldo_basetelefonofecha_contratacionfecha_revision_sueldobonificacionbajas

CE1 dniSubclaseParticion

Hombre

CP,CE1 dni

fechaIni_ServiciofechaFin_ServicioservicioduracionMesesDestino

Mujer

CP,CE1 dni

hijosestado

Vendedor

CP,CE1 cod_empleado

nVentas

Responsable

CP,CE1 cod_empleado

nVendedoresCE1, U1

Figura 7.20: Diseño Relacional

7.7.6 Clases de Acceso a Datos

El enlace entre el nivel de aplicación y el nivel de persistencia necesario para obte-ner/escribir los datos de/en la base de datos, hace necesaria la existencia de clasesque se sitúen entre ambos niveles y se responsabilicen de cargar los objetos del nivelde aplicación con datos de la base de datos y actualizar la base de datos cuando estoscambien su estado. La opción que se toma en OO-Method es una alternativa intere-sante en la que se incorpora a la arquitectura una clase llamada “Object-Mediator”[78] que es visible al nivel de aplicación y que proporciona un interfaz sencillo para ac-ceder a la base de datos. Ofreciendo llamadas generalmente sencillas como guardary cargar, que pasan toda la responsabilidad de la petición al interfaz con la basede datos. Las clases de negocio suelen acceder a estas clases mediante agregación oherencia. En este caso se utiliza la agregación, incorporando a la clase un atributoobjeto-valuado que contendrá una instancia del objeto mediador a la cual se le pediránlos servicios de persistencia. A continuación se presenta como ejemplo de aplicación laimplementación del evento subir_sueldo que una vez …nalizada la comprobación delas restricciones de integridad actualiza el objeto de la clase Empleado con su nuevosueldo base.

public void subir_sueldo(long incremento)throws Exception{

try{

comprobar_transicion_estado(subir_sueldo);eval_subir_sueldo(incremento);comprobar_restricciones_integridad();mediadorBD.guardar(); // se actualiza el objeto en la BD


comprobar_disparos();}catch (Exception e){throw new Exception();

}

Con esta técnica las responsabilidades se dividen de una forma útil, separando elinterfaz con los datos, del modelo del negocio. Aplicando esta aproximación se puedenrealizar cambios en el formato de las tablas sin alterar el modelo del dominio. Estasolución es interesante cuando los formatos de las tablas están fuera del control delequipo del proyecto o cuando las estructuras de datos pueden cambiar para mejorar elrendimiento. Cuanta mayor sea la volatilidad de las fuentes de datos, más importanteserá utilizar este componente intermedio.

7.8 El Nivel de Presentación

El nivel de presentación se encarga de ofrecer al usuario todos los recursos disponiblespara permitir la activación de eventos sobre la sociedad de objetos que constituyenla aplicación. Además proporciona mecanismos de búsqueda y navegación sobre laspoblaciones de las clases para facilitar su búsqueda. La invocación de un evento,una vez se han recogido los argumentos necesarios a través de la interfaz de usuario,realizará una llamada a un servicio de un componente en el nivel de aplicación paraque resuelva su ejecución.El propósito de este apartado es presentar cómo se ve afectado el nivel de interfaz

cuando debe generarse código para soportar las relaciones taxonómicas presentadas enesta tesis, y aportar soluciones para su implementación. El apartado se estructura dela siguiente manera: en primer lugar se presenta una propuesta básica para la genera-ción automática de la interfaz de usuario de una aplicación, a continuación se presentacómo se ve afectada la interfaz de usuario propuesta por cada una de las relacionestaxonómicas introducidas. Se analizan y proponen soluciones para modi…car el menúde la aplicación, para tratar la introducción de valores de atributos en la creación deobjetos especializados y roles, y por último se tratan temas como las observacionesde la población de objetos y la navegabilidad entre relaciones taxonómicas.

7.8.1 Interfaz de Usuario de la Aplicación

Existen innumerables soluciones posibles de interfaz grá…ca de usuario (IGU) para unmismo problema. Con el …n de garantizar la calidad de las interfaces obtenidas, elproceso de generación elegido tiene en cuenta principios de ergonomía y de consistenciafrente al entorno en el cual se implementa la solución. En este apartado se presentala solución adoptada en OO-Method [147, 148] para la generación automática de laIGU del sistema modelado.Adoptando la política de acción verbo-nombre, la IGU consta básicamente de un

menú principal del que cuelgan las clases y subclases en menús en cascada y dondeaparece una entrada de menú por cada evento que puede ser lanzado. Para cada eventoexistirá una pantalla donde se solicitarán los argumentos del evento al usuario. Entreellos, y debido a que se emplea el paradigma verbo-nombre, estará el identi…cador delobjeto al que se le pide el evento.Los elementos visuales que tendrá la aplicación generada serán los siguientes:

7.8. El Nivel de Presentación 273

² Una ventana inicial de autorización donde el usuario se identi…ca como perte-neciente a una determinada clase (de entre las agentes del sistema), indicandoun identi…cador y una clave de acceso.

² Un formulario principal (ver …gura 7.21) que servirá de puerta de entrada a laaplicación una vez superada la identi…cación.

² Un menú de aplicación que tendrá los siguientes elementos visuales:– Un menú “Fichero” donde se encuentran las opciones “Accesos” y “Salir”

– Un título de menú por cada clase simple.

¤ Una entrada de observaciones para cada clase.¤ Una entrada por cada evento perteneciente a una clase.

– Un título de menú del que cuelgan las interacciones globales.

² Para cada evento un formulario de petición de argumentos. La selección de unevento desde el menú invoca a su correspondiente formulario (ver …gura 7.22)donde se indican cada uno de los argumentos necesarios para la correcta invo-cación del evento. Entre los argumentos aparecen tanto los explícitos, como losimplícitos. Los argumentos explícitos son los declarados como información delevento. Los argumentos implícitos son los que permiten identi…car el objetoservidor del evento. Cada control que recoge datos (cajas de texto, cajas combi-nadas, listas, etc.) tiene la información su…ciente (introducida en el modelo deinterfaz, a través de patrones de interfaz) para hacer una validación de su con-tenido y disponen del código necesario para hacer dichas validaciones y avisaral usuario de sus errores cuando intente lanzar el evento.

La información necesaria para construir la interfaz de usuario está totalmenteincluida en la especi…cación del sistema obtenida en la fase de modelado conceptual.En el caso de clases que se relacionan mediante especialización o rol, el nivel de

presentación generado debe incorporar un tratamiento especí…co para objetos de lassubclases y de la superclase, como se presenta en los siguientes apartados.

7.8.2 Las Relaciones Taxonómicas y el Menú de la Aplicación

En cuanto al menú de la aplicación generada concretamente se pueden dar las siguien-tes situaciones:

1. Se trabaja sólo con objetos de las subclases. Por tanto se necesitaráuna entrada de menú por cada subclase y no hará falta una entrada de menúpara la clase padre. El tratamiento de las subclases en el nivel de presentaciónserá igual que el de una clase simple, mientras que la clase padre no apareceráen el menú de la aplicación. Otra opción no descartable en esta situación esque la clase padre aparezca como opción de menú pero sólo para acceder alas subclases que …gurarán como opciones de la clase padre. Esta situaciónsólo tiene sentido en especializaciones estáticas (por la posibilidad de creacióndirecta) y dinámicas (por la posibilidad de tratar de forma independiente losestados de la superclase).


Figura 7.21: Pantalla principal de la aplicación

Figura 7.22: Ventana asociada al evento Matricular


2. Se trabaja sólo con objetos de la clase padre. Se necesitará una entradade menú para la clase padre. Una vez seleccionada alguna opción (activación deevento u observación del estado o la población), dependiendo de a qué subclasepertenecen los objetos se tratarán, a nivel de propiedades visibles (eventos yatributos), de una manera u otra. Esta situación se puede dar en todas lasrelaciones taxonómicas presentadas.

3. Se trabaja tanto con objetos de la clase padre como con objetos delas subclases. En este caso se necesitará una entrada de menú tanto para laclase padre como para las subclases. Las subclases se consideran opciones delmenú de la clase padre. Estas opciones tendrán asociado un submenú con lasmismas opciones que una clase simple. Esta situación se puede dar en todas lasrelaciones taxonómicas presentadas.

Es importante destacar que estas posibles soluciones deberían ser con…gurables porel analista, para que dependiendo de los requisitos de usuario, se elija una solución uotra, o combinación de las tres.

7.8.3 Introducción de Datos en la Creación de Objetos

Una vez vistas las representaciones posibles de las clases que participan en las rela-ciones taxonómicas, se debe tratar otro problema que afecta a cómo se resuelve en elnivel de presentación la interacción con el usuario en situaciones en las que se creanobjetos especializados o roles, y es necesario introducir los valores de los atributosnuevos de los objetos especializados.Cuando se crea un objeto de una clase, es sencillo conocer los atributos de la clase a

los cuales el usuario deberá proporcionar un valor, ya que se conocen los argumentosimplícitos y explícitos que posee el evento constructor. Si la clase se especializa oposee algún rol, se debe solicitar el valor de alguno de los atributos emergentes delas clases especializadas o roles, de forma que se pueda inicializar correctamente elestado de dichos objetos. A continuación se va a tratar como se resuelve en el nivelde presentación esta situación para los distintos tipos de relaciones taxonómicas.

Introducción de los Valores de los Atributos en Especializaciones Estáticas

La creación de objetos especializados estáticamente se puede llevar a cabo mediantecreación directa o tras las comprobación de las condiciones de especialización sobreatributos constantes del objeto de la clase padre.En la creación directa el constructor de la subclase posee todos los argumentos

que se deben pedir al usuario.En el caso de las condiciones de especialización, en el momento de la construcción

del objeto cuando se le dan valor a los argumentos del constructor se podrá conocer enqué subclase se especializa el objeto permanentemente, porque uno de los argumentosserá el valor que se le va a dar al atributo constante que forma parte de la condiciónde especialización. Por ello, se pueden pedir en dicho momento los valores de losatributos emergentes de la subclase en que se va a especializar.Para llevar a cabo este proceso de especialización, en el nivel de presentación se

introducirá la lógica necesaria para realizar las comprobaciones de las condiciones de


Figura 7.23: Introducción de los valores de los atributos de las especializaciones es-táticas

especialización, y dinámicamente se mostrarán u ocultarán (activar o desactivar) lascajas de introducción de valores de los atributos de las clases especializadas, tal y comose muestra en la …gura 7.23. Otras opciones interesantes consisten en aceptar primerola introducción de los valores de la clase padre y posteriormente ir solicitando los delas subclases según las condiciones que se cumplan, tal y como se muestra en la …gura7.24. En este caso, se cumple la condición de especialización sexo = ‘‘Hombre’’, porlo cual se activan los mecanismos necesarios para introducir los atributos emergentesde la subclase Hombre.Una vez recogida a nivel de interfaz la información necesaria, se construye un men-

saje (el constructor) que contendrá como argumentos todos los valores de los atributosnecesarios, tanto de la clase base como de sus especializaciones. Este mensaje se en-vía a una clase del nivel de aplicación que se encarga de crear el objeto de negociocorrespondiente.

Introducción de los Valores de los Atributos en Especializaciones Dinámi-cas

La creación de objetos especializados de forma dinámica se puede llevar a cabo me-diante el cumplimiento de ciertas condiciones de especialización sobre atributos va-riables del objeto de la clase padre o mediante la activación de eventos de migración.Cuando la especialización ocurre durante la creación del objeto de la clase padre,

en el caso de las condiciones de especialización, se puede conocer a partir del valor delatributo variable que forma la condición en qué subclase se va a especializar, y en elcaso de los eventos de migración se conoce cuál es la subclase inicial en la migración,por lo que en estos casos los métodos de introducción de los valores de los atributospresentados en el apartado anterior son perfectamente válidos.Como se puede ver en la …gura 7.25, en el momento de la introducción de todos los

valores de los atributos que ocurren en la condición de especialización (profesion =‘‘Profesor’’) se muestran los atributos de la clase Profesor para poder ser intro-ducidos. De esta manera se logra un efecto de adaptación automática de la interfazpara capturar la semántica de las especializaciones. Esta solución facilita el trabajo alos usuarios ya que no tienen que esperar a aceptar los valores de la clase padre para


Figura 7.24: Introducción de los valores de los atributos de las especializaciones es-táticas

introducir los de la subclase.En las particiones dinámicas por evento, no será necesario implementar este dina-

mismo para los diálogos de la interfaz, ya que el diagrama de migración marca cualserá la clase que se activará por defecto en la construcción del objeto. En la …gura7.26 se puede observar que al crearse una instancia de la clase Persona, automática-mente se especializará en Soltera. En este caso Soltera será la subclase inicial deldiagrama de migración asociado a una partición dinámica de Persona en Soltera,Casada y Divorciada.La única diferencia respecto a las subclases estáticas se dará cuando se realice la

migración (ya sea por condición o por evento) una vez creado el objeto. La imple-

Figura 7.25: Comprobación dinámica de la condición de especialización


Figura 7.26: Petición de los valores de los atributos de la subclase Soltero (Especiali-zación Dinámica por Evento)

mentación de esta situación se puede abordar de dos maneras:

1. El Cliente Acepta Peticiones de Información por Parte del Servidor. Esta aproxi-mación consiste en ejecutar el evento del objeto sin tener en cuenta si se puedenproducir migraciones por la ocurrencia del evento. Cuando se realiza la invo-cación del evento solo será necesario introducir los argumentos de…nidos paraese evento. A continuación, se lanzará el método que implementa el evento enel nivel de aplicación, si se produce una migración, el nivel de aplicación seencargará de realizar la petición al nivel de presentación de los valores de losatributos de la clase especializada. El usuario introducirá los valores y el nivelde presentación enviará al nivel de aplicación los valores solicitados, …nalizandoéste la ejecución del evento y devolviendo el control al nivel de presentación.En la …gura 7.27 se puede ver una ventana de información adicional que servirápara pedir el valor de alguno de los atributos de la nueva faceta adquirida.

2. El Cliente no Acepta Peticiones de Información por Parte del Servidor. Actualmenteexisten entornos de ejecución como aplicaciones WEB o sistemas transacciona-les donde la anterior opción no sería aplicable dado que los navegadores WEBsuelen incorporar políticas de seguridad bastante estrictas que no permiten laaceptación de conexiones desde ninguna máquina, y que los sistemas transaccio-nales exigen a los clientes el envío de un único mensaje con toda la informaciónnecesaria para ejecutar un evento transaccional, prohibiendo la comunicacióncon el cliente durante la ejecución de la transacción. Estas restricciones exigenintroducir una nueva aproximación para abordar la especialización dinámica desubclases durante el lanzamiento de cualquier evento que pueda hacer migraral objeto. La solución pasa por un análisis previo de la especi…cación y portrasladar la semántica de la migración al nivel de presentación. Así pues, en elcaso de:

(a) las condiciones de especialización: para cada evento que pueda afectaral valor del atributo en la condición de especialización (información incluidaen la evaluación y/o en el diagrama de migración) se comprobará a nivelde presentación qué efectos (sólo es necesaria la evaluación) va a producir


Figura 7.27: Información adicional para la subclase Estudiante

sobre él, concretamente, si el efecto hace que se cumpla la condición deespecialización entonces se le pedirá al usuario los atributos propios de lasubclase a la que va a migrar antes de lanzar el evento.

(b) la ejecución de los eventos de migración: en este caso el diagrama demigración permite conocer cuál el la subclase a la que se va a migrar antesde lanzar el evento, por tanto se le pueden pedir al usuario los atributospropios de la subclase destino antes de enviar el evento. Para conseguirlose puede trasladar parte de la lógica del diagrama de migración al nivel depresentación.

Introducción de los Valores de los Atributos en Subclases de Rol

La creación de roles se lleva a cabo mediante la ejecución de eventos activadores.Cada uno de estos eventos está asociado a una subclase de rol, por lo que cuando selanzan se conoce la subclase de rol en la cual se va a crear el rol, por tanto, antes desu lanzamiento se pueden pedir los atributos necesarios para la creación del rol.

7.8.4 Observaciones y Navegabilidad

En cuanto a las observaciones que se podrán realizar sobre las subclases, en las venta-nas de observación se podrán ver todas las propiedades (atributos y eventos) propiasy nuevas de las subclases. En el caso de las clases padre, cuando se está trabajandocon una instancia de una clase que se especializa en varias subclases se debe ofrecer alusuario la posibilidad de acceder (navegar) a sus facetas o propiedades como objetoespecializado o rol. En algunas ocasiones se puede querer ir de la observación deuna instancia de una clase hija a la observación de su clase padre. Estos patronesestán tipi…cados en los patrones de Interfaz de Usuario que ya hay de…nidos paraOO-Method en [147, 170] y que se corresponden con la “navegación ofertada” para elpatrón de Selección de Población y el Patrón de Presentación de Instancia que de…neel Patrón de Selección de Acción en su variante Navegación Ofertada. En la …gura7.28 se presenta la ventana de observación de una instancia de la clase Cliente y lasfacetas Estudiante y Empleado por las que se puede navegar.


Figura 7.28: Observaciones y Navegabilidad en la clase Cliente

7.9 Conclusiones

En este capítulo se ha presentado un proceso de generación de código basado enpatrones de diseño para las relaciones taxonómicas del modelo OASIS. Este procesoaplica la estrategia de generación de código propuesta en el Modelo de EjecuciónExtendido que incorpora técnicas basadas en patrones a través de una serie de etapas.En primer lugar se han identi…cado cuáles son los patrones de diseño que permiten

representar de forma más directa y precisa las relaciones taxonómicas en el espaciode la solución. Este proceso se ha llevado a cabo analizando los patrones de diseño ytécnicas de implementación que implementan relaciones taxonómicas en la práctica.Para realizar la selección se ha utilizado el marco propuesto en el capítulo 4. El marcoha permitido conocer cómo soportan estos patrones a las características estructuralesy de comportamiento que poseen las relaciones taxonómicas.Una vez seleccionados los patrones, se han detectado qué características de las

relaciones taxonómicas no son capaces de dar soporte directo. El siguiente paso haconsistido en incorporar a dichos patrones las características necesarias para poderimplementar completamente el patrón conceptual mediante un proceso de especializa-ción. Una de las características que los patrones de diseño no soportaban directamenteha sido la implementación del comportamiento del objeto siguiendo la estrategia deejecución. Esta característica se ha incorporado a los patrones recomendando la uti-lización del patrón Template Method para implementar la estrategia de ejecución.La última etapa del proceso ha consistido en de…nir un conjunto de correspon-

dencias precisas entre los distintos tipos de relaciones taxonómicas presentes en OO-Method y los patrones de diseño seleccionados y adaptados. De esta forma se haproporcionado la infraestructura necesaria para construir generadores de código au-tomáticos que produzcan código de calidad automáticamente.La generación de código que se ha presentado se ha llevado a cabo en arquitecturas

de tres niveles. El trabajo se ha centrado en abordar con todo nivel de detalle lageneración de los componentes software del nivel de aplicación, donde se implementala lógica de los objetos de negocio, pero no ha olvidado la generación del nivel de


persistencia y el de presentación, por lo que en la última parte del capítulo se haexplicado cómo se puede generar el esquema de la base de datos y la interfaz grá…cade usuario.

Capítulo 8

Conclusiones

En este último capítulo, se presentan las conclusiones sobre el trabajo de tesis des-arrollado. En primer lugar, se enumeran las principales contribuciones a los métodosde desarrollo de software actuales, en segundo lugar se comentan algunas de las ex-tensiones que se pueden incorporar al trabajo desarrollado y por último algunas líneasde trabajo futuro que se están llevando a cabo.

8.1 Contribuciones

Los métodos de desarrollo de software deben evolucionar de forma continua mediantela incorporación de nuevas técnicas de modelado, diseño e implementación, re…nandolos procesos de desarrollo que proponen, con la …nalidad de producir software de ca-lidad y de alcanzar una elevada productividad. En esta tesis se han aportado ideasnuevas que ayuden a mejorar los procesos de producción de software, en especial elde OO-Method. Las contribuciones esenciales de la tesis se enmarcan en dos áreas:(1) En el modelado conceptual : de…niendo un modelo de relaciones taxonómicas ex-presivo, y desarrollando una notación estándar para su aplicación en la construccióndel esquema conceptual; (2) En el proceso de desarrollo: incorporando de forma dis-ciplinada y sistemática técnicas basadas en patrones software que proporcionan unenfoque metodológico para guiar el proceso de modelado de relaciones taxonómicas yautomatizar la generación de código.Las contribuciones especí…cas de la tesis son las siguientes:

1. El desarrollo de un marco general de referencia para caracterizar los distintostipos de relaciones taxonómicas existentes en el modelado conceptual OO. Sehan presentado diversas aplicaciones del marco, y en particular éste se ha apli-cado para: (1) caracterizar las relaciones taxonómicas propuestas, (2) construirel lenguaje de patrones y (3) evaluar la adecuación de las técnicas de implemen-tación estudiadas.

2. La incorporación a OO-Method de un nuevo modelo formal de relaciones taxo-nómicas basado en OASIS y el desarrollo de una notación basada en UML paradar soporte grá…co (a nivel estructural y de comportamiento) al nuevo conjuntode patrones conceptuales introducidos. De esta forma se han proporcionando

283

284 Capítulo 8. Conclusiones

un conjunto de construcciones conceptuales expresivas que permiten describirde forma no ambigua las taxonomías presentes en los esquemas conceptualesOO.

3. La propuesta de un lenguaje de patrones que sirve como guía precisa de ayudaal modelado de relaciones taxonómicas. Este lenguaje se ha construido tomandocomo base las dimensiones del marco de referencia propuesto y las característicasdel modelo taxonómico de…nido. El proceso de construcción del lenguaje puedeser adaptado fácilmente para proponer lenguajes para distintos tipos de modelostaxonómicos.

4. La introducción de una estructura navegacional basada en preguntas de ayudaa la identi…cación y especi…cación de relaciones taxonómicas. Esta estructurade navegación se ha obtenido a partir del lenguaje de patrones y de las rela-ciones entre éstos. Además, se ha desarrollado un método para su aplicaciónsistemática.

5. La evaluación de las técnicas de implementación y patrones de diseño que sepueden aplicar para implementar las relaciones taxonómicas. Este estudio se harealizado haciendo uso del marco propuesto. Además ha permitido: seleccionaraquellos patrones de diseño que faciliten una representación software precisa decada relación taxonómica, detectar las carencias expresivas de los patrones dediseño, y determinar cómo se deben extender/adaptar (lo que se ha llamadoespecialización) para dar un soporte completo a las relaciones taxonómicas enel espacio de la solución.

6. La propuesta de un proceso completo de generación de código, en el cual se hande…nido correspondencias precisas (a nivel estructural y de comportamiento)entre los distintos tipos de relaciones taxonómicas presentes en el espacio delproblema y los patrones de diseño especializados, que han sido seleccionados yadaptados. La utilización de estructuras de diseño de calidad ha facilitado laestructuración de la generación de código y ha permitido representar adecuada-mente los patrones conceptuales seleccionados.

Las ideas presentadas se han aplicado en el contexto de OO-Method, pero son per-fectamente extrapolables a cualquier método de desarrollo, siempre que los patronesconceptuales utilizados posean una semántica bien de…nida.El trabajo realizado en esta tesis constituye una primera aproximación a la conse-

cución de lo que podría ser un objetivo más general a largo plazo: la orientación delproceso de desarrollo de software hacia tareas de alto nivel de abstracción que ocultenadecuadamente la complejidad tecnológica. Esto se llevará a cabo automatizandocompletamente el proceso de producción de software, desde el modelado conceptual(mediante la construcción de entornos activos [114] de producción de software queproporcionen herramientas para la construcción incremental del esquema conceptual,ayudando al analista en la toma de decisiones de modelado) hasta la implementación(mediante generadores automáticos de código).

8.2. Trabajo Futuro 285

8.2 Trabajo Futuro

El trabajo desarrollado tiene continuidad en al menos tres áreas de trabajo que sepueden abordar en un futuro próximo. Estas tres áreas son:

Extensión del Trabajo Desarrollado

El trabajo desarrollado en la tesis puede ampliarse mediante:

² La extensión del método incorporando la capacidad de seleccionar un estiloarquitectónico a utilizar en la aplicación. Con esta mejora, a partir de lospatrones conceptuales y el estilo arquitectónico (capas, cliente-servidor, ”peers”descentralizados, ...) se deberían producir los patrones de diseño de acuerdo auna arquitectura software determinada.

² La depuración y/o extensión del marco de referencia propuesto, re…nando lasdimensiones existentes o introduciendo nuevas.

² La construcción de un asistente de modelado [42] que facilitará la identi…caciónde las relaciones taxonómicas. Este asistente está siendo desarrollado actual-mente como un “Add-In”1 de la herramienta CASE Rational Rose. El asistentese basa en el lenguaje de patrones y en las preguntas propuestas en el capítu-lo 6 de la tesis. La herramienta ayuda en la toma de decisiones de modeladoaconsejando qué patrón conceptual especi…car y cómo especi…carlo, según unaserie de características estructurales y de comportamiento detectadas, mediantepreguntas, durante el proceso de modelado .

² La construcción de una herramienta de validación que ayude al desarrollador aidenti…car en el prototipo generado situaciones de funcionamiento que eviden-cien comportamientos no deseados o incompletitud del esquema conceptual. Sila funcionalidad no es la esperada, se identi…carán las decisiones de modela-do erróneas y se modi…cará el esquema de forma interactiva hasta conseguir lafuncionalidad deseada.

² La incorporación de un tratamiento completo de especi…cación y gestión deexcepciones [4], implementación de atributos derivados [5], y el estudio de cómose ve afectada la implementación de transacciones [3] en las taxonomías. Estostrabajos están llevándose a cabo actualmente y ya han dado fruto a algunaspublicaciones donde se presentan resultados iniciales.

² El tratamiento, a nivel de especi…cación e implementación, de los problemassobre la interacción y dependencias entre distintos roles que están activos si-multáneamente. Tomando como punto de partida la propuesta presentada porPernici en [181].

² El estudio en casos reales de la necesidad de relajar las condiciones de especia-lización, exigiendo compatibilidad de signatura.

1Aplicación o componente software que se utiliza para extender la funcionalidad de aplicacionesexistentes.


Por último, es importante destacar que, en la actualidad, el trabajo desarrolladoen la tesis está siendo incorporado progresivamente en un entorno CASE industrial[167] que da soporte a OO-Method.

Interactuar con otras Líneas de Trabajo en el Contexto de OO-Method

Actualmente existen tres líneas de trabajo desarrolladas en paralelo alrededor de OO-Method, con las que el trabajo presentado puede interactuar mejorando las propuestasexistentes. Estas líneas son la Ingeniería de Requisitos, las Interfaces Grá…cas deUsuario y el Modelado de Aplicaciones WEB.

1. En la línea de la Ingeniería de Requisitos se está desarrollando un trabajo [108]en el cual se utilizan técnicas como los Casos de Uso y los Diagramas de Secuen-cia para la elicitación de requisitos. Este trabajo introduce un nuevo modelollamadoModelo de Requisitos que constituye el punto de entrada a OO-Method.Este modelo permite obtener los requisitos de la aplicación en las fases inicialesdel proceso de desarrollo, y a partir de éstos se ha desarrollado un proceso se-miautomático que permite obtener el diagrama de clases. En la actualidad sólose obtienen las clases simples y son necesarias nuevas heurísticas para obtenerlas agregaciones, asociaciones y especializaciones. En este aspecto la tesis puedeayudar introduciendo el uso del lenguaje de patrones y la estructura navegacio-nal en la etapa de obtención de clases, o utilizando las ideas subyacentes paraproporcionar heurísticas.

2. En la línea de las Interfaces Grá…cas de Usuario se están enriqueciendo las téc-nicas de modelado existentes con modelos que permitan modelar aspectos deinteracción con el usuario. Se está desarrollando un trabajo [147] que introduceen OO-Method un Modelo de Presentación que permite especi…car a nivel deespacio del problema cómo va a ser la interacción del usuario con el sistema deinformación. El modelo permite especi…car patrones de interfaz, la de…niciónde Vistas y la especi…cación de un modelo de navegación. De esta forma sedeterminan cuáles son las propiedades que deberá tener una interfaz de usuarioconcreta, independientemente de la implementación particular que se obtengacomo producto software …nal. El trabajo de tesis puede in‡uir en este Modelode Presentación introduciendo nuevos patrones de interfaz y técnicas navega-cionales inducidas por las relaciones taxonómicas tal y como se ha visto en elcapítulo 8, y como comenta Lauesen en [124, 125].

3. En el línea de Modelado de Aplicaciones WEB [163, 164] al igual que en elModelo de Presentación se introduce un modelo navegacional en la etapade modelado conceptual. Este modelo permite representar adecuadamente losrequisitos navegacionales que introduce el WEB a nivel de interfaz de usuario.En esta línea al igual que en la anterior el trabajo de tesis puede aportar nuevospatrones de navegación cuando los objetos que se muestran o acceden en laspáginas WEB forman parte de una estructura taxonómica.

Por último es interesante comentar una nueva línea de trabajo conjunta que in-corpora gran parte de las ideas presentadas en esta tesis. Esta línea renombra el

8.2. Trabajo Futuro 287

proceso de producción de software propuesto por OO-Method como “Extreme Con-ceptual Modeling”, trasladando alguna de las ideas de la Programación Extrema aOO-Method, pero cambiando el nivel de abstracción en el que se aplican. Se proponeel uso de manera extrema de las abstracciones de alto nivel como construcciones deprogramación. En este caso se piensa que la elaboración de un esquema conceptuales realmente “programación” a alto nivel de abstracción. Este enfoque se puede con-seguir si se proporciona un entorno que a partir de los esquemas conceptuales generecódigo automáticamente (en este caso OO-Method y la propuesta de la tesis). Deesta manera el desarrollador sólo tendrá que concentrarse en las tareas de elicitaciónde requisitos y de modelado conceptual.

De…nir Nuevas Líneas de Trabajo

A continuación se presentan nuevas líneas de trabajo, algunas ya en desarrollo y otraspendientes de inicio:

² Las ideas del trabajo de tesis se están aplicando a otro patrón conceptual deOO-Method: la agregación. Se está construyendo un nuevo marco de referencia[38] (incorporando algunas ideas de la propuesta de Henderson-Sellers et al.[105] para la caracterización precisa de la agregación), y se está proporcionandoun proceso de generación de código basado en patrones de diseño.

² La introducción de métricas para medir la calidad de las taxonomías modela-das en el esquema conceptual es un tema que debe ser abordado para podercomparar distintas representaciones del mismo problema.

² Una línea interesante puede ser la construcción de Marcos de Trabajo (Frame-works) junto con guías precisas para su instanciación, a partir de los patronesde diseño especializados que se han introducido en esta tesis. De esta forma seofrecerá a los desarrolladores estructuras de diseño complejas que puedan reuti-lizar sin necesidad de utilizar OO-Method. Algunas herramientas CASE comoTogether [226] (con la patrones de diseño de Gamma, Coad y EJB) y RationalRose [58] están empezando a adoptar esta idea de forma parcial, porque node…nen guías para su instanciación.

² Otro trabajo de interés será llevar la propuesta del marco de referencia al grupode investigadores que conforman el “Precise UML Group”2 [225], y trabajar con-juntamente en el desarrollo de una propuesta estándar que mejore la existenteactualmente.

² Para …nalizar, se puede trasladar la experiencia adquirida en el desarrollo dellenguaje de patrones propuesto al conjunto de líneas de trabajo de OO-Method,con la intención de construir, mediante un lenguaje de patrones uni…cado, unaguía completa que documente el proceso de desarrollo seguido en OO-Method.

2Un grupo de investigadores de todo el mundo que intentan proporcionar una semántica precisaa las abstracciones presentes en el estándar UML.


8.3 Publicaciones Relacionadas con la Tesis

En este apartado se indican las publicaciones en las cuales ha participado el autor yque están relacionadas con el trabajo de tesis desarrollado. A continuación se detallala relación de las mismas clasi…cadas por tipo de publicación (Artículos en Revista,Congresos Internacionales y Nacionales). También se han incluido los Proyectos deFin de Carrera dirigidos por el autor en la Escuela Universitaria de Informática y en laFacultad de Informática de la Universidad Politécnica de Valencia que han contribuidoa la consecución de objetivos desde un punto de vista de implementación.

Artículos en Revista

² V. Pelechano, O. Pastor, J. Sánchez. Especialización Dinámica y GeneraciónAutomática de Código. Un Enfoque Basado en Patrones. NOVATICA, (147):4449, Noviembre 2000.

² O. Pastor, J. Gómez, E. Insfrán, V. Pelechano. The OO-Method Approach forInformation Systems Modelling: From Object-Oriented Conceptual Modeling toAutomated Programming. Information Systems, 26(7): pags. 507-534, Perga-mon / Elsevier Science, 2001.

² V. Pelechano, O. Pastor, E. Insfrán. Automated Code Generation of DynamicSpecializations. An Approach Based on Design Patterns and Formal Techniques,Data & Knowledge Engineering, North-Holland / Elsevier Science. Aceptadoen Septiembre de 2001 para su publicación.

Congresos Internacionales

² O. Pastor, V. Pelechano, E. Insfrán, J. Gómez. From Object Oriented Con-ceptual Modeling to Automated Programming in Java. In 17th InternationalConference on Conceptual Modeling (ER98), Springer-Verlag. Lecture Notes inComputer Science (1507).pags. 183-196, Singapur, Noviembre 1998.

² J. Gómez, E. Insfrán, V. Pelechano, O. Pastor. The Execution Model: A Compo-nent-based Architecture to Generate Software Components from Conceptual Mo-dels. CAiSE’98 Workshop on Component-based Information Systems Engine-ering (CBISE’98). Pisa, Italia. Junio 8-12, 1998. pags. 87-94, 1998.

² J. Gómez, O. Pastor, E. Insfrán, V. Pelechano. From Object-Oriented Concep-tual Modeling to Component-Based Development. 10th International Conferenceon Database and Expert Systems Applications (DEXA’99). Florencia, Italia.Springer-Verlag. Lecture Notes in Computer Science (1677), pags 332-341, 1999.

² V. Pelechano, O. Pastor, J. Sánchez. An Automatic Code Generation Process forDynamic Specialization based on Design Patterns and Formal Techniques. The16th IFIP World Computer Congress. International Conference on Software:Theory and Practice (ICS2000), pages 526-539. Editores Marie-Claude GaudelYulin Feng, David Notkin, Publishing House of Electronics Industry, Agosto2000.

8.3. Publicaciones Relacionadas con la Tesis 289

² V. Pelechano, M. Albert, E. Campos, O. Pastor. A Code Generation Process forRole Classes: An approach based on Formal Techniques and Design Patterns,TOOLS-EASTERN EUROPE, Aceptado para publicación.

² V. Pelechano, O. Pastor, E. Campos, M. Albert. Dynamic Integrity Cons-traints Checking in an Automatic Software Production Method. ArgentinianSymposium on Software Engineering - ASSE 2001, pags. 161-176, 2001.

² E. Campos, M. Albert, V. Pelechano, O. Pastor. Implementación de un Mo-delo de Ejecución en Entornos Orientados a Objetos para los Disparos de OO-Method. Jornadas Chilenas de Computación 2001- IX Encuentro Chileno deComputación, Noviembre 2001.

² M. Albert, E. Campos, V. Pelechano, O. Pastor. Tratamiento de Atributos Deri-vados en Entornos de Producción Automática de Software Orientado a Objetos.Workshop Iberoamericano de Ingenieria de Requisitos y Ambientes SoftwareIDEAS 2001, San José, Costa Rica, pags. 117-131, 2001.

Congresos Nacionales

² V. Pelechano, J. Sánchez, O. Pastor. Especialización dinámica y GeneraciónAutomática de Código. Un Enfoque basado en patrones. Actas de las IV Jorna-das de Trabajo en Ingeniería del Software y Bases de Datos (JISBD 99), Cáceres,Extremadura. Noviembre 1999. pags.233-244 1999.

² P. Sánchez, P. Letelier, J.A.Troyano, V. Pelechano, J. Torres. Especializaciónen el Ámbito del Modelado Conceptual. Actas de las IV Jornadas de Trabajo enIngeniería del Software y Bases de Datos (JISBD 99), Cáceres, Extremadura.Noviembre 1999.

² J. Sánchez, V. Pelechano, O. Pastor. State Types and Dynamic Signatures inOO-Method. Actas de las IV Jornadas de Trabajo Menhir, Sedano-Burgos, pags64-68, 1999.

² M. Albert, E. Campos, V. Pelechano, M. Katrib. Tratamiento de Excepcionesa Nivel de Modelado Conceptual OO. Actas de las VI Jornadas de Trabajo enIngeniería del Software y Bases de Datos (JISBD 2001), Almagro, Ciudad Real.Noviembre 2001.

Proyectos de Fin de Carrera

² Análisis, Diseño e Implementación de un generador automático de código Delphi4.0 a partir de un modelo conceptual Orientado a Objetos con relaciones deherencia. Enero 1999. Escuela Universitaria de Informática (UPV).

² Análisis, Diseño e Implementación de un generador automático de código Del-phi 4.0 a partir de un modelo conceptual Orientado a Objetos con particionesestáticas, dinámicas y grupos de roles. Enero 1999. Escuela Universitaria deInformática (UPV).


² Análisis, Diseño e Implementación de un generador automático de interfaces deusuario a partir de un modelo conceptual OO. Enero 1999. Escuela Universitariade Informática (UPV).

² El patrón conceptual de herencia en OASIS 3.0/OO-Method, Análisis y Genera-ción de Código Java utilizando patrones de diseño. Septiembre 1999. Facultadde Informática (UPV).

² Desarrollo de un Generador Automático de Aplicaciones de Gestión en VisualBasic. Junio 2000.Facultad de Informática (UPV).

² Gestión y Mantenimiento de un diccionario de datos para Modelos ConceptualesOO-Method. Julio 2000. Facultad de Informática (UPV).

² Catálogo de patrones de Herencia para OO-Method: Especi…cación e Implemen-tación. Septiembre 2000 Facultad de Informática (UPV).

² Implementación de una Herramienta de Ayuda al Modelado Conceptual basadaen Patrones. Diciembre 2001 Facultad de Informática (UPV).

Apéndice A

Ejemplo de Aplicación

En este apéndice se desarrolla un caso de estudio completo en el que se aplica deforma sistemática el proceso de producción de software presentado en esta tesis. Elejemplo aborda desde la etapa de modelado hasta la generación de código Java de lasiguiente manera:

1. se construye el esquema conceptual OO-Method siguiendo la notación basadaen UML (propuesta en el capítulo 5), aplicando como guías de modelado, el len-guaje de patrones especializado y la estructura de preguntas que se presentaronen el capítulo 6,

2. se obtiene la especi…cación OASIS del esquema conceptual obtenido,3. se aplica la estrategia de generación de código presentada en el capítulo 7 a dichaespeci…cación, obteniendo los componentes software de cada uno de los nivelesde la arquitectura de la aplicación.

La estructura del apéndice consta de tres apartados, en primer lugar se describetextualmente (de manera informal) el ejemplo elegido, en segundo lugar se presentael proceso de modelado conceptual en el cual se aplica la estructura navegacional y ellenguaje de patrones especializado propuestos en la tesis, para obtener de forma siste-mática y guiada el esquema conceptual en formato UML. A continuación se obtiene,a partir del esquema conceptual, su correspondiente especi…cación OASIS. Por últi-mo, se aplica el Modelo de Ejecución Extendido a dicha especi…cación, generando loscomponentes software de cada nivel de la arquitectura propuesta, siguiendo el procesode generación de código presentado en el capítulo 7 de la tesis.

A.1 Descripción

El ejemplo que se presenta puede considerarse un subsistema de una aplicación en elcual aparecen los tipos de relaciones taxonómicas introducidos en esta tesis, y algunascombinaciones entre ellas (a distintos niveles). Este ejemplo pretende abarcar unagran cantidad de casos interesantes a los que da solución la tesis presentada. Ladescripción textual es la siguiente:

291

292 Apéndice A. Ejemplo de Aplicación

Se desea modelar un sistema informático para la gestión de la información de Per-sonas y en particular para mantener información relativa a su condición de Hombreo Mujer, de Estudiante de una carrera Universitaria, y de Empleado. Con el …n deacotar el número de tipos de empleos posibles que puede tener una persona, estos sereducirán a aquellas personas que puedan trabajar como Vendedores o Responsablesde Ventas.Para las Personas se desea mantener información sobre su dni, nombre, apellidos,

sexo, dirección, telefono, edad y las revisiones médicas (son obligatorias al menos dosuna a los 45 años y otra a los 65) que se ha realizado durante su existencia.Respecto a los Hombres es importante mantener información sobre el servicio obli-

gatorio1 (militar o social sustitutorio) que deben realizar, y su duración en meses Encuanto a las Mujeres se mantendrá información sobre su estado (normal/embarazada)y los hijos que ha dado a luz, además ésta deberá realizarse obligatoriamente una re-visión médica a los 35 años si todavía no ha tenido hijos.Una persona podrá estudiar y/o trabajar. Como Estudiante tendrá las propieda-

des de un estudiante y podrá matricularse hasta de 3 carreras a la vez en la mismaUniversidad, las carreras tendrán asignaturas y éstas se impartirán en un determi-nado curso. El estudiante no se podrá matricular de 20 o más asignaturas, podráexaminarse y …nalizar los estudios si ha aprobado todos los créditos necesarios paradar por …nalizada la carrera. Cuando …nalice los estudios dejará de ser estudiante.El estudiante se considerará matriculado en el curso de aquella/s asignatura/s quepertenezcan a un curso superior a las demás, si un estudiante al examinarse apruebala asignatura, los créditos de la asignatura se sumarán a aquellos créditos totales quetiene aprobados y dejará de estar matriculado de la asignatura.Si a una persona se le contrata ésta pasará a trabajar en un puesto de una sección

determinada, tendrá un sueldo base y podrá recibir boni…caciones, además se le con-trolarán las bajas mensuales. El empleado no podrá tener un sueldo base inferior a60000, el salario que percibirá cuando se le pague cada …n de mes será el sueldo basemás las boni…caciones que haya acumulado. Un empleado podrá ser despedido y en-tonces ya no será empleado. Se le podrá subir el sueldo en una determinada cantidiadcada vez que haya pasado un año o más tiempo desde su última revisión de sueldo.Un empleado podrá ser Vendedor o Responsable de Ventas. Inicialmente cuando se lecontrata será como Vendedor, pudiendo pasar a Responsable a través de una promo-ción y al contrario siendo rebajado el Responsable. El Vendedor tiene como objetivovender la mayor cantidad de productos de la empresa, por cada producto que venda sele boni…cará con 10 pesetas (la boni…cación no podrá exceder de 100000 pesetas cadasmes), cada principio de mes la boni…cación y las ventas realizadas se reiniciará a 0.Si un vendedor está de baja cinco o más veces en un mes entonces se le quitará la boni-…cación. Si se le sube el sueldo ese mes se le quitará la boni…cación y, por último, unempleado sólo podrá promocionar si el número de ventas realizadas es mayor que 300unidades. El Responsable tendrá a su cargo a un conjunto de Vendedores, la empresale podrá asignar o quitar vendedores a su cargo. La boni…cación de un responsableestará en función del número de vendedores que tenga a su cargo, por cada uno deellos cobrára 500 pesetas más al mes. La boni…cación que cobra no podrá exceder de200000 pesetas mensuales. Una restricción importante es que para ser Responsable

1Actualmente este servicio está en vías de desaparición en España, pero se considera por ser unadiferencia entre hombres y mujeres.

A.2. Modelado Conceptual 293

se deberá ser mayor de 24 años. A los responsables se les podrá rebajar sólo cuandoya no tengan ningún vendedor a su cargo, se les subirá el sueldo cuando cumplan lascondiciones de cualquier empleado pero además tengan como más de 100 vendedoresa su cargo, y se les quitará la boni…cación cuando cumplan las condiciones de losempleados y tengan como mínimo 20 vendedores a su cargo.

A.2 Modelado Conceptual

La primera etapa en el proceso de desarrollo propuesto consiste en obtener un esquemaconceptual que constituya un modelo del dominio de la aplicación. Para ello se aplicael algoritmo propuesto en el capítulo 6, haciendo uso de la estructura navegacionalbasada en preguntas y el lenguaje de patrones desarrollado.

A.2.1 Aplicación del Lenguaje de Patrones y la EstructuraNavegacional

El proceso de modelado se llevará a cabo de forma iterativa de la siguiente forma:

1. Para cada clase susceptible de ser especializada se aplicará el patrón DeterminarRelaciones Taxonómicas. En este caso el patrón se aplicará sobre la clase Personapor ser la más general de las que se puedan detectar en el enunciado del ejemplo.En la aplicación de este patrón:

(a) se obtendrá un conjunto de subclases que especialicen a la clase seleccio-nada. Para detectar la existencia de subclases en el modelo se preguntará¿Todos los objetos de la clase tienen el mismo carácter o se pueden divi-dir en algunas categorías?. En este caso se contesta que la clase se puededividir en varias subclases, por lo que a continuación se le pide al analis-ta que identi…que cada una de las subclases, en el ejemplo se detectan lassubclases siguientes: Hombre, Mujer, Estudiante y Empleado (ver FiguraA.1). Si se aplica de forma recursiva a cada subclase la pregunta anteriorse detectará que la subclase Empleado a su vez se puede categorizar enVendedor y Responsable (ver Figura A.2).

(b) para cada subclase detectada se comprobará que se cumplen los princi-pios de no redundancia y economía cognitiva (requisitos necesarios paraser consideradas subclases). La no redundancia se comprobará mediantela cuestión: ¿Introduce la subclase alguna propiedad adicional (atributo ocomportamiento nuevo) que no posea su superclase? y, la economía cogni-tiva mediante la cuestión ¿La subclase aporta más información sobre losobjetos pertenecientes a dicha subclase que la propia categorización en síproporciona?. En todos los casos del ejemplo se detecta que las subclasesposeen atributos y eventos nuevos (ver Figura A.3). El proceso detec-ción de propiedades se introduce con la aplicación del patrón DeterminarPropiedades de la Subclase.


Persona


Figura A.1: Detección de subclases de Persona

Empleado


Figura A.2: Detección de subclases de Persona

Personadnin ombreapell idosdi recciontelefonoedadsexo

cambiar_direccion()cambiar_telefono()incrementar_edad()revision_medica()crear()el iminar()matricular()contratar()

Mujerhi josestado


HombrefechaIni_ServiciofechaFin_ServicioServicioDuracionMeses


Estu diantecod_estudiantecreditosTotalesCarreracursonAsignaturasMatriculadasTotalCreditosAprobados

examinar()matricular_asignatura()terminar_estudios()matricular()

E mpleadocod_empleadoNombre_empresapuestosalariote lefonofecha_contratacionfecha_revi sio n_salariobonificacion

cambiar_empresa()cambi ar_puesto()i ncrementar_sal ario()subir_salario()pagar()despedir()con tratar()

VendedornVentas


ResponsablenClientesnVendedores

captar_cl ientes()perder_clientes()asignar_vendedores()quitar_vendedores()rebajar()

Figura A.3: Identi…cación de atributos y operaciones emergentes


Persona

Mujer Ho mbre Estudiante Empleado


Estáticas

Dinámicas

Figura A.4: Identi…cación de subclases estáticas y dinámicas

2. A cada subclase identi…cada en el paso anterior, se le aplica el patrón Deter-minar Características Temporales para conocer si la especialización es estática odinámica, esto permitirá a su vez conocer la categoría de los criterios de espe-cialización detectados, es decir, si son estáticos o dinámicos. Para detectar lascaracterísticas temporales de las subclases se realizará la pregunta ¿Los objetosde la subclase se mantienen en ésta durante toda su existencia o pueden crearsey destruirse con el paso del tiempo sin que dejen de existir en la superclase?. Enel ejemplo, las subclases Mujer y Hombre son estáticas (por lo que se utilizaráncriterios de especialización estáticos) y las demás dinámicas, ya que una Personapuede ser y dejar de ser Estudiante y Empleado durante su existencia sin dejarde ser Persona, y un Vendedor (Responsable) puede pasar a ser Responsable(Vendedor) sin dejar de ser Empleado (ver Figura A.4).

3. Aplicar el patrón Determinar Criterio de Especialización a la superclase y a sussubclases, identi…cando los distintos criterios de especialización (estáticos y di-námicos) por los que se especializa la superclase.

En las subclases estáticas se preguntará ¿Se debe cumplir alguna condición ba-sada en atributos constantes en la superclase, por la cuál ésta se especializa enla subclase?. En el caso de Hombre y Mujer existe una condición basada en elatributo constante sexo, por lo que una Persona será Hombre si sexo=”H”, y se-rá Mujer si sexo=”M” (ver Figura A.5). Los criterios seleccionados cumplen laspropiedades de no redundancia, claridad, precisión, simplicidad y uniformidad.

4. En las subclases dinámicas se aplicará en primer lugar el patrón DeterminarRestricciones Dinámicas, para conocer la naturaleza de la dinamicidad. Dichainformación se obitne realizando la siguiente pregunta: La creación de una ins-tancia de una subclase dinámica se lleva a cabo: ¿mediante migración desdeuna subclase o creándose a partir del objeto de la superclase?. En el ejemplose observa que en las subclases Estudiante y Empleado, sus instancias se crean


Persona

Mujer Hombre

sexo="M" sexo="H"

Figura A.5: Criterios de especialización estáticos

Estudiante Empleado

Ve ndedor Re spon sabl e

Roles

Din ámica s

Figura A.6: Identi…cación de Roles y Subclases Dinámicas

a partir del objeto de la superclase mediante un proceso de extensión verti-cal, sin embargo las subclases Vendedor y Responsable representan estados delEmpleado y su creación se lleva a cabo mediante un proceso migratorio en elque un objeto de la subclase (evoluciona horizontalmente) migra hacia la nuevasubclase (ver Figura A.6).

5. Una vez se ha determinado si existe evolución horizontal o extensión verticalse especi…cará el criterio de especialización dinámico asociado a cada tipo desubclase. En el caso de un evolución horizontal se preguntará por condicionessobre atributos variables o eventos de migración en la subclase origen de lamigración, y en el caso de extensión vertical se preguntará por los eventos deactivación en la superclase. Así pues:

(a) Para cada una de las subclases con evolución horizontal se preguntará:¿Se debe cumplir alguna condición (basada en atributos variables) o, debeocurrir algún evento para que se cree un objeto de la subclase?. Una vezdetectado el criterio, para cada subclase se preguntará al modelador porla subclase origen en la que se debe cumplir la condición de migración oproducir el evento, y por la condición o evento causante de dicha migra-ción. Si el origen de la migración es la superclase será porque se está en la


Vendedor

Responsable


rebajar

Figura A.7: Diagrama de Migración de la subclase Empleado

Persona

Estudiante Empleado


Figura A.8: Eventos de creación y destrucción de subclases

subclase inicial de la migración. En el caso del ejemplo la migración estábasada en eventos. Un Empleado cuando lo contratan pasa inicialmente aser Vendedor, éste después puede promocionar a la subclase Responsable, yel Responsable puede ser rebajado de nuevo a Vendedor. Esta informaciónsirve para determinar una dependencia entre las subclases (patrón De…nirDependencia Existencial) que se utilizará para construir de forma automáti-ca el diagrama de migración para la partición de Empleado (si al …nal seidenti…ca como partición dinámica, ver Figura A.7).

(b) Para cada una de las subclases con extensión vertical se le preguntará:¿Debe ocurrir algún evento en la superclase para que se cree un objeto dela subclase? y si ¿Debe ocurrir algún evento para que un objeto abandonela sublase?. En esta caso, las subclases Estudiante y Empleado extiendenverticalmente a la Persona, ya que cuando ésta se matricula de una carreraUniversitaria se especializa en Estudiante, y deja dicha subclase cuandotermina los estudios. Cuando lo contratan se especializa en Empleado y…naliza su trabajo cuando lo despiden (ver Figura A.8).

6. Se agruparán aquellas subclases que cumplan el mismo criterio o aquellas entrelas cuales se produzcan migraciones de objetos, con la intención de detectarparticiones o grupos de rol. La subclases Hombre yMujer constituyen un grupoporque se han especializado siguiendo el mismo criterio que es el sexo de la


Persona



Figura A.9: Identi…cación de Grupos de Subclases

Persona, Estudiante y Empleado se han especializado a partir de la ocurrenciade un evento, aunque se determina que pertenecen a dos categorías que no tienenrelación una con otra y no deben agruparse. Por último, Vendedor y Responsableson dos subclases de Empleado que se han especializado según el tipo de trabajoque realizan en la empresa, por lo que parece adecuado agruparlas (ver FiguraA.9).

7. El patrón Determinar Restricciones Estáticas se aplicará a los conjuntos de sub-clases detectados, con la intención de comprobar las propiedades estáticas decompletitud ( siempre existe algún objeto que cumple el criterio) y disyunción(el criterio sólo se cumple para una clase del grupo a la vez).

(a) Para conocer si la especialización es completa, a cada grupo de subclases sepreguntará si un objeto de la superclase, en un instante dado ¿siempre esinstancia de una subclase en el conjunto de subclases especializadas?. Si laespecialización es incompleta es debido a que el criterio de especializaciónelegido no posee las características deseadas o se tiene un grupo de rol. Sies incompleta y tiene todas las características de una partición, según elmodelo taxonómico se de…nirá obligatoriamente un subclase adicional quehará que la partición sea completa. En el ejemplo propuesto un objetode la clase Persona siempre será Mujer o Hombre, por lo que este grupode subclases es completo, en el caso de Estudiante y en el de Empleadono tiene porque pertenecer en cualquier instante a dichas subclases, por loque serán incompletas en ambos casos. La especialización de Empleado enVendedor y Responsable será completa.

(b) Para conocer si la especialización es disjunta, a cada grupo de subclases sepreguntará si un objeto de la superclase, en un instante dado ¿siempre esinstancia de una única subclase en el conjunto de subclases especializadas?.Si existe un solapamiento entre subclases, es porque se habrá de…nido un


Grupos Subclases IS CM HP V RE CT RD M DE I CE

Hom b re , M u j e r E S S í H ,M (C C ) ,N S p D ,C E N o 0 ,1 S p C D E

E s tu d ia n t e E S S í H ,M (C S ) ,N S p D , I D E xV 0 ,3 S p P DV

Em p le a d o E S S í H ,M (C S ) ,N S p D , I D E xV 0 ,N S p P DV

Ven d ed o r , R e s p o n sa b le E S S í H ,M (C C ) ,N S p D ,C D E vH 0 ,1 S p ,S b C DV

Tabla A.1: Características de las Relaciones Taxonómicas según el Marco Multidi-mensional propuesto

criterio de especialización incorrecto o, la partición o el grupo de rol enconsideración son en realidad dos grupos de rol o dos particiones, por loque el grupo tendrá que dividirse. En el ejemplo propuesto un objeto de laclase Persona no podrá ser a la vez Mujer y Hombre, por lo que este grupode subclases es disjunto, en el caso de Estudiante y en el de Empleado co-mo el grupo esta formado por una subclase también serán disjuntos amboscasos. Si anteriormente el modelador hubiera decidido que Estudiante yEmpleado constituían un único grupo, en este paso se detectaría que elcriterio de especialización era incorrecto o que en realidad eran dos gruposo particiones. La especialización de Empleado en Vendedor y Responsablees disjunta porque un responsable no puede ser vendedor a la vez y vice-versa.

8. El patrón Determinar Multiplicidad se aplicará a las subclases dinámicas. Sólolas subclases dinámicas con extensión horizontal podrán tener una multiplici-dad mayor que 1. La multiplicidad se determinará respondiendo a la siguientecuestión: ¿En cuántas instancias de una subclase puede especializarse un objetode la superclase?. En el ejemplo las subclases tendrán una multiplicidad [0,1]exceptuando la subclase Estudiante la cual podrá ser [0,3], ya que un estudiantepodrá estudiar como máximo 3 carreras universitarias a la vez, en la mismaUniversidad.

9. Se aplicará el patrón Determinar Relación de Identidad para de…nir cómo se vaa identi…car la subclase. La relación entre el mecanismo de identi…cación dela subclase respecto a la superclase se preguntará mediante la cuestión siguien-te: ¿La subclase utiliza el mecanismo de identi…cación de la superclase o poseeuno propio?. Las subclases Estudiante y Empleado tendrán independencia deidenti…cación respecto a Persona, utilizando un mecanismo de identi…cacióncompletamente nuevo, que dependerá de la Escuela o Facultad en la que estématriculado y de la Empresa en la que trabaje respectivamente. Las demássubclases tendrán dependencia de identi…cación.

Con la información recopilada en este cuestionario se tiene su…ciente informaciónpara situar las relaciones detectadas en el marco conceptual presentado. De estaforma se puede categorizar la relación taxonómica como partición estática, dinámicao rol (ver tabla A.1).Siguiendo la notación UML, en la …gura A.10 se puede ver el resultado …nal del

proceso de modelado.


Personadninombreapel lidosdireccionte lefonoedadsexore visio ne s

camb ia r_di reccion()cambiar_telefono()incrementar_edad()re visio n_ med ica()crear()el iminar()matricu la r()contratar()

Mujerhi josestado


HombrefechaIni_ServiciofechaFin_ServicioServicioDuracionMesesDestino

comenzar_Servicio()final izar_Servicio()sortear()

Estudiantecod_estudiantecreditosTotalesCarreracu rson Asi gnaturasMatricu la da sTo tal Cre dit osAproba do s

e xamina r()mat ricular_ asignatura ()terminar_estudios()matricular()

Empleadocod_empleadoseccionpuestosalariosueldo_basetelefonofecha_contratacionfecha_revision_sueldoboni ficacionbajas

cambiar_seccion()cambiar_puesto()boni ficar()subir_sueldo()pagar()despedir()contratar()iniciar_mes()faltar_al_trabajo()

VendedornVentas


Respon sab lenVendedores

asignar_vendedores()quitar_vendedores()rebajar()

<<sexo=M>> <<sexo = H>>

<<matricular() / terminar()>>

<<contratar() / despedir()>>

sexo

<<jugad o_ por>>

<<0,3>><<dinámi ca>>

<<jugad o_ por>>

Figura A.10: Diagrama de Clases Final


Persona0

crear eliminar


matricular if edad>=18contratar if edad>=16

Figura A.11: DTE de la clase Persona

11. A partir de esta información, para la especi…cación de las propiedades y elcomportamiento de las subclases, se aplicarán los patrones De…nir Propiedadesde la Subclase y Especi…car Comportamiento de la Subclase que es dependientedel tipo de la relación.

En este ejemplo, inicialmente se especi…ca la clase Persona en la que se detectala necesidad de almacenar la siguiente información (1) de tipo constante: dni,nombre, apellidos, sexo y (2) de tipo variable: direccion, telefono, edad, revisiones(número de revisiones médicas realizadas). Además, se incluirán: eventos decreación y destrucción de objetos: crear y eliminar respectivamente, los even-tos contratar y matricular, detectados anteriormente, como eventos activadoresde los roles Empleado y Estudiante respectivamente, y por último los eventosde modi…cación de los atributos variables cambiar_direccion, cambiar_telefono,cumplir_años y revision_medica.

El comportamiento se especi…ca mediante precondiciones, evaluaciones, dispa-ros y el ciclo de vida. En cuanto a la precondiciones: en el ejemplo existendos condiciones que deben cumplirse para ejecutar los eventos contratar y ma-tricular respectivamente. Una especi…cará que para contratar a una persona esnecesario que tenga 16 o más años, la otra especi…cará que para matricularse deuna carrera será necesario tener 18 o más años. El efecto de los eventos sobrelos atributos de la clase se especi…cará mediante las siguientes evaluaciones: elevento de creación dará valor a los atributos constantes y a los atributos direc-ción y edad, los eventos cambiar_direccion y cambiar_telefono proporcionaránuna nueva dirección y un nuevo teléfono a los atributos direccion y telefono. Loseventos cumplir_años y revision_medica incrementarán en 1 la edad y las revi-siones respectivamente. Los eventos contratar y matricular se encargan de crearlos roles y, no tienen (en este caso) ningún efecto sobre el estado de la Persona.Se ha detectado una condición que obliga a que una persona pase una revisiónmédica cuando tenga 45 y 65 años. Esta situación se especi…cará a través deun disparo donde se especi…cará, que a toda Persona se le disparará el eventorevision_medica cuando se cumplan dichas condiciones. El comportamiento deun objeto de la clase, visto como una secuencia de transiciones entre estados,se modelará a través del DTE de la Figura A.11, en la cual se observa que,una vez se crea una Persona pueden ocurrirle en cualquier orden, los eventosespeci…cados en su signatura.

² Para la subclase Hombre se aplicarán los patrones:


– De…nir Propiedades de la Subclase, detectándose la necesidad de especi…car:

¤ atributos nuevos: fechaIni_Servicio, Servicio (tipo de servicio [Mili-tar,PrestacionSocial]), DuracionMeses (número de meses que dura elservicio) y Destino como atributos variables; fechaFin_Servicio (serála fechaIni incrementada en los meses que dure el servicio DuracionMe-ses) como atributos derivados.

¤ eventos nuevos: sortear que ocurre cuando sortean al Hombre para re-alizar un Servicio en particular, de una duración determinada en meses(DuracionMeses), comenzar_Servicio que ocurre cuando el Hombre ini-cia el servicio, por último el evento …nalizar_Servicio que ocurre cuando…naliza éste.

– Especi…car Comportamiento de la Subclase, especi…cándose (según las pautasde…nidas en el capítulo 5):

¤ precondiciones de los eventos:¢ para poder comenzar el servicio (comenzar_Servicio), se debe cum-plir que el Hombre haya sido sorteado habiéndole asignado un des-tino (Destino <> ‘‘’’) y, que la fecha de inicio del servicio to-davía no esté asignada (fechaIni = ‘‘00/00/0000’’),

¢ para poder ser sorteado (sortear), no tiene que haber realizado elservicio (Servicio=’’NoRealizado’’).

Ambos casos son precondiciones nuevas, por lo que se cumplirá lacompatibilidad de comportamiento exigida.

¤ evaluaciones de los eventos:¢ sortear: da valor al Servicio a realizar y a DuracionMeses de dichoservicio.

¢ comenzar_Servicio: da valor a la fecha de inicio del servicio (fecha-Ini_Servicio).

¢ …nalizar_Servicio: establece que el servicio ha sido realizado (Ser-vicio=’’Realizado’’).

¤ disparos: si la fecha actual (hoy) es la misma que cuando debe …nalizarel servicio (fechaFin_Servicio ), entonces se debe disparar el evento…nalizar_Servicio.

¤ ciclos de vida: la subclase Hombre es estática por lo que se seguiránlas reglas de extensión y re…namiento del DTE de la clase Persona.En el caso de ocurra el evento sortear (si no ha realizado ya el servicio)seguirá comportándose como una Persona, aunque cuando ocurra elevento comenzar_Servicio (si ya ha sido sorteado y no está realizandoel servicio) pasará a un estado Hombre0 (ver …guras A.12 y A.13), en elcual podrá comenzar_Servicio y seguir comportándose como Persona.Cuando le ocurra finalizar_Servicio pasará al estado (Persona0) en elcual se sigue comportando como una Persona. Esta situación se puedemodelar, siguiendo las pautas propuestas en el capítulo 5, como sepuede ver en la …gura A.12. También se puede modelar de formaequivalente utilizando subestados de los que está compuesto el estado


Persona0crear eliminar

incrementar_edadcambiar_direccion

cambiar_telefono


matricular if edad>=18revision_medica

Hombre0

comenzar_servicio if (Destino<>"" and fechaIni="00/00/0000")

finalizar_servicio

eliminar

cambiar_telefono

revision_medicacontratar if edad>=16

matricular if edad>=18cambiar_direccion

incrementar_edad

sortear if Servicio="NoRealizado"

Figura A.12: DTE de la subclase Hombre

Persona0. En la …gura A.13 se presenta esta última aproximación, enla cual se interpreta que, estando en el estado Persona0, pueden ocurrirlos eventos del subdiagrama, y estando en el subdiagrama se está enel estado Persona0 por lo que pueden ocurrir los eventos que ocurrenen Persona0.

² Para la subclase Mujer se aplicarán los patrones:– De…nir Propiedades de la Subclase, detectando:

¤ atributos nuevos: hijos (número de hijos que tiene) y estado ([normal,embarazada]) que son variables.

¤ eventos nuevos: quedar_embarazada que ocurre cuando se con…rma suestado de buena esperanza y, dar_a_luz ocurre cuando la mujer de aluz.

– Especi…car Comportamiento de la Subclase, especi…cándose:

¤ precondiciones de los eventos:¢ para poder quedarse embarazada (quedar_embarazada), se debecumplir que no esté embarazada (estado=’’normal’’), y

¢ para dar a luz (dar_a_luz) debe estar embarazada (estado =‘‘embarazada’’).

Ambos casos son precondiciones nuevas por lo que se cumplirá la com-patibilidad de comportamiento exigida.

¤ evaluaciones de los eventos:


Persona0

Hombre0Hombre0

comenzar_servicio if (Destino<>"" and fechaIni="00/00/0000")

finalizar_servicio

crear eliminar

incrementar_edadcambiar_direccion

cambiar_telefono


matricular if edad>=18revision_medica

sortear if Servicio="NoRealizado"

Figura A.13: DTE de la subclase Hombre. Versión con estados anidados o compues-tos.

¢ quedar_embarazada: cambia el estado de la Mujer a “embarazada’’.¢ dar_a_luz: incrementa el número de hijos de laMujer en el númerode hijos que haya tenido en el parto, además cambia la Mujer alestado “normal’’.

¤ disparos: en esta subclase se debe rede…nir el disparo especi…cado en laclase Persona (según el patrón Especi…car Disparos) porque una mujerademás de las revisiones médicas de los 45 y 65 años deberá pasaruna revisión médica cuando tenga 35 y si no ha tenido hijos todavía.Con esta rede…nición se garantiza en la subclase la actividad de lasuperclase y se extiende la condición de disparo.

¤ ciclos de vida: el DTE será parecido al de Hombre. En este caso unaMujer seguirá comportándose como una Persona, aunque cuando ocu-rra el evento quedar_embarazada pasará a un estado Embarazada (ver…gura A.14). En dicho estado podrá dar_a_luz y seguir comportán-dose como Persona. Cuando le ocurra este evento pasará al estado(Persona0) en el cual se sigue comportando como una Persona. Es-ta situación se puede modelar, siguiendo las pautas propuestas en elcapítulo 5, como se ve en la …gura A.14.

² Para la subclase de rol Estudiante se aplicarán los patrones:

– De…nir Propiedades de la Subclase, detectando:

¤ atributos nuevos: cod_estudiante (código de estudiante propio de lacarrera universitaria) que es constante, TotalcreditosAprobados (crédi-tos que el estudiante ha aprobado hasta el momento) y curso (en elque está matriculado un alumno, se conoce a partir del curso de laasignatura cuyo curso es más elevado) que son variables y NumAsigna-turasMatriculadas (número de asignaturas de las que está matriculadoel estudiante) que será derivado. La clase Estudiante estará agregada


Persona0

Embarazada

crear eliminar

Embarazada

quedar_embarazada if estado="Normal"

dar_a_luz

cambiar_telefonocontratar if edad>=16cambiar_direccion

matricular if edad>=18revision_medicaincrementar_edad

Figura A.14: DTE de la subclase Mujer

con una clase Asignaturas, por lo que poseerá implícitamente un atri-buto objeto valuado llamado AsignaturasMatriculadas que almacenarálas asignaturas de las cuáles está matriculado.

¤ eventos nuevos: matricular_asignatura que ocurre cada vez que el es-tudiante se matricula de una determinada asignatura, examinar queocurre cuando un estudiante se examina de una asignatura determina-da y terminar_estudios que ocurre cuando se …nalizan completamentelos estudios.


¤ precondiciones de los eventos: para poder …nalizar los estudios (termi-nar_estudios) será necesario que el alumno haya cursado todos loscréditos de la carrera universitaria en la que está matriculado. (Carreraserá un atributo implícito (objeto valuado) que emerge por la relaciónde agregación existente entre la subclase Estudiante y una clase Ca-rrera).

¤ evaluaciones de los eventos:¢ matricular_asignatura: posee como argumentos una asignatura yel curso al que ésta pertence, añadiendo dicha asignatura a la co-lección de asignaturas de las que está matriculado y cambiando elvalor del curso si la asignatura es de un curso superior al actual.

¢ examinar: posee como argumentos la asignatura y la nota obtenidaen el examen. Si la nota es mayor o igual que 5 (ha aprobado), seincrementará el número de créditos aprobados en los créditos dela asignatura y se eliminará de la colección de asignaturas de lasque el estudiante está matriculado.

¢ matricular (heredado): es el activador del rol, y su evaluación enla subclase Estudiante especi…ca que cuando empieza a estudiar lohace por el primer curso.

¤ restricciones de integridad : es necesario especi…car que un estudianteno se puede matricular de más de 20 asignaturas.


Estudiante0matricular

Estudiante1

eliminar



examinar if NumAsignaturasMatriculadas>=1

terminar_estudios

eliminar

Figura A.15: DTE de la subclase Estudiante

¤ disparos: la …nalización de los estudios se puede automatizar activandoel evento terminar_estudios cuando el número TotalcreditosAprobadossea igual a los créditos totales de la carrera matriculada.

¤ ciclos de vida: Al ser un rol no se exigirá compatibilidad de compor-tamiento. Se creará un DTE que tendrá obligatoriamente como tran-sición inicial el evento matricular (activador del rol) y como transición…nal el evento terminar_estudios (que …naliza el rol). Se crearán esta-dos Estudiante0 y Estudiante1 para ordenar la ocurrencia de eventos dela siguiente manera: una vez se matricula un estudiante, éste podrámatricularse de asignaturas. Una vez matriculado de alguna asigna-tura podrá examinarse y seguir matriculándose hasta que …nalice losestudios o se elimine del sistema. Este comportamiento se presenta enel DTE de la …gura A.15. En esta …gura no se han incluido los eventosheredados de Persona para facilitar su comprensión del DTE.

² Para la subclase de rol Empleado se aplicarán los patrones:– De…nir Propiedades de la Subclase, detectando:

¤ atributos nuevos: cod_empleado (código de empleado propio de cadaempresa) que es constante, seccion (en la que trabaja), puesto (lugarque ocupa en una sección determinada) , salario, sueldo_base, telefono(en el trabajo), fecha_contratacion (la fecha en la que se creo como em-pleado), fecha_revision_sueldo, boni…cacion, y bajas (número de vecesque el empleado ha estado de baja en un mes) que son variables.

¤ eventos nuevos: pagar que ocurre cada vez que se la paga al emplea-do, subir_sueldo ocurre como mínimo cada año e incrementa el sueldobase en una cantidad determinada, cambiar_puesto cambia el puestode trabajo del empleado por uno nuevo, cambiar_seccion cambia alempleado a una nueva sección, boni…car da una boni…cación o incre-mento de salario, se utiliza para incentivar o recompensar al empleado,faltar_al_trabajo ocurre cada vez que el empleado no va a trabajar,iniciar_mes ocurre cada primero de mes, servirá, despedir este evento…naliza la etapa de la Persona como Empleado (desactivará el rol).



¤ precondiciones de los eventos:¢ para poder subirle el sueldo (subir_sueldo) a un empleado debenpasar 12 o más meses entre la fecha actual y la fecha de la últimarevisión del sueldo (según política de empresa),

¢ sólo podrá ocurrir el evento iniciar_mes el primer día del mes.¤ evaluaciones de los eventos:

¢ contratar: es el de activación del rol. Cuando ocurre, crea el roly proporciona un sueldo base para el Empleado, asignándole unpuesto en una determinada sección.

¢ pagar: da valor al atributo salario, siendo el salario la suma delsueldo base y la boni…cación (para simpli…car el ejemplo, no seaplican deducciones).

¢ cambiar_puesto y cambiar_seccion: cambian al empleado a unpuesto y una sección nueva.

¢ subir_sueldo: incrementa el sueldo base en una cantidad (que se lla-mará incremento), y a la vez actualiza el atributo fecha_revision_-sueldo a la fecha en la que ocurrió el evento.

¢ boni…car: incrementa el atributo boni…cacion en un valor determi-nado (incremento)

¢ faltar_al_trabajo: incrementa el número de bajas en una unidad.¢ iniciar_mes: inicializa el número de bajas a 0.¢ cumplir_años: es heredado de Persona. En esta subclase re…na sucomportamiento de la siguiente manera: cada vez que el empleadocumpla años se le dará una boni…cación de 5000 pesetas.

¤ restricciones de integridad : es necesario exigir que el sueldo base siem-pre sea mayor que 60000 pesetas (mínimo salarial).

¤ disparos: el evento pagar se activará de forma automática cuando es…n de mes, y el evento iniciar_mes cuando la fecha sea primero de mes.Por último, la empresa sigue la política de que a un empleado se lequita la boni…cación acumulada si ha tenido 5 bajas en un mes.

¤ ciclos de vida: Al ser un rol no se exigirá compatibilidad de com-portamiento. Se creará un DTE que tendrá obligatoriamente comotransición inicial el evento contratar (que activa el rol) y como transi-ción …nal el evento despedir (que …naliza el rol). Se creará como estadoEmpleado0, ordenando la secuencia de eventos de la siguiente manera:una vez se contrata a una persona, éste se convierte en empleado y po-drá cambiar_puesto, iniciar_mes, faltar_al_trabajo, cambiar_sección,cambiar_telefono, boni…car, pagar, subir_sueldo y todos los eventos he-redados de Persona. Este comportamiento se presenta en el DTE dela …gura A.16.

La partición dinámica de la clase Empleado tendrá asociado un diagramade migración (ver …gura A.7) obtenido durante la especi…cación de loscriterios de especialización dinámicos (paso 5).


Empleado0contratar

cambiar_telefono cambiar_seccioncambiar_puesto

cambiar_direcc ion

eliminar

despedir

pagar



inic iar_mes

faltar_al_trabajo

Figura A.16: DTE de la subclase de rol Empleado

² Para la subclase Vendedor se aplicarán los patrones:

– De…nir Propiedades de la Subclase, detectando:

¤ atributos nuevos: nVentas será el número de ventas que realiza el ven-dedor en un mes. nVentas es de tipo variable.

¤ eventos nuevos: vender que ocurre cada vez que el vendedor vende unnúmero determinado de productos, promocionar que ocurre cuando sedesea promover al vendedor a un puesto de responsable de ventas, esteevento es importante porque constituye la forma de migrar de la claseVendedor a Responsable.


¤ precondiciones de los eventos: para poder promocionar a un vendedor,necesariamente deberá haber vendido 300 productos.

¤ evaluaciones de los eventos:¢ vender: incrementa el número de ventas en la cantidad de produc-tos vendidos; a su vez incrementa la boni…cación en diez veces losproductos que haya vendido (se le boni…cará hasta que su boni…-cación alcance las 100000 pesetas).

¢ subir_sueldo (heredado): re…na su efecto en la subclase Vendedor,inicializando a 0 la boni…cación obtenida. Según la política em-presarial cuando se sube el sueldo de un vendedor éste no tienederecho a la boni…cación que tenía acumulada.

¢ iniciar_mes (heredado): re…na su efecto en la subclase Vendedor.Se decide que cada nuevo mes se inicializará a 0 la boni…caciónobtenida y el número de ventas. De esta forma el evento hereda-do iniciar_mes añade comportamiento en la subclase modi…candoatributos heredados.

¤ restricciones de integridad : es necesario exigir que la boni…cación deun vendedor no pueda ser mayor que 100000 pesetas.


Empleado0



cambiar_telefono cambiar_seccion

cambiar_puesto

cambiar_direccion

eliminar

despedir

cambiar_telefono

promocionar

venderiniciar_mes

faltar_al_trabajo

pagar

contratar

Figura A.17: DTE de la subclase dinámica Vendedor

¤ ciclos de vida: Se exigirá la compatibilidad de comportamiento res-pecto a Empleado. En este caso, un Vendedor seguirá comportándosecomo un Empleado y aceptará los eventos propios de Vendedor (vendery promocionar). Cuando ocurra el evento promocionar …nalizará su exis-tencia como Vendedor y migrará a la subclase Responsable (ver …guraA.7). Esta situación se puede modelar, como se puede ver en la …guraA.17.

² Para la subclase Responsable se aplicará:– De…nir Propiedades de la Subclase, detectando:

¤ atributos nuevos nVendedores que será el número de vendedor de loscuales es reponsable.

¤ eventos nuevos: asignar_vendedores que ocurre cada vez que se le asig-nan nuevos vendedores a cargo del responsable, quitar_vendedores queocurre cada vez que se le quitan vendedores al responsable, rebajarocurre cuando se desea rebajar al responsable a vendedor, este eventoconstituye la forma de migrar de la clase Responsable a Vendedor.


¤ precondiciones de los eventos:¢ la precondición del evento subir_sueldo heredada de Empleado, serede…ne haciéndola más restrictiva. La rede…nición exige, ademásde la condición herededa, que el responsable tenga más de 100empleados a su cargo,

¢ se especi…ca una precondición nueva asociada al evento rebajar.Esta precondición exigirá que para rebajar a un Responsable, ésteno deberá tener vendedores a su cargo.

¤ evaluaciones de los eventos:


¢ asignar_vendedores: incrementa el número de vendedores que sele asignan al responsable, en un número determinado. Ademáspor cada vendedor nuevo asignado se le boni…ca con 500 pesetas,siempre teniendo en cuenta que cuando la boni…cación total excedade 200000 pesetas no se le contabilizará en la boni…cación.

¢ quitar_vendedores: tiene el efecto contrario al evento asignar_ven-dedores. Decrementa el número de vendedores a cargo del respon-sable y se le quitan 500 pesetas de boni…cación por cada vendedorque ya no esté a su cargo. Se tiene en cuenta que la boni…caciónno puede ser nunca menor que 0.

¤ restricciones de integridad : la boni…cación de un responsable se de-be limitar a 200000 pesetas. Otra restricción importante es que unresponsable para poseer dicho cargo tiene que ser mayor de 24 años.

¤ disparos: en esta subclase se rede…ne el disparo que quita la boni…-cación de un empleado. Se exigirá para quitar la boni…cación que,además de faltar 5 veces al trabajo, el responsable tenga 20 o menosvendedores a su cargo. Esta rede…nición mantiene la compatibilidadde comportamiento.

¤ ciclos de vida: Se exigirá la compatibilidad de comportamiento res-pecto a Empleado En este caso un Responsable seguirá comportándo-se como un Empleado y aceptará los eventos propios de Responsable(asignar_vendedores, quitar_vendedores y rebajar), cuando ocurra elevento rebajar …nalizará su existencia como Responsable y migrará ala subclase Vendedor (ver …gura A.7). La subclase Responsable ex-tiende el DTE heredado añadiendo un nuevo estado Responsable1 paraordenar la ocurrencia de los eventos nuevos (asignar_vendedores, qui-tar_vendedores) de la siguiente manera: se modelará que cuando se leasignan vendedores a su cargo a un responsable, es cuando verdadera-mente empieza a ejercer de responsable, por ello se crea una transiciónal estado Responsable1. En este estado le pueden asignar y quitar ven-dedores, si le quitan todos los vendedores a su cargo, el responsablesigue siéndolo pero en realidad deja de ejercer porque no tiene a nadiea su cargo, en este estado le pueden asignar vendedores o lo puedenrebajar a Empleado (y en dicho momento …naliza su existencia comoResponsable). Esta situación se puede modelar como se puede ver enla …gura A.18.

A.2.2 Especi…cación OASISA partir de la información de modelado introducida en el proceso de construccióndel esquema conceptual, presentado en el apartado anterio, se obtendrá, siguiendo elproceso de traducción presentado en [174], la siguiente especi…cación OASIS.

Las subclases a su vez tendrán sus relaciones de agregación con clases comoCarreraUniversitaria, Asignatura (en el caso de Estudiante) y Empresa en elcaso de Empleado.


Empleado0

Responsable1


subir_sueldo

bonificar

promocionar

cambiar_telefono


cambiar_direccion

faltar_al_trabajo

iniciar_mespagar

Responsable1


asignar_vendedores

quitar_vendedores(n) if nVendedores=n

eliminar

despedir

rebajar

Figura A.18: DTE de la subclase dinámica Responsable

Conceptual schema Ejemplo

class Personaidentification

dni: (dni)constant attributes

dni: stringnombre: string;apellidos: string;sexo: string;

variable attributesdireccion: string;telefono: string;edad: nat;revisiones: nat;

eventscrear new;eliminar destroy;cambiar_direccion(NuevaDireccion:string);cambiar_telefono(NuevoTelefono:string);cumplir_años;revision_medica;contratar(s_base:nat; Vpuesto,Vseccion:string);matricular(Estudios:string);

preconditionscontratar if (edad >= 16)matricular if (edad >= 18)


valuations[cambiar_direccion(Ndireccion)] direccion:=Ndireccion;[cambiar_telefono(Ntelefono)] telefono:=Ntelefono;[cumplir_años] edad:= edad + 1;[revision_medica] revisiones:= revisiones + 1;

triggersself::revision_medica when {edad=45 or edad=65};

processPersona = crear.Persona0;Persona0 = (cambiar_direccion(ndir) + cambiar_telefono(ntel) +incrementar_edad + revision_medica + contratar + matricular ).Persona0+ eliminar;

end class

class Hombrevariable attributes

fechaIni_Servicio: date;Servicio: string;DuracionMeses: nat;Destino: String;

derived attributesfechaFin_Servicio: date;

derivationsfechaFin_Servicio:= inc(fechaIni_Servicio, DuracionMeses);//la función inc devuelve la fecha que se pasa como primer argumento//incrementada en el número de meses que se pasa como segundo argumento

eventssortear(Serv:string, Duracion:nat, Dest:String);comenzar_Servicio(fechaI:date);finalizar_Servicio;

preconditionssortear if Servicio=’’NoRealizado’’;comenzar_servicio if (Destino<>’’’’ and fechaIni_Servicio=’’00/00/0000’’;

valuations[crear] Servicio=’’NoRealizado’’;[sortear(Serv, Duracion, Dest)] Servicio:=Serv and DuracionMeses:=Duracion

and Destino:=Dest;[comenzar_Servicio(fechaI)] fechaIni_Servicio := fechaI;[finalizar_Servicio] Servicio:=’’Realizado’’;

triggersself::finalizar_Servicio when {fechaFin_Servicio=hoy)};

processHombre = crear.Persona0;Persona0 = (cambiar_direccion(ndir) + cambiar_telefono(ntel) +incrementar_edad + revision_medica + contratar + matricular +sortear).Persona0 + comenzar_servicio.(Persona0 + Hombre0) + eliminar;Hombre0 = finalizar_Servicio.Persona0;

end class

class Mujer


variable attributeshijos: nat;estado:string;

eventsquedar_embarazada;dar_a_luz(num_hijos:nat);

preconditionsdar_a_luz if (estado=’’embarazada’’);quedar_embarazada if (estado=’’normal’’);

valuations[quedar_embarazada] estado := ‘‘embarazada’’;[dar_a_luz(num_hijos)] hijos:=hijos+num_hijos;[dar_a_luz(num_hijos)] estado:=’’normal’’;

processMujer = crear.(Persona0 + quedar_embarazada.(Embarazada + Persona0));Embarazada = dar_a_luz;

triggersself::revision_medica() when {edad=45 or edad=65 or

(edad = 35 and hijos=0)};end class

class Estudianteidentification

cod_estudiante: (cod_estudiante);constant attributes

cod_estudiante: string;variable attributes

TotalcreditosAprobados: nat;curso: string;

derived attributesNumAsignaturasMatriculadas: nat;

derivationsNumAsignaturasMatriculadas:= count(AsignaturasMatriculadas)//la clase Estudiante está agregada con la clase Asignatura a través//de la relación AsignaturasMatriculadas

constraints{NumAsignaturasMatriculadas < 20};

eventsmatricular_asignatura(C:string, A:string);examinar(Asig:Asignatura,Nota:real);terminar_estudios destroy;

preconditionsexaminar if NumAsignaturas>=1;terminar_estudios if TotalcreditosAprobados=Carrera.creditosTotales;

valuations[matricular]curso:=’1’;[matricular_asignatura(C,A)] AsignaturasMatriculadas.anyadir(A);curso<C [matricular_asignatura(C,A)] curso:=C;Nota>=5 [examinar(Asig,Nota)]TotalcreditosAprobados:=TotalcreditosAprobados + Asig.Creditos;Nota>=5 [examinar(Asig,Nota)] AsignaturasMatriculadas.eliminar(Asig);


processEstudiante = matricular.Estudiante0;Estudiante0 = (cambiar_direccion + cambiar_telefono +incrementar_edad + revision_medica + contratar + matricular ).Estudiante0+ matricular_asignatura.Estudiante1 + eliminar;Estudiante1 = (matricular_asignatura + examinar).Estudiante1+ (cambiar_direccion + cambiar_telefono + incrementar_edad +revision_medica + contratar + matricular ).Estudiante1+ terminar_estudios + eliminar;

triggersself::terminar_estudios when

{TotalcreditosAprobados=Carrera.creditosTotales};end class

class Empleadoidentification

cod_empleado: (cod_empleado);constant attributes

cod_empleado: string;variable attributes

seccion: string;puesto: string;salario: nat;sueldo_base: nat;telefono: string;fecha_contratacion:date(hoy);fecha_revision_sueldo:date;bonificacion: nat;bajas:nat;

constraints{sueldo_base > 60.000}; //mínimo salarial{bonificacion <=100000};{edad >= 18};

eventspagar;subir_sueldo(Incremento:nat);cambiar_puesto(NuevoPuesto:string);cambiar_seccion(NuevaSeccion:string);bonificar(Incremento:nat);faltar_al_trabajo;iniciar_mes;despedir destroy;

preconditionssubir_sueldo(N) if ((hoy - fecha_revision_sueldo) >= 12);iniciar_mes if primero_de_mes(hoy);

valuations[contratar(s_base,Vpuesto,Vseccion)] sueldo_base:=s_baseand puesto:=Vpuesto and seccion:=Vseccion;[pagar] salario:= sueldo_base + bonificacion;[cambiar_seccion(NuevaSeccion)] seccion = NuevaSeccion;[cambiar_puesto(NuevoPuesto)] puesto = NuevoPuesto;


[subir_sueldo(Incremento)] sueldo_base = sueldo_base + Incremento;[subir_sueldo(Incremento)] fecha_revision_sueldo = hoy;[bonificar(Incremento)] bonificacion = bonificacion + Incremento;[iniciar_mes] bajas:=0;[faltar_al_trabajo] bajas:=bajas+1;[cumplir_años] bonificacion:=bonificacion+5000;

processEmpleado = contratar.Empleado0;Empleado0 = (cambiar_direccion + cambiar_telefono +incrementar_edad + revision_medica + matricular+ cambiar_seccion + cambiar_puesto + pagar + subir_sueldo+ bonificar + iniciar_mes + faltar_al_trabajo).Empleado0+ despedir + eliminar;

triggersself::pagar when {fin_de_mes(hoy)};self::bonificar(-bonificacion) when {bajas=5};self::iniciar_mes when {primero_de_mes(hoy)};// cuando empieza el mes se ponen a 0 las bajas y la boni…cacion

end class

class Vendedorvariable attributes

nVentas: nat;events

vender(n_productos);promocionar;

preconditionspromocionar if nVentas >300;

valuations[vender(n_productos)] nVentas = nVentas + n_productos;bonificacion <100000 and bonificacion + n_productos*10<=100000[vender(n_productos)] bonificacion = bonificacion + n_productos*10;bonificacion <100000 and bonificacion + n_productos*10>100000[vender(n_productos)] bonificacion = 100000;[iniciar_mes] bonificacion:=0 and nVentas:=0;[subir_sueldo(Incremento)] bonificacion:=0;

processVendedor = contratar.Empleado0;Empleado0 = (cambiar_direccion + cambiar_telefono +incrementar_edad + revision_medica + matricular+ cambiar_seccion + cambiar_puesto + pagar + subir_sueldo+ bonificar + iniciar_mes + faltar_al_trabajo + vender).Empleado0+ despedir + eliminar + promocionar;

end class

class Responsablevariable attributes

nVendedores: nat;events

asignar_vendedores(Num_Vendedores:nat);quitar_vendedores(Num_Vendedores:nat);


rebajar;preconditions

subir_sueldo(N) if ((hoy - fecha_ultima_revision >= 12) andnVendedores>100);

quitar_vendedores(N) if nVendedores>=N;rebajar if nVendedores=0;

constraints{edad > 24};{bonificacion <=200000};

valuations[asignar_vendedores(Num_Vendedores)]

nVendedores:= nVendedores + Num_Vendedores;bonificacion <200000 and bonificacion + Num_Vendedores*500 <=200000[asignar_vendedores(Num_Vendedores)]

bonificacion:= bonificacion + Num_Vendedores*500;bonificacion <200000 and bonificacion + Num_Vendedores*500 >200000[asignar_vendedores(Num_Vendedores)]

bonificacion:= 200000;[quitar_vendedores(Num_Vendedores)]

nVendedores:= nVendedores - Num_Vendedores;[quitar_vendedores(Num_Vendedores)]

bonificacion:= bonificacion - Num_Vendedores*500;process

Responsable = promocionar.Empleado0;Empleado0 = (cambiar_direccion + cambiar_telefono +incrementar_edad + revision_medica + matricular+ cambiar_seccion + cambiar_puesto + pagar + subir_sueldo+ bonificar + iniciar_mes + faltar_al_trabajo+ asignar_vendedores(n). Responsable1).Empleado0+ rebajar + despedir + eliminar;Responsable1 = asignar_vendedores(n) + quitar_vendedores(n) + Empleado0+ {nVendedores=n}quitar_vendedores(n). Empleado0;

triggersself::bonificar(-bonificacion) when {bajas=5 and nVendedores<=20}

end class

// especi…cación de las relaciones taxonómicasHombre, Mujer

static specialization of Persona;

Vendedor, Responsabledynamic specialization of Persona;migration relation is

Empleado = contratar.VendedorVendedor = promocionar.ResponsibleResponsable = rebajar.Vendedor;

Empleado towards(0,1) contratar, despedir role of Persona;

Estudiante towards(0,3) matricular, terminar role of Persona;

A.3. Generación de Código 317

end conceptual schema

A.3 Generación de Código

En este apartado se presenta, de forma detallada, el resultado de la generación decódigo del sistema de ejemplo, especi…cado en este apéndice, para cada uno de losniveles de la arquitectura propuesta.

A.3.1 Nivel de Aplicación

En el nivel de aplicación se presenta la generación de código para aquellas clases delejemplo en cuya implementación se introducen la mayoría de las técnicas presentadasen esta tesis. Esto se lleva a cabo para entender cómo se aplica sistemáticamente lasolución propuesta cuando en el esquema conceptual existe clasi…cación múltiple yjerarquías de múltiples niveles. Las clases del esquema conceptual que han sido se-leccionadas para desarrollar su representación software en Java son: la clase Personaporque tiene de…nida una partición estática (Hombre y Mujer) y dos grupos de roles(Estudiante y Empleado), la subclase Mujer por ser una subclase estática, la subcla-se Empleado por tener de…nida una partición dinámica (Vendedor y Responsable)siendo a la vez un rol, y la subclase Responsable por ser una subclase dinámica delrol Empleado perteneciendo a una jerarquía de dos niveles. De cada una de estasclases se presenta su estructura y la implementación de algunos de los métodos queilustran mejor la propuesta.

Clase Persona

public class Persona {

//Atributos de la claseString dni; //Identi…cador de la clase PersonaString nombre;

String apellidos;

String direccion;

String telefono;

int edad;

String sexo;

int revisiones; // node revisiones médicas realizadasPart_HombreMujer obj_estado_sexo = null; // partición estática (Nombre/Mujer)Vector roles_Estudiante = new Vector(1); // grupo de rol EstudianteVector roles_Empleado = new Vector(3); // grupo de rol EmpleadoString estadoDTE = new String(‘‘E_INICIAL’’); //Estado del objeto en el DTEBasedatos bd = new Basedatos(); //objeto de acceso a los datos (“mediador”)

//contructor “básico” de la clase Personapublic Persona() { }


//Servicios que ofrece la clase Persona:

//Constructor de la clase Persona especi…cado en el Esquema Conceptual//Implementa la estrategia de ejecuciónpublic void crear(String p_dni, String p_nombre, String p_apellidos,String p_direccion, String p_telefono, int p_edad, String p_sexo,Hashtable argumentos) throws Exception{

try{

comprobar_transicion_estado(‘‘crear’’);//no hay precondición especi…cadaeval_crear(p_dni, p_nombre, p_apellidos, p_direccion, p_telefono,p_edad, p_sexo);comprobar_RI();bd.crear(this); //se crea la instancia de Persona en la BD.//después de aplicar la estrategia de ejecución (a falta de los disparos)//se llama al método especializar para que//especialice al objeto en una de las subclasesespecializar_por_atributo_constante(argumentos);comprobar_disparos();//al …nal del proceso se comprueban los posibles disparos

} catch (Exception e){throw new Exception();}}

//Método encargado de especializar las instancias en una subclase según el valor del//atributo sexo.public void especializar_por_atributo_constante(Hashtable Argumentos)throws Exception{

if (sexo.equals(‘‘Mujer’’)){

obj_estado_sexo = new Mujer(this);obj_estado_sexo.crear(Argumentos);

}else

{if (sexo.equals(‘‘Hombre’’)){

obj_estado_sexo = new Hombre(this);obj_estado_sexo.crear(Argumentos);

} else throw new Exception(‘‘Error, no se puede especializarel objeto’’);2

}}

//Destructor de la clase Persona,//al tener de…nidos dos grupos de roles y una partición estática//destruye sus roles activos y delega en el objeto estado//para que el objeto activo de la partición se autodestruya

2Porque el valor del atributo no es correcto o porque en la creación del objeto estado se haproducido un error.


public void eliminar() throws Exception{

try{

comprobar_transicion_estado(‘‘destruir’’);//no hay precondición especi…cada//no hay evaluación especi…cada para el destructordestruir_roles(); //destruye sus roles activosobj_estado_sexo.destruir(); //destruye el objeto estado (Hombre o Mujer)//no se comprueban restricciones de integridad porque el estado no ha cambiadocomprobar_disparos();bd.eliminar(this)

}catch(Exception e){throw new Exception();}}

// método oculto que destruye los roles activosprotected void destruir_roles() throws Exception{

for (int i=0;i<roles_Empleado.size();i++){

try{

//Destruir el rol(Empleado)roles_Empleado.elementAt(i).despedir();//Eliminar el rol de la colección de Empleadosroles_Empleado.removeElementAt(i);

}catch(Exception e){throw new Exception();}}for (int i=0;i<roles_Estudiante.size();i++){

try{

//Destruir el rol(Estudiante)roles_Estudiante.elementAt(i).terminar_estudios();//Eliminar el rol de la colección de Estudiantesroles_Estudiante.removeElementAt(i);


}

//Implementación de Eventos propios de la clase Persona

public void cambiar_direccion(String nDireccion)throws Exception{

try{

comprobar_transicion_estado(‘‘cambiar_direccion’’);eval_cambiar_direccion(nDireccion);comprobar_RI();bd.actualizar(this);comprobar_disparos();

}catch (Exception e){throw new Exception();}}


public void incrementar_edad() throws Exception{

try{

comprobar_transicion_estado(‘‘incrementar_edad’’);eval_incrementar_edad();comprobar_RI();bd.actualizar(this);comprobar_disparos();


// ......más eventos de la clase Persona

//Eventos (matricular/contratar) que ofrece la clase Persona para activar los roles// (Estudiante/Empleado) que puede desempeñar una Persona

public void matricular(String p_carrera, int p_creditos) throws Exception{

try{

// no se necesita comprobar la restricción de disyunción// porque los grupos de roles sólo son de una clasecomprobar_cardinalidades(‘‘matricular’’);comprobar_transicion_estado(‘‘matricular’’);comprobar_precondicion_matricular();//no se ha especi…cado evaluacióncomprobar_RI();comprobar_disparos();//creación del rol EstudianteEstudiante rol = new Estudiante();//estrategia de ejecución del evento matricular en el rol creadorol.r_matricular(this, p_carrera, p_creditos);//añade el rol a la colección de roles de Estudianteroles_Estudiante.addElement(rol);


public void contratar(int s_base)throws Exception{

try{

// no se necesita comprobar la restricción de disyunción// porque los grupos de roles sólo son de una clasecomprobar_cardinalidades(‘‘contratar’’);comprobar_transicion_estado(‘‘contratar’’);comprobar_precondicion_contratar();//no se ha especi…cado evaluacióncomprobar_RI();comprobar_disparos();Empleado rol = new Empleado();rol.r_contratar(this, p_Sbase);roles_Empleado.addElement(rol);



//Método que comprueba que se puede crear el rol.

public void comprobar_cardinalidades(String evento)throws ViolacionCardinalidad{//Puede ser estudiante y empleado a la vez//Se permite tener una instancia de Estudiante y hasta tres de Empleado

if ((evento==‘‘contratar’’) && (roles_Empleado.size() >= 3))throw new ViolacionCardinalidad();

if ((evento==‘‘matricular’’) && (roles_Estudiante.size() == 1))throw new ViolacionCardinalidad();

}}

//Aquí estaría el método comprobar_disyunción del grupo de rol// si cada grupo de rol tuviese más de una subclase

//Implementación mediante delegación el objeto estado//de los eventos propios de las subclases Hombre y Mujer

public void quedar_embarazada() throws Exception{

try{

obj_estado_sexo.quedar_embarazada();}catch(Exception e){throw new Exception();}

}

public void dar_a_luz(int num_hijos)throws Exception{

try{

obj_estado_sexo.dar_a_luz(num_hijos);}catch(Exception e){throw new Exception();}

}

public void sortear(String servicio, int duracion_meses)throws Exception{

try{

obj_estado_sexo.sortear(servicio,duracion_meses);}catch(Exception e){throw new Exception();}

}

// ......más eventos de la subclase Hombre

//Métodos que implementan los pasos de la estrategia de ejecución

public void comprobar_transicion_estado(String evento)throws EventoNoPermitido{//Si el objeto estado no se ha creado todavía y el evento que ocurre es el construtor se

acepta la transición


if (obj_estado_sexo == null){ if (evento.equals(‘‘crear’’)) return;}

else{

try{//Si el objeto estado ya está creado la comprobación se realiza mediante delegación

obj_estado_sexo.comprobar_transicion_estado(evento);}catch(Exception e) throw new EventoNoPermitido();

}}

}

public void comprobar_precondicion_contratar() throws ViolacionPrecondicion{

if !(edad >= 16) throw new ViolacionPrecondicion();}

public void comprobar_precondicion_matricular() throws ViolacionPrecondicion{

if !(edad >= 18) throw new ViolacionPrecondicion();}

public void eval_crear(String p_dni, String p_nombre, String p_apellidos,String p_direccion, String p_telefono, int p_edad, String p_sexo)

{dni = p_dni;nombre = p_nombre;apellidos = p_apellidos;direccion = p_direccion;telefono = p_telefono;edad = p_edad;sexo = p_sexo;

}

public void eval_cambiar_direccion(String nueva_direccion){

direccion = nueva_direccion;}

public void eval_cambiar_telefono(String nuevo_telefono){

telefono = nuevo_telefono;}

public void eval_incrementar_edad(){

edad = edad + 1;}

public void eval_revision_medica(){

revisiones = revisiones + 1;}

public void comprobar_restricciones_integridad()


throws ViolacionRestriccion{//No hay restricciones de integridad de…nidas para Persona y sus subclases de la partición//Mujer/Hombre}

public void comprobar_disparos() throws ErrorDisparos{

if (((edad==45) jj (edad==65)) & (!disparado)){

disparado = true;revision_medica();

}if (obj_estado_sexo!=null){

if ((obj_estado_sexo.es_clase().equals(‘‘Mujer’’)) & (!disparado)){

disparado = true;obj_estado_sexo.comprobar_disparos();

}}

}//Método que elimina un rol de la lista de roles

public void eliminar_rol(RoleObject rol){if (rol.es_clase().equals(‘‘Estudiante’’)) roles_Estudiante.removeElementAt(0);

else{

for (int i=0;i<roles_Empleado.size();i++){

Empleado emp = (Empleado)roles_Empleado.elementAt(i);Empleado rolemp = (Empleado)rol;if (emp.cod_empleado == rolemp.cod_empleado)

roles_Empleado.removeElementAt(i);}

}}

//Métodos de consulta de valores de atributos.public int obtener_edad(){

return edad;}......}.........

//Part_HombreMujerpublic abstract class Part_HombreMujer {

String estadoDTE = new String(‘‘E_INICIAL’’);//Estado del objeto en el DTE


Persona pers;public Part_HombreMujer() { }

......// otros métodos

Subclase Mujer

public class Mujer extends Part_HombreMujer{int hijos;String estado;boolean disparado = false;Basedatos bs = new Basedatos();public Mujer() { }//Servicios que ofrece la clase Mujer://Constructor (no especi…cado) de la clase Mujer. Se llama cuando en el constructor//de la clase Persona se lleva a cabo la especialización//(método especializar_por_atributo_constante)public void crear(Hastable argumentos) throws Exception{

try{

comprobar_transicion_estado(‘‘crear’’);eval_crear((int) (argumentos.get(‘‘p_hijos’’)).intValue(),

(String)(argumentos.get(‘‘p_estado’’)));comprobar_restricciones_integridad();bs.crear(this);comprobar_disparos();

} catch (Exception e){throw new Exception();

}}//Destructor de la clase Mujer, se llama desde la clase Persona cuando se destruye//un objeto (método destruir)public void destruir()throws Exception{

try{

comprobar_transicion_estado(‘‘destruir’’);bs.eliminar(this);comprobar_disparos();

}catch(Exception e){ throw new Exception();}}

public void quedar_embarazada()throws Exception{

try{

comprobar_transicion_estado(‘‘quedar_embarazada’’);comprobar_precondicion_quedar_embarazada();eval_quedar_embarazada();comprobar_restricciones_integridad();bd.actualizar(this);


comprobar_disparos();} catch (Exception e){throw new Exception();}

}

public void dar_a_luz(int num_hijos) throws Exception{

try{

comprobar_transicion_estado(‘‘dar_a_luz’’);comprobar_precondicion_dar_a_luz();eval_dar_a_luz(num_hijos);comprobar_restricciones_integridad();bd.actualizar(this);comprobar_disparos();

} catch (Exception e){throw new Exception();}}

//Método de consulta que utiliza la clase Persona para obtener el nombre de//la subclase en la que se especializa un objeto Personapublic String es_clase(){

return new String(‘‘Mujer’’);}

//Métodos que implementan la estrategia de ejecuciónpublic void comprobar_transicion_estado(String evento) throws EventoNoPermitido{

if (estadoDTE.equals(‘‘E_INICIAL’’)){

if (evento==‘‘crear’’) estadoDTE=‘‘Persona0’’;else throw new EventoNoPermitido();

}else if (estadoDTE.equals(‘‘Persona0’’)){

if ((evento==‘‘cambiar_direccion’’)jj(evento==‘‘cambiar_telefono’’) jj(evento == ‘‘incrementar_edad’’) jj (evento == ‘‘revision_medica’’)jj(evento == ‘‘matricular’’) jj (evento == ‘‘contratar’’))estadoDTE = estadoDTE;else

if (evento == ‘‘quedar_embarazada’’) estadoDTE = ‘‘Embarazada’’;else

if (evento == ‘‘destruir’’) estadoDTE = ‘‘E_DESTRUIDO’’;else throw new EventoNoPermitido();

}else if (estadoDTE.equals(‘‘Embarazada’’)){

if ((evento == ‘‘cambiar_direccion’’)jj (evento==‘‘cambiar_telefono’’)jj

(evento == ‘‘incrementar_edad’’) jj (evento == ‘‘revision_medica’’) jj(evento == ‘‘matricular’’)jj(evento == ‘‘contratar’’))estadoDTE = estadoDTE;else

if ( evento == ‘‘dar_a_luz’’) estadoDTE = ‘‘Persona0’’;


elseif (evento == ‘‘destruir’’) estadoDTE = ‘‘E_DESTRUIDO’’;

else throw new EventoNoPermitido();}

}

public void comprobar_precondicion_quedar_embarazada()throws ViolacionPrecondicion{

if (!(estado.equals(‘‘normal’’))) throw new ViolacionPrecondicion();}

public void comprobar_precondicion_dar_a_luz() throws ViolacionPrecondicion{

if (!(estado.equals(‘‘embarazada‘‘))) throw new ViolacionPrecondicion();}

public void eval_crear(int p_hijos, String p_estado){

hijos = p_hijos;estado = p_estado;

}

public void eval_quedar_embarazada(){

estado = ’’embarazada‘‘;}

public void eval_dar_a_luz(int num_hijos){

hijos = hijos + num_hijos;estado = ’’normal‘‘ ;

}

public void comprobar_restricciones_integridad() throws ViolacionRestriccion{

if (pers.obtener_edad() < 20) throw new ViolacionRestriccion();}


if ((pers.obtener_edad() == 35) & (hijos == 0) & (!disparado)){

disparado = true;pers.revision_medica();

}}// Clase RoleObjectpublic abstract class RoleObject {

Persona Jugador; //El jugadorString estadoDTE = new String(’’E_INICIAL‘‘);public RoleObject() {}

// .......otros métodos


Clase Empleado

public class Empleado extends RoleObject{int cod_empleado; //identi…cador de la clase EmpleadoString telefono;String puesto;long salario;String seccion;int sueldo_base;Date fecha_contratacion;Date fecha_revision_sueldo;int bonificacion;int bajas;Part_tipoEmpleado obj_estado_tipoEmpleado;Basedatos bd = new Basedatos();//contructor ”básico“ de la clase Empleadopublic Empleado() {}

//Eventos nuevos en la subclase de rol Empleadopublic void cambiar_seccion(String NuevaSeccion) throws Exception{

try{

comprobar_transicion_estado(’’cambiar_seccion‘‘);//no hay precondición especi…cadaeval_cambiar_seccion(NuevaSeccion);comprobar_restricciones_integridad();bd.actualizar(this);comprobar_disparos();


public void cambiar_puesto(String NuevoPuesto) throws Exception{

try{comprobar_transicion_estado(’’cambiar_puesto‘‘);//no hay precondición especi…cadaeval_cambiar_puesto(NuevoPuesto);comprobar_restricciones_integridad();bd.actualizar(this);comprobar_disparos();}catch (Exception e){throw new Exception();}

}

public void subir_sueldo(long incremento)throws Exception{

try{comprobar_transicion_estado(’’subir_sueldo‘‘);comprobar_precondicion_subir_sueldo();eval_subir_sueldo(incremento);comprobar_restricciones_integridad();bd.actualizar(this);comprobar_disparos();



public void pagar()throws Exception{

try{comprobar_transicion_estado(’’pagar‘‘);//no hay precondición especi…cadaeval_pagar();comprobar_restricciones_integridad();bd.actualizar(this);comprobar_disparos();}catch (Exception e){throw new Exception();}

}

public void bonificar(long Cantidad)throws Exception{

try{comprobar_transicion_estado(’’bonificar‘‘);//no hay precondición especi…cadaeval_bonificar(Cantidad);comprobar_restricciones_integridad();bd.actualizar(this);comprobar_disparos();}catch (Exception e){throw new Exception();}

}

public void iniciar_mes()throws Exception{

try{comprobar_transicion_estado(’’iniciar_mes‘‘);comprobar_precondicion_iniciar_mes();eval_iniciar_mes();comprobar_restricciones_integridad();bd.actualizar(this);comprobar_disparos();}catch (Exception e){throw new Exception();}

}

// ......más eventos de la clase Empleado

//Evento de destruccion del rol Empleadopublic void despedir() throws Exception{

try{comprobar_transicion_estado(’’despedir‘‘);//no hay precondición especi…cada//no hay evaluación especi…cadabd.eliminar(this);comprobar_disparos();//después de llevar a cabo la estrategia de ejecución//se destruyen los objetos estado (si tiene una partición asociada)obj_estado_tipoEmpleado.destruir();//se le pide al jugador que elimine el rol de la colección (al ser un rol de Persona)


Jugador.eliminar_rol(this);}catch (Exception e){throw new Exception();}

}

//Eventos de Migración. Surgen por la partición dinámica (Vendedor/Responsable)//de la clase Empleado: promocionar –> Responsable, rebajar –> Vendedor.public void promocionar(int nVendedores) throws EventoNOPermitido{

if (obj_estado_tipoEmpleado.nombre_clase.equals(’’Vendedor‘‘){

// si el objeto activo es un Vendedorobj_estado_tipoEmpleado.promocionar(nVendedores);// delega la ejecución del evento promocionar// en el objeto de la subclaseargumentos = new Hashtable(); // se inicializa la hashtableespecializar_por_evento(’’promocionar‘‘,

argumentos.put(’’nVendedores‘‘, new int(nVendedores));// método especializador

}else throw new EventoNOPermitido();// el evento promocionar pertenece a la subclase Vendedor

}

public void rebajar() throws EventoNOPermitido{

if (obj_estado_tipoEmpleado.nombre_clase.equals(’’Responsable‘‘)){

// si el objeto activo es un Responsableobj_estado_tipoEmpleado.rebajar();// delega la ejecución del evento rebajar// en el objeto de la subclaseargumentos = new Hashtable(); // se inicializa la hashtableespecializar_por_evento(’’rebajar‘‘,argumentos);// método especializador

}else throw new EventoNOPermitido();// el evento rebajar pertenece a la subclase Responsable

}

//Eventos que hereda de la clase Persona. Delegará su ejecución en el jugador//Constructor heredado de la clase Persona. Delega su ejecución en el jugador para//que sea Persona quién cree un objeto de dicha clase.public void crear(String p_dni, String p_nombre, String p_apellidos,String p_direccion, String p_telefono, int p_edad, String p_sexo,int p_hijos, String p_estmujer, Date p_fechaIni, Date p_fechaFin,String p_servicio, int p_duracion) throws Exception{

try{

Jugador.crear(p_dni, p_nombre, p_apellidos, p_direccion, p_telefono,

p_edad, p_sexo, p_hijos, p_estmujer,p_fechaIni, p_fechaFin, p_servicio,p_duracion);



//Destructor de la clase Persona. Delega para que la clase Persona//destruya el objeto de su clase.public void destruir() throws Exception{

try{

Jugador.destruir();}catch(Exception e){throw new Exception();}

}

public void cambiar_direccion(String nDireccion)throws Exception{

try{

Jugador.cambiar_direccion(nDireccion);}catch (Exception e){throw new Exception();}

}

// ......más eventos de la clase Persona

public void contratar(int p_sbase)throws Exception{

try{

Jugador.contratar(p_sbase);}catch(Exception e){

throw new Exception();}}

public void matricular(String carrera, int creditos) throws Exception{

try{

Jugador.matricular(carrera, creditos);}catch(Exception e){


// métodos de consulta (mediante delegación) de atributos heredados de la clase Persona

public int obtener_edad(){

return Jugador.obtener_edad();}public String obtener_dni(){

return Jugador.obtener_dni();}......

//Eventos de las subclases dinámicas Vendedor y Responsable. Se implementan//mediante delegación sobre el objeto estado


public void vender(int nproductos) throws Exception{

try{

obj_estado_tipoEmpleado.vender(nproductos);}catch(Exception e){throw new Exception();}

}

public void anyadir_vendedores(int Num_Vendedores) throws Exception{

try{

obj_estado_tipoEmpleado.anyadir_vendedores(Num_Vendedores);}catch(Exception e){throw new Exception();}

}

public void eliminar_vendedores(int Num_Vendedores) throws Exception{

try{

obj_estado_tipoEmpleado.eliminar_vendedores(Num_Vendedores);}catch(Exception e){throw new Exception();}

}

//Métodos ocultosprotected void r_contratar(Persona p_pers, int p_Sbase) throws Exception{

try{

comprobar_transicion_estado(’’contratar‘‘);//no hay precondición especi…cadaeval_r_contratar(p_pers, p_Sbase);comprobar_restricciones_integridad();bd.crear(this);especializar_por_evento(’’contratar‘‘,0)comprobar_disparos();

}catch(Exception e){throw new Exception();

}}

private void especializar_por_evento(String Evento, Hastable Argumentos){

if (obj_estado_tipoEmpleado==null){

// no hay ningún objeto activo porque// se está en el proceso de creación de un Empleadoif (Evento.equals(’’contratar‘‘)){

obj_estado_tipoEmpleado= new Vendedor(this);// crea un Vendedor y lo asigna al objeto estadoobj_estado_tipoEmpleado.contratar((int)

(Argumentos.get(’’s_base‘‘)).intValue());


// se inicializan los atributos de Vendedor si es necesario// ejecutando el método constructorreturn;

}}if (obj_estado_tipoEmpleado.nombre_clase().equals(‘‘Vendedor’’){

if (Evento.equals(‘‘promocionar’’)){

// si ocurre el evento promocionarobj_estado_tipoEmpleado.free();// se destruye el objeto activoobj_estado_tipoEmpleado= new Responsable(this);// crea un objeto de la subclase Responsableobj_estado_tipoEmpleado.promocionar((int)(Argumentos.get(‘‘nVendedores’’)).intValue());

// se inicializan los atributos de Responsable si es necesario// ejecutando el método constructor

return;}return;

}if (obj_estado_tipoEmpleado.nombre_clase().equals(‘‘Responsable’’){

if (Evento.equals(‘‘rebajar’’)){

// si ocurre el evento rebajarobj_estado_tipoEmpleado.free();// se destruye el objeto activoobj_estado_tipoEmpleado = new Vendedor(this);// crea un objeto de la subclase Vendedorobj_estado_tipoEmpleado.rebajar();// se ejecuta el constructor y inicializan los atributos de Vendedor si es nece-

sarioreturn;

}return;

}}

//Método clasi…cadorpublic String es_clase(){

return ‘‘Empleado’’;}

//Métodos que implementan los pasos de la estrategia de ejecución

public void comprobar_transicion_estado(String evento) throws EventoNoPermitido{//Si el objeto estado no se ha creado todavía y el evento que ocurre es el construtor se

acepta la transiciónif (obj_estado_tipoEmpleado == null)


{ if (evento.equals(‘‘contratar’’)) return;}else{

try{//Si el objeto estado ya está creado la comprobación se realiza mediante delegación

obj_estado_tipoEmpleado.comprobar_transicion_estado(evento);}catch(Exception e)

{throw new EventoNoPermitido();

}}

}

public void comprobar_precondicion_subir_sueldo() throws ViolacionPrecondicion{

if (obj_estado_tipoEmpleado.nombre_clase().equals(‘‘Responsable’’))// el objeto está especializado en la subclase Responsable{

obj_estado_tipoEmpleado.comprobar_precondicion_subir_sueldo();// ejecutar el método de la subclase porque el evento subir_sueldo// ha rede…nido la precondición en la subclase Responsablebreak;

}else if !((DiferenciaFechas(new Date(),fecha_ultima_revision) >= 12)

throw new ViolacionPrecondicion();}

public void comprobar_precondicion_contratar() throws ViolacionPrecondicion{

Jugador.comprobar_precondicion_contratar();//delega en el objeto jugardor (de la clase Persona)

}

public void comprobar_precondicion_iniciar_mes() throws ViolacionPrecondicion{

if !(primero_de_mes(new Date())throw new ViolacionPrecondicion();}

public void eval_cambiar_puesto(String NuevoPuesto){

puesto = NuevoPuesto;}

public void eval_cambiar_seccion(String NuevaSeccion){

seccion = NuevaSeccion;}

public void eval_pagar(){

salario = sueldo_base + bonificacion;}

public void eval_bonificar(long Cantidad){


bonificacion = bonificacion + Cantidad;}

public void eval_subir_sueldo(long incremento){

sueldo_base = sueldo_base + incremento;fecha_revision_sueldo = new Date();if (obj_estado_tipoEmpleado.es_clase().equals(‘‘Vendedor’’))

obj_estado_tipoEmpleado.eval_subir_sueldo(incremento);}

public void eval_cambiar_telefono(String NuevoTelefono){

telefono = String NuevoTelefono;}

public void eval_faltar_al_trabajo(){

bajas = bajas + 1;}

public void eval_iniciar_mes(){

bajas = 0;if (obj_estado_tipoEmpleado.es_clase()==‘‘Vendedor’’)

obj_estado_tipoEmpleado.eval_iniciar_mes();}

// Métodos heredados de la clase Persona, implementados mediante delegación hacia eljugador

public void eval_cambiar_direccion(String nueva_direccion){

Jugador.eval_cambiar_direccion(nueva_direccion);}

public void eval_incrementar_edad(){

Jugador.eval_incrementar_edad();}

public void eval_revision_medica(){

Jugador.eval_revision_medica();}

public void eval_r_contratar(Persona p_pers, int p_sbase){

Jugador = p_pers; // se asigna el jugador// se inicializan los atributoscod_empleado = obtener_siguiente_codigo_empleado();// obtiene el siguiente código de empleado como identi…cadorsueldo_base = p_sbase;

}

public void comprobar_restricciones_integridad() throws ViolacionRestriccion


{if (!(sueldo_base >= 60000)throw new ViolacionRestriccion();// se comprueba la restricción común a Vendedor y Responsableif (obj_estado_tipoEmpleado.es_clase().equals(‘‘Responsable’’)

obj_estado_tipoEmpleado.comprobar_restricciones_integridad();// el objeto está especializado en Responsable por lo que// se comprueban la restricciones rede…nidas en Responsableelse if (!(bonificacion<=100000) jj !(jugador.obtener_edad()>=18))

throw new ViolacionRestriccion();// el objeto está especializado en Vendedor por lo que// se comprueban la restricciones de…nidas en Empleado

}


Date hoy = new Date();if (fin_de_mes(new Date())) pagar();if (bajas==5) bonificar(-10000);if (primero_de_mes(new Date())) iniciar_mes();try{

Jugador.comprobar_disparos();}catch(Exception e){throw new ErrorDisparos();}

}

// se supone implementadas las siguientes funciones de bibliotecaprivate boolean fin_de_mes(Date fecha){

....}private boolean primero_de_mes(Date fecha){

....}private int DiferenciaFechas(Date Primerafecha, SegundaFecha){

....}....

// Partición tipo Empleadopublic abstract class Part_tipoEmpleado {

public Part_tipoEmpleado() { }String estadoDTE = new String(‘‘E_INICIAL’’);Empleado emp;.............

Clase Responsable

public class Responsable extends Part_tipoEmpleado{int nVendedores;boolean disparado = false;


String estadoDTE = new String(‘‘E_INICIAL’’);Basedatos bd = new Basedatos();

//contructor “básico” de la clase Responsablepublic void Responsable(){}

//Servicios que ofrece la clase Responsable//Constructor de la clase Responsable, se llama cuando en la clase//Empleado se lleva a cabo la especialización mediante la activación del evento promocionar

public void promocionar(int nVendedores)throws Exception{

try{comprobar_transicion_estado(‘‘promocionar’’);// no existe precondición especi…cada en Responsable (sí en Vendedor)eval_promocionar(nVendedores);comprobar_restricciones_integridad();bd.crear(this);comprobar_disparos();


}}

//Destructor heredado de la clase Empleado//se ejecuta la estrategia de ejecución y a continuación//se llama al evento de la clase Empleado (despedir) mediante delegaciónpublic void despedir() throws Exception{

try{comprobar_transicion_estado(‘‘despedir’’);// no existe precondición especi…cada en Responsable// no existe evaluación especi…cada en Responsablecomprobar_restricciones_integridad();bd.eliminar(this);comprobar_disparos();// se llama a despedir mediante delegación sobre Empleadoemp.despedir();


}}

public void asignar_vendedores(int Cantidad)throws Exception{

try{comprobar_transicion_estado(‘‘asignar_vendedores’’);// no existe precondición especi…cada en Responsableeval_asignar_vendedores(Cantidad);comprobar_restricciones_integridad();bd.actualizar(this);comprobar_disparos();} catch (Exception e){throw new Exception();


}}

public void quitar_vendedores(int Cantidad)throws Exception{

try {comprobar_transicion_estado(‘‘quitar_vendedores’’);eval_quitar_vendedores(Cantidad);comprobar_restricciones_integridad();bd.actualizar(this);comprobar_disparos();} catch (Exception e){


//Evento portador de la clase Vendedor, actúa como destructor de Responsablepublic void rebajar()throws Exception{

try{

comprobar_transicion_estado(‘‘rebajar’’);// no existe evaluación asociadacomprobar_restricciones_integridad();bd.eliminar(this);comprobar_disparos();


}}

//Método clasi…cadorpublic String es_clase(){

return ‘‘Responsable’’;}

//Método de consultapublic int obtener_vendedores(){

return nVendedores;}//Algunos métodos que implementan los pasos de la estrategia de ejecuciónpublic void comprobar_precondicion_subir_sueldo() throws ViolacionPrecondicion{

if (!((DiferenciaFechas(new Date(),fecha_ultima_revision) >= 12) &&(nVendedores>100))

throw new ViolacionPrecondicion();// comprueba la precondición del evento subir_sueldo

}

public void comprobar_precondicion_rebajar() throws ViolacionPrecondicion{

if (nVendedores != 0) throw new ViolacionPrecondicion();


// comprueba la precondición del evento rebajar}

public void comprobar_restricciones_integridad() throws ViolacionRestriccion{

if !(emp.obtener_edad() > 24)throw new ViolacionRestriccion(‘‘La edad de unResponsable ha de ser mayor de 24 años’’);

if !(emp.bonificacion > 200000)throw new ViolacionRestriccion(‘‘La bonificación deun Responsable no puede ser mayor que 200000’’);

}

public void eval_asignar_vendedores(int Cantidad){

nVendedores = nVendedores + Cantidad;if ((emp.bonificacion + (Cantidad*500)) < 200000)

emp.bonificacion = emp.bonificacion + Cantidad*500;else emp.bonificacion = 200000;

}

public void eval_quitar_vendedores(int Cantidad){

nVendedores = nVendedores - Cantidad;emp.bonificacion = emp.bonificacion - Cantidad*500;

}

public void eval_promocionar(int vendedores){

nVendedores = vendedores;}


if (emp.bajas==5 && nVendedores<=20){try{

emp.bonificar(-emp.bonificacion);}catch(Exception e){throw new ErrorDisparos();}}

}

A.3.2 Nivel de Presentación

En el nivel de presentación se introduce una solución a la implementación de la interfazgrá…ca de usuario. En este apartado se presenta la solución adoptada para diseñar eimplementar: (1) la Ventana Principal y el Menú de la Aplicación, (2) la activaciónde eventos, (3) la creación de objetos, (4) la observación de la población de una clasey (5) la destrucción de objetos.


Ventana Principal y Menú de la Aplicación

La Ventana Principal de la aplicación posee un menú del que cuelgan las clases ysubclases en menús en cascada. El menú de aplicación generada tendrá los siguienteselementos visuales:

² Un menú “Proyecto” donde se encuentran las opciones “Accesos” y “Salir”² Un menú “Persona” donde se encuentra para dicha clase (ver …gura A.19):

– Una entrada de observaciones– Una entrada por cada evento perteneciente a una clase.– Un submenú para sus subclases estáticas Hombre y Mujer incluyendo cadauno las opciones de observaciones y eventos.

² Un menú “Estudiante” donde se encuentra para dicho rol (ver …gura A.20):– Una entrada de observaciones– Una entrada por cada evento perteneciente a una clase.

² Un menú “Empleado” donde se encuentra para dicho rol (ver …gura A.21):– Una entrada de observaciones– Una entrada por cada evento perteneciente a una clase.– Un submenú para sus subclases dinámicas Vendedor y Responsable inclu-yendo cada uno las opciones de observaciones y eventos.

Es importante destacar que las subclases de rol Estudiante y Empleado poseen supropia opción de menú en vez de incluirse como submenús del menú “Persona”. Estoes debido a que el usuario trabaja mayoritariamente con Estudiantes y Empleados.

Activación de Eventos

La activación de un evento desde el menú invoca a su correspondiente formulario depetición de argumentos donde se indican cada uno de los argumentos necesarios parala correcta invocación del evento. Como muestra de la implementación se presentanalgunos ejemplos de formularios de petición de argumentos. En la …gura A.22 se pue-de ver el formulario de petición de argumentos del evento asignar_vendedores dela clase Responsable. En esta …gura se observa la visualización de dos argumentosimplícitos (el código del empleado y el nombre completo de éste). El usuario selec-cionará el objeto sobre el cuál desea activar el evento. Como argumento explícito seintroduce el número de vendedores que se le asignan al responsable.Otro formulario del mismo tipo es el de la …gura A.23 correspondiente a la peti-

ción de argumentos del evento examinar de la clase Estudiante, en el cuál se pide(argumentos explícitos) el nombre de la asignatura de la cual se examina y la notaobtenida en el examen.Los formularios de las …guras A.24 y A.25 introducen información complementaria3

sobre el estado del objeto, que sirve para facilitar la comprensión de la funcionalidad3Patrón de Interfaz introducido en [147].


Figura A.19: Menú ”Persona” de la Ventana Principal

Figura A.20: Menú ”Estudiante” de la Ventana Principal


Figura A.21: Menú ”Empleado” de la Ventana Principal

Figura A.22: Petición de Argumentos para el Evento asignar_vendedores


Figura A.23: Petición de Argumentos para el Evento examinar

Figura A.24: Petición de Argumentos para el Evento subir_sueldo

del evento y evitar problemas de usabilidad. En el primer caso el evento subir_sueldoincrementa en una cantidad determinada el sueldo del Empleado, para evitar erroresde comprensión se visualiza el valor actual del sueldo, en la siguiente …gura el eventocambiar_telefono cambiar el número de teléfono de una Persona por un valor nuevo,para evitar problemas se presenta el número de teléfono actual.

Creación de Objetos

En las situaciones en las que se crean objetos, es necesario introducir los valores queinicializan los atributos del objeto, y en el caso de producirse una especialización,se deben introducir los nuevos atributos pertenecientes a la clase especializada encuestión.En la …gura A.26 se muestra el formulario que se visualiza cuando se activa el

evento crear de la clase Persona. Como se puede observar en la …gura, se visualizanelementos grá…cos (cajas de edición, botones de radio) necesarios para que el usuario


Figura A.25: Petición de Argumentos para el Evento examinar

introduzca el valor de los atributos del objeto que se va a crear. En la …gura se puedeobservar que existen dos elementos (botones de radio) que sirve para introducir lacondición de especialización (de la partición estática Hombre y Mujer). Si se seleccionaHombre, se inhabilita el campo de edición número de hijos y se activa el marco DatosServicio y sus controles visuales, para que se introduzca la información nueva de lasubclase Hombre. Si se selecciona Mujer se pedirá el número de hijos que tiene y seinhabilitará el marco Datos Servicio.En la …gura A.26 se muestra el formulario que se visualiza cuando se activa el

evento promocionar sobre un objeto de la subclase de rol Empleado. Este evento esportador de la partición dinámica por lo que su efecto será migrar el objeto Vendedora la clase Responsable, es por ello que pide el número de vendedores para poderinicializar los valores de los atributos nuevos de Vendedor.

Observaciones

En cuanto a las observaciones que se pueden realizar sobre la población de una claseo subclases, cuando se active dicha opción de menú se visualizará en una rejilla todoslos objetos de la clase en cuestión y para cada uno todas sus propiedades (en esteejemplo sólo atributos). Como ejemplo se puede ver en la …gura A.28 la observaciónde la población de la clase Persona.

Destrucción de Objetos

La destrucción de los objetos se llevará a cabo de la misma forma que la activación decualquier evento en el cual se seleccionará el objeto a destruir mediante un formulariodel mismo tipo al de petición de argumentos de un evento. También se puede eliminarun objeto seleccionándolo de entre la población de la clase como se puede apreciar enla …gura A.29.

A.3.3 Nivel de Persistencia

En el ejemplo utilizado durante el desarrollo de la tesis se ha especi…cado (ver …gura7.19) una partición estática (de Persona en Hombre y Mujer), dos grupos de rol (de


Figura A.26: Ventana de petición de argumentos en la creación de una Persona

Figura A.27: Venta de petición de argumentos para el evento promocionar de Vende-dor


Figura A.28: Venta de observaciones de la clase Persona

Figura A.29: Destrucción de objetos de la clase Persona


Persona

CP dni

nombreapellidossexodirecciontelefonoedadrevisionesSubclaseParticionSubclaseRolEmpleadoSubclaseRolEstudiante

Estudiante

CP cod_estudiante

totalCreditosAprobadoscursonumAsignaturasMatriculadas

CE1 dni

Empleado

CP cod_empleado

seccionpuestosalariosueldo_basetelefonofecha_contratacionfecha_revision_sueldobonificacionbajas

CE1 dniSubclaseParticion

Hombre

CP,CE1 dni

fechaIni_ServiciofechaFin_ServicioservicioduracionMesesDestino

Mujer

CP,CE1 dni

hijosestado

Vendedor

CP,CE1 cod_empleado

nVentas

Responsable

CP,CE1 cod_empleado

nVendedoresCE1, U1

Figura A.30: Diseño Relacional del Ejemplo

Persona en Estudiante y Empleado), y una partición dinámica (de Empleado enVendedor y Responsable). Si se aplican las correspondencias presentadas, se creará:

1. Una tabla para la clase Persona con sus atributos propios y los atributosSubclaseParticion (para almacenar el nombre de la subclase activa de la par-tición Hombre-Mujer), SubclaseRolEmpleado y SubclaseRolEstudiante (paraalmacenar el nombre de los roles activos de Empleado y Estudiante).

2. Una tabla para cada una las subclases estáticas Mujer y Hombre con sus atributosnuevos.

3. Una tabla para cada una de las subclases de rol Estudiante y Empleado. Es-ta última incluirá un atributo adicional llamado SubclaseParticion para al-macenar el nombre de la subclase activa de la partición dinámica Vendedor-Responsable.

4. Una tabla para las subclases Vendedor y Responsable.

El diseño resultante se puede ver en la …gura A.30. Donde la sigla CP signi…caclave primaria, la sigla CE signi…ca clave ajena y la sigla U signi…ca clave única quecon el atributo not null representa una clave alternativa.Siguiendo las pautas de…nidas por la propuesta del capítulo 7, este diseño permite

generar el siguiente esquema relacional utilizando sentencias SQL:create table PERSONA (

dni char(10) not null,nombre char(30) not null,apellidos char(40) not null,


sexo char(1) not null,direccion char(50),telefono char(15),edad smallinteger,revisiones smallinteger,SubclaseParticion CHAR(10) not null

check (SubclaseParticion in (’Hombre’,’Mujer’)),SubclaseRolEmpleado CHAR(10) null,SubclaseRolEstudiante CHAR(10) null,Primary key (dni));

create table HOMBRE (fechaIni_Servicio date,fechaFin_Servicio date,servicio char(30),duracionMeses smallinteger,Destino char(30),dni char(10) not null,Primary key (dni),Foreign Key (dni) references PERSONA

On delete cascadeOn update restrict);

create table MUJER (hijos smallinteger DEFAULT 0,estado char(10) DEFAULT ‘‘normal’’,Primary key (dni),Foreign Key (dni) references PERSONA


create table ESTUDIANTE (cod_estudiante CHAR(10) not null,totalCreditosAprobados smallinteger,curso smallinteger,numAsignaturasMatriculadas smallinteger,Primary key (cod_estudiante),Foreign Key (dni) references PERSONA


create table EMPLEADO (cod_empleado char(10) not null,seccion char(30) not null,puesto char(30) not null,salario integer not null,sueldo_base integer not null,telefono char(15),fecha_contratacion date,fecha_revision_sueldo date,bonificacion integer,bajas smallinteger,dni char(10) unique,


SubclaseParticion char(15) not null,check (SubclaseParticion in (’Vendedor’,’Responsable’))

Primary key (cod_empleado),Foreign Key (dni) references PERSONA


create table VENDEDOR (nVentas smallinteger,cod_empleado char(10) not null,Primary key (cod_empleado),Foreign Key (cod_empleado) references EMPLEADO


create table RESPONSABLE (nVendedores smallinteger,cod_empleado char(10) not null,Primary key (cod_empleado),Foreign Key (cod_empleado) references EMPLEADO


Apéndice B

Un Entorno de Generación deCódigo

En este apéndice se describe un prototipo de herramienta CASE que da soporte a lageneración automática de código en entornos de desarrollo industriales (en este casoBorland Delphi). La herramienta genera código exclusivamente para las relacionestaxonómicas especi…cadas en un esquema conceptual OO-Method almacenado en unrepositorio relacional. El prototipo que se presenta, ha sido utilizado para adquirirexperiencia en la construcción de generadores de código.La estructura del apéndice es la siguiente: en el primer apartado se describe la

herramienta desarrollada, se presenta su arquitectura y los aspectos más relevantesde la interfaz de usuario del prototipo. En el segundo y último apartado se presentaun ejemplo de prototipo generado, explicando la arquitectura de la aplicación (tresniveles) y cómo se han obtenido automáticamente cada uno de sus niveles.

B.1 La Herramienta de Generación

En este apartado se presenta una herramienta de generación de código para rela-ciones taxonómicas. Esta herramienta se ha implementado utilizando el entorno dedesarrollo visual Borland Delphi. La herramienta permite obtener automáticamenteun prototipo en Borland Delphi, que es funcionalmente equivalente a un subconjun-to de un esquema conceptual construido usando OO-Method. El subconjunto delesquema lo constituyen los tipos de relaciones taxonómicas introducidos en esta tesis.

B.1.1 Arquitectura

La herramienta desarrollada es capaz de leer la información de modelado almace-nada en un repositorio relacional. Este repositorio permite almacenar los esquemasconceptuales construidos con la herramienta OO-Method/CASE. La herramienta, apartir de la información leída y siguiendo las pautas propuestas en la tesis, generauna aplicación multinivel totalmente operativa. Los elementos que la constituyen son(ver …gura B.1):

349

350 Apéndice B. Un Entorno de Generación de Código

1. Un repositorio relacional 1. Constituye una extensión conservativa del reposi-torio relacional que utiliza la herramienta OO-Method/CASE.

2. Un módulo lector del repositorio. Permite obtener la información almacenadaen el repositorio.

3. Un analizador léxico y sintáctico. Que permite analizar las fórmulas (precon-diciones, restricciones de integridad, disparos, condiciones de especialización)presentes en la especi…cación OASIS.

4. Un generador de código. En este módulo, a partir de la información obtenidadel repositorio y su posterior análisis, se aplican las correspondencias de…nidasen la tesis, generándose la implementación correspondiente. Para obtener laimplementación se generan archivos con extensiones: *.PAS (son archivos en loscuales se implementan las clases del nivel de aplicación y persistencia), *.DPR(es el archivo de proyecto, uno por aplicación), *.TXT (estos archivos contienenla información referente a cada uno de los formularios que componen la interfazgrá…ca de usuario de la aplicación), y *.SQL (archivos con scripts SQL paragenerar el esquema relacional de la base de datos). Antes de compilar, los archi-vos *.TXT que representan a los formularios se convertirán al formato binariogenerando los archivos con extensión *.DFM (como se puede ver en la …guraB.1). Los archivos *.DPR, *.PAS, y *.DFM se compilan para crear el ejecutable.

El Repositorio de OO-Method y su Extensión

El repositorio relacional de la herramienta desarrollada es una extensión del reposito-rio que utiliza OO-Method/CASE actualmente (construido a partir del metamodelode OO-Method desarrollado en [178]).Los tipos de relaciones taxonómicas presentados requieren almacenar más infor-

mación que la existente en el repositorio actual ( que representa el modelo taxonómicode OASIS 2). La extensión que se ha realizado da soporte a los conceptos de Par-tición (Completa e Incompleta), Rol, Grupos de Rol y a las cardinalidades asociadasa los roles. Esta extensión se llevará a cabo extendiendo el metamodelo existente sinmodi…car (eliminando o renombrando) ningún elemento existente (clase, atributo uoperación). De esta manera se podrá reutilizar el trabajo y los esquemas conceptualesalmacenados por la herramienta OO-Method/CASE.En la …gura B.2 se puede ver el metamodelo ampliado del repositorio con las

clases y atributos añadidos. Se ha añadido la clase Particion que está compuestapor especializaciones y es a la vez componente de Clase, queriendo representar queuna clase puede dividirse en diversas (0,N) particiones. La clase Particion posee losatributos esCompleta que indica si la partición es completa, y esGrupoRol que indicasi la partición es un grupo de rol. Aunque el concepto de partición no es exactamenteel de grupo de rol, este atributo se ha introducido para intentar simpli…car el modelo,ya que partición y grupo de rol agrupan un conjunto de clases especializadas. La otraclase que se ha introducido es Rol como especialización estática de EspecEvento. Aesta última clase se le añadido el atributo esRol como condición de especialización.

1Actualmente OO-Method/CASE soporta también el almacenamiento de los esquemas concep-tuales en formato XML (www.w3c.org) para facilitar su importación y manipulación por terceros.

B.1. La Herramienta de Generación 351

OO-Method/CASEEditor Gráfico

Generador Código

Repositorio(BDR)

LectorRepositorio

Analizador Generador

BDR

Interfaz Gráfica de Usuario

Objetos de Negocio

Objetos de Acceso a Datos

Prototipo Generado

.DPR

.PAS

.TXT

ScriptsSQL

Compilador*.EXE *.DLL

*.DFM

Convertir

genera

OO-Method/CASEEditor Gráfico

Generador Código

Repositorio(BDR)

LectorRepositorio

Analizador Generador

BDR

Interfaz Gráfica de Usuario

Objetos de Negocio

Objetos de Acceso a Datos

Prototipo Generado

.DPR.DPR

.PAS.PAS

.TXT.TXT

ScriptsSQLScriptsSQL



*.DFM

Convertir

genera

Figura B.1: Elementos de la Herramienta de Generación

En la clase Rol se le han especi…cado los atributos cardMax y cardMin cardinalidadmáxima y mínima de la subclase de rol, respectivamente. El diagrama de migraciónse representa como un proceso por lo que no será necesario incorporar nuevas clasesen el metamodelo, ya que la clase Proceso está presente en el metamodelo inicial.

B.1.2 Interfaz de Usuario

Una vez el analista ha realizado la especi…cación del sistema en OO-Method y la haalmacenado en un repositorio, se está en disposición de utilizar el generador de códigodesarrollado. Cuando el analista decide ejecutarlo, la primera pantalla que se visualizaes la que se presenta en la …gura B.3. En dicha …gura básicamente se presentan lasopciones de Abrir, Proyecto, Destino, Generar, Salir y Ayuda. Estas opciones serviránpara generar un prototipo a partir de un esquema conceptual existente. El proceso aseguir para la obtención del prototipo es el siguiente:

1. En primer lugar, se debe de elegir el repositorio del cual el generador obtendrátoda la información necesaria (la especi…cación del sistema) para la generacióndel prototipo. Para ello se pulsará el botón Abrir o la opción de Menú Archivoj Abrir Repositorio. Una vez pulsado aparecerá la pantalla encargada de dichaselección (como se puede ver en la …gura B.4).

2. Una vez seleccionado el repositorio se pulsará el botón Proyecto o la opción deMenú Archivo j Seleccionar Proyecto y aparecerá la ventana de la …gura B.5.


EspecCondcond icion : StringEsPermanente : Bool

Herenciatipo_herencia : String

{tipo=count(tiene)}

si t ipo=0 la clase es elementalSi tipo>0 la clase es compleja

PAQUETE: RELACIONES

EspecEventoes_rol

ti po_rel acio n

tipo_herencia

tipo_especializacion

Relaciontipo_relacion : String

Agregacionnombre : Stringrolag regado : Stri ngrolcomp onente : Stri ngEsRe fe renci al : BoolEsEstati ca : Bo olCardM inCompon en te : StringCardMa xComp on en te : St ringCardMinCompuesta : StringCardMaxCompuesta : StringDI_en_compuesta : BoolDI_ en_Co mpone nte : Bool

<<disjunto>>

Generalizaciont ipo_ genera lizacion : Strin g

<<disjunto>>

2.. *

Rolcard_mincard_max

Clasenombre : stri ngtipo : Stringdescripcion : String

1

0..n

1

0..n

tiene

0..n

1

0..n

1

Agrega

Particiones_completaid_particiones_grupo_rol0..n0..n

Especializaciontipo_especializacion : String

1..n1..n

Especializa

1..n1..n

Figura B.2: Metamodelo Extendido de OO-Method

Figura B.3: Ventana Inicial del Generador

B.1. La Herramienta de Generación 353

Figura B.4: Ventana de Selección del Repositorio

Figura B.5: Ventana de Selección de Esquema Conceptual

Esta ventana muestra los esquemas conceptuales (proyectos) que almacena elrepositorio para que se seleccione uno en cuestión.

3. Una vez que el esquema conceptual ha sido elegido, se debe proceder a seleccio-nar el directorio de destino del código fuente que se va a generar (son los archivoscaracterísticos de un proyecto de Delphi, tales como *.pas, *.dcu, *.dpr, *.dfm,el prototipo en sí (el ejecutable) y la base de datos del prototipo. Para ello sepulsará el botón Destino o la opción de Menú Archivo j Seleccionar DirectorioDestino y aparecerá la ventana de la …gura B.6.

4. Seleccionado ya el repositorio y el directorio destino se puede proceder al procesode generación de código. Para ello se pulsará el botón con la etiqueta Generaro la opción de Menú Archivo j Generar Código. Una vez acabado el proceso degeneración de código aparecerá una pantalla indicando la …nalización del procesoe invitando a la ejecución del prototipo.


Figura B.6: Ventana de Selección del Directorio Destino

El generador también posee un Asistente (ver …gura B.7) para usuarios no expertosque automatiza la secuencia de pasos anterior.

B.2 Prototipo Generado

En este apartado se presenta la implementación del prototipo generado automática-mente siguiendo la propuesta presentada en esta tesis.

B.2.1 Arquitectura

Las clases que componen la aplicación generada se distribuirán en cada uno de lostres niveles de la arquitectura propuesta. En la …gura B.8 se muestra el diseño de laaplicación que constituye una aproximación particular a la arquitectura a tres nivelesutilizada para el diseño del prototipo.El nivel de presentación está representado por las clases de interfaz de usuario

(implementadas en los …cheros *.DFM generados por la herramienta). El nivel deaplicación está compuesto por las clases generadas aplicando las correspondenciasde…nidas en la tesis a los patrones de diseño especializados (implementadas en los…cheros *.PAS). Estas clases no aparecen de forma explícita en el diseño de la …guraB.8, para no complicar el esquema se ha introducido una única clase llamada Claseque representa a las clases de diseño que implementan las clases conceptuales. Lasclases Atributo y Evento en realidad no constituyen clases de diseño pero se hanincorporado para poder relacionarlas con los elementos del nivel de presentación quese encargan de visualizarlos, y así facilitar la comprensión de la arquitectura. Elnivel de persistencia está compuesto por las clases de acceso a la base de datos,representadas por la clase BD, (implementadas en los …cheros *.PAS) y por la base dedatos relacional que almacenará a los objetos de la aplicación.

B.2. Prototipo Generado 355

Figura B.7: Asistente de Generación


MenúVista Árbol

Atributo

Formulario

0..n

Campo Edición

Panel0..1

1..n

BD

0..1

0..n

Navegador Rejilla

1..nOpción

1..n1..n

Clase

0..n 10..n 1

Nodo

0..n0..n

1..n1..n

Evento

0..n1 0..n1

{or} {or}

-----------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------

Figura B.8: Diseño del Prototipo Generado


B.2.2 Funcionamiento

Haciendo uso del esquema de la …gura B.8 y la captura de pantalla de la …gura B.9 seva a identi…car el diseño prede…nido de la interfaz de usuario propuesta para todos losprototipos generados, explicando a su vez cuál será el funcionamiento del prototipo:

² Una clase Formulario, que es el formulario principal de la aplicación. Contieneun Menú, una Vista Árbol, un Panel,y un Navegador.

– El Menú posee tres items de menú:

¤ Menú de clases: Seleccionando este menú se puede ver la relación declases que hay en el sistema a analizar, así como para cada una de ellasmuestra sus posibles subclases existentes. Las clases que se muestrenen este menú son las mismas que hay en el árbol de herencia quemuestra la Vista Árbol.

¤ Menú de métodos: Seleccionando este menú se puede ver la relación deeventos2 disponibles para la clase que actualmente esta seleccionada.

¤ Menú de Ayuda.– La Vista Árbol se utiliza para mostrar en sus Nodos todas las clases exis-tentes del sistema, así como las subclases que posee cada superclase (eneste caso representadas como nodos de un subárbol creado para cada clase)y todos los eventos de ambas. Tanto desde la Vista Árbol como desde lositems de Menu, se realizan todas las selecciones de clases y activaciones deeventos.

– El Panel contiene objetos de las clases Campo Edición y Rejilla. Cuandose selecciona una clase aparece un Panel en el área del formulario principalque representará la clase que actualmente está seleccionada, visualizandosu población en la Rejilla y el estado del primer objeto de ésta en losCampos de Edición (uno por cada atributo). Si la clase tiene clases des-cendientes, tendrá paneles invisibles que se harán visibles cuando sea selec-cionada dicha subclase. En estos paneles se mostrarán los nuevos atributosde la subclase.

– El Navegador permitirá moverse a través de la población de objetos de laclase activa.

Por último, es importante destacar que para activar un evento es necesario ins-tanciar los argumentos de éste. Para ello en el modelo de ejecución se propone queexista un formulario de petición de argumentos. Si una clase no tiene objetos o nohay un objeto servidor seleccionado se controlará que no pueda ser activado ningúnevento para esa clase bien desde el menú o desde el árbol (desactivando las opcionesde los servicios que no pueden ser seleccionados). Por ejemplo, cuando no existe nin-gún objeto para la clase activa, desde el menú sólo se podrán activar los eventos decreación (ver …gura B.10), estando desactivados los restantes.Cuando se activa un evento (ver …gura B.10) se muestra un formulario como el de

la …gura B.11, con tantos objetos campos de edición cómo argumentos posea el evento2En la Interfaz de Usuario se les ha llamado métodos en vez de eventos por ser un término

comúnmente utilizado en la programación OO


Vista Árbol

Rejilla

NavegadorMenú

Panel

Campo Edición

Nodos

Vista Árbol

Rejilla

NavegadorMenú

Panel

Campo Edición

Nodos

Figura B.9: Componentes de la Interfaz de Usuario. Ventana Principal

activado. Cada campo de edición tendrá una aparencia dependiendo del dominio delargumento que representa, por ejemplo un dato de tipo fecha hace que el formulariomuestre un campo especial que al pulsarse hace que se depliegue un calendario dondese puede seleccionar una fecha concreta. En este formulario se comprobará si elusuario ha rellenado o no el argumento requerido, y si en cada campo de edición seha introducido el carácter apropiado a cada dominio del argumento, en caso contrarioaparecerá un mensaje informando al usuario de tal efecto (ver …gura B.15). Una vez elusuario ha introducido los argumentos requeridos en las cajas de edición, se realizarála llamada al evento implementado en el nivel de aplicación.En el nivel de aplicación se ejecutará la implementación del evento a través de la

ejecución de cada uno de los pasos de la estrategia de ejecución (comprobar transiciónde estado, comprobar precondiciones, evaluar, comprobar restricciones de integridady comprobar disparos). Si la ejecución del evento no se puede producir por que no secumple alguno de los pasos entonces se avisará al usuario (ver …gura B.13), y si hatenido éxito se actualizará la base de datos (ver …gura B.14).La activación y ejecución de cualquier evento seguirá las pautas que se han presen-

tado. Los eventos de destrucción eliminarán al objeto de la base de datos. Si el eventoque se ejecuta es portador o activador del rol, o se cumple una condición de espe-cialización. Se mostrará un formulario (ver …gura ) donde se pedirán los argumentosnecesarios para dicha especialización (dando valor a los nuevos atributos).


Figura B.10: Activación del evento comprar_vehículo

Figura B.11: Petición de argumentos para el evento comprar_vehículo

Figura B.12: Mensaje de información sobre el tipo del argumento introducido


Figura B.13: Mensaje que informa de la violación de una precondición

Figura B.14: Se ha creado un nuevo objeto Vehículo


Figura B.15: Petición de argumentos para especializar un objeto

Bibliografía

[1] A. Aarsten, D. Bugali y G. Menga. Patterns for Three-Tier Client/Server Ap-plications. Informe técnico, Dept. of Automatica e Informatica, Politecnico diTorino, Italy, 1997.

[2] A. Albano, R. Bergamini, G. Ghelli y R. Orsini. An Object Data Model withRoles. En D. Bell R. Agrawal, S. Baker, editor, 19th International Conferenceon Very Large Databases, páginas 39–51. Morgan Kaufmann, 1993.

[3] M. Albert. Especi…cación de Transacciones en Modelos Conceptuales: Del Es-pacio del Problema al Espacio de la Solución. Informe técnico, Departamentode Sistemas Informáticos y Computación, 2001. Trabajo de Investigación.

[4] M. Albert, E. Campos, V. Pelechano y M. Katrib. Tratamiento de Excep-ciones a Nivel de Modelado Conceptual OO. En Mario Piattini Oscar Díaz,Arantza Illarramendi, editor, VI Jornadas de Ingeniería del Software y Basesde Datos (JISBD 2001), páginas 311–326. Noviembre 2001.

[5] M. Albert, E. Campos, V. Pelechano y O. Pastor. Tratamiento de AtributosDerivados en Entornos de Producción Automática de Software Orientado a Ob-jetos. En Workshop Iberoamericano de Ingenieria de Requisitos y AmbientesSoftware IDEAS 2001, páginas 117–131. 2001.

[6] C. Alexander. The Timeless Way of Building. Oxford University Press, 1979.

[7] C. Alexander, S. Ishikawa, M. Silvertein, M. Jacobson, I. Fiksdahl-King y S. An-gel. A Pattern Language: Towns, Building, Construction. En Oxford UniversityPress. 1977.

[8] J. Altmeyer, J.P. Riegel, B. Schuermann, M. Schuetze y G. Zimmermann. Appli-cation of a Generator-Based Software Development Method Supporting ModelReuse. En Proceedings of 9th International Conference in Advanced InformationSystems Engineering, CAiSE97, páginas 159–171. Springer-Verlag, Barcelona,Catalonia,Spain, June 1997. Lecture Notes in Computer Science 1250, ISBN3-540-63107-0.

[9] P. America. Inheritance and Subtyping in a Parallel Object-oriented Language.En ECOOP’87: European Conference on Object Oriented Programming, páginas234–242. Springer-Verlag, Paris, France, June 1987. Lecture Notes in ComputerScience 246.

363

364 BIBLIOGRAFÍA

[10] P. America. Designing an Object-oriented Programming Language with Beha-vioural Subtyping. En G. Rozenberg J. W. De Bakker, W. P. De Roever, edi-tor, Proceedings of the Foundations of Object-Oriented Languages, REX Scho-ol/Workshop, páginas 60–90. Springer-Verlag, Paris, France, June 1990. LectureNotes in Computer Science 489.

[11] A. Analyti, P. Constantopoulos y N. Spyratos. Specialization by Restrictionand Schema Derivations. Information Systems, 23(1):1–38, 1998.

[12] L. F. Andrade, J. C. Gouveia y P. J. Xardonne. Architectural Concerns inAutomating Code Generation. En OOPSLA midyear conference. 1998.

[13] P. A. Angeles. Dictionary of Philosophy. Harper Perennial, New York, 1981.

[14] L. Aqvist. Handbook of Philosophical Logic II, capítulo Deontic Logic, páginas605–714. Reidel, 1984. Gabbay D.M., Guenthner F. (ed.).

[15] System Architect. web site http://www.popkin.com, 2000.

[16] S. Argawal, R. Jensen y A.M. Keller. Architecting Object Applications for HighPerformance with Relational Databases. En OOPSLA Workshop on ObjectDatabase Behaviour, Benchmarks, and Performance. Austin, 1995.

[17] C.W. Bachman y M. Daya. The Role Concept in Data Models. En Proceedingsof the Third International Conference on Very Large Data Bases, páginas 464–476. 1977.

[18] R. Balzer, T. Cheatham y C. Green. Software Technology in the 1990s: Usinga New Paradigm. IEEE Computer, páginas 39–45, November 1983.

[19] H. Balzert, F. Hofmann, C. Niemann y V. Kruschinski. JANUS Application De-velopment Environment, Generating more than the User Interface. En CADUI96. FUNDP, Namur, 1996.

[20] D. Baumer, G. Gryczan, R. Knoll, C. Llienthal, D. Riehle y H. Züllighoven.Framework Development for Large Systems. Communications of the ACM,40(10):52–59, October 1997.

[21] D. Baumer y D. Riehle. Product Trader, capítulo 3. Pattern Languages ofProgram Design 3. Addison-Wesley, 1998.

[22] D. Baumer, D. Riehle, W. Siberski y M. Wulf. The Role Object Pattern. EnPLoP 97 (The 4th Pattern Languages of Programming Conference). 1997.

[23] K. Beck. Embracing Change with Extreme Programming. IEEE Computer,páginas 70–77, Octubre 1999.

[24] T. Behrens y S. Richards. StateLator - Behavioral Code Generation as an Ins-tance of a Model Transformation. En L. Bergman B. Wangler, editor, Interna-tional Conference on Advanced Information Systems Engineering, CAiSE 2000,páginas 401–416. Springer-Verlag, 2000. Lecture Notes in Computer Science1789.

BIBLIOGRAFÍA 365

[25] R. Bell. Code Generation from Object Models. Embedded Systems Program-ming, March 1998. http://www.embedded.com/98/9803fe3.html.

[26] E. V. Berard. Essays on Object Oriented Software Engineering, tomo 1.Prentice-Hall, Englewood Cli¤s, N.J., 1993.

[27] S. Bergamaschi y C. Sartori. On Taxonomic Reasoning In Conceptual Design.ACM Transactions on Database Systems, 17(3):385–422, September 1992.

[28] B.I. Blum. A Taxonomy of Software Development Methods. Communicationsof the ACM, 37(11):82–94, 1994.

[29] M. Boasson. The Artistry of Software Architecture. IEEE Software SpecialIssue on Architectures, páginas 13–16, November 1995.

[30] M. Boger, T. Baier, F. Wienberg y W. Lamersdorf. Extreme Modeling. EneXtreme Programming and Flexible Processes in Software Engineering. June2000.

[31] G. Booch. Object Oriented Analysis and Design with Applications. Second Edi-tion. Addison-Wesley, 1994.

[32] A. Borgida, J. Mylopoulos y H.K.T. Wong. Generalization/Specialization as aBasis for Software Speci…cation, páginas 84–117. Springer-Verlag, 1984.

[33] R. J. Brachman. What is-a is and isn’t. IEEE Computer, 16(10):30–36, October1983.

[34] R.J. Brachman y J. G. Schmolze. An Overview of the KL-ONE KnowledgeRepresentation System. Cognitive Science, 9:171–216, 1985.

[35] K. Brown. Crossing Chasms. Pattern Languages of Program Design 2, capítu-lo Crossing Chasms: The Architectural Patterns. Software Patterns Series.Addison-Wesley, K. Brown and B. Whitenack edición, 1996.

[36] F.J. Budinsky, M.A. Finnie, J.M. Vlissides y P.S. Yu. Automatic Code Gene-ration from Design Patterns. IBM Systems Journal, 35(2), 1996.

[37] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad y M. Stal. Pattern-Oriented Software Architecture. A System of Patterns. John Wiley and Sons,1996.

[38] E. Campos. Agregación. Una Aproximación basada en Patrones Conceptuales.Informe técnico, Departamento de Sistemas Informáticos y Computación, 2001.Trabajo de Investigación.

[39] E. Campos, M. Albert, V.Pelechano y O. Pastor. Implementación de un Mo-delo de Ejecución en Entornos Orientados a Objetos para los Disparos de OO-Method. En Jornadas Chilenas de Computación 2001- IX Encuentro Chilenode Computación. Noviembre 2001.

366 BIBLIOGRAFÍA

[40] J.H. Canós. OASIS un lenguaje único para Bases de Datos Orientadas a Ob-jetos. Tesis Doctoral, Departamento de Sistemas Informáticos y Computación,Universidad Politécnica de Valencia, Diciembre 1996.

[41] T. Cargill. C++ Programming Style. Addison-Wesley, Reading, MA, 1992.

[42] J.V. Carrión. Implementación de una Herramienta de Ayuda al Modelado Con-ceptual basada en Patrones. Proyecto Fin de Carrera, Facultad de Informática,2001.

[43] J. A. Carsí. OASIS como Marco Conceptual para la Evolución del Software. TesisDoctoral, Departamento de Sistemas Informáticos y Computación, UniversidadPolitécnica de Valencia, Octubre 1999.

[44] K. Carter. Executable Modelling with the UML. The xUML method and iUML,the xUML toolset. Informe Técnico ref: CTN 80 v1.1, Kennedy Carter Ltd.,http://www.kc.com/, 2000.

[45] J. Charles. Software Research Heads US Funding Priorities. IEEE Software,páginas 107–110, May/June 1999.

[46] S.W. Clyde, D.W. Embley y S.N. Wood…eld. Tunable Formalism in Object-Oriented System Analysis: Meeting the Needs of Both Theoreticians and Prac-titioners. En OOPSLA’92, páginas 452–465. Vancouver, Canada, 1992.

[47] P. Coad. Object Oriented Patterns. Comunications of the ACM, 35(9):152–159,1992.

[48] P. Coad y M. May…eld. JAVA Design: Building Better Apps and Applets 2ndEdition. Yourdon Press, Upper Saddle River, 1999.

[49] P. Coad, D. North y M. May…eld. Object Models: Strategies, Patterns andApplications. Yourdon Press Computing Series. Prentice-Hall, 1997.

[50] P. Coad y E. Yourdon. Object-Oriented Analysis. Prentice-Hall, 1990.

[51] D. Coleman, T. Arnold, S. Bodo¤, C. Dollin, H. Gilchrist, R. Hayes y T. Je-remaes. Object Oriented Development: The FUSION Method. Prentice-Hall,1994.

[52] D. Coleman, F. Hayes y S. Bear. Introducing Objectcharts or How to Use State-charts in Object Oriented Design. IEEE Transaction on Software Engineering,18(1), January 1992.

[53] S. Cook y J. Daniels. Designing Objects Systems. Object-Oriented Modellingwith Syntropy. Prentice Hall, 1994.

[54] W.R. Cook, W.L. Hill y P. S. Canning. Inheritance is not subtyping. EnSeventeenth Annual ACM Symposium on Principles of Programming Languages,páginas 125–135. ACM Press, 1990.

[55] J. O. Coplien. Advanced C++ Programming Styles and Idioms. Addsion-Wesley,Reading, MA, 1993.

BIBLIOGRAFÍA 367

[56] J. O. Coplien. A Generative Development Process Pattern Language, páginas243–300. Cambridge University Press, New York, l. rising ed. edición, 1998.

[57] J.O. Coplien y D.C. Schmidt. Pattern Languages of Program Design. Addsion-Wesley, Reading, MA, 1995.

[58] Rational Software Corporation. Rational Rose User’s Manual. Informe técnico,2000.

[59] P. Costa, M. Barceló, D. Costal, A. Olivé, C. Quer andd A. Roselló y M.R.Sancho. Las Clases de Objetos en ROSES. En I Jornadas de Investigación yDocencia en Bases de Datos. La Coruña, España, 1996.

[60] CREWS (Cooperative Requirements Engineering with Scenarios). Informe téc-nico, ESPRIT Project Programme 21.903, August 1996.

[61] W. Damm y D. Harel. LSCs: Breathing Life Into Message Sequence Charts.En A. Fantechi P. Giancarlini y R. Gorrieri, editores, Proceedings 3rd IFIPInternational Conference on Formal Methods for Open Object-based DistributedSystems (FMOODS’99), páginas 293–312. Kluwer Academic Publishers, 1999.

[62] Real Academia de la Lengua Española. Diccionario de la Real Academia de laLengua Española. http://www.rae.es, 2001.

[63] G. Denker y P. Hartel. TROLL - An Object oriented Formal Method for Dis-tributed Information System Design: Syntax and Pragmatics. TROLL Version3.0. Informe técnico, Universität Braunschweig, 1998.

[64] V. Devedzic. Ontologies: Borrowing from Software Patterns. Intelligence, pági-nas 14–24, 1999.

[65] P. Douglas, G. Alliger y R. Goldberg. Client-Server and Object-Oriented Trai-ning. En Computer, páginas 80–84. June, 1996.

[66] D.F. D’Souza y A.C. Wills. Objects, Components and Frameworks with UML.Addison-Wesley, Reading, MA, 1998.

[67] E. Dubois. The Albert II language: On the Design and the Use of a FormalSpeci…cation Language for Requirements Analysis. Tesis Doctoral, ComputerScience Department. University of Namur, Namur, 1995.

[68] F. Durán y A. Vallecillo. Writing ODP Enterprise speci…cations in Maude. EnJosé Cordeiro y Haim Kilov, editores, Proc. of WOODPECKER’01, páginas55–68. Setubal, Portugal, julio 2001.

[69] P. Dyson y B. Anderson. Pattern Languages of Program Design 3, capítuloState Patterns, páginas 125–142. Software Patterns. Addison-Wesley, RobertMartin, Dirk Riehle and Frank Buschmann edición, 1998.

[70] J. Ebert y G. Engels. Structural and behavioural views on omt-classes. EnS. Urban y E. Bertino, editores, International Conference on Object-OrientedSystems, Methodologies, and Applications (ISOOMS’94). 1994.

368 BIBLIOGRAFÍA

[71] H. D. Ehrich, C. Caleiro, A. Sernadas y G. Denker. Logics for SpecifyingConcurrent Information Systems. Logics for Database and Information Systems,páginas 167–198.

[72] P. W. Fach. Design Reuse through Frameworks and Patterns. IEEE Software,páginas 71–76, September/October 2001.

[73] E. Falkenberg. Concepts for Modelling Information. En G.M. Nijssen, editor,Proceedings of the IFIP Conference on Modelling in Data Base ManagementSystems, páginas 95–109. North-Holland, Amsterdam, 1976.

[74] R.B. Feenstra y R.J. Wieringa. LCM 3.0 : A Language for Describing Concep-tual Models. En Faculty of Mathematics and Computer Science, Vrije Univer-siteit. Technical Report IR-344, Amsterdam, December 1993.

[75] M. Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997.

[76] M. Fowler. Dealing with Roles, 1998. http://www2.awl.com/cseng/titles/0-201-89542-0.

[77] E. Gamma. The Extension Object Pattern. En PLoP’96. 1996.

[78] E. Gamma, R. Helm, R. Johnson y J. Vlissides. Design Patterns: Elements ofReusable Object-Oriented Software. En Professional Computing Series, editor,Addison-Wesley, Reading, MA. 1994.

[79] R.C. Goldstein y V. C. Storey. Data Abstractions: Why and How? Data andKnowledge Engineering, 29:293–311, 1999.

[80] J. Gómez. Generación Automática de Componentes Software a partir de Mode-los Conceptuales Orientados a Objeto. Tesis Doctoral, Universidad de Alicante,Noviembre 1999.

[81] G. Gottlob, M. Schre‡ y B. Röck. Extending object-oriented systems withRoles. ACM Transactions on Information Systems, 14(3):268–296, 1996.

[82] A. Grau, J. K. Filipe amd M. Kowsari, S. Eckstein, R. Pinger y H. D. Ehrich.The TROLL Approach to Conceptual Modelling: Syntax, Semantics and Tools.En S. Ram T. W. Ling y M. L. Lee, editores, Proceedings of 17th InternationalConference on Conceptual Modeling (ER’98), páginas 277–290. Springer-Verlag,1998. LNCS 1507.

[83] A. Grau y M. Kowsari. A Validation System for Object Oriented Speci…cationsof Information Systems. En R. Manthey y V. Wolfengagen, editores, Proceedingsof ADBIS’97 Symposium, páginas 277–290. 1997.

[84] J. Griethuysen. Concepts and Terminology for the Conceptual Schemaand the Information Base. ANSI, New York, 1982. Publication NumberISO/TC97/SC5-N695.

[85] Object Management Group. web page http://www.omg.org.

BIBLIOGRAFÍA 369

[86] Object Management Group. Uni…ed Modeling Language Speci…cation Version1.4 draft. Informe técnico, February 2001 (Version 1.3, June 1999).

[87] T. Gruber. Toward Principles for the Design of Ontologies used for Knowled-ge Sharing. International Journal of Human Computer Studies, (43):907–928,1995.

[88] N. Guarino. Concepts, Attributes and Arbitrary Relations: Some Linguisticand Ontological Criteria for Structuring Knowledge Bases. Data and KnowledgeEngineering, 8(2):249–261, 1992.

[89] N. Guarino. Formal Ontology, Conceptual Analysis and Knowledge Representa-tion. International Journal of Human and Computer Studies, 43(5/6):625–640,1995.

[90] N. Guarino y C. Welty. A Formal Ontology of Properties. En EKAW-2000:The 12th International Conference on Knowledge Engineering and KnowledgeManagement. Spring-Verlag, October 2000. LNCS.

[91] N. Guarino y C. Welty. Identity, Unity, and Individualization: Towards a FormalToolkit for Ontological Analysis. En ECAI-2000: The European Conference onArti…cial Intelligence. IOS Press, August 2000.

[92] N. Guarino y C. Welty. Ontological Analysis of Taxonomic Relationships. EnA. Laender y V. Storey, editores, ER-2000: The 19th International Conferen-ce on Conceptual Modeling, páginas 210–224. Springer-Verlag, October 2000.LNCS 1920.

[93] S. Guo, W. Sun y M.A. Weiss. Solving Satis…ability and Implication Problemsin Database Systems. ACM Transactions On Database Systems, 21(2):270–293,1996.

[94] J.L. Hainaut, J.M. Hick, V. Englebert, J. Henrard y D.Roland. Representationof IS-A relations. Institut d’Informatique, University of Namur, 1996.

[95] D. Harel. Handbook of Philosophical Logic II, capítulo Dynamic Logic, páginas497–694. Reidel, 1984. Gabbay D.M., Guenthner F. (ed.).

[96] D. Harel. Statecharts : A Visual Formalism for Complex Systems. Science ofComputer Programming, 8:231–274, 1987.

[97] D. Harel. From Play-In Scenarios to Code: An Achievable Dream. En Fun-damental Approaches to Software Engineering (FASE). Springer-Verlag, March2000.

[98] D. Harel y E. Gery. Executable Object Modeling with Statecharts. IEEEComputer, páginas 31–42, July 1997.

[99] D. Harel y O. Kupferman. On the Behavioral Inheritance of State-Based Ob-jects. Informe técnico, 2000.

370 BIBLIOGRAFÍA

[100] W. Harrison y H. Ossher. Subject-Oriented Programming (A Critique of PureObjects). En Proceedings of the Object-Oriented Programming Systems, Lan-guages and Applications (OOPSLA’93). 1993.

[101] T. Hartmann, R. Jungclaus y G. Saake. Aggregation in a Behavior OrientedObject Model. En ECOOPŠ92: European Conference on Object-Oriented Pro-gramming, páginas 57–77. Springer-Verlag, 1992. Lecture Notes in ComputerScience 615.

[102] T. Hartmann, G. Saake, R. Jungclaus, P. Hartel y J. Kusch. Revised Versionof the Modelling Language Troll (Troll version 2.0). En Technische UniversitatBraunschweig, Informatik-Berichte. TR94-03, April 1994.

[103] D. Hay. Data Model Patterns: Conventions of Thought. Dorset House, 1996.

[104] F. Heister, J.P. Riegel, M. Schuetze, S. Schultz y G. Zimmermann. Pattern-Based Code Generation for Well-De…ned Application Domains. Informe técnico,Computer Science Department, University of Kaiserslautern, 1998.

[105] B. Henderson-Sellers y F. Barbier. What Is This Thing Called Aggregation? EnJ. Bosch R. Mitchell, A.C. Wills y B. Meyer, editores, Proceedings of TOOLS29, páginas 216–230. IEEE Computer Society, Los Alamitos, CA, USA, 1999.

[106] I-Logix Inc. products web page, http://www.ilogix.com.

[107] ILOG OPL Studio. product web page: http://www.ilog.com/, 2001.

[108] E. Insfrán, M. Burbano y O. Pastor. Generating Conceptual Schemas fromRequirements Models. En Jornadas de Ingeniería de Requisitos Aplicada (JIRA2001). Universidad de Sevilla, June 2001.

[109] ISO/IEC. Open Distributed Processing – Reference Model – Part 2: Foun-dations. International Standard ISO/IEC 10746-2, ITU-T X.902, ISO/ITU-T,1997.

[110] ISO/IEC. RM-ODP Enterprise Language. Draft International StandardISO/IEC 15414, ITU-T X.911, ISO/ITU-T, 2001.

[111] R. B. Jackson, D. W. Embley y S.N. Wood…eld. Automated Support forthe Development of Formal Object-Oriented Requirements Speci…cation. EnCAiSE’94, páginas 135–148. Springer-Verlag, Utrecht, The Netherlands, 1994.LNCS 811.

[112] I. Jacobson, G. Booch y J. Rumbaugh. The Uni…ed Software DevelopmentProcess. Addison-Wesley, 1999.

[113] I. Jacobson, M. Christerson, P. Jonsson y G. Overgaard. Object Oriented Soft-ware Engineering, a Use Case Driven Approach. Addison -Wesley. Reading,Massachusetts, 1992.

[114] S. Jarzabeck y R. Huang. The Case for User-Centered CASE Tools. Commu-nications of ACM, 41(8):93–99, August 1998.

BIBLIOGRAFÍA 371

[115] R. E. Johnson. Frameworks= Components + Patterns. Communications of theACM, 40(10):39–42, October 1997.

[116] C.B. Jones. Systematic Software Development with VDM. Prentice-Hall, En-glewood Cli¤s, NJ, 1986.

[117] R. Jungclaus, G. Saake, T. Hartmann y C. Sernadas. TROLL - A Languagefor Object-Oriented Speci…cation of Information Systems. ACM Transactionson Information Systems, 14(2):175–211, April 1996.

[118] N. Kerth. Pattern Languages for Program Design, capítulo Caterpillar’s Fate:A Pattern Language for Transformation from Analysis to Design. SoftwarePatterns Series. Addison Wesley Publishing Company, Menlo Park, California,James C. Coplien and Douglas C. Schmidt edición, 1995.

[119] B.B. Kristensen. Object-oriented Modeling with Roles. En B. Stone J. Mur-phy, editor, OOIS’95: Proceedings of the International Conference on Object-Oriented Information Systems, páginas 57–71. Springer-Verlag, December 1995.

[120] B.B. Kristensen y K. Osterbye. Conceptual Modeling and Programming Lan-guages. ACM SIGPLAN Notices, 29(9):81–90, September 1994.

[121] B.B. Kristensen y K. Osterbye. Roles: Conceptual abstraction theory andpractical language issues. Theory and Practice of Object Systems, 2(3):143–160, 1996.

[122] J. Kusch, P. Hartel, T. Hartmann y G. Saake. Gaining a Uniform View ofDi¤erent Integration Aspects in a Prototyping Environment. En DEXA’95,páginas 35–42. Springer-Verlag, 1995. LNCS 978.

[123] W.R. LaLonde y J. Pugh. Subclassing 6= Subtyping 6= is-a. Journal of ObjectOriented Programming, 3(5):57–62, 1991.

[124] S. Lauesen. Real-Life Object-Oriented Systems. IEEE Software, páginas 76–83,March/April 1998.

[125] S. Lauesen y M.B. Harning. Virtual Windows: Linking User Tasks, Data Mo-dels, and Interface Design. IEEE Software, 18(4):67 –75, Jul/Aug 2001.

[126] D. Lea. Roles Before Objects. 1995. http://www.g.oswego.edu/ lea.

[127] M. Lenzerini. Covering and Disjointness Constraints in Type Networks. EnProceedings of ICDE 87, páginas 386–393. 1987.

[128] P. Letelier. Animación Automática de Especi…caciones OASIS usando Progra-mación Lógica Concurrente. Tesis Doctoral, Departamento de Sistemas Infor-máticos y Computación, Universidad Politécnica de Valencia, Diciembre 1999.

[129] P. Letelier, P. Sánchez, I. Ramos y O. Pastor. OASIS 3.0: Un enfoque for-mal para el modelado conceptual orientado a objetos. Servicio de PublicacionesUniversidad Politécnica de Valencia, Valencia, España, 1998. SPUPV -98.4011.ISBN 84-7721-663-0.

372 BIBLIOGRAFÍA

[130] Q. Li y F.H. Lochovsky. ADOME: An Advanced Object Modeling Environment.IEEE Transactions on Knowledge and Data Engineering, 10(2):255–276, 1998.

[131] S.W. Liddle, D.W. Embley y S.N. Wood…eld. Unifying Modeling and Pro-gramming Through an Active, Object-Oriented Model-Equivalent Program-ming Language. En 14th International Conference on Object-Oriented andEntity-Relationship Modeling (OOER’95), páginas 55–64. Springer-Verlag, GoldCoast, Australia, 13-15 December 1995. LNCS 1021.

[132] O.I. Lindland, G. Sindre y A. Solverg. Understanding Quality in ConceptualModeling. IEEE Software, páginas 42–49, Marzo 1994.

[133] U.W. Lipeck y D. Feng. Construction of Deterministic Transition Graphs fromDynamics Integrity Constraints. En Proceedings of the 14th Intern. Workshopon Graph- heoretic Concepts in Computer Science, páginas 166–179. Springer-Verlag, Berlin, 1988. LNCS 344.

[134] B. H. Liskov y J.M. Wing. A Behavioral Notion of Subtyping. ACM Tran-sactions on Programming Languages and Systems, 16(6):1811–1841, November1994.

[135] S. Liu, A.J. O¤ut, C. Ho-Stuart, Y. Sun y M. Ohba. SOFL: A Formal Engine-ering Methodology for Industrial Applications. IEEE Transactions on SoftwareEngineering, 24(1):24–45, January 1998.

[136] O.L. Madsen, B. Magnusson y B. Moller-Pedersen. Strong Typing of ObjectOriented Programming Revisited. ACM SIGPLAN Notices, 25(10):140–149,October 1990.

[137] N. A. Maiden y A.G. Sutcli¤e. Exploiting Reusable Speci…cations throughAnalogy. Communications of the ACM, 35(4):55–64, 1992.

[138] J. Martin y J. Odell. Object Oriented Methods: A Foundation. Prentice-Hall,1994.

[139] J. Martin y J.J. Odell. Object-Oriented Analysis and Design. Prentice-Hall,Englewood Cli¤s, N.J., 1992.

[140] J. Martin y J.J. Odell. Object Methods: Pragmatic Considerations. PrenticeHall, 1996.

[141] J. Martin y J.J Odell. Object-Oriented Methods: A Foundation. Prentice Hall,Upper Saddle River, N.J., 1998.

[142] R. C. Martin, D. Riehle, F. Buschmann y J. Vlissides. Pattern Languages ofProgram Design 3. Software Patterns Series. Addison-Wesley Pub Co, October1997.

[143] G. Maughan y B. Durnota. MON: An Object Relationship Model IncorporatingRoles, Classi…cation, Publicity and Assertions. En Proceedings of OOIS ’94,International Conference on Object Oriented Information Systems. 1994.

BIBLIOGRAFÍA 373

[144] G. Meszaros y J. Doble. A Pattern Language for Pattern Writing, páginas 529–574. Pattern Languages of Program Design 3. Addison-Wesley, Robert Martin,Dirk Riehle and Frank Buschmann edición, 1998.

[145] B. Meyer. Construcción de Software Orientado a Objetos. Prentice-Hall, Se-gunda Edición, 1998.

[146] J.J. Ch. Meyer. A di¤erent approach to deontic logic: Deontic logic viewed asa variant of dynamic logic. Notre Dame Journal of Formal Logic, 29:109–136,1988.

[147] P.J. Molina. Especi…cacion de interfaz de usuario en OO-Method. PFC, Facul-tad de Informatica. UPV, 1998.

[148] P.J. Molina, O. Pastor, S. Martí, J.J. Fons y E. Insfrán. Specifying ConceptualPatterns in an Object-Oriented Method with Automatic Code Generation. EnE.Kapetanios y H.Hinterberger, editores, Second IEEE International Workshopon User Interfaces to Data Intensive Systems (UIDIS 2001), páginas 61–72.IEEE Computer Society, 2001.

[149] R. Neches, R. Fikes, T. Finin, T. Gruber, R. Patil, T. Senator y W. Swartout.Enabling Technology for Knowledge Sharing. AI Magazine, 12(3), 1991.

[150] O. Nierstrasz. Object-Oriented Software Composition, capítulo Regular Typesfor Active Objects, páginas 99–121. Prentice-Hall, 1995.

[151] Objectime. Objectime CASE Tool. web page http://www.objectime.com.

[152] OBLOG Software S.A. The OBLOG software development approach. Informetécnico, OBLOG Software S.A., 1999.

[153] J. J. Odell. Advanced Object-Oriented Analysis and Design Using UML. Cam-bridge University Press, 1998.

[154] J. Odrowski y P. Sogaard. Pattern Integration: Variations of State. Informetécnico, Sprint Corporation, 1996.

[155] A. Olivé. Taxonomies and Derivation Rules in Conceptual Modeling. EnM.C. Norrie K. R. Dittrich, A. Geppert, editor, CAiSE 2001, páginas 417–432.Springer, 2001. LNCS 2068.

[156] A. Olivé, D. Costal y M.R. Sancho. Entity Evolution in IsA Hierarchies. En18th International Conference on Conceptual Modeling, ER’99, páginas 62–80.Springer-Verlag, 1999. LNCS 1728.

[157] R. Orfali y D. Harkey. The Essential Distributed Objets Survival Guide. John-Wiley and Sons, 1996.

[158] M. Page-Jones. Fundamentals of Object-Oriented Design in UML. Object Te-chnology Series. Addison-Wesley, 2000.

[159] J. Palsberg y M.I. Schwartzbach. Static Typing for Object-oriented Program-ming. Informe Técnico DAIMI PB-355, Aarhus University, June 1991.

374 BIBLIOGRAFÍA

[160] M. P. Papazoglou. Unraveling the Semantics of Conceptual Schemas. Commu-nications of ACM, 38(9):80–94, September 1995.

[161] J. Parsons y Y. Wand. Choosing Classes in Conceptual Modeling. Communi-cations of the ACM, 40(6):63–69, June 1997.

[162] J. Parsons y Y. Wand. Using Objects for Systems Analysis. Communicationsof the ACM, 40(11):104–110, November 1997.

[163] O. Pastor, S. Abrahao y J. Fons. Building E-Commerce Applications fromObject-Oriented Conceptual Models. Newsletter of the ACM SIGecom Exchan-ges, 2(2):24–32, 2001.

[164] O. Pastor, S. Abrahao y J. Fons. Object-Oriented Approach to Automate WebApplications. En 2nd International Conference on Electronic Commerce andWeb Technologies (EC-Web’01), páginas 16–28. Springer-Verlag, Munich, Ger-many, Septiembre 2001. LNCS 2115.

[165] O. Pastor, J. Gómez, E. Insfrán y V. Pelechano. The OO-Method Approach forInformation Systems Modelling: From Object-Oriented Conceptual Modelingto Automated Programming. Information Systems, 26(7):507–534, 2001.

[166] O. Pastor, F. Hayes y S. Bear. OASIS: An object-oriented Speci…caction Lan-guage. En CAiSE’92, páginas 348–363. Springer-Verlag, Manchester, UK, 1992.

[167] O. Pastor, J. Iborra y I. Ramos. OO-METHOD-CASE: A Software ProductionWorkbench Supporting Automated Prototyping. En 6th International Confe-rence on Extending Database Technology, Demo Session. (EDBT’98). Valencia,España, March 1998.

[168] O. Pastor, E. Insfrán, V. Pelechano J., Romero y J. Merseguer. OO-Method:An OO Software Production Environment Combining Conventional and FormalMethods. En 9th Conference on Advanced Information Systems Engineering(CAiSE’97), páginas 145–159. Springer-Verlag, Barcelona, Spain, June 1997.LNCS (1250).

[169] O. Pastor, E. Insfrán y V. Pelechano. Modelado Orientado a Objetos Aplicadoa Entornos de Desarrollo Relacionales. En II Jornadas de Investigación y Do-cencia en Bases de Datos (JIDBD’97), páginas 61–71. Madrid, España, Julio1997.

[170] O. Pastor, E. Insfran y V. Pelechano. Conceptual User Interface Patterns forObject Oriented Conceptual Models. En ADBIS-DASFAA 2000 Symposium onAdvances in Databases and Information Systems. September 2000.

[171] O. Pastor, E. Insfrán, V. Pelechano y S. Ramírez. Linking Object-Oriented Con-ceptual Modeling with Object-Oriented Implementation in Java. En Databaseand Expert Systems Applications (DEXA’97), páginas 132–142. Springer-Verlag,Toulouse, France, September 1997. LNCS (1308).

BIBLIOGRAFÍA 375

[172] O. Pastor, E. Insfrán, G. Quiles y J.M. Barberá. Object-Oriented ConceptualModeling Techniques to Design and Implement a sound and robust ORACLEEnvironment. En Oracle Open World 97. European Oracle Users Group Con-ference (EOUG’97). Viena, Austria, April 1997.

[173] O. Pastor, V. Pelechano, B. Bonet y I. Ramos. An Object Oriented Metho-dological Approach for Making Automated Prototyping Feasible. En Databaseand Expert Systems Applications (DEXA’96), páginas 29–39. Springer-Verlag,Zurich, Switzerland, September 1996. LNCS (1134).

[174] O. Pastor, V. Pelechano, B. Bonet y I. Ramos. OO-Method versión 2: UnaMetodología de Análisis y Diseño Orientado a Objetos. DSIC II/1/96, DSIC -Universidad Politécnica de Valencia, Valencia, España, Enero 1996.

[175] O. Pastor, V. Pelechano, E. Insfrán y J. Gómez. From Object Oriented Con-ceptual Modeling to Automated Programming in Java. En 17th InternationalConference on Conceptual Modeling (ER’98), páginas 183–196. Springer-Verlag,Singapore, November 1998. LNCS (1507).

[176] O. Pastor y I. Ramos. OASIS version 2 (2.2): A Class-De…nition Language toModel Information Systems. Servicio de Publicaciones Universidad Politécnicade Valencia, Valencia, España, 1995. SPUPV-95.788.

[177] O. Pastor, I. Ramos y J. Iborra. El Proyecto CASE / OO-Method;Antecedentes,Características y Objetivos. ITI-ITE 96-2, Instituto Tec-nológico de Informática (ITI), Valencia, España, 1996.

[178] V. Pelechano, E. Insfrán y O. Pastor. El Metamodelo OO-Method y su Re-positorio Relacional. DSIC - Universidad Politécnica de Valencia, 1998:DSIC–II/16/98, Valencia, España Mayo.

[179] V. Pelechano, O. Pastor y E. Campos amd M. Albert. Dynamic Integrity Cons-traints Checking in an Automatic Software Production Method. En ArgentinianSymposium on Software Engineering - ASSE 2001, páginas 161–176. 2001.

[180] V. Pelechano, O. Pastor, N. García y S. Ramírez. Implementación y compro-bación de restricciones de integridad dinámicas en entornos de programaciónorientados a objetos. En II Jornadas Nacionales de Ingeniería de Software,páginas 101–116. San Sebastián, España, Septiembre 1997.

[181] B. Pernici. Objects with Roles. En IEEE/ACM Conference on O¢ce Informa-tion Systems, páginas 205–215. Cambridge, Mass, 1990.

[182] Planeta-Agostini. Dicccionario planeta-agostini, 2000.

[183] H.H.III. Porter. Separating the subtype hierarchy from the inheritance of im-plementation. Journal of Object-Oriented Programming, 4(9):20–29, 1992.

[184] W. Pree. Design Patterns for Object Oriented Software Development. Addison-Wesley, Reading, Mass, 1995.

376 BIBLIOGRAFÍA

[185] G. Preuner, S. Conrad y M. Schre‡. View Integration of Behavior in Object-oriented Databases. Data and Knowledge Engineering, 36:153–183, 2001.

[186] J.W. Rahayu, E. Chang, T.S. Dillon y D. Taniar. A Methodology for Trans-forming Inheritance Relationships in an Object-Oriented Conceptual Model toRelational Tables. Information and Software Technology, 42:571–592, 2000.

[187] R. K. Raj y H. M. Levy. A Compositional Model for Software Reuse. TheComputing Journal, 32(4):312–322, 1989.

[188] I. Ramos, O. Pastor y J.H. Canós. On the use of Algebras as Semantic Domainsof Object Societies. En Actas del 3rd International Workshop of the DeductiveApproach for DB and IS. Roses, Cataluña, 1992.

[189] D. A. Rawsthorne. A Pattern Language for Requirements Analysis. Informetécnico, BDM Air Safety Management Company, University of Denver, 1997.

[190] T. Reenskaug, P. Wold y O.A. Lehne. Working with Objects - The OOramSoftware Engineering Method. 1996.

[191] D. W. Renouf y B. Henderson-Sellers. Incorporating Roles into MOSES. EnTOOLS 15. Melbourne, Australia, 1996.

[192] J. Richardson y P. Schwarz. Aspects: Extending Objects to Support Multiple,Independent Roles. SIGMOD Record, 20(2):298–307, 1991.

[193] J.J. Rodríguez, Y. Crespo y J.M Marqués. On Transformation strategies fromMultiple Inheritance to Single Inheritance. A Comparative Approach. En IVJornadas de Trabajo MENHIR, páginas 59–63. Sedano, Burgos, Mayo 1999.

[194] C. Rolland, J. Stirna, N. Prekas, P. Loucopoulos, A. Persson y G. Grosz. Eva-luating a Patterns Approach as an Aid for the Development of OrganizationalKnowledge: An Empirical Study. En L. Bergman B. Wangler, editor, Interna-tional Conference on Advanced Information Systems Engineering, CAiSE 2000,páginas 176–191. Springer-Verlag, 2000. Lecture Notes in Computer Science1789.

[195] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy y W. Lorensen. Object Orien-ted Modeling and Design. Prentice-Hall, 1991.

[196] G. Saake, P. Hartel, R. Jungclaus, R. Wieringa y R. Feenstra. InheritanceConditions for Object Life Cycle Diagrams. En EMISA Workshop. 1994.

[197] P. Sánchez. Animación de Especi…caciones OASIS mediante Redes de PetriOrientadas a Objeto. Tesis Doctoral, Departamento de Sistemas Informáticosy Computación, Universidad Politécnica de Valencia, Enero 2000.

[198] D. Schmidt, M. Fayad y R.E. Johnson. Software Patterns. Communications ofthe ACM, 39(10):37–39, 1996.

BIBLIOGRAFÍA 377

[199] A. Schoenfeld. Domain Speci…c Patterns: Conversions, Persons and Roles,and Documents and Roles. En Proceeding of the 1996 Conference on PatternsLanguages of Programming (PLOP’96). Washington University, Department ofComputer Science, 1996.

[200] E. Sciore. Object Specialization. ACM Transactions on Information Systems,7(2):103–122, 1989.

[201] SDL:. ITU-T Recommendation Z.100, Languages for telecommunications ap-plications: Speci…cation and Description Language. Informe técnico, Ginebra,1999.

[202] B. Selic, G. Gullekson y P.T. Ward. Real-Time Object-Oriented Modeling. JohnWiley and Sons, New York, 1994.

[203] A. Sernadas, C. Sernadas y H.D. Ehrich. OO Speci…cation of Databases: AnAlgebraic Approach. En W. Kent P. M. Stocker, editor, VLDB’87, páginas107–116. Morgan Kau¤mann, 1987.

[204] A. Sernadas, C. Sernadas y H.D. Ehrich. OBLOG-Object Oriented Logic : aninformal introduction. Technical report, Lisboa, 1991.

[205] M. Shaw. Patterns for Software Architectures, páginas 453–462. Patterns Lan-guages of Program Design. Addison-Wesley, Reading, MA, J. Coplien and D.Schmidt edición, 1995.

[206] S. Shlaer y SJ. Mellor. Object Lifecycles: Modeling the World in States.Yourdon-Press, 1992.

[207] S. Shlaer y S.J. Mellor. Recursive Design of an Application-Independent Archi-tecture. IEEE Software, páginas 61–72, January 1997.

[208] A.S. Da Silva, A.H.F. Laender y M.A Casanova. On the Relational Representa-tion of Complex Specialization Structures. Information Systems, 25(6):399–415,2000.

[209] M. Snoeck y G. Dedene. Generalization/specialization and Role in Object orien-ted Conceptual Modeling. Data and Knowledge Engineering, 12(2):171–195,1996.

[210] M. Snoeck y G. Dedene. Existence Dependency: The Key to Semantic IntegrityBetween Structural and Behavioral Aspects of Object Types. IEEE Transac-tions on Software Engineering, 24(4):233–251, April 2001.

[211] J. L. Sourrouille. UML Behavior: Inheritance and Implementation in CurrentObject-Oriented Languages. En LNCS 1723, editor, UML ’99 - The Uni…edModeling Language, Beyond the Standard, páginas 457–472. Springer, 1999.

[212] J. F. Sowa. Conceptual Structures: Information Processing in Mind and Ma-chine. Addison-Wesley, 1984.

[213] S. Spaccapietra, C. Parent y E. Zimányi. Modeling Time from a ConceptualPerspective. En CIKM 98, páginas 432–440. 1998.

378 BIBLIOGRAFÍA

[214] F. Steimann. On the Representation of Roles in Object-oriented and ConceptualModeling. Data and Knowledge Engineering, 35:83–106, October 2000.

[215] F. Steimann. Role = Interface: A Merger of Concepts. Journal of ObjectOriented Programming (JOOP), 14(4):23–32, Noviembre 2001.

[216] L. A. Stein. Delegation is Inheritance. En Proceedings of OOPSLA 87, páginas138–146. ACM Press, October 1987.

[217] A. Steiner y M. C. Norrie. Temporal Object Role Modelling. En Proceedingsof 9th Conference on Advanced Information Systems Engineering (CAiSE’97),páginas 243–258. Springer-Verlag, Barcelona, Spain, June 1997. LNCS (1250).ISBN: 3-540-63107-0.

[218] M. Stumptner y M. Schre‡. Behavior Consistent Inheritance in UML. En A.H.F.Laender, S.W. Liddle y V.C. Storey, editores, ER2000 Conference, páginas 527–542. Springer-Verlag, Heidelberg, 2000. LNCS 1920.

[219] J. Su. Dynamic Constraints and Object Migration. En G.M. Lohman, A. Ser-nadas y R. Camps, editores, Proceedings of the 17th International Conferenceon Very Large Databases, páginas 233–242. VLDB Endowment Press, 1991.

[220] C. Szyperski. Component Software. Beyond Object-Oriented Programming.Addison-Wesley, 1998.

[221] A. Taivalsaari. Object-oriented Programming with Modes. Journal of Object-Oriented Programming, 6(3):25–32, June 1993.

[222] A. Taivalsaari. On the Notion of Inheritance. ACM Computing Surveys,28(3):438–479, September 1996.

[223] T.J. Teorey, D. Yang y J.Fry. A Logical Design Methodology for RelationalDatabases using the Extended Entity-Relationship Model. ACM ComputingSurveys, 18(2):197–222, June 1986.

[224] W. Tepfenhart y J. Cusick. A Uni…ed Object Topology. IEEE Software, páginas31–35, May/June 1997.

[225] The Precise UML Group. http://www.puml.org/. Web Site.

[226] TogetherSoft. Together 5.0 CASE Tool, http://www.togethersoft.com/. WebSite.

[227] J. Torres. Especi…caciones Orientadas a Objetos Basadas en Restricciones: Pro-totipado Basado en un Lenguaje Orientado a Procesos. Tesis Doctoral, Depar-tamento de Lenguajes y Sistemas Informáticos, Universidad de Sevilla, 1997.

[228] J.A. Troyano. Herencia y Clasi…cacion en un lenguaje de especi…cacion orien-tado a objetos. Tesis Doctoral, Departamento de Lenguajes y Sistemas Infor-máticos. Universidad de Sevilla, 1998.

[229] J.A. Troyano, M. Mejías, J. Torres y M. Toro. Extensiones al sistema de clasi-…cación de UML. Computación y Sistemas, 3(3):202–213, 2000.

BIBLIOGRAFÍA 379

[230] P. Wegner. Concepts and Paradigms of Object-Oriented Programming. ACMOOPS Messenger, 1(1):7–87, 1990.

[231] P. Wegner y B. Zdonik. Inheritance as an incremental modi…cation mechanismor what like is and isn’t like. En S. Gjessing, editor, ECOOP ’88: EuropeanConference on Object-Oriented Programming,, páginas 55–77. Springer-Verlag,Berlin, 1988. Lecture Notes in Computer Science 276.

[232] C. Weir. Pattern Languages of Program Design 3, capítulo Patterns for Des-igning in Teams, páginas 487–501. Software Patterns Series. Addison-Wesley,robert martin, dirk riehle and frank buschmann edición, 1998.

[233] C.A. Welty y D.A. Ferrucci. Instances and Clases in Software Engineering.Intelligence, Summer 1999:24–28, 1999.

[234] B. Whitenack. Pattern Languages for Program Design, capítulo RAPPeL: ARequirements Analysis Process Pattern Language for Object Oriented Develop-ment. Software Patterns Series. Addison Wesley Publishing Company, MenloPark, California, James C. Coplien and Douglas C. Schmidt edición, 1995.

[235] R. Wieringa. Algebraic Foundations for Dynamic Conceptual Models. TesisDoctoral, Dept. of Mathematics and Computer Science. Vrije Universiteit, Ams-terdam, May 1990.

[236] R. Wieringa y E.Dubois. Integrating Semi-formal and Formal Software Speci…-cation Techniques. Information Systems, 19(4):33–54, 1994.

[237] R. Wieringa, W. Jonge y P. Spruit. Roles and Dynamic Subclasses: A ModalLogic Approach. Informe técnico, Vrije Universteit, The Netherlands, 1995.

[238] R. Wieringa, W. Jonge y P. Spruit. Using Dynamic Classes and Role Classes toModel Object Migration. Theory and Practice of Object Systems, 1(1):61–83,1995.

[239] R. Wieringa, R. Jungclaus, P. Hartel, T. Hartmann y G. Saake. OMTROLLObject Modeling in TROLL. En G.Koschorrek (eds.) Udo W. Lipeck, editor,International Workshop on Information Systems - Correctness and Reusability(IS-CORE’93). Hannover, September 1993.

[240] R. Wirfs-Brock, B. Wilkerson y L. Wiener. Designing Object Oriented Software.Englewood Cli¤s, Nj. Prentice-Hall, 1990.

[241] P. Wohed. Conceptual Patterns for Reuse in Information Systems Analysis. EnL. Bergman B. Wangler, editor, CAiSE 2000, LNCS 1789, páginas 157–175.Springer-Verlag, Berlín, Heidelberg, 2000.

[242] R.K. Wong, H.L. Chau y F.H. Lochovsky. Dynamic Knowledge Representationin DOOR. En N. Pissinou K. Makki X. Wu, J. Tsai, editor, Proceedings ofthe 1997 IEEE Knowledge and Data Engineering Exchange Workshop, páginas89–96. IEEE Computer Society, Los Alamitos, 1997.

380 BIBLIOGRAFÍA

[243] E. Yourdon, K. Whitehead, J. Thomann, K. Oppel y P. Nevermann.MainstreamObjects: An Analysis and Design Approach for Business. Prentice-Hall, 1995.

[244] S. B. Zdonik. Why Properties are Objects, or Some Re…nements of "is-a". EnACM/IEEE Fall Joint Computer Conference, páginas 41–47. November 1986.

[245] L. Zhao y T. Foster. Pattern Languages of Program Design 3, capítulo A PatternLanguage of Transport Systems (Point and Route), páginas 409–430. SoftwarePatterns. Addison-Wesley, Robert Martin, Dirk Riehle and Frank Buschmannedición, 1998.

[246] L. Zhao y T. Foster. Modeling Roles With Cascade. IEEE Software, páginas86–93, September/October 1999.

Technical University of Valencia · iv Agradecimientos Quiero agradecer a cada uno de los miembros...

Documents

Transcript of Technical University of Valencia · iv Agradecimientos Quiero agradecer a cada uno de los miembros...