aplicaciones ), acrónimo del modelado - ucol.mx · ingeniería de aplicaciones dirigida por...

Ingeniería de aplicaciones dirigida por modelos y basada en técni-cas de líneas de productos software en el contexto de la MDE (del inglés Model-Driven Engineering) presenta la aproximación BOM (del inglés Baseline-Oriented Modeling), acrónimo del modelado orientado a la Baseline (repositorio de software reutilizable). BOM es un framework que genera aplicaciones software en un dominio específico, dirigido por modelos y que utiliza técnicas de líneas de productos software. Este proceso implica, por un lado, construir una Baseline que contenga todos los assets necesarios para obte-ner todos los productos de una línea de productos software, y por otro lado, realizar el plan de producción de la misma. BOM es ilus-trado mediante el dominio de los sistemas expertos que realizan tareas de diagnósticos.

Inge

nier

ía d

e ap

licac

ione

s

INGENIERÍA DEAPLICACIONES

dirigida por modelos y basada en técnicasde líneas de productos software

María Eugenia Cabello EspinosaIsidro Ramos Salavert

María

Eug

enia

Cabe

llo E

spino

saIsi

dro R

amos

Sala

vert

dirig

ida

por m

odel

os y

bas

ada

en té

cnic

as d

e lín

eas

de p

rodu

ctos

sof

twar

e

María Eugenia Cabello EspinosaDoctora en programación declarativa e ingeniería de la programación por la Universitat Politècnica de València. Sus intereses de investigación se centran en los sistemas expertos, las líneas de productos software, el desarrollo de software dirigido por modelos y las ontologías.

Isidro Ramos SalavertDoctor en ciencias físicas por la Universidad Complutense de Madrid. Sus principales intereses de investigación en la ingeniería en software están relacionados con las líneas de productos software, el desarrollo de software dirigido por modelos, las arquitecturas software y la transforma-ción de modelos.

Ingeniería de aplicaciones dirigida por modelos y basada en técnicas

de líneas de productos software

Universidad de ColimaMtro. José Eduardo Hernández Nava, RectorMtro. Christian Jorge Torres Ortiz Zermeño, Secretario GeneralLic. Jorge Silva Torres, Coordinador General de Comunicación SocialMtra. Gloria Guillermina Araiza Torres, Directora General de Publicaciones

Ingeniería de aplicaciones dirigida por modelos y basada en técnicas

de líneas de productos software

María Eugenia Cabello Espinosa Isidro Ramos Salavert

© Universidad de Colima, 2016 Avenida Universidad 333 C.P. 28040, Colima, Colima, México Dirección General de Publicaciones Teléfonos: (312) 316 10 81 y 316 10 00, extensión 35004 Correo electrónico: [email protected] www.ucol.mx

ISBN: 978-607-8356-72-0

Derechos reservados conforme a la leyImpreso en México / Printed in Mexico

Proceso editorial certificado con normas Iso desde 2005Dictaminación y edición registradas en el Sistema Editorial Electrónico Pred Registro: LI-016-12 Recibido: Mayo de 2012 Publicado: Abril de 2016

Libro realizado con recursos PEF.

Índice

Parte I: IntroducciónIntroducción general ....................................................................9

Capítulo I: Tendencias actuales en la ingeniería de software .................. 19Ingeniería dirigida por modelos .................................................... 19

Arquitectura dirigida por modelos .....................................22 mda y las vistas de arquitectura software ............................. 24Líneas de productos software ........................................................ 26

Repositorio de la línea de productos software: La Baseline .........................................................................31Arquitectura de la línea de productos software ...................32Aproximación para los procesos de la ingeniería de la línea de productos software ........................................34Variabilidad en las líneas de productos software .................37

Representación de la variabilidad .............................39 Primera clasificación para representar la variabilidad: lenguajes de modelado ...........41 Segunda clasificación para representar la variabilidad: lenguajes textual y gráfico ......42Gestión de la variabilidad ........................................46

Herramientas utilizadas en la línea de productos software .............................................................................48

Modelo prisma ..........................................................................52Sistemas expertos .......................................................................56Estándares de la omg utilizados en bom como técnicas de modelado ..............................................................................64

Metamodelo de la ingeniería de procesos de software .........65Especificación de activos reutilizables ................................66Notación para el modelado de procesos de negocio ............67Lenguaje de modelado unificado ........................................68Facilidad de meta-objetos...................................................69

Conclusiones................................................................................ 70

Parte II: Preliminares

Capítulo II: Arquitecturas software de la línea de productos ................ 75Arquitectura de los sistemas expertos ............................................ 77Arquitectura genérica y arquitecturas base de los sistemas expertos de diagnóstico ................................................................ 79Conclusiones................................................................................ 86

Capítulo III: El diagnóstico: La variabilidad del dominio ..................... 87Casos de estudio........................................................................... 90

Diagnóstico médico ...........................................................90Diagnóstico de desastres ....................................................92Diagnóstico de candidatos a beca .......................................94Diagnóstico de programas educativos.................................95Diagnóstico televisivo ........................................................96

Análisis de las características asociadas al diagnóstico .................... 99Análisis de las características involucradas en el proceso del diagnóstico ..............................................99Análisis de las características involucradas en los requisitos del usuario .............................................100Análisis de las características del dominio .........................101Análisis de las características del dominio de la aplicación ................................................................105

Conclusiones.............................................................................. 107

Capítulo IV: Los sistemas expertos de diagnóstico: La funcionalidad del dominio ................................................... 109

Variabilidad en la estructura de los sistemas expertos de diagnóstico ............................................................................ 112Variabilidad en el comportamiento de los sistemas expertos de diagnóstico ............................................................................ 116

Procesos de inferencia ......................................................116Proceso de inferencia estático .................................117Proceso de inferencia dinámico ..............................121

Conclusiones.............................................................................. 124

Parte III: La aproximación Baseline-Oriented Modeling

Capítulo V: Gestión de la variabilidad a través de bom ....................... 127Primera variabilidad en bom....................................................... 130Segunda variabilidad en bom ...................................................... 132Conclusiones.............................................................................. 141

Capítulo VI: Aproximación bom-eager: Desarrollo de la línea de productos software mediante técnicas ad hoc utilizadas en bom para el tratamiento de la variabilidad .... 143

Tratamiento de la primera variabilidad: de la arquitectura genérica a las arquitecturas base .................................................. 143Tratamiento de la segunda variabilidad: de la arquitectura base a las arquitecturas prisma ................................................... 146Desarrollo de los sistemas expertos de diagnóstico en bom ......... 148Conclusiones.............................................................................. 152

Capítulo VII: Aproximación bom-lazy: Desarrollo de la línea de productos software mediante técnicas de transformación de modelos utilizadas en bom para el tratamiento de la variabilidad ........................................ 153

Vistas de los sistemas expertos de diagnóstico en bom .............. 153 Metamodelos de las vistas software ........................................... 154 Relaciones entre metamodelos y transformaciones entre modelos........................................................................... 158

Relaciones entre vistas software ........................................161Transformaciones entre modelos ......................................164

Proceso bom para la transformación de modelos ........................ 167Conclusiones.............................................................................. 169

Capítulo VIII: Modelado del proceso de desarrollo de la línea de productos software en bom .................................................... 171

Proceso para crear la línea de productos software ........................ 171Ingeniería del dominio: Creación de la Baseline ......................... 178

Análisis del domino .........................................................179Desarrollo de los componentes básicos reutilizables .........180

Ingeniería de la aplicación: Ejecución del plan de producción .................................... 203

Plan de producción de la línea de productossoftware en la aproximación bom-eager ..........................204

Caracterización del producto .................................206Síntesis del producto .............................................210Construcción del producto ....................................213

Plan de producción de la línea de productos software en la aproximación bom-lazy ............................214

Ejecución del sistema ................................................................. 216Conclusiones.............................................................................. 216

Parte IV: Conclusiones

Conclusiones generales ......................................................................... 219

Bibliografía ....................................................................................... 233

Acrónimos .......................................................................................... 245

Parte I Introducción

Ilustr

ació

n de

Víct

or O

dín

Gar

cía R

odríg

uez.

11

Introducción general

Seis honrados servidores me enseñaron cuanto sé; sus nombres son cómo, cuándo, dónde,

qué, quién y por qué.Rudyard Kipling

El desarrollo de sistemas, actualmente, se complica cada vez más debido a una serie de factores como, por ejemplo, la apa-

rición de nuevas tecnologías (internet e intranet), la interconexión de varios sistemas y plataformas, la necesidad de integrar viejos sistemas aún válidos (Legacy Systems), la adaptación personalizada del software a cada tipo de usuario, las necesidades específicas de un sistema y las diferentes plataformas de implementación. Esta situación obliga a que se requieran, en cortos periodos, múltiples versiones de la misma o parecida aplicación; por ello, la inge-niería del software debe proporcionar herramientas y métodos que permitan desarrollar una familia de productos con distintas capacidades y adaptables a situaciones variables y no a un único producto.

Ante esta situación surge el concepto Líneas de Produc-tos Software (spl , por sus siglas en inglés [Software Product Li-nes]) (www.softwareproductlines.com), con la finalidad de con-trolar y minimizar los altos costos que implica desarrollar soft-ware. De esta manera se crea un diseño que puede ser comparti-do por todos los miembros que conforman una familia de pro-gramas (la arquitectura básica). Así pues un diseño, hecho explí-citamente para un producto, beneficia al software común y pue-

12

Introducción

de usarse en diferentes productos, lo cual reduce los gastos ge-nerales y el tiempo para construir nuevos productos. Asimismo, se destaca la importancia de los planes de producción, preferi-blemente automatizables, al ofrecer tiempos y costos de ejecu-ción predecibles.

Por otro lado, en la actualidad existen una gran cantidad y variedad de trabajos relacionados con el desarrollo de sistemas software complejos: modelos arquitectónicos, componentes, as-pectos y lenguajes para definir arquitecturas. Todo ello persigue un consenso, aún no logrado, en los conceptos básicos —y su precisión— que define a este tipo de los sistemas software com-plejos así como la metodología que se aplicará para su desarrollo.

Entre los trabajos realizados para desarrollar software complejo surge el modelo prisma (Pérez, 2006), el cual presenta ventajas en la construcción de modelos arquitectónicos comple-jos; además, en el marco de la calidad controlada, cubre el hueco que existe en el modelado de sistemas software altamente recon-figurable y reutilizable. El modelo arquitectónico prisma integra dos aproximaciones: el Desarrollo de Software Basado en Com-ponentes (cbsd, por sus siglas en inglés [Component-Based Soft-ware Development]) (Szyperski, 1998) y el Desarrollo de Soft-ware Orientado a Aspectos (aosd, por sus siglas en inglés [As-pect-Oriented Software Development]) (aosd, 2001). Esta inte-gración se consigue al definir los elementos arquitectónicos me-diante aspectos. De esta forma dicho modelo, además de definir los elementos arquitectónicos básicos y especificar su sintaxis y semántica, también especifica los aspectos que detallan las pro-piedades necesarias de cada uno de éstos.

Según lo anterior, y ante diversas necesidades (crear sistemas en diferentes dominios, minimizar los costos de producción al reutilizar paquetes de software, generar un código automáticamente con la finalidad de incrementar la productividad y la calidad así como disminuir el tiempo al mer-

13

María Eugenia Cabello Espinosa | Isidro Ramos Salavert

cado, construir un sistema de forma sencilla mediante ontolo-gías de dominio que faciliten la comunicación hombre-máqui-na, desarrollar sistemas independientes de plataforma, los cuales se analicen desde la perspectiva del problema y no de la solución, también, que sean aplicables a diversos dominios, entre otros), se escribe este libro que plantea cómo generar automáticamente sistemas software en un dominio concreto.

Sin embargo, “nada sale de la nada”, por lo que la gene-ración automática de sistemas software es posible si existe al-gún framework que lo respalde. Ante esto, el Grupo de Gestión de Objetos (omg, por sus siglas en inglés [The Object Manage-ment Group]) (http://www.omg.org), dentro de la tendencia de la Ingeniería Dirigida por Modelos (mde, por sus siglas en in-glés [Model Driven Engineering]) (Kent, 2002) —que promue-ve el uso de los modelos, sus relaciones y sus transformaciones como artefactos de primera clase a partir de los cuales se ge-neran códigos—, propone la Arquitectura Dirigida por Mode-los (mda, por sus siglas en inglés [Model-Driven Architecture]) (mda, 2003), que defiende el uso de estándares y potencia la in-dependencia de plataforma en los procesos que desarrollan soft-ware dirigidos por modelos, como una nueva forma de generar aplicaciones.

En este contexto, este libro presenta la aproximación de-nominada Baseline-Oriented Modeling (bom): un framework que genera aplicaciones en un dominio específico, basada en Línea de Productos Software.

bom ha usado la iniciativa de la mda para construir mo-delos de dominio y su posible transformación en modelos arqui-tectónicos, así como la posibilidad de automatizar la transfor-mación que especifica cómo se convierten los modelos en una aplicación ejecutable. Sin embargo, no se automatiza todo, es necesaria la intervención de un usuario que interaccione con el sistema y a su vez aporte información sobre la variabilidad del

14

Introducción

dominio a un alto nivel de abstracción. El usuario de bom, en el rol del ingeniero de la aplicación, para desarrollar un sistema concreto, aportará al sistema la información mínima necesaria del dominio particular.

Asimismo, bom utiliza técnicas de la mda —para el mo-delado— con un alto nivel de abstracción y captura la informa-ción del dominio a través de modelos conceptuales que confor-man a sus respectivos metamodelos al especificar la variabilidad y la funcionalidad separadamente. Además, bom utiliza técni-cas de las spl para sistematizar el re-uso de productos software, con el fin de generar automáticamente sistemas con arquitectu-ras software prisma. Con ello, bom integra estos diferentes espa-cios tecnológicos con el objetivo de disminuir la complejidad del problema en el desarrollo del software.

Por otro lado, una clase de sistemas que actualmente ge-nera interés son los Sistemas Expertos (es, por sus siglas en inglés [Expert Systems]) (Turban y Aronson, 2001), dado que son siste-mas inteligentes que capturan el conocimiento de los expertos y tratan de imitar sus procesos de razonamiento cuando resuelven un problema en un cierto dominio. No obstante, el desarrollo de este tipo de sistemas es complejo, ya que los elementos bási-cos que conforman su arquitectura varían tanto en su comporta-miento como en su estructura. Por consiguiente, existe la nece-sidad de soportarlos adecuadamente.

Las metodologías y aplicaciones desarrolladas de los siste-mas expertos forman una amplia categoría de productos relati-vos a la investigación, los cuales ofrecen ideas y soluciones a di-chos sistemas en dominios específicos.

Asimismo, debe señalarse la importancia que han cobra-do en los últimos años los sistemas expertos que realizan tareas de diagnóstico. Además, se considera que existen diversas razo-nes para que el desarrollo de este tipo de sistemas inteligentes es-

15


tén más inclinados al paradigma de las spl que al software tra-dicional:

• La primera razón es la heterogeneidad de las aplicaciones del dominio, dado que, en cada caso de estudio, las características del diagnóstico difieren de un caso al otro. La variabilidad de las spl permite tratar esa heterogeneidad.

• La segunda razón se debe a que los sistemas de diagnóstico en dominios específicos han sido tratados de forma particular para diagnosticar un caso de estudio, sin embargo las aplica-ciones del diagnóstico involucran una amplia gama de domi-nios y áreas de aplicación.

• La tercera razón es la rapidez con la que cambia la tecnología. La spl facilita el desarrollo de los productos en distintas plata-formas y su uso en distintas tecnologías.

• La cuarta razón se basa en el propio proceso de inferencia del diagnóstico, el cual cambia según el dominio de aplicación, por lo que varias estrategias de razonamiento están implicadas en los procesos del diagnóstico. La spl permite considerar estas estra-tegias de razonamiento como una más de sus “características”.

• Finalmente, la quinta razón es que el desarrollo de software ba-sado en componentes y la ingeniería de la línea de productos comparten los mismos fines desde diferentes puntos de vista y, por lo tanto, se pueden obtener beneficios en su integración (Atkinson, Bayer y Muthig, 2000).Por ello, para ilustrar bom se eligió el dominio de los

sistemas expertos que realizan diagnóstico o Sistemas Expertos de Diagnóstico (des, por sus siglas en inglés [Diagnostic Expert Systems]).

Con el fin de conocer la variabilidad representada por las características particulares y generales de dicho dominio, se rea-lizó un estudio de campo sobre los sistemas expertos que realizan tareas de diagnóstico, y asimismo un estudio de campo del diag-nóstico, el cual consideró cinco casos de estudio que involucran al diagnóstico médico, el diagnóstico de programas de posgra-do (diagnóstico educativo), la asignación de becas (diagnóstico

16

Introducción

educativo), la decisión de transmitir un video (diagnóstico tele-visivo) y el diagnóstico de emergencias. Como resultado de este análisis, el cual se basa en técnicas de la mda y de la spl, el mo-delo prisma, y la estructura y funcionamiento de los des, se es-pecificó el proceso para desarrollar una spl de sistemas de diag-nóstico.

Dicho proceso implica principalmente modelar la Base-line (como repositorio de todos los assets necesarios para con-struir un producto de la spl) y definir las transformaciones de modelos como ejecución del plan de producción de la spl.

Explícitamente, para el desarrollo de bom se realizaron las siguientes acciones:

• En primer lugar, gestionar la variabilidad en bom.• En segundo lugar, desarrollar la spl en niveles de abstracción de

modelado, a través de la aproximación bom-eager (mediante técnicas ad-hoc para el tratamiento de la variabilidad) y de la aproximación bom-lazy (mediante técnicas de transformación de modelos para el tratamiento de la variabilidad).

• En tercer lugar, modelar en el estándar denominado Metamo-delo de Ingeniería de Procesos de Software (spem, por sus si-glas en inglés [Software Process Engineering Metamodel] (spem, 2006), el proceso para desarrollar la spl en las fases de la inge-niería del dominio y de la ingeniería de la aplicación (ejecución del plan de producción). De esta acción se deriva la siguiente: » Modelar la Baseline. Crear una Baseline mediante el están-

dar denominado Especificación de Recursos Reutilizables (ras, por sus siglas en inglés [Reusable Asset Specification] (ras, 2005), para empaquetar e incorporar en ella todos los assets de su contenido. Explícitamente se modelan todos los assets contenidos en la Baseline, incluyendo el plan de pro-ducción de la spl, para lo cual se llevará a cabo lo siguiente:

» Modelar los requisitos y la funcionalidad de los sistemas ex-pertos, así como de la variabilidad de un dominio específi-co, mediante Modelos Independientes de Computación (cim, por sus siglas en inglés [Computer Independent Model]).

17


» Modelar la funcionalidad de los se así como la variabili-dad de un dominio específico y de sus dominios de apli-cación en modelos conceptuales independientes, de don-de se abstraerán de los detalles tecnológicos de la platafor-ma de implementación, mediante Modelos Independientes de Plataforma (pim, por sus siglas en inglés [Platform Indepen-dent Model]), y al definir transformaciones entre modelos.

» Modelar la ejecución del plan de producción de la spl. Com-binar las especificaciones contenidas en el pim con los deta-lles de la plataforma de implementación, originando Mo-delos Específicos de Plataforma (psm, por sus siglas en inglés [Platform Specific Model]). De esta manera bom, en inte-racción con el usuario, selecciona los assets que conforman la base de los productos originados por la spl y crea las ar-quitecturas prisma correspondientes.

• En cuarto y último lugar, aplicar bom en distintos casos de es-tudio relativos a un dominio específico (los des), y en dos do-minios de aplicación significativos (el diagnóstico médico y el diagnóstico educativo), que ayuden a mostrar cómo bom ges-tiona la variabilidad y cómo se generan dichos sistemas (has-ta su ejecución).

19

Capítulo I

Tendencias actuales en la ingeniería de software

No sabe más el que más cosas sabe, sino el que sabe las que más importan.

Bernardino Rebolledo

En este capítulo se presentan las tendencias actuales más im-portantes en la ingeniería de software, enmarcados sobre los

espacios tecnológicos usados en este trabajo y que son los funda-mentos en los que se basa el mismo.

Ingeniería dirigida por modelos La Ingeniería Dirigida por Modelos (mde, por sus siglas en in-glés [Model Driven Engineering]) (Kent, 2002) constituye una aproximación, para el desarrollo de sistemas software, basada en la separación de la especificación de la funcionalidad del sistema de su implementación, en plataformas específicas. Dicha inge-niería busca elevar el nivel de abstracción al destacar el modela-do conceptual y el papel de los modelos en el desarrollo de soft-ware.1

1 Sobre el tema, en la literatura pueden encontrarse los términos Model-Driven Software Development y Model-Driven Engineering como sinónimos, sin embargo el presente trabajo usará este último.

20


En el paradigma de la mde, los modelos constituyen los elementos centrales en el desarrollo de software, al contrario que en el enfoque tradicional que está más centrado en la imple-mentación. Los modelos se expresan mediante conceptos más abstractos que los utilizados en los lenguajes de programación, y la descripción del sistema es independiente de la tecnología uti-lizada.

Con ello los modelos son fácilmente especificados y su mantenimiento es más sencillo, lo cual sirve de guía para desa-rrollar el sistema por medio de la tecnología aplicada. Uno de los objetivos de la mde es automatizar este proceso. Los modelos permiten que se capture el conocimiento, así como la lógica del negocio, independientemente de la tecnología utilizada para im-plementar los sistemas, con el fin de proteger la inversión frente a cambios y evolución de la tecnología.

En la mde los modelos, como entidades de primera clase, son usados en todo el ciclo de vida de la ingeniería, el cual es vis-to como una cadena de transformación de modelos. El objetivo principal de la mde es usar modelos para incrementar el nivel de abstracción, en el cual los desarrolladores de aplicaciones crean software para simplificar y formalizar las actividades y tareas que comprende el ciclo de vida del software.

Asimismo, en la mde, un sistema software se crea a través de la definición de diferentes modelos en varios niveles de abs-tracción, donde cada modelo es una versión más refinada de los modelos definidos en el nivel de abstracción superior. Los refina-mientos continúan hasta que se obtiene la implementación eje-cutable del sistema.

La derivación de los modelos con determinado nivel de abstracción respecto a modelos de nivel superior se realiza por medio de transformaciones. Una transformación de modelos es-pecifica cómo un modelo de salida se construye basado en los elementos de uno o varios modelos de entrada. Con los len-

21

Capítulo I. Tendencias actuales en la ingeniería de software

guajes de transformación de modelos se automatiza el proceso para derivar un modelo de otro modelo.

Por ello, en la mde pueden identificarse como concep-tos básicos los siguientes: modelos, transformación de modelos, metamodelos y meta-metamodelos de acuerdo con Meta Object Facility (mof, por sus siglas en inglés [Meta Object Facility]) de la omg. Las relaciones entre modelos, metamodelos y meta-me-tamodelos se presentan en la figura 1. Una vista de un sistema puede ser representada por un modelo. Cada modelo debe con-formar a su metamodelo, el cual debe escribirse en el lenguaje de dicho metamodelo. De la misma manera, el metamodelo debe conformar a su meta-metamodelo que se describe por el mismo.

Figura 1. Nociones básicas en la mde

Fuente: Adaptada de Bézivin (2005).

Actualmente existen dos iniciativas principales y diferen-tes de la mde. Una de éstas es el enfoque de la omg, a través de la estrategia mda, y la otra iniciativa es la de Microsoft, a través de las Fábricas de Software (sf, por sus siglas en inglés [Soft-ware Factories]) y de los Lenguajes Específicos de Dominio (dsl,

22


por sus siglas en inglés [Domain Specific Languages]) (Greenfield, Short, Cook, et al., 2004).

Arquitectura dirigida por modelosLa Arquitectura Dirigida por Modelos (mda, por sus siglas en inglés [Model-Driven Architecture]) [mda, 2003] define tres ni-veles conceptuales de modelado, en diferentes niveles de abstrac-ción. Éstos pueden ser modelos formales, y por lo tanto, enten-dibles por la computadora. Cabe señalar que el framework bom se corresponde directamente con estas ideas.

• En el primer nivel de abstracción se modelan los requisitos del sistema mediante Modelos Independientes de Computación (cim) que sirven de puente entre los expertos del dominio y los desarrolladores que afrontan la realización del sistema. Los cim no representan detalles del sistema dependientes del cál-culo, de la computadora, sino del dominio de aplicación que presente el mismo.

• En el segundo nivel de abstracción se encuentran los Modelos Independientes de Plataforma (pim) —que sirven para repre-sentar la funcionalidad y la estructura del sistema— los cuales se aíslan de los detalles tecnológicos de la plataforma de imple-mentación. Con los pim se desarrollan los sistemas que conten-drán tecnología neutral, lo cuales proporcionan servicios que se implementarán posteriormente de forma diferente en cada plataforma concreta. Los modelos del nivel pim pueden refi-narse tantas veces como se quiera hasta obtener una descrip-ción del sistema con el nivel de claridad y abstracción desea-do. Un pim es una especificación de un sistema en términos de conceptos sobre el dominio y con independencia de platafor-mas tecnológicas.

• En el tercer nivel de abstracción se encuentran los Modelos Es-pecíficos de Plataforma (psm), que combinan las especificaciones contenidas en un pim, con los detalles de la plataforma elegida.

23


Un pim puede transformarse en un psm, y también a par-tir de distintos psm se pueden generar distintas implementacio-nes del mismo sistema.

De acuerdo con la mda, una transformación de modelos “es el proceso de convertir un modelo en otro modelo del mis-mo sistema”. En general, una transformación de modelos es el proceso de generación automática de un modelo destino, a par-tir de un modelo origen, de acuerdo con una definición de trans-formación, la cual se expresa en un lenguaje de transformación de modelos (Kurtev, 2005).

La mda propone algunas restricciones para las transfor-maciones entre estos niveles de abstracción:

• Definir reglas de transformación entre modelos pim-psm, y pim-pim.

• Mantener una relación de trazabilidad entre los requisitos del sistema (expresados en el modelo cim) y los artefactos repre-sentados en los modelos pim y psm que permiten llevar a cabo tales requisitos.Por ello, las transformaciones contempladas en la mda

pueden agruparse en dos tipos (France y Bieman, 2001): verti-cales y horizontales. Una transformación vertical es aquella en la que los niveles de abstracción del modelo origen y el modelo destino son diferentes. Ejemplos de estas transformaciones son el refinar un modelo o implementarlo en un lenguaje de pro-gramación concreto. La mda contempla diversas transformacio-nes verticales, por ejemplo:

• Cuando un pim está suficientemente refinado se transforma en un modelo dependiente de la infraestructura final de ejecu-ción, de modo que un pim se transforma en uno o varios psm.

• Cuando al partir de una implementación en una plataforma concreta, se desea abstraerse de los detalles concretos de di-cha plataforma, se aplica una transformación vertical para pa-sar del psm al pim.

24


Una transformación horizontal es aquella donde el mo-delo origen y el modelo destino corresponden al mismo nivel de abstracción. Una aplicación de estas transformaciones permite obtener modelos con diferentes vistas del sistema (por ejemplo, de una vista modular a una vista componente-conector), donde se pasa de un pim a otro, o bien obtener modelos específicos para distintas plataformas al pasar de un psm a otro. La principal apli-cación de este tipo de transformaciones es la evolución de mode-los, la cual puede ser:

• Perfectiva, para mejorar un diseño o cambiar el metamodelo.• Correctiva, para corregir errores en el diseño. • Adaptativa, para introducir en un diseño nuevos requisitos o

restricciones. La omg promueve la especificación de transformaciones

entre modelos, a través del estándar denominado Query View Transformations [qvt, 2005]. Cabe señalar que en la actualidad no existe una implementación de referencia que abarque la pro-puesta completa de las qvt, aunque sí han surgido propuestas que lo soportan en parte, tales como la herramienta moment (Queralt, Hoyos, Boronat, et al., 2006).

Además de las transformaciones modelo a modelo, exis-ten las transformaciones modelo a código o texto, que son prin-cipalmente utilizadas para transformar modelos diseñados en los niveles más bajos a código de un lenguaje de programación espe-cífico, y también para generar la implementación de artefactos.

mda y las vistas de arquitecturas softwareLas arquitecturas software pueden representarse por un conjun-to de vistas de las diferentes estructuras que presenta un siste-ma software (Shaw y Clements, 2006), denominadas vistas de arquitecturas software, o en inglés Software Architecture Views (sav). Sobre éstas existen diversas aproximaciones, por ejemplo: sei (Shaw y Clements, 2006), ieee (ieee-1471, 2000), y (Kru-chten, 1995).

25


Aunque hay algunas diferencias sobre cómo se interpre-ta una vista, también hay coincidencias en el tipo de elementos y sus relaciones. En todas esas aproximaciones, los componen-tes y conectores son considerados bloques de construcción bási-cos para la vista componente-conector, y el módulo para la vis-ta modular.

Las sav pueden usarse para separar asuntos (concerns), y están representadas por varios modelos. Asimismo las sav pue-den formarse como modelos abstractos —es decir, los pim— aunque representen sistemas específicos; sus características son aplicables a un conjunto similar de sistemas (familias de siste-mas software) de modo que la misma sav puede ser adaptada a sistemas en diferentes plataformas, es decir, a diferentes mode-los específicos de plataforma: los psm. Además, las sav están for-madas con elementos en un alto nivel de abstracción, descri-tos por los lenguajes de descripción de arquitecturas o notacio-nes que son traducidas a nivel código. Por lo tanto, la mda pue-de ser usada no sólo para refinar una arquitectura software, sino también para realizar transformaciones entre vistas arquitectó-nicas que están en el mismo nivel de abstracción (Kleppe, War-mer, y Bast, 2003).

En bom se seleccionaron las vistas de arquitectura soft-ware —descritas en Limón, Ramos y Torres (2006)— como las aproximaciones que más se adecuan a la propuesta de este libro, es decir, la vista modular y la vista componente-conector. Di-chas vistas son tratadas en bom como la Vista Funcional del Sis-tema (vfs), lo cual representa la funcionalidad de los sistemas ex-pertos. Sin embargo, en bom el tratamiento de la variabilidad del dominio y la variabilidad de la funcionalidad de los sistemas es manejado separadamente (en modelos independientes). Por ello, en bom es también considerada la Vista de la Variabilidad de Dominio (vvd).

26


Líneas de productos softwareUna de las aproximaciones más importantes en la ingeniería del software es la Línea de Productos Software (spl, por sus siglas en inglés [Software Product Lines]) (http://www.softwareproduct-lines.com), paradigma enriquecido en los últimos años por la mde (Schmidt, 2006).

Una spl puede definirse como un conjunto de sistemas intensivos de software que comparten un conjunto común de características manejables, y que son desarrolladas mediante un conjunto de activos básicos comunes (artefactos que pueden ser software, herramientas, documentos, modelos, etcétera). Los productos de una spl se diferencian por sus características, donde una característica es un incremento en la funcionalidad del producto. Es evidente que las características pueden ser usa-das en distintos miembros de una spl.

Asimismo, es importante considerar técnicas para el aná-lisis de requisitos funcionales y no funcionales de la nueva línea de productos, así como técnicas de clasificación y estudio de las relaciones entre los requisitos del sistema, que a la vez sugieren utilizar las bibliotecas de reutilización como gestores de este tipo de componentes software reutilizables o assets.

Al respecto existen propuestas muy útiles que pueden considerarse como puntos de partida y que deben complemen-tarse con las propuestas de las nuevas técnicas. En particular, Feature-Oriented Domain Analysis (foda) (Kang, Cohen, Hess, et al., 1990) que sistematiza las etapas iniciales en donde se de-sarrollan las spl. Sin embargo, se necesitan herramientas más potentes para obtener modelos de requisitos más precisos que los propuestos en estos métodos, así como cambiar su enfoque del espacio de la solución, al espacio del problema que se pre-tende solucionar.

Investigadores del área han proporcionado algunas defi-niciones de las spl. Este libro recurrió a la bibliografía especiali-

27


zada, donde existen diversas definiciones, pero tal vez la más co-nocida es la que ofrecen Clements y Northrop (2001), quienes definen a la spl como se enuncia a continuación:

Un conjunto de sistemas software que comparten un conjunto común y gestionado de características, que satisface las necesidades específicas de un segmento de mercado o misión y que son desa-rrolladas a partir de un conjunto central de “assets” de una manera preestablecida.

Esta definición se detalla en los siguientes cinco concep-tos:

• Productos: “Un conjunto de sistemas software […]”. Las spl cambian el enfoque del desarrollo de software. Los procesos de desarrollo no intentan construir una aplicación, sino un núme-ro de ellas (Clements y Northrop, 2001).

• Características: “[…] que compartenun conjunto común y gestionado de características […]”. Las características son “uni-dades por medio de las cuales diferentes productos pueden ser distinguidos y definidos en una spl” (Batory, Sarvela y Raus-chmayer, 2004).

• Dominio: “[…] que satisface las necesidades específicas de un segmento de mercado o misión […]”. Una spl se crea en el ámbito de un dominio. Un dominio es un área de aplicación de productos software Un dominio se define como “un blo-que de conocimiento especializado, un área de experticia o un conjunto de funcionalidades relacionadas” (Northrop, 2002).

• Activos reutilizables de software: “[…] y que son desarrolladas a partir de un conjunto central de assets […]”. Un activo de software reutilizable es “un artefacto o recurso que es usado en la producción de una línea de productos software más que en un producto” (Clements y Northrop, 2001).

• Plan de producción: “[…] de una manera preestablecida“. Se establece con anterioridad cómo es producido cada produc-to y cómo se componen todos los activos de software reutili-zables para permitir la producción del producto final. Una lí-nea de productos está formada por un conjunto de aplicacio-nes muy parecidas que pertenecen a un dominio determina-

28


do como, por ejemplo, el dominio del diagnóstico. El plan de producción es “una descripción de cómo son usados los activos de software reutilizables para desarrollar un producto de una lí-nea de productos y especificar cómo usar el plan de producción para construir el producto final” (Chastek y McGregor, 2002). Las spl surgieron en la década de los ochenta —en las es-

cuelas de negocio— con un claro objetivo económico mediante el desarrollo sinérgico de productos (Knauber y Succi, 2001). La reducción de costos, la disminución del tiempo de mercado, y la mejora en la calidad, son beneficios que se derivan de una estra-tegia basada en las líneas de productos. Sin embargo, para cada posible beneficio derivado de la reutilización existe un costo aso-ciado. En Clements et al. (1998) se presentan los elementos que afectan tanto a la línea de productos como a los nuevos produc-tos, junto a los beneficios y los costos asociados.

El objetivo principal de una spl es reducir el tiempo, el esfuerzo, el costo y la complejidad de crear y mantener los pro-ductos de la spl a través de:

• La detección de los aspectos comunes que se presentan en la línea de productos a través de la consolidación y reutilización de los activos de entrada a la línea de productos.

• El manejo de los aspectos variables de los productos que confor-men la línea a través de los puntos de variación que se encuen-tren en los activos y los modelos de decisión (Krueger, 2006).La reutilización del software es uno de los objetivos fun-

damentales dentro de la ingeniería del software. Las spl poten-cian la reutilización estratégica. Los assets de una spl van más allá de la reutilización de código.

Cada producto de la línea de productos toma la ventaja de las diferentes etapas (análisis, diseño, implementación, plani-ficación y prueba), las cuales se realizan en cada uno de los pro-ductos desarrollados previamente en la spl. De los componen-tes de bajo nivel inicialmente reutilizados (básicamente código fuente), se ha ido ampliado el espectro a niveles de abstracción

29


cada vez más altos. Al respecto, Krueger (1992) clasifica en los niveles más altos a los assets, como generadores de aplicaciones o arquitecturas software. Por su parte, Mili et al. (1995) conside-ran sistemas transformacionales reutilizables y lenguajes de muy alto nivel. Una tendencia general es crear elementos reutilizables de grano más grueso, como por ejemplo bibliotecas de clases y frameworks (Wirfs-Brock y Johnson, 1990).

Los frameworks capturan las decisiones comunes que pre-senta el diseño de un tipo de aplicaciones, mediante el estable-cimiento de un modelo común a todas ellas (en bom, la Arqui-tectura Genérica), asignando responsabilidades y estableciendo colaboraciones entre las clases que forman dicho modelo. Este modelo común contiene puntos de variabilidad, conocidos co-mo puntos calientes (Pree, 1995), y tiene en cuenta los distintos comportamientos de las aplicaciones representadas por el fra-mework. Los frameworks constituyen un hito importante en la reutilización de software, ya que permiten la reutilización de có-digo y también la reutilización del diseño de sistemas o subsis-temas. La utilización de frameworks, como base de arquitecturas de referencia adaptables, junto con la utilización de técnicas que describen (e implementan) los puntos de variación, presentes en una familia de productos, ha permitido el éxito del concepto spl (Bosch, 2000; Clements y Northrop, 2001).

Los autores Clements y Krueger (2002b) propusieron la distinción de tres modelos para crear spl: el proactivo, el ex-tractivo y el reactivo:

• El modelo proactivo es el más clásico y propone un gran es-fuerzo e inversión iniciales en una ingeniería de dominio ex-haustiva, donde se establece el dominio exacto de los produc-tos de la línea, para luego crear los activos. Esta aproximación puede requerir tiempos y costos de adopción prohibitivos para una empresa.

30


• El modelo extractivo plantea la utilización, durante la inge-niería de dominio, de ingeniería inversa de los productos ya existentes en el dominio para obtener conocimiento más pre-ciso sobre éste más rápidamente. Con el desarrollo de activos en esta aproximación se obtiene una reducción considerable de costo y tiempo.

• En el modelo reactivo no se establece desde un principio toda la línea de productos, sino que se incluirán nuevos productos a medida que aparezca la necesidad de producirlos. La creación de activos es por tanto más incremental y progresiva que con los modelos de adopción anteriores. El concepto spl (Clements y Northrop, 2001) aparece pa-

ra formalizar técnicas de fábrica de software. Asimismo, se anota la importancia de los planes de producción, preferiblemente automáticos, al ofrecer tiempos y costos de ejecución predecibles.

Las spl permiten la reutilización sistemática de las fami-lias de productos, es decir, productos similares diferenciados por algunas características; de este modo se promueve la industriali-zación sobre el desarrollo de software.

Una familia de productos software es un conjunto de productos asociados a un dominio determinado. Este concep-to lo definen García, Barras, Laguna, y Marques (2002) de la si-guiente manera:

Una familia de productos software es] el conjunto de productos diferentes que pueden ser producidos desde un diseño común, assets compartidos y mediante un proceso de ingeniería de aplicaciones. La pertenencia a este conjunto depende de la abstracción que unifica los assets en un sistema que funciona: una arquitectura, las reglas físicas o de negocio, o la plataforma hardware.

Los mismos también lo definen como “el conjunto de productos que comparten una plataforma común, pero tiene características y funcionalidad requeridas por el cliente”. Sin em-bargo, algunas veces es confundido el término líneas de producto con los términos familia de productos y dominio, o bien se realiza

31


una correspondencia biunívoca entre línea de productos y uni-dad de negocio. A continuación son aclarados estos términos:

• Una spl no necesita construirse como una familia de produc-tos, aunque es la forma de obtener los mayores beneficios. Una familia de productos no necesita constituir una línea de pro-ductos si los productos resultantes tienen poco en común en términos de sus características.

• Una spl no es un grupo de productos producidos por una úni-ca unidad de negocio; por lo tanto, puede esperarse que haya una gran correlación entre las líneas de productos y las unida-des de negocio, pero conceptualmente son distintas. Una uni-dad de negocio se forma por razones financieras o de organiza-ción, y puede ser responsable de una o más líneas de productos, mientras que en una línea de productos se comparten y ges-tionan un conjunto común de características que satisfacen las necesidades específicas de un mercado seleccionado. Las líneas de productos que provienen de diferentes unidades de negocio pueden mezclarse para formar una súper línea de productos.

• Una spl no es sinónimo de dominio. Un dominio es un cuer-po especializado de conocimiento, un área de experiencia o una colección de funcionalidad relacionada. La línea de productos hace referencia a los sistemas software que comparten las ca-racterísticas particulares de un sector en el mercado.

Repositorio de la línea de productos software: La BaselineLa spl requiere almacenar sus activos de software en repositorios o Baselines. La Baseline es una base de datos especializada que al-macena activos de software y facilita su recuperación y manteni-miento. Su objetivo es asegurar la disponibilidad de activos para apoyar y desarrollar los productos de una spl.

De todos los assets contenidos en la Baseline, la arquitec-tura software juega el papel más central. El diseño de una arqui-tectura software deberá cubrir a todos los productos de la spl e incluir a todas las características que se comparten entre los pro-ductos. Los componentes que se identificaron en la arquitectu-

32


ra deben reflejar la funcionalidad requerida, pero además deben soportar la variabilidad identificada en la arquitectura de la lí-nea de productos.

Arquitectura de la línea de productos softwareCon respecto a la arquitectura existe un amplio rango de de-finiciones, de modo que aunque no existe una sola definición que capte perfectamente el significado de arquitectura, se pue-den obtener los elementos comunes de tales definiciones: estruc-tura, composición, organización, comportamiento, decisiones, ámbito, estilos y cualidades. Otras incluyen referencias explícitas de componentes (la unidad computacional principal), conecto-res (las interacciones entre diferentes componentes), e interfaces (propiedades de los componentes), los cuales son abstracciones básicas de los lenguajes de descripción de arquitecturas (Medvi-dovic y Taylor, 2000]. Por su parte, Eeles (2006) agrega a esto el propósito, las necesidades de los stakeholders, el ámbito y la es-tructura.

El Software Engineering Institute (sei) encontró 77 defini-ciones que la comunidad ha dado a la arquitectura, de las cuales las más representativas son las siguientes:

• La arquitectura es la parte fundamental de un sistema incor-porada en sus componentes, sus relaciones con otros, y el en-torno, y los principios que guían su diseño y evolución (ieee-1471, 2000).

• Una arquitectura es la descripción de las estructuras de un sis-tema; puede haber varias (descomposición modular, de proce-so, de despliegue, de capas, etcétera). La arquitectura es el pri-mer artefacto que puede ser analizado para determinar cómo son logrados los atributos de calidad, y también sirve como el plan del proyecto. Una arquitectura sirve como el vehículo de comunicación, es la manifestación de las decisiones tempra-nas sobre el diseño, y es una abstracción reusable que puede ser transferida a nuevos sistemas.

33


De esta manera, contar con arquitecturas estandarizadas permite definir los contextos en donde los elementos reutiliza-bles pueden ser desarrollados. Así pues, la ingeniería de domi-nio surge como una evolución de la reutilización sistemática del software, basada en modelos donde las arquitecturas software juegan un papel importante.

En una spl, la arquitectura es la expresión de los aspec-tos no variantes, mientras que, con una arquitectura convencio-nal, al utilizar cualquier instancia se obtiene el comportamiento de un solo sistema. En la spl, identificar las variaciones permi-tidas e incorporar mecanismos para conseguirlas, es parte de la responsabilidad al construir una arquitectura. Los productos en una spl existen simultáneamente y pueden variar en términos de su comportamiento, calidad de atributos, plataforma, configu-ración física y middelware, ente otros.

La clave para construir exitosamente una spl consiste en discriminar entre lo que permanece constante y lo que varía, en todos los miembros de la familia. La arquitectura software ma-neja esta dualidad, dado que todas las arquitecturas son abstrac-ciones que admiten una pluralidad de instancias, lo que permite concentrarse en diseños de una serie de implementaciones dife-rentes. Por ello, la Arquitectura de la Línea de Productos (alp), también denominada arquitectura de dominio, es la clave para la reutilización sistemática, ya que describe la estructura que pre-sentan los productos del dominio al mostrar sus componentes y las relaciones entre los mismos.

Si se desea definir adecuadamente una alp, deben armo-nizarse las cualidades que se persiguen para los productos de la spl con la definición de elementos opcionales, alternativos o va-riables. La alp debe ser particularizada cada vez que se desarro-lla un producto de la línea.

La alp es una arquitectura software genérica que realiza lo siguiente:

34


• Describe la estructura que presenta toda la familia de produc-tos y no solamente la de un producto particular.

• Captura los aspectos comunes y variables que presenta una fa-milia de productos software. Mientras los aspectos comunes de la arquitectura son capturados por los componentes de software que son comunes a toda la familia, los aspectos variables de la arquitectura son capturados por los componentes de software que varían entre los miembros de la familia.

Aproximación para los procesos de la ingeniería de la línea de productos softwareEl proceso para desarrollar una spl no intenta construir una aplicación, sino una familia de éstas. Dicho enfoque produce un cambio de un desarrollo orientado a un único producto soft-ware, hacia uno de varios productos que contienen característi-cas comunes que forman una familia de productos. Esto implica una reestructuración en el desarrollo del software y, de esta ma-nera, surgen dos procesos de ingeniería distintos: la ingeniería del dominio y la ingeniería de la aplicación.

La ingeniería del dominio se centra en el desarrollo de elementos reutilizables que formarán la familia de productos, mientras que la ingeniería de la aplicación se orienta hacia la construcción o desarrollo de productos individuales, pertene-cientes a la familia de productos, y que satisfacen un conjunto de requisitos y restricciones expresados por un usuario específi-co; así se reutilizan, adaptan e integran los elementos reutiliza-bles existentes y producidos en la ingeniería de dominio (Gar-cía et al., 2002).

Por ello, la división entre la ingeniería del dominio y la ingeniería de la aplicación es fundamental en la aproximación de las spl (Clements y Northrop, 2001).

Esta partición es la base de cualquier intento de reutiliza-ción y automatización en procesos de software (Czarnecki y Ei-senecker, 2000).

35


Frecuentemente, los productos y los activos principales son construidos en sinergia con el otro. En la figura 2 se ejem-plifica esta triada de actividades, donde se observa que cada cír-culo representa una de las actividades esenciales.

Las tres están ligadas en un movimiento conjunto, con lo cual se muestra que las tres son esenciales y que están unidas, también, que el desarrollo puede ocurrir en cualquier orden de forma altamente iterativa.

Las flechas rotativas indican no solamente que los acti-vos principales son usados para desarrollar productos, sino tam-bién que las revisiones de activos principales existentes, o inclu-so nuevos activos, podrían evolucionar en el desarrollo del pro-ducto.

Figura 2. Las tres actividades esenciales para la spl

Fuente: Tomado de Clements y Northrop (2001).

bom se fundamenta en la aproximación para desarrollar una spl mencionada por Clements y Norton y que es mostrada en la figura 3.

La tabla 1, por su parte, bosqueja el proceso total:

36


Tabla 1. Procesos de la ingeniería en la splIngeniería del dominio Ingeniería de la aplicaciónAnálisis del dominio Caracterización del productoDesarrollo de componentes básicos reutilizables (assets) Síntesis del productoPlaneación de la producción Construcción del producto

Fuente: Tomada de Clements y Northrop (2001).

El análisis del dominio estudia la variabilidad del domi-nio. Frecuentemente este estudio se realiza de acuerdo con las características del dominio y se representa mediante un modelo de características. En el desarrollo de los componentes básicos reu-tilizables se concibe, diseña e implementan los componentes bá-sicos reutilizables. Esto no sólo involucra el desarrollo de la fun-cionalidad del dominio, sino también define cómo los compo-nentes básicos reutilizables deben ser extendidos. En el planea-miento de la producción se define cómo los productos individua-les son creados. En general implica la capacidad de producción que tenga la spl.

En la caracterización del producto se eligen las caracterís-ticas que diferencian un producto seleccionado. Este proceso se inicia con la selección de las características. La síntesis del pro-ducto reúne los componentes básicos reutilizables para obtener la materia prima (un producto está compuesto de). Las técnicas de variabilidad son usadas en este proceso. La construcción del producto procesa la materia prima según el plan de construcción (por ejemplo, compilar, generar código, ejecutar, etcétera), para obtener un producto final.

Cada una de las etapas del proceso para desarrollar una spl se realiza por un usuario que desempeña un rol particular. En la etapa de la ingeniería del dominio, el usuario cumple con el rol de ingeniero de la spl o ingeniero del dominio. En la eta-pa de la ingeniería de la aplicación, el usuario cumple con el rol de ingeniero en la aplicación del software o ingeniero de la apli-cación.

37


Esta situación se muestra en la figura 3, donde un tercer usuario (el cliente) aparece, el cual hace uso de la aplicación re-sultante.

Figura 3. Desarrollo de una spl

Fuente: Tomado de Clements y Northrop (2001).

Variabilidad en las líneas de productos softwareLa variabilidad es particularmente relevante en el campo de las spl. La variabilidad entre productos de una línea de productos puede expresarse en términos de características (Kang, Kim, Lee, et al., 1998; Bosch, 2000a). Una característica es una unidad ló-gica de comportamiento que es especificada por un conjunto de requisitos funcionales o de calidad (Bosch, 2000a).

Uno de los elementos clave para una spl es la representa-ción y gestión de la variabilidad. La variabilidad ha sido descrita como “[…] la habilidad de un sistema software o artefacto pa-ra ser cambiado, personalizado o configurado para usarse en un contexto particular (Van Grurp y Bosch, 2002)”.

Con el propósito de analizar el tema de la variabilidad se realizaron y discutieron diferentes aproximaciones en los úl-

38


timos años. Sin embargo, actualmente no existe una forma es-tándar para representarla. Gran parte de las aproximaciones pro-puestas agregan anotaciones de variabilidad directamente en los modelos que captan la funcionalidad del software —como el Lenguaje de Modelado Unificado, los Lenguajes de Descripción de Arquitecturas, etcétera—, mientras que otras aproximacio-nes más poderosas separan la especificación de la variabilidad en modelos específicos. Actualmente, la variación de las caracterís-ticas puede ser implícitamente definida en la mda mediante el uso de perfiles de dominios particulares; por lo tanto, la variabi-lidad debe modelarse explícitamente con el fin de obtener pro-ductos óptimos. En este contexto se encuentra la iniciativa de la mda referente a la construcción de modelos de dominio (expre-sados como grafos de características) y su posible transformación en modelos arquitectónicos.

La novedad que propone la mda es la posibilidad de au-tomatizar (al menos parcialmente) la transformación que espe-cifica cómo se convierten las instancias del modelo de caracterís-ticas en una aplicación ejecutable. La transformación sería equi-valente a la compilación de un modelo descrito por un lenguaje específico de dominio. El requisito previo antes de evaluar esta posibilidad es disponer de un metamodelo que represente uni-formemente los conceptos de cada una de las técnicas utilizadas.

La ingeniería de la spl pretende soportar un grupo de productos que atiendan diferentes clientes individuales o dife-rentes segmentos de mercado. La variabilidad es un concepto clave en cualquiera de esas aproximaciones. En lugar de enten-der cada uno de los sistemas individuales, la ingeniería de la spl mira a la línea de productos como un todo y la variación entre los sistemas individuales. Esta variabilidad debe ser definida, re-presentada, explotada e implementada a través de dicha ingenie-ría. Cuando se maneja la variabilidad en una línea de productos, necesitan distinguirse tres tipos principales:

39


• Comunes: una característica (funcional o no funcional) puede ser común a todos los productos en la línea de producto. Ésta es implementada como parte de la plataforma.

• Variables: una característica puede ser común a algunos pro-ductos, pero no a todos. Entonces, debe ser explícitamente mo-delada como una posible variabilidad y debe ser implementa-da en una forma que permita tenerla solamente en los produc-tos seleccionados.

• Específicos del producto: una característica puede ser parte so-lamente de un producto. Tales especialidades son escasamen-te requeridas por el mercado, pero sí por los intereses de los clientes individuales. Mientras las características comunes y variables se mane-

jan esencialmente en la ingeniería del dominio, las característi-cas específicas del producto son manejadas exclusivamente en la ingeniería de la aplicación.

◊ Representación de la variabilidadPara representar la variabilidad se han realizado y discutido dife-rentes aproximaciones en los últimos años. Las aproximaciones más modernas soportan la caracterización de la variabilidad por medio de características que atraviesan diferentes vistas. Así se describe si la información de la variabilidad está totalmente in-tegrada en otros modelos o no.

Mientras unos modelan la variabilidad integrada en la notación del modelo, otras aproximaciones modelan la variabi-lidad con un modelo de variabilidad específico y distinto al mo-delo del sistema principal, lo cual es considerablemente más fácil de aplicar en ambientes complejos y a mayor escala (Bachmann et al., 2003). La notación que distingue entre el modelo de va-riabilidad y el modelo de un sistema básico se llama modelado de variabilidad ortogonal (Pohl, Bockle, y Van der Linder, 2005).

La variabilidad puede describirse mediante una notación gráfica que conforma un diagrama de variabilidad. La notación

40


gráfica usada en Pohl et al. (2005) y en Bachmann et al. (2003) consiste en los siguientes elementos:

• Puntos de variabilidad: describen dónde existen diferencias en los productos finales. El descubrimiento de los puntos de varia-bilidad se realiza durante el proceso del diseño de la arquitec-tura, como opciones para implementar las variaciones identi-ficadas cuando se llevan a cabo los procesos de requisitos o va-riaciones normales durante el diseño.

• Variantes: son las diferentes posibilidades que existen para ins-tanciar un punto de variabilidad. Los puntos de variabilidad se definen a través de sus variantes. La identificación de la varia-bilidad es una actividad continua, porque un producto puede variar de muchas maneras al identificar las variantes en cual-quier tiempo durante el proceso de desarrollo. Algunas varian-tes son identificadas durante la elicitación de los requisitos de la línea de productos; otras, durante el diseño de la arquitec-tura, y otras durante la implementación.

• Dependencias de variabilidad: son usadas para cualificar las di-ferentes elecciones (variantes) que son posibles en un punto de variabilidad. La notación incluye una cardinalidad que determi-na cuántas variantes pueden ser seleccionadas simultáneamen-te. Las dependencias de variabilidad pueden ser tres: alterna-tiva (alternative), opcional (optional) y obligada (mandatory).

• Dependencias de restricciones: describen las dependencias en-tre determinadas variantes seleccionadas. Existen dos formas de restricciones:

• Requiere (requires): la selección de una variante puede reque-rir la selección de otra variante (quizás en un punto de varia-bilidad diferente).

• Exluye (excludes): la selección de una variante puede prohibir la selección de otra variante (quizás en un punto de variabili-dad diferente).Un modelo único de variabilidad y funcionalidad por sí

mismo representa con dificultad todo el significado de la varia-bilidad en la ingeniería de la spl, ya que dicho modelo resulta-ría muy confuso al incluirle todas las restricciones y plasmarle la

41


funcionalidad de los sistemas. Esto ocasiona que no exista una forma estándar para representar la variabilidad. Por ello, algunas de las aproximaciones propuestas agregan notaciones de variabi-lidad directamente a los modelos, mientras otras aproximacio-nes separan la especificación de la variabilidad en un modelo se-parado, es decir, en dos vistas independientes (la vista de la va-riabilidad y la vista de la funcionalidad).

En la literatura sobre el tema, por ejemplo el proyecto am-ple (2007), se encuentran dos clasificaciones para representar la variabilidad. La primera clasifica la especificación de la variabili-dad según los diagramas que la soportan: sobre diagramas uml, sobre lenguajes adl o al usar los dsl. La segunda clasificación distingue dos formas de plasmarla: textualmente o por un dia-grama de modelos.

Primera clasificación para representar la variabilidad: lenguajes de modeladoComo primera clasificación, en la literatura se encuentran tres formas para representar la variabilidad:

• En el lenguaje de modelado unificado (uml, por sus siglas en inglés [Unified Modeling Language]), a través de un uml-Pro-file, se modela la variabilidad en modelos de clases o diagra-mas de secuencia al añadir extensiones estereotipadas. De esta forma se expresa de manera implícita la variabilidad en un solo modelo que mezcla la funcionalidad y la variabilidad. En este contexto se encuentra la propuesta de Clauss (2001a, 2001b) que presenta un uml-Profile para modelar la variabilidad. Asi-mismo Gomma y Shin (2007) utilizan un modelo de variabi-lidad semi-ortogonal donde la variabilidad es representada en una vista separada, pero donde los puntos de variabilidad y las variantes aparecen estereotipadas en diagramas uml.

• En los lenguajes de descripción de arquitecturas (adl, por sus siglas en inglés [Architecture Description Language]) han sido propuestas notaciones de modelado para soportar desarrollo basado en arquitecturas. Al igual que en uml, existe un mo-

42


delo donde se mezcla la funcionalidad y la variabilidad. En el proyecto ample d2.1 (2007) se describe un adl basado en xml altamente extensible para modelar arquitecturas de líneas de producto: el x adl 2.0.

• El uso de los lenguajes específicos de dominio (dsl, por sus si-glas en inglés [Domain Specific Language]) permite expresar la variabilidad en el lenguaje del dominio del problema. Los dsl, en contraste con los lenguajes de propósito general adl y uml, permiten describir sistemas software y arquitecturas por medio de términos cercanos al dominio de las aplicacio-nes que son entendidos de mejor manera por los expertos del dominio, sin que ellos requieran un amplio conocimiento de conceptos arquitectónicos. En el desarrollo de una spl, múl-tiples aplicaciones pueden ser generadas para el mismo domi-nio específico; por lo tanto, puede decirse que la spl estimu-la la creación y uso de los dsl; pero, por otro lado, crear, dise-ñar, implementar y mantener un dsl requiere un cierto cos-to, ya que el tiempo usado en la creación, diseño, implemen-tación y mantenimiento del dsl, es mayor que en un lengua-je de propósito general, dado que un nuevo dsl es creado por cada nueva spl. Esta forma de representar la variabilidad im-plica un modelado explícito para definir la variabilidad, es de-cir, se manejan dos modelos distintos, uno para la funcionali-dad y otro para la variabilidad.De estas tres formas para representar la variabilidad, se

eligió la tercera: bom es una aproximación donde la especifica-ción de la variabilidad y la funcionalidad se manejan en modelos separados, a través de modelos conceptuales de variabilidad or-togonal que conforman a sus respectivos metamodelos.

Segunda clasificación para representar la variabilidad: lenguajes textual y gráfico La variabilidad puede ser representada textualmente o bien por un diagrama del modelo. Cada aproximación tiene sus venta-jas y desventajas. La representación textual permite numerosos

43


detalles a expensas de alguna ambigüedad debido a la interpre-tación del lenguaje natural. La aproximación de diagramas no siempre puede proveer las abstracciones efectivas para transmi-tir información más detallada. A continuación se comentan am-bas aproximaciones:Aproximación textual

• El lenguaje natural. La variabilidad se describe mediante pala-bras clave y frases que representan las características del siste-ma con sus posibles detalles de configuración y relaciones. Sin embargo, esta representación puede resultar ambigua, ya que es posible seleccionar más de una opción para una aplicación dada. Adicionalmente, una vez que la variabilidad adquiere mayor complejidad, este método falla rápidamente. Una ma-nera clara para documentar la variabilidad, sin tales ambigüe-dades, es listar explícitamente la variabilidad y describir su cla-se, así se remueve la ambigüedad de una aproximación mera-mente lingüística.

• El lenguaje de descripción de características. Con este fin Deur-sen y Klint (2002) propusieron un lenguaje de descripción de características (fdl, por sus siglas en inglés [Feature Descrip-tion Language]) para modelar características y restricciones. Ellos representan los puntos de variabilidad que contienen el conjunto de características variantes, y describen los tipos de restricciones al utilizar palabras clave en su lenguaje de descrip-ción de características. Sin embargo, mientras esta aproxima-ción trabaja para pequeños problemas, puede ser difícil mante-ner una visión general de variabilidades y dependencias cuan-do el tamaño del modelo de características aumenta; por esta razón los modelos de diagramas son generalmente preferibles. No obstante, en ocasiones la aproximación textual podría ge-nerarse en un diagrama del modelo de características y enton-ces tener una vista alternativa.

Aproximación gráfica (modelos gramaticales)• Con el fin de obtener un mejor entendimiento sobre un tema

complejo, es beneficioso mostrar el concepto mediante diagra-

44


mas. Así, modelar la variabilidad en forma de diagramas pue-de ayudar a expresar lo siguiente:

• Características comunes y variables.• Tipos de alternativas de la variabilidad (obligatoria, opcional

y alternativa).• Dependencias entre características• Un modelo coherente para diferentes usuarios (clientes e inge-

nieros de software).Las aproximaciones que separan la variabilidad en vistas

distintas están basadas en el primer metamodelo de variabilidad propuesto por Bachmann et al. (2003) como la forma para sepa-rar la variabilidad de los artefactos afectados (por ejemplo, com-ponentes, clases, interfaces). Esta separación permite que la va-riabilidad por sí misma sea tratada como una nueva vista arqui-tectónica (la vista de variabilidad). Tal aproximación es genéri-ca y puede por lo tanto ser usada para describir variabilidad en todas las clases de artefactos software. El metamodelo de Bach-mann et al. (2003) para capturar la variabilidad se presenta en la siguiente figura (4).

Figura 4. Metamodelo de variabilidad

Fuente: Tomado de Bachmann et al. (2003).

El metamodelo consiste en cuatro elementos principales: punto de variación, variante, activo y fundamento. Un punto de variación (variation point) describe un punto explícito con el número de decisiones de ingeniería, es decir, las variantes (va-riants) que puede tener un activo reutilizable (asset) o, dicho de

45


otro modo, un artefacto o un paquete de artefactos. El funda-mento (rationale) explicita la intención del punto de variación al ingeniero de software o al que configura el sistema. La relación de dependencia (depends on) denota que existe una dependen-cia entre: a) un punto de variación y otro punto de variación, b) una variante y un punto de variación, y c) entre una variante y otra variante. Similarmente la relación remplazar (replace) deno-ta que: a) un punto de variación remplazará a otro punto de va-riación, b) una variante remplazará a un punto de variación, y c) una variante remplazará a otra variante.

En 1990 Kang et al. propusieron el Modelo de Caracte-rísticas (del inglés Feature Models), el cual permite representar todos los posibles productos que existen en una spl en un solo modelo. Así pues, la primera notación del modelo de caracterís-ticas fue introducida por foda (Kang et al., 1990), la cual es una metodología que se emplea en la ingeniería del dominio, desa-rrollada por el Software Engineering Institute de la Carnegie Me-llon University y enfocada a crear una spl mediante un proceso estructurado que se basa en la notación de los modelos de carac-terísticas. A partir de entonces, muchas han sido las extensiones y mejoras que se han propuesto y realizado sobre dicho mode-lo, lo cual ha intentado incrementar su capacidad expresiva, co-mo se observa en los trabajos de Griss, Favaro, y D’Allesandro (1998).

Los modelos de características modelan los conceptos co-munes y variables de una línea de productos y las propiedades de estructura en el dominio de interés; esto implica que que iden-tifican la spl en términos de la variabilidad soportada. Por ello, los modelos de características son la clave técnica de las líneas de producto para desarrollar software (Batory et al., 2006), debido a que son modelos formales que usan características para especi-ficar productos. Cada conjunto de características define un pro-grama único en una spl; donde una característica (del inglés fea-

46


ture) es “una característica del producto que es usado para dis-tinguir un producto de una familia de productos relacionados” (Batory, 2004).

Al respecto, Batory et al. (2006) definieron, de dos for-mas, un modelo de características: como un conjunto de carac-terísticas organizadas jerárquicamente y como un lenguaje pa-ra especificar productos en una spl. Con este propósito utiliza-ron un diagrama de características para representar gráficamen-te un modelo de características. Su trabajo señala que las rela-ciones entre de características son categorizadas como se seña-la a continuación:

• And (y): todas deben ser seleccionadas.• Xor alternative (o): solamente una puede ser seleccionada.• Or (or): una o más pueden ser seleccionadas.• Mandatory (obligatorio): las que son requeridas.• Optional (opcional): las que son opcionales.

Su notación gráfica se muestra en la siguiente figura (5):

Figura 5. Notación gráfica utilizada en el modelo clásico de características

and or(chosse 1)

mandatory optionalxor(1+)

Fuente: Tomado de Batory et al. (2006).

Además, el modelo de características especifica las distin-tas variantes disponibles del dominio, de forma que se modelan las restricciones del dominio al incluir o excluir las características de acuerdo con las alternativas que son presentadas.

◊ Gestión de la variabilidad La gestión de la variabilidad consiste en la habilidad para mane-jar eficientemente las diferencias o cambios en el desarrollo del

47


software, donde se consideran todas las fases de desarrollo, des-de el análisis de requisitos hasta la implementación. El manejo de la variabilidad puede involucrar varios aspectos como los re-quisitos software, características, interfaz del usuario, o la plata-forma de implementación.

El manejo de la variabilidad es de interés en cualquier aproximación que se relacione con la ingeniería de la spl y la misma cubre todo el ciclo de vida. La variabilidad es relevan-te para todos los assets del desarrollo de software. La variabili-dad debe ser expresada en los activos (product´s line core assets), de tal forma que la variabilidad decore a la spl con diferentes ca-racterísticas.

Una técnica para el manejo de la variabilidad es la pro-gramación orientada a características (fop, por sus siglas en in-glés [Feature Oriented Programming]), la cual es un paradigma de las spl donde las características son los bloques de los produc-tos construidos, es decir, los componentes básicos reutilizables. A través de las características los diferentes productos pueden ser distinguidos y definidos en una spl (Batory et al., 2004).

fop es el estudio de la modularidad de características, por lo que puede ser vista como una metodología modular, en don-de las características son consideradas como ciudadanos de pri-mera especie en el diseño.

Por ello, fop enfoca principalmente las características de un sistema, en lugar de los objetos que lo componen (como lo sería en un lenguaje orientado a objetos). En fop una caracterís-tica es una parte relevante de un objeto o cosa (López-Herrejón, 2005). Así, fop es una metodología de programación la cual sos-tiene que crear varias características y conectarlas a través de pro-cedimientos/métodos/funciones es la mejor manera de eliminar la redundancia y mejorar la eficiencia, enriqueciendo la funcio-nalidad principal.

48


Herramientas utilizadas en la línea de productos softwareLas spl requieren gestionar la variabilidad, sobre todo el proce-so para desarrollar la línea de productos, donde se involucran los artefactos software en diferentes niveles de abstracción. Por ello, las herramientas para desarrollar los productos deben soportar un proceso de desarrollo integral que permita crear artefactos software, asegurar propiedades y generar pruebas, así como la calidad del producto.

Esta sección se limitó a considerar el conjunto de herra-mientas que ha sido desarrollado expresamente para la ingenie-ría de la spl, en donde se tuvieron en cuenta los principales inte-reses para el desarrollo y modelado de este conjunto de sistemas (spl), que involucran artefactos software en todos sus niveles de abstracción y en todas las fases que conforman su ciclo de vida.

En la tabla 2 se presentan los criterios utilizados para eva-luar las herramientas existentes y que son potencialmente rele-vantes para el desarrollo de la spl, con respecto al proceso de de-sarrollo. Dichos criterios se basan en la funcionalidad principal de la herramienta —en términos de la spl— y la gestión que rea-liza en el ciclo de vida donde se desarrolla este producto.

49


Tabl

a 2.

Com

para

ción

(fun

cion

al) d

e la

s her

ram

ient

as p

ara

el d

esar

rollo

de

las s

pl

Cob

ertu

ra d

e lo

s pro

ceso

sPu

re: v

aria

nts

Gea

rsFm

p2rs

moa

wPr

otob

omD

efini

ción

de

spl

Mod

elo

de

cara

cter

ístic

asM

odel

o de

ca

ract

eríst

icas

Mod

elo

de

cara

cter

ístic

asds

lM

odel

os

conc

eptu

ales

Anál

isis/

valid

ació

n de

spl

(esp

acio

del

dom

inio

)Sí

, se

com

prue

ba

com

patib

ilida

d en

tre e

l mod

elo

de

cara

cter

ístic

as y

el

mod

elo

de la

fam

ilia.

Sí, l

a he

rram

ient

a in

cluy

e un

info

rme

esta

dísti

co e

l cua

l, po

r ej

empl

o, c

alcu

la e

l nú

mer

o de

pro

duct

os

pote

ncia

les b

asad

os

en e

l núm

ero

de

decl

arac

ione

s y

defin

icio

nes d

e ca

ract

eríst

icas

.

Sí, s

e ca

lcul

an

un n

úmer

o de

co

nfigu

raci

ones

re

pres

enta

das p

or

un m

odel

o de

ca

ract

eríst

icas

, pr

opag

ando

ele

ccio

nes

de c

onfig

urac

ión,

et

c éte

ra.

No

No

Anál

isis/

valid

ació

n de

pr

oduc

tos (

espa

cio

de la

ap

licac

ión)

S í, s

e co

mpr

ueba

co

mpa

tibili

dad

entre

el m

odel

o de

car

acte

rístic

as

y el

mod

elo

de

desc

ripci

ón d

e la

va

riabi

lidad

.

S í, s

e co

mpr

ueba

qu

e la

sele

cció

n de

car

acte

rístic

as

(en

un m

odel

o de

ca

ract

eríst

icas

) de

una

insta

ncia

del

pro

duct

o se

a la

cor

rect

a.

S í, s

e ve

rifica

n pl

antil

las d

el m

odel

o ba

sánd

ose

en

cara

cter

ístic

as, c

on

restr

icci

ones

ocl

bie

n fo

rmad

as.

S í, s

e co

mpr

ueba

la

valid

ació

n de

l mod

elo

con

restr

icci

ones

ocl

.

No

Ensa

mbl

ado

del p

rodu

cto

S íSí

No

SíSí

Prue

ba d

el p

rodu

cto

No

No

No

No

No

Ejec

ució

n de

l pro

duct

oN

oN

oN

oN

oSi

Man

teni

mie

nto

del

prod

ucto

No

No

No

No

No

Con

tinúa

en la

pág

ina

sigui

ente

.

50


Cob

ertu

ra d

e lo

s pro

ceso

sPu

re: v

aria

nts

Gea

rsFm

p2rs

moa

wPr

otob

om

Sopo

rte

para

dom

inio

s de

aplic

ació

n es

pecí

ficos

No

No

No

No

Sí

Expr

esiv

idad

de

edito

res d

el

mod

elo

de c

arac

terís

ticas

Jera

rquí

a de

car

acte

rístic

asSí

SíSí

, inc

luye

la

posib

ilida

d de

cr

ear c

arac

terís

ticas

cl

onad

as.

No

rele

vant

eSí

, inc

luye

niv

eles

en

algu

nas c

arac

terís

ticas

de

l dom

inio

de

aplic

ació

n.Se

lecc

ión

de c

arac

terís

ticas

One

-of,

mor

e-of

, op

tiona

l, m

anda

tory

.O

ne-o

f, m

ore-

of, o

p-tio

nal,

man

dato

ry.

One

-of,

mor

e-of

, op-

tiona

l, m

anda

tory

.N

o re

leva

nte

(no

expl

ícita

s en

el d

sl).

And,

or,

optio

nal,

man

dato

ry.

Car

acte

rístic

as c

on v

alor

esSí

SíSí

, inc

luye

tipo

s de

atrib

utos

No

rele

vant

eSi

, inc

luye

nom

bre,

tip

o y

(en

su c

aso,

ni

vel)

de a

trib

utos

Aser

cion

es so

bre

valo

res d

e la

s car

acte

rístic

asSí

SíSí

No

rele

vant

eSí

Repr

esen

taci

ón d

e la

s ca

ract

eríst

icas

Grá

fico

Text

ual

Grá

fico

y te

xtua

lN

o re

leva

nte

Grá

fico

y te

xtua

l

Múl

tiple

s mod

elos

de

cara

cter

ístic

asS í

SíSí

, inc

luye

re

stric

cion

es e

ntre

el

los q

ue p

erm

iten

la e

spec

ializ

ació

n en

es

cena

s.

No

rele

vant

e (p

ero

pued

en u

sars

e

múl

tiple

s dsl

).

Sí, m

odel

os

conc

eptu

ales

de

l dom

inio

y

del d

omin

io d

e ap

licac

ión.

Dep

ende

ncia

s de

los

mod

elos

de

cara

cter

ístic

asSí

SíSí

, inc

luye

n re

stric

cion

es o

cl.

No

rele

vant

eSí

Vien

e de l

a pá

gina

ant

erio

r.

51


Inge

nier

ía d

el p

rodu

cto

Pure

: var

iant

sG

ears

Fmp2

rsm

oaw

Prot

obom

Sopo

rte

para

man

ejar

in

stanc

ias d

el m

odel

o de

ca

ract

eríst

icas

SíSí

SíN

oSí

Sopo

rte

para

la

insta

ncia

ción

del

pro

duct

oSí

SíN

o, só

lo m

odel

o de

in

stanc

iaci

ón.

Sí (g

ener

ació

n de

có

digo

fuen

te d

esde

el

cód

igo

dsl)

.

Sí (g

ener

ació

n au

tom

átic

a de

có

digo

C#

med

iant

e un

com

pila

dor d

e m

odel

os).

Ambi

ente

de

ejec

ució

nN

oN

oN

oN

oSí

, (ge

nera

ción

au

tom

átic

a de

l ej

ecut

able

sobr

e el

m

iddl

ewar

e).

Edito

res p

ara

man

ejar

de

pend

enci

as e

ntre

mod

elos

de

car

acte

rístic

as

SíSí

, es p

osib

le m

anej

ar

las d

epen

denc

ias

sobr

e lo

s mod

elos

de

car

acte

rístic

as d

e m

ódul

os m

ixin

.

SíN

oSí

Gen

erad

or d

e có

digo

SíN

oN

oSí

SíD

estin

os d

e im

plem

enta

ción

Tecn

olog

ía

agnó

stica

, y

espe

cífic

a so

port

ada

para

C/C

++ y

Java

.

Tecn

olog

ía a

gnós

tica

No

Tecn

olog

ía a

gnós

tica

Tecn

olog

ía a

gnós

tica

sobr

e pl

ataf

orm

as

desti

no p

im, y

es

pecí

fica

sopo

rtad

a pa

ra C

#.

Fuen

te: A

dapt

ada

del a

mpl

e d.

3.1

proj

ect (

ampl

e, 2

007)

.

52


Modelo prismaEl modelo prisma (Plataforma Oasis para Modelos Arqui-tectónicos (Pérez, 2006)) surge para cubrir los complejos requi-sitos software a través de su potencia expresiva, facilidad de uso y novedad. El modelo prisma presenta propiedades y ventajas en la construcción de modelos arquitectónicos altamente reconfig-urables y reutilizables dentro de un marco de calidad controlada.

El modelo arquitectónico prisma integra dos aproxi-maciones: el Desarrollo de Software Basado en Componentes (cbsd, por sus siglas en inglés [Component-Based Software De-velopment]) (Szyperski, 1998) y el Desarrollo de Software Orien-tado a Aspectos (aosd, por sus siglas en inglés [Aspect-Oriented Software Development]) (aosd, 2001). Esta integración se con-sigue al definir los elementos arquitectónicos mediante aspectos como los siguientes: coordinación, funcional, persistencia, dis-tribución (Ali, Ramos, y Carsí, 2005), y presentación. De esta forma, prisma, además de definir los elementos arquitectónicos básicos y especificar su sintaxis y semántica, también especifica los aspectos que cubren las propiedades necesarias de cada uno de éstos. Por ello, un elemento arquitectónico del modelo pris-ma puede analizarse desde dos vistas diferentes: interna y externa (véase la figura 6). La vista interna muestra al elemento arquitec-tónico como un prisma, de forma que cada lado del prisma co-rresponde a un aspecto, mientras que la vista externa encapsu-la la funcionalidad del elemento arquitectónico sólo con la visi-bilidad de los servicios que éste publica a través de sus puertos.

53


Figura 6. Vistas interna y externa de un elemento arquitectónico prisma

Architectural Element

FUNCIONALDISTRIBUTION SAFETY

--- ---… …

Weavings

Architectural ElementArchitectural Element


--- ---… …


--- ---… …

WeavingsWeavings

Port

Fuente: Tomado de Pérez (2006).

El modelo prisma consta de tres tipos de elementos ar-quitectónicos: componentes, conectores y sistemas. Un compo-nente captura la funcionalidad del sistema, mientras que un co-nector actúa como coordinador entre otros elementos arquitec-tónicos. Un sistema es un elemento arquitectónico de mayor granularidad que permite encapsular un conjunto de compo-nentes, conectores y otros sistemas, correctamente conectados entre sí.

Un elemento arquitectónico prisma está formado por un conjunto de aspectos de diferentes tipos, las relaciones de en-tretejido entre estos aspectos (weavings) y uno o más puertos. Un aspecto prisma es un asunto de interés del sistema (concern) que es común y compartido por el conjunto de tipos del siste-ma (crosscutting concerns). Los tipos de aspectos (funcional, co-ordinación, distribución, etcétera) que forman un elemento ar-quitectónico varían de acuerdo con el sistema software. Dichos aspectos utilizan el conjunto de servicios que ofrecen las inter-faces.

Los aspectos contienen los protocolos. El protocolo defi-ne un proceso que describe un conjunto de acciones cuya ocu-rrencia es posible. Éste se compone por un conjunto de procesos

54


que establecen los servicios y transacciones posibles. También permite especificar las prioridades de ejecución de cada uno de los servicios implicados. En los conectores un protocolo modela el proceso global: coordina y sincroniza los servicios de los dis-tintos played_roles: la coreografía.

Así pues, un played_role es una proyección del protocolo coreografía sobre el conjunto de servicios que brinda una inter-faz, el cual define el comportamiento parcial de un puerto con un papel determinado. El mismo es una vista parcial del proto-colo que tiene sentido por sí solo, es decir, un comportamiento específico y restrictivo que es posible asociarlo posteriormente a un puerto de un componente o conector. Un played_role per-mite a los componentes actuar de forma diferente en función de otros componentes a los que esté conectado.

Los played_roles y los protocolos se especifican mediante el pi-cálculo poliádico (Milner, 1991), el cual permite describir de forma sencilla la ejecución de procesos y servicios susceptibles de ejecutarse concurrentemente.

El weaving (entretejido) establece las sincronizaciones necesarias entre los aspectos que conforman un elemento arqui-tectónico. Un weaving define la ejecución de un servicio de un aspecto puede generar la invocación de un servicio de otro as-pecto (before, after,…). Los puertos representan los puntos de interacción entre los elementos arquitectónicos.

Existen dos tipos de relaciones para interconectar los ele-mentos arquitectónicos: attachments y bindings. Los attachments establecen el canal de comunicación entre el puerto de un com-ponente y el puerto de un conector., mientras que los bindings establecen la comunicación entre un puerto de un sistema y un puerto de un elemento arquitectónico de los que encapsula. De este modo, los bindings permiten mantener un enlace entre los distintos niveles de granularidad de los elementos arquitectóni-cos que forman el modelo.

55


El prisma especifica la arquitectura en dos niveles: el de definición de tipos y el de configuración. En el nivel de tipos se definen los tipos de la arquitectura: interfaces, aspectos, compo-nentes, conectores y sistemas, los cuales son guardados en una librería para su reutilización. En el nivel configuración se espe-cifican las topologías que conforman las instancias de los mo-delos arquitectónicos de un determinado sistema software. Es-ta diferenciación proporciona importantes ventajas, ya que per-mite gestionar de forma independiente los tipos de elementos y las topologías específicas de cada sistema, así se obtiene un ma-yor nivel de reutilización y un mejor mantenimiento de las li-brerías de tipos.

El metanivel del modelo prisma y las propiedades reflexi-vas de los lenguajes diseñados, dan soporte a la evolución de los elementos arquitectónicos y a la reconfiguración dinámica de la topología. Esta característica permite definir un metanivel por aspecto al reificar las propiedades que deseen ser evolucionadas y, para ello, se basa en la reflexión.

Mediante dicho proceso el modelo prisma da soporte a la evolución de sus modelos, de esta manera reduce el esfuerzo de mantenimiento en sus productos; la evolución proporciona la dinámica del tipo, es decir, la capacidad para cambiar su estruc-tura y comportamiento basándose en la evolución del software que plantea la reflexión.

Los elementos arquitectónicos prisma se obtienen al identificar escenas funcionales del sistema y al asignar un conec-tor para cada escena funcional; dependiendo de si éstas son sim-ples o complejas, el elemento será un componente (componente simple) o un sistema (componente complejo), respectivamente. El concepto de escena aparece en el trabajo de Noriega y Sierra (1998), y es definido con un enfoque prisma por Pérez (2003) al considerar que “una escena se caracteriza por las tareas que se desempeñan en la actividad siguiendo un determinado protoco-

56


lo, los actores que las realizan y el espacio virtual o físico donde se desarrolla.”

El modelo prisma especifica la arquitectura a través de su propio lenguaje de descripción de arquitecturas (adl). El adl del prisma está dividido en dos niveles de especificación: el nivel de definición de tipos y el nivel de configuración:

• En el nivel de definición de tipos, prisma potencia la reutili-zación y combina el cbsd y el aosd. Este nivel permite definir los tipos necesarios para especificar un sistema arquitectónico. Dichos tipos se guardan en una librería para posteriormente reutilizarlos en la definición de distintos modelos arquitectó-nicos. Sus ciudadanos de primer orden son: interfaces, aspec-tos, componentes y conectores.

• El nivel de configuración permite definir las instancias y espe-cificar la topología del modelo arquitectónico; para ello, en pri-mer lugar se importan todos aquellos tipos (conectores, com-ponentes y sistemas), definidos mediante el lenguaje de defi-nición de tipos, que se necesiten para un determinado mode-lo arquitectónico. Después, se define el conjunto de instancias necesarias de

cada uno de los tipos importados. Finalmente, se debe especifi-car la topología al interconectar adecuadamente las instancias del modelo. Esta diferenciación proporciona importantes ven-tajas, ya que permite gestionar de forma independiente los tipos de elementos y las topologías específicas de cada sistema; de es-ta forma se obtiene un mayor nivel de reutilización y un mejor mantenimiento de las librerías de tipos.

Sistemas expertos Los sistemas de soporte para la toma de decisiones (del inglés Decision Support Systems) son un bloque de toma de decisiones sustentado en una base de datos; este bloque puede ser usado por quienes toman las decisiones para apoyar el proceso de de-cidir.

57


De los diferentes tipos de sistemas de apoyo a las decisio-nes, los sistemas expertos (es, por sus siglas en inglés [Expert Sys-tems]) dan mayor soporte en el proceso de toma de decisiones, lo cual permite tener el conocimiento del experto capturado en una base (no estructurada) de conocimientos y utilizarlo cuan-do se requiera sin que esté él presente. Los sistemas expertos que están basados en reglas, contienen conocimientos predefinidos que se utilizan para tomar todas las decisiones (para fines de este libro se han considerado los sistemas expertos basados en reglas). Por ello, los sistemas expertos adquieren cada vez mayor auge, hasta el punto de suponer un punto de referencia importante en la toma de decisiones. Al respecto, Druzdzel y Flynn (2000) re-comiendan la técnica de los se por las ventajas del acceso inte-ractivo a grandes volúmenes de datos e información con los cua-les puede decidirse entre alternativas recomendadas y justifica-das para evitar los sesgos en las decisiones basadas únicamente en el juicio intuitivo humano.

Un sistema experto es un programa software que permite simular el comportamiento de un especialista humano frente a un problema de su competencia en un determinado campo. Es-tos sistemas intentan codificar los conocimientos y reglas de de-cisión por las que optan los especialistas, de manera que pueden aprovecharse estas pericias al tomar las decisiones.

Estos sistemas están orientados esencialmente a determi-nados tipos de trabajos, limitados conceptualmente a una serie de acciones o decisiones.

El concepto de sistema experto es muy amplio y su defi-nición varía en cada autor, sin embargo, un fundamento común puede extraerse de todas éstas: un sistema experto es un sistema con pericia en la solución de problemas; esto es, un sistema que posee razonamientos, habilidades y conocimientos acerca de un dominio particular, para resolver los problemas de forma similar a la de un experto humano.

58


• La arquitectura de estos sistemas se refiere a los módulos que forman parte del mismo, independiente del dominio. Espe-cíficamente se definen tres tipos de arquitecturas en general:

• Arquitecturas de primera generación, en donde el control y el conocimiento están centralizados.

• Arquitecturas de segunda generación, guiada principalmente por la filosofía de sistemas distribuidos. Al respecto, se habla de agentes inteligentes, en donde cada uno de ellos presenta un comportamiento inteligente.

• Arquitecturas de tercera generación, en donde la idea básica es la reutilización de muchos de los componentes del sistema. Una arquitectura de este tipo es la que se propone en este li-bro, ya que los se pueden considerarse como una tercera gene-ración de sistemas informáticos.Las metodologías y aplicaciones que se han desarrolla-

do para los sistemas expertos producen una amplia categoría de productos de investigación, así se ofrecen sugerencias y solucio-nes a dichos sistemas en dominios específicos. Estas metodolo-gías y aplicaciones se diversifican según los antecedentes de los autores, su experiencia, sus intereses de investigación, sus habi-lidades en la metodología utilizada y el dominio del problema. Un estudio realizado por Liao (2005) examina y contempla las metodologías de los sistemas expertos, a los que clasifica en on-ce categorías.

Asimismo, los sistemas expertos se han implementado en diversos paradigmas de programación —por ejemplo, la estruc-turada, la lógica y la orientada a objetos, entre otros—; de es-ta manera, su desarrollo se ha inclinado hacia lenguajes de cuar-ta generación y métodos de programación visual para dar un en-torno y una estructura amigable de comunicación con el usua-rio (Liao, 2003).

Sin embargo, la arquitectura de estos sistemas se imple-mentó con una estructura basada en componentes (Giarratano y Riley, 2004) sin considerar adicionalmente la orientación a as-

59


pectos, como lo contempla el modelo propuesto en el presente trabajo, el cual integra estos dos enfoques.

La necesidad del uso de estos sistemas se debe, por un la-do, al aumento constante de conocimientos y datos a conside-rar en una decisión y, por otro lado, a la capacidad de estos sis-temas para manejar una gran cantidad de conocimientos y emu-lar el razonamiento humano para tomar una decisión o llegar a una conclusión.

Una de las formas más utilizadas para representar el cono-cimiento es a través de un conjunto de reglas del tipo sí-entonces. En la parte del sí están expresadas las premisas de determinada situación, y en la parte del entonces se encuentra la conclusión. La estructuración del conocimiento como sistemas de sí-enton-ces, permite ordenar el conocimiento como árboles virtuales, en donde la raíz se encuentra formada por las conclusiones termi-nales, y las premisas son hojas de diferentes ramas. Los árboles de decisión detallan una secuencia de pasos en los cuales se selec-ciona un camino a través de una cadena de eventos y acciones. Una de las mejores formas para conocer el desempeño e impor-tancia de los sistemas expertos es a través de las diferentes tareas genéricas que son capaces de ejecutar.

La amplia gama o tipología de sistemas expertos se debe a la gran variedad que existe de dominios y problemas explora-dos en los mismos.

Con este fin se crearon sistemas expertos para la interpre-tación, la predicción, el diagnóstico, el diseño, la planeación, el monitoreo, la depuración, la reparación, la instrucción, el con-trol y otros tipos de tareas. Una encuesta realizada por el Japan Information Processing Development Center (jipdec [1989]), en Japón, sobre el uso de los sistemas expertos, demostró que las ta-reas realizadas por éstos son las que se muestran en la siguien-te gráfica (1):

60


Gráfica 1. Porcentajes sobre las tareas de los sistemas expertos

Fuente: Tomada del jipdec (1989).

El porcentaje excede a 100%, pues se admitían varias ta-reas para cada uno de los sistemas expertos. Además, como se observa en la misma gráfica (1), la aplicación de los sistemas ex-pertos ha sido extensa en diversos ámbitos de la vida humana, sin embargo se muestra un notable interés en los sistemas que realizan tareas de diagnóstico. Por ello, y con la finalidad de ilus-trar en este libro la aproximación bom, se eligió a los sistemas ex-pertos que realizan tareas de diagnóstico.

Un sistema experto para el diagnóstico es un sistema que infiere las razones de un buen o mal funcionamiento, respecto a un ente, a partir de la interpretación de datos observados, los cuales pudieran ser ruidosos, inseguros o incompletos.

La construcción de los sistemas expertos para resolver ta-reas de diagnóstico, en el campo de la medicina, es muy amplia, como se observa en Liebewitz (1998). Sin embargo, el campo del diagnóstico abarca otras aplicaciones además de las médicas (si bien pueden ser estas últimas las más conocidas) como lo son: finanzas y gestión, educación, administración, militar, transpor-tes, aeronáutica, agricultura, arqueología, derecho, geología, in-

61


dustria electrónica, informática y telecomunicaciones. En estos casos se trata de fallos, averías o anomalías que se producen ge-neralmente en un ente. Los sistemas basados en reglas con en-cadenamiento hacia adelante o hacia atrás, los razonamientos oportunísticos y diferenciales, los basados en casos, los basados en modelos y los probabilísticos, resultan ser fuertes candidatos pa-ra problemas de diagnóstico.

Por otra parte, los sistemas basados en redes neuronales son muy útiles para problemas de diagnóstico, sobre todo cuan-do el diagnóstico depende fuertemente del reconocimiento de patrones. Sin embargo los razonamientos más utilizados por los humanos para realizar un diagnóstico son el deductivo, el induc-tivo y el diferencial. Dichos razonamientos se describen a con-tinuación.

◊ Razonamiento deductivoEl razonamiento deductivo o guiado por los datos (también lla-mado razonamiento con encadenamiento hacia adelante o ra-zonamiento “forward”) consiste en enlazar los conocimientos a partir del uso de datos (propiedades de la entidad a diagnosti-car) con el fin de obtener la solución de un problema. Dado que en este razonamiento se generan nuevas propiedades o hechos, existen dos formas de tratarlos, que son: profundidad cuando un hecho en cuanto se genera se introduce a la base de conoci-mientos, o en anchura cuando no se incorporan los hechos a la base de conocimientos hasta que se ha terminado. En general, las soluciones pueden ser más de una. De un hecho así deduci-do se puede asegurar su verdad. La ventaja desde el punto de vis-ta técnico de utilizar este modo de encadenar el conocimiento es su sencillez y que la entrada de datos es única y se da al prin-cipio del programa. Este encadenamiento está basado en el mo-dus ponens de la lógica formal que dice que: Si conocemos la re-gla: “si A entonces B”, y A es cierto, entonces podemos deducir que B es también cierto.

62


El encadenamiento hacia adelante se desarrolla según el siguiente procedimiento.

• Hasta que ninguna regla produzca una nueva afirmación o la hipótesis sea identificada.

• Para cada regla.• Trátese de corroborar cada antecedente de la regla mediante su

apareamiento con hechos conocidos.• Si se corroboran todos los antecedentes de la regla, hágase valer

el consecuente, a menos que ya exista una afirmación idéntica;• Repítase el procedimiento para todos los apareamientos y al-

ternativas de sustitución.

Figura 7. Grafo del razonamiento deductivoHipótesis / Objetivo

Variables observables

◊ Razonamiento inductivoEl razonamiento inductivo o guiado por los objetivos (también llamado razonamiento con encadenamiento de reglas hacia atrás o razonamiento “backward”) consiste en comprobar que un ob-jetivo es cierto en base a unos hechos que forman el universo del sistema. Este encadenamiento tiene su fundamento en el modus tollens de la lógica formal que dice que si conocemos la regla: “Si A entonces B” y también conocemos que A es falso, enton-ces podemos inducir que B también lo es.

El encadenamiento hacia atrás se desarrolla según el si-guiente procedimiento:

• Hasta que todas las hipótesis se hayan identificado y ninguna se pueda comprobar o hasta que las hipótesis sean verificadas:

• Para cada hipótesis.

63


• Para cada regla cuyo consecuente coincida con la hipótesis en cuestión.

• Inténtese corroborar cada uno de los antecedentes de la regla mediante su apareamiento con afirmaciones de la memoria en funcionamiento o mediante encadenamiento regresivo a tra-vés de otra regla, creando nuevas hipótesis.

• Asegúrese de verificar todas las alternativas de unificación y sustitución.

• Si todos los antecedentes de la regla logran ser corroborados, notifíquese el éxito y concluya que la hipótesis es verdadera.

Figura 8. Grafo del razonamiento inductivo

Hipótesis / Objetivo


◊ Razonamiento diferencialEl razonamiento diferencial se realiza cuando hay que comparar entre dos o más posibilidades diagnósticas o hipótesis. En este razonamiento se lleva a cabo el siguiente proceso: primero se rea-liza el razonamiento deductivo con el fin de llegar a un diagnós-tico; si se llegase a dos o más posibilidades diagnósticas, se reali-zará el razonamiento diferencial, invocando al razonamiento in-ductivo para reformular preguntas al usuario o buscar datos que permitan determinar cuál de las posibilidades diagnósticas es la más certera al problema analizado, es decir, verificar las solucio-nes o hipótesis.

64


Figura 9. Grafo del razonamiento diferencial





Estándares de la omg utilizados en bom como técnicas de modeladoLas técnicas de modelado en bom utilizan los estándares de la omg. En particular, se usan estándares tradicionales como los siguientes:

• Lenguaje de Modelado Unificado (uml, por sus siglas en inglés [Unified Model Language]) (uml, 2005), que permite mode-lar, construir y documentar los elementos que forman un sis-tema software.

• Facilidad de Metaobjetos (mof, por sus siglas en inglés [Meta Object Facility]) (mof, 2006), la cual es una propuesta de la omg para el caso específico de la mda, como un lenguaje de metamodelado. Asimismo, nuevos estándares que en los últimos años ha

propuesto la omg para la mda y que complementan los anteri-ores:

• Metamodelo de la Ingeniería de Procesos de Software (spem, por sus siglas en inglés [Software Process Engineering Metamo-del]) (spem, 2006), que define un lenguaje para modelar pro-cesos de desarrollo de software.

65


• Especificación de Recursos Reutilizables (ras, por sus siglas en inglés [Reusable Asset Specification]) (ras, 2005), que define de manera estándar toda la información asociada a un activo o recurso, a través de la cual es posible manipularlo y reutilizarlo.

• Notación para el Modelado de Procesos de Negocio (bpmn, por sus siglas en inglés [Business Process Model Notation] (omg-bpmn, 2006), que define las técnicas de modelado de proce-sos de negocio.

Metamodelo de la ingeniería de procesos de software Los procesos de desarrollo de software se han vuelto tan

complejos que es necesario el uso de lenguajes formales para mo-delarlos. Con este fin, la omg en el año 2001, creó el Metamode-lo de la Ingeniería de Procesos de Software (spem, por sus siglas en inglés [Software Process Engineering Metamodel]) (spem, 2006), el cual define un lenguaje estándar de modelado que permite describir tales procesos.

Esta línea de investigación tuvo su origen en un estudio que exploraba las sinergias entre las spl, la mde y la ingeniería de procesos software (Ávila-García et al., 2006) de una mane-ra estándar. spem es un metamodelo y un uml-Profile dedica-do al modelado de procesos software relacionados. spem se utili-za para modelar una familia de procesos software. El metamode-lo spem es muy extenso, ello permite el modelado de numerosos aspectos y problemas del proceso de desarrollo.

En este estándar, la idea sobre proceso de desarrollo soft-ware está centrada en la colaboración entre entidades abstrac-tas llamadas roles, que realizan operaciones llamadas actividades, sobre entidades de trabajo concretas llamadas productos de tra-bajo. El metamodelo spem permite relacionar cualquier elemen-to (por ejemplo, actividades, tareas, artefactos, etcétera) con ele-mentos guía que dan soporte a su manipulación.

Estas guías pueden ser desde tutoriales y ejemplos hasta plantillas y activos reutilizables. El proceso de configuración de

66


activos para generar una aplicación concreta puede ser modela-do a través de spem. El ingeniero de la aplicación debe realizar la tarea de configuración. Éste será el ejecutor de dicho proceso el cual, previamente, deberá diseñarlo un ingeniero de dominio, encargado además de crear los activos reutilizables así como las guías de configuración adecuadas para generar cada uno de los productos de la línea y de almacenarlos en la Baseline.El trabajo presentado en este libro, utilizó el estándar spem en todas las tareas llevadas a cabo para el modelado de los assets, incluyendo al plan de producción de la spl.

Especificación de activos reutilizables La Especificación de Activos Reutilizables (ras, por sus siglas en inglés [Reusable Asset Specification]) (ras, 2005), define la ma-nera estándar de empaquetar activos reutilizables, permitiendo identificar, describir y empaquetar un activo, por lo cual cumple con los requisitos para una reutilización efectiva.

Al respecto, Ávila-García et al. (2006) definen al acti-vo como una colección cohesiva de artefactos que resuelven un problema específico o conjunto de problemas, así como meta in-formación para facilitar la reutilización.

Un artefacto es un producto de trabajo que se realizó du-rante el ciclo de desarrollo de software como, por ejemplo, es-pecificaciones de requerimientos, modelos, archivos de código fuente, documentos xml, etcétera. En este contexto, un artefac-to es un archivo; la meta información se definió por un archivo xml que contendrá el modelo ras del activo (como se muestra en los trabajos de (Ávila-García et al., 2006)).

El modelo hace referencia a los artefactos contenidos en el activo, así como las actividades que definen procesos o guías de uso para el mismo. Estas actividades permitirán, entre otras cuestiones, configurar la variabilidad de los artefactos conteni-dos en el activo para obtener de éste soluciones concretas.

67


También, en el capítulo viii se muestra cómo se utilizó la técnica del estándar ras al empaquetar y desempaquetar los artefactos software del repositorio de assets (la Baseline).

Notación para el modelado de procesos de negocio Como consecuencia del creciente interés en las técnicas rela-tivas al modelado de procesos de negocio, en junio del 2005 la Iniciativa para la Gestión de los Procesos de Negocio (bpmi, por sus siglas en inglés [Business Process Management Iniciative]) (omg-bpmi, 2005) formó parte de la omg, publicando en febre-ro de 2006, la versión 1.0 final de la Notación para el Modela-do de Procesos de Negocio (bpmn, por sus siglas en inglés [Business Process Model and Notation]) (omg-bpmn, 2006).

Antes de la absorción de la bpmi por la omg, los diagra-mas de actividad de uml se usaban para el modelado de proce-sos de negocio pero, en la actualidad, todo parece indicar que la propia omg eligió a la bpmn para el modelado de procesos de ne-gocio. Según los propios autores, “bpmn se centra en los proce-sos de negocio, y los diagramas de actividad de uml se centran en el diseño de software; por lo tanto no son competidoras, si-no diferentes puntos de vista sobre un sistema”.

En lo relativo a los elementos gráficos de las dos nota-ciones, algunos trabajos como los de White (2004) afirman que bpmn es más rico gráficamente, con menos símbolos base y más variaciones de éstos, lo que facilita la comunicación sobre la complejidad de los procesos de negocio entre los distintos usua-rios involucrados. Según White (2004), los diagramas de activi-dad son una notación más técnica, mientras que bpmn está di-rigido a los usuarios de negocio, con lo cual puede interpretar-se que la notación bpmn es más comprensible para la gran ma-yoría de los usuarios.

En el tema variabilidad en el comportamiento de los sis-temas expertos (capítulo iv) de este libro, se muestra el uso de es-

68


te estándar al modelar los procesos de inferencia de los sistemas expertos de diagnóstico.

Lenguaje de modelado unificadoEl Lenguaje de Modelado Unificado (uml, por sus siglas en in-glés [Unified Modeling Language]) (uml, 2005)), es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. uml está res-paldado por la omg.

• Con el fin de que se comprenda lo que es el uml, a continua-ción se analizan cada una de las palabras que lo componen:

• Lenguaje: uml cuenta con una sintaxis bastante definida y una semántica intuitiva. Por lo tanto, al modelar un concepto en uml, existen reglas sobre cómo deben agruparse los elementos del lenguaje y el significado de esta agrupación.

• Modelado: mediante la sintaxis de uml se modelan distintos aspectos del mundo real, los cuales permiten una mejor in-terpretación y entendimiento de éste; es decir, uml es visual).

• Unificado: uml unifica diversas técnicas de modelado en sólo una. Por lo anterior, se concluye que uml es un lenguaje gráfi-

co para visualizar, especificar, construir y documentar un sistema de software. uml ofrece un estándar para construir un plano del sistema (modelo), incluyendo aspectos conceptuales tales como procesos y funciones, así como aspectos concretos, por ejemplo, expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables.

Es importante resaltar que uml es un lenguaje para es-pecificar (no para describir) métodos o procesos; se utiliza para definir un sistema de software y para detallar los artefactos soft-ware en el sistema; en otras palabras, es el lenguaje donde en el que está descrito el modelo.

Un modelo representa a un sistema software desde una perspectiva específica.

69


Por otro lado, al desarrollar el nuevo estándar 2.0 de uml, la omg se planteó, entre otros, dos objetivos principales, debido a la influencia de éstos en la nueva versión:

• Hacer el lenguaje de modelado más extensible. • Permitir la validación y ejecución de modelos. • uml 2.0 cuenta con 13 tipos de diagramas, los cuales muestran

diferentes aspectos de las entidades que representa. Cada uno de estos modelos permite fijarse en un aspecto distinto del sis-tema. Los modelos de uml 2.0 que se utilizaron en este traba-jo son los siguientes:

• Diagrama de clases.• Diagrama de casos de uso.• Diagrama de estados

Facilidad de meta-objetos En el caso específico de la mda, la omg propone la Facilidad de Meta Objetos (mof, por sus siglas en inglés [Meta Object Facili-ty]) (mof, 2006),) para expresar los metamodelos; es decir, mof es un lenguaje de metamodelado. Este lenguaje puede utilizar las Query/Views/Transformations (qvt) (qvt, 2005) para establecer las relaciones entre los metamodelos. Específicamente, el len-guaje de las qvt-Relations es usado para describir las relaciones.

• El metamodelado es un mecanismo que permite construir formalmente lenguajes de modelado, como lo es uml. La Ar-quitectura de Modelado de 4 Capas es la propuesta de la omg orientada a estandarizar conceptos relacionados con el mode-lado, desde los más abstractos a los más concretos. Los nive-les definidos en esta arquitectura se denominan comúnmente m3, m2, m1, y m0:

• El nivel m3 (meta-metamodelo) es el más abstracto, donde se encuentra mof, mismo que permite definir metamodelos con-cretos, por ejemplo, el metamodelo de uml.

• En el nivel m2 (metamodelo), sus elementos son lenguajes de modelado, por ejemplo uml. Los conceptos en este nivel pue-den ser clase, atributo, asociación, agregación, etcétera.

70


• En el nivel m1 (modelo), sus elementos son modelos de datos, por ejemplo, entidades como persona, atributos como nom-bre, y relaciones entre las entidades.El nivel m0 (instancia) modela al sistema real. Sus ele-

mentos son datos (por ejemplo, María).La definición de lenguajes para transformación de mo-

delos se encuentra en la capa m3, ya que una instancia específi-ca de transformación se ubica en la capa m2 para poder relacio-nar instancias genéricas de metamodelos concretos que se ubi-can en m2, entre cuyas instancias se produce la transformación. Es decir, los modelos que concretamente están involucrados en la transformación (capa m1) son parámetros para el lenguaje de transformación. El metamodelo para transformaciones y su ins-tanciación no pueden convivir en la misma capa, ya que repre-sentan distintos niveles de abstracción.

En la capa m3 se ubica mof, que provee un lenguaje pa-ra expresar los metamodelos. mof es usado para especificarse a sí mismo (en el nivel m3) y para especificar los metamodelos de las vistas y sus interacciones (en nivel m2). mof representa un me-tametamodelo cerrado sobre el que se instancian metamodelos (instancias de mof); en consecuencia, los metamodelos se ubi-can en la capa m2. En este libro se utilizó la versión mof 2.0.

Conclusiones Los espacios tecnológicos presentados en este capítulo ofrecen una funcionalidad conjunta y coordinada para la generación au-tomática de aplicaciones. En particular, con la aproximación bom se pretende mejorar el desarrollo de los sistemas expertos a través de lo siguiente:

• Al usar las ventajas que proporcionan los propios sistemas ex-pertos al separar los procesos de inferencia de la información del conocimiento de un dominio específico, e incorporar varias estrategias de razonamiento para resolver un problema, apli-cando la manera más eficiente.

71


• Al construir sistemas de manera simple, con ontologías del diagnóstico y de los dominios de aplicación. De esta manera se ofrece un acercamiento al lenguaje específico del dominio (dsl) del problema, lo que facilita la interacción con el usuario.

• Al aplicar las técnicas de spl con el fin de construir un dise-ño que compartan todos los miembros de una familia de pro-gramas. De esta manera, un diseño específico puede usarse en diferentes productos, lo que reduce los costos, los tiempos de producción, el esfuerzo y la complejidad.

• Al construir las arquitecturas de las spl en el marco del modelo prisma, donde se integrarán componentes y aspectos reutiliza-bles, lo cual facilita su mantenimiento y complejidad.

• Al aplicar técnicas de la mda con el fin de implementar los sis-temas sobre diferentes plataformas, y transformarlos para ob-tener una aplicación ejecutable.

• Al desarrollar sistemas independientes de plataforma, aborda-dos desde la perspectiva del problema y no de la solución; ello proveerá generalidad en la aproximación desarrollada y aplica-bilidad en diferentes dominios.

Parte II Preliminares

Ilustr

ació

n de

Víct

or O

dín

Gar

cía R

odríg

uez.

75

Capítulo II

Arquitecturas software de la línea de productos

Los conceptos y principios fundamentales de la ciencia son invenciones libres del espíritu humano.

Albert Einstein

La taxonomía de los sistemas software (sw) involucra la clasi-ficación de dichos sistemas (véase figura 10). Dentro de esta

taxonomía se encuentran los sistemas expertos, los cuales son una clase de sistemas software, por ello la relación entre ambos es del tipo is_a. Esta especialización de clases permite que la tipología de los sistemas expertos pueda igualmente ser representada a través de una relación del tipo is_a con la clase sistemas expertos (es) (véase figura 11).

Este libro se enfoca en el dominio del diagnóstico, es de-cir, en los se que realizan tareas de diagnóstico. Tal elección se debe a que, como se mencionó, el dominio más demandado por el mercado se lleva a cabo en esta temática, así como por la ex-periencia que los autores del presente trabajo poseen sobre el de-sarrollo de éstos. Sin embargo, con el fin de fortalecer dicha ex-periencia los mismos efectuaron un estudio de campo el cual se presenta en el capítulo iii.

76


Los casos de este estudio muestran que existen diferentes tipos de diagnóstico (diagnóstico médico, diagnóstico educati-vo, etcétera). Dentro de la taxonomía, esta tipología se sitúa co-mo una especialización de los sistemas expertos de diagnósti-co (des), por lo que entre ellos existe también una relación is_a (véase figura 11).

Finalmente, esta tipología es aplicada al espécimen; por ejemplo, en el diagnóstico médico puede aplicarse para detectar enfermedades infecciosas infantiles, enfermedades cardiovascu-lares, etcétera, por lo tanto, existe una instanciación; es decir, el sistema que diagnostica las enfermedades infecciosas infantiles es una instancia de los des de diagnóstico médico, por ejemplo. Por ello, y a diferencia de las anteriormente comentadas, la re-lación que existe entre ambos es is_instante_of (véase figura 10).

Figura 10. Taxonomía de los sistemas software

SW SYSTEMS

ACCOUNTING SYSTEMS EXPERT SYSTEMS(ES) PAYROLL SYSTEMS

…PREDICTIONES

DIAGNOSTICES

INTERPRETATIONES

…

…MEDICALDIAGNOSIS

EDUCATIONALDIAGNOSIS

EMERGENCY DIAGNOSIS

…INFANTILE INFECTIOUSUS

DISEASESCARDIOVASCULAR

DISEASES

is_instance_of

is_a

is_a

is_a

Fuente: Elaboración propia.

77

Capítulo II. Arquitecturas software de la línea de productos

Arquitectura de los sistemas expertosUno de los activos más importantes de una spl es su arquitectu-ra denominada la Arquitectura de la Línea de Productos (alp), debido a que ésta define cómo los elementos software se integran para crear un sistema y, a su vez, define la funcionalidad básica de los productos que serán desarrollados. En este libro la arqui-tectura de la spl se corresponde con la arquitectura de los siste-mas expertos o sistemas basados en el conocimiento que reali-zan diagnóstico. En este contexto, la aproximación bom es un framework que genera sistemas expertos de diagnóstico (des) en un dominio particular (es decir, una spl).

Como se muestra en la figura 11, la arquitectura típica de un sistema experto cuenta con varios módulos (Turban y Aron-son, 2001): la base de conocimientos, la memoria de trabajo, el mecanismo de inferencia, la interfaz de entrada/salida, el módu-lo de explicaciones y el módulo de aprendizaje. Sin embargo, no todos los sistemas expertos son construidos con la totalidad de dichos módulos. La base de conocimientos, la memoria de tra-bajo, el mecanismo de inferencia y la interfaz de entrada/salida se encuentran en todo sistema experto basado en reglas, mien-tras que el módulo de explicaciones pudiera no estar presente en alguno de ellos y el módulo de aprendizaje sólo está presente en unos cuantos.

La base de conocimientos contiene reglas, hechos e infor-mación acerca de un dominio especializado de conocimientos. Este conocimiento es utilizado por el mecanismo de inferen-cia para formular hipótesis. La cantidad y la calidad de los con-ocimientos contenidos en la base de conocimientos determinan la bondad del sistema experto en la solución de problemas del dominio.

La memoria de trabajo es un almacén temporal de infor-mación dinámica. En ésta es almacenada, en forma de hechos, toda la información aportada por el usuario al sistema (datos ini-

78


ciales y respuestas a preguntas formuladas), así como las conclu-siones de todas las reglas disparadas en el transcurso del proce-so de inferencia. Cuando el proceso de solución de un problema particular ha concluido, el contenido de la memoria de trabajo es borrado o eliminado, de forma tal que esta memoria queda limpia antes de iniciar la solución de otro problema. La memo-ria de trabajo es tratada como un módulo independiente o bien es incorporada al módulo de la base de conocimientos.

En el mecanismo de inferencia, los procesos de inferen-cia de estos sistemas se llevan a cabo a través de estrategias de ra-zonamiento como el encadenamiento de reglas hacia adelante y hacia atrás o como resultado de una combinación de éstos.

La interfaz de entrada/salida permite la comunicación en-tre el usuario y el sistema. A través de ésta el usuario ofrece datos iniciales al sistema o responde preguntas formuladas por éste. La gran mayoría de las interfaces de comunicación conocidas esta-blecen la comunicación usuario-sistema mediante simples me-nús de selección para los cuales se utilizan lenguajes restringidos, éstos son aproximaciones cercanas al lenguaje cotidiano.

Figura 11. Arquitectura de un sistema experto


79


Arquitectura genérica y arquitecturas base de los sistemas expertos de diagnósticoEn las spl existen partes comunes y partes variables de los pro-ductos, en el caso de este libro, los sistemas expertos de diagnós-tico (des). La parte común está representada por la arquitectu-ra genérica, la cual capta la funcionalidad de dichos sistemas, es decir, la funcionalidad compartida de cada producto. La parte variable involucra las características particulares adicionales que definen los productos concretos, representados por las arquitec-turas base.

Sin embargo, los productos concretos pueden compar-tir características comunes, lo que implica formar familias repre-sentadas por las arquitecturas base, como se muestra en la figu-ra 9. De esta manera, la arquitectura genérica es el representan-te canónico de las arquitecturas base (es decir, las familias) y una arquitectura base es el representante canónico de la familia de productos con la que se corresponde. Por lo tanto, la arquitectu-ra genérica es el representante canónico de toda la spl.

Figura 12. Metáfora visual de la relación que existe entre los representantes canónicos de la spl

Family 4(Base Arch. 4)

Family 1(Base Arch. 1) Family 2

(Base Arch. 2)

Family 3(Base Arch. 3)

Product1

Product10

Product2

Product4

Product9

Product6

Product7

Product8

Product12

Product3 Product

5

Product11

SystemDOMAIN (Generic

Arch.)


80


Con el objetivo de conocer la arquitectura de los des, se realizó un estudio de campo. Las fuentes en que se basa este es-tudio contemplan desde bibliografía consultada en libros de la temática (Turban y Aronson, 2001; Giarratano y Riley, 2004), y estudios realizados en la metodología y tipología de los se (Liao, 2005), hasta consultas con profesores de asignaturas relaciona-das con el conocimiento de los sistemas expertos, y la propia ex-periencia de los autores del presente trabajo, en el desarrollo de los des.

Con base en el estudio de campo, se detectó que la arqui-tectura genérica que captura la funcionalidad de esos sistemas puede representarse por tres módulos básicos, como se muestra en las figuras 13 y 14.

Figura 13. Módulos esenciales que integran un des

INFERENCE MOTOR

KNOWLEDGE BASE

USER INTERFACE


El módulo InferenceMotor establece el proceso de infe-rencia y toma decisiones. El módulo KnowledgeBase contiene el conocimiento del dominio de aplicación; dicho módulo integra el Módulo de Base de Hechos o Memoria de Trabajo y el Módu-lo de Base de Conocimientos. Por último, el módulo UserInter-face establece la interacción hombre-máquina.

81


Figura 14. Arquitectura genérica en el dominio de los des

SystemDOMAIN (Generic

Arch.)

INFERENCE MOTOR

KNOWLEDGE BASE

USER INERFACE


Sin embargo, la arquitectura software de la spl en bom (esto es, la arquitectura genérica de los des) es implementada con arquitecturas tipo prisma, de esta manera se obtienen las ventajas (reutilización, compilación, etcétera) de los modelos prisma al incorporar las aproximaciones del desarrollo de soft-ware basado en componentes y el desarrollo de software orien-tado a aspectos. La elección de esta representación se debe a que la correspondencia entre ambos modelos tiene un pequeño gap semántico. Como lo muestra, con flechas, la figura 15, en esta relación se corresponden uno a uno los módulos y los compo-nentes InferenceMotor, KnowledgeBase y UserInterface. Sin em-bargo, para ser consistente con el metamodelo de prisma, es necesario incorporar un nuevo elemento arquitectónico, esto es, el conector, el cual establece la comunicación entre los compo-nentes. Los attachments son las conexiones (canales de comuni-cación) entre componentes y conectores.

82


Figura 15. Correspondencia entre la arquitectura genérica de un des (a) y una arquitectura base (b)

INFERENCEMOTOR

KNOWLEDGE BASE

USERINTERFACE

CONNECTOR

INFERENCE MOTOR

KNOWLEDGE BASE

USER INTERFACE

(a) (b)Fuente: Elaboración propia.

De esta manera, se obtiene una arquitectura base cuando se parte de la arquitectura genérica de una spl; sin embargo, du-rante el proceso para desarrollar una aplicación concreta (miem-bro de la línea de productos), ésta se deriva a partir de una ar-quitectura ligada al dominio: la arquitectura genérica, pero exis-ten características particulares adicionales cuya presencia/ausen-cia define el producto concreto. Esta situación puede requerir eliminar o añadir componentes o relaciones entre ellos, desarro-llar extensiones en los componentes existentes, así como confi-gurar los componentes y desarrollar elementos software especí-ficos para las arquitecturas base. Lo anterior implica la creación de una arquitectura base específica, cada vez que se desarrolla un producto de la línea. En este contexto, la figura 15 presenta la correspondencia entre la arquitectura genérica y una arquitectu-ra base distinta a la que se muestra en la figura 16 asociada a un caso de estudio distinto.

83


Figura 16. Correspondencia entre la arquitectura genérica de un des (a) y una arquitectura base (b)

INFERENCE MOTOR

KNOWLEDGE BASE

USER INTERFACE

INFERENCE MOTOR

KNOWLEDGEBASE

CLINICAL USER INTERFACE

LABORATORY USER INTERFACE

Connector 1

Connector 2

Connector 3

(a) (b) Fuente: Elaboración propia.

La figura 17 muestra una metáfora visual de dos arquitec-turas base distintas derivadas de la misma arquitectura genérica.Figura 17. Metáfora visual de una única arquitectura genérica

(a) y dos arquitecturas base (b)

INFERENCE MOTOR

KNOWLEDGE BASE

USER INERFACE

.

.

.

INFERENCEMOTOR

KNOWLEDGE BASE

USERINTERFACE

CONNECTOR

INFERENCE MOTOR

KNOWLEDGEBASE

CLINICAL USER INTERFACE

LABORATORY USER INTERFACE

Connector 1

Connector 2

Connector 3


84


La técnica de modelado para construir sistemas con ar-quitecturas base parte de la especificación dada por los requisi-tos funcionales que el producto final ha de satisfacer, los cuales son modelados mediante un diagrama de casos de uso de uml. En particular, las variantes relevantes relacionadas con la variabi-lidad en la estructura de un sistema son: el número de casos de uso, el número de actores y el número de casos de uso a los que puede acceder un actor (este punto se trata con detalle en el ca-pítulo vi de este libro).

De lo anteriormente dicho, se deduce que la taxonomía de los se, desde la perspectiva de las spl, se refleja en las rela-ciones is_a e is_instance_of. La variabilidad ligada a la semán-tica de la relación is_a se plasma en la transformación de la ar-quitectura genérica a las arquitecturas base, y la semántica de la variabilidad ligada a la relación is_instance_of se plasma en la transformación de las arquitecturas base a las arquitecturas de los productos finales, como se muestra en la figura 18.

85


Figura 18. Esquematización referente a la taxonomía de los des y las arquitecturas de la spl


86


ConclusionesComo se observó en este capítulo, la arquitectura base de los des no es única, sino que existe variabilidad en dichas arquitecturas y por consiguiente en el funcionamiento de estos sistemas. Asi-mismo se observa que la relación is_a (es decir, de herencia) so-portada por la taxonomía de dichos sistemas, se corresponde con la funcionalidad de la arquitectura genérica de los des, la cual es heredada por todos los miembros de la familia de productos software (esto es, la arquitectura base). Por último, la variabili-dad ligada a la semántica de la relación is_instance_of se corre-sponde con la arquitectura del producto final específica del do-minio de aplicación.

Con el propósito de conocer la variabilidad, se realizó un estudio de campo sobre el comportamiento y la estructura de los sistemas expertos basados en reglas de un dominio específi-co; para ello, se eligió el dominio del diagnóstico también me-diante un estudio de campo en este dominio. En el capítulo iv se presenta el análisis del diagnóstico en el que se muestra la va-riabilidad del dominio; por su parte, el capitulo v analiza la ar-quitectura y comportamiento de los des con el fin de mostrar la funcionalidad del dominio.

87

Capítulo iii

El diagnóstico: la variabilidad del dominio

El experimentador que no sabe lo que está buscando no comprenderá lo que encuentra.

Claude Bernard

En este capítulo se muestra el estudio de campo realizado en un dominio particular: el diagnóstico. Con este fin se presentan

diferentes casos de estudio que sirvieron de base para analizar las características que presenta el dominio del diagnóstico y de los dominios de aplicación. Los cinco casos de estudio son los siguientes:

• El diagnóstico médico para detectar la enfermedad que pade-ce un paciente.

• El diagnóstico de víctimas por desastres, para clasificar a éstas. • El diagnóstico televisivo que indica si un video es considerado

como adecuado o no para ser transmitido al aire. • El diagnóstico de programas educativos para calificar la etapa

de desarrollo en que se encuentra los mismos.• El diagnóstico de candidatos a beca para decidir si ésta es otor-

gada o no.Así pues, con el objetivo de conocer los dominios de ca-

da caso, se llevaron a cabo reuniones con expertos en dichos do-minios de aplicación. De esta manera, uno de los autores del presente trabajo, quien asumió el rol de ingeniero del cono-cimiento, obtuvo las variables observables, las reglas que relacio-nan dichas variables y los resultados del diagnóstico (objetivos) que pueden obtenerse al final de este proceso.

Las fuentes en las que se basó el estudio de campo fueron las siguientes:

88


• Un pediatra proporcionó la información sobre el diagnósti-co médico, donde se particularizó en enfermedades infeccio-sas infantiles.

• La información referente al diagnóstico de víctimas por desas-tres, y su clasificación, la proveyó un paramédico y voluntario de la institución Cruz Roja Mexicana.

• Un funcionario de la Red edusat, la cual se encuentra adscri-ta a la Dirección General de Televisión Educativa de la Secre-taría de Educación Pública de México, proporcionó informa-ción para estudiar el diagnóstico televisivo.

• El diagnóstico de programas educativos (particularmente los posgrados en física) está enfocado a la evaluación de éstos, y el mismo lo realizó el Consejo Nacional de Ciencia y Tecnolo-gía de México (conacyt), a través de pares académicos, quie-nes publicaron los criterios de evaluación y los resultados ob-tenidos (conacyt, 1997).

• Finalmente, para el diagnóstico de candidatos a beca, la infor-mación fue proporcionada por quien fungía como responsa-ble de dicha área, la cual pertenece al conacyt. Al respecto debe comentarse que, para el estudio de cam-

po, se consideró suficiente la información adquirida con estos cinco casos de estudio, ya que se lograron identificar las carac-terísticas de la variabilidad asociada con el diagnóstico, lo cual muestra la viabilidad de su aplicación en bom. Además, pueden añadirse más casos de estudio debido a que bom es una aproxi-mación reactiva, en la cual no se establece desde un principio el dominio de la línea de productos, sino que se incluirán paulati-namente nuevos productos a medida que aparezca la necesidad de producirlos.

Sobre el análisis que se realizó a través del estudio de cam-po, se concluye lo siguiente: El diagnóstico consiste en interpre-tar el estado de una entidad, o en su caso, identificar el proble-ma o disfunción de una entidad, a través de sus propiedades (va-riables observables).

89

Capítulo III. El diagnóstico: la variabilidad del dominio

Un proceso de diagnóstico es el conjunto de tareas en-caminadas a la identificación de una anomalía o propiedad a partir de variables observables y razonamientos.

Una entidad es el sujeto al que se le realiza el diagnósti-co. Una hipótesis es el objetivo o resultado del proceso de diag-nóstico. Cuando se identifica el problema o disfunción que pre-senta una entidad, se obtiene una hipótesis. Por ello el objetivo que persigue el proceso del diagnóstico es obtener un resultado del diagnóstico o validación de una hipótesis.

Las propiedades de una entidad son la caracterización mediante datos de las causas que provocan una anomalía o dis-función de la misma. Estas propiedades pueden tener n niveles de abstracción, y se relacionan en interniveles a través de reglas.

Durante el proceso del diagnóstico, las propiedades rele-vantes con las que se analiza una entidad pueden ser siempre las mismas o diferentes. Además la entidad está caracterizada por un conjunto específico de propiedades que varían según la hi-pótesis a validar. Esto implica dos tipos de vistas sobre las enti-dades: la vista constante donde las propiedades son siempre las mismas en el proceso del diagnóstico, y la vista variable donde las propiedades cambian durante dicho proceso.

Dichas vistas están implícitas en el número de hipótesis que se obtienen en el transcurso de la realización del diagnósti-co. Si se tiene la misma vista de la entidad, es decir, las propie-dades durante el proceso del diagnóstico no cambian, se llegará a una única hipótesis o resultado del diagnóstico y, por el con-trario, si la vista cambia, esto es, las propiedades durante el pro-ceso del diagnóstico son diferentes, puede obtenerse más de una hipótesis, lo que implica que dichas hipótesis deberán ser valida-das hasta obtener la hipótesis correcta que corresponde al resul-tado del diagnóstico.

Este comportamiento se representa mediante estrategias de razonamiento que se aplican durante el proceso del diagnós-

90


tico. De esta forma, si existe una sola hipótesis será aplicado el razonamiento deductivo, ya que este tipo de estrategia deduce la hipótesis a partir de las propiedades de la entidad. Sin embargo, si estamos ante la presencia de varias hipótesis, es necesario rea-lizar un razonamiento diferencial para elegir la hipótesis correc-ta de entre todas las posibles, combinando estrategias deducti-vas e inductivas.

Casos de estudio

Diagnóstico médico En este tipo de dignóstico, la entidad a diagnosticar es el pa-ciente y el resultado del diagnóstico es la enfermedad que pade-ce el paciente. Las propiedades de las entidades cambian, es de-cir, son diferentes en cada hipótesis que puede resultar del pro-ceso del diagnóstico.

En este tipo de diagnóstico pueden considerarse los si-guientes casos de uso:

• Caso de uso 1: realizar diagnóstico clínico.• Caso de uso 2: realizar diagnóstico de laboratorio.• Caso de uso 3: obtener resultados del diagnóstico (realizar diag-

nóstico integral).Los casos de uso se llevan a cabo por dos usuarios fina-

les distintos: el médico y el responsable del laboratorio. Los ca-sos de uso 1 y 3 son realizados por el médico. El caso de uso 2 es realizado por el responsable del laboratorio. Las propiedades son los signos y síntomas del paciente, los cuales están clasifica-dos en dos niveles de abstracción: los de grano grueso y los de grano fino.

Las propiedades del nivel 0 son los signos y síntomas de grano grueso (por ejemplo, tos y fiebre). Las propiedades del nivel 1 son los signos y síntomas de grano fino (por ejemplo, tos seca y fiebre continua).

91


Las hipótesis del nivel 1 son los síndromes (por ejemp-lo, ira), que son inferidos a través de las reglas del nivel 1. Las hipótesis del nivel 2 son las enfermedades (.por ejemplo, neu-monía), es decir, el resultado del diagnóstico inferido a través de las reglas del último nivel.

El tipo de razonamiento aplicado es el diferencial. Al ini-cio se realiza un razonamiento deductivo del cual se infieren varias hipótesis (es decir, posibles enfermedades), por lo que se invoca al razonamiento inductivo para diferenciar esas hipótesis, así se obtiene la hipótesis validada, que es el resultado del diag-nóstico (es decir, la enfermedad).

El escenario donde se desarrolla el proceso del diagnósti-co médico es el siguiente: con valores de los signos y síntomas de grano grueso, es inferido el síndrome. Esta parte del proceso se realiza con el razonamiento deductivo. Dicho síndrome da lugar (por deducción) a dos o más posibles enfermedades (posibles hi-pótesis). Estas hipótesis deben ser validadas por lo que, median-te los datos de los signos y síntomas de grano fino, se infiere la enfermedad (hipótesis validada) que padece el paciente. Esta úl-tima parte del proceso se realiza con el razonamiento inductivo.

En el grafo que a continuación se presenta (figura 19) só-lo se han incluido, por simplicidad, cinco hipótesis (enferme-dades) que pueden derivarse durante el proceso del diagnósti-co médico.

92


Figura 19. Grafo del diagnóstico médico

ENFERMEDAD 1

síndrome 1

signos y síntomas de grano grueso

síndrome 2

ENFERMEDAD 2

ENFERMEDAD 3

ENFERMEDAD 4

ENFERMEDAD 5

signos y síntomas de grano fino


Diagnóstico de desastresEn este tipo de diagnóstico, la entidad a diagnosticar es la víc-tima del desastre, y el resultado del diagnóstico es el color de la etiqueta que se le coloca a la víctima, la cual identifica el tipo de atención que deberá darse a la misma en determinada emergen-cia. Las propiedades de las entidades son diferentes en cada hi-pótesis que puede resultar en el proceso del diagnóstico. Este caso de estudio cuenta solamente con un caso de uso (indicar etiqueta) y un usuario final que desempeña un rol.

Las propiedades en este caso de estudio son los signos vi-tales que manifiesta la víctima. Las propiedades del nivel 0 son la indicación de si una víctima es o no ambulatoria. Las propie-dades del nivel 1 son el resto de los signos vitales (por ejemplo, perfusión).

Las hipótesis representan el estado de intervención de emergencia en la víctima (por ejemplo, inmediato), es decir, el resultado del diagnóstico inferido a través de las reglas del últi-mo nivel.

93


El tipo de razonamiento aplicado es el diferencial. Al ini-cio se realiza un razonamiento deductivo del cual se infiere una hipótesis que será el resultado del diagnóstico, o bien pueden in-ferirse varias hipótesis, por lo que se invoca al razonamiento in-ductivo para diferenciar entre esas hipótesis, así se obtendrá la hipótesis validada, es decir, el resultado del diagnóstico.

El escenario para el proceso del diagnóstico de desastres es el siguiente: con valores del signo vital de si es, o no, ambula-toria la víctima, es inferida la hipótesis final (menor importan-cia) con lo cual termina el proceso del diagnóstico, o bien las posibles hipótesis (atención inmediata, no salvable, retardado). Esta parte del proceso se realiza con el razonamiento deductivo. En el caso de que se hayan generado varias hipótesis, éstas deben ser validadas, por lo tanto, con los datos que proporcione el res-to de los signos vitales observados en la víctima, se infiere la eti-queta que se colocará a ésta (hipótesis validada). Este última par-te del proceso se realiza con el razonamiento inductivo.

Figura 20. Grafo del diagnóstico en desastres

MENOR IMPORTANCIA(VERDE)

caminar ambulatorio

INMEDIATO(ROJO)

caminar no ambulatorio

ventilación no ventila

NO SALVABLE(NEGRO)

RETARDADO(AMARILLO)

vías aéreasno respira

vías aéreassi respira

ventilación no ventila

frec.resp<30/min

act mental positiva

ventilación si ventila frec.resp

>=30/min

ventilaciónsi ventila

frec.resp<30/min

perfusión< 2 seg

act mental negativa

ventilaciónsi ventila

frec.resp<30/min

perfusión>2 seg


94


Diagnóstico de candidatos a becaEn esta clase de diagnóstico educativo, la entidad a diagnosticar es un candidato a beca, y el resultado del diagnóstico es la decisión de si se le debe otorgar la beca a dicho candidato. Las propie-dades con las que son consideradas las entidades son las mis-mas, por lo que se genera una sola hipótesis que resulta del mis-mo proceso.

Este caso de estudio cuenta con un caso de uso (realizar decisión de otorgamiento) y un usuario final que desempeña un solo rol. Las propiedades son los requisitos que debe cumplir el candidato para ser beneficiado con una beca, y corresponden al nivel 0 (por ejemplo, promedio de calificaciones). La hipótesis es la indicación de si debe otorgarse la beca al candidato, es de-cir, el resultado del diagnóstico inferido a través de las reglas del nivel 1 (único nivel de reglas en este caso de estudio).

El tipo de razonamiento aplicado a dicho caso es el de-ductivo. El escenario para el proceso del diagnóstico de becas es el siguiente: con valores sobre los requisitos que debe cumplir un candidato a beca, es inferida la hipótesis, así se deduce si se otor-ga, o no, la beca.

Figura 21. Grafo sobre el diagnóstico de candidato a beca

DECISIÓN DE OTORGAMIENTO

posgrado de calidad

aceptaciónal programa

nivel del programa

área promedio nacionalidad edad


95


Diagnóstico de programas educativos En esta clase de diagnóstico educativo, la entidad a diagnosticar es un programa educativo de posgrado, y el resultado del diag-nóstico es el nivel de desarrollo que presenta el programa educa-tivo. Las propiedades con las cuales se analizan las entidades no cambian, por lo que se genera una sola hipótesis que resulta de tal proceso.

En este diagnóstico se consideró un caso de uso (obtener nivel de desarrollo) y un usuario final que desempeña un rol. Las propiedades son los rubros y sub rubros evaluados de un pro-grama educativo. Las propiedades del nivel 0 son los subrubros (por ejemplo, control de calidad de alumnos). Las propiedades del nivel 1 son los rubros cuyo valor es inferido al aplicarse las reglas del nivel 1 (por ejemplo, plan de estudios).

La hipótesis es la valoración que se le otorga al progra-ma educativo según su estado de desarrollo, es decir, el resulta-do del diagnóstico inferido a través de las reglas del nivel 2. El tipo de razonamiento aplicado es el deductivo, y el escenario pa-ra el proceso del diagnóstico educativo es el siguiente: con valo-res de los sub rubros involucrados en la evaluación del progra-ma educativo es inferido, por deducción, el valor de los rubros y posteriormente es inferida la hipótesis, de esta manera se de-duce cuál es la etapa en la que se encuentra el desarrollo del pro-grama educativo.

96


Figura 22. Grafo sobre el diagnóstico de programas educativosETAPA DE DESAROLLO

infraestructura plan de estudios profesorado alumnado

biblioteca yhemeroteca

cómputo

laboratorios

edificios enstalaciones

serviciosgenerales

diseñogeneral

controlcalidadalumnos

exp. invest.alumnos

no. cursos

duraciónprogramada

masacrítica

formaciónacadémica

productividadcientífica

grupos y líneasde investigación

poblaciónestudiantil tasa de

graduación

tiempo degraduación

calidad deegresados

control yseguimientoescolar


Diagnóstico televisivoAquí la entidad a diagnosticar es un video, y el resultado del di-agnóstico es la calidad del video con el fin de decidir si debe transmitirse al aire. Las propiedades de las entidades son las mis-mas, por lo que se genera una sola hipótesis que resulta de este proceso.

En este caso de estudio se contempló un caso de uso (ob-tener decisión de transmisión) y un usuario final que desem-peña un rol. Las propiedades son las características del video. Las propiedades del nivel 0 son los sub rubros que se evaluarán sobre determinado video (por ejemplo, imágenes). Las propie-dades del nivel 1 son los rubros que caracterizan un video, cuyo valor es inferido al aplicar las reglas del nivel 1 (por ejemplo, producción).

La hipótesis es el estado en el que se encuentra el video, es decir, el resultado del diagnóstico inferido a través de las re-glas del nivel 2. El tipo de razonamiento aplicado es el deducti-vo, y el escenario para el proceso del diagnóstico televisivo es el siguiente: mediante los valores de los sub rubros del video es in-

97


ferido, por deducción, el valor de los rubros que caracterizan a éste y finalmente se infiere la hipótesis, así se deduce cuál es el estado del video.

Figura 23. Grafo sobre el diagnóstico televisivo

ESTADO DEL VIDEO

producción contenido calidad técnica

imágenes

estructuratelevisiva

recursos televisivos

música

tratamiento

información

cumple objetivo

audio video cinta


La siguiente tabla (3) muestra un resumen de las diferen-tes características de cada uno de los casos de estudio realizados:

98


Tabl

a 3.

Tip

os d

e di

agnó

stico

(y su

s car

acte

rístic

as p

rinci

pale

s) e

studi

ados

en

este

trab

ajo

11

12

1

vid

eo/t

ran

smit

vid

eo

5

11

12

14

111 2

112

113

Use

U

se

Cas

esC

ases

321

Ded

uct

iv1

1

145

11

1D

edu

ctiv

e2

1T

V D

IAG

NO

SIS

5

11

1D

edu

ctiv

e2

1E

DU

CA

TIO

NA

L D

IAG

.4

111 1-2

112

113

321

Ded

uct

ive

11

SC

HO

RA

LS

HIP

DIA

G.

can

did

ate/

giv

esc

ho

lars

hip

Dif

fere

nti

al1

4D

ISA

ST

ER

DIA

GN

OS

IS

vict

im/la

bel

Dif

fere

nti

al2

5M

ED

ICA

L D

IAG

NO

SIS

pat

ien

t/d

isea

se

Rea

son

ing

Rea

son

ing

Vie

wV

iew

TY

PE

OF

DIA

GN

OS

IST

YP

E O

F D

IAG

NO

SIS

enti

tyen

tity

/dia

gn

osi

s/d

iag

no

sis

edu

cati

vep

rog

ram

/ d

evel

op

men

tals

tag

e

Hyp

oth

eses

Hyp

oth

eses

Pro

per

tyP

rop

erty

leve

lsle

vel s

Act

ors

Act

ors

Use

cas

es

Use

cas

es

per

per

act o

rac

tor

Sam

eP

rop

erti

es

Sam

eP

rop

erti

es

Sam

eP

rop

erti

es

Ch

ang

eP

rop

erti

es

Ch

ang

eP

rop

erti

es

99


Análisis de las características asociadas al diagnóstico De acuerdo con el estudio de campo descrito en la sección ante-rior, se concluye que existe variabilidad tanto en el proceso del diagnóstico como en los requisitos del usuario. Sin embargo, al considerar los campos específicos del dominio de aplicación, surge otra variabilidad.

Dado que la variabilidad puede ser descrita en términos de sus características, en las siguientes secciones de este capítu-lo se presenta el análisis de las características involucradas en el proceso del diagnóstico, los requisitos del usuario y el dominio de aplicación.

Análisis de las características involucradas en el proceso del diagnóstico Sobre este tema se observaron cuatro características (fuentes o puntos de variabilidad) que están presentes en el proceso del diagnóstico, y que a continuación se enuncian:

• Vista de las entidades. Una entidad puede ser considerada siem-pre con las mismas propiedades (misma vista); o bien, una en-tidad puede tener diferentes propiedades (diferentes vistas) du-rante el proceso del diagnóstico.

• Nivel de las propiedades. Las propiedades de las entidades pue-den tener uno o varios niveles de abstracción. Las reglas que re-lacionan las propiedades de la entidad interniveles tienen n-1 niveles, donde n es el nivel que presentan las propiedades de la entidad.

• Número de hipótesis. Es el objetivo o resultado del proceso del diagnóstico. Este proceso permite tener una o varias hipótesis candidatas, las cuales deberán ser validadas con el fin de selec-cionar la hipótesis correcta o la más certera.

100


• Tipo de razonamientos. Los razonamientos o estrategias de ra-zonamiento son la forma en que el mecanismo de inferencia realiza el diagnóstico mediante la información del dominio. Los razonamientos (en estos casos de estudio) pueden ser el deductivo, el inductivo y el diferencial (deductivo-inductivo). A continuación se muestra un ejemplo de las característi-

cas de esta variabilidad, correspondientes al caso de estudio pa-ra el diagnóstico médico:

Vista de la entidad: mismaNiveles de propiedades: 2Número de hipótesis: 5 (es decir, >1)Tipo de razonamiento: diferencial

Análisis de las características involucradas en los requisitos del usuario Al respecto se observaron tres características (fuentes o puntos de variabilidad) relacionadas con los requisitos del usuario, y que a continuación se enuncian:

• Número de casos de uso. Indica la división del sistema la cual se basada en la funcionalidad; es decir, las distintas operacio-nes que se esperan del sistema y cómo se relaciona con su en-torno (usuarios finales o actores).

• Número de actores. Éste permite representar al número de usuarios finales del sistema.

• Número de casos de uso por actor. Un actor puede acceder a uno o varios casos de uso.A continuación se muestra un ejemplo de las característi-

cas de esta variabilidad, correspondientes al caso de estudio so-bre el diagnóstico médico:

Número de casos de uso: 3Número de actores: 2Número de casos de uso por actor: 1, 1-2

101


Análisis de las características del dominioMediante este estudio de campo se consideraron a las caracterís-ticas relacionadas con el dominio, como las características que involucran tanto al proceso del diagnóstico, como las de los re-quisitos del usuario. Cada una de las características asociadas al dominio del diagnóstico, se plasman en el modelo de caracterís-ticas, en el árbol de decisión, y en el modelo conceptual del do-minio. De esta manera, las características del dominio son repre-sentadas a través de modelos que identifican a la spl en térmi-nos de la variabilidad.

Los casos de estudio presentados en este libro, se exponen en la tabla 4 a través de un resumen de dichas características, así como sus grafos, los cuales muestran: el nivel de propiedades, el número de hipótesis, el tipo de razonamiento, y la vista de las propiedades que presenta la entidad.

102


Tabla 4. Síntesis sobre la variabilidad del dominio que presentaron los casos de estudio realizados para este trabajo

Scholarship Diagnosis:candidate/

give scholarship

same propertiesdeductive reasoning1 hypothesis1 property level1 use case1 user: (he access to a uniqueuse case)

Educational Diagnosis:educational program/

developmental stage

same propertiesdeductive reasoning1 hypothesis2 property levels1 use case1 user: (he access to a uniqueuse case)

TV Diagnosis:video/transmit video

same propertiesdeductive reasoning1 hypothesis2 property levels1 use case1 user: (he access to a uniqueuse cases

Scholarship Diagnosis:candidate/

give scholarship

same propertiesdeductive reasoning1 hypothesis1 property level1 use case1 user: (he access to a uniqueuse case)

Educational Diagnosis:educational program/

developmental stage

same propertiesdeductive reasoning1 hypothesis2 property levels1 use case1 user: (he access to a uniqueuse case)

TV Diagnosis:video/transmit video

same propertiesdeductive reasoning1 hypothesis2 property levels1 use case1 user: (he access to a uniqueuse cases

TYPE OF DIAGNOSISENTITY/RESULT OF DIAGNOSIS

FEATURES(1 st. VARIABILITY)

GRAPHS

Medical Diagnosis:patient/disease

change propertiesdifferential reasoning5 hypotheses2 property levels3 use cases2 users: (user A acess to 2 use cases, and user B acess to 1 use case)

Disaster Diagnosis:victim/label

change propertiesdifferential reasoning4 hypotheses2 property levels1 use case1 user: (he access to a uniqueuse case)

TYPE OF DIAGNOSISENTITY/RESULT OF DIAGNOSIS

FEATURES(1 st. VARIABILITY)

GRAPHS

Medical Diagnosis:patient/disease

change propertiesdifferential reasoning5 hypotheses2 property levels3 use cases2 users: (user A acess to 2 use cases, and user B acess to 1 use case)

Disaster Diagnosis:victim/label

change propertiesdifferential reasoning4 hypotheses2 property levels1 use case1 user: (he access to a uniqueuse case)

Por su parte, la figura 24 representa el modelo de caracte-rísticas que ofrece la spl por medio de una notación similar a la que proponen Czarnecki y Antkiewicz (2005a), así como Batory

103


et al. (2006), a excepción de intercambiar los conectivos and y or por así convenir a los intereses del presente trabajo (notación aplicada a los grafos de las reglas o relaciones entre las entidades de las propiedades). El modelo organiza las características en una composición jerárquica donde la opcionalidad y la obligatorie-dad están presentes. Además de las relaciones jerárquicas, los modelos de características también permiten restricciones cruza-das en el árbol. Un ejemplo de una restricción cruzada en el ár-bol en nuestra línea de productos es que la entidad que tiene una vista en donde cambian sus propiedades implica obtener diver-sas hipótesis y realizar un razonamiento diferencial.

Figura 24. Modelo de características que representa al dominio del diagnóstico

DIAGNOSIS

Property Levels

ReasoningHypotheses

same change

1 2

1

deductive differential

Use Cases

1 3

Actors

1 2

Use Cases by Actor

1 1-2

NOMENCLATURE: and or

(select 1)mandatory optional

>1

Entity Views

Fuente: Adaptado de y Antkiewicz (2005a), así como de Batory et al. (2006).

De esta manera, puede construirse la especificación del modelo de características del diagnóstico, según la siguiente sin-taxis:

Diagnosis: entity_views property_levels hypotheses reasoning use_cases actors use_cases_by_actor;

Entity_views: same changeProperty_levels: 1 2

104


Hypotheses: 1 >1Reazoning: deductive differentialUse_cases: 1 3Actors: 1 2Use_cases_by_actor: 1 1-2

// cross Restrictions of the tree same implies 1 hypothesis deductive;change implies >1 hyphoteses differential;

Las opciones de variabilidad (características de la spl), observadas en el modelo de características del diagnóstico, están plasmadas en un árbol de decisión (figura 25), en corresponden-cia de una por cada nodo:

Figura 25. Árbol de decisión sobre las características de la spl

change

Reasoning

diferencialdeductiv e

Prop erty Levels

221

Use Cases

Actors

Use Cases by Actor

Hypotheses

1 >1

11 1 3

11 1

2

1 1 1

same

1- 2

Entity Views

Asimismo, la instancia concreta de estas características (las variantes) es introducida de acuerdo con su modelo con-ceptual. La figura 26 muestra el modelo conceptual del domi-

105


nio (mcd) del diagnóstico en el cual se especifica la ontología del diagnóstico que involucra características y particularidades del diagnóstico en el que se desenvolverá el sistema que se desea construir. Los conceptos mostrados en el modelo conceptual de esta figura, a través de un modelo de clases uml, son los nece-sarios para el modelado de un sistema experto desde una apro-ximación orientada al diagnóstico. Dichos conceptos se corres-ponden con la perspectiva cim del diagnóstico y describen ele-mentos propios del diagnóstico.

Figura 26. Modelo conceptual del dominio del diagnóstico

Análisis de las características del dominio de la aplicaciónAlgunas de las características seleccionadas del modelo de carac-terísticas deben explicitarse de acuerdo con el caso de estudio en el que se realiza la aplicación; de esta manera se conforma la on-tología respecto al dominio específico de aplicación. Dichas ca-racterísticas se enuncian a continuación:

• Nombre, tipo y nivel de las propiedades. Por nivel de abstrac-ción, las propiedades de la entidad a diagnosticar adquieren un nombre y un tipo.

106


• Reglas por niveles. Las reglas que relacionan las propiedades de la entidad adquieren el nombre y tipo de las propiedades que están presentes en los antecedentes y el consecuente de cada una de las reglas.

• Nombre, tipo y nivel de las hipótesis. Se adquiere el nombre y el tipo de las hipótesis a validar, por niveles, que produce el proceso del diagnóstico.A continuación se muestra un ejemplo de las propie-

dades, reglas e hipótesis obtenidas en el caso de estudio sobre el diagnóstico médico:

Propiedades del nivel 0: tos, fiebrePropiedades del nivel 1: tos seca, fiebre continuaHipótesis de nivel 1: ira, parotiditisHipótesis de nivel 2: neumonía, bronquitis, paperasRegla de nivel 1: if (fiebre=true and tos=true and dificultad_

respiratoria=tue) then síndrome=parotiditisRegla de nivel 2: if (fiebre_continua=true and tos_seca=true and parótidas_

anormales= true and ……….) then enfermedad=paperas

La figura 27 muestra la vista de la variabilidad que pre-senta el dominio de la aplicación en el modelo conceptual del dominio de la aplicación (MCDA).

107


Figura 27. Modelo conceptual que representa al dominio de la aplicación


ConclusionesEl estudio de la variabilidad en el diagnóstico, el cual se expuso en este capítulo, mostró que las características observadas en el proceso del diagnóstico y los requisitos del usuario pueden con-siderarse como puntos o fuentes de una primera variabilidad, y que adicionalmente deben ser consideradas las características del campo de aplicación, a través de una segunda variabilidad. Estas consideraciones sirven como introducción para analizar la varia-bilidad de los des en el siguiente capítulo.

109

Capítulo iv

Los sistemas expertos de diagnóstico: la funcionalidad del dominio

Si hay un secreto del buen éxito reside en la capacidad para apreciar el punto de vista del prójimo

y ver las cosas desde ese punto de vista así como del propio.Henri Ford

En este capítulo se presenta el análisis realizado a través del estudio de campo de los sistemas expertos basados en reglas,

que llevan a cabo tareas de diagnóstico. Mediante dicho análisis se concluye lo siguiente:

En el proceso de desarrollo de una aplicación concreta (miembro de la línea de productos), ésta debe derivarse a par-tir de la arquitectura genérica ligada al dominio. En este proce-so deben seleccionarse aquellas variantes que resultan apropiadas para los requisitos funcionales y no funcionales expresados por los usuarios del sistema. Las variantes seleccionadas deben consi-derarse en función de los requisitos particulares de la aplicación.

Por otro lado, al considerar el proceso de diagnóstico des-de la perspectiva de un sistema software, se induce que además de las características comentadas, se incluyan en la variabilidad algunos de los requisitos de los usuarios finales del sistema. Estas características se plasman en un diagrama de casos de uso, con lo cual se incorpora a la variabilidad del dominio, el número de casos de uso, el número de actores y el número de casos de uso a los que accede cada actor.

La razón de ello es que se ha detectado una forma dife-rente de realizar el proceso del diagnóstico en cada caso de uso y,

110


además, que dicho proceso puede dividirse en subprocesos, que a su vez pueden ser invocados por diferentes actores (en caso de que existan).

La coreografía del proceso de diagnóstico establece la sin-cronización entre el mecanismo de inferencia, la información del dominio y la IGU. Por ello, estos sistemas deben ser desarro-llados mediante la construcción de todos sus componentes de acuerdo al caso de estudio (o aplicación del dominio).

Esto implica que existe variabilidad en la base de conoci-mientos, el motor de inferencia y la interfaz del usuario. Explí-citamente, las estrategias de razonamiento difieren de un caso de estudio a otro, lo que implica que existe variabilidad en el mo-tor de inferencia; las propiedades de las entidades a diagnosticar difieren de un caso al otro, por lo que también existe variabili-dad en la base de conocimientos, ya que las propiedades de las entidades a diagnosticar difieren de un caso al otro; y finalmen-te, debido a que un operario del sistema puede desempeñar más de un rol, es decir, un mismo usuario puede solicitarle al sistema distintas funcionalidades (por ejemplo, diversos casos de uso de un diagrama UML), se concluye que la interfaz del usuario tam-bién involucra variabilidad.

Las propiedades de las entidades al relacionarse entre sí pueden cumplir reglas. A través de reglas, el proceso de diagnós-tico contempla diversos niveles de abstracción para las propieda-des de una entidad, y para la relación entre las propiedades a tra-vés de reglas, de forma que:

Las propiedades del nivel n y las propiedades del nivel n+1, se relacionan a través de las reglas de nivel n+1,

Las propiedades del nivel 0 obtienen su valor del usuario, Las propiedades del nivel n+1 se infieren aplicando las re-

glas del nivel n+1,El valor de las propiedades superiores al nivel 0, se puede

obtener del usuario o bien inferirse a través de las reglas.

111

Capítulo IV. Los sistemas expertos de diagnóstico: la funcionalidad...

Una relación entre las propiedades es una regla del tipo IF <premisa> THEN <conclusión>, i.e. una cláusula de Horn con cabeza, en donde la premisa y la conclusión de dichas reglas to-man valores de las propiedades. La base de conocimientos con-tiene este tipo de reglas que representan la información del do-minio de aplicación del diagnóstico y se representan mediante una estructura de árbol; mientras que el motor de inferencia al aplicar las estrategias de razonamiento, recorre el árbol, es decir, aplica las reglas.

Una estructura de árbol, como la generada por el encade-namiento de reglas, puede ser recorrida en dos sentidos: en an-chura (niveles), donde se contemplan todas las posibilidades de un nudo antes de pasar al siguiente nodo o bifurcación del árbol; y en profundidad (ramas) en el que no se toma otro nodo has-ta que no se ha desarrollado completamente una rama. Respec-to a la spl presentada en este libro, el motor de inferencia aplica el recorrido en profundidad.

Los razonamientos o estrategias de razonamiento son la forma en que el mecanismo de inferencia realiza el diagnóstico. Las estrategias de razonamiento son simulaciones de los tipos de razonamientos más comunes que usa una persona para realizar un diagnóstico. Sin embargo para llegar a una conclusión diag-nóstica, el experto del dominio trata de aplicar todas aquellas es-trategias de razonamiento que le permitan obtener un diagnós-tico de la forma más eficiente. En otras palabras, el tipo de ra-zonamiento que resulta más adecuado para solucionar una par-te del proceso del diagnóstico, no tiene porque ser el más ade-cuado para resolver otra parte del mismo. Además, no siempre se obtiene el diagnóstico con la misma técnica de razonamiento. Por ello, las estrategias de razonamiento relativas al mecanismo de inferencia, difieren de un caso de estudio a otro.

Es por ello que el mecanismo de inferencia aplica las es-trategias de razonamiento, utilizando la información del domi-

112


nio para obtener las propiedades. Los razonamientos aplicados para ilustrar bom en este libro son el deductivo, el inductivo y el diferencial, debido a que son de los más utilizados para reali-zar un diagnóstico.

Variabilidad en la estructura de los sistemas expertos de diagnósticoCon el propósito de mostrar que los elementos arquitectónicos de un sistema experto varían en su estructura, se modelaron los requisitos funcionales que presenta esta clase de sistemas, al apli-car una técnica de modelado para construir sistemas con arqui-tecturas con vista de componente-conector, desarrollada ex pro-feso para el presente trabajo.

La técnica de modelado para construir sistemas con ar-quitecturas base, parte de la especificación de los requisitos fun-cionales que el producto final ha de satisfacer, modelados me-diante un diagrama de casos de uso de uml. En particular, las variantes relevantes relacionadas con la variabilidad en la estruc-tura de un sistema son los siguientes: el número de casos de uso, el número de actores y el número de casos de uso a los que pue-de acceder un actor.

Este análisis muestra que la estructura de los elementos arquitectónicos varía según el número de casos de uso conside-rados, así como el número de actores y de los casos de uso a los que accede un actor. Los casos de uso constituyen una división del sistema la cual se basa en la funcionalidad. El diagrama de casos de uso muestra las distintas operaciones que se esperan del sistema y cómo se relaciona con su entorno (usuario).

La obtención de la arquitectura base, al partir de la arqui-tectura genérica, tiene en cuenta las particularidades (o features) que presenta el caso de diagnóstico considerado. Los elementos arquitectónicos de la arquitectura base se obtienen al identificar escenas funcionales del sistema y al asignar cada elemento a una

113


escena funcional. De esta manera, si la escena es simple o com-pleja, el elemento será un componente (componente simple) o un sistema (componente complejo), respectivamente. Donde el concepto escena “se caracteriza por las tareas que se desempeñan en la actividad siguiendo un determinado protocolo, los actores que las realizan y el espacio virtual o físico donde se desarrolla” (Pérez, 2003b).

De acuerdo con esto, se presenta paso a paso la técni-ca para modelar arquitecturas base, mediante un caso de estu-dio presentado por un sistema experto que realiza el diagnósti-co médico.

Especificar los requisitos funcionales (en un alto nivel de abstracción) mediante un diagrama uml de casos de uso. En es-te ejemplo aparecen tres casos de uso y dos actores, en donde un actor accede a dos casos de uso y el otro actor accede sólo a uno. Véase la siguiente figura (28).

Figura 28. Diagrama uml que ejemplifica un caso de uso sobre diagnóstico médico

Doctor Laboratory

member

Get Therapy

GetClinicalDiagnosis

GetLaboratoryDiagnosis

<<include>>

Get Diagnosis


Configurar un modelo arquitectónico, por cada caso de uso. En el caso de estudio contemplado, se obtuvieron tres casos de uso, por lo que se construyen tres modelos arquitectónicos. Véase la siguiente figura (29).

114


Figura 29. Modelos arquitectónicos correspondientes a cada caso de uso

a) caso de uso 1 b) caso de uso 2 c) caso de uso 3Fuente: Elaboración propia.

Construir el modelo arquitectónico final. Los elementos arquitectónicos definidos en cada caso de uso son modificados para obtener los elementos arquitectónicos del modelo final, a través de los siguientes criterios:

• Conectores: conservar los conectores, es decir, el número de conectores del modelo arquitectónico final es igual al núme-ro de casos de uso.

• Componentes: unir los componentes, es decir, obtener un com-ponente por módulo y unir cada puerto del componente a un conector (por medio de un attachment). El número de puer-tos de cada componente del modelo final será igual al número de casos de uso donde fue utilizado dicho componente. En el ejemplo que nos ocupa, el modelo arquitectónico

final presenta la vista de la figura 30.

115


Figura 30. Modelo arquitectónico que representa a un sistema de diagnóstico médico


En este ejemplo, el modelo arquitectónico posee los si-guientes elementos:

• El componente InferenceMotor (con tres puertos).• El componente KnowledgeBase (con tres puertos).• El componente ClinicalUser (con dos puertos).• el componente LaboratoryUser (con un puerto).• El conector Coordinator 1.• El conector Coordinator 2.• El conector Coordinator 3.

116


De manera general, se concluye que los elementos del modelo arquitectónico base tienen las siguientes características:

• Conector Coordinator: por cada caso de uso, hay un conector coordinator que une a todos los componentes de ese caso de uso.

• Componente InferenceMotor: el número de puertos que po-see el componente InferenceMotor es igual al número de ca-sos de uso.

• Componente KnowledgeBase: el número de puertos del com-ponente KnowledgeBase es igual al número de casos de uso.

• Componente UserInterface: el número de componentes User-Interface es igual al número de actores que conforman el dia-grama de casos de uso. Asimismo, el número de puertos de un componente UserInterface es igual al número de casos de uso a los que puede acceder el actor (representado por dicho com-ponente).

Variabilidad en el comportamiento de los sistemas expertos de diagnósticoEl estudio de campo realizado en este trabajo, muestra que el comportamiento de los elementos arquitectónicos varía de acuerdo con el dominio de aplicación e implícitamente con el tipo de razonamiento usado al simular los razonamientos segui-dos por los humanos para emitir un diagnóstico. Dicho com-portamiento se basa en la estrategia de razonamiento que es apli-cada por el componente InferenceMotor para realizar el proceso del diagnóstico; es decir, si se aplica el razonamiento deductivo o el razonamiento diferencial, los procesos de inferencia son dis-tintos, como se muestra en la siguiente sección.

Procesos de inferencia En el componente InferenceMotor, a través del protocolo de su aspecto funcional, se especifica el proceso de decisión como una simulación de los razonamientos realizados por expertos para tomar una decisión (por ejemplo, al realizar un diagnóstico).

117


Tales razonamientos son representados en forma de procesos. De esta manera, la variabilidad existente entre los diversos com-ponentes InferenceMotor se corresponde con los diversos pro-cesos de decisión.

Conforme al análisis sobre el estudio de campo realiza-do, la spl que se utilizó en el presente trabajo contempla dos ti-pos en lo que concierne a procesos de decisión: el estático y el dinámico. El estático se corresponde con el hecho de que la vis-ta de la entidad a diagnosticar es la misma durante dicho proce-so. En el dinámico, por su parte, la vista de la entidad a diagnos-ticar es diferente durante el mismo proceso.

La variabilidad en el comportamiento entre los elemen-tos arquitectónicos de un se varía de acuerdo con la estrategia de razonamiento aplicada. Como se muestra en las figuras 31 y 34, dichas estrategias se corresponden con la vista de la entidad a diagnosticar durante el proceso de diagnóstico, el número de niveles de las propiedades de esa entidad y el número de hipóte-sis resultantes en éste.

En cuanto al mecanismo de inferencia para la toma de decisión (es decir, los procesos estático y dinámico), se modeló de diversas formas:

• A través de un diagrama de grafos.• Mediante el lenguaje Business Process Management Notation

(bpmn).• En un diagrama de transición de estados (en uml).

Asimismo se presenta la especificación de dichos procesos mediante los adl del modelo prisma, donde se utiliza un álge-bra de procesos: el pi-cálculo (Puhlmann, 2006).

◊ Proceso de inferencia estático En el proceso estático, una entidad siempre tiene las mismas propiedades durante el proceso del diagnóstico (es decir, la mis-ma vista), y sólo una hipótesis (meta u objetivo del diagnóstico). La figura 28 presenta un grafo de la metáfora visual referente al

118


proceso de inferencia estático; en éste se muestran los niveles i de las propiedades Pi (color azul) y la hipótesis Hi (color negro), así como el razonamiento deductivo (flechas hacia arriba) de dicho proceso. Las reglas de inferencia presentan la siguiente forma:

pj,i : pi ← pk, i-1* : pi -1 and hj,i : hi ← pk,i-1* : pi

Donde i = 0, 1 ,..., n (n = número de niveles), j,k :Nat y suponen una iteración sobre las propiedades de nivel i-1 usadas en la obtención de la propiedad j de nivel i (en el caso de k) y lo mismo pero con la hipótesis, única en este caso, de nivel i. Por ejemplo se tiene p0, p1 ← p0, p2 ← p1, h ← p2:

Figura 31. Grafo que simula el proceso de inferencia estático

P0

P1

P2

H

P2

P1

P0

P1 P1


119


Por su parte, las figuras 32 y 33 muestran cómo se mode-la el proceso estático a través del bpmn y el diagrama de transi-ción de estados en uml, respectivamente.

Figura 32. Modelado del proceso de inferencia estático en bpmn

cleanDB

i= 1,….,n

sendDiagnosis

i : = 1

[i ≤ n][i > n]

obtainDiagnosis

getProperties0

X inferProperties_i

i:= i+1

inferHypothesis


120


Figura 33. Diagrama que muestra la transición de estados en el proceso de inferencia estático

obtainDiagnosis

[i ≤ n]

cleanDB

getProperties0

increase

end

begin

set1inferProperties_iinferHypothesis

sendDiagnosis

P5

P4

P6

P7

P0

P1

P2

P3

obtainDiagnosis

cleanDB

getProperties0

i= 1,….,n

increase

end

begin

set1

[i > n]

inferProperties_iinferHypothesis

sendDiagnosis

P5

P4

P6

P7

P0

P1

P2

P3


La especificación en el adl de prisma (figura 33), necesa-ria para que se incorpore en los activos de la Baseline (como pro-tocolo del aspecto funcional del componente Motor de Inferen-cia), es la siguiente:

121


PROTOCOLSFINFERENCE::= begin ( ) → P0P0::= (PROCESS_obtainDiagnosis ? (DIAGNOSIS) → P1P1::= cleanDB ! ( ) → P2P2::= (PROCESS_getProperties0 ! (PROPERTIES0) → PROCESS_getProperties0 ? (PROPERTIES)) → P3P3::= set1 ( ) → P4P4::= ({I<N} PROCESS_inferPropertiesI ! (PROPERTIES_0, PROPERTIES_I → PROCESS_inferPropertiesI ? (PROPERTIES_0, PROPERTIES_I ) ) → P5 + ({i=N} PROCESS_inferHypothesis ! (PROPERTIES_I, HYPOTHESIS) → PROCESS_inferHypothesis ? (PROPERTIES_I, HYPOTHESIS) ) → P6P5::= increase ( ) → P4P6::= PROCESS_sendDiagnosis ! (DIAGNOSIS) → P7P7::= end;

◊ Proceso de inferencia dinámicoEn este proceso, una entidad durante el proceso del diagnóstico tiene diferentes propiedades (es decir, diferentes vistas), y exis-ten diferentes hipótesis candidatas que deben ser evaluadas con el fin de seleccionar la hipótesis válida (meta u objetivo del diag-nóstico).

En la figura 31, a través de un grafo, se presenta una metá-fora visual del proceso de inferencia estático, en el cual se mues-tran los niveles de las propiedades (color azul), diversas hipóte-sis (color negro), así como los razonamientos deductivo (flechas hacia arriba) e inductivo (flechas hacia abajo) en dicho proceso. Las reglas de inferencia presentan la siguiente forma:

hj,i+1 : Hi+1 ← pk,i* : Pi ^ hl,i* : Hi

Donde i = 0, 1 ,..., n (n = número de niveles), j,k,l:Nat. Por ejemplo, en la figura 34 se tiene:

H1 ← P0, H2 ← P1 ^ H1, H3 ← P2 ^ H2:

122


Figura 34. Grafo que simula el proceso de inferencia dinámico

H1

H2

H3

P0

P1

P2

H3

P2H2

H3 H3

P2

P1


Respecto a las figuras 35 y 36, éstas muestran el modela-do del proceso dinámico llevado a cabo mediante el bpmn y el diagrama de transición de estados en uml, respectivamente.

Figura 35. Modelado del proceso de inferencia dinámico en bpmn

cleanDB

i= 0,….,nHi+1= 1,……,H

sendDiagnosis

[ i < n-1 ]

[i = n-1 ]

obtainDiagnosis

X

i:= i+1

inferHypothesis_i+1

i : = 0 H i+1: = 1

getProperties_i

[ H i+1 = true ][ H i+1 = false ]

X

H i+1: = H i+1 +1

[ H i+1 < H ]

[ H i+1 = H ]

X


123


Figura 36. Diagrama que muestra la transición de estados en el proceso de inferencia dinámico

obtainDiagnosis

cleanDB

getProperties_i

increaseLevel

end

begin

levelSet0

inferHypothesis_i+1

sendDiagnosis

P4

P5

P6

P0

P1

P2

P3

hypotesisSet1

[Hi+1= false and H i+1 < H]

increaseHypotesis

[Hi+1= true and i <n-1]

[H i+1= true, and i =n-1][H i+1= false and H i+1 = H]

end

i= 0,….,nHi+1= 1,……,H


La especificación en el adl de prisma (figura 36), necesa-ria para que se incorpore en los activos de la Baseline (como pro-tocolo del aspecto funcional del componente Motor de Inferen-cia), es la siguiente:

PROTOCOLSFINFERENCE::= begin ( ) → p0P0::= (PROCESS_obtainDiagnosis ? (DIAGNOSIS) → p1P1::= cleanDB ! ( ) → P2P2::= (setLevel0 ( )| setHypotesis1 ( ) ) → P3P3::= (PROCESS_getProperties ! (PROPERTIES_I) → PROCESS_getProperties ? (PROPERTIES_I)) → P4P4::= (PROCESS_inferHypothesis ! (PROPERTIES_I, HYPOTHESIS_I+1 → PROCESS_inferHypothesis ? (PROPERTIES_I, HYPOTHESIS_I+1)) → P5P5::= ({Hi+1=true and i=n-1} PROCESS_sendDiagnosis ! (DIAGNOSIS) → PROCESS_sendDiagnosis ? (DIAGNOSIS) → P6

124


+ {Hi+1=true and i=n-1} increseLevel ( ) → P3 + {Hi+1=false and Hi+1<H} increseHypotesis ( ) → P3 + {Hi+1=false and Hi+1=H} endP6::= end;

ConclusionesEl estudio de campo que se realizó en los des, muestra que la ar-quitectura base de estos sistemas no es única, sino que varía en su estructura y comportamiento. Asimismo, con el modelado de los requisitos y la funcionalidad de los se se mostró la variabili-dad en la estructura y en el comportamiento de dichos sistemas, respectivamente. De acuerdo con las características que repre-sentan estas variabilidades, se concluye lo siguiente:

• La variabilidad en la estructura de un des depende del nú-mero de casos de uso, así como del número de actores y casos de uso por actor, es decir, la variabilidad en los requisitos del usuario final

• La variabilidad en el comportamiento de un des está relacio-nada con la estrategia de razonamiento que se aplique, la vista de la entidad durante el proceso del diagnóstico y el número y nivel de las hipótesis que intervienen en dicho proceso, es de-cir, la variabilidad en el proceso del diagnóstico.Con el análisis de los des, realizados en este capítulo, se

identificó y definió la variabilidad en este tipo de sistemas, lo cual permite presentar (en el próximo capítulo) cómo es gestio-nada la variabilidad en bom.

Parte III La aproximación

baseline-oriented modeling

Ilustración de Víctor Odín García Rodríguez.

127

Capítulo v

Gestión de la variabilidad a través de bom

La ciencia es la progresiva aproximación del hombre al mundo real.Max Planck

La variabilidad entre los productos de una spl puede expresarse en términos de características (features) (Kang, Kim, Lee, et

al., 1998b; Bosch, 2000); sin embargo, el tratamiento de la varia-bilidad implica, por un lado, el manejo de las características del dominio —las cuales están plasmadas en un modelo de caracte-rísticas— y, por otro lado, el que la variabilidad debe ser captada en activos (product´s line core assets). Además, la variabilidad del dominio de aplicación debe decorar a un esqueleto arquitectura base para obtener el producto final.

Así pues, el manejo de la variabilidad sólo a través de un modelo de características, y la decoración con sus diferentes fea-tures, no resuelve la complejidad de los sistemas antes enuncia-dos. Esto obliga a gestionar además la variabilidad sobre las ar-quitecturas base que comparten una arquitectura genérica; por ello, se ha tratado la variabilidad en dos fases: la variabilidad ini-cial es tratada a través de puntos de variabilidad plasmados en un árbol de decisión, el cual selecciona la arquitectura base co-rrecta; la segunda variabilidad se maneja mediante la decoración de esas arquitecturas base con las características del dominio de aplicación.

128


De esta manera, las características que definen la spl im-plican dos tipos ortogonales de variabilidad. La primera varia-bilidad se obtiene por el propio proceso del diagnóstico (es de-cir, son las características que presenta el dominio del diagnós-tico) y los requisitos del usuario final, lo que implica una arqui-tectura-base específica. La segunda variabilidad corresponde al campo de aplicación del diagnóstico (por ejemplo, las caracte-rísticas que muestran los diagnósticos educativo, televisivo, mé-dico, etcétera).

Por ello, bom es una aproximación donde la especifica-ción de la variabilidad y la funcionalidad se manejan en mode-los separados los cuales están representados a través de mode-los conceptuales que conforman a sus respectivos metamodelos.

bom modela la variabilidad independiente de la funcio-nalidad, distinguiendo así un modelo de variabilidad de un mo-delo funcional (la arquitectura genérica). No obstante, como ya se mencionó (capítulo iv), en los sistemas expertos el modelo funcional no es único, esto provoca que deba trabajarse con di-versos modelos del sistema, razón por la cual fue necesario divi-dir esta situación en dos partes:

• Primera variabilidad: modelar el sistema con el modelo de va-riabilidad del dominio y con el modelo de funcionalidad (es decir, con la arquitectura genérica de los se), con el fin de ob-tener (mediante técnicas de árbol de decisión o con transfor-mación de modelos) uno de los modelos de arquitectura base.

• Segunda variabilidad: modelar el sistema con el modelo de va-riabilidad del dominio de aplicación y con el modelo de fun-cionalidad (es decir, la arquitectura base específica) con el fin de obtener (a través de decorar a las arquitecturas base con las características del dominio de aplicación) un modelo arquitec-tónico (en nuestro caso, prisma) como producto final de la spl (es decir, un des).

129

Capítulo V. Gestión de la variabilidad a través del bom

Por ello, la aproximación bom contempla dos spl que se corresponden con las dos variabilidades consideradas:

• La SPL1, es decir, la spl de arquitecturas base. • La SPL2, es decir, la spl de arquitecturas prisma.

Además, de acuerdo con los resultados del estudio de campo que se menciona en el capítulo iv, se concluye que la va-riabilidad gestionada en la aproximación bom integra dos tipos de variabilidad ortogonal (figura 37):

• La primera variabilidad (v1) se relaciona con el proceso del diag-nóstico y los requisitos del usuario. Esta variabilidad determi-na una arquitectura base específica. Las características que se corresponden con el proceso de diagnóstico se relacionan con el comportamiento de los se (es decir, vista de la entidad, nivel de las propiedades, número de hipótesis y tipo de razonamien-to). Las características que se corresponden con los requisitos del usuario se relacionan con la estructura de los se (es decir, número de casos de uso, número de actores y número de ca-sos de uso por actor).

• La segunda variabilidad (v2) se relaciona con el dominio de apli-cación específico, y determina el producto final de la spl. Las características del dominio de aplicación son las propiedades del nivel n, las reglas de inferencia del nivel n-1 y las hipótesis.

130


Figura 37. Clasificación de las características que presenta la variabilidad gestionada por bom

Features(F)

User Requirements

System DomainSTRUCTURE

Specific Domain(diagnostic process)

System DomainBEHAVIOUR

FP.i: Property of level i

number of Use Casesnumber of Actorsnumber of Use Cases / Actor

FP: name and typeof Properties

FH: name and typeof Hypotheses

FR: Rules definition FR.i: Rules of level i

type of Entity Viewsnumber of Property levelsnumber of Hypothesestype of Reasoning

FH.i: Hypothesis of level i

V1: (domain)

V2:(applicationdomain)


Primera variabilidad en bomEl primer tipo de variabilidad involucra una familia de arquitec-turas base, denominada SPL1. Ésta es almacenada en la Baseline, por ello la Baseline es en sí una spl formada por todas las arqui-tecturas base como activos reutilizables o assets.

La variabilidad inicial representa la variabilidad del domi-nio (propiedades de la entidad que participan en el proceso del diagnóstico, niveles de dichas propiedades, tipos de razonamien-to y número de hipótesis), y la variabilidad en los requisitos del usuario final del sistema (número de casos de uso, número de ac-tores, y número de casos de uso por actor).

Las características de la primera variabilidad están pre-sentes en el modelo de características de la spl de diagnóstico, las cuales están plasmadas en un árbol de decisión y captadas co-mo instancias en un modelo conceptual del dominio, que repre-

131


sentan todos los valores de la variabilidad. Por ello, el modelo de características, el árbol de decisión y el modelo conceptual del dominio, como mecanismos de variabilidad, son constructores de la variabilidad en el nivel de artefacto (en este caso, de la ar-quitectura base).

El árbol de decisión permite seleccionar los assets necesa-rios para construir el modelo de las arquitecturas base. Las ho-jas del árbol de decisión apuntan hacia dichos assets. La estructu-ra de los elementos arquitectónicos de un se involucra a las ca-racterísticas sobre tres puntos de variabilidad en el árbol de de-cisión: número de casos de uso, número de actores y número de casos de uso por actor. Estas características son utilizadas pa-ra seleccionar los activos que ayudarán a configurar las arquitec-turas base.

El comportamiento de los elementos arquitectónicos de un sistema experto, involucra a las características representadas por los siguientes cuatro puntos de variabilidad en el árbol de decisión: las vistas de las entidades, los niveles de las propie-dades, el número de hipótesis y el tipo de razonamientos. Estas características están relacionadas con los servicios y sus evalua-ciones, los protocolos y los played_roles, de los aspectos que con-tienen los elementos arquitectónicos prisma, es decir, la infor-mación de estado, de los procesos y de los roles, respectivamente. En consecuencia, y para optimizar el proceso de inserción de las características, en lugar de repetir éstas en cada uno de los tipos prisma, se fijan en los esqueletos.

El manejo de la variabilidad del dominio puede ser visto como una transformación que recibe de entrada el modelo de la variabilidad del dominio y el modelo funcional de la arquitectu-ra genérica, lo que produce como salida el correspondiente mo-delo de la arquitectura base.

132


Segunda variabilidad en bomEl segundo tipo de variabilidad involucra a las spl de la aplica-ción en un campo específico. Esta variabilidad permite a las ar-quitecturas base ser enriquecidas o decoradas con las caracterís-ticas del dominio de aplicación.

Durante el proceso en el que se maneja esta variabilidad, las variantes del dominio específico de aplicación son dadas co-mo instancias de un modelo conceptual del dominio de aplica-ción. Dichas variantes o características son insertadas (por me-dio de transformaciones) en los esqueletos de las arquitecturas base con el fin de generar los artefactos software de tipo prisma. Las características que son usadas para rellenar o decorar los es-queletos son las siguientes: el nivel, nombre y tipo de las propie-dades de la entidad a diagnosticar, el nivel, nombre y tipo de las hipótesis, y las reglas que relacionan a ambas características.

Durante la gestión para la variabilidad en el dominio de aplicación, una spl puede ser vista como un conjunto de mode-los que comparten a su vez un conjunto común de característi-cas manejables, las cuales se desarrollan mediante un conjunto de activos. A continuación se presenta la especificación de la ges-tión relacionada con las características del dominio de la aplica-ción (segunda variabilidad).

De acuerdo con Trujillo (2007), un modelo que corres-ponde a la línea de producto software de diagnóstico, se define de la siguiente forma:

M-X = {FP.i, FH.i, FR.i},

En ésta, m-x es el modelo del dominio de aplicación es-pecífica x y el resto de elementos son las características de dicha línea de producto, en la que i= 0,1,…….,n.

Asimismo, el diseño de un programa se define como: prog SPL-X = FP.i FH.i FR.i

133


Esto significa que el programa spl-x tiene las característi-cas: fp.i, fh.i, fr.i: features de las propiedades, hipótesis y reglas respectivamente. Por ello, el conjunto de programas que puede crearse desde un modelo es una línea de productos. Es decir, el conjunto de programas que se corresponden con los elementos arquitectónicos, mismos que son creados desde el modelo m-dm del diagnóstico médico, es la línea de producto del caso médico.

Por ejemplo, para el caso de estudio sobre el diagnóstico médico se tiene lo siguiente:

Características de las propiedades de nivel 0: FP.0 = tos, fiebre, dificultad respiratoria, ........Características de las propiedades de nivel 1: FP.1 = tos seca, tos con flema, fiebre continua,

dificultad respiratoria grave, .......Características de las hipótesis de nivel 1: FH.1 = ira, parotiditis,....Características de las hipótesis de nivel 2: FH.2 = bronquiolitis, neumonía, crup espasmódico,

paperas, parotiditis bacteriana, .........Características de las reglas de nivel 1: FR.1 = {fiebre = true and tos = true and dificultad

respiratoria=true} síndrome=”ira” {fiebre = true and dolor a masticación = true and

parótidas anormales=true} síndrome=”parotiditis” Características de las reglas de nivel 2: FR.2 = {síndrome=”ira” } enfermedad= “bronquiolitis”{síndrome=”ira” } enfermedad= “neumonía”{síndrome=”ira” } enfermedad= “crup espasmódico” {síndrome=” parotiditis” } enfermedad= “paperas”{síndrome=” parotiditis” } enfermedad= “parotiditis

bacteriana”.......Características de las reglas de nivel 3: FR.3 ={ fiebre continua=true and fiebre mayor a 38 =true and

dolor y crecimiento de parótidas =true and dolor a masticación espontáneo agudo=true } enfermedad= “paperas”

.......

134


El Modelado Orientado a Características (fom, por sus siglas en inglés [Feature-Oriented Modeling]) ofrece un conjun-to de operaciones, donde cada operación implementa una carac-terística. Las características pueden distinguirse como constan-tes o funciones (Trujillo, 2007). De esta manera, las característi-cas consideradas como constantes representan modelos base (pa-ra el caso de este trabajo, los esqueletos arquitecturas base). Los esqueletos son decorados o rellenados con las características que presente el dominio de aplicación, con el fin de crear los tipos prisma respectivos. Las características son modeladas como fun-ciones y representan refinamientos de modelos los cuales son ex-tensiones del modelo base de entrada, por ejemplo:

fx.i ∙ e-mi-dmj,Esta extensión significa “agregar la característica fx.i

al modelo base e-mi-dm”, donde ∙ denota la aplicación de la función, j=0,1,…,n, y e-mi-dmo es el esqueleto del motor de in-ferencia correspondiente al caso del diagnóstico médico.

El proceso de decoración con características es represen-tado por el siguiente algoritmo:

E-MI-DM1 = FP.0 ∙ E-MI-DM0E-MI-DM2 = FP.1 ∙ E-MI-DM1E-MI-DM3 = FH.1 ∙ E-MI-DM2E-MI-DM4 = FH.2 ∙ E-MI-DM3E-MI-DM5 = FR.1 ∙ E-MI-DM4E-MI-DM6 = FR.2 ∙ E-MI-DM5E-MI-DM7 = FR.3 ∙ E-MI-DM6

En éstas, < fx.i > son las características a rellenar, dadas por:

FP.0 = Características de las propiedades de nivel 0,FP.1 = Características de las propiedades de nivel 1,FH.1 = Características de las hipótesis de nivel 1,FH.2 = Características de las hipótesis de nivel 2,FR.1 = Características de las reglas de nivel 1,FR.2 = Características de las reglas de nivel 2,FR.3 = Características de las reglas de nivel 3,

135


El algoritmo anterior se clarifica a través de la siguiente metáfora visual (figura 38) donde se muestra el proceso de in-serción de las características en un esqueleto seleccionado de la Baseline (e-mi-dmo) para crear su correspondiente tipo prisma.

Figura 38. Proceso de inserción de las características en un esqueleto para formar su tipo prisma

FP.0

T1

FP.1

T2FP.0

FPH

T3FP.0, FP.1

XML XML XML XSLTXSLT XSLT

FH

T4

FR.1

T5FP.0, FP.1,FPH, FH

FR.2

T6

XML XMLXSLTXSLT XSLT

FP.0, FP.1, FPH

XML

XML

FR.3

T7

XSLT XML

E-MI-DM0 E-MI-DM1 E-MI-DM2

E-MI-DM3

E-MI-DM4

E-MI-DM4E-MI-DM5

E-MI-DM6E-MI-DM7

FP.0, FP.1,FPH, FHFR.1

FP.0, FP.1,FPH, FHFR.1, FR.2

FP.0, FP.1,FPH, FHFR.1, FR.2,FR.3


Por su parte, la figura 39 muestra cómo se lleva a cabo el proceso que inicia desde la inserción de características en los es-queletos, hasta la configuración de la arquitectura del modelo específico de la spl.

136


Figura 39. Esquematización sobre cómo se desarrolla el proceso que inicia desde la inserción de características en los esqueletos,

hasta la configuración de la arquitectura

≤ Fi

≤ Ti

XSLT

E-MI-DEDT

E-BC-DEDT

E-IU-DEDT

E-C-DEDT

Esqueletos seleccionadosEsqueletos seleccionados

XML-ADL Prisma

<<in>> <<out>>

T-MI-DT

T-BC-DT

T-IU-DT

T-C-DT

Tipos creadosTipos creados

XML-ADL Prisma

≤ Ti

≤ Ti

≤ Ti

TransformacionesTransformaciones

ModeloArquitectónico

DT

≤ Fi

≤ Fi

≤ Fi

CaracterísticasCaracterísticas

XML-ADL Prisma

Arquitectura TipoArquitectura Tipo


Como ejemplo, en la tabla 5 se presenta el esqueleto aspecto funcional del componente KnowledgeBase, y su respectivo tipo prisma, referente al caso de estudio sobre el diagnóstico médi-co. Ambos son especificados en el adl de prisma (en negrita se ponen los huecos que son rellenados con las características del dominio de aplicación.

137


Tabla 5. Ejemplo de un aspecto esqueleto y su correspondiente tipo prisma

Functional aspect of the Knowl-edge Base of a skeleton

Functional aspect of the Knowledge Base of a PRISMA type

Functional Aspect FBaseMD using IDomainMD Attributes Variable < FP.0 >;

< FP.1 >;

< FPL.1 >;

Derived < FH.1 >, derivation < FR.1 >

< FH.2 >, derivation < FR.2 >,

< FH.2 >, derivation < FR.3 >;

Services...

End_Functional Aspect FBaseDM

Functional Aspect FBaseMD using IDomainMD Attributes Variables cough: bool; fever: bool; respiratory_dificulty: bool; ... dry_cough: bool; constant_fever: bool; grave_respiratory_dificulty:bool; ... positive_hematic_biometric:bool; ... Derived syndrome: string; derivation {cough=true and fever=true and respiratory_dificulty=true} syndrome=”warth”;

posible_disease: string; derivation {syndrome=”warth”} posible_disease=”pneumonia”; {syndrome=”warth”} posible_disease=”crup”; {syndrome=”warth”} posible_disease=”bronchilitis”;

disease: string; derivation {constant_fever=true and greater_39_fever=true and 2_3_days_fever=true and phlegmatic_cough=true and frequent_cough=true and positive_hematic_biometric=true)} disease=”pneumonia”;...

Services...

End_Functional Aspect FBaseDM


138


Al respecto, debe señalarse que una arquitectura base puede ser instanciada a una o más arquitecturas prisma (es decir, a va-rios productos de la spl). Como ejemplo de ello se encuentran los casos de estudio sobre el diagnóstico de programas educati-vos y el diagnóstico televisivo mencionados en el capítulo iii. Éstos comparten la misma arquitectura base esqueleto, pero ca-da uno de ellos origina diferentes arquitecturas finales prisma, debido a que en cada una fueron añadidas o insertadas diferen-tes propiedades del dominio de aplicación. La figura 40 muestra una metáfora visual de ello.

Figura 40. Metáfora visual que representa a una arquitectura base y dos arquitecturas prisma

features ofapplication domain B

INFERENCEMOTOR

KNOWLEDGE BASE

USERINTERFACE

CONNECTOR

1

INFERENCEMOTOR

USERINTERFACE

KNOWLEDGEBASE

connector

INFERENCEMOTOR

USERINTERFACE

KNOWLEDGEBASE

connector

features ofapplication domain A


139


Con el fin de mostrar lo que se mencionó anteriormen-te, en la tabla 6 se presenta el esqueleto del aspecto funcional del componente KnowledgeBase, y sus correspondientes tipos pris-ma, referente a los casos de estudio diagnóstico de programas edu-cativos y diagnóstico televisivo; éstos, igualmente que el caso sobre el diagnóstico médico (usado como ejemplo en este libro), son especificados en el adl de prisma.

140


Tabla 6. Ejemplo de un aspecto esqueleto y dos aspectos tipo prisma sobre los casos de estudio diagnóstico de programas

educativos y diagnóstico televisivo2


2 Los huecos (feature holders) que se rellenaron con las características del dominio de aplicación, se resaltaron con negritas.

Func

tiona

l asp

ect o

f the

K

now

ledg

e Ba

se o

f a sk

elet

onFu

nctio

nal a

spec

t of t

he K

now

ledg

e Ba

se o

f a

PRIS

MA

type

(cas

e stu

dy: E

duca

tiona

l Pro

gram

D

iagn

osis)

Func

tiona

l asp

ect o

f the

Kno

wle

dge

Base

of a

PR

ISM

A ty

pe (c

ase

study

: TV

Dia

gnos

is)

Functional Aspect

FBaseDPEDT using

IDomainDPEDT

Attributes

Variables

< FP.0 >,

Deriveds

< FP.1 >,

< FH >

Derivations

< FR.1 >

< FR.2 >

........

Services

…….

Played_Roles

........

Protocols

…….

End_Functional Aspect

FBaseDPEDT

Functional Aspect FBaseDPEDT using

IDomainDPEDT

Attributes

Variables

pictures:string,

TVstructure:string;

music:string,

audio:string,

...

Deriveds

production:string,

content:string

technicalQuality:string;

stateVideo:string;

Derivations

{pictures=”proper” and

TVstructure=“authorized” and

music=”good”} production:=”good”

...

{production=”good” and content

=“good” and technicalQuality=”good”}

sateVideo:=”VideoOK”

......

Services

…….

Played_Roles

........

Protocols

…….

End_Functional Aspect FBaseDPEDT

Functional Aspect FBaseDPEDT

using IDomainDPEDT

Attributes

Variables

laboratories:string,

library:string,

criticalMass:string,

scientificProductivity:string;

...

Deriveds

infrastructure:string,

faculty:string

develpmentStage:string;

...

Derivations

{laboratories=”good”

and library=“ good”}

infrastructure:=“ good”

{critical_mass=”good” and

scientificProductivity =“ good”}

faculty:= “good”

{infrastructure=“good”

and faculty= “good”}

develpmentStage:=“consolidated;

......

Services

…….

Played_Roles

........

Protocols

…….

End_Functional Aspect FBaseDPEDT

141


ConclusionesLa forma de gestionar en dos etapas la variabilidad en bom es la principal aportación de este libro en el ámbito de las spl. Dicha iniciativa fue resultado de la observación —hecha por los auto-res del presente trabajo— respecto a que el manejo de la variabi-lidad con un solo modelo de características, y el tratamiento de la variabilidad por decoración con diferentes características, no solucionaban la complejidad que conlleva el tratamiento de la variabilidad. Esto provocó que se gestionara la variabilidad sobre las arquitecturas base que comparten una arquitectura genérica.

De esta manera, en una primera etapa (con la variabilidad inicial) se selecciona la arquitectura base correcta y, en una se-gunda etapa (con la segunda variabilidad), se decoran esas arqui-tecturas base con las características del dominio de aplicación. Por ello, se concluye que bom maneja dos tipos de variabilidad, que se corresponden con el desarrollo de dos spl:

• La spl de las arquitecturas base, denominada SPL1, la cual se corresponde con la relación is_a en la taxonomía de los des, y que conforman familias de productos que comparten caracte-rísticas comunes en el domino.

• La spl de las arquitecturas prisma, denominada SPL2, la cual se corresponde con la relación is_instance_of en la taxonomía de los des, y que conforman los productos finales específicos del dominio de la aplicación (es decir, son las instancias de las arquitecturas base).La gestión de la variabilidad es, pues, la base para el desa-

rrollo de los des que se presenta en los siguientes capítulos (vi y vii). En éstos se exhibirán dos aproximaciones de bom (la apro-ximación bom-eager y la aproximación bom-lazy). El tamaño de la Baseline determinará la aproximación más adecuada como una posible solución para el desarrollo de la spl, de la siguiente manera:

• Si la Baseline es pequeña (dominios de cardinalidad baja), es conveniente que se elija la aproximación bom-eager al aplicar

142


técnicas de árbol de decisión (para la primera variabilidad) y técnicas de la fom (para la segunda variabilidad). En bom-ea-ger, la Baseline es construida previamente (durante la fase de la ingeniería del dominio), es decir, la Baseline es explícita y se accede a ésta para elegir los assets en el plan de producción de la spl (durante la fase de la ingeniería de la aplicación).

• Si la Baseline es grande (dominios de cardinalidad alta), es con-veniente que se elija la aproximación bom-lazy al aplicar téc-nicas de transformación de modelos (por ejemplo, con qvt-Relations). En bom-lazy, la Baseline se construye en el mo-mento de la primera transformación (correspondiente a la pri-mera variabilidad), es decir, la Baseline es implícita y se realiza un cálculo para construir los assets en el plan de producción de la spl. bom-lazy es una solución computacional, y la Base-line es construida durante la fase de la ingeniería de la aplica-ción cuando se ejecuta el plan de producción.

143

Capítulo vi

Aproximación BOM-EAGER: Desarrollo de la línea de productos software mediante técnicas ad hoc utilizadas para el tratamiento de la variabilidad

La técnica es el esfuerzo para ahorrar esfuerzo.José Ortega y Gasset

En este capítulo, se describe cómo bom lleva a cabo el desarro-llo de la spl, con variabilidad de baja cardinalidad, mediante

técnicas específicas para tratar la primera y la segunda variabilidad.

Tratamiento de la primera variabilidad: de la arquitectura genérica a las arquitecturas baseLa variabilidad inicial o primera variabilidad (relacionada con las características del dominio) es representada y manejada a tra-vés de dos modelos separados:

• Modelo funcional del dominio, representado por la arquitectu-ra genérica de nuestra spl. Esta arquitectura genérica es com-partida por varias arquitecturas base (o plantillas de arquitec-turas base), que representan la spl1.

• Modelo de la variabilidad del dominio, representado por el mo-delo conceptual del dominio (mcd), el cual se plasma en un árbol de decisión. Los dsl se utilizan para manejar la variabi-lidad tanto en el nivel de definición para crear el árbol de de-

144


cisión, como para usar dicho árbol con el objeto de elegir (por medio de puntos de variabilidad y la generación de variantes) las diferentes arquitecturas base de los dominios específicos. De esta manera, la primera variabilidad implica a la spl

de los esqueletos que conforman las arquitecturas base, es decir, la spl1. Esta spl se encuentra almacenada en la Baseline la cual es, en sí, una spl conformada por todos los assets necesarios para construir dichas arquitecturas base esqueleto.

Un dato interesante es el referente a que una arquitec-tura base (activo reutilizable) puede ser vista como la constante de una spl en sí misma, sólo que el producto resultante de ésta es una instancia específica del activo, en vez de una aplicación completa. Así, para obtener estas arquitecturas base como re-sultado de la combinación del modelo funcional (arquitectura genérica del des) y del modelo de la variabilidad (mcd), en dos vistas separadas, se debe realizar una transformación de mode-los, a la cual se le llama t1.

Aquí debe mencionarse que la arquitectura genérica (ar-quitectura de los des) conforma al metamodelo de módulos. El mcd conforma al metamodelo de clases de uml, y las arquitectu-ras base conforman el metamodelo de componentes-conectores (explícitamente el metamodelo Esqueleto, es decir, el metamode-lo de prisma con huecos).

Dado que el número de las arquitectura base es limita-do (esto no implica que no pueden agregarse más arquitecturas base, ya que bom es una aproximación reactiva de spl), en bom, la transformación t1 se realiza como una función ya calculada a través de una tabla (representada por la Baseline). t1 es una función (1 a n) con dominio y co-dominio limitado, en donde el cálculo se realiza una sola vez y el resultado es para todas las variantes. De esta forma, dadas las variantes se implementa t1 como un acceso a la tabla.

145

Capítulo VI. Aproximación BOM-EAGER: Desarrollo de la línea...

Esta tabla es la Baseline (la cual contiene los esqueletos de las arquitecturas base), la cual contiene de forma implícita la transformación t1. Con esta función se generan, a partir de una única arquitectura genérica, las distintas arquitecturas base.

Sin embargo, de éstas n arquitecturas base, debe ser se-leccionada solamente una, adecuada al caso específico del domi-nio; por ello, en bom la variabilidad del mcd se plasma en un ár-bol de decisión. De esta manera, con técnicas de árbol de deci-sión puede seleccionarse la arquitectura base del caso específico al introducir los datos referentes a la variabilidad del dominio, los cuales se expresan como variantes de los puntos de variabili-dad (características del dominio).

Esta función recibe como dato sólo la variabilidad plas-mada en el árbol de decisión (ya que la arquitectura genérica es fija). La función de transformación t1 es la siguiente:

t1 (modelo_arqGenérica, modelo_variabilidad1) = modelo_arqBase: modelo_ spl1Asimismo, con la aproximación bom se obtienen ventajas

al tratar separadamente el modelo funcional y el de variabilidad, esto permite convertir una arquitectura genérica en varias ar-quitecturas base y modelar la variabilidad independientemente (véase la figura 41).

146


Figura 41. Tratamiento de la primera variabilidad (v1) a través de bom


Tratamiento de la segunda variabilidad: de la arquitectura base a la arquitectura prismaLa segunda variabilidad (relacionada con las características del dominio de la aplicación) también es representada y manejada mediante dos modelos distintos:

• Modelo conceptual funcional del dominio de la aplicación, re-presentado por una arquitectura base de la spl1.

• Modelo conceptual de la variabilidad del dominio de aplica-ción, representado por el modelo conceptual del dominio dela aplicación (mcda).

147


De esta manera, la segunda variabilidad involucra a la spl de la aplicación en un campo específico, es decir, la spl2. Esta variabilidad permite a las arquitecturas base de nuestra spl ser enriquecidas o decoradas con las features del dominio de apli-cación.

En bom se modela explícitamente la variabilidad del do-minio de aplicación, ajeno a las arquitecturas base esqueleto. El dsl se utiliza tanto para manejar la variabilidad—cuyo objeto es crear el mcda— como para usar éste (por medio de las carac-terísticas del dominio de la aplicación), al decorar las arquitec-turas base con dichas características para obtener una aplicación específica, es decir, los productos de la spl2.

Esto puede realizarse mediante una transformación t2, que consiste en tomar los dos modelos (el modelo de arquitec-tura base seleccionado y el modelo de variabilidad del dominio de aplicación) y obtener un solo modelo (el modelo de la arqui-tectura prisma). Para dicha transformación, se implementa una función con la que se obtiene la arquitectura prisma (recibien-do como dato la variabilidad del dominio de aplicación, ya que la arquitectura base es fija):

t2 (modelo_arqBase, modelo_variabilidad2) = modelo_arq prisma : modelo_ spl2En bom se obtienen ventajas al tratar separadamente los

modelos funcional y de variabilidad, ello permite convertir una arquitectura base en una arquitectura prisma y modelar la varia-bilidad independientemente (véase la figura 42).

148


Figura 42. Tratamiento de la segunda variabilidad (v2) a través de bom


Desarrollo de los sistemas expertos de diagnóstico en bomUna síntesis de estos dos últimos temas se muestra en la figu-ra 43 en la que aparece una metáfora visual sobre el desarrollo de los des mediante bom. En dicha figura se observa un primer paso donde a partir de la arquitectura genérica se obtiene la ar-quitectura base seleccionada (por técnicas de árbol de decisión), a través de una instancia del modelo mcd que captura la variabi-lidad v1 del dominio.

149


Un segundo paso es realizado para decorar la arquitectu-ra base y obtener la arquitectura prisma (por técnicas de fom, utilizando transformaciones con plantillas xslt sobre documen-tos xml) mediante una instancia del modelo mcda que captura la variabilidad v2 del dominio de aplicación.

Figura 43. Desarrollo de los des en bom


En este punto debe enfatizarse que el modelo de arqui-tecturas base conforma el metamodelo Esqueleto. Los modelos de variabilidad mcd y mcda conforman al metamodelo de clases de uml, y el modelo de arquitecturas prisma conforma el meta-modelo prisma.

Por su parte, la tabla 7 muestra una metáfora visual de las arquitecturas (genérica, base y prisma) sobre los casos de estudio que se mencionaron en el capítulo iii.

150


Tabla 7. Metáfora visual que muestra la variabilidad reflejada en las arquitecturas de los des referente a los casos de estudio


151


El usuario (ingeniero de la aplicación) para obtener un producto de la spl (es decir, un des), necesita introducir en bom, mediante dos pasos, los datos de la variabilidad:

• En un primer paso, el ingeniero introduce las características de la variabilidad del dominio (es decir, v1) por medio de una ins-tancia del mcd. De esta forma, bom seleccionará una arquitec-tura base ad hoc al caso de estudio.

• En el segundo paso, el ingeniero introduce las características de la variabilidad del dominio de la aplicación (es decir, v2), a través de una instancia del mcda. Con ello, bom generará una arquitectura prisma como un producto de la spl.En bom el entorno destino es el framework prisma. La

compilación del modelo arquitectónico, la cual genera automá-ticamente el código (en c#,.net), se realiza a través de la herra-mienta prisma-model-compiler. El sistema final como aplica-ción ejecutable, instancia de la spl, se obtiene a través del Mid-dleware prismanet.

Un ejemplo de la interacción entre un des y un usuario final (el cliente), se muestra en la figura 44. El ejemplo corres-ponde al caso de estudio sobre el diagnóstico médico.

Figura 44. Información de entrada y salida que genera un des desde el enfoque mostrado por el usuario final

pneumoniadry coughconstant feverrespiratory dificulty


152


ConclusionesCon bom se obtienen ventajas al tratar separadamente el mode-lo funcional y el de variabilidad, esto permite convertir una ar-quitectura genérica en una arquitectura base prisma y modelar la variabilidad independientemente; con ello se realiza, expresi-va y fácilmente, la transformación de modelos.

Si la spl es de cardinalidad baja, con la aproximación bom-eager se obtienen ventajas al manejar la variabilidad por medio de técnicas de decisión (es decir, la técnica de árbol de decisión para obtener la arquitectura base) y la técnica del fom para obtener la arquitectura prisma como el producto final, en lugar de utilizar aproximaciones más complejas (como la apro-ximación bom-lazy, que utiliza técnicas de transformación de modelos aplicando las qvt-Relations), como se verá en el próxi-mo capítulo.

La externalización de la Baseline y su acceso mediante téc-nicas de árbol de decisión aparece como una solución más ade-cuada y se ha empleado en bom para la realización de su primer prototipo: Protobom. El tratamiento de la segunda variabilidad v2 permite también una solución ad hoc mediante técnicas ba-sadas en xml y plantillas xslt que han sido igualmente utiliza-das en el contexto del fom para decorar los esqueletos de las ar-quitecturas base, con el fin de producir las arquitecturas prisma (como instancias de las arquitecturas base).

Sin embargo, aunque la aproximación bom-eager es me-nos compleja y es una solución adecuada, si la variabilidad de la spl es de cardinalidad alta, es más conveniente utilizar la aproxi-mación bom-lazy. Esto se debe a que, si se cuenta con una am-plia spl, el árbol de decisión tendrá numerosas ramas y no sería práctico construir todos los assets de la Baseline (como sucede en la aproximación bom-eager).

153

Capítulo vii

Aproximación BOM-LAZY: Desarrollo de la línea de productos software mediante técnicas de transformación de modelos utilizadas para el tratamiento de la variabilidad

Ciencia es todo aquello sobre lo cual siempre cabe discusión.José Ortega y Gasset

Similar al capítulo anterior, se describe cómo bom lleva a cabo el desarrollo de la spl, con variabilidad de cardinalidad alta,

mediante técnicas de transformación de modelos para el trata-miento de la variabilidad.

Vistas de los sistemas expertos de diagnóstico en bomEn la aproximación bom el tratamiento de la variabilidad del dominio y la variabilidad de la funcionalidad de los sistemas se maneja con modelos independientes; por ello, en bom se con-sideran dos clases de vistas de los sistemas expertos: la Vista de la Variabilidad del Sistema (vvs) y la Vista Funcional del Siste-ma (vfs).

La vvs se describe a través de dos modelos conceptuales de variabilidad: el mcd, el cual captura la variabilidad que pre-senta el proceso del diagnóstico y los requisitos del usuario (v1), y el mcda, que captura la variabilidad del dominio de aplicación (v2). EL mcd conforma al metamodelo de la variabilidad v1

154


(mm v1) y el mcda conforma al metamodelo de la variabilidad v2 (mm v2). Ambos metamodelos son el metamodelo de clases de uml 2.0 (uml, 2005), pero otros metamodelos específicos de dominio pueden ser usados, permitiendo lenguajes específicos de dominio para capturar la vvs.

La vfs de los sistemas expertos ocurre en diferentes eta-pas, las cuales son llevadas a cabo por el proceso de producción (spl) mediante dos vistas que se plasman en tres modelos arqui-tectónicos:

• La vista modular para el modelo de la arquitectura genérica, el cual conforma al metamodelo modular (mm modular).

• La vista componente-conector (c-c) para los modelos de las ar-quitecturas base que conforman al metamodelo Skeleton (mm skeleton), y los modelos de las arquitecturas prisma que con-forman al metamodelo prisma (mm prisma) para el producto final. El mm skeleton es similar al mm prisma (Pérez, 2006), pero con huecos (feature-holders: donde serán insertadas las características del dominio de aplicación).Las vistas utilizadas en la vfs son denominadas por mda

como vistas de arquitecturas software (sav, por sus siglas en in-glés [Software Architecture Views]). En bom se seleccionaron la vista modular y la vista componente-conector como las vistas de arquitectura software más apropiadas con la propuesta que pre-senta este trabajo.

Metamodelos de las vistas softwareEn mda, la omg propone el Meta Object Facility (mof) (mof, 2006) con el cual define metamodelos. mof provee un lenguaje para expresar metamodelos, así como una notación gráfica; por ello, el presente trabajo utilizó dicha notación para la especifi-cación de los metamodelos. Para la especificación de los meta-modelos de las vistas modular y c-c, han sido analizadas diversas propuestas (Bass, Clement y Kazman, 2003; ieee-1471, 2000; y Krutchten, 1995). Sin embargo, se seleccionaron la vistas descri-

155

Capítulo VII. Aproximación BOM-LAZY: Desarrollo de la línea...

tas en Bass et al. (2003) como las aproximaciones más apropia-das referente al tema que se trata en este libro.

◊ Especificación del metamodelo de la vista modular (mm modular view) La figura 45 muestra el metamodelo de la vista modular; en éste, el principal elemento considerado es el módulo. No obstante, existe distinción entre un módulo simple y un módulo com-plejo, el cual es usado como un contenedor de módulos. La re-lación class representa los estilos mostrados en Bass et al. (2003 [decomposition, uses and layers]), éstos son tratados como relacio-nes. El tipo de relación distingue un estilo de otro y las etique-tas en las asociaciones indican cómo la relación es llevada a cabo; por ejemplo, en la figura 45 la etiqueta used indica que el ele-mento de Module class será usado por otro elemento del mismo.

◊ Especificación del metamodelo de la vista c-c (mm c-c view) El metamodelo de la vista c-c se presenta en la figura 46, don-de se muestra el Component class y Connector class como los prin-cipales elementos, sin embargo ambos se derivan de un compo-nent class más genérico: Tcomponent. La manera en que dichos elementos se relacionan se corresponde con sus estilos o rela-ciones (Pipe-Filter, Client-Server, PeerToPeer, Publish-Suscribe, y Shared-Data) heredados de Relation class. Esta clase une los com-ponentes por medio de la clase conector. Las interacciones entre los componentes de esta vista se refinan mediante el metamode-lo de clases de uml. Este metamodelo especifica cómo se relacio-nan los componentes (objetos).

◊ Especificación del metamodelo de las vistas de la variabilidad del dominio (mmv1 y mmv2) El metamodelo de clases que presenta uml (uml, 2005) es usado en ambos metamodelos de la variabilidad v1 y v2.

156


Figura 45. Vista del metamodelo modular (notación en mof)


157


Figura 46. Vista del metamodelo c-c (notación en mof)


158


Relaciones entre metamodelos y transformaciones entre modelosEn esta sección se analizan las relaciones entre las vistas fun-cionales del sistema (vfs). El objetivo principal de este análi-sis es establecer las reglas de correspondencia en el nivel meta-modelo y realizar la transformación en el nivel modelo. Así, la fi-gura 47 (sección a) muestra un ejemplo sobre dos relaciones de correspondencia en el nivel metamodelo. En este caso, r1 indi-ca que cada elemento módulo de la vista modular (<<Modular View>>) se corresponde con un elemento componente de la vis-ta c-c (<<c-c View>>), y r2 indica que un <<Uses>> de <<Mod-ular View>> se corresponde con un elemento conector de la << c-c View>>. Estas relaciones son usadas para realizar la transfor-mación en el nivel modelo, como se muestra en la figura 47 (sec-ción b).

Figura 47. Ejemplo de relaciones entre dos vistas en el nivel metamodelo (sección a) y transformaciones de un modelo en

otro modelo en el nivel modelo (sección b)

<<C-C View>>

<<ModularView>>

<<Module>>A

<<Module>>B<<uses>>

:Comp_A :Connect :Comp_B

(b)(a)

R1Module Component

R2<<Uses>> Connector

T rans form s to

M odular view

m odular view

C-C view

Fuente: Limón, Cabello y Ramos (2007).

Antes de definir las relaciones, debe elegirse un lenguaje para representarlas correctamente. Como ya se mencionó, en el caso específico de la mda, la omg propone el Meta Object Faci-lity (mof) para expresar metamodelos, y las Query/Views/Trans-

159


formations (qvt [2005]) para establecer las relaciones entre esos metamodelos Específicamente, el lenguaje de las qvt-Relations puede ser usado para describir dichas relaciones.

Inicialmente, deben darse los metamodelos fuente y des-tino. La correspondencia entre cada elemento de los metamode-los debe definirse de acuerdo con la manera en que sus reglas son representadas a través de las qvt. En este caso, los metamodelos fuente son el metamodelo modular y el metamodelo de la varia-bilidad v1, y el metamodelo destino es el metamodelo esquele-to. Las reglas consideradas en las relaciones de los elementos que se presentan en los metamodelos modular y de variabilidad v1 son del tipo check only (para verificar los elementos) en su parte izquierda, y del tipo enforce (para crear los elementos del meta-modelo esqueleto) en su parte derecha.

Al respecto nótese que no todos los elementos entre los modelos considerados tienen relaciones de correspondencia. La tabla 8 muestra algunas de las relaciones de correspondencia identificadas con su nombre, tipo (de acuerdo con las qvt) y los elementos implicados (clases).

Tabla 8. Algunas relaciones identificadas en el metamodelo modular y el metamodelo c-c

RelationIdentificationR1 = R2 X R1

Type

Classes involved by view

Modular view C-C view

moduleToComponet top Module Component

functionToService - Module, Function, Type

Component, Service, Port

rUseModToConnector top Uses, Module, Function

Connector, Role, Component, Port, Service

rCompositionModToComp top Composition, module

Composition component

Fuente: Limón et al. (2007).

160


En el caso de la aproximación bom, se identifican dos ti-pos de relaciones entre las vistas funcionales del sistema:

• Las relaciones entre las vistas modular y c-c.• Las relaciones entre vistas c-c.

Respecto a las vistas que definen la variabilidad de la spl, un modelo (mcd) captura la variabilidad del dominio: v1 (por ejemplo, el diagnóstico), y otro modelo (mcda) captura la varia-bilidad del dominio de aplicación: v2 (por ejemplo, el diagnósti-co médico, el diagnóstico educativo, etcétera).

Las relaciones anteriores se crean en el marco de la mda, como se muestra en la figura 48. Por su parte, mof se usa para especificarse a sí mismo (nivel m3) y para especificar los meta-modelos de las vistas y sus interacciones (nivel m2). También, las relaciones r1 y r2 se establecen en el nivel m2, donde r1 se aso-cia con las relaciones entre las vistas modular y c-c, y r2 con las relaciones entre vistas c-c. Sus respectivos perfiles son los sigui-entes:

R1 ⊆ MM MODULAR X MM V1 → MM SKELETON;defR2 ⊆ MM SKELETON X MM V2 → MM PRISMA;def

Un nivel más bajo (nivel m1) es donde las transforma-ciones t1 y t2 son aplicadas. Con la transformación t1, un pri-mer modelo, el modelo esqueleto, correspondiente al modelo de la arquitectura base, se obtiene al utilizar como fuente la vis-ta del modelo modular —correspondiente al modelo de la ar-quitectura genérica— y el modelo conceptual de la variabilidad del dominio (mcd): v1. Esta primera versión se refina al obtener la vista c-c (correspondiente al modelo de la arquitectura pris-ma) a través de la transformación t2, para ello utiliza el mode-lo conceptual referente a la variabilidad del dominio de aplica-ción (mcda): v2.

161


Figura 48. Relaciones entre metamodelos y transformaciones entre modelos, en el escenario de las spl

M3

M2

MODULAR VIEW / DCM SKELETON / ADCM

M1

R1

T1

R2

MOF

T2

C-C VIEW

Meta-models

Models

V1 V2


Relaciones entre vistas software En esta sección, las relaciones entre las vistas software mostradas en la tabla 8 se especifican en las qvt-Relations. El código y los programas son mostrados en la figura 49. Asimismo, y para ma-yor claridad, en esta sección se omite el prefijo esqueleto, es decir, el componente esqueleto será mencionado como componente, y el conector esqueleto se referirá como conector.

◊ Relación moduleToComponent Esta relación transforma cada uno de los módulos en un com-ponente. En la figura 49 (a) se muestran dos tipos de prefijos: checkonly y enforce. El objeto del módulo dominio es del tipo checkonly, y, en contraste, el objeto del componente dominio es del tipo enforce. Esto crea un objeto de la clase componente el cual se relaciona con la clase módulo. La cláusula where indica una llamada a la relación functionToService, misma que relacio-na un objeto de la clase función con un objeto de la clase servi-cio. El diagrama y el correspondiente código son mostrados en la figura 50 (a).

162


◊ Relación functionToService Esta relación implica que una función de la clase módulo gene-rará un servicio de la clase componente. En la cláusula where se obtiene el nombre del puerto, cuya función es llamada typePort. Cuando la relación es ejecutada, serán creadas sólo las clases que están en el metamodelo fuente (la clase ServiceToPort). El dia-grama y el correspondiente código son mostrados en la figura 49 (b).

◊ Relación rUseModToConnector La relación uses se transforma de la metaclase modular a la me-taclase conector para realizar la unión entre un conector y dos componentes en la metaclase c-c, como lo muestra la figura 50 (sección c). La cardinalidad de objetos de esta relación es 1 a n, porque una relación de dos componentes se establece a través de un conector. La misma figura (49 [c]) muestra parte del códi-go sobre cómo las relaciones son invocadas por la cláusula where para crear las relaciones entre módulo, componente y function-ToService.

◊ Relación rCompositionModToComp El conjunto de módulos también generará un conjunto de com-ponentes; por lo tanto, cuando un componente (contenedor) es creado, un subordinado es creado dentro de éste. Ello se mues-tra en la figura 49 (d).

163


Figura 49. Diagramas y códigos de las relaciones moduleToComponent (a), functionToService (b),

rUseModToConnector (c), y rCompositionModToComp (d)

top re lation moduleToComponent{ nam: String;

checkonly domain mod m: Module { name = nam};

enforce domain com c: Component{name = nam};

where{ responsibilityAservice(m,c)}}}

(a)

m:Module

name=nam

<<dom ain>>

C E

m od c omc:component

name=nam

<<dom ain>>

whereresponsabilidadAservic io (m ,c )

m:Module<<dom ain>>

C E

m od c omser: Service

name=nam

m: Port

name=namtype=typepto

fun:Funcion

name=nam

c:Component

name=nam

<<dom ain>>

typ:Type

name=nam

wheretypePto = typePort(typ)

re lation funtionToservice{ nam,ntyp,nser,typePto:String;checkonly domain mod m:Module {

function = fun:Function {name=nam, type = typ:Type {name=ntyp}}}

enforce domain c:Component{ service = ser:Service {name=nser}, port = pue:Port {nser=nser + 'pto', type = typePto}}

where {typePto = typePort(ntip) }}

function typePort(typeFun:String):String; { if (typeFun = 'LOCAL') then 'IN'

e lse if (typeFun = 'RESULT') then 'OUT' e lse 'IN OUT'

endifendif;

}}

(b)

top relationrUseModAConnector { ser_1, ser_2 :Service; comp_1, comp_2:Component;

nma,nmo,ncon,nfa,nfo,tfa,tfo : String.checkonly domain reluse ru:Use

{name=nuse, use = am:Module {name,nma, fun = fa:Funtcion {name=nfa, type=tfa}}

used = om:Module{name=nmo, fun = fo:Function {name=nfo, typo=tfo}} }................................

…………………where {

moduleToComponent (am,comp_1);moduleToComponent (om,comp_2);functionToService (fa,serv_1);functionToService (fb,serv_2);

}

use:Usenam= nuse

<<domain>>

C E

mod com

ca: Component

name=nca

pa: Port

name=npatype=typepto

ud:Modulenomb=nudo

c:Connectorname=nomc

<<domain>>

:Servicenam= nseu

:Servicenam= nsed

sa: Servicename=nsa

cb: Component

name=ncb

pb: Port

name=npbtype=typepto

sb: Service

name=nsb

ra: Rol

nor=nra

rb: Rol

nor=nrb

us:Modulenomb=nusa

wheremoduleTocomponent ( am, comp_1)moduleTocomponent ( om, comp_2)functionToservice(fa, fa,serv_1)functionToservice(fo,serv_2)

(c)

rc:Com pos it ion

name=nc

<<dom ain>>

C E

m od c om

ct:Com ponent

name=nomc

<<dom ain>>

c:Component

name= nom c o

sub:Modulo

name=npn

prop:Modulo

name=nps

top relationrCompositionModTocomp { nc, nct, nco, npn, nps, ncomp : String;

checkonly domainrcomp rc: Composition {name=nc, prop = mp:Module {name= npn} sub = ms:Module {name=nps}

}enforce domain cc:

Component{name = nct, container = cc; component = c : Component{ name = nco }}}

(d)

c ontainer :Com ponent

name= nom c o


164


Transformaciones entre modelosLa figura 50 muestra las transformaciones involucradas para construir arquitecturas de la spl. Esta figura ilustra cómo las transformaciones se realizan en el nivel modelo y son aplicadas en el proceso de dicha transformación. Es decir, las transforma-ciones t1 y t2 son ejecutadas en el nivel modelo (nivel m1 en el mof ) y son definidas en el nivel metamodelo (nivel m2 en el mof ).

En la transformación t1 se obtiene un primer modelo (modelo esqueleto) mediante las fuentes modelo modular y mo-delo mcd. En la transformación t2, al utilizar las fuentes modelo esqueleto y modelo mcda, se obtiene un segundo modelo (mode-lo prisma) como un refinamiento.

El modelo arquitectónico modular, como un paso pre-vio a la transformación t1, debe ser diseñado. Este modelo es-tá constituido por tres módulos (InferenceMotor, KnowledgeBase y UserInterface) que se unen entre sí a través de las relaciones de dependencia. A continuación, la transformación t1 es ejecuta-da y ésta produce el modelo esqueleto (modelo destino) al utili-zar como fuentes el modelo mcd y el modelo modular. Las figu-ras 50 y 51 muestran que un componente esqueleto es produci-do por cada módulo, y cada relación de dependencia genera un conector esqueleto. Las relaciones moduleToComponent y rUse-ModToConnector son las reglas aplicadas para generar el modelo esqueleto (usando los metamodelos como plantillas).

Las transformaciones t1 y t2 de modelos son ejecuta-das por medio de las qvt-Relations. En la transformación t1, las qvt-Relations deben tomar en cuenta la arquitectura genéri-ca, la instancia del mcd y la configuración de la arquitectura ba-se. En la transformación t2, las qvt-Relations deben tomar en cuenta la configuración de la arquitectura base, la instancia del mcda y la configuración de la arquitectura prisma.

165


Figura 50. Las transformaciones t1 y t2 de modelos

(Modular View)

MODULAR Meta-model

UML-Class Meta-model: MMV1

conforms_to

conforms_to

INFERENCE MOTOR

KNOWLEDGE BASE

USERINTERFACE

INFERENCE MOTOR

KNOWLEDGE BASE

USERINTERFACE

( C-C View)

SKELETON Meta-model

UML-Class Meta-model: MMV2

conforms_to

conforms_to

conforms_to

(C-C View)

PRISMA Meta-model

INFERENCE MOTOR

KNOWLEDGE BASE

USER INTERFACE CONNECTOR

INFERENCE MOTOR

KNOWLEDGE BASE

USERINTERFACE CONNECTOR

QVT-Relations

QVT-Relations

T1

T2


166


Figura 51. Las transformaciones t1 y t2 de modelos (expresados en niveles de mof)


167


Proceso bom para la transformación de modelos En este apartado se expone un proceso que permite el diseño de los sistemas expertos. Las tareas y elementos involucrados en el mismo son mostradas en la figura 52.

Las especificaciones de los metamodelos de las vistas mo-dular y c-c, y el diagrama de clases de uml, son los primeros elementos requeridos para inicializar este proceso. A continua-ción, las relaciones de correspondencia entre dichos elementos son identificadas y especificadas por medio del lenguaje qvt-Re-lations. Todas estas tareas son ejecutadas solamente una vez. La tarea de diseñar los modelos puede realizarse tantas veces como sea requerida.

La vista del modelo modular, el mcd y las relaciones esta-blecidas entre las vistas del metamodelo vista modular y el de vis-ta c-c, son usadas como fuentes en la transformación t1, la cual produce la vista del modelo esqueleto. A continuación, una se-gunda transformación t2 es aplicada para refinar al modelo es-queleto, en donde se toman como fuentes el mcda y dicho mo-delo para producir la vista del modelo prisma.

168


Figura 52. Tareas y elementos involucrados en el proceso para la transformación de los modelos

MM

1/M

M2

S1

S2

Ma

11

.*

Mb

n1

MM

3/M

M4

Aa

Ab

Sx

n1

Sy

n1

..+

MO

DU

LA

R

MM

: MM

1

SKE

LET

ON

M

M: M

M2

UM

L-C

LASS

M

M: M

M3

PRIS

MA

MM

: MM

4

TO

SPE

CIF

Y T

HE

ME

TA

-MO

DE

LS

TO

IDE

NT

IFY

R

ELA

TIO

NS

OF

CO

RR

ESP

ON

DE

NC

ES

TO

SPE

CIF

Y

TH

E R

ELA

TIO

NS

TO

DE

SIG

N

TH

E M

OD

ULA

R M

OD

EL,

TH

E D

CM

MO

DE

L: V

1,A

ND

TH

E A

DC

M M

OD

EL

: V2

QV

T-R

elat

ions

TO

TR

AN

SFO

RM

T

HE

MO

DU

LAR

MO

DE

LT

O T

HE

SK

ELE

TO

N M

OD

EL

TO

TR

AN

SFO

RM

T

HE

SK

ELE

TO

N M

OD

EL

TO

TH

E P

RIS

MA

MO

DE

L

task

that

can

be p

erfo

rmed

sev e

ral

times

task

that

ispe

rfor

med

only

one

time

KE

Y

INF

ER

EN

CE

MO

TO

R

CO

NN

EC

TO

RC

ON

NE

CT

OR

KN

OW

LE

DG

E B

ASE

USE

R I

NT

ER

FA

CE

connect

or

INF

ER

EN

CE

MO

TO

R

CO

NN

EC

TO

RC

ON

NE

CT

OR

KN

OW

LE

DG

E B

ASE

USE

R I

NT

ER

FA

CE

connect

or

INF

ER

EN

CE

MO

TO

R

CO

NN

EC

TO

RC

ON

NE

CT

OR

KN

OW

LE

DG

E B

ASE

USE

R I

NT

ER

FA

CE

connect

or

T2

T1

INF

ER

EN

CE

P

RO

CE

SS

KN

OW

LE

DG

E

BA

SE

USE

R

INT

ER

FA

CE

INF

ER

EN

CE

P

RO

CE

SS

KN

OW

LE

DG

E

BA

SE

USE

R

INT

ER

FA

CE

Fuente: Adaptada de Limón et al. (2007).

169


ConclusionesLa especificación presentada en este capítulo, cuya función es el desarrollo de la spl por medio de las qvt-Relations como téc-nica de transformación de modelos para el tratamiento de la variabilidad, muestra que esta aproximación (bom-lazy) reali-za el proceso de gestión de la variabilidad en el dominio de los sistemas software de manera más compleja que la aproximación bom-eager.

El número de reglas qvt se multiplica: una al menos por cada camino que une la raíz con una hoja del árbol de decisión y por cada artefacto de la vista modular, a efectos de considerar la variabilidad de las arquitecturas base mediante el tratamiento de la variabilidad v1.

Asimismo, por cada característica o conjunto de caracte-rísticas de la aplicación es necesario introducir una regla qvt. La idea que subyace en el fondo es que la Baseline aparece plasma-da en el código de las qvt-Relations, complicando innecesaria-mente el proceso.

El uso de transformaciones con las qvt-Relations debe tomar en cuenta al modelo de la variabilidad y al modelo arqui-tectónico. En la primera transformación t1 debe considerar a la arquitectura genérica y al modelo conceptual de la variabilidad del dominio, y en la segunda transformación t2 a las arquitec-turas base y al modelo conceptual de la variabilidad del domi-nio de la aplicación, lo cual implica una solución computacio-nal y algorítmica, de esta manera se obtienen complejas reglas de transformación.

Una solución ad hoc para la complejidad en el manejo de la variabilidad, con las qvt, se presentó en el capítulo anterior a través de las técnicas que utiliza la aproximación bom-eager. Sin embargo, si la spl es de cardinalidad alta, resulta más convenien-te aplicar la aproximación bom-lazy (expuesta en el presente ca-pítulo) debido a que el problema de la complejidad (con el uso

170


de qvt-Relations) sería menor que si se construyeran todos y ca-da uno de los assets contenidos en la Baseline (como la aproxima-ción bom-eager), lo cual incrementaría notablemente el núme-ro de ramas en el árbol de decisión para poder acceder a la gran cantidad de productos de la spl que se desarrolla.

171

Capítulo viii

Modelado del proceso de desarrollo de la línea de productos software en bom

En el punto donde se detiene la ciencia, empieza la imaginación.Jules de Gaultier

Este capítulo presenta detalladamente cómo se lleva a cabo el modelado para el desarrollo de la spl, el cual se realiza en dos

partes: la ingeniería del dominio y la ingeniería de la aplicación. Dichos procesos son modelados a través de dos estándares de la omg: Reusable Asset Specification (ras, 2005) y Software Process Engineering Metamodel (spem, 2006).

Proceso para crear la línea de productos softwareEl modelado del proceso para crear a la spl define el conjun-to de recursos o activos principales (core assets) con los cuales se crea una familia de productos software. Dicho modelado se basa en el estándar de la especificación de recursos reutilizables (ras) para definir de modo estándar toda la información asociada a un activo o recurso reutilizable, a través de la cual es posible mani-pular y reutilizar dicho activo; y en el estándar del metamode-lo de ingeniería de procesos software (spem) como lenguaje que modela procesos de desarrollo en esta área mediante una termi-nología común y estándar, permitiendo el modelado de muchos aspectos y actividades relacionadas con el proceso de desarrollo de software.

172


Al respecto es conveniente mencionar que, para el mode-lado se consideró como un artefacto software a cualquier pro-ducto de trabajo creado durante un proceso para desarrollar software, tal como modelos, documentos de requisitos, archivos de código fuente, archivos de configuración xml, .doc, .xls, et-cétera, que resuelven problemas recurrentes en el desarrollo de software. Asimismo se consideró que un activo es una colección cohesiva de artefactos software que resuelven un problema es-pecífico o un conjunto de problemas, así como la metainforma-ción para facilitar su reutilización. Un activo se almacena como un archivo comprimido que empaqueta un conjunto de archi-vos, cada uno representando uno de estos artefactos.

Respecto al lenguaje de modelado, aunque el metamode-lo spem es muy extenso, este trabajo se centró en el modelado de tareas, para lo cual se utilizó relaciones de secuencia pero sin prioridad entre las mismas. Dichas tareas, ejecutadas por roles, consumen artefactos de entrada y producen artefactos de sali-da. Además, algunas tareas tienen asociados elementos guía que ayuden al rol a desempeñar dicha tarea.

La tabla 9 presenta los iconos estándar de spem utilizados en este libro, así como su significado.

173

Capítulo VIII. Modelado del proceso de desarrollo de la línea...

Tabla 9. Iconos estándar de spem utilizados en el modelado de la spl

Icono Significado

Actividad

Rol del ingeniero

Guía

Proceso

Producto de trabajo

Modelo en uml(especialización de producto de trabajo)

Documento(especialización de producto de trabajo)


Asimismo, en la siguiente tabla (10) se presentan los ico-nos de spem creados ex profeso para el modelado de la spl en bom.

174


Tabla 10. Iconos de spem creados ex profeso para el modelado de la spl

Icono Significado

Esqueleto(aspecto)

Aspecto tipo prisma

Interfaz tipo prisma

Componente tipo prisma

Conector tipo prisma

Esqueleto aspecto-proceso inserción de características

Híbrido empaquetado

MI 3

C 3U 3

BC 3

Modelo arquitectóinico tipo prisma

Configuración del modelo arquitectónico

Caja(Kit-Box)

Baseline


175


Al respecto, existen algunas herramientas para el mode-lado en spem, por ejemplo, la que incorpora Visual Studio, pero las herramientas que soporta spem no son ejecutables sino grá-ficas, por lo tanto, la expresividad de los iconos utilizados pue-de realizarse con otro tipo de herramientas como Power Point, el cual utilizó este trabajo para realizar varios iconos (como es-pecializaciones del icono producto del trabajo) que ex profeso se elaboraron para dibujar los assets, la Baseline y el plan de produc-ción. Por ello, se aprovechó el esfuerzo y tiempo invertidos, y da-do que la expresividad en Power Point de la vista final es la mis-ma, se decidió continuar de esa manera hasta el final.

Al usar como referencia la aproximación de Clements et al. (2001), para producir la spl en la que se clasifican los pro-cesos de desarrollo de las spl, se describen a continuación las ta-reas realizadas en dichos procesos. Sin embargo, debe señalarse que en este trabajo se introdujo un cambio importante el cual constituye una de sus aportaciones: la Baseline contiene, como un activo más, el plan de producción de la spl. De esta forma se incrementa notablemente la automatización en la producción de un producto de la spl. Por ello se fusionaron —en la fase de la ingeniería del dominio— las tareas de desarrollo de los compo-nentes básicos reutilizables y del plan de producción en una úni-ca tarea (desarrollo de componentes básicos reutilizables):

Ingeniería del dominio:1) Análisis del dominio2) Desarrollo de los componentes básicos reutilizablesTareas:

• Crear modelo de características.• Crear árbol de decisión.• Crear procesos de selección de activos.• Crear modelo conceptual del dominio. • Crear modelo conceptual del dominio de aplicación. • Crear esqueletos.

176


• Crear artefactos tipo prisma.• Crear proceso principal de inserción de características del do-

minio de aplicación.• Crear procesos de inserción de las características del dominio

de aplicación. • Crear esqueletos aspecto-proceso.• Crear híbridos empaquetados.• Crear configuración del modelo arquitectónico.• Crear modelos ras de activos.• Crear cajas (kit-boxes).• Crear el plan de producción de la spl. • Crear la Baseline.

Ingeniería de la aplicación:1) Caracterización del producto:Tareas:

• Obtener características del dominio. • Seleccionar activos.• Desempaquetar caja.• Obtener características del dominio de aplicación.• Crear aspectos tipo prisma.

2) Síntesis del productoTareas:

• Construir especificación prisma.3) Construcción del productoTareas:

• Compilar modelo arquitectónico (generar código).• Crear sistema ejecutable.

De manera general se concluye que, el ingeniero de do-minio es quien crea el plan de producción y los artefactos soft-ware que son utilizados para llevar a cabo sus tareas; y el inge-niero de la aplicación es quien ejecuta el plan de producción de la spl.

En el mismo contexto, si se comparan las actividades que deberán realizar los analistas de bom, en sus roles de ingeniero

177


del dominio o ingeniero de la aplicación, se observa que el traba-jo del ingeniero de dominio es más complejo, ya que éste diseña con detalle modelos, recursos reutilizables y procesos adecua-dos para generar cada uno de los productos de la línea, así como especificar al ingeniero de aplicación cómo puede obtener una solución concreta a través de lenguajes específicos de dominio (los modelos conceptuales de la variabilidad).

En cambio, el trabajo del ingeniero de la aplicación es considerablemente sencillo, pues trabaja en un mayor nivel de abstracción sin preocuparse de las tareas de configuración de los componentes básicos reutilizables; además, dirige sus esfuerzos en la especificación de las características deseadas para el produc-to a generar. El ingeniero de la aplicación sólo debe realizar la ta-rea de configuración; éste será el ejecutor del plan de producción que previamente fue diseñado por el ingeniero de dominio. Con esta aproximación el ingeniero de la aplicación está obligado a seguir el plan predefinido por el ingeniero del dominio.

El ingeniero del dominio debe ser suficientemente exper-to para determinar la plataforma común que comparte toda la familia de productos. La plataforma de una spl es “el conjun-to de subsistemas software e interfaces que forman una estruc-tura común desde la cual un conjunto de productos pueden ser producidos y desarrollados eficientemente” (Meyer y Lehnerd, 1997).

Las partes que componen la plataforma son denomina-dos componentes básicos reutilizables o assets (Clements y Nor-throp, 2001). Éstas pueden incluir la arquitectura, los compo-nentes software, los modelos diseñados, etcétera. En general, puede utilizarse cualquier artefacto (Pohl et al., 2005). La plata-forma es la base sobre la cual los productos pueden ser creados si se adicionan características (variabilidad). Nuestra platafor-ma consiste en un conjunto de assets que incluye elementos ar-quitectónicos en el marco del metamodelo prisma, esqueletos o

178


plantillas de aspectos prisma, así como procesos y modelos con-ceptuales.

Asimismo debe aclararse que el ingeniero del dominio no aborda la creación directa de la spl (esa actividad la desempeña el ingeniero de la aplicación), sino la generación de familias de activos. A medida que el ingeniero del dominio encuentra simi-litudes (a través de los puntos de variabilidad) entre los activos que va creando en los diferentes dominios específicos, formará familias de activos organizándolos en forma de spl. De este mo-do el ingeniero del dominio creará una spl para generar la fami-lia de productos.

Cuando el ingeniero del dominio desee crear un activo, inspeccionará la Baseline en busca de uno que cubra sus requeri-mientos. Si ninguno de los miembros de la familia satisface sus necesidades, deberá crear un activo por su cuenta, a partir del miembro que más se adecue a éstas. Cuando termine la tarea de creación, deberá realizar la ingeniería del dominio para incluir la nueva variante en la familia de productos y almacenarla así en la Baseline.

A partir de este momento, el proceso de configuración del activo permitirá generar la nueva variante de activos, para ser aplicada siempre que se repitan las condiciones que origina-ron su aparición. De acuerdo con esto es importante conside-rar que el ingeniero del dominio deberá tener un amplio cono-cimiento del dominio, con el fin de seguir patrones y establecer similitudes.

Ingeniería del dominio: Creación de la BaselineEn esta primera fase se crean todos los activos y se describe el proceso de configuración de activos así como el plan de produc-ción de la familia de productos. No obstante, una spl requiere almacenar sus activos en un repositorio. En el presente trabajo, todos los activos son depositados en la Baseline, por ello se pre-

179


senta toda la fase de la ingeniería del dominio como la fase don-de se construye la Baseline.

La Baseline es un repositorio especializado que almacena activos de software y facilita su recuperación y mantenimiento. Su objetivo es asegurar la disponibilidad de los activos para apo-yar el desarrollo de productos de la spl.

En la Baseline se plasman tanto los activos como el cono-cimiento necesario para que bom operacionalice lo almacenado con el fin de obtener el producto final, lo cual incrementa la au-tomatización. Al respecto debe señalarse que, tanto para crear la Baseline, como para explotarla, se utilizan modelos. En la Base-line se materializa la variabilidad del dominio, de forma que és-ta es en sí una spl.

A continuación se listan todos los artefactos software creados por el analista que desempeña el rol de ingeniero del dominio, con el fin de obtener la Baseline como un artefacto más. Asimismo, se muestran en spem las tareas que implican la creación de la Baseline y los activos implicados, también se co-menta brevemente su uso en la ingeniería de la aplicación.

Las tareas que están presentes en la primera fase de la ingeniería del dominio son realizadas en dos partes: el análisis del dominio, y el desarrollo de los componentes básicos reutiliz-ables y del plan de producción.

Análisis del dominioEn el análisis del dominio se estudia la variabilidad del dominio (en este caso el del diagnóstico) en términos de sus característi-cas. Al respecto Arango y Prieto-Díaz (1991) mencionan que en el análisis del dominio es donde se adquiriere y se modela el co-nocimiento sobre el dominio; aquí se realiza una búsqueda de elementos comunes y diferencias en la familia de sistemas que lo conforman. Esta etapa es muy importante para desarrollar una línea de productos, ya que los dominios son analizados y la in-

180


formación sobre éstos es capturada y organizada en modelos del dominio y en elementos software reutilizables (assets).

Desarrollo de los componentes básicos reutilizablesDurante el desarrollo de los componentes básicos reutilizables (assets) se conciben, diseñan e implementan los assets. Esto no sólo involucra el desarrollo de la funcionalidad del dominio, sino también define cómo los assets deben ser extendidos. Los assets correspondientes a esta etapa se enuncian a continuación.

◊ El modelo de características Éste identifica la spl en términos de la variabilidad del dominio. Las características de este modelo son plasmadas en un árbol de decisión (véanse las figuras 53 y 54).

Figura 53. Creación del Modelo de Características (notación en spem)

FEATURE MODEL

<<out>>

VARIABILITY OF DIAGNOSTIC DOMAIN

Create Feature Model


181


Figura 54. Modelo de CaracterísticasDIAGNOSIS

Property Levels

ReasoningHypotheses

same change

1 2

1

deductive differential

Use Cases

1 3

Actors

1 2

Use Cases by Actor

1 1-2

NOMENCLATURE: and or

(select 1)mandatory optional

>1

Entity Views


◊ El árbol de decisión Las características observadas en el modelo de características son plasmadas en el árbol de decisión. Los puntos de variabilidad que conforman la primera variabilidad están representados en los nodos del árbol de decisión, y las hojas del árbol represen-tan las familias de assets de la spl. Las rutas del árbol de decisión son plasmadas en el proceso de selección de assets (véanse las fi-guras 55 y 56).

Figura 55. Creación del árbol de decisión (notación en spem)

FEATURES MODEL

<<out>><<in>>

DECISION TREE

Create Decision Tree


182


Figura 53. Árbol de decisión

change

Reasoning

diferencialdeductiv e

Prop erty Levels

221

Use Cases

Actors

Use Cases by Actor

Hypotheses

1 >1

11 1 3

11 1

2

1 1 1

same

1- 2

Entity Views


Los puntos de variabilidad (vp, por sus siglas en inglés [Variability Points]) plasmados en el árbol de decisión son repre-sentados mediante sus variantes (véase la tabla 11):

Tabla 11. Puntos de variabilidad y sus variantes

Entity Views = {same, change} vp1 = {v11, v12}

Reasoning={deductive, differential}

vp2 = { v21, v22}

Hypotheses = {1, >1} vp3 = { v31, v32,}

Property Levels = {1,2} vp4 = { v41, v42, v43}

Use Cases = {1,3} vp5={v51,v52,v53,v54,v45}

Actors = {1,2} vp6={v61, v62, v63, v64}

Use Cases per Actor = {1, 1-2} vp7 = {v71, v72, v73, v74}


183


◊ El proceso de selección de assets El ingeniero del dominio, para crear este proceso, se apoya con el árbol de decisión y la información que contiene la Baseline. Este proceso computa las trayectorias del árbol de decisión para selec-cionar assets, de acuerdo con los puntos de variabilidad seleccio-nados del dominio. Cada hoja del árbol representa la familia de assets seleccionada y está contenida en una caja (Kit Box [véanse las figuras 57 y 58]). La información del contenido de la Base-line está representada por: Baseline = {caja1, caja2, caja3, caja4, Plan de Producción},

Donde la caja i corresponde a la familia i de assets (empa-quetados en una caja). Este proceso es ejecutado por bom en la fase de la ingeniería de la aplicación, cuando el ingeniero confi-gura el mcd en donde aporta al sistema la información del do-minio específico (es decir, las variantes de los puntos de variabi-lidad del dominio).

Figura 57. Modo en que se crea el proceso de selección de assets (notación en spem)

ASSET SELECTION PROCESS

<<out>>

DECISION TREE

<<in>> <<in>>

INFORMATION OF BASELINE

CreateAsset Selection Process


184


Figura 58. Proceso de selección de assets

change

Reasoning

differencialdeductive

Property levels

221

Use Cases

Actors

Use Cases by Actor

Hypotheses

1 >1

1 1 1 3

1 1 1 2

1 1 1

same

1- 2

Entity Views

BOX 1 BOX 2 BOX 3 BOX 4


El proceso de selección de assets está representado por las trayectorias que recorren el árbol de decisión, conforme a las va-riantes de los puntos de variabilidad elegidos por el ingeniero de la aplicación. Cada trayectoria sigue un camino desde la raíz del árbol de decisión hasta sus hojas que apuntan a la caja seleccio-nada. En este libro se contemplan las siguientes trayectorias:

Tabla 12. Trayectorias del árbol de decisión

Path 1= [v11,v21,v31,v41,v51,v61,v71]⇒ Kit-Box1





185


◊ El modelo conceptual del dominio (mcd) Las características como puntos de variabilidad presentes en el modelo de características y en el árbol de decisión, están presen-tes en el modelo conceptual del dominio, el cual captura la va-riabilidad del dominio. En la ingeniería de la aplicación, este ar-tefacto es usado cuando el ingeniero introduce en el sistema, como una instancia de dicho modelo, las variantes (la informa-ción del dominio específico) a través de bom, con el fin de selec-cionar las cajas contenidas en la Baseline (véanse las siguientes fi-guras 59 y 60).

Figura 59. Creación del Modelo Conceptual del Dominio (notación en spem)

DOMAIN CONCEPTUAL MODEL

<<out>>

VARIABILITY OF DOMAIN

CreateDomain Conceptual Model


186


Figura 60. Modelo Conceptual del Dominio (mcd)


187


◊ El modelo conceptual del dominio de la aplicación (mcda) Este modelo captura la variabilidad del dominio de aplicación. Con este artefacto software bom obtiene, del ingeniero de la aplicación, las características de un dominio de aplicación espe-cífico, con el fin de decorar las arquitecturas base de ese dominio (véanse las figuras 61 y 62).

Figura 61. Creación del Modelo Conceptual del Dominio de la Aplicación (notación en spem)

<<out>>

VARIABILITY OF APPLICATION DOMAINS

APPLICATION DOMAIN CONCEPTUAL MODEL

Create ApplicationDomain Conceptual Model


188


Figura 62. Modelo Conceptual del Dominio de la Aplicación (mcda)


◊ Los esqueletos o plantillas de assets Los esqueletos son plantillas especificadas en el adl de prisma que contienen huecos, los cuales posteriormente serán rellena-dos con las características del dominio de la aplicación, confor-mando de esta manera un aspecto tipo prisma. Por ello, los es-

189


queletos de la spl tratada en este libro son representados por me-dio de los aspectos (es decir, un aspecto prisma pero con hue-cos). Además sólo se consideró un aspecto para cada elemento arquitectónico (puede existir más de un aspecto en un elemen-to arquitectónico). Así, se consideró el aspecto funcional de los componentes y el aspecto de coordinación de los conectores. Los aspectos esqueletos son utilizados en la etapa de la ingeniería de la aplicación cuando bom los recupera de la Baseline y los relle-na con las características del dominio de la aplicación. Estas ca-racterísticas, desde el inicio, son proporcionadas al sistema por el ingeniero de la aplicación por medio de una instancia del mcda. Los aspectos esqueleto rellenados o decorados son los aspectos tipo prisma, que son usados para configurar el modelo arquitec-tónico de un sistema experto (véase la figura 63).

Figura 63. Creación de los aspectos esqueletos (notación en spem)


Un esqueleto se considera como un tipo prisma con hue-cos, dichos huecos serán rellenados con las características del do-minio de aplicación (es decir, las propiedades de la entidad del dominio, las hipótesis y las reglas, las cuales se corresponden con los atributos del aspecto tipo prisma). Así, resulta lógico considerar que los esqueletos contienen n huecos según la can-

190


tidad de características. De esta manera, si un esqueleto no tie-ne huecos (llamado esqueleto degenerado) es porque no tendrá ninguna característica que insertar (es decir, no tendrá atributos cuando se convierta en tipo prisma). Un ejemplo de esqueleto degenerado es el correspondiente al aspecto de coordinación de un conector.

Esta situación provoca que el aspecto de coordinación siempre sea un tipo prisma y no un esqueleto, sin embargo, para utilizar una nomenclatura unificada, dicho artefacto software es tratado como esqueleto (es decir, esqueleto degenerado).

En el modelo prisma el conjunto de aspectos que con-forman un elemento arquitectónico es visto como la cara de un prisma, de modo que dicho elemento tendrá tantos aspectos co-mo caras de un prisma. Aunque se consideró sólo un aspecto por elemento, en la metáfora visual se rellenó todo el prisma. Una metáfora visual de un esqueleto es la siguiente:

Figura 64. Metáfora visual de un esqueleto (aspecto)


◊ Los tipos prisma (interfaces, elementos arquitectónicos y modelo arquitectónico) Las interfaces, los elementos arquitectónicos (componentes y co-nectores) y el modelo arquitectónico, son considerados como ar-tefactos software tipo prisma debido a que no involucran en su especificación a las características del dominio de la aplicación. Una interfaz contiene el conjunto de servicios que se reciben/en-vían a través de un puerto que pertenezce a un elemento arqui-tectónico. Las interfaces no involucran features, por ello no son consideradas como esqueletos, sino tipos prisma. Una metáfo-ra visual de una interfaz es mostrada en la siguiente figura (65).

191


Figura 65. Metáfora visual de una interfaz tipo prisma


Los aspectos tipo prisma son los aspectos esqueleto relle-nos con las características que presenta el dominio de la aplica-ción del diagnóstico, es decir, el dominio específico del caso de estudio. Por ello, la metáfora visual de un aspecto tipo prisma se representa con los mismos iconos pero con color, es decir, relle-nados con las características que fueron insertadas.

En el modelo prisma los elementos arquitectónicos im-portan los aspectos que lo conforman. Los cuatro elementos ar-quitectónicos del prisma, básicos para la spl de este trabajo, son los siguientes:

• El componente InferenceMotor que establece el control del sis-tema y la estrategia general de la solución para tomar decisio-nes (por ejemplo obtener un diagnóstico). Este componente presenta un aspecto funcional.

• El componente KnowledgeBase que contiene el conocimien-to del dominio, respecto al caso de estudio, en forma de reglas de inferencia (cláusulas de Horn con cabeza) y hechos (infor-mación que permanece constante). Este componente presen-ta un aspecto funcional.

• El componente UserInterface que establece la interacción hom-bre-máquina, lo cual permite la comunicación entre los usua-rios y el sistema. A través de este componente el usuario ofrece los datos al sistema o responde a preguntas formuladas por éste. El componente UserInterface presenta un aspecto funcional.

• El conector Coordinator que contiene la coreografía llevada a cabo por el proceso del dominio (por ejemplo el proceso del diagnóstico), y sincroniza los servicios que son enviados/reci-bidos por los componentes que une. Este conector presenta un aspecto de coordinación.

192


La siguiente figura (66) muestra una metáfora visual de un componente y un conector tipo prisma:

Figura 66. Metáfora visual de un componente (a) y un conector (b) tipo prisma


Las interfaces, los elementos arquitectónicos y la configu-ración no contienen los huecos semánticos, es decir, no conlle-van features; por ello, estos artefactos software no son considera-dos esqueletos sino tipos prisma. Estos artefactos son almacena-dos en la Baseline (véase la figura 67).

Figura 67. Creación de los artefactos tipo prisma (notación en spem)

<<out>>

<<in>><<in>>

<<in>>

<<in>>

CreatePRISMA types

MI 3

C 3U 3

BC 3

PRISMA TYPES

DSSMODEL

PRISMA MODEL

PROCESS TO CREATE ARCHITECTURES

VARIABILITY POINTS


193


◊ La configuración del modelo arquitectónico Este asset captura la forma en que es configurada una arquitec-tura prisma por medio de la instanciación de los artefactos soft-ware tipo prisma que lo conforman y las conexiones entre éstos. Dicho asset es almacenado en la Baseline. En la ingeniería del do-minio, el modelo de configuración y los artefactos tipo prisma son tomados por bom con el fin de compilar este modelo, así se obtiene el código.

Figura 68. Proceso para crear las configuraciones de los modelos arquitectónicos (notación en spem)


◊ El proceso principal para la inserción de características Éste es el proceso general, llamado inserción de las características del dominio de la aplicación, el cual invoca a los procesos indivi-duales de inserción de características asociados con los esquele-tos (aspectos). Véanse las siguientes figuras (69 y 70).

194


Figura 69. Creación del proceso principal para la inserción de características (notación en spem)

MAIN FEATURE INSERTION PROCESS

<<out>>CreateMain Feature Insertion Process

FEATURES


Figura 70. Proceso principal para la inserción de características

FEATURE INSERTION PROCESSES 4_1, 4_2, 4_3, 4_4, 4_5, 4_6, 4_7

MAIN FEATURE INSERTION PROCESS 4

4_1

1

4_2

4_3

4_4

4_5

4_6

4_7

invoke


195


◊ Los procesos para la inserción de características Cada uno de estos procesos es usado para insertar las caracterís-ticas del dominio de aplicación en los esqueletos (aspectos). Es-tos procesos son invocados por el proceso principal para la inser-ción de características (véase la figura 71).

Figura 71. Creación de los procesos para la inserción de características (notación en spem)

FEATURE INSERTION PROCESSES

<<out>><<in>>


CreateFeature Insertion Processes


◊ Los esqueletos “aspecto-proceso” Cada uno de estos assets está formado por un esqueleto aspec-to y su correspondiente proceso para la inserción de caracterís-ticas. Estos assets, cuyo fin es decorar los esqueletos y convertir-los en tipos prisma, son ejecutados en la ingeniería de la aplica-ción (véase la figura 72).

196


Figura 72. Creación de los esqueletos aspecto-proceso (notación en spem)


◊ Los híbridos empaquetados Un asset empaquetado es un paquete software conformado por varios assets. Este asset se almacena como un archivo comprimi-do que empaqueta un conjunto de archivos, donde cada uno re-presenta a uno de estos artefactos.

Un híbrido empaquetado está compuesto por un esque-leto aspecto-proceso y sus respectivas interfaces y elemento arqui-tectónico tipo prisma, mismos que son empaquetados en un nuevo asset. Estos assets son depositados en la Baseline. En el do-minio de la aplicación, los híbridos empaquetados seleccionados son desempaquetados para que puedan utilizarse cada uno de los elementos que lo integran (véase la figura 73).

197


Figura 73. Creación de los híbridos empaquetados (notación en spem)


◊ Los modelos ras de los assets El modelo ras de un activo es un modelo que conforma al me-tamodelo ras. Este modelo hace referencia a los artefactos con-tenidos en el activo, así como la metainformación para facilitar su reutilización, actividades que permitirán configurar la varia-bilidad de los artefactos contenidos en el activo para obtener, del mismo, soluciones concretas. Este modelo se empaqueta junto al resto de artefactos dentro del archivo comprimido que repre-senta al activo, el cual contiene la identificación y la clasificación del activo, la descripción de sus artefactos, sus puntos de varia-bilidad y cómo configurarlos. La metainformación que describe un activo se define por un archivo configurado en xml que con-tendrá el modelo ras del activo.

En bom, un modelo ras almacena la información de ca-da uno de los assets que están contenidos en una caja: identifica-dor id de cada asset, clasificación de los assets, descripción de los assets y los puntos de variabilidad del dominio asociados a esos assets (véase la figura 74).

198


Figura 74. Creación de los modelos ras (notación en spem)

RAS MODELS OF THE ASSETS

<<out>>

ASSET IDS

ASSET CLASSIFICATIONS

DESCRIPTIONOF THE ASSETS

VARIABILITY POINTS

<<in>><<in>><<in>>

<<in>>

CreateRAS Models


◊ Las cajas (kit-boxes)Los assets seleccionados por el ingeniero de la aplicación, para formar familias de spl con características comunes (de la prime-ra variabilidad), son empaquetados como un asset. Los assets em-paquetados conforman cajas cuyo contenido (activos y conoci-miento de cómo hacer) es construido en esa misma fase (véase la figura 75).

199


Figura 75. Creación de las cajas (notación en spem)


La siguiente figura (76) muestra una metáfora visual de una caja y su contenido.

Figura 76. Ejemplo de una caja (kit-box)

BOX 1

Skeleton 1_4 Feature InsertionProcess 1_4

InterfacePRISMA type1_4

Architectural ElementPRISMA type 1_4

Architectural ModelConfiguration 1

Main Feature InsertionProcess 1

ADCM 1

RAS Model 1

Packaged Hybrid 1_4

Aspect-Process Skeleton 1_4

MI 3

C 3U 3

BC 3

Architectural Model Type 1

KIT-


200


◊ El plan de producción de la Línea de Productos Software Este proceso muestra el ciclo de vida que presenta bom para la producción de una spl. Dicho proceso, en la etapa de la inge-niería del dominio, es depositado en la Baseline como un activo. En la ingeniería de la aplicación, el plan de producción se lleva a cabo para generar un sistema experto como producto de la spl (véase la figura 77).

Figura 77. Creación del plan de producción (notación en spem)

PRODUCTION PLAN OF THE SPL(SPEM)

<<out>>CreateProduction Plan


El planeamiento de la producción implica la capacidad de fábrica de la spl. En esta etapa se define cómo los productos software individuales son creados; para ello asimismo se creó el plan de producción de una familia de productos contenidos a su vez en una spl, ya que la realización de dicha producción es par-te de la ingeniería de la aplicación.

El ingeniero del dominio describirá el proceso de confi-guración del activo como el plan de producción de la spl. La fi-gura 78 muestra, en spem, el proceso a seguir en la ingeniería de la aplicación para el plan de producción de una spl.

Así también debe señalarse que dicho proceso (la confi-guración del activo, que es el plan de producción de una línea de productos) es automático y obligatorio, con ello se obliga al ingeniero de la aplicación a utilizar las variantes ofrecidas por el

201


activo reutilizable. De esta manera, el ingeniero de la aplicación no puede crear cualquier sistema de diagnóstico sino que se le obliga a seguir el plan, para lo cual puede seleccionar únicamen-te una de las variantes de la línea y a su vez elegir las característi-cas que lo identifican.

De esta forma se obtienen dos ventajas: la primera es obligar a seguir patrones y buenas prácticas de modelado que el ingeniero del dominio —al realizar esta tarea— ha establecido progresivamente mientras creaba el activo, y la segunda es cen-tralizar el conocimiento con el fin de auxiliar a nuevos ingenie-ros de la aplicación para que éstos aprendan a realizar dicha ta-rea (véase la figura 78).

Figura 78. El plan de producción de la spl en bom (notación en spem)

Obtain domainfeatures

Select assetsUnpackageKit-Box

Obtain applicationdomain features

Create aspectPRISMA types

Build PRISMAspecification

Compile architectural model

Create executablesystem

…

…


◊ La Baseline La Baseline es el último asset que se construye en la ingeniería del dominio, dado que es el repositorio de todos los assets necesarios para obtener un producto de la spl (véase la figura 79).

202


Figura 79. Creación de la Baseline (notación en spem)


La Baseline está formada por un conjunto de assets em-paquetados formando cajas. Además de estas cajas, la Baseline contiene el plan de producción de la spl como un assets más. Dicho contenido implica que la Baseline es un repositorio tanto de todos los assets como del conocimiento necesario para produ-cir la spl, lo cual es una novedad en las spl y una de las aporta-ciones de este trabajo.

La Baseline es utilizada en la ingeniería de la aplicación para elegir de este repositorio los assets (cajas o kit-boxes) corre-spondientes al dominio específico. La Baseline está representada de la siguiente manera:

Baseline = {Kit-Box1, Kit-Box2, Kit-Box3, Kit-Box4, Production Plan}

Una metáfora visual de la Baseline se presenta en la si-guiente figura (80).

203


Figura 80. Metáfora visual de la Baseline

BASELINEBASELINE

Production Plan of SPL

KIT-BOX 1

MI 3

C 3U 3

BC 3

KIT-BOX 2

MI 3

C 3U 3

BC 3

KIT-BOX 3

MI 3

C 3U 3

BC 3

KIT-BOX 4

CONNECTOR 2

INFERENCEMOTOR

INTERFACEUSER 2

CONNECTOR 1

INTERFACE USER 1

CONNECTOR 3 KNOWLEDGEBASE

13

2

2

2

2

1

1

1

32

32

3

3

1

3


Ingeniería de la aplicación: Ejecución del plan de producciónEn esta segunda fase, las diversas tareas relativas al proceso de de-sarrollo del software para el plan de producción de la spl son eje-cutadas por el rol del ingeniero de aplicación; por ello, debe re-calcarse que este plan de producción será el proceso de configu-ración del activo del diagnóstico específico que se encuentra en desarrollo.

Las spl proponen la reutilización del mismo conjunto de activos principales para generar una línea de productos (Cle-ments et al., 2001). En esta estrategia es de vital importancia la capacidad de los activos para ser configurados por el ingeniero de la aplicación. El proceso de configuración de activos, con el cual se genera una aplicación concreta, puede ser modelado uti-lizando spem.

204


En la fase de la ingeniería de la aplicación se realiza el plan de producción; éste fue creado en la fase ingeniería del dominio como un asset.

Así pues, debido a que, como resultado de este trabajo, se proponen dos aproximaciones para el desarrollo de la spl, a con-tinuación se presenta el plan de producción de la spl de acuerdo con la perspectiva de cada aproximación.

Plan de producción de la línea de productos software en la aproximación bom-eager

En la aproximación bom-eager, la Baseline es utilizada en la fase ingeniería de la aplicación como uno de los recursos que poseen las tareas del plan de producción de la spl para seleccionar los as-sets contenidos en la misma.

El plan de producción describe el proceso a través de ta-reas o actividades que se realizan para obtener un producto final de la spl. Dicho proceso emplea la notación del estándar spem (figura 78). El plan de producción es seguido a través de bom que interacciona con el usuario (ingeniero de la aplicación) de forma que solamente introduce en dos ocasiones los datos co-rrespondientes al dominio específico. Estos datos son los puntos de variabilidad (características de la primera variabilidad) y las características del dominio de la aplicación (características de la segunda variabilidad).

En la misma figura (81) se muestran las ocho tareas invo-lucradas en el plan de producción, y todas éstas se llevan a cabo por bom a través de la interacción con el usuario que desempeña el rol de ingeniero de la aplicación.

205


Figura 81. Plan de producción que sigue la aproximación bom-eager (notación en spem)

Ob

tain

do

ma

infe

atu

res

Sele

ct

assetsB

AS

EL

INE

BA

SE

LIN

E

Un

packag

eK

it-B

ox

Ob

tain

ap

plicati

on

do

main

featu

res

MI

3

C 3

U 3

BC

3

Cre

ate

asp

ect

PR

ISM

A t

yp

es

Bu

ild

PR

ISM

Asp

ecif

icati

on

MI

3

C 3

U 3

BC

3

Co

mp

ile

arc

hit

ectu

ral

mo

del

Cre

ate

execu

tab

lesyste

m

DC

M

AD

CM

A-P

SK

EL

ET

ON

S

MA

IN F

EA

TU

RE

INS

ER

TIO

N P

RO

CE

SS

I, A

.E. P

RIS

MA

TY

PE

S

AR

CH

ITE

CT

UR

AL

MO

DE

L T

YP

E

AR

CH

ITE

CT

UR

AL

MO

DE

L C

ON

FIG

KIT

-BO

X

AS

PE

CT

P

RIS

MA

TY

PE

S

PR

ISM

A T

YP

ES

CO

MP

ILE

D A

RC

HIT

EC

TU

RA

L.M

OD

EL

EX

EC

UT

AB

LE

S

YS

TE

M

DO

MA

IN F

EA

TU

RE

S

AP

PL

ICA

TIO

N

DO

MA

IN F

EA

TU

RE

S

AS

SE

T S

EL

EC

TIN

G

PR

OC

ES

S

BA

SE

LIN

E

<<

in>

><

<in

>>

<<

in>

>

<<

in>

>

<<

in>

>

<<

in>

>

<<

in>

>

<<

in>

>

<<

in>

>

<<

in>

>

<<

in>

>

<<

ou

t>>

<<

ou

t>>

<<

ou

t>>

<<

ou

t>>

<<

ou

t>>

<<

ou

t>>

<<

ou

t>>

<<

ou

t>>

<<

in>

>

<<

in>

><

<in

>>

<<

ou

t>>

12

3

4

56

78

<<

in>

>


206


A continuación se describen y se modelan en spem cada una de las tareas mencionadas (se enfatiza la tarea donde es uti-lizada la Baseline). Estas tareas son realizadas en tres partes: la ca-racterización del producto, la síntesis del producto y la construc-ción del producto.

◊ Caracterización del productoAquí se eligen las características que diferencian un producto se-leccionado. Al respecto debe señalarse que el proceso caracteri-zación del producto tiene como punto de partida un modelo con-ceptual de diagnóstico (es decir, dominio del diagnóstico) y un modelo conceptual del dominio específico (es decir, dominio de la aplicación). Inicialmente se aplica una secuencia de trans-formaciones automáticas de dichos modelos a una arquitectura prisma para la spl. La transformación automática entre los mo-delos es esencialmente una transformación dirigida por la selec-ción de características efectuada por el ingeniero de aplicación, quien configurará un modelo conceptual de características del diagnóstico y un modelo conceptual del dominio, que a su vez (por las relaciones de trazabilidad) generarán el modelo arqui-tectónico de la aplicación. En función de los requisitos particu-lares que presente la aplicación se seleccionan las variantes, las cuales deben ser tomadas en cuenta por el ingeniero de la apli-cación.

Este proceso involucra tres tareas ejecutadas a través del rol del ingeniero de aplicación: crear la configuración de las ca-racterísticas del dominio, seleccionar los assets, configurar carac-terísticas del dominio de aplicación y crear los tipos.

• Tarea 1. Obtener las características del dominio. bom obtiene (del ingeniero de la aplicación al usar las check boxes y pull-down menus) las características del dominio expresadas en el modelo conceptual del dominio, y que son consideradas como puntos de variabilidad de la primera variabilidad (véase la fi-gura 82).

207


Figura 82. Proceso para obtener las características del dominio (notación en spem)

Obtain domainfeatures

DCMDOMAIN FEATURES

<<in>> <<out>>

DOMAIN FEATURES


• Tarea 2. Seleccionar los assets (Kit-Boxes). Con los puntos de variabilidad seleccionados por el ingeniero, bom recupera de la Baseline la kit-box correspondiente. En esta actividad, mostra-da en la figura 83, son consumidos desde el inicio los siguien-tes artefactos software: proceso de selección de assets (éste es aplicado por bom para seleccionar los assets correspondientes al dominio de aplicación), características del dominio (es decir, la información dada por el ingeniero de aplicación sobre las ca-racterísticas del dominio de aplicación a través de una instan-cia del mcd), y la Baseline (ésta contiene los kit-box assets co-rrespondientes a un dominio específico). En el proceso de sali-da son producidos los artefactos software seleccionados con el fin de obtener un producto de la spl, es decir, la caja que co-rresponde al dominio específico.

208


Figura 83. Proceso para seleccionar un asset (notación en spem)

Select assets

BASELINEBASELINE

KIT-BOX

DOMAIN FEATURES

ASSET SELECTING PROCESS

BASELINE

<<in>> <<out>>

<<in>><<in>>


• Tarea 3. Desempaquetar la caja. La caja que fue seleccionada por el ingeniero, a través de bom, debe desempaquetarse para poder utilizar cada uno de los assets de su contenido en forma individual (véase la figura 84).

Figura 84. Proceso para desempaquetar una caja (notación en spem)

Unpackage Kit-Box

MI 3

C 3U 3

BC 3

ADCM

A-P SKELETONS


I, A.E. PRISMA TYPES

ARCHITECTURAL MODEL TYPE

<<in>> <<out>>

KIT-BOX

ARCHITECTURAL MODEL CONFIG


209


• Tarea 4. Obtener características del dominio de aplicación. bom obtiene (del ingeniero de aplicación) las características del do-minio de la aplicación consideradas como características de la segunda variabilidad (véase la figura 85).

Figura 85. Proceso para obtener las características del dominio de la aplicación (notación en spem)

Obtain applicationdomain features

ADCM

APPLICATION DOMAIN FEATURES

<<in>> <<out>>


• Tarea 5. Crear los aspectos tipo prisma. bom rellena los esque-letos (aspectos) con los datos de las características del dominio de aplicación —respecto al caso de estudio— las cuales fueron definidas por el ingeniero de la aplicación y, de esta manera, crea los aspectos tipo prisma (véase la figura 86).

210


Figura 86. Proceso para obtener los aspectos tipo prisma(notación en spem)

Create aspectPRISMA typesA-P SKELETONS


ASPECT PRISMA TYPES

APPLICATION DOMAIN FEATURES

<<in>>

<<in>><<out>>

<<in>>

INI


◊ Síntesis del productoUn producto está compuesto por activos. La síntesis del produc-to reúne los activos para obtener la materia prima. En este pro-ceso se ejecuta la tarea construir especificación prisma a través del rol que desempeña el ingeniero de la aplicación.

• Tarea 6. Construir especificación prisma. bom toma los aspec-tos tipo prisma y los aglutina con otros assets desempaqueta-dos en la tarea 3: los artefactos tipo prisma (interfaces, elemen-tos arquitectónicos, modelo arquitectónico), y la configuración del modelo arquitectónico, con el fin de reunir a todos los as-sets necesarios para construir la especificación del modelo ar-quitectónico prisma (véase la figura 87), los cuales serán utili-zados en la siguiente tarea.

211


Figura 87. Proceso para construir la especificación prisma (notación en spem)

MI 3

C 3U 3

BC 3

Build SpecificationPRISMA

MI 3

C 3U 3

BC 3

I, A.E. PRISMA TYPES

ARCHITECTURAL MODEL TYPE

ARCHITECTURAL MODEL CONFIGURATION

ASPECT PRISMA TYPES

PRISMA TYPES

<<in>><<in>>

<<in>>

<<out>><<in>> Build PRISMAspecification

PRISMA SPECIFICATION


Al respecto se señala que, esta tarea, con la herramien-ta prisma-case (Cabedo, Pérez, Carsí y Ramos, 2005; Pérez, Ali, Costa, et. al., 2005a), los assets (artefactos software tipo prisma y la configuración del modelo arquitectónico) pueden ser crea-dos al modelar el sistema a través de una metáfora visual; es de-cir, es equivalente la obtención de los assets, a través de bom, a la generación de dichos assets mediante el modelado de la arquitec-tura del sistema con prisma-case.

La figura 88 muestra el modelo que presenta el sistema del diagnóstico de programas educativos. Como puede obser-varse en dicha figura, con la aproximación bom es más sencillo especificar un modelo arquitectónico y se obtienen los mismos resultados (assets en el adl de prisma).

212


Figura 88. Metáfora visual que representa el sistema del diagnóstico de programas educativos (realizada con la herramienta prisma-case)


213


◊ Construcción del productoEn la construcción del producto se procesa la materia prima me-diante el proceso de construcción (compilar, generar código) para obtener el producto final.

Las tareas que se realizan en esta etapa, a través del rol que desempeña el ingeniero de la aplicación, son compi-lar el modelo y crear el sistema ejecutable. El entorno destino de bom es el framework prisma; por ello, las tareas compilar mode-lo y crear sistema ejecutable son realizadas sobre las herramientas prisma-model-compiler (Cabedo et al., 2005) y el middleware prisma-net (Costa, Pérez, Ali, et al., 2005; Pérez et al., 2005ª), respectivamente, como se comenta a continuación.

• Tarea 7. Compilar el modelo arquitectónico. Los artefactos tipo prisma, y la configuración del modelo arquitectónico, son in-corporados por medio de bom a la herramienta prisma-mo-del-compiler para compilar el modelo arquitectónico y gene-rar automáticamente el código (en c#,. net). Véase la siguien-te figura (89).

Figura 89. Proceso para compilar el modelo arquitectónico prisma (notación en spem)

MI 3

C 3U 3

BC 3

PRISMA TYPES

Compile architectural model

COMPILEDARCHITECTURAL.MODEL

<<in>> <<out>>

AND ARCHITECTURAL MODEL CONFIGURATION


214


• Tarea 8. Crear el sistema ejecutable. bom, a través del midd-leware prisma-net obtiene, del modelo arquitectónico com-pilado, el sistema final como una aplicación ejecutable, es de-cir, una instancia de la spl que el ingeniero de la aplicación se encuentre realizando. Véase la figura 90.

Figura 90. Proceso para crear el sistema ejecutable (notación en spem)

Create executablesystem

COMPILEDARCHITECTURAL MODEL

EXECUTABLE SYSTEM

<<in>> <<out>>


Plan de producción de la la línea de productos software en la aproximación bom-lazyEn la aproximación bom-lazy, la Baseline se calcula en la fase ingeniería de la aplicación, es decir, la Baseline es implícita. El plan de producción describe el proceso a través de seis tareas o actividades que se realizan para obtener un producto final de la spl. Este proceso (figura 91) se realiza mediante la notación del estándar spem.

El plan de producción es seguido a través de bom el cual interacciona con el usuario, quien desempeña el rol de ingenie-ro de la aplicación, de forma que solamente introduce en dos ocasiones los datos correspondientes al dominio específico. Es-tos datos son los puntos de variabilidad (características de la pri-mera variabilidad) y las características del dominio de aplicación (características de la segunda variabilidad).

215


Figura 91. Plan de producción que sigue la aproximación bom-lay (notación en spem)

Ob

tain

do

ma

infe

atu

res

Bu

ildsk

elet

on

Ob

tain

app

licat

ion

do

mai

nfe

atu

res

Bu

ildP

RIS

MA

mo

del

MI

3

C 3

U 3

BC

3

Co

mp

ile

arch

itec

tura

lmo

del

Cre

ate

exec

uta

ble

syst

em

DC

M

AD

CM

AR

CH

ITE

CT

UR

AL

MO

DE

L

BA

SE

AR

CH

ITE

CT

UR

E(S

KE

LE

TO

N)

CO

MP

ILE

D A

RC

HIT

EC

TU

RA

LM

OD

EL

EX

EC

UT

AB

LE

S

YS

TE

M

DO

MA

IN F

EA

TU

RE

S

AP

PL

ICA

TIO

N

DO

MA

IN F

EA

TU

RE

S

QV

T T

RA

NS

FO

RM

AT

ION

S

<<

in>

><

<in

>>

<<

in>

>

<<

in>

><

<in

>>

<<

in>

>

<<

ou

t>>

<<

ou

t>>

<<

ou

t>>

<<

ou

t>>

<<

ou

t>>

<<

ou

t>>

<<

in>

>

<<

in>

>

12

34

56


216


Ejecución del sistema (producto final) Con el propósito de clarificar la ejecución del sistema experto (producto final) por el usuario final, se utiliza la notación en spem. Cuando se realiza la tarea ejecutar sistema, se consumen el sistema ejecutable correspondiente al modelo del sistema diag-nóstico relacionado con el caso específico (o sea, el producto fi-nal de la spl), y los valores de las propiedades que presente la en-tidad a diagnosticar (introducidos a través de la igu); producién-dose como salida el resultado del diagnóstico de dicha entidad (en la igu). Véase la siguiente figura (92).

Figura 92. Ejecución de un sistema de la spl (notación en spem)

Final User

<<out>>

<<in>>

Entity property values

Result(Diagnosis)

Executable System(EXE)

<<in>>Execute System


Conclusiones Cualquiera de las dos aproximaciones de bom (es decir, bom-ea-ger o bom-lazy) muestra que dicha aproximación es una solu-ción genérica aplicable a otros dominios y a diferentes tipos de sistemas software, ya que se mantiene el mismo plan de produc-ción de la spl. Además, en la ingeniería del dominio pueden ser creados los mismos assets pero con características ad hoc al domi-nio, o bien construir otros assets que se correspondan con el do-minio en el que se desarrolla la spl.

Parte IV Conclusiones

Ilustr

ació

n de

Víct

or O

dín

Gar

cía R

odríg

uez.

219

Conclusiones generales

La ciencia avanza a pasos, no a saltos.Thomas Macaulay

Las tendencias actuales de la ingeniería de software están en-focadas en las aproximaciones para el desarrollo de sistemas

software basados en la separación de la especificación del sistema de su implementación. Con ello, se persigue elevar el nivel de abs-tracción dándole una mayor importancia al modelado conceptual y al papel de los modelos en el desarrollo de software, al contrario que en el enfoque tradicional que está más centrado en la imple-mentación en plataformas específicas. En dichas aproximaciones, los modelos son fácilmente especificados y su mantenimiento es más sencillo, sirviendo de guía para el desarrollo del sistema, cuya descripción es independiente de la tecnología utilizada, protegien-do la inversión frente a cambios y evoluciones en la tecnología. Además, dichas tendencias promueven la automatización de todo el proceso de desarrollo, objetivo del paradigma de la Ingeniería Dirigida por Modelos (mde).

En este contexto, en el presente libro se define la aproxi-mación mda denominada Baseline-Oriented Modeling (bom) co-mo un framework que genera automáticamente aplicaciones en un dominio específico con arquitecturas prisma, mediante téc-nicas de Líneas de Productos Software (spl). Para ilustrar bom,

220


se eligió el dominio de los Sistemas Expertos de Diagnóstico (des), dada la importancia que han cobrado en los últimos tiem-pos las tareas de diagnóstico y el desarrollo de este tipo de siste-mas como apoyo a la toma de decisiones.

Conforme a un análisis de campo realizado, se concluyó que es compleja esta clase de sistemas, debido a que varían tan-to en su comportamiento como en su estructura. Esta situación produce diversas arquitecturas base en la spl, las cuales compar-ten una sola arquitectura genérica. Además, existe otra variabi-lidad que decora diferentemente a las arquitecturas base con las características que presenta el dominio de aplicación.

En consecuencia, en bom se realizó un tratamiento de la variabilidad en dos niveles asociados a dos tipos de spl. La pri-mera variabilidad implica a la spl1, formada por todas las arqui-tecturas base que comparten la arquitectura genérica de los des. La segunda variabilidad implica a la spl2 en un dominio de apli-cación específico, formada por todas las arquitecturas prisma que comparten las arquitecturas base, es decir, las arquitecturas de los productos finales de la spl.

En este contexto, mediante técnicas ad hoc utilizadas en bom, fueron gestionadas dichas variabilidades (bom captura las variabilidades del dominio y del dominio de la aplicación en ins-tancias de dos modelos conceptuales separados). Las técnicas de árbol de decisión y de fom, o bien, las técnicas de transforma-ción de modelos, explotan dicha información con el fin de obte-ner una aplicación específica por medio de técnicas de spl en el contexto de la mda. Los modelos finales son compilados y es ge-nerado el código objeto, obteniéndose de esta forma una aplica-ción ejecutable. Asimismo, se modeló la spl en dos fases: la in-geniería del dominio (donde se construyen todos los assets y el conocimiento de cómo se construye un producto, depositados en la Baseline) y la ingeniería de la aplicación (donde se realiza el plan de producción de la spl).

221

Conclusiones

Sin embargo, el tamaño de la Baseline determina la con-veniencia de utilizar dos aproximaciones diferentes, por lo que, si la Baseline es pequeña entonces es conveniente utilizar la apro-ximación bom-eager, la cual utiliza técnicas de árbol de deci-sión para seleccionar de la Baseline los assets, y las técnicas de fom para decorar los esqueletos. En cambio, si la Baseline es grande es mejor utilizar la aproximación bom-lazy, ya que és-ta emplea técnicas de transformación de modelos para construir los productos de la spl.

Además, el framework bom permite ampliar la Baseline. Por el hecho de haber establecido la aproximación reactiva so-bre el uso de las spl, se podrá extender el análisis del campo a otros dominios de aplicación con el fin de incrementar la varia-bilidad —y por lo tanto la Baseline—. De esta manera, la spl po-drá ofrecer más productos. Adicionalmente, puede utilizarse el framework bom en otros tipos diferentes de sistemas como, por ejemplo, las arquitecturas Pipeline (es decir, los compiladores), o bien las arquitecturas software orientadas a servicios, así como contemplar una spl de actualidad, por ejemplo, el software em-potrado y la domótica, entre otros.

De esta manera, se concluye que las características de bom son las siguientes:

• bom integra varios espacios tecnológicos para cubrir la com-plejidad del problema (éstas son las tendencias actuales de la ingeniería de software).

• La variabilidad es manejada a nivel de modelos (no a nivel de programas).

• La variabilidad de los sistemas es modelada al utilizar modelos de la variabilidad, independientes de sus modelos funcionales. Los dsl para expresar la variabilidad son adecuados al dominio, en lugar de agregarlos a los modelos funcionales (uml, adl).

• La variabilidad es manejada por dos tipos ortogonales de la misma: una dada por las características del dominio (diagnós-tico), y otra por las características del dominio de la aplicación.

222


• bom implementa una aproximación genérica para el desarrollo de la spl; esta aproximación puede aplicarse en diferentes do-minios, dominios de aplicación, tipos de sistemas software y plataformas destino (psm), ya que se mantiene el mismo plan de producción de la spl. Sin embargo, en la fase de la inge-niería del dominio deberán ser creados los mismos assets, pero con las particularidades ad hoc al caso. Asimismo, algunos ar-tefactos software pueden ser reutilizados o bien modificados para dominios que comparten algunas características comunes. Asimismo, se concluye que bom podrá ser una solución

genérica aplicable a diversos tipos de sistemas software, si se sa-tisfacen las siguientes condiciones:

• Si en el dominio existe una arquitectura genérica que pueda captarse a través de un modelo modular.

• Si dicha arquitectura contiene variantes expresadas como pun-tos de variabilidad.

• Si puede construirse una Baseline que almacene activos y el sa-ber hacer.

• Si la obtención de un producto puede realizarse por selección de características plasmadas en un modelo de características.

• Si las arquitectura base pueden especificarse formalmente, es decir, con una semántica y una sintaxis formales.Por otro lado, existen algunos trabajos relacionados con

el desarrollo de bom, sobre la cual hay un gran número de acer-camientos. Las metodologías y aplicaciones en esta temática han producido una amplia variedad de investigaciones, lo que ofre-ce sugerencias y soluciones en dominios específicos. En concre-to, este trabajo tiene como puntos de partida los que se exponen a continuación:

• La definición de modelos a un alto nivel de abstracción, de acuerdo con la mda, los modelos independientes de la tecno-logía (pim), cuyas instancias soportarán la información del do-minio, tanto de su funcionalidad como de su variabilidad. En el presente libro se consideró esta línea con un enfoque hacia los sistemas expertos basados en líneas de productos.

223

Conclusiones

• Las investigaciones realizadas por Liao (2005), quien:• Examinó las metodologías de los sistemas expertos y clasificó a

éstos en once categorías. Dos de éstas corresponden a los siste-mas basados en reglas y los sistemas basados en el conocimien-to, los cuales se consideraron en este libro al utilizar el conoci-miento representado en forma de reglas (cláusulas de Horn) y hechos (variables observables, es decir, propiedades de las en-tidades a diagnosticar).

• Expresó que las aplicaciones de los sistemas expertos se desa-rrollan como sistemas orientados a un problema en un domi-nio específico. Este libro se enfocó en el dominio del diagnós-tico. Sin embargo, en bom pueden contemplarse otros tipos de tareas que desempeñen los sistemas expertos (por ejemplo, la de interpretación y la de predicción). Con dichos dominios puede aplicarse bom si se realiza un nuevo proceso de desarro-llo de la spl en la fase de la ingeniería del dominio, y aplicar el mismo plan de producción realizado en este libro en la fase de la ingeniería de la aplicación.

• Señaló que el desarrollo de los sistemas expertos se caracteri-za por separar el conocimiento de los procesos como unidades independientes. En el modelo arquitectónico presentado en este libro, los elementos arquitectónicos se definieron al tener en cuenta este concepto, específicamente cuando se consideró un componente que contiene el conocimiento del dominio de aplicación y otro distinto que ejecuta los procesos de inferen-cia para llevar a cabo el diagnóstico.

• Las investigaciones realizadas por Giarratano y Riley (2004), y otros autores, consideran que las arquitecturas de los se están basadas en componentes. En este libro, la arquitectura genéri-ca de la spl (esto es, la arquitectura genérica de los sistemas ex-pertos) está conformada por módulos que se corresponden con los componentes mencionados por Giarratano.

• La implementación de los sistemas expertos que ha sido reali-zada en diferentes paradigmas de programación, tales como la estructurada, la lógica y la orientada a objetos. Estos paradig-mas están orientados a lenguajes de cuarta generación y méto-

224


dos de programación visual para dar una comunicación ami-gable con el usuario. En este libro se usa el lenguaje de des-cripción de arquitecturas de prisma para definir los modelos arquitectónicos.

• La detección de componentes basada en la descomposición fun-cional del problema, es decir, del sistema, compatible con la metodología Architecture Based Design Method (Bachmann, Bass, Chastek, et. al, 2000), propuesta por The Software En-gineering Institute of The Carnegie Mellon University para di-señar arquitecturas software de un dominio de aplicación. Esta metodología se aplicó para la construcción del modelo arqui-tectónico de los sistemas expertos.

• El trabajo realizado por Garlan (2001) como punto de referen-cia para establecer los elementos de un sistema software com-plejo, en el cual se introducen conceptos como componente, conector, sistema, puertos de entrada y de salida. Dichos con-ceptos se contemplaron en el modelo propuesto.

• El concepto contrato de Andrade y Fiadeiro (1999), ya que se han definido los conectores de los modelos arquitectónicos pertenecientes a la spl como una extensión de dicho concep-to, donde se incorpora la coreografía en los conectores, espe-cificada como el protocolo del aspecto de coordinación de di-chos elementos arquitectónicos.

• La integración de las aproximaciones que combinan el Desa-rrollo de Software Basado en Componentes y el Desarrollo de Software Orientado a Aspectos, introducida por Constantini-des y Errad (2000). Esta integración se contempla en el modelo prisma (Pérez, 2006). Los aspectos y requisitos descritos en el prisma son considerados en la arquitectura de la spl presenta-da en este libro. Asimismo, Giarratano et al. (2004), así como otros autores en el campo de los sistemas expertos, consideran que las arquitecturas de esos sistemas están basadas solamente en componentes. En este trabajo se integran las aproximacio-nes que combinan componentes (cbsd) con aspectos (aosd), con lo cual se obtienen las ventajas de cada una de ellas y, de

225

Conclusiones

esta forma, se incrementan la reusabilidad y el mantenimien-to de los sistemas expertos.

• Las líneas de producto software, que incorporan técnicas y me-todologías relacionadas con este libro. Entre éstos se encuen-tran los trabajos de los siguientes autores:

• Batory, Benavides y Ruiz-Cortés (2006), por un lado, y Czar-neki et al. (2005b), por otro, expresan las características del do-minio en un Modelo de Características. En bom se representa-ron las características del diagnóstico en un modelo de carac-terísticas, mismas que son plasmadas en un árbol de decisión y capturadas en un modelo conceptual.

• Trujillo (2007) ha utilizado el Feature Oriented Programming (fop) como técnica para insertar características en documen-tos xml a través de xslt. En bom se utilizó dicha técnica para insertar las características del dominio de aplicación por me-dio de plantillas xslt en los aspectos (esqueletos) prisma de los componentes del sistema experto, representados como do-cumentos xml. Además, se incorporó Feature-Oriented Pro-gramming, pero a nivel de modelos, de forma que ha sido de-finido y usado como técnica la Feature-Oriented Modeling en la aproximación bom-eager.

• González-Baixauli y Laguna (2005) aplican la propuesta de la mda y la Ingeniería de Requisitos para Líneas de Productos. En bom se utilizaron técnicas de mda para producir aplicacio-nes, así como contemplar los requisitos del usuario final para construir los elementos arquitectónicos de la spl (los activos reutilizables).

• Clements y Northrop (2001) usan la aproximación de desarro-llo de las spl al establecer una división entre la ingeniería del dominio y la ingeniería de la aplicación, para la reutilización y la automatización de los procesos software. Asimismo, el mé-todo Kobra divide la ingeniería del dominio (para desarrollar la familia de productos, incluyendo identificación de compo-nentes comunes y variables) de la ingeniería de la aplicación (para la derivación de un producto específico dentro de la fa-milia). Esta aproximación se utiliza en bom para desarrollar

226


su spl en las fases de ingeniería del dominio e ingeniería de la aplicación, respectivamente.

• Ávila-García, García, Rebull, y García (2006) desarrollaron un editor de modelos ras (como un plugin de Eclipse) para el em-paquetamiento de los activos reutilizables y su manipulación, así como el uso del estándar spem para procesos de modelado, ofreciendo facilidades de creación y manipulación de spl. En el presente trabajo se integraron estos dos estándares de la omg para la manipulación y creación de la Baseline, incluyendo en ésta el plan de producción de la spl. Se ha utilizado el están-dar spem para modelar todo el proceso relativo al desarrollo de la spl, y el estándar ras para empaquetar todos los activos has-ta conformar la Baseline.

• Santos (2007) desarrolló una técnica basada en la mda para gestionar la variabilidad en las spl, según el dominio específi-co. En el presente trabajo se utiliza dicha técnica mediante dos modelos conceptuales (Modelo Conceptual de Dominio [mcd] y Modelo Conceptual del Dominio de la Aplicación [mcda]), los cuales generan el software necesario para capturar las carac-terísticas del dominio y del dominio de aplicación como ins-tancias de dichos modelos, respectivamente.

• Bachmann, Goedicke, Leite, et al. (2003) propusieron la sepa-ración de la descripción sobre la variabilidad y la funcionalidad de los artefactos afectados. En bom la especificación de la va-riabilidad y de la funcionalidad se captan en modelos separa-dos. Además, a través de instancias que proporcionan los dos modelos conceptuales, mcd y mcda, se capta la variabilidad en dos etapas; la primera al definir la información de las caracte-rísticas que presenta el dominio, las cuales se usan para selec-cionar los assets adecuados de la Baseline, y la segunda al defi-nir las características que muestra el dominio de la aplicación para configurar la aplicación final, respectivamente.

• Gomma y Shin (2007) utilizan un modelo de variabilidad se-mi-ortogonal donde la variabilidad se representa en una vista separada, pero los puntos de variabilidad y las variantes apare-cen estereotipadas en diagramas uml. En bom las vistas de la

227

Conclusiones

variabilidad y de la funcionalidad son tratadas separadamente, pero, a diferencia de Gomma y Shin, las variantes están incor-poradas en los modelos de variabilidad específicos.

• Bosch (2000) describe tres dimensiones en las que se pueden descomponer los conceptos involucrados en las spl. De esas tres, la que se corresponde con este libro es la primera dimensión, que considera un sistema como un conjunto de assets forma-do por los sistemas construidos sobre la base de la arquitectura y los componentes de la spl. Esta actividad requiere la adap-tación de la arquitectura de la línea de productos para ajustar-se a la arquitectura de sistema, lo cual puede requerir eliminar o añadir componentes, o relaciones entre ellos, desarrollar ex-tensiones en los componentes existentes, configurarlos y desa-rrollar elementos software específicos para el sistema. En bom se parte de una arquitectura genérica que comparten las arqui-tecturas base, mismas que serán enriquecidas con las caracte-rísticas del dominio de aplicación para obtener las arquitectu-ras prisma como productos finales.

• Clements y Krueger (2002b) diferenciaron tres modelos de crea-ción de las spl: el proactivo, el extractivo y el reactivo. bom se inclina por el modelo reactivo, en el cual no se establece des-de un principio el dominio en extenso de la línea de produc-tos, sino que se incluyen nuevos productos a medida que apa-rece la necesidad de producirlos. La creación de activos es, por tanto, más incremental y progresiva que con los otros mode-los de adopción.

• Nakagawa, Martins, Felizardo, y Maldonado (2009), Naka-gawa, Ferrari, Sasaki, y Maldonado (2011), Nakagawa y Oli-veira (2011b), Nakagawa, Antonino y Becker (2011c) propu-sieron un proceso para establecer arquitecturas de referencia orientadas a aspectos, el cual se aplica para construir una ar-quitectura de referencia sobre un dominio específico. En bom se propone un proceso genérico para diseñar y generar arqui-tecturas de spl a partir de una arquitectura de referencia per-teneciente al dominio que se denomina como la arquitectura genérica. También se define un proceso e implementa un fra-

228


mework para relacionar la arquitectura de referencia con las ar-quitecturas (mediante componentes-conectores y aspectos) de la línea de productos en un dominio específico, es decir, los des.

• Chen et al. (2009) mencionan que, a través de una revisión sistemática de las spl, existe un gran número de propuestas para la gestión y representación de la variabilidad. Particular-mente muchas de ellas están basadas en la notación original de FODA [Kang et al., 1998a], proponiendo varias extensiones a ella. Nuestro trabajo está estrechamente relacionado con su in-vestigación en el modelado de las características.De acuerdo con lo anterior, las principales contribuciones

contempladas en bom, son las siguientes:En la mda:

• Proponer una aproximación dirigida por modelos, la cual se orienta a la variabilidad para el desarrollo de sistemas software.

En la Línea de Productos Software:• Ofrecer un marco conceptual para identificar y definir la varia-

bilidad en la fase de la ingeniería del dominio, y para gestionar e implementar la variabilidad en la ingeniería de la aplicación.

• Manejar la variabilidad a través de dos tipos ortogonales de va-riabilidad: la del dominio y la del dominio de aplicación.

• Presentar un plan de producción genérico para diversos tipos de sistemas software.

• Implementar una herramienta case (prototipo) para desarrollar aplicaciones de una spl durante todo su ciclo de vida.

• Implementar la gestión de la variabilidad mediante las qvt-Re-lations como técnica de transformación de modelos.

En las herramientas prisma:• Incorporar directamente al compilador de modelos (prisma-

model-compiler) el modelo arquitectónico (especificado en el adl de prisma sobre documentos xml) para generar el códi-go que será ejecutado sobre el Middleware prisma-net.

En los Sistemas Expertos:• Generar un des, de manera sencilla, con sólo introducir la in-

formación de la variabilidad, al utilizar lenguajes específicos de dominios.

229

Conclusiones

• Ofrecer una spl para sistemas expertos de diagnóstico (des), al reducir complejidad, costos, tiempo y esfuerzos.

• Mejorar el desarrollo de los sistemas expertos: » Al usar las ventajas de los sistemas expertos, separando los

procesos de inferencia de la información del conocimiento de un dominio específico, contemplando diversas estrate-gias de razonamiento para resolver un problema, aplican-do la manera más eficiente.

» Al construir sistemas de una manera simple con ontolo-gías del diagnóstico y de los dominios de aplicación. De esta manera se ofrece un acercamiento al lenguaje específi-co del dominio sobre un problema, lo que facilita la inte-racción con el usuario.

» Al aplicar las técnicas de spl y construir con éstas un diseño que compartan todos los miembros de una familia de pro-gramas. De esta manera, un diseño específico puede usarse en diferentes productos, lo cual reduce los costos, los tiem-pos de producción, el esfuerzo y la complejidad.

» Al construir las arquitecturas de la línea de productos en el marco de prisma e integrar componentes y aspectos reu-tilizables, lo que facilita su mantenimiento y complejidad.

» Al aplicar técnicas de la mda para implementar los sistemas sobre diferentes plataformas y transformarlos para obtener una aplicación ejecutable.

» Al desarrollar sistemas independientes de plataforma, abor-dados desde la perspectiva del problema y no de la solu-ción, lo cual provee generalidad en la aproximación desa-rrollada y aplicabilidad en diferentes dominios.

» Al ofrecer una funcionalidad conjunta y coordinada de to-dos los espacios tecnológicos contemplados en bom.

Finalmente, se considera que el uso del framework bom conlleva las siguientes ventajas:

• Generalidad. bom es una aproximación genérica que puede utilizarse para desarrollar diversos tipos de sistemas en dife-rentes dominios.

230


• Abstracción. La semántica de bom contempla altos niveles de abstracción debido a que utiliza modelos.

• Amigabilidad. El uso de bom, por quien desarrolla las aplica-ciones, es muy sencilla, ya que solamente debe ingresar en bom los datos que contienen la variabilidad del dominio y del do-minio de la aplicación, obteniendo una aplicación ejecutable.

• Automatización. Con bom se obtiene una aplicación ejecuta-ble de forma automática.

• Estandarización. bom se basa en diversos estándares propor-cionados por la omg.En cuanto a la implementación, actualmente se está de-

sarrollando una herramienta (bom tool) que incorpora la obten-ción de las características presentes en la primera y la segunda variabilidad a través de modelos al uso compilables, con lo cual el proceso que se sigue en el plan de producción se realizaría au-tomáticamente. Dicha herramienta integrará las aproximaciones bom-eager y bom-lazy, donde el ingeniero de la aplicación po-drá elegir, desde el inicio, cuál de las dos aproximaciones utiliza-rá. Al respecto es importante recalcar que la evaluación de “bom tool” deberá realizarse sobre el proceso de producción, no sobre los productos finales de la spl, dado que ello depende de la ca-lidad de los assets. Por ejemplo, la calidad de un des dependerá, entre otros aspectos, de la eficiencia que presente su motor de in-ferencia y de una amplia base de conocimientos.

BibliografíaIlu

strac

ión

de V

íctor

Odí

n G

arcía

Rod

rígue

z.

233

Bibliografía

Ali, N.; Ramos, I., y Carsí, J. (2005). Conceptual Model for Distributed As-pect-Oriented Software Architectures. International Conference on Infor-mation Technology Coding and Computing, itcc 2005, ieee Computer Society, Las Vegas, NV, USA, March 2005.

ample (2007). Specific Targeted Research Project: ist-33710. Project start date: 1 October 2006, duration: 3 years. Disponible en http://www.ample-project.net

Andrade, L., y Fiadeiro, J. (1999). Interconnecting Objects via Contracts. oopsla´99.aosd (2001). Disponible en http://aosd.net. http://portal.acm.org/browse_

dl.cfm?linked=1&part=magazine&idx=J79&coll=ACM&dl=ACM (Oc-tober 2001 issue of Communications of the ACM)

Arango, G., y Prieto-Díaz, R. (1991). Domain Analysis Concepts and Research Direc-tions. En: R. Prieto-Díaz y G. Arango (eds.), Domain Analysis and Software Systems Modeling. Páginas 9-32. ieee Computer Society Press.

Ávila-García, O.; García, A. E.; Rebull, V. S., y García J. L. (2006). Integrando modelos de procesos y activos reutilizables en una herramienta MDA. xi Jor-nadas de Ingeniería de Software y Bases de Datos jisbd’2006, Barcelona, España, octubre de 2006, pp. 483-488.

Atkinson, C.; Bayer, J., y Muthig, D. (2000). Component-based product line de-velopment: the KobrA Approach. En P., Donohoe (ed.), Proceedings of the 1st Software Product Line Conference (splc), The International Series in Engineering and Computer Science 576, pp. 289-310, Denver (Colo-rado, USA), August 2000.

Bachmann, F.; Bass, L.; Chastek, G., et al. (2000). The Architecture Based Design Method. Technical Report cmu/sei-2000- tr-001. USA: Carnegie Mellon University.

Bachmann, F.; Goedicke, M.; Leite J., et al. (2003). A meta-model for representing variability in product family development. En: Proceedings in the 5th In-ternational Workshop on Product Family Engineering (pfe’5), pp. 66-80.

234


Bass, L.; Clements, P.; Cohen, S., et al. (1997). Product Line Practice Workshop Re-port. Technical Report cmu/sei-97-TR-003 (esc-tr-97-003), Software Engineering Institute. USA: Carnegie Mellon University, Pittsburgh, Pennsylvania 15213.

Bass, L.; Chastek, G.; Clements, P., et al. (1998). Second Product Line Practice Work-shop Report. Technical Report cmu/sei-98-tr-015 (esc-tr-98-015), Soft-ware Engineering Institute. USA: Carnegie Mellon University, Pittsburgh, Pennsylvania 15213.

Bass, L., y Kazman, R. (2003). Software Architecture in Practice. SEI Series in Soft-ware Engineering (2ª ed.). Addison-Wesley, p. 528.

Batory, D.; Sarvela, J.N., y Rauschmayer (2004). Scaling Stepwise Refinament. En: ieee Transactions on Software Engineering (tse), 30(6):3555-371.

Batory. D.; Benavides, D., y Ruiz-Cortés (2006). Automated Analyses of Feature Models: Challenges Ahead. cacm on Software Product Lines.

Batory, D. (2004, mayo). Feature-oriented programming and the ahead tool suite. En: Proceedings of the 26th International Conference on Software Engineer-ing, icse, pp. 702-703.

Bernstein, P.A.; Levy, A.Y., y Pottinger, R. (2000, junio). A Vision for Management of Complex Models. Microsoft Research Technical Report msr-tr-2000-53 (short version in SIGMOD Record 29, 4 (Dec. ‘00).

Bezevin, J. (2005). On the Unification Power of Models, Software and Systems Modeling, vol. 4(2), pp. 171-188, 2005.

Bonczek, R.; Holsapple, C., y Whinston, A. (1981). Foundations of Sistemas Exper-tos. New York: Academic Press.

Boronat, A.; Pérez, J.; Carsí, J., y Ramos, I. (2004). Two experiencies in software dynamics. En: Journal of Universal Science Computer. Special issue on Breakthroughs and Challenges in Software Engineering, Vol. 10, (issue 4).

Bosch, J. (2000a). Design & Use of Software Architectures: Adopting and Envolving a Product-Line Approach. Addison-Wesley.

Bosch, J. (2000b). “Product Line Architectures”, en ObjectiveView [en línea], (4):13-18. Disponible en http://www.ratio.co.uk

Bracciali, A.; Brogi, A., y Canal, C. (2002). Systematic Component Adaptation. En: Proceedings of IDEAS. La Habana, Cuba.

Brito, I., y Moreira, A. et al. (2003). Towards a Composition Process for Aspect-Ori-ented Requeriments. Early Aspects 2003: Aspect-Oriented Requeriments Engineering and Architecture Design, Workshop of The 2nd. Internation-al Conference on Aspect_Oriented Software Development, Boston, USA, March 2003.

Butler, G. (2003). Application Development Strategies. New Technologies and Methods for the Full Life Cicle.

Cabedo, R.; Pérez; J.; Carsí, J., y Ramos, I. (2005). Modelado y Generación de Ar-quitecturas prisma con dsl Tools, en Actas del IV Workshop DYNAMICA, Archena, Murcia, España, 2005.

235

Bibliografía

Cabello. M.; Gómez, M.; Llevador, M., y Ramos, I. (2008). Protobom: a framework that semi-automatically generates Expert Systems based on Software Prod-uct Lines. En: Technical report: dsic II/02/08, Universitat Politécnica de Valéncia, pages 68.

Carsí, J. A. (1999). OASIS como Marco Conceptual para la Evolución de Software. Tesis doctoral. Universidad Politécnica de Valencia, Valencia, España.

Chastek, G., y McGregor, J. (2002, junio). IGUdelines for Developing a Product Line Production Plan. Technical Report, cmu/sei. cmu/sei-2002-tr-06.

Chen, I.; Babar, M.A.; and Ali, N. (2019). Variability management in software pro-duct lines: A systematic review. 13 th. International Software Product Lines Conference, C.A. USA.

Clauss, M. (2001a). Modelling variability with UML. Young Researchers Work-shop, 3rd Int. En: Symposium on Generative and Component-Based Software Engineering (gcse), Erfurt (Germany).

Clauss, M. (2001b). Generic Modelling using UML extensions for variability. Work-shop on Domain-Specific Visual Languages (dsvl), 16 Int. Conf. on Ob-ject-Oriented Programming Systems, Languages and Applications (oops-la), 11-18, Tampa Bay , Florida, USA.

Clements, P.; Northrop, L.; Bachmann, F., et al. (1998). A Framework for Software Product Line Practice – Version 1.0. Product Line Systems Program. Software Engineering. USA: Institute, Carnegie Mellon University, Pittsburgh, Pennsylvania 15213.

Clements, P., y Northrop, L. (2001). Software Product Lines: Practices and Patterns. En: sei Series in Software Engineering, Addison Wesley.

Clements, P.; Bachmann, F.; Bass, L., et al. (2002a). Documenting Software Archi-tecture, Views and Beyond. USA: Addison Wesley, Reading, 560 páginas.

Clements, P., y Krueger, C. (2002b). Being proactive pays off/Eliminating the adoption barrier. En: ieee Software, pp. 28-31, julio-agosto, 2002.

Cohen, S.; Friedman, S.; Martin, L., et al. (1995). Product Line Identification for ESC-Hanscom. Special Report cmu/sei-95-SR-024, Software Engineer-ing Institute. USA: Carnegie Mellon University, Pittsburgh, Pennsylvania 15213.

Cohen, S., y Northrop, L. “Object-Oriented Technology and Domain Analysis”. En: Proceedings of the Fifth International Conference on Software Reuse, ICSR-5, 1998, páginas 86-93., Victoria, B.C., Canada. ieee-cs, 2-5.

conacyt (1997). Revista Ciencia y Desarrollo. Consejo Nacional de Ciencia y Tec-nología, México, Edición especial, 1987.

Constantinides, C., y Errad, T. (2000). On the Requeriments for Concurrent Software Architectures to Support Advanced Separation of Concerns. En: Proceedings of The oopsla 2000, Workshop on Advanced Separation of Concerns in Object-Oriented Systems.

Corpoica (2006). Librería virtual de sistemas expertos. Disponible en http://www.corpoica.org.co/Libreria/software.asp?id_categoria=clase&id_producto= 16&offsetr=1&index=1.

236


Costa, C.; Pérez, J.; Ali, N., et al. (2005). prismanetMiddelweare: Soporte de la Evo-lución Dinámica de Arquitecturas Software Orientadas a Aspectos. Actas de las X Jornadas de Ingeniería de Software y Bases de Datos (jisbd). Grana-da, España.

Czarnecki, K., y Eisenecker, U. (2000). Generative Programming: Methods, Tools, and Applications. USA: Addisson-Wesley, pp. 267-304.

Czarnecki, K., y Antkiewicz, M. (2005a). A Template Approach Based on Superim-posed Variants. En: 4th International Conference on Generative Program-ming and Component Engineering (gpce 2005), Tallinn, Estonia, septi-embre-octubre.

Czarnecki, K., y Kim, C.H.P. (2005b). Cardinality-based feature modeling and con-straints: A progress report. En:OOPSLA International Workshop on Soft-ware Factories, San Diego California, USA.

Deelstra, S.; Sinnema, M.; Van Gurp, J., y Bosch, J. (2003). Model Driven Archi-tecture as Approach to Manage Variability in Software Product Families. Pro-ceedings of the Workshop on Model Driven Architecture: Foundations and Applications (mdaaafa 2003), pp. 109-114, CTIT Technical Report TR-CTIT-03-27, University of Twente.

Deursen, A., y Klint, P. «Domain-specific language design requires feature descrip-tions». En: Journal of Computing and Information Technology, 10(1), pp. 1-17, junio-marzo, 2002.

Durzdel, M., y Flynn, R. “Decision Support Systems”. En: Encyclopedia of Library and Information Science, Vol. 67, Suppl. 30, 2000, pp. 120-133, Allen Kent (ed.), Marcel Dekker, Inc., New York.

Eclipse (2007). Disponible en http://www.eclipse.orgEeles, P. (2006). What is Software Architecture, IBM Developerworks. Disponi-

ble en http://www-128.ibm.com/developerworks/rational/library/feb06/eeles/

France, R., y Bieman, J. (2001). Multi-view Software Evolution: A UML based Framework for Evolving Object-Oriented Software. Actas del International Conference on Software Maintenance (icsm 2001). En: ieee Computer Society, pp. 386-39.

Fresnel, D.; Benjamins, R., y Motta, E. (1999). A Framework for Knowledge System Reuse. En: Proceeding of the International Joint Conference on AI (ij-cai-99), Stockholm, Sweden.

García, F.; Barras, J.; Laguna, M., y Marques, J. (2002). Líneas de Producto, Compo-nentes, Frameworks y Mecano. Informe Técnico dptoia-it-2002-04. Espa-ña: Universidad de Valladolid.

Garlan, D.; Cheng, S., y Kompanek, A. (2001). Reconciling the Needs of Architectur-al Description with Object Modeling Notations. En: Science of Computer Programming Journal, Special UML Edition, Elsevier Science.

Giarratano, J., y Riley, G. (2004). Expert Systems: Principles and Programming (4ª ed.) (Hardcover), pp. 842.

237

Bibliografía

Gomma, H.; Kerschberg, L.; Sugumaran, V., et al. “A Knowledge Based Software Engineering Environment for Reusable Software Requirements and Ar-chitectures”. En: Journal of Automated Software Engineering. Vol 3. Num-bers 3-4, 2006, páginas 285-307.

Gomma, H., y Shin, M. (2007, junio). Automated Software Product Line Engineer-ing and Product Derivation. En: Proceedings of the 40 th Hawaii Inter-national Conference on System Sciences-hicss, Waikoloa, Hawaii, USA.

Gomma, H. (2004). Designing Software Products Line with uml: From uses cases to pattern-based software architectures. The Addison-Wesley Object Thecnolo-gy Series. (Hardcover) 736 pages.

González-Baixauli, B., y Laguna, M. (2005). mda e Ingeniería de Requisitos para Líneas de Producto. Taller sobre Desarrollo Dirigido por Modelos. mda y Aplicaciones [en línea]. (dsdm´05), Granada, España, pp.10. Disponible en http://ftp.informatik.rwthaachen.de/Publications/

Greenfield, J.; Short, K.; Cook, S., et al. (2004). Software Factories: Assembling Ap-plications with Patterns, Models, Frameworks, and Tools. Wiley.

Griss, M.; Favaro, J., y D’Allessandro, M. (1998, junio). Integrating Feature Mod-eling with the rseb. En: Proceedings of Fifth International Conference on Software Reuse (icsr`5), Victoria, Canadá, pp. 76-85.

Hickman, F.; Killin, J., y Land, L. (1989). Analysis for Knowledge-Based Systems: A Practical igude to the kads Methodology. England: Ellis Horwood, pp. 190.

ieee-1471 (2000). ieee Standard Asotiation. ieee Product No. SH94869-tbr, ieee Recommended Practice for Architectural Description of Software-Inten-sive Systems. Disponible en http://standards.ieee.org/reading/ieee.std_public/description/se/1471-2000_desc.html

Jacobson, I.; Griss M., Jonsson, P. (1997). Software Reuse. Architecture, Process and Organization for Business Success. acm Press. Addison Wesley Longman.

jipdec (1989). Japan Information Processing Development Center. Disponible en http://www.jipdec.or.jp/eng/. Y http://findarticles.com/p/articles/mi_m1052/is_/ai_8550825?tag=artBody;col1

Kang, K.; Cohen, S.; Hess, J., et al. (1990). Feature-Oriented Domain Analysis (foda). Feasibility Study. Technical Report cmu/sei-90- tr21 (esd-90- tr-222), Software Engineering Institute, Carnegie-Mellon University, Pitts-burgh, Pennsylvania 15213.

Kang, K.; Kim, S.; Lee, J., et al. (1998a). “form: A Feature Oriented Reuse Method with Domain Specific Reference Architectures”. En: Annals of Software Engineering, Vol. 5, pp. 143-168.

Kang, K.; Kim, S.; Lee, J., et al. (1998b) Kang K. C., Kim S., Lee J., Kim K., and Shim E., Feature-Oriented Software Engineering for the Electronic Bulletin Board System (EBBS) Domain. En: Proceedings of the Third World Con-ference on Integrated Design and Process Technology (idpt’98).

238


Kent, S. Model Driven Engineering. Integrated Formal Methods: Third Interna-tional Conference, IFM 2002, Turku, Finland, May 15-17, 2002. lncs, Vol. 2335, Springer-Verlag, 2003, pp. 286-298.

Kleppe, A.; Warmer, J., y Bast, W. (2003). Kleppe A., Warmer J., and Bast W. MDA Explained: The Model Driven Architecture™: Practice and Promise, Addison Wesley Professional, ISBN 978-0-321-19442-8.

Kiczales, G. (1997). Aspect Oriented Programming (ecoop`97), lncs 124, Springer Verlag.

Kiczales, G.; Hilsdale, E.; HulGUn, J., et al. (2001). An Overview of AspectJ. Pro-ceeding of the European Conference on Object-Oriented Programming, Springer Verlag.

Klingler, C., y Solderitsch, J. dagar: A Process for Domain Architecture Definition and Asset Implementation. In Proceedings of the Annual International Conference on ada (TriAda’96), pp. 231-245, December 3-7, 1996, Phil-adelphia, PA (USA). acm, acm Press.

Knauber, P., y Succi, G. Perspectives on Software Product Lines. acm Software Engi-neering Notes, 26(2):29-33. Marzo, 2001.

Krueger, Ch. (1992). Software Reuse. acm Computing Surveys, 24(2):131-183.Krueger, Ch. (2002). Variation Management for Software Production Lines. En: Pro-

ceedings of splc 2002, pp. 37-48. Krueger, Ch. (2006). New Methods in Software Product Line Development, splc

2006, Austin, Texas, EUA, pp. 95-102.Krutchten, P. “The 4+1 View Model of Architecture”. En: ieee Software 12(6),

1995, pp. 42-50.Kurtev, I. (2005). Adaptability of Model Transformations. PhD. Thesis, University of

Twente, The Netherlands.Lee, K.; Kang, K.; Chae, W., et al. (2000). Feature-Based Approach to Object-Orient-

ed Engineering of Applications for Reuse. Software: Practice and Experience, 30(9):1025-1046.

Liao, S. Knowledge “Management Technologies and Applications- Literature Re-view from 1995-2002”. En: Expert Systems with Applications, Vol. 25, Is-sue 2, 2003, pp. 155-164.

Liao, S. “Expert Systems Methodologies and Applications- a Decade Review from 1995-2004”. En: Expert Systems with Applications, Vol. 28, Issue 1, 2005, pp. 93-103.

Liebewitz, J. (1998). The Handbook of Applied Expert Systems. CRC Press.Limón, R.; Ramos, I., y Torres, J. (2006). Designing Aspectual Architecture Views.

En: Aspect Oriented Software Development, Computational Science and its Applications, LNCS 3983, pp. 726-735.

Limón, R.; Cabello, M., y Ramos, I. (2007). Establishing Relations among Software Architecture Views through mda for spl. En: Proceedings of the 14 th Inter-national Congress on Computer Science Research- ciicc´07, Veracruz, México, pp. 175-187, 2007.

239

Bibliografía

Linton, M.; Vlissides, J., y Calder, P. (1989). Composing User Interfaces with Inter-views. ieee Computer, 22(2).

Little, J. (1970). Models and Managers: The Conceptual of a Decision Calculus. Man-agement Science, Vol. 16, No. 8, abril, 1970, pp. 466-485.

López-Herrejón, R. (2005). Understanding Feature Modularity in Feature Orient-ed Programming [en línea]. Disponible en http://www.ecoop.org/phdoos/ecoop2005phd/RobertoErickLopezHerrejon.pdf

Loques, O.; Sztajnbberg, A.; Leite, J., y Lobosco, M. (2000). On the Integration of Meta-level Programming and Configuration Programming. En Walter Caz-zola, Robert J. Stroud, Francesco Tisato V. (eds.), Reflextion and Software Engineering (special edition). Lectures Notes in Computer Science, pp. 191-210, Springer-Verlag, Heidelberg, Germany.

McIlroy, M. (1976). Mass-Produced Software Components. Software Engineering Concepts and Techniques; 1968 NATO Conference on Software Engineer-ing. J. M. Buxton, P. Naur y B. Randell editores. Pp. 88-98. Van Nostrand Reinhold.

mda (2003). omg-Model Driven Achitecture, mda Guide Version 1.0.1. Disponi-ble en http://www.omg.org/docs/omg/03-06-01.pdf

Mediniqvt (2007). Disponible en http://projects.ikv.de/qvtMedvidovic, N., y Taylor, R. “A Classification and Comparison Framework for Soft-

ware Architecture Description Languages”. ieee Transactions on Software Engineering 26(1) 70-93, junio, 2000.

Medvidovic, N., y Taylor R. (2002). A Classification and Comparison Framework for Software Architectures. En: Proceedings of ideas, La Habana, Cuba.

Melnik, S.; Rahm, E., y Bernstein, P. (2003). Rondo: A Programming Platform for Generic Model Management. sigmo, en Web Semantics, vol. 1, número 1.

Mens, T., y Van Gorp, P. (2005). A Taxonomy of Model Transformation. Proceed-ings of Workshop on Graph and Model Transformation (GraMoT 2005).

Meyer, M., y Lehnerd, A. (1997). The Power of Product Platforms. Free Press.Mili, H.; Mili, F., y Mili, A. (1995). Reusing Software: Issues and Research Directions.

En: ieee Transaactions on Software Engineeering, 21(6):528-562.Miller, J., y Mukerji, J. (2001). Model Driven Architecture. Document number orm-

sc/2001-07-01. Disponible en http://www.omg.org/mda.ModelWare (2006). Smart qvt: An Open Source Model Transformation Tool

Implementing the mof 2.0 qvt-Operational Language. Disponible en http://smartqvt.elibel.tm.fr

mof (2006). omg-Meta-Object Facility 2.0. Disponible en http://www.omg.org/spec/MOF/2.0/PDF, http://www.omg.org/docs/ formal/06-01-01.pdf

Monge, R.; Alves, C., y Vallecillo, A. (2002). A Graphical Representation of cots-Based Software Architecture. En: Proceedings of ideas, La Habana, Cuba.

Myllymaki, T. (2001). Variability Management in Software Product-Lines. Software Systems Laboratory, Tampere University of Technology.

240


Nakagawa, E.; Martins, R.; Felizardo, K., y Maldonado, J. (2009). Towards a process to design aspect-oriented reference architectures. En: Proceedings of clei’2009, pp. 1-10, Pelotas, Brazil.

Nakagawa, E.; Ferrari, F.; Sasaki, M., y Maldonado, J. (2011a). An aspect-oriented reference architecture for software engineering environments. En: Journal of Systems and Software, 84(10), pp.1670–1684.

Nakagawa, E., y Oliveira, L. (2011b). Using systematic review to elicit requirements of reference architectures. En: Proceedings of wer’2011, pp. 273–284, Rio de Janeiro, Brazil.

Nakagawa, E.; Antonino, P., y Becker, M. (2011c). Reference architecture and prod-uct line architecture: A subtle but critical difference. En: Proceedings of ecsa’2011, lncs 6903, pp. 207–211, Essen, Germany.

Neighbors, J. (1984). The Draco Approach to Constructing Software from Reusable Components. ieee Transactions on Software Engineering, SE-10(5):564-574.

net (2005). Microsoft. net Framework 2.0 / Visual Studio 2005. Disponible en http://msdn.microsoft.com/en-us/library/zw4w595w(VS.80).aspx

Noriega, P., y Sierra, C. “Subastas y Sistemas Multiagente”. En: Revista Iberoameri-cana de Inteligencia Artificial, Número 6, 1998, pp. 68-84.

Northrop, L. (2002). SET Software Product Line Tenets. ieee Software, 19(04):32-40.

Northrop, L. Software Architecture in Practice. sei Series in Software Engineering, 2nd edition. Addison-Wesley, octubre 2003, Cap.14: Software Product Lines: re-using architectural assets. Pp. 352-368.

ocl (2003). omg-Object Constraint Language, version 2.0. Document uml 2.0 OCL Final Adopted specification. Disponible en http://www.omg.org/cgi-bin/doc?ptc/2003-10-14

Oliva, A.; Garcia, I., y Buzato, L. (1998). The Reflective Architecture of Guaraná. Technical Report ic-98-14, Instituto de Computación, Universidad de Campiñas.

omg. Disponible en http://www.omg.orgomg-bpmi (2005). Disponible en http://www.bpmi.org. Y http://www.omg.org/

news/releases/pr2005/06-29-05.htm - 15k omg-bpmn (2006). Disponible en http://www.omg.org/issues/, OMG final adop-

ted specification, feb 2006, dtc/06-01-01, http://www.bpmn.org/Docu-ments/

Pérez, J.; Ramos, I.; Lorenzo, A., et al. (2002). prisma: Plataforma oasis para Modelos Arquitectónicos. Actas de las vii Jornadas de Ingeniería de Software y Bases de Datos, jisbd, Escorial (Madrid), España.

Pérez, J.; Ali, N.; Costa, C., et al. (2005a). Executing Aspect-Oriented Compo-nent-Based Software Architectures on .net Technology. En: Proceedings of 3rd International conference on . net Technologies, Pilsen, Czech Repub-lic, pp. 97-108.

241

Bibliografía

Pérez, J.; Ali, N.; Carsí J., et al. (2005b). Designing Software Architectures with an Aspect-Oriented Language. En: Journal on Aspect Orientation, Published by Houman Younessi, rise ® advice 2004, Vol. 1.1. p. 20.

Pérez, J. (2003). oasis como soporte formal para la definición de Modelos Hipermedia Dinámicos, Distribuidos y Evolutivos. Trabajo de investigación dentro del programa de doctorado de Programación Declarativa e Ingeniería de la Programación. Universidad Politécnica de Valencia, España.

Pérez, J. (2006). prisma: Aspect-Oriented Software Architectures. PhD. Thesis of Phi-losophy in Computer Science, Polytechnic University of Valencia, Spain, pp. 397.

Pohl et al., 2005 Pohl K., Bockle G., and Van der Linden F., Software Product Line Engineering: Foundations, Principles and Techniques. Springer, 2005.

Pree, W. (1994). Meta Patterns – A Means for Capturing the Essential of Reusable Object-Oriented Design. En Proceedings of the 8th European Conference on Object-Oriented Programming. Bologna, Italy.

Pree, W. (1995). Design Patterns for Object-Oriented Software Development. Ad-dison-Wesley, 1995.

Queralt, P.; Hoyos, L.; Boronat, A., et al. (2006). Un motor de transformación de modelos con soporte para el lenguaje qvt Relations. Taller Desarrollo de Software Dirigido por Modelos - dsdm’06 (junto con jisbd’06), Sitges, España.

qvt (2005). omg-Query/View/Transformations: mof 2.0 qvt Final Adopted Spec-ification. Disponible en http://www.omg.org/docs/ptc/05-11-01.pdf

ras (2005). omg- Reusable Asset Specification v2.2. Disponible en http://www.omg.org/technology/documents/formal/ras.htm, http://www.omg.org/cgi-bin/doc?formal/2005-11-02

Rashid, A.; Sawyer, P.; Moreira, A., et al. (2002). Aspects: a Model for Aspect-Ori-ented Requeriments Engineering. ieee Joint Conference on Requeriments Engineering, Essen, IEEE Computer Society, pp. 199-202, Germany.

Reich, Y., y Kapeliok (2005). Sistemas Expertos. Vol. 41, Issue 1, p.1-19.Riebisch, M.; Streitferdt, D., y Pshov, I. (2003). Modeling Variability for Object-Ori-

ented Product Lines. En: Proceedings of the Workshop Modeling Variabil-ity for Object-Oriented Product Lines, ecoop.

Santos, A.; Koskimies, K., y Lopes, A. (2007). Using Model-Driven Architecture for Variability Management in Software Product Lines. Ph Thesis Proposal Facultade de Ciencias de la Universidade de Lisboa, Portugal.

Schmidt, D. “Model-Driven Engineering. ieee Computer”. 39 (2), 2006, pp. 41-47.

sei (2007). Software Engineering Institute. A Framework for Software Product Lines Practice v4.2. Disponible en http://www.sei.cmu.edu

Sendall, S., y Kozaczynski, W. (2003). Model Transformation – the Heart and Soul of Model-Driven Software Development. ieee Software, Special Issue on Mod-el Driven Software Development, pages 42-45.

242


Shaw, M., y Clements, P. (2006). The Golden Age of Software Architecture, ieee Soft-ware, Volume: 23 Issue: 1, pp. 31-39.

Simos, M.; Creps, D.; Klingler, C., et al. (1996). Organization Domain Modeling (odm) igudebook – Version 2.0. Technical Report stars-vc-a025/001/00, Lockheed Martin Tactical Defense Systems, 9255 Wellington Road Manassas, va 22110-4121.

Simos, M. (1995, abril). Organization Domain Modeling (odm): Formalizating the Core Domain Modeling Life Cycle. Symposium on Software Reusability.

Sonnemann, R. (1995). Exploratory Study of Software Reuse Factory. PhD. thesis, George Mason University, Fairfax, Virginia, Spring.

spem (2006). Software Process Engineering Metamodel, Version 2.0. Technical Report, 2006. Disponible en http://www.omg.org/docs/ad/06-06-02.pdf

spl. Web page of The Software Product Lines. Disponible en http://www.software-productlines.com

Sprague, R.H. A Framework for the Development of Expert Systems, Management Information Systems Quarterly, vol. 4, número 4, 1980, pp. 1-26.

Studer, R.; Decker, S., y Fresel, D. (2000). Situation and Perspective of Knowledge Engineering, en: J. Cuenca et al. (eds.), Knowledge Engineering and Agent Technology, ios Press, pages 16.

Suvée, D.; Vanderperren, W., y Jonckers, V. (2003, marzo). JAsCo: An Aspect-Ori-ented Aprroach Tailored for Component-Based Software Development. 2nd International Conference on Aspect-Oriented Software Development (aosd), acm Press, pp. 21-29. Boston, Massachusetts, USA.

Svahnherg, M.; Van Gurp, J., y Bosch, J. (2000a). On the Notion of Variability in Software Product Lines. Blekinge Institute of Technology Research Report 2000:2.

Svahnherg, M., y Bosch, J. (2000b). Issues Conserning Variabiliaty in Software Product Lines. En: Development and Evolution of Software Architectures for Product Familie. Proceedings of International Workshop iw-sapf3, Vol. 1409 of Lecture Notes in Computer Science, Springer, pp. 146-157.

Szyperski, C. (1998). Component Software: beyond Object-Oriented Programming. acm Press and Adisson Wesley, New York, USA.

Taenatzer, G.; Nagl, M.; Schurr, A., y Munch, M. (2000). agg: A Tool Environ-ment for Algebraic Graph Transformation. Applications of Graph Trans-formations with Industrial Relevance. Ed. Springer Verlag, lncs 1779, pp. 481-488.

Turban, E., y Aronson, J. (2001). Expert Systems and Intelligent Systems. Prentice Hall, pp. 865 pages.

Trujillo, S. (2007). Feature Oriented Model Driven Product Lines. PhD. Thesis, The University of the Basque Country, San Sebastian, Spain, pp. 175.

uml (2005). omg-Unified Modeling Language version 2.0. Disponible en http://www.omg.org/docs/formal/05-07-04.pdf.

243

Bibliografía

Van der Linden, F.; Schmid, K., y Rommes, E. (2007). Software Product Lines in Action: the Best Industrial Practice in Product Line Engineering. Springer, pp. 333.

Van Group, J., y Bosch, J. (2002). Design Erosion: Problems and Causes, Journal of Systems & Software, 61 (2), pp. 105-119.

Vici, A., y Argentieri, N. (1998, junio). fodacom: An Experience with Domain Anal-ysis in Italian Telecom Industry. En: Proceedings of the Fifth International Conference on Software Reuse, icsr-5, pp. 166-175. 2 - 5, Victoria, B.C., Canada. ieee-cs.

Warmer, J., y Kleppe, A. (2004). The Object Constraint Language, Second Edition, Getting Your Models Ready for mda. Addison-Wesley.

White, S. (2004). Process modelling notations and workflow patterns. bptrends.Wirfs-Brock, R., y Johnson, R. (1990). Surveying current research in object-oriented

design. Communications of the acm, 33(9):105-124.xml (2006). w3c Consortium. Extensible Markup Language (xml), version 1.0.

Disponible en http://www.w3.org/TR/2006/REC-xml-20060816/.61xslt (2005). w3c Consortium. xsl Transformations (xslt), version 2.0. Disponible

en http://www.w3.org/TR/xslt20/.60,61

244

Autores

María Eugenia Cabello Espinosa Licenciada en física por la Universidad Nacional Autónoma de México, maestra en ciencias de la computación por la Fundación Arturo Rosen-blueth, diplomada de diseño gráfico asistido por computadora por la Uni-versidad de Colima, así como varios grados otorgados por la Universitat Politècnica de València, España: especialidad en programación declarativa e ingeniería de la programación, diploma de estudios avanzados, maestría en ingeniería de software, métodos formales y sistemas de información, y doc-torado en programación declarativa e ingeniería de la programación. Líder del cuerpo académico Tecnologías de Información y Desarrollo de Software de la Universidad de Colima; miembro y líder de varios proyectos de inves-tigación con financiamiento; y miembro de sociedades académicas como la Red Española de Líneas de Productos Software y la Sociedad Mexicana de Ciencias de la Computación. Sus intereses de investigación se centran en los sistemas expertos, el dominio del diagnóstico, las líneas de produc-tos software, el desarrollo de software dirigido por modelos y las ontologías.

Isidro Ramos Salavert Licenciado y doctor en ciencias físicas por la Universidad Complutense de Madrid, España, y licenciado en ciencias de la computación por Universi-dad Politécnica de Madrid, España. Presidente fundador de la Sociedad Es-pañola de Ingeniería en Software, rector fundador de la Universidad Castilla La Mancha, Premio Nacional de Informática 1974, Premio Nacional de In-formática García Santesmases 2007 y Premio Sapiens Académico 2014 por su contribución investigadora en su amplia trayectoria universitaria; fun-dador de varios centros de informática y grupos de investigación en diver-sas universidades europeas, líder de varios proyectos de investigación con fi-nanciamiento, miembro de sociedades académicas como la Red Española de Líneas de Productos Software. Sus principales intereses de investigación en la ingeniería en software están relacionados con las líneas de productos soft-ware, el desarrollo de software dirigido por modelos, las arquitecturas soft-ware y la transformación de modelos.

245

Acrónimos

adl Architecture Description Language (Lenguaje de Descripción de Arquitecturas)alp Arquitectura de la Línea de Productosaosd Aspect-Oriented Software Development (Desarrollo de Software Orientado a

Aspectos)bom Baseline-Oriented Modelingbpmn Business Process Model Notation (Notación para el Modelado de Procesos de

Negocio)cbsd Component-Based Software Development (Desarrollo de Software Basado en

Componentes)cim Computer Independent Model (Modelo Independiente de Computación)des Diagnostic Expert Systems (Sistemas Expertos de Diagnóstico)dsl Domain Specific Languages (Lenguajes Específicos de Dominio)es Expert Systems (Sistemas Expertos)fdl Feature-Description Language (Lenguaje de Descripción de Características)fom Feature-Oriented Modeling (Modelado Orientado a Características)fop Feature-Oriented Programming (Programación Orientada a Características)igu Interfaz Gráfica del Usuario mcd Modelo Conceptual de Dominiomcda Modelo Conceptual del Dominio de la Aplicaciónmda Model-Driven Architecture (Arquitectura Dirigida por Modelos)mde Model-Driven Engineering (Ingeniería Dirigida por Modelos)omg Object Management Group (Grupo de Gestión de Objetos)pim Platform Independent Model (Modelo Independiente de Plataforma)psm Platform Specific Model (Modelos Específicos de Plataforma)ras Reusable Asset Specification (Especificación de Recursos Reutilizables)sav Software Architecture Views (Vistas de Arquitecturas Software)sf Software Factoriesslp Software Product Line (Línea de Productos Software)spem Software Process Engineering Metamodel (Metamodelo de Ingeniería de

Procesos de Software)uml Unified Modeling Language (Lenguaje de Modelado Unificado)vfs Vista Funcional del Sistemavp Variability Points (Puntos de Variabilidad)vvs Vista de la Variabilidad del Sistema

Ingeniería de aplicaciones dirigida por modelos y basada en técnicas de líneas de productos software, de María Eugenia Cabello Espinosa e Isidro Ramos Salavert, fue editado en la Dirección General de Publicaciones de la Universidad de Colima, avenida Universidad 333, Colima, Colima, México, www.ucol.mx. La edición se terminó en abril de 2016. En la composición tipográfica se utilizó la familia Adobe Garamond Pro. El tamaño del libro es de 22.5 cm de alto por 16 cm de ancho. Programa Editorial: Alberto Vega Aguayo. Gestión Administrativa: Inés Sandoval Ve-negas. Corrección: José Augusto Estrella. Diseño: José Luis Ramímez Moreno. Cuidado de la edición: Alberto Vega.

Ingeniería de aplicaciones dirigida por modelos y basada en técni-cas de líneas de productos software en el contexto de la MDE (del inglés Model-Driven Engineering) presenta la aproximación BOM (del inglés Baseline-Oriented Modeling), acrónimo del modelado orientado a la Baseline (repositorio de software reutilizable). BOM es un framework que genera aplicaciones software en un dominio específico, dirigido por modelos y que utiliza técnicas de líneas de productos software. Este proceso implica, por un lado, construir una Baseline que contenga todos los assets necesarios para obte-ner todos los productos de una línea de productos software, y por otro lado, realizar el plan de producción de la misma. BOM es ilus-trado mediante el dominio de los sistemas expertos que realizan tareas de diagnósticos.

Inge

nier

ía d

e ap

licac

ione

s

INGENIERÍA DEAPLICACIONES

dirigida por modelos y basada en técnicasde líneas de productos software

María Eugenia Cabello EspinosaIsidro Ramos Salavert

María

Eug

enia

Cabe

llo E

spino

saIsi

dro R

amos

Sala

vert

dirig

ida

por m

odel

os y

bas

ada

en té

cnic

as d

e lín

eas

de p

rodu

ctos

sof

twar

e

María Eugenia Cabello EspinosaDoctora en programación declarativa e ingeniería de la programación por la Universitat Politècnica de València. Sus intereses de investigación se centran en los sistemas expertos, las líneas de productos software, el desarrollo de software dirigido por modelos y las ontologías.

Isidro Ramos SalavertDoctor en ciencias físicas por la Universidad Complutense de Madrid. Sus principales intereses de investigación en la ingeniería en software están relacionados con las líneas de productos software, el desarrollo de software dirigido por modelos, las arquitecturas software y la transforma-ción de modelos.

aplicaciones ), acrónimo del modelado - ucol.mx · ingeniería de aplicaciones dirigida por...

Documents