4+1 Vistas y Mas Ion

2 ESTADO DEL ARTE
Este capítulo se concibe como una exposición sobre la situación actual en cuanto al
empleo de entornos multidisciplinares en el desarrollo de SW para SCDTR. Esta
exposición se hace de forma progresiva.
Se inicia con una descripción de la ciencia básica sobre dos conceptos abstractos
identificados como necesarios para el entorno en el primer capítulo: el Modelado y
el empleo de Lenguajes Formales como mecanismo de expresión de instancias de
modelos. Se repasarán, entre otras, nociones como vista, abstracción o instancia,
por un lado, y léxico, sintaxis o semántica por el otro. Así mismo, se introducirán
los fundamentos de dos tecnologías estándar aplicables en cada uno de estos dos
campos: el lenguaje de modelado UML y el lenguaje formal XML, respectivamente.
El interés en este punto no va más allá de conocer las ventajas que estas
tecnologías pueden aportar para ubicarlas con criterio en el entorno, pero será en
otros capítulos donde se profundice sobre las características más específicas de las
técnicas seleccionadas.
Posteriormente, el estudio se centra en las Herramientas Específicas de

Dominio, es decir, en las herramientas más utilizadas en cada una de las
disciplinas mencionadas en el primer capítulo. Este recorrido permitirá recoger
similitudes y diferencias entre herramientas, que conducirán al enunciado de las
necesidades que se le imponen al entorno que las integre. También se describirán
algunas Aproximaciones a la Integración de Herramientas o soluciones
ofrecidas por otros grupos de investigación que también persiguen la colaboración y
comunicación entre herramientas.
2.1 Modelado
2.1.1 Niveles de Abstracción
2.1.2 Modelo de 4+1 vistas
2.1.3 UML (Unified Modeling Language)

2.1.3.1 Diagramas utilizados en UML
2.1.3.2 Proceso de Desarrollo
2.1.3.3 Carencias de UML 1.4
2.1.4 Estándares OMG

2.1.4.1 Model Driven Architecture (MDA)
2.1.4.2 Meta Object Facility (MOF)
2.1.4.3 XML Metadata Interchange (XMI)
2.1.5 UML 2.0
2.2 Lenguajes Formales

2.2.1 Algunas Definiciones
2.2.2 EBNF
2.2.3 XML
2.2.4 Generación de Gramáticas a partir de Modelos UML
2.3 Herramientas Específicas de Dominio

2.3.1 Ingeniería de Control
2.3.2 Sistemas Distribuidos
2.3.3 Sistemas de Tiempo Real

2.3.3.1 UML para Sistemas de Tiempo Real
2.3.4 Ingeniería del SW

2.3.4.1 Modelo de Madurez de Capacidad Software (CMM)
2.3.4.2 El Proceso de Desarrollo del SW
2.3.4.3 Estructura de las Herramientas CASE
2.3.4.4 Lenguajes de Descripción de Arquitecturas
2.4 Aproximaciones a la Integración de Herramientas

2.4.1 Soluciones particulares de dominio
2.4.1.1 NetBeans
2.4.1.2 Ptolemy
2.4.2 Soluciones genéricas (METAframework)

2.4.2.1 Generic Modelling Environment (GME)
2.4.2.2 Eclipse
Capítulo 2: Estado del Arte
22..11 M
MOOD
DEEL
LAAD
DOO
Sobre la construcción de un modelo como abstracción de la realidad y

sobre la jerarquía de las abstracciones. Descripción de las características
de UML y otros estándares OMG relacionados con el modelado.
2.1.1 NIVELES DE ABSTRACCIÓN

El modelado es necesariamente un ejercicio de abstracción, entendida ésta como
una simplificación y generalización de la realidad. Abstraer significa ignorar, excluir
o esconder ciertos detalles de un conjunto de elementos con el objetivo de capturar
y resaltar las características comunes a todos esos elementos. Una abstracción es
hija y madre a la vez porque primeramente es concebida a partir del análisis de
ciertos elementos, pero después sirve como origen para la instanciación o
concreción de nuevos elementos que se derivan de ella. Ejemplos típicos de
abstracción son los tipos de datos que se usan en programación para agrupar datos
con características comunes.
El uso de la abstracción permite describir, representar, manejar y resolver

problemas complejos, pudiendo después aplicar los resultados a casos concretos
(instancias). Normalmente, se construyen jerarquías de abstracción, en las que
cada nivel de abstracción se apoya en los inferiores. Cada nivel de abstracción
esconde ciertos detalles a los niveles superiores de forma que se simplifica el
tratamiento de problemas más complicados. Se dice que la construcción de los
niveles de abstracción se hace ‘de abajo hacia arriba’ (bottom-up), puesto que se
parte de lo más concreto y se van agrupando y generalizando características
comunes para ‘subir’ un peldaño más en la pirámide de niveles. Por el contrario, la
implementación o puesta en práctica de resultados genéricos se hace de ‘arriba
hacia abajo’ (top-down) porque a partir de una solución genérica deducida desde
un nivel de abstracción alto se va ‘descendiendo’ para poder instanciar esa solución
y aplicarla a una realidad concreta.
En general, pueden definirse tantos niveles de abstracción como se precise para

gestionar adecuadamente un determinado problema. Incluso para un mismo
problema pueden existir diferentes aproximaciones de abstracción, por ejemplo los
marcos de referencia OSI y TCP/IP emplean respectivamente siete y cuatro niveles
de abstracción para representar las capas involucradas en la comunicación de
información.
La representación abstracta de la información es la base en la que se fundamenta la

evolución del conocimiento humano en cualquier área. Concretamente, en el caso
de la informática los ejemplos son múltiples: codificación de la información,
Pág. 2-1
programación en lenguajes de alto nivel, generación de compiladores, modularidad

del software, etc. En este ámbito de la informática se definen típicamente cuatro
niveles de abstracción para el modelado:
Tabla 2-1. Niveles de abstracción en el modelado.
NIVELES DE ENTIDADES LENGUAJES DEFINIDOS

ABSTRACCIÓN MANEJADAS
Meta-metamodelo Meta-modelos Lenguaje para la descripción de diferentes tipos de

modelos. Lenguaje de modelado
Meta-modelo Meta-metadatos ó Lenguaje para la descripción de diferentes tipos de datos

Modelos (meta-datos)
Modelo Meta-datos Lenguaje para la descripción de datos concretos
Información Datos
• Nivel de Información. Agregación ‘informal’ de datos a manejar en un

entorno concreto (aplicación). Se separa un subconjunto de datos con
características comunes o interesantes desde un determinado punto de
vista.
• Nivel de Modelo. Agregación ‘informal’ de meta-datos (datos sobre los

datos) que describen una información concreta. Se describen las
características comunes de los datos dando lugar a meta-datos que se
agrupan, describiéndose las relaciones entre ellos, para formar un modelo.
• Nivel de Meta-modelo. Agregación ‘informal’ de modelos o meta-

metadatos (descripción de meta-datos). Descripciones que definen la
estructura y la semántica de los metadatos. Se describen las características
comunes de subconjuntos de meta-datos dando lugar a meta-metadatos o
modelos que se agrupan, describiéndose las relaciones entre ellos, para
formar un meta-modelo.
• Nivel de Meta-metamodelo. Definición de la estructura y la semántica de

los meta-metadatos. Se capturan las características comunes de
subconjuntos de modelos dando lugar a meta-modelos que se agrupan,
describiéndose las relaciones entre ellos, para formar un meta-metamodelo.
Tal y como muestra la Tabla 2-1, en cada nivel de define una nueva entidad (meta-
dato, modelo, meta-modelo,…) que es empleada en el nivel superior para generar
otra entidad más abstracta (modelo agrupando meta-datos, meta-modelo
agrupando modelos,…). Además, la adecuada expresión de esta jerarquía de
abstracciones está directamente relacionada con el uso de lenguajes formales. En
cada nivel de abstracción se genera el lenguaje que sirve para describir los
elementos del nivel inmediatamente inferior. Por esa razón, un modelo no pasará a
constituirse en agregación formal de meta-datos hasta que no exista un meta-
Pág. 2-2
modelo que defina el lenguaje con el que describir formalmente al modelo, de

forma que la especificación de cualquier modelo (instancia del meta-modelo) pueda
ser validada.
De una manera burda, se pueden asemejar estos niveles de abstracción con los
empleados en la definición de los lenguajes de programación de alto nivel, tal y
como muestra la Tabla 2-2:
Tabla 2-2. Ejemplo de abstracción jerárquica: lenguajes de programación.
ENTIDADES
NIVELES LENGUAJES
MANEJADAS
Meta-lenguaje Lenguajes de Lenguaje para la descripción de diferentes lenguajes

programación programación de programación
Lenguaje programación Sentencias control flujo, Lenguaje para la descripción de programas como
variables, tipos,… modelos de ejecuciones
Tipos de datos TYPE Lenguaje para la descripción de tipos de datos como

modelos de variables
tNombre = string [20];
tCuenta = RECORD ...
Variables Nombre, Número Lenguaje para la descripción de variables (y

cuenta,... relaciones entre ellas) como modelos de los datos
Información bancaria ‘Aitor Pérez’, 1253456,...
En el caso particular de la programación orientada a objetos se puede decir que los

niveles de abstracción más significativos serían: dato, objeto, clase y modelo.
En general, se puede aplicar el modelado jerárquico en cualquier ámbito, teniendo

claro cuál es el nivel inferior o qué tipo de información se va a modelar y con qué
propósito y cuántos niveles de abstracción (por encima del inicial) se van a
necesitar. Habitualmente se emplea el término alinear para denotar la acción de
definir o fijar la información a modelar, los datos que van a constituir el primer
escalón de la jerarquía. A partir de ese punto de denotan los niveles superiores
como modelo, metamodelo, meta-metamodelo, etc respecto al más inferior.
Pág. 2-3
Figura 2-1. Arquitectura de metamodelado de UML en 4 niveles.
La Figura 2-1 representa la arquitectura de UML (lenguaje de modelado que se

describirá en el apartado 2.1.3) tal y como es definida por Medvidovic y Taylor
(2000) y basada en cuatro niveles. El nivel de meta-metamodelo define un lenguaje
para la especificación de notaciones de modelado, y una de sus instancias es UML.
El nivel de metamodelo define las especificaciones legales para un determinado
lenguaje de modelado, por ejemplo el metamodelo UML define la notación legal y la
semántica de las especificaciones UML. El nivel de modelo se usa para representar
sistemas específicos, un modelo será así una instancia del metamodelo que
describe un producto específico. Finalmente, se encuentra el nivel de los objetos de
usuario.
Pág. 2-4
2.1.2 MODELO DE 4+1 VISTAS

En lo concerniente al modelado de sistemas software desde varios puntos de vista,
es obligada la referencia al modelo 4+1 de Kruchten (1995). Este modelo permite
describir la arquitectura de grandes sistemas SW desde múltiples vistas para tratar
separadamente los requisitos de usuarios finales, desarrolladores, ingenieros de
sistemas, gestores de proyecto, etc. Por lo tanto, son diferentes y complementarias
las capacidades de cada vista porque detrás de ellas hay perfiles de usuario
diferentes. El modelo describe vistas (arquitecturas) a través de elementos
(componentes, conectores) y notaciones gráficas específicas para cada vista. Las
vistas que se definen son:
• Vista Lógica. Está pensada para que el usuario final pueda describir la
funcionalidad deseada. Se realiza una descomposición del sistema siguiendo la
filosofía de Orientación a Objetos (abstracción, encapsulado y herencia). La
notación gráfica empleada se compone de diagramas de clases y patrones para
la descripción estática y máquinas de estados finitos para describir el
comportamiento dinámico. Los elementos de su notación son:
o Componentes: clase, clase parametrizada, categoría de clases
o Conectores: asociación, agregación, uso, herencia, instancia
• Vista de Proceso. Los integradores del sistema la emplean para expresar

requisitos no funcionales como integridad, rendimiento o escalabilidad. Se
realiza la distribución de los objetos diseñados en la vista lógica en procesos
(conjunto de tareas concurrentes) en función de los requisitos no funcionales.
Se deben reflejar aspectos de concurrencia, sincronización y comunicación entre
procesos. Los elementos de su notación son:
o Componentes: proceso, proceso simple, periodicidad
o Conectores: mensaje, RPC (Remote Procedure Call), mensaje

bidireccional, difusión de evento
• Vista de Desarrollo. Los programadores la emplean para describir la

organización estática del SW en el entorno de desarrollo (gestión del SW,
descomposición en subsistemas a desarrollar por gente diferente, descripción de
interfaces, relaciones de importación y exportación, reutilización, requisitos del
lenguaje de programación o herramientas de desarrollo, evaluación de costes,
planificación, portabilidad, seguridad). Los elementos de su notación son:
o Componentes: módulo, subsistema, nivel
o Conectores: referencia, dependencia de compilación
Pág. 2-5
• Vista Física. Los ingenieros de sistema definen aquí el mapeo del SW en el HW

aplicando requisitos como disponibilidad, tolerancia a fallos, rendimiento o
escalabilidad. Si existen varios nodos es aquí donde se define la topología del
sistema y las comunicaciones y se mapean en diferentes nodos los procesos,
tareas y objetos. Pueden existir diferentes configuraciones físicas de un mismo
sistema para las fases de pruebas y desarrollo. Se intenta realizar un mapeo
flexible y con mínimo impacto en el SW. Los elementos de su notación son:
o Componentes: procesadores, otros dispositivos
o Conectores: línea de comunicación permanente o no, bidireccional o

unidireccional
• Escenarios ó casos de uso. Ilustran el uso y las relaciones entre el resto de

las vistas y permiten abstraer los requisitos más generales. El nombre de ‘4+1’
proviene del uso que se le da a esta quinta vista como vista integradora de las
demás, en la que se expresan las relaciones cruzadas. Los elementos de su
notación son:
o Componentes: actores, casos de uso
o Conectores: relaciones
Tal y como resume la Figura 2-2, cada vista tiene un perfil de usuario y una
notación gráfica especializada (formada siempre por un conjunto de componentes y
conectores) para resolver sus necesidades expresivas. Además, se establece un
proceso de desarrollo porque está predefinido el orden en el cual se deben utilizar
cada una de las vistas para modelar el sistema; se comienza siempre por la vista
lógica y se termina en la física, pero se tiene en cuenta en cada vista lo que se
haya generado en las anteriores. En definitiva, se avanza hacia una descripción
completa del sistema aportando detalles al todo desde perspectivas particulares.
Pág. 2-6
Cada vista posee diferentes:

• Usuarios / Objetivos
• Notación (componentes y conectores)
Figura 2-2. Vistas del Modelo 4+1
Pág. 2-7
2.1.3 UML (UNIFIED MODELING LANGUAGE)

Originalmente, UML fue concebido por Grady Booch, James Rumbaugh e Ivar
Jacobson de Rational Software. Posteriormente obtuvo el apoyo de la industria vía
el consorcio de socios de UML, y fue presentado al Object Management Group
(OMG) y aprobado por éste como estándar (17 de noviembre de 1997).
Debido a que UML evolucionó a partir de varios métodos orientados a objeto de

segunda generación (en cuanto a nivel de notación), mayoritariamente se cree que
sólo es aplicable a sistemas de software orientados a objeto cuando, realmente,
UML no es simplemente un lenguaje para modelado orientado a objeto de tercera
generación, sino un "lenguaje para modelado unificado" relativo a sistemas en
general (ver Figura 2-3). Al ser un lenguaje de modelado y no un método, consiste
en una notación principalmente gráfica, que cualquier método puede emplear para
expresar su diseño.
Rumbaugh
Booch Jacobson
Odell Meyer
Pre- and Post-conditions
Shlaer-Mellor
Object life cycles UML Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes Wirfs-Brock
Embly Responsabilities
Singleton classes Fusion
Operation descriptions,
message numbering
Figura 2-3. UML como fusión de varios lenguajes de modelado.
UML es un lenguaje de modelado para la especificación, visualización,

construcción y documentación de sistemas:
Como lenguaje, se emplea para la comunicación, es decir, como medio

para capturar el conocimiento (semántica) y expresar el conocimiento
(sintaxis) del sistema en estudio. Proporciona un vocabulario y las reglas
para combinar las palabras de ese vocabulario con objeto de posibilitar la
comunicación, de manera que un desarrollador puede escribir un modelo en
UML, y otro desarrollador, que incluso utilice otra herramienta de
programación, puede interpretar ese modelo sin ambigüedad.
Como lenguaje de modelado, se centra en la comprensión del sistema a

través de la formulación de un modelo del mismo (y su contexto respectivo).
Se trata de un lenguaje estándar para trazar “los planos del sistema”, cuyo
Pág. 2-8
vocabulario y reglas se centran en la representación conceptual y física de

un sistema.
En cuanto a cómo se aplica para especificar sistemas, se puede utilizar

para comunicar "qué" se requiere de un sistema y "cómo" puede ser
construido. Dado que especificar significa construir modelos precisos, UML
cubre la especificación de todas las decisiones de análisis, diseño e
implementación que deben realizarse al desarrollar e implementar un
sistema.
En cuanto a cómo se aplica para visualizar sistemas, se puede usar para

describir visualmente un sistema antes de ser construido. Un modelo
explícito facilita la comunicación.
En cuanto a cómo se aplica para construir sistemas, se puede emplear

para guiar la construcción de un sistema (similar a los "planos"). Además,
UML es lo suficientemente expresivo y no ambiguo como para permitir, a
través de herramientas que lo integran, la ejecución directa de modelos, la
simulación de sistemas y la instrumentación de sistemas en ejecución.
En cuanto a cómo se aplica para documentar sistemas, se puede utilizar

para capturar conocimiento de un sistema a lo largo de todo el proceso de
su ciclo de vida. UML cubre la documentación de la arquitectura de un
sistema y todos sus detalles, también proporciona un lenguaje para modelar
las actividades de planificación de proyectos y gestión de versiones.
Además, cuidando la unificación, integra las mejores prácticas de la ingeniería de la

industria tecnológica y de sistemas de información pasando por todos los tipos de
sistemas (software y no software), dominios (negocios versus software) y procesos
de ciclo de vida.
También es importante destacar que UML NO es:
Un lenguaje de programación visual, sino un lenguaje de modelado visual.

No obstante, existen herramientas CASE que conectan de forma directa los
modelos UML a una gran variedad de lenguajes de programación.
Una herramienta de especificación, sino un lenguaje para modelado de

especificación.
Un proceso, sino que habilita procesos.
En resumen, UML posibilita la captura y comunicación del conocimiento y facilita la

adaptación al posible aumento de complejidad o cambio. Este lenguaje para
modelado (estandarizado en ciertas industrias), no es un lenguaje cerrado, sino
más bien, un lenguaje abierto y totalmente extensible.
Pág. 2-9
2.1.3.1 Diagramas utilizados en UML
UML describe cualquier tipo de sistema en términos de diagramas

orientados a objetos.
Un diagrama es la representación gráfica de un conjunto de elementos,

normalmente mostrado como un grafo conexo de nodos (elementos) y arcos
(relaciones).
UML permite representar un sistema desde diferentes perspectivas, obteniendo

diferentes modelos en forma de diagramas. Por tanto, un diagrama es tan sólo una
proyección gráfica de los elementos que configuran un sistema.
UML incluye los siguientes diagramas:
• Diagrama de Casos de Uso
• Diagrama de Clases (incluyendo Diagrama de Objetos)
• Diagramas de Comportamiento:
o Estados
o Actividad
o Interacción (Diagramas de Secuencia y de Colaboración)
• Diagramas de Implementación:
o Componentes
o Despliegue
La Figura 2-4 muestra las relaciones que se establecen entre estos tipos de
diagramas. Otra posible clasificación de los diagramas UML los divide en:
• Estructurales: de clases, objetos, componentes y despliegue.
• De comportamiento: de casos de uso, estados, actividad, secuencia y

colaboración
• De gestión de modelos: de paquetes, de modelos y de subsistemas
Pág. 2-10
Diagramas de
Distribución
Diagramas de C
Clases Ó
D
I
Casos de Diagramas de G
Diagramas de
Uso Secuencia O
Componentes
Diagramas de
Colaboración Diagramas de
Estados
Diagramas de
Actividad
Figura 2-4. Relación entre diagramas.
2.1.3.1.1 Diagrama de Casos de Uso
Los Casos de Uso son descripciones de la funcionalidad del sistema

independientes de la implementación.Esta técnica permite capturar información
de cómo un sistema o negocio trabaja actualmente, o de cómo se desea que
trabaje. No pertenece realmente al enfoque orientado a objeto, más bien es una
técnica para el modelado de escenarios (un escenario es una instancia de un Caso
de Uso) en los cuales el sistema debe operar.
El modelo de los Casos de Uso comprende los actores (agente, persona o cosa que
solicita un servicio al sistema o actúa como catalizador para que ocurra algo), el
sistema y los propios Casos de Uso.
Un Caso de Uso describe una situación de uso del sistema interactuando con
actores. Se determinan observando y precisando, actor por actor, las secuencias de
interacción desde el punto de vista del usuario. Examinando estas secuencias de
interacción, que expresan las necesidades funcionales de los actores, se determina
el conjunto de funcionalidades del sistema. La Figura 2-5 ilustra un ejemplo de
diagrama de casos de uso.
La descripción del Caso de Uso incluye:
9 El inicio: ¿cuándo y qué actor lo produce?
9 El fin: ¿cuándo se produce y qué valor devuelve?
9 La interacción actor-caso de uso: ¿qué mensajes intercambian ambos?
9 Objetivo del caso de uso: ¿qué lleva a cabo o intenta?
9 Cronología y origen de las informaciones
9 Repeticiones de comportamiento: ¿qué operaciones son iteradas?
Pág. 2-11
9 Situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el

caso de uso?
Caso de uso
Actor
Caso de uso
Actor
Actor
Caso de uso
Actor
Caso de uso
Figura 2-5. Diagrama de casos de uso.
La realización de los Casos de Uso es la transformación de los distintos pasos y

acciones que lo describen en clases, operaciones y relaciones entre clases.En
resumen, los Casos de Uso describen, bajo la forma de acciones y reacciones, el
comportamiento de un sistema desde el punto de vista del usuario, permitiendo
definir los límites del sistema y las relaciones del sistema con el entorno.
2.1.3.1.2 Diagrama de Clases
Un Diagrama de Clases presenta las clases y objetos del sistema con sus
relaciones estructurales y de herencia.
El Diagrama de Clases (ver Figura 2-6) es el diagrama principal para el análisis y

diseño, aunque el trabajo realizado en los Diagramas de Casos de Uso, de
Secuencia y de Colaboración aporta información para establecer las clases, objetos,
atributos y métodos.
Pág. 2-12
Clase Clase Clase
1 .. 4 1 .. 2 1
1 * *
Clase 1 * Clase 1 * Clase
{disjunta, completa} *
1
Clase Clase Clase
Figura 2-6. Diagrama de Clases.
Los Diagramas de Clases y los Diagramas de Objetos pertenecen a dos vistas

complementarias del modelo. Un Diagrama de Clases muestra la abstracción de una
parte del dominio, mientras que un Diagrama de Objetos representa una situación
concreta del dominio, dado que cada objeto es una instancia de una clase y cada
enlace es una instancia de una relación (los enlaces vinculan objetos, las
asociaciones vinculan clases).
Los Diagramas de objetos que contienen objetos y enlaces son instancias de los
Diagramas de Clases que contienen clases y asociaciones. Por lo tanto, debe existir
coherencia entre ambos.
2.1.3.1.3 Diagramas de Interacción
Los Diagramas de Interacción muestran cómo se comunican los objetos en

una interacción.
Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las
aplicaciones. De ahí que se modelen las interacciones.
Existen dos tipos de Diagramas de Interacción: los Diagramas de Secuencia y los

Diagramas de Colaboración. Los Diagramas de Secuencia están bien adaptados
para representar interacciones, mientras que los Diagramas de Colaboración se
prestan más al descubrimiento de abstracciones pues permiten representar los
objetos en una disposición próxima a la realidad. Es frecuente empezar por uno de
Colaboración y pasar después a Secuencia.
2.1.3.1.4 Diagrama de Secuencia
El Diagrama de Secuencia muestra el orden cronológico de mensajes entre

objetos durante un escenario concreto.El Diagrama de Secuencia se emplea
para establecer un escenario del sistema, determinando los objetos y mensajes
involucrados. Presenta los objetos de un escenario mediante líneas verticales y los
Pág. 2-13
mensajes entre objetos como flechas conectando objetos. Además, refleja de

manera indirecta las opciones de control.
:Objeto :Objeto :Objeto :Objeto

:Actor :Actor
Mensaje
Mensaje
Mensaje
Mensaje
Mensaje
Mensaje
Mensaje
Mensaje
Figura 2-7. Diagrama de Secuencia.
Son de gran utilidad para:
• La documentación de un Caso de Uso: en términos próximos al usuario y sin

detallar la sincronización existente.
• La representación precisa de las interacciones entre objetos.Diagrama de

Colaboración
El Diagrama de Colaboración modela la interacción entre los objetos de un

Caso de Uso. La colaboración es mediante el intercambio de mensajes.El
Diagrama de Colaboración se emplea para establecer un escenario del sistema,
determinando los objetos y mensajes involucrados. Los objetos están conectados
por enlaces (links) en los cuales se representan los mensajes enviados
acompañados de una flecha que indica su dirección. Así, la estructura estática viene
dada por los enlaces, mientras que la estructura dinámica está representada
mediante el envío de mensajes por los enlaces. Además, la distribución de los
objetos en el diagrama permite representar una disposición espacial.
Son útiles en la fase exploratoria para identificar objetos. En realidad, el Diagrama

de Colaboración (ver Figura 2-8) ofrece una mejor visión del escenario cuando el
analista está intentando comprender la participación de un objeto en el sistema.
Pág. 2-14
N: mensaje :Objeto
Actor N: mensaje
:Objeto
N: mensaje
N: mensaje
N: mensaje
Actor
N: mensaje
N: mensaje :Objeto
N: mensaje
:Objeto
Figura 2-8. Diagrama de Colaboración.
2.1.3.1.6 Diagrama de Estados
El Diagrama de Estados modela el comportamiento de una parte del

sistema a través del tiempo.
Típicamente se elabora un Diagrama de Estados para cada clase que tenga un

comportamiento significativo; para el resto se puede considerar que tienen un único
estado. El comportamiento es modelado en términos del estado en el cual se
encuentra el objeto, qué acciones se ejecutan en cada estado y cuál es el estado al
que transita después de un determinado evento. Los Diagramas de Estados
representan autómatas de estados finitos desde el punto de vista de los estados y
las transiciones. El formalismo es el de los Statecharts (Harel et al 1990).
Los Statecharts son autómatas jerárquicos que permiten expresar concurrencia,

sincronización y jerarquías de objetos. Cada objeto sigue el comportamiento
descrito en el Statechart asociado a su clase, y el estado en el que se encuentran
caracterizas sus condiciones dinámicas.
El estado está caracterizado parcialmente por los valores de los atributos del
objeto. Cada objeto está en un estado en cierto instante y la transición entre
estados, que es instantánea, se debe a la ocurrencia de eventos. Los estados inicial
y final están diferenciados del resto.
Los Statecharts de UML son deterministas y son complementarios a los escenarios

(ver Figura 2-9).
Pág. 2-15
Transición
Estado Transición Estado
Transición Transición
Estado
Figura 2-9. Diagrama de Estados.
2.1.3.1.7 Diagrama de Actividad
El Diagrama de Actividad es una variante de los Diagramas de Estados,

organizado respecto a las acciones.
Caso especial de Diagrama de Estados donde:
• Todos (o la mayoría de) los estados son estados de acción.
• Todas (o la mayoría de) las transiciones son “disparadas” como consecuencia de

la finalización de la acción.
El Diagrama de Actividad (Figura 2-10) puede estar asociado a una clase, a la

implementación de una operación (representación del comportamiento interno de
un método) o a un Caso de Uso. Las actividades se enlazan por transiciones
automáticas, es decir, cuando una actividad termina se desencadena el paso a la
siguiente actividad. Las actividades no poseen transiciones internas ni transiciones
desencadenadas por eventos.
Actor Actor Actor
Actividad
Actividad
Actividad
Actividad
Actividad
Actividad Actividad
Actividad Actividad
Actividad
Figura 2-10. Diagrama de Actividad.
Pág. 2-16
2.1.3.1.8 Diagrama de Componentes
Los Diagramas de Componentes describen los elementos físicos y sus

realizaciones en el entorno de realización.
Un Diagrama de Componentes permite modelar la estructura del software y la

dependencia entre componentes. Normalmente, un componente es un grupo de
clases que trabajan estrechamente, pudiendo corresponder a código fuente, binario
o ejecutable. Pero en general, los componentes representan todos los tipos de
elementos software que entran en la fabricación de aplicaciones informáticas;
pueden ser: simples archivos, paquetes de Ada, bibliotecas cargadas
dinámicamente, etc. Por ejemplo: cada clase del modelo lógico se realiza en dos
componentes: la especificación y el cuerpo.La especificación contiene el interfaz de
la clase, mientras que el cuerpo contiene la realización de dicha clase.
Las relaciones de dependencia se utilizan en los Diagramas de Componentes para

indicar que un componente se refiere a los servicios ofrecidos por otro componente
(ver Figura 2-11).
Por otra parte, los distintos componentes pueden agruparse en paquetes, según un
criterio lógico, para simplificar la implementación. Son paquetes estereotipados en
<<subsistemas>> para incorporar la noción de biblioteca de compilación y de
gestión de configuración.
Los subsistemas organizan la vista de realización de un sistema. Cada subsistema

puede contener componentes y otros subsistemas (la descomposición en
subsistemas no es una descomposición funcional).
La relación entre paquetes y clases en el nivel lógico es la correspondiente entre

subsistemas y componentes en el nivel
Componente
Componente
Componente Componente Componente
físico.
Figura 2-11. Diagrama de Componentes.
Pág. 2-17
2.1.3.1.9 Diagrama de Distribución
Los Diagramas de Distribución muestran la disposición física de los

distintos nodos que componen un sistema y el reparto de los componentes
sobre dichos nodos.
El Diagrama de Distribución modela la distribución en tiempo de ejecución de los

elementos de procesamiento y componentes de software, con los procesos y
objetos asociados. Modelan los nodos y la comunicación entre ellos.
Nodo Componente
Componente
Componente
Nodo
Componente Componente
Nodo Componente
Componente Componente
Figura 2-12. Diagrama de Distribución.
2.1.3.2 Proceso de Desarrollo
UML no es una metodología.
Dentro del proceso de solución de un problema, es el método subyacente el que

sugiere cómo se utiliza el conocimiento para construir una solución. Esto incluye el
sugerir qué diagramas se deben usar, y la perspectiva y el nivel de abstracción a
emplear para trazar e interpretar dichos diagramas. Los métodos deberían
considerarse como sugerencias y recomendaciones que organizan y facilitan el
proceso de solución de un problema, más que ser considerados como reglas rígidas
e inflexibles que restringen al arte de resolver problemas.
UML no prescribe ningún enfoque en particular para resolver un problema, es muy

flexible y personalizable para adaptarse a cualquier enfoque. Permite y promociona
(pero no requiere ni ordena) un proceso conducido por casos de uso, centrado en la
arquitectura, reiterativo, e incremental que sea orientado al objeto y basado en
componentes:
• Los Casos de Uso se emplean para administrar y proveer de un enfoque a un

problema. Expresan interacciones entre los roles de los usuarios del sistema
(actores) y los subconjuntos de funcionalidad (casos de uso).
Pág. 2-18
• La arquitectura se utiliza para administrar la complejidad y mantener la

integridad, y se enfoca como una solución a un problema que evoluciona.
• Las iteraciones y los incrementos se usan repetidamente en la aplicación de

un proceso para evolucionar hacia una solución al problema.
El ciclo de vida para UML consiste en una serie de ciclos cada uno de los cuales
produce una nueva versión del producto, es decir, se basa en la evolución de
prototipos ejecutables. Cada ciclo está compuesto por fases y cada una de estas
fases está compuesta por un número de iteraciones.
Fases
Actividades
Estudio de Elaboración Construcción Transición
oportunidad
Requisitos
Una iteración en la
fase de elaboración
Análisis
Diseño
Implementación
Pruebas
Iteración(es) iter. iter. iter. iter. iter. iter. iter.

Preliminar(es) #1 #2 #n #n+1 #n+2 #m #m +1
Figura 2-13. Proceso de desarrollo.
Tal y como refleja la Figura 2-13, las fases son las siguientes:
Estudio de oportunidad: Se define la funcionalidad y capacidades del

producto.Elaboración: Tanto la funcionalidad como el dominio del problema
se estudian en profundidad, se define una arquitectura básica y se planifica
el proyecto considerando los recursos disponibles.Construcción: El producto
se desarrolla a través de iteraciones, y cada iteración involucra tareas de
análisis, diseño e implementación. La arquitectura básica de las fases de
estudio y análisis se refina de manera incremental conforme se construye
(se permiten cambios en la estructura), se programa y prueba, y se
documenta tanto el sistema construido como el manejo del
mismo.Transición: El producto se entrega al usuario. También se incluyen
tareas de marketing, instalación, configuración, soporte, mantenimiento,
etc., así como de finalización de los manuales de usuario. Por supuesto,
Pág. 2-19
estas tareas se realizan en iteraciones.En cada iteración se reproduce el ciclo

de vida en cascada (a menor escala) para acometer los objetivos que se establecen
en función de la evaluación de las iteraciones precedentes.Cada iteración se basa
en la construcción de un número reducido de escenarios que se centran primero en
los riesgos más importantes y determinan las clases y las categorías a construir en
dicha iteración. Cada iteración comprende:
• Planificar la iteración (estudio de riesgos).
• Análisis de los Casos de Uso y escenarios.
• Diseño de opciones arquitectónicas.
• Codificación y pruebas. La integración del nuevo código con el existente de

iteraciones anteriores se hace gradualmente durante la construcción.
• Evaluación de la entrega ejecutable (evaluación del prototipo en función de

las pruebas y de los criterios definidos).
• Preparación de la entrega (documentación e instalación del prototipo).
Finalmente, insistir de nuevo en que UML, al ser un lenguaje de modelado y no un

método, consiste en una notación principalmente gráfica, que cualquier método
puede emplear para expresar su diseño.
2.1.3.3 Carencias de UML 1.4
Una de las razones de la rápida extensión en los últimos años del lenguaje de
modelado UML es su gran capacidad expresiva. UML dispone de potentes recursos
expresivos que le permiten describir sistemas provenientes de ámbitos muy
diversos. En esta generalidad del estándar radica su flexibilidad y capacidad de
adaptación, pero también es ésa una de sus debilidades. Un lenguaje genérico
proporciona un punto inicial común para la descripción de todo tipo de sistema,
pero ese lenguaje único no puede abordar la descripción detallada de sistemas muy
diferentes entre sí, para ello se requiere de capacidades expresivas especializadas,
y no genéricas. Por tanto, UML se consolidará como estándar universal para el
modelado en la medida en la que sea capaz de conjugar una gramática genérica
con unas capacidades expresivas especializadas y extensibles para cubrir el
modelado detallado de cualquier sistema.
Tal y como muestran las investigaciones de otros autores (Egyed 2000), UML 1.4
no ha logrado aún solucionar satisfactoriamente el objetivo de aunar lo genérico y
lo particular bajo un mismo lenguaje de modelado estándar. Aunque próximas
versiones prometen avanzar más en esta línea, los mecanismos de creación de
perfiles estándar (estereotipos y tagged values) y las reglas OCL (Object Constraint
Language) no han satisfecho todas las expectativas.
Pág. 2-20
Por ello, se ha planteado el uso de complementos a UML como los lenguajes ADL
(Architecture Description Language). Son lenguajes especializados en problemas
concretos y, por tanto, muy potentes en el análisis y simulación de esos casos. La
creación de perfiles UML basados en ADLs permite aumentar la capacidad de
análisis específico, ya que los ADL cumplen en pequeños nichos especializados lo
que se espera que UML pueda llegar a cumplir en el futuro de manera genérica
(modelado, análisis, validación).
Aún así, las inconsistencias expresivas que permite el propio núcleo de UML hacen
que la extensión a través de perfiles no deje de ser un parche. UML puede verse
como una colección de vistas gráficas débilmente integradas, lo cual facilita su
generalidad, pero permite la existencia de incoherencias entre vistas, posibilitando
que el modelo total sea incoherente, no válido o formalmente incorrecto. Algunas
de las potenciales inconsistencias que se han detectado son las siguientes (Egyed
2000):
• Inconsistencia entre clases de diferentes niveles (ver Figura 2-14). La

representación de diferentes niveles de abstracción no se basa en un
formalismo. Simplemente se usan diferentes diagramas en los que algunas
clases coinciden, pero no existe una comprobación formal de la coherencia de
las relaciones y dependencias expresadas.
• Inconsistencia entre clase y diagrama de secuencia (ver Figura 2-15). Se

permiten en el diagrama de secuencia llamadas a métodos que el diagrama de
clases prohíbe.
• Inconsistencia de cardinalidad (ver Figura 2-16). No se comprueba que se

respete la cardinalidad expresada en un diagrama de clases.
• Inconsistencia entre estado y diagrama de secuencia (ver Figura 2-17).
Pág. 2-21
Figura 2-14. Inconsistencia entre niveles.
Figura 2-15. Inconsistencia entre clase y diagrama de secuencia.
Pág. 2-22
Figura 2-16. Inconsistencia de cardinalidad.
Figura 2-17. Inconsistencia entre estado y diagrama de secuencia.
Cada vista supone una representación del sistema manejable desde el punto de
vista de uno de los individuos interesados, una descripción parcial del modelo en el
contexto de un individuo. El conjunto de todas las vistas debería representar un
modelo coherente y sin contradicciones, pero no es así debido a que existen
“agujeros” entre el conjunto de vistas UML y el modelo formal que pretenden
representar. Estos agujeros se pueden presentar en la forma de inconsistencias
Pág. 2-23
dentro de una misma vista, entre vistas de igual tipo o entre vistas de diferente
tipo.
Estas inconsistencias potenciales son fruto de la generalidad y riqueza expresiva

que persigue UML. “Podrían” ser capturadas por el diseñador (Boehm 1989 recoge
técnicas manuales de validación y verificación), pero no son captadas
automáticamente, por lo que inhabilitan a UML como el punto de partida de un
procesado formal y automático de la información. La resolución de este problema
supondría, entre otras cosas, la comprobación de coherencia entre los diagramas
estructurales y los de comportamiento, el soporte de mecanismos formales para la
definición de niveles de abstracción y la comprobación de coherencia entre las
abstracciones y los niveles inferiores en cuanto a cardinalidad, relaciones y
dependencias.
En resumen, el Metamodelo UML se muestra deficiente en el chequeo automático

de consistencia y en la transformación automática de información entre vistas.
Precisamente, y como se describe en el apartado 2.2, esas dos funcionalidades son
dos puntos fuertes de XML gracias al uso de Schemas y al lenguaje de
transformación XSLT.
Pág. 2-24
2.1.4 ESTÁNDARES OMG

OMG, Object Management Group (www.omg.org) es un consorcio que agrupa a
unas 800 compañías y trabaja en el desarrollo de arquitecturas (basadas en
objetos) para la integración de aplicaciones distribuidas. Trata de obtener
consensos amplios para generar especificaciones libres que luego las empresas
implementen. OMG produce estándares abiertos para todos los aspectos de la
computación distribuida; desde el análisis y diseño, pasando por la infraestructura y
hasta la aplicación de objetos y componentes en plataformas middleware definidas
virtualmente.
OMG plantea con MDA (Model Driven Architecture, www.omg.org/mda/) un

conjunto de estándares aplicables a la integración de información a partir del
modelado de la misma. MDA se convierte en la arquitectura marco para todas las
especificaciones presentes y futuras de OMG. De momento, relaciona y da un
sentido global a especificaciones como UML, MOF y XMI (que se describirán en los
siguientes apartados).
Este conjunto de estándares pueden jugar un papel importante en la expresión

explícita de los modelos que manejen las herramientas a integrar y en la
descripción de las relaciones entre ellos.
2.1.4.1 Model Driven Architecture (MDA)
Los proyectos de SW hoy en día raramente son de desarrollo puro, se reutilizan

módulos previamente desarrollados, SW libre y componentes del mercado. Además,
se emplean variedad de Sistema Operativos, lenguajes, tecnologías, tipos de
aplicaciones y middlewares1. En definitiva, se trata de sistemas heterogéneos y
poder integrar todas estas piezas precisa de una especificación formal y de alto
nivel de la ‘lógica de negocio’ de la empresa. La consecución de la integración de
las aplicaciones propias de una empresa para facilitar la reutilización,
mantenibilidad, adopción de nuevos estándares y tecnologías del SW es uno de los
retos actuales, y la proliferación de APIs uno de los problemas a resolver.
A este respecto, la primera aproximación de OMG pretendía establecer una serie de

estándares orientados a objeto, conocidos en conjunto como OMA (OMG’s Object
Management Architecture), para desarrollar aplicaciones distribuidas en entornos
heterogéneos. El corazón de su solución era CORBA, que definía cómo la
información que partía de un cliente era traducida desde el lenguaje que empleara
éste a un lenguaje intermedio común IDL (Interface Definition Language), de forma
que en el destino se tradujera de IDL al lenguaje particular empleado por el
1
Middleware. SW para comunicar una aplicación con la red en un sistema distribuido o para
comunicar aplicaciones diferentes tanto en función como en plataforma de ejecución
Pág. 2-25
destinatario. La intención de OMG era que se generalizara el uso de CORBA y que

sustituyera a otros middlewares, pero tuvo un éxito relativo. DCOM (Microsoft), RMI
(Remote Method Invocation de Sun) ó XML y SOAP (Simple Object Access Protocol)
sobre Internet se han constituido en alternativas a CORBA como solución
middleware. Las compañías necesitan integrar (además de SO, lenguajes, bases de
datos y redes) tecnologías antiguas y nuevas para el middleware, por lo que no son
habituales las arquitecturas ‘puramente CORBA’.
OMG rediseña su estrategia y nace MDA (Millar y Mukerji 2001), que se convierte
en la arquitectura base para sus estándares desde septiembre de 2001. MDA unifica
los espacios del modelado y del middleware (no necesariamente CORBA) y permite
mantener el SW desarrollado, adaptarlo y añadirle nuevas tecnologías y productos
COTS.
Se opta por una arquitectura más genérica, un mayor nivel de abstracción. Se

enfatiza la forma en la que el sistema debería ser integrado, independientemente
de las tecnologías que vayan a emplearse en su implementación. Es una
arquitectura basada en modelos porque esta es la única forma de cubrir los
requisitos adaptándose a los cambios tecnológicos venideros de forma controlada.
Pero no sólo indica cómo crear esos modelos sino que facilita los pasos desde el
modelo hasta el código final gracias a un conjunto de estándares que permiten este
mapeo y que se van adaptando a las tecnologías. Una especificación completa MDA
consta de:
Un PIM (Platform Independent Model) o Modelo Independiente de la

Plataforma expresado en UML. Este modelo debe recoger la funcionalidad y el
comportamiento deseado, independientemente de las técnicas y tecnologías
que se empleen en su implementación. De este modo, no es necesario repetir
el proceso de modelado cada vez que se introduzca una nueva tecnología o
sistema.
Uno o varios PSM (Platform Specific Model) o Modelo Específico de Plataforma.

Este modelo completa al PIM especificando cómo toma forma el sistema al ser
implementado en una plataforma determinada. Los conceptos abstractos del
PIM se detallan y describen de forma acorde a los recursos de la plataforma
elegida.
Conjuntos de definiciones de interfaces que describen cómo se implementa el

modelo base en diferentes plataformas middleware. Se precisará de tantos
interfaces como plataformas decida soportar el desarrollador.
El mapeo desde PIM (y a través de PSM) a una plataforma soportada por MDA está
definido en las especificaciones OMG, y por tanto, implementado por herramientas
que facilitan la tarea.
La descripción del PIM se hace en UML (otro estándar de OMG) porque se muestra
como el candidato ideal:
Pág. 2-26
9 variedad de representaciones para la expresión de todos los aspectos

relevantes: casos de uso y diagramas de actividades para especificación de
requisitos, diagramas de clases y objetos para el diseño, diagramas de
paquetes y subsistemas para el desarrollo, etc
9 amplia difusión, se ha convertido en un estándar para el modelado de SW
9 madurez tecnológica, está a punto de aparecer la versión UML 2.0
9 modelado independiente de lenguajes de programación, no está ligado a IDL

como CORBA
9 válido para generar cualquier conjunto de APIs a diferentes middlewares a

través de perfiles específicos
Para dar coherencia global a la arquitectura MDA surgen otros estándares como:
MOF (Meta Object Facility). Meta-modelo o marco genérico estándar para la

definición de modelos de datos en general, y de UML en particular. Permite a
los modelos UML ser intercambiados entre herramientas y repositorios. MOF
asegura que cada uno de los tipos de modelo UML se defina de forma
consistente. Por ejemplo, que una clase de un diagrama de clases tenga una
relación precisa con una actividad o con un caso de uso. Cada diagrama UML es
realmente una ‘vista’ del meta-modelo UML subyacente recogido en MOF.
XMI (XML Metadata Interchange). Estándar que permite expresar en forma de

fichero XML cualquier modelo (o meta-modelo) definido en MOF. Esta facilidad
para la serialización o disposición en forma de flujo de datos (o meta-datos)
ofrece un formato adecuado para intercambiar entre diferentes herramientas
aquella información cuya semántica ha sido expresado en MOF.
CWM (Common Warehouse Metamodel). Es un meta-modelo de bases de

datos. Estandariza las bases para el modelado de los datos comunes a una
organización, de forma que se habilite el sencillo intercambio de meta-datos
independientemente de su forma de almacenamiento físico.
Pág. 2-27
Figura 2-18. Estrategia general MDA.
Las relaciones entre todos estos estándares (Figura 2-18) serán reforzadas y
dotadas de mayor consistencia a través de las acciones futuras que planifica OMG
(llevadas a cabo por ‘task forces’):
Definir IDL CORBA, CORBA, UML y CWM como modelos acordes con MOF, es
decir, definirlos en los términos de MOF. Esto implica:
○ Podrá generarse IDL a partir de un modelo MOF.
○ Se redefinirá CORBA en un modelo abstracto UML (en lugar de usar IDL)

acorde con MOF. Así, se permitirá a una herramienta convertir
automáticamente un diagrama UML en código IDL, en virtud del mapeo
MOF-IDL.
○ Se asegurará la coherencia y la posibilidad de ampliación de los diagramas

UML.
○ Podrán ser implementadas de forma consistente en cualquier sistema las

bases de datos cuyos modelos estén expresados en CWM.
Lanzar UML 2.0 con modificaciones como:
○ Extensiones a través de perfiles. Nuevos elementos de representación,

acordes con evoluciones MOF y UML, que permiten traducir diagramas UML
Pág. 2-28
en código, así como dar soporte a una ingeniería inversa consistente. Se han
generado perfiles para CORBA e IDL.
○ OCL (Object Constraint Language) refinado para dotar de semántica de

comportamiento (acción) a UML (aparte de la estructural)
Actualizar y perfeccionar XMI evolucionando en paralelo con MOF y UML. Así,

herramientas que soporten UML 2.0 (con XMI) podrán trasladar via internet
diagramas UML entre aplicaciones e información entre bases de datos.
De cara a los servicios que obtiene el desarrollador de aplicaciones, la filosofía MDA

puede resumirse así:
1. Las compañías crean descripciones (PIM), en un alto nivel de abstracción, de

la lógica de las aplicaciones y de cómo serán estructuradas e integradas
(middleware que las comunique) independiente de detalles de
implementación.
2. Estas descripciones se extienden y detallan para cada plataforma (PSMs).
3. Los diseños PSM se convierten en código para las plataformas específicas

seleccionadas. La coherencia que MOF impone a todos los estándares
permite llegar finalmente a la generación automática de código desde una
descripción totalmente gráfica. Aún más, se soportaría la ingeniería inversa
porque cambios en el código podrían usarse para modificar el diagrama UML
en el PSM apropiado.
En definitiva, el PIM de la empresa sería válido durante muchos años a pesar de la

aparición de nuevas tecnologías y cambios en APIs y middlewares. OMG se ocupará
de crear nuevos perfiles que generen automáticamente los APIs para las nuevas
tecnologías que vayan surgiendo.
2.1.4.2 Meta Object Facility (MOF)
Meta-modelo estándar o marco genérico para la definición de modelos de datos en

general, y de UML en particular. Así, todos los modelos expresados en UML se
generarán a partir del meta-modelo MOF, este origen común permitirá el
intercambio de modelos entre aplicaciones (a través de XMI). Empresas como IBM,
Oracle y Sun están empleando MOF para asegurar que sus productos pueden
intercomunicarse. MOF proporciona una jerarquía que permite representar
información a niveles de abstracción mayores progresivamente. La relación entre
cualesquiera dos niveles es la misma que existe entre una clase y un objeto o entre
un schema y un documento XML (como se verá en el apartado 2.2.3).
Al mismo tiempo, y aunque resulte un poco confuso, un subconjunto de elementos

UML (junto con lenguaje natural) se emplea para definir MOF porque se considera
el mejor sistema de modelado.
Pág. 2-29
MOF describe los conceptos empleados para construir modelos para aplicaciones
concretas. Por otra parte, también define un repositorio para meta-modelos y
modelos. Esto permite almacenar los modelos UML de manera formal, así como
definiciones de tipos de datos empleados en aplicaciones concretas.
Con el mapeo de MOF a CORBA IDL se definen interfaces que permiten al cliente
crear, acceder o cambiar la información descrita por el modelo. Se maneja la
información pero se mantiene la consistencia estructural y lógica, y los requisitos
establecidos en el modelo de información
MOF puede entenderse desde dos puntos de vista:
Punto de vista del modelado. El diseñador (mirando desde niveles altos de

abstracción hacia abajo) usa MOF para definir un modelo de información para
un dominio de interés concreto. Esta definición se emplea para dirigir
posteriormente el diseño o la implementación del SW ligado a ese modelo de
información.
Punto de vista de los datos. El programador (mirando desde la concreción de

la información hacia meta-niveles superiores) usa MOF para manejar la
información de acuerdo a los dictados del meta-modelo.
Los conceptos modelados por MOF son: clases (representación de metadatos,

meta-objetos MOF, contienen atributos, operaciones y referencias), asociaciones
(relaciones binarias entre meta-objetos), tipos de datos no objetos (tipos de datos
primitivos, externos,...), paquetes (modularizan los modelos) y requisitos o
constraints.
En MOF, como en UML, se emplea OCL (Object Constraint Language) para expresar
requisitos adicionales sobre los datos. Un requisito se compone de nombre,
lenguaje, expresión, política de evaluación y conjunto de elementos implicados.
En MOF se definen los siguientes niveles de abstracción (Figura 2-19):
○ M0. Información a modelar
○ M1. Modelos UML. Interfaces IDL. XMI permite leer y escribir documentos
XML desde aquí
○ M2. Metamodelos UML. Metamodelos IDL. XMI genera DTD o Schema desde
aquí
○ M3. Modelo MOF
Donde el nivel inferior M0 puede alinearse con aquella entidad que se pretenda
modelar. Si se pretende modelar una base de datos, M0 estará constituido por la
información a almacenar; si se modelan las aplicaciones diseñadas por una
empresa, M0 estará constituido por casos concretos de aplicaciones, etc.
Pág. 2-30
Figura 2-19. Niveles de abstracción MOF.
Se está trabajando en alinear los niveles de abstracción de UML 2.0 y MOF 2.0 para
ciertos propósitos, como pueda ser el empleo de UML como lenguaje para
representar modelos MOF. Aunque MOF suponga un nivel de abstracción mayor la
diferencia no importa si no se usan múltiples niveles de abstracción. Si las
aplicaciones intercambian información en un nivel de abstracción definido por un
modelo basta con UML.
2.1.4.3 XML Metadata Interchange (XMI)
XMI puede definirse como el formato para la serialización (disposición en forma de

flujo) de meta-datos acordes con MOF. XMI permite intercambiar meta-datos MOF
(incluidos los modelos UML) entre diferentes herramientas, al expresarlos en forma
de documento XML. XMI, por estar basado en MOF, permite expresar información
en cualquiera de los niveles de abstracción de la jerarquía MOF.
El flujo de XMI se modela con el conjunto de datos XML, por eso XMI también
constituye un mapeo de UML (y CWM) a XML. MDA hará uso de XMI cuando se
defina el mapeo de un PIM a plataformas basadas en XML.
XMI está limitado en el sentido de que se preocupa de los conceptos que describen
el estado de los objetos, no el comportamiento. XMI sí puede ser empleado para
guardar todas las partes de un modelo UML pero al salvar una instancia de una
clase UML se guardan sólo los valores de las características estructurales.
XMI es necesario porque XML no es orientado a objeto. Por tanto, existe más de un
modo de mapear objetos a XML y se requiere de un estándar. XMI elige uno de los
posibles mapeos y lo estandariza. Para intercambiar objetos entre aplicaciones, que
en principio pueden estar escritas en diferentes lenguajes de programación, es
necesario:
1. Definir qué es un objeto de forma inequívoca e independiente de cualquier

lenguaje de programación.
Pág. 2-31
2. Mapear (traducir) de forma biunívoca2 y estándar el objeto desde su

representación independiente a su representación particular en cada uno de
los lenguajes destino. De esta forma, si un objeto se traduce a varios
lenguajes y, de estos, se retorna a la representación original, en todos los
casos el resultado debería ser el mismo.
UML resuelve la primera parte del problema, pues ofrece una definición y
representación independiente de objeto. En cuanto a la segunda parte, XML parece
ser la solución porque ofrece un formato estándar para la representación de
información, sin embargo, no supone de por sí un mapeo biunívoco para los
objetos.
Doc API
XML
XML
Elementos Código Objetos
XML propio aplicación
Doc SW
XMI
XMI
Objetos
aplicación
Figura 2-20. Mapeo con APIs XML y con XMI.
Tal y como muestra la Figura 2-20, un documento XML se descompone en sus

elementos gracias a SW que se apoya en un API. Con código propio del
desarrollador se consigue una representación acorde con la aplicación. El camino
inverso también consta de dos pasos. A pesar de existir APIs estándar (SAX,
DOM,…) para diferentes lenguajes de programación, éstos no dejan de ser
colecciones de funciones que facilitan el trabajo, pero la traducción sigue estando
en manos del desarrollador y el resultado dependerá de las decisiones que tome.
Por esta razón, la relación no es biunívoca ya que diferentes desarrolladores
2
Se dice de la correspondencia matemática que asocia cada uno de los elementos de un conjunto con
uno, y solo uno, de los elementos de otro conjunto, y cada elemento de este último con uno, y solo uno,
de los elementos de aquél.
Pág. 2-32
tomarán diferentes decisiones en la traducción. XMI soluciona esta situación porque

provee de un mapeo estándar de objetos definidos en UML a elementos XML, de
diagramas de objetos a documentos XML y de modelos UML a schemas. XMI crea
automáticamente el código de transformación, por ello, aplicaciones que usen XMI
pueden intercambiar objetos entre sí. XMI también se apoya en APIs estándar. Sin
embargo, su uso es escondido al desarrollador para conseguir que la traducción no
dependa de sus decisiones.
A modo de ejemplo, algunas de las cuestiones que resuelve XMI de manera

estándar, no dejándolas al libre albedrío del desarrollador son las siguientes:
generación de identificador único local (en el documento) y global, mecanismos de
herencia, referencias locales (entre elementos de un mismo documento) o globales
(XLink), asociación de namespaces al ámbito de paquetes UML, extensiones
estándar para añadir información propia de aplicaciones, generación estándar de
schemas desde modelos UML, inclusión de documentación de usuario, etc (Grose et
al 2002).
Sin embargo, XMI no pretende suponer un corsé para los programadores y ofrece
margen de maniobra en algunas cuestiones. Aunque existe un modo estándar por
defecto de expresar las cosas, que será el preferido cuando se busque
compatibilidad entre aplicaciones, también se puede afinar la generación
automática de código XMI para modular cuestiones como el mapeo opcional de
atributos UML a elementos ó atributos XML o el uso de tagged values para
personalizar la creación automática de schemas.
El uso de XMI se puede integrar en el proceso de creación de SW de forma acorde a

la estructura MDA. Dentro del ciclo de vida, XMI puede estar presente en las
siguientes labores:
Creación de Schema XMI a partir de modelo UML. Será necesario si se usa la

validación porque la fuente externa de ficheros XMI no es necesariamente
fiable o porque el sistema es poco tolerante a fallos en los datos de entrada.
Generación de código para manejar datos con ese modelo UML. El código
generado está personalizado para un modelo. Se generará por completo
cada vez que cambie el modelo.
Implementación de la aplicación. Al menos una parte de la aplicación habrá

que generarla a mano pero existe un modo estándar de generar código Java
de modelos MOF: JMI (Java Metadata Interface). JMI describe la generación
de interfaces que permiten la creación de instancias del modelo MOF y la
carga y serialización de ficheros XMI para esas instancias.
Para los casos en los que no se utilicen herramientas de generación automática de

código a partir de modelos UML, también existen APIs específicas para XMI:
• JOB (Java Object Bridge) permite almacenar objetos Java en documentos

XMI y a la inversa.
Pág. 2-33
• XMI Framework proporciona una representación genérica de objetos y sus

estados en un modelo simple y permite crear documentos XMI a partir de
objetos genéricos y a la inversa. La salida es un stream asociable a un
fichero, a un fichero ZIP o a una conexión de red.
Cabe hacer un comentario al respecto del nivel de abstracción con el que se vaya a
usar XMI. XMI permite el intercambio de metamodelos, modelos o datos en formato
XML, pero según la naturaleza de la información intercambiada se distingue una
arquitectura de tres ó cuatro niveles:
Intercambio de metamodelos ó modelos. Se emplea una arquitectura de

cuatro niveles (MOF / metamodelo / modelo / datos), donde MOF es un
meta-metamodelo ó un modelo de metamodelos. XMI regula, por una parte,
el mapeo de metamodelos (definidos según MOF) y Schemas, y por otra
parte, entre modelos (que tengan a MOF como meta-metamodelo) y
documentos XML.
Intercambio de datos. Arquitectura de tres niveles (MOF / modelo / datos).

Para poder emplear XMI, se necesita que el modelo de datos empleado se
haya definido de acuerdo a MOF, es decir, se toma MOF como metamodelo
de datos. En este caso, XMI permite mapear los modelos (diagrama de
clases) a Schemas y los datos (diagrama de objetos) a documentos XML.
En resumen, se pueden enumerar los siguientes beneficios del uso de XMI:
9 Representación estándar de objetos XML, habilitando el intercambio efectivo

de objetos entre aplicaciones.
9 Generación automática de schemas, código y documentación a partir de

modelos UML.
9 Creación de documentos simples que van avanzando según la aplicación

evoluciona.
9 Uso de XML sin necesidad de conocerlo a fondo (esconde las complejidades

del manejo de documentos XML) o posibilidad de usar los conocimientos en
XML para personalizar el uso que se hace de XMI.
9 Permite el modelado con XML incluyéndolo en la estructura del MDA.
9 Permite el trabajo con datos y con metadatos. Por estar relacionado con
MOF y poder estar éste alineado en diferentes niveles de abstracción.
Pág. 2-34
2.1.5 UML 2.0

La versión 2.0 de UML viene acompañada de nuevas versiones de los estándares
MOF (Meta Object Facility), XMI (XML Metadata Interchage) y OCL (Object
Constraint Language). Es un intento de coordinación general de varios estándares
para dar un soporte más formal y completo a la filosofía general de MDA (Model
Driven Arquitectura), tal y como se ha avanzado en el apartado 2.1.4.1.
Concretamente, MOF 2.0 da soporte al núcleo de UML y permite la creación formal
de un número indeterminado de niveles de abstracción. XMI 2.0 permite la
serialización automática de los modelos UML en forma de ficheros XML y de los
metamodelos en forma de XML Schemas. Está recomendado su uso para el
intercambio estándar de información entre herramientas UML y para el
almacenamiento de los modelos en repositorios XML.
Mientras que UML 1.4 tenía como objetivo principal la respuesta a las necesidades
clásicas de la industria del SW, UML 2.0 se plantea cubrir otros campos como el
modelado de negocio, de sistemas de tiempo real, basado en componentes, etc. El
mecanismo estándar para extender las capacidades de UML a cada uno de estos
campos específicos es el de los perfiles y este mecanismo se ve mejorado en la
nueva versión. En general, se mejora la escalabilidad y usabilidad del lenguaje en
todos los ámbitos.
Características generales de UML 2.0:
Simplificación de la sintaxis y semántica del lenguaje.
Alineación formal con MOF.
Soporte del modelado de la arquitectura SW y del modelado basado en

componentes, lo que conlleva el uso de una nueva semántica:
○ Además de la semántica de comportamiento y datos propia de la orientación

a objetos, se expresan servicios e interfaces para desarrollar entidades
autónomas.
○ Concepto de puerto (punto de interacción entre clases) y de puerto de

comportamiento (configuración inicial de una clase, capacidad para crear y
borrar partes).
○ Descomposición jerárquica (bloques que se ensamblan formando bloques

mayores):
∗ La granularidad de una clase no está predefinida, puede estar

compuesta de otras clases.
Pág. 2-35
∗ Los conectores difieren de las asociaciones en que dependen del

contexto, mientras que las asociaciones son válidas en todos los
contextos.
∗ Haciendo “zoom out” sobre una estructura interna aparece la vista de

“caja blanca” de una clase.
∗ Desarrollo bottom-up y top-down.
Se refina el modelo de desarrollo y el de proceso, gracias a la mejora de los

diagramas de actividad, de interacciones y máquinas de estados.
Nuevo mecanismo de extensión para añadir metaclases propias y mejorar así la

definición de perfiles.
Soporte de arquitecturas en tiempo de ejecución para modelar flujo de datos y

objetos entre diferentes partes del sistema.
Mejor representación de las relaciones.
Mejor modelado de comportamiento con encapsulado y escalabilidad.
Modelos ejecutables (nueva semántica de acción):
○ Capacidad para definir puntos de entrada y salida de un estado compuesto.
○ Capacidad para expresar un bloque de acción.
○ Semánticas de acciones de ejecución (el modelo es independiente del

lenguaje destino). OCL (Object Constraint Language) refinado para dotar de
semántica de comportamiento (acción) a UML (aparte de la estructural).
UML 2.0 promete convertirse en una solución general, haciendo innecesario el uso
de extensiones de su metamodelo para tratar los problemas específicos de
dominios específicos.
Pág. 2-36
22..22 L
LEEN
NGGU
UA ESS F
AJJE FOOR
RMMA
ALLE
ESS
Sobre la teoría de los lenguajes formales y su implementación a través de

EBNF y XML.
En función de su grado de formalidad, las notaciones o lenguajes se pueden

clasificar en (McDermid 1993):
Notaciones Informales: Uso de diagramas imprecisos complementados con

lenguaje natural. Tienen la ventaja de ser legibles para muchos pero las
interpretaciones de los mismos son diversas.
Notaciones Estructuradas: Empleo de diagramas bien definidos que

establecen conexiones entre un conjunto de componentes predefinidos de
antemano. A veces se ligan estas descripciones gráficas a representaciones
sintácticas en un lenguaje bien definido. Estas notaciones no permiten dar
soporte al análisis ni a la manipulación automática.
Notaciones Formales: Eliminan interpretaciones equívocas, permiten la

realización de análisis y la manipulación automática y dan soporte a la
validación (prueba de la existencia de propiedades necesarias) de la
información.
De lo descrito sobre UML 1.4 se puede deducir que encajaría en la categoría de

Notaciones Estructuradas. De alguna forma, se sacrifica la formalidad de la notación
para obtener una mayor capacidad expresiva que permite a UML ser utilizado para
modelar un amplio abanico de sistemas. Se prioriza la capacidad expresiva sobre la
capacidad de validación formal de la información expresada. Si la validación formal
fuera un requisito importante, habría que elegir otro lenguaje, actualizar el
metamodelo UML con mayor soporte formal (objetivo de UML 2.0) o usar UML en
conjunto con otra notación formal que lo complemente.
Las propiedades atribuidas a las Notaciones Formales se han identificado como

necesarias para el entorno multidisciplinar en el capítulo inicial. Interesa su empleo
para poder validar las representaciones del SCDTR acordes con cada uno de los
metamodelos. Por ello, en este apartado se describirá EBNF como una gramática
adecuada para la definición de notaciones formales y se repasarán los fundamentos
de XML, metalenguaje formal basado en reglas EBNF. En principio, se repasan las
definiciones de algunos conceptos clave para el análisis posterior de lenguajes.
Pág. 2-37
2.2.1 ALGUNAS DEFINICIONES

Un lenguaje, en sentido amplio, no es sólo un listado de palabras (léxico), tiene
asociada una sintaxis (reglas sobre las combinaciones posibles de términos;
taxonomía o clasificación y jerarquía de los términos). Aún más, es deseable
compartir una ontología (exhaustivo y riguroso esquema conceptual dentro de un
dominio dado, en orden a facilitar la comunicación y el uso compartido de la
información) entre todos los sistemas que vayan a utilizar ese lenguaje.
En el párrafo anterior aparecen varios términos, relacionados con el lenguaje, cuyo

significado es preciso conocer para profundizar en la teoría de los lenguajes
formales. Por eso, este apartado pretende establecer el vocabulario base que se
emplee en explicaciones posteriores a lo largo de la memoria. Las siguientes
definiciones han sido extraídas de FOLDOC (Free On Line Dictionary Of Computing,
http://foldoc.doc.ic.ac.uk), Wikipedia (www.wikipedia.org), Aho et al (1986) y
Hopcroft et al (2000).
Gramática:
Definición formal de la estructura sintáctica de un lenguaje, normalmente dada en

forma de reglas de producción, que especifican el orden de los componentes en una
sentencia o cadena bien formada en ese lenguaje.
Cada regla tiene a la izquierda un símbolo que designa una categoría sintáctica y a
la derecha una secuencia de uno o más símbolos. Cada símbolo puede ser a su vez
terminal o no-terminal. Un símbolo terminal (lexema) es una parte de la
sentencia sin estructura sintáctica interna (por ejemplo, un identificador o un
operador). Un símbolo no-terminal es la parte izquierda de alguna regla. Por
ejemplo, a continuación se presentan dos reglas de la gramática EBNF, que definen
cómo es un comentario en XML:
Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] |[#x10000-#x10FFFF]

Comment ::= ''
La primera regla define Char como uno de los caracteres definidos por un número
hexadecimal acorde con Unicode. Los tramos válidos se expresan entre corchetes y
el símbolo ‘|’ representa un OR lógico. La segunda regla describe Comment como
una cadena ‘<!- -‘, seguida de un número indefinido de ocurrencias Char excepto el
‘-‘ ú ocurrencias ‘-‘ y un carácter distinto de ‘-‘, y terminado por la cadena ‘-->’. Es
decir, no puede haber dos guiones seguidos dentro del comentario.
Normalmente, una regla es designada como la de mayor nivel en el contexto de la

sentencia, y ésa define la estructura de la sentencia. Una gramática puede ser
empleada para analizar sintácticamente una sentencia (fase que suele precederse
de un análisis léxico) o para generarla. La generación comienza por la regla de
máximo nivel y se va eligiendo entre las producciones alternativas en cada caso.
Pág. 2-38
Sintaxis:
Parte de la Gramática que estudia la ordenación y relaciones mutuas de las

palabras en la oración y el enlace de unas oraciones con otras. Descripción de las
estructuras válidas que pueden adoptar los símbolos de un lenguaje. Describe cómo
los símbolos pueden ser combinados, independientemente de su significado. El
significado de un lenguaje viene dado por la semántica.
Sintaxis abstracta. Una representación de datos (típicamente un mensaje

transmitido por un enlace de comunicación o un programa siendo compilado) que
es independiente de la implementación (codificación, estructuras orientadas a la
máquina o representación física de los datos). Se define por oposición a sintaxis
concreta (en compilación) ó sintaxis de transferencia (en comunicaciones).
La representación interna de un programa en un compilador es un ejemplo típico

que se especifica con una sintaxis abstracta. Esta expresión se hace en términos de
categorías como “sentencia”, “expresión” e “identificador”. Todo ello es
independiente de la sintaxis origen (sintaxis concreta) del lenguaje que se esté
compilando (aunque normalmente serán muy similares). Un árbol de análisis es
similar a un árbol de sintaxis abstracta, pero también tiene elementos como
paréntesis, significativos sintácticamente pero que están implícitos en la estructura
del árbol de sintaxis abstracta.
Parser (Analizador sintáctico):
Algoritmo o programa para determinar la estructura sintáctica de una sentencia o

cadena de símbolos en algún lenguaje. Normalmente, toman como entrada una
secuencia de lexemas producidos en un analizador léxico. Pueden producir algún
tipo de árbol de sintaxis abstracta como salida.
Un generador de parsers toma la descripción formal de una gramática, por

ejemplo en EBNF, y produce código fuente para un parser que reconoce sentencias
válidas según esa gramática y ejecuta acciones asociadas. YACC (Yet Another
Compiler-Compiler) es un generador de analizadores integrado en UNIX.
Análisis léxico:
Un flujo de caracteres (el de un programa) es leído carácter a carácter y agrupado

en lexemas: palabras clave, identificadores, literales (constantes) y signos de
puntuación. Los lexemas se pasan al parser para su análisis sintáctico.
Semántica:
Significado de un lexema o de una cadena para un determinado lenguaje. Una

misma cadena puede tener diferentes significados en diferentes lenguajes.
BNF (Backus-Naur Form):
Pág. 2-39
Metasintaxis (sintaxis para describir otras sintaxis) formal para expresar gramáticas
libres de contexto. Es una de las notaciones metasintácticas más empleadas para
especificar la sintaxis de los lenguajes de programación. EBNF es una extensión.
Lenguaje natural:
Lenguaje hablado o escrito por humanos, en oposición al usado para programar

(comunicación con ordenadores).
Metadatos:
Datos sobre otros datos. Datos orientados a la definición, información o

documentación sobre otros datos en un entorno concreto (aplicación,
comunicación). Los metadatos pueden incluir información sobre el contexto, calidad
y condición o características de los datos (nombre, tamaño, tipo, estructura,
localización, asociaciones, propiedades).
Lexema:
Unidad léxica mínima de un lenguaje. En un lenguaje de programación: palabras

clave, identificadores, literales y signos de puntuación.
ASN.1 (Abstract Syntax Notation 1):
Estándar ISO para transmisión de datos estructurados en redes. Define la sintaxis

abstracta de la información pero no restringe el modo en que la información es
codificada. El intercambio de información entre aplicaciones sobre una red se
facilita con ASN.1 junto con reglas específicas de codificación porque se describen
las estructuras de datos de forma independiente a la arquitectura de la máquina o
al lenguaje de implementación.
Símbolo:
Entidad abstracta que no se define formalmente (letras, dígitos).
Alfabeto:
Conjunto finito de símbolos.
Ontología (Informática):
El término ontología en informática hace referencia al intento de formular un

exhaustivo y riguroso esquema conceptual dentro de un dominio dado, en orden a
facilitar la comunicación y el uso compartido de información entre diferentes
sistemas.
Un uso común tecnológico actual del concepto de ontología, en este sentido, se

encuentra en la inteligencia artificial y la representación del conocimiento. En
algunas aplicaciones, se combinan varios esquemas en una estructura de facto
completa de datos, que contiene todas las entidades relevantes y sus relaciones
dentro del dominio.
Pág. 2-40
Los programas informáticos pueden utilizar así la ontología para una variedad de
propósitos, incluyendo el razonamiento inductivo, la clasificación, y una variedad de
técnicas de resolución de problemas. Típicamente, las ontologías en los
ordenadores se relacionan estrechamente con vocabularios fijos --una ontología de
fundacional -- con cuyos términos debe ser descrito todo lo demás. Debido a que
esto puede ocasionar representaciones pobres para ciertos dominios de problemas,
se deben crear esquemas más especializados para convertir en útiles los datos a la
hora de tomar decisiones en el mundo real.
Web Semántica:
La Web Semántica es una visión de futuro propuesta por Tim Bernes-Lee. Consiste
en construir una agrupación de documentos estructurada de forma que se facilite el
acceso y el rastreo automático de la información de un modo más coherente al que
hoy en día utilizan las herramientas de búsqueda web.
La consecución de estos objetivos se fundamenta en:
• Documentos marcados con información semántica. Se trata de extensiones

de las etiquetas <meta> que se emplean en la actualidad para ofrecer
información a los web crawlers que alimentan con información los motores
de búsqueda. Esta información sería legible por las máquinas (procesable
automáticamente) y podría tratarse de datos dirigidos al consumo humano
sobre el contenido del documento (autor, título, descripción) o podría
tratarse de metadatos (enlaces a recursos y servicios adicionales).
• Vocabularios de metadatos comunes (ontologías) y mapas entre los

vocabularios que permitan a los autores marcar los documentos para que los
agentes puedan usar la información contenida en los metadatos.
• Agentes automáticos para ejecutar tareas que empleen los metadatos para
dar servicio a los usuarios de la Web Semántica.
• Servicios basados en web para suministrar información específicamente a

los agentes.
Las tecnologías que permitirán poner en funcionamiento la Web Semántica serán:

URIs (Uniform Resource Identifier) para la identificación de recursos, XML
(eXtensible Markup Language) como lenguaje soporte de los documentos con
metainformación y los espacios de nombre (recogidos en XML Schema) para
distinguir diferentes vocabularios.
Pág. 2-41
2.2.2 EBNF
EBNF (Extended Backus-Naur Form) es una colección de reglas denominadas
producciones (Aho et al 1986). Toda regla describe un fragmento específico de
sintaxis. Un documento es válido si puede ser reducido, a través de la aplicación
repetida de reglas, a una única regla específica (sin lexema en su parte izquierda).
Ejemplo:
[1] Palabra ::= Consonante Vocal+ Consonante

[2] Consonante ::= [^aeiou]
[3] Vocal ::= [aeiou]
La regla 1 indica que una Palabra es una Consonante, seguida de una o más
Vocales y terminada por una Consonante. La regla 2 define Consonante como una
letra diferente de a, e, i, o, u. La regla 3 define Vocal como cualquiera de las letras
a, e, i, o, u.
Empleando las reglas del ejemplo se pueden realizar validaciones sobre instancias
concretas. Por ejemplo, ¿es ‘dos’ una Palabra?:
• ‘dos’ está compuesto por las letras ‘d’ ‘o’ ‘s’.
• según la regla 2, ‘d’ es una Consonante, por tanto dos: Consonante ‘o’
‘s’
• según la regla 3, ‘o’ es una Vocal, por tanto dos: Consonante Vocal ‘s’
• según la regla 2, ‘s’ es una Consonante, por tanto dos: Consonante

Vocal Consonante
• según la regla 1, ‘dos’ es una Palabra
Siguiendo el mismo análisis ‘seis’, ‘rey’ ó ‘diez’ son Palabras, pero ‘mesa’ ó
‘tres’ no lo son.
Aunque EBNF no es un modo eficiente para representar sintaxis para el consumo

humano, existen programas (metacompiladores) que pueden generar
automáticamente un analizador a partir de reglas EBNF. Esto hace que sea una
forma adecuada para representar la sintaxis de lenguajes destinados a ser
procesados (parseados) por un ordenador.
Pág. 2-42
2.2.3 XML
Uno de los logros más importantes en el diseño de XML (eXtensible Markup
Language) es hacerlo fácil de usar por las herramientas de compilación modernas.
Parte de este logro se fundamenta en la expresión de la sintaxis de XML en EBNF.
XML está definido con una gramática EBNF de 89 reglas. Aunque las reglas son más
complejas que las del ejemplo visto en el apartado anterior, el mismo tipo de
análisis permite a un parser XML determinar cuándo un documento XML es
sintácticamente correcto.
XML nació como un subconjunto de SGML (Standard Generalized Markup Language)

(ISO 8879). SGML es un estándar para mantener repositorios de documentación
estructurada. Tiene varios estándares asociados como Unicode e ISO/IEC 10646
para caracteres, Internet RFC 1766 para las etiquetas identificadoras de lenguaje,
ISO 639 para los códigos de nombre de los lenguajes e ISO 3166 para codificar los
nombres de los países.
Los documentos XML no son simples contenedores de información. Los datos

contenidos se organizan siguiendo una estructura jerárquica en forma de árbol. Las
unidades mínimas de información que componen éste árbol lógico son los
elementos. Siempre existe un único elemento raíz del que cuelgan otros
elementos hijos. Además, la información recogida en un elemento puede verse
complementada a través de los atributos (propiedades del elemento). Los
atributos pueden ser de diferentes tipos dependiendo de la naturaleza de la
información que vayan a expresar.
A continuación se muestra un documento XML:
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE AGENDA_TELEFONOS SYSTEM "G:\XML\agenda.dtd">
<AGENDA_TELEFONOS>
<FICHA>
<Nombre>Elisabeth</Nombre>
<Apellido1>Estevez</Apellido1>
<Apellido2>Estevez</Apellido2>
<Direccion>Maria Diaz de Haro, 3 Bilbao</Direccion>
<Telefono movil="si">610085498</Telefono>
</FICHA>
<FICHA>
<Nombre>Unai</Nombre>
<Apellido1>Gangoiti</Apellido1>
<Apellido2>Gutubai</Apellido2>
<Direccion>Pirata etorbidea, 13 Mungia</Direccion>
<Telefono movil="no">946875667</Telefono>
</FICHA>
Pág. 2-43
</AGENDA_TELEFONOS>
En este documento se aprecia como AGENDA_TELEFONOS es el elemento raíz del que

cuelgan todos los demás, concretamente cuelgan dos elementos FICHA y cada uno
de ellos a su vez está compuesto por instancias de los elementos Nombre,
Apellido1, Apellido2, Direccion y Telefono. Por último, se puede apreciar la
presencia de un atributo movil asociado al elemento teléfono (para indicar si el
número pertenece a un móvil o no). Cada uno de los elementos y atributos tiene un
contenido particular, pero siempre se respeta la estructura jerárquica en forma de
árbol que muestra la figura Figura 2-21.
Figura 2-21. Estructura en árbol del fichero XML.
La validación o comprobación formal de la sintaxis de un documento XML se puede

llevar a cabo a dos niveles: documento XML bien formado y documento XML
válido.
Un documento XML estará bien formado si respeta la estructura y sintaxis definidas

por la especificación XML. Las comprobaciones son las mismas para cualquier
documento XML porque todos ellos deben cumplir las 89 reglas EBNF que regulan el
lenguaje. El resumen de las comprobaciones que realiza el parser puede ser el
siguiente:
9 Los documentos XML deben seguir una estructura jerárquica en lo respectivo

a las etiquetas que delimitan la información, cada etiqueta debe estar
correctamente incluida en otra, y cada elemento con contenido cerrado con
la etiqueta adecuada.
9 Se permite un único elemento raíz del que cuelgan todo lo demás.
9 Los valores de los atributos están encerrados entre comillas.
9 XML es sensible a mayúsculas y minúsculas
9 Los espacios en blanco (espacio, tabulador, retorno de carro y salto de línea)

se usan para hacer más legible el documento pero no suelen ser tenidos en
cuenta por el procesador.
9 Existen un conjunto de restricciones para los identificadores.
Pág. 2-44
9 Todas las etiquetas o marcas deben ser entendidas por el procesador XML
(lo que no sean etiquetas serán datos) y empiezan por “<” acabando en “>”.
Como lenguaje para la representación de datos, XML (a diferencia de HTML) separa

totalmente el contenido, las reglas gramaticales y el formato de presentación. Es
decir, el documento XML contiene la información en ‘estado puro’. Las reglas
gramaticales que se deben cumplir en la expresión de está información las recoge
el estándar (aunque se pueden ampliar en un schema, como se verá a
continuación) y los diferentes formatos de presentación que se le apliquen al
documento están recogidos en hojas de estilo.
Aunque así lo sugiera su nombre, XML no es un simple lenguaje de marcado, es un

metalenguaje que permite definir lenguajes de marcado específicos para un uso
determinado. Los requisitos gramaticales adicionales que deberá cumplir el
documento XML escrito en el nuevo lenguaje se expresarán en un Schema. Un
schema recoge todas las restricciones léxicas y sintácticas que definen el nuevo
lenguaje, y es compartido por todos los documentos XML que sean expresados en
ese lenguaje.
Un documento XML será válido si, además de estar bien formado, respeta la
estructura y restricciones que le imponga su schema asociado. En resumen, el
parser XML debe comprobar los siguientes aspectos para determinar como válido
un documento:
9 El documento tendrá que estar bien formado, es decir, utilizar

correctamente el lenguaje de marcado XML.
9 Existirá un schema asociado contra el que se realizará la validación. Este

schema estará escrito con un determinado lenguaje de schema.
9 El documento cumplirá con todas las restricciones que le impone el schema

asociado en forma de:
o Modelo de contenido: patrón que establece los elementos-hijo

aceptados para cada elemento, el orden de aparición y su
cardinalidad ó número de ocurrencias.
o Sistema de tipos: El contenido de elementos y atributos deberá estar

formado por datos del tipo recogido en el schema asociado.
Ahora bien, no existe una forma única de escribir schemas, existen varios
lenguajes de schema, que se emplean para la definición de schemas. El más
antiguo y sencillo de ellos es el lenguaje DTD (Document Type Definition).
A continuación, se lista el DTD correspondiente al fichero XML mostrado

anteriormente como ejemplo. Este DTD define un lenguaje específico sencillo para
la descripción de agendas telefónicas y será el documento que lea el parser XML
estándar para llevar a cabo la validación, tal y como muestra la Figura 2-22. El DTD
define la estructura de una agenda como un conjunto de una o más ‘fichas’, cada
Pág. 2-45
una de ellas con los elementos y atributos ya referidos. Supone una especie de
plantilla o patrón que deberán cumplir todas las agendas descritas en este
lenguaje.
<?xml version="1.0" encoding="UTF-8"?>
<!ELEMENT AGENDA_TELEFONOS (FICHA+)>

<!ELEMENT FICHA (Nombre, Apellido1, Apellido2, Direccion, Telefono)>
<!ELEMENT Nombre (#PCDATA)>
<!ELEMENT Apellido1 (#PCDATA)>
<!ELEMENT Apellido2 (#PCDATA)>
<!ELEMENT Direccion (#PCDATA)>
<!ELEMENT Telefono (#PCDATA)>
<!ATTLIST Telefono
movil (no | si) #REQUIRED>
MiAgenda.xml PARSER Mensajes de

XML
error
Agenda.dtd
Figura 2-22. Proceso de validación de documento XML.
Un parser XML no sólo lee el documento XML para llevar a cabo su validación,
además permite la accesibilidad de las aplicaciones a los datos. Para llevar a cabo
esta funcionalidad el parser debe implementar alguno de los APIs (Application
Program Interface) estandarizados para el acceso a datos XML: SAX ó DOM.
Un parser SAX (Simple API for XML) genera eventos en varios puntos del
documento (principio y fin del documento, de cada elemento, etc). El programador
puede así escribir el código que trata cada uno de estos eventos (handlers) y
decidir así qué hacer con la información.
DOM (Document Object Model) es una recomendación oficial del W3C que define un
interfaz (independiente de plataformas y lenguajes) para permitir a los programas
el acceso y actualización de estilo, estructura y contenido de documentos XML. Al
procesar un documento con un parser DOM se obtiene una estructura en árbol con
todos los elementos del documento (ver Figura 2-23).
En general, cuando es importante la estructura del documento, se deben mover

partes completas o se va a usar en más de una ocasión la información, DOM es el
Pág. 2-46
interfaz elegido. Se sacrifica un menor rendimiento y mayor consumo de memoria

por una mayor riqueza de funciones para acceso a la información.
Doc XML Parser SAX Handlers
Doc XML Parser DOM
Figura 2-23. Diferencias entre parsers SAX y DOM.
Además del tipo de API que implementen, otros criterios para la clasificación de
parsers XML son su capacidad de validación (no todos la poseen) o el lenguaje de
programación particular empleado (Java, C++, Perl, Python).
XSL (eXtensible Stylesheet Language) es otro estándar XML normalizado por el

W3C. XSL tiene una doble funcionalidad como vocabulario XML para especificar la
semántica de formato de documentos de cara a la presentación y como lenguaje
para transformar documentos XML.
En cuanto a la primera de las funcionalidades, permite generar diferentes formatos

(HTML, PDF, RTF, VRML, PDF, sonido,…) a partir de un único fichero XML de origen.
Mientras la información ha sido expresada en XML, XSL permite describir la forma
en que dicha información debe ser presentada.
Como lenguaje de transformación XSL supone una pequeña sintáxis de lenguaje de

script para poder procesar los documentos XML de forma más cómoda.
Básicamente, XSL define una transformación entre un documento de entrada XML y
otro documento XML de salida. Esta transformación se describe a través un
conjunto de reglas. Cada regla se compone de un patrón (pattern) que indica en
qué contexto y condiciones se disparará la regla y una acción (template) que indica
lo que hay que realizar cuando se dispare.
Pág. 2-47
Doc1.xml PROCESADOR Doc2.xml

XSLT
Transf.xsl
Figura 2-24. Transformación XSL entre documentos XML.
Cada regla afecta a uno o varios elementos del documento. El efecto de las reglas
es recursivo, de forma que un elemento situado dentro de otro también es
transformado. Las reglas de transformación no tienen efectos laterales, el resultado
debe ser el mismo independientemente del orden en que se disparen las reglas.
Una regla no puede modificar el árbol producido por otra, sólo puede añadir nuevos
nodos al resultado.
La Figura 2-24 muestra la transformación del documento ‘Doc1.xml’ en otro

documento diferente ‘Doc2.xml’. Esta transformación es llevada a cabo por un
procesador XSL estándar atendiendo a las instrucciones recogidas en la hoja de
estilo ‘Transf.xsl’.
Las transformaciones XSL pueden aplicarse a la solución de problemas concretos

como:
• Vocabularios alternativos. Si dos vocabularios comparten semántica y

difieren en uso de términos y sintaxis, se puede traducir documentos de uno
a otro a través de XSL.
• Filtrado de información irrelevante. Una buena aproximación es tener un

solo documento XML con toda la información y filtrar con hojas de estilo la
información relevante para cada usuario con o sin cambio de vocabulario.
Ambos documentos podrían compartir el mismo schema y diferir sólo en la
cantidad de contenido.
Pág. 2-48
2.2.4 GENERACIÓN DE GRAMÁTICAS A PARTIR DE

MODELOS UML
Aunque UML y XML tengan características muy diferentes, ambos son lenguajes, y
no es difícil de entender que se plantee el objetivo de armonizar los beneficios que
aportan cada uno de ellos. De hecho, esfuerzos por normalizar el mapeo entre UML
y XML han sido liderados por varios organismos como SWIFT3, ISO (International
Organization for Standardization) y UN/CEFACT4.
Siempre existe un modelo que subyace a cualquier lenguaje, y si bien UML permite
capturar la semántica de un sistema gráficamente (representación adecuada para
consumo humano), la información expresada en XML es más fácilmente procesada
por las aplicaciones, portable entre sistemas y serializable para su transmisión.
XMI es un estándar que permite conjugar las ventajas de ambas representaciones

pero se le achacan ciertas limitaciones (al menos a su versión 1.1):
• Genera DTDs y no XML Schemas.
• No soporta multiplicidad en las relaciones.
• Ficheros resultantes muy grandes y poco legibles para humanos.
• Poca flexibilidad en la generación automática.
Por estas razones, se definen otros mapeos como el de Carlson (2001). Carlson
define un mapeo bidireccional propio a través de un perfil UML (estereotipos,
tagged values y constraints). Esto permite al usuario elegir entre la generación que,
por defecto, aplica el perfil o la generación personalizada mediante el uso de
estereotipos. Los estereotipos permiten definir qué requisitos del modelo UML
quiere trasladar al schema y cómo de estricto desea que sea éste.
Los schemas generados desde este perfil particular son un refinamiento de los que
genera XMI. Es decir, desde un mismo modelo UML se puede generar bien el DTD
que proporciona XMI (pues no hace caso a los estereotipos), o bien el schema
particular del perfil (aplicando las restricciones que marcan los estereotipos).
Instancias válidas contra el schema del perfil lo serán también contra el DTD de
XMI, pero no a la inversa.
3
Society for Worldwide Interbank Financial Telecommunication. Organización dedicada al
desarrollo y promoción de la interacción global y estandarizada entre las transacciones
financieras internacionales a través de un lenguaje común.
4
United Nations Centre for the Facilitation of the Administration, Commerce and Transport.
Pág. 2-49
Este perfil, junto con un conjunto de facilidades adicionales,

forman la herramienta comercial Hypermodel
(http://xmlmodeling.com/products/hyperModel/) que se implementa como un
plugin de Eclipse (http://eclipse.org/), herramienta que se describe en el apartado
2.4.2.2.
Figura 2-25. Herramienta HyperModel.
La utilización de UML para describir lenguajes XML aporta las siguientes ventajas:
9 El modelo UML puede servir como especificación independiente de cualquier

implementación particular de lenguaje de schema, a partir del cual se
pueden definir mapeos a los diferentes tipos de schema (DTD, XML Schema,
NG, RDF,…).
9 Interfaz gráfico. Se facilita la captura de la semántica a través de los

diagramas.
9 Rápido desarrollo de buenos schemas sin conocer a fondo XML.
9 Uso por defecto de las reglas de mapeo normalizadas en la organización o

empleo opcional de estererotipos para personalizar la generación
automática.
9 Mapeo directo del modelo a la implementación práctica para la

comprobación de cardinalidad, herencia y relaciones de dependencia que
deben existir entre los conceptos tanto en el SW, como en las bases de
datos o en los documentos.
9 Generación de los schemas y las clases Java que vayan a manejar esos
datos desde un modelo común. Se logra la creación automática de datos
portables y código portable para la gestión de esos datos, evitando errores
con la introducción de modificaciones. Esto facilita mucho el mantenimiento
y la reutilización.
Pág. 2-50
9 Los schemas se han usado para definir vocabularios pero normalmente se

acompañan de documentación textual para explicar su semántica. Los
diagramas de clases UML pueden enfatizar la descripción de la semántica.
9 Fácil comprensión de elementos y relaciones para otras personas

involucradas (y no entendidas en la sintaxis XML) por ser UML un lenguaje
gráfico y muy extendido.
9 UML se ha convertido en el estándar de facto para análisis de requisitos y

diseño, unifica el proceso de desarrollo y facilita la comunicación entre todos
los agentes involucrados en el sistema.
Pág. 2-51
Pág. 2-52
22..33 H
HEERRRRAAM
MIIE
ENNT
TAASS E
ESSPPEECCÍÍFFIICCAASS D
DEED
DOOM
MIIN
NIIO
O
Sobre el panorama actual de las herramientas de uso más común en cada

uno de los dominios. Se analizan las características de las herramientas
individuales y los intentos conocidos de integración de varias de ellas.
Es muy amplio el rango y la variedad de herramientas que tienen interés en el

desarrollo de SCDTR, por ello, es difícil realizar una clasificación compacta de todas
ellas. Con objeto de ilustrar esta heterogeneidad y como ejemplo de taxonomía, se
toma la realizada por INCOSE5.
INCOSE es una organización sin ánimo de lucro fundada en 1990 para promocionar
la aplicación de aproximaciones interdisciplinares orientadas a la construcción de
sistemas más eficaces. Bajo el nombre de Ingeniería de Sistemas agrupan al
conjunto de disciplinas que permiten desarrollar sistemas con éxito. Se intenta
definir las necesidades del cliente y las funcionalidades del sistema en etapas
tempranas del ciclo de desarrollo, documentar los requisitos y diseñar pruebas de
validación que consideren el problema completo, tanto desde el punto de vista
técnico como de negocio. Para esta concepción de la Ingeniería de Sistemas,
INCOSE define la siguiente taxonomía de herramientas:
Herramientas de Gestión:
○ Gestión de la configuración
○ Gestión del Workflow
○ Gestión de riesgos
○ Estimación de costes y seguimiento
○ Seguimiento de defectos
Herramientas de Ingeniería:
○ Diseño de sistemas
∗ Modelado
− Estructural
− De comportamiento (dinámico ó estático)
− Prototipado de HMI (Human Machine Interface)
5
The International Council on Systems Engineering (www.incose.org).
Pág. 2-53
∗ Diseño
− Simulación
− Análisis numérico
− Específicas de dominio
− Medida de la efectividad
○ Ingeniería de requisitos
∗ Gestión
− Clasificación
− Captura e identificación
− Trazabilidad
∗ Generación
○ Validación de diseños
∗ Análisis de threads
∗ Planificación de pruebas de validación
∗ Validación del cumplimiento de requisitos
− Medición
− Análisis de rendimiento
Herramientas para la compartición de información
○ Comunicación
∗ Interpersonal
∗ Recuperación de información
− Servicios de directorio
− Transferencia de ficheros
− Servicios de información
− WWW
○ Análisis de datos
∗ Hojas de cálculo
∗ Reducción de datos
∗ Visualización de datos
○ Publicación electrónica
∗ Generación automática de documentos
∗ Publicación técnica
Pág. 2-54
∗ Ilustración técnica
∗ Convertidores de formato de fichero
○ Visualización electrónica
∗ De bases de datos
∗ De documentos con formato
Herramientas para el soporte de infraestructura
○ Administración de sistemas
○ Soporte de redes
○ Gestión de productos
La amplia base de datos de herramientas catalogadas por INCOSE

(http://www.paper-review.com/tools/tdb/home.php) puede ser consultada de
acuerdo a esta clasificación o a través de un motor de búsqueda.
Una categoría que merece un comentario aparte es la de las herramientas de

gestión de requisitos. Herramientas de gestión de requisitos recogidas y analizadas
por INCOSE son las siguientes: Analyst Studio (RequisitePro), Caliber RM, C.A.R.E,
Catalyze, CORE, Cradle, DOORS, QSS requireit, Envision, IRqA, RMTrak, Team
Trace, Tracer, RDT, RTM, SLATE, SpeeDev, Systems Engineer, Tofs, Vital Link,
XTie-RT.
Estas herramientas permiten entender las necesidades del usuario, lo que supone el
punto de partida para el desarrollo de la aplicación adecuada, y al mismo tiempo,
proporcionan el patrón sobre el que medir el éxito logrado en la implementación
final. La gestión de requisitos consiste en la captura, almacenamiento, gestión
(organización, trazabilidad, análisis y visualización) y diseminación de información.
La trazabilidad es un concepto clave; supone la provisión de relaciones entre los

requisitos, el diseño y la implementación de un sistema para gestionar el efecto de
los cambios y asegurar el éxito del sistema desarrollado. Algunos estudios apuntan
a la trazabilidad como el aspecto que más debe mejorarse en las herramientas de
ingeniería de sistemas. El problema es que para ser efectiva, la trazabilidad
requiere asociar los requisitos con información almacenada en una variedad de
herramientas (ya que suelen ser diferentes las herramientas involucradas en
especificación, diseño o implementación). Por tanto, no basta con asegurar la
trazabilidad dentro de los límites de una herramienta, debe asegurarse dentro del
conjunto de herramientas que se usen en el entorno.
Si es consistente a lo largo del desarrollo, la trazabilidad debe permitir dar

respuesta a las siguientes cuestiones:
9 ¿Cuál es el impacto de un cambio en un requisito?
Pág. 2-55
9 ¿Dónde se implementa un determinado requisito?
9 ¿Cumple la implementación todos los requisitos?
9 ¿Es este requisito necesario?
9 ¿Qué decisiones de diseño afectan a la implementación de un requisito?
9 ¿Por qué se ha implementado este diseño?, ¿cuáles son las alternativas?
9 ¿Es necesario este elemento de diseño?
9 ¿Cómo se interpreta este requisito?
9 ¿Hemos terminado?
En definitiva, para dar respuesta a estas cuestiones se identifica claramente la

trazabilidad como una propiedad necesaria en el entorno multidisciplinar objeto de
este trabajo. Es una propiedad transversal a todos los dominios y que necesita ser
implementada independientemente de cualquier herramienta, y a la vez interactuar
con todas.
Aún teniendo presente que existen otras muchas clasificaciones de herramientas

(ninguna del todo precisa), los siguientes apartados se ciñen a una clasificación
acorde con los dominios esbozados en el primer capítulo para repasar algunas de
las herramientas más habituales en el desarrollo de SCDTR. No se pretende realizar
un estudio del arte profundo de cada uno de los dominios, más bien se analizan
buscando los puntos clave de cada dominio de cara a la integración de
herramientas.
Pág. 2-56
2.3.1 INGENIERÍA DE CONTROL

Se agrupan bajo el acrónimo CACE6 (Computer-Aided Control Engineering) el
conjunto de herramientas SW de ayuda a la creación de Sistemas de Control.
Normalmente, estas herramientas constan de un entorno de ejecución con interfaz
de usuario y una colección de funciones científicas, matemáticas y de ingeniería
para poder desarrollar las operaciones de cómputo requeridas en las aplicaciones
de control. Suelen disponer de una arquitectura abierta que permita la modificación
de las funciones existentes y la adición de nuevas para poder adaptar la
herramienta a las necesidades particulares del usuario. Entre las más significativas
se encuentran:
Matlab de Mathworks™(www.mathworks.com). Es la más popular en entornos

académicos (más de 400 libros publicados) y cada vez más extendida en la
industria. Es un motor computacional de propósito general desde el que se
pueden invocar más de 600 de funciones para soportar cálculos, gráficos y
simulaciones con usos muy diversos. Su funcionalidad se puede extender a
través de toolboxes (colecciones de funciones especializadas en un campo).
Existe un largo listado de toolboxes entre las que se encuentran las
desarrolladas por la propia Mathworks (unas 60), por otras empresas (más de
275) y por universidades y particulares (incontables). Por mencionar solamente
algunos ejemplos de toolboxes relacionadas directamente con la ingeniería de
control: instrumentación, control LMI (Linear Matriz Inequality), control
predictivo, calibración basada en modelos, procesado de señal, identificación de
sistemas, optimización, control robusto, redes neuronales, fuzzy, estadística,…
Cabe un comentario específico sobre las toolboxes Simulink, Control, StateFlow
y RTW por su importancia en el modelado y diseño de sistemas de control:
○ Simulink es un toolbox para modelado y simulación avanzada que permite al

usuario construir diagramas de bloques que representan la dinámica de los
sistemas a través de un interfaz interactivo de manipulación de iconos.
Tiene una colección de bloques predefinidos que puede ser ampliada
creando otros nuevos en el lenguaje propio de matlab o con código externo
(C, C++, Fortran, Java).
○ Control es una colección básica de funciones para manipulación de

diagramas de bloques, análisis de sistemas y diseño basado en
metodologías de control clásico o moderno. Ejemplos de funciones:
transformada de Laplace, análisis y diseño en el dominio temporal,
frecuencial y espacio-estado, sistemas de tiempo continuo y discreto, cálculo
6
Además de CACE (Computer-Aided Control Engineering), también se habla de CACSD
(Computer-Aided Control System Design).
Pág. 2-57
del lugar de las raíces, diagramas de Bode, Nyquist y Nichols, diseño por
ubicación de polos, etc.
○ StateFlow. Expresión de la lógica de control a través de modelos jerárquicos

dirigidos por eventos. Programación gráfica, simulación y generación
automática del código que implementa las máquinas de estados finitos. Uso
en paralelo con modelos Simulink.
○ RTW (Real Time Workshop). Genera automáticamente código C

personalizable para los diagramas Simulink, lo cual permite el prototipado
rápido y la simulación con HW in the loop. Soporta una variedad de drivers
para la generación de código adaptado al HW.
MATRIXx de National Instruments (www.ni.com/matrixx). Entorno interactivo

de manipulación de matrices que combina la potencia de cálculo numérico con
facilidades gráficas de sencillo uso para analizar sistemas lineales aplicados a
ingeniería. Simulación dinámica, diseño de control y generación automática de
código y documentación a través de su familia de productos (Xmath,
SystemBuild, AutoCode, y DocumentIt).
ACSL de AEgin Technologies (www.acslsim.com). ACSL (Advanced Continuous

Simulation Language), nació hace 25 años como el primer lenguaje para
modelado y simulación de sistemas continuos disponible comercialmente; está
basado en el estándar CSSL (Continuous System Simulation Language). Sobre
este núcleo, se ha construido un entorno de simulación con potentes gráficos.
Este entorno se puede especializar en varios campos de aplicación gracias a
paquetes adicionales que se adaptan a las necesidades particulares de
simulación de ese campo. Paquetes ACSL: Sim, Math, Open API, Graphic
Modeller, Optimize, Real Time, Vision, C Code, JMASS Translator.
Program CC de Systems Technology. (www.programcc.com). Programa para

análisis y diseño de sistemas de control. Proporciona un diseño detallado
gracias a funciones que automatizan los algoritmos de la teoría de control
clásica y moderna, en los dominios temporal ó frecuencial, con entradas
sencillas ó múltiples de tipo analógico ó digital.
Se puede apreciar como la mayoría de estos entornos intentan adaptarse a las

necesidades del desarrollo de sistemas actuales agrupando cada vez más
funcionalidades paralelas a las propias del control (generación de código, interfaz a
lenguajes de programación,…) e intentando abarcar varios dominios. Por ejemplo,
son muy interesantes al respecto los avances de Matlab y Matrixx que, a través de
los paquetes adicionales RTW y AutoCode respectivamente, abordan la generación
de código para el HW de control, permitiendo la rápida generación de prototipos y
facilitando el salto de la simulación teórica a la implementación real.
De hecho, una posibilidad para crear un entorno multidisciplinar es seleccionar una

de estas herramientas comerciales y completarla con aquellas funcionalidades de
las que carezca para el desarrollo de SCDTR. Una gran ventaja de esta
Pág. 2-58
aproximación es el conocimiento que los especialistas en control ya tienen de la

herramienta. En esta línea han profundizado varios grupos de investigación:
DEVELOPMENT FRAMEWORK (Universidad de Sheffield). Es un intento de

construcción de un entorno común en el que se complementan una
herramienta CACE y una herramienta CASE7 para unificar los mundos de la
Ingeniería de Control y del SW (Bass et al 1994, Browne et al 1996 y Hajji
et al 1997). Concretamente, las herramientas elegidas son Matlab y
Software through Pictures (www.aonix.com). El entorno permite especificar
el sistema en Matlab, traducir las especificaciones a la notación de la
herramienta CASE, diseñar en ella la arquitectura SW teniendo en cuenta
requisitos no funcionales y generar el código final en lenguaje C para el
kernel de tiempo real “Virtuoso”. Ha sido necesario complementar las
funcionalidades de cada una de las herramientas para conseguir:
o Traducción de información de una herramienta a otra a través de la

notación FII (Framework Information Interchange).
o Especificación adicional de conceptos no recogidos en principio por

las herramientas: diferentes algoritmos de mapeo de los procesos a
procesadores, mecanismos de tolerancia a fallos, etc.
RTF (Real Time Framework, ver anexo A.2). Entorno construido alrededor
de Matlab añadiéndole funcionalidades de las que no dispone pero que son
necesarias para el desarrollo de SCDTR. Durante los primeros años de
desarrollo de esta tesis ésta es la aproximación que se eligió. Se seleccionó
Matlab como núcleo del entorno por ser la herramienta CACE de mayor
aceptación, por agrupar disciplinas diversas y facilitar la adaptación a las
necesidades propias. Se consideraron de interés las toolboxes Simulink,
StateFlow y RTW, y sobre esa base se aumentaron las funcionalidades para
cubrir las necesidades de los SCDTR:
o Nueva vista Simulink para la especificación de la topología de red del

sistema distribuido y la identificación de nodos y enlaces de
comunicación.
o Nueva vista Simulink para la especificación de la arquitectura SW

(hilos de ejecución concurrentes, mecanismos de comunicación y
sincronización) de cada nodo.
o Generación automática de código, acorde con las vistas anteriores,

para tarjetas comerciales CAN y Sistema Operativo de Tiempo Real
VxWorks.
7
Computer-Aided Software Engineering.
Pág. 2-59
o BERTA (Basic Environment for Real Time Análisis, ver anexo A.1)
para realizar análisis de peores tiempos de respuesta extremo a
extremo y simulación de escenarios concretos de activación en
sistemas distribuidos sobre los buses CAN o Profibus.
Aunque en principio pueda parecer una aproximación adecuada, ambos intentos

adolecen de los mismos problemas que han impedido su permanencia en el tiempo
a través de la renovación continua:
• Mantenimiento y actualización muy complejos. Se basan en la arquitectura

propia de un producto comercial, y esa arquitectura no está pensada para
integrar nuevos servicios que difieran del modo de funcionamiento previsto
en la concepción del producto. La integración de otros servicios depende
demasiado del funcionamiento interno de las herramientas y acaba
convirtiéndose en un conjunto de “parches”.
• Poca flexibilidad. Son soluciones estáticas que no permiten elegir al usuario

otras herramientas.
• Precio adicional de cada paquete. Se basan en uno o varios productos

comerciales con paquetes añadidos a la opción básica.
• No abiertos. La capacidad de modificación o de interacción se limita al API

(Application Program Interface) que ofrece el fabricante.
• Incompatibilidades entre versiones. La dependencia de la herramienta

comercial hace que con las nuevas versiones haya que adaptar todo el
entorno.
• Derivas de la empresa o del producto. El entorno está atado al futuro de la

herramienta comercial que puede cambiar de empresa, cambiar de filosofía
o incluso desaparecer.
• Campos de interés no cubiertos por la misma herramienta comercial. Por

ejemplo:
o Modelado y simulación de componentes físicos. En los campos

eléctrico, electrónico, mecánico, termal, neumático e hidráulico se ha
generado SW con este propósito, pero no se ha hecho en conjunción
con el mundo del control. Por ejemplo, Saber Simulation Software
(de Analogy) (www.analogy.com) usa el concepto de patrones de
componentes para modelar dispositivos electrónicos (transistores,
circuitos integrados), mecánicos (motores, poleas), eléctricos (cables,
resistencias), etc. La simulación permite evaluar la tolerancia
estadística y la idoneidad de los componentes físicos para el sistema.
Aplicaciones de este tipo deberían ser extensiones naturales de las
herramientas CACE.
Pág. 2-60
o Visualización animada del movimiento de sistemas dinámicos. Las

actuales tecnologías interactivas y de alto rendimiento de video
suponen un complemento perfecto para las herramientas CACE.
Como conclusión de este apartado, se puede resumir que las herramientas CACE no
se limitan a realizar un limitado número de funcionalidades estrictamente
relacionadas con el control, sino que intentan adaptarse a las necesidades de los
desarrolladores y añaden funcionalidades paralelas al control pero necesarias para
la implementación de sistemas. Esta tendencia ha supuesto un acercamiento a
otros dominios y ha impulsado la creación de algunos entornos multidisciplinares
que toman como núcleo una herramienta CACE para complementarla con
desarrollos ad hoc. Estas experiencias anteriores no aconsejan asociar el núcleo del
entorno a ningún producto comercial. La arquitectura general y el funcionamiento
interno del entorno multidisciplinar deben ser independientes de cualquier
herramienta.
Pág. 2-61
2.3.2 SISTEMAS DISTRIBUIDOS

Para resolver los problemas de implantación de un sistema distribuido existen
varios tipos de herramientas de apoyo entre los que se pueden mencionar:
• Analizadores de red o herramientas de monitorización. Son herramientas no

intrusivas que simplemente muestran al usuario lo que está siendo
transmitido. Tienen la posibilidad de mostrar esta información a diferentes
niveles: a nivel de bit o byte, trama, mensaje, señales,… Permiten medir
tiempos, filtrar determinados mensajes, almacenar en fichero el histórico de
una sesión, etc.
• Herramientas de configuración de red y nodos. Ayudan en las labores

propias de la puesta en marcha del sistema y configuración de la gestión de
red: asignación de direcciones a nodos, mapeos de variables de proceso a
mensajes, multiplexación de señales en mensajes, asignación de canales
analógicos y digitales, asignación de prioridades de los mensajes, periodos
de transmisión, configuración de los servicios de transmisión periódicos y
esporádicos, etc.
• Simuladores del comportamiento en red. Permiten ver el funcionamiento

virtual de una red antes de su instalación para evaluar posibles retardos,
errores, cargas, eficiencia de uso,... Funcionalidades como inyección
intencionada de sobrecargas de mensajes o mensajes erróneos para valorar
el comportamiento ante diversos escenarios.
Todas ellas se apoyan en HW específico de la red en cuestión, lo que les permite

capturar la información o bien convertirse en un nodo más que participa en el envío
y recepción de mensajes si la herramienta dispone de esta capacidad.
Otra de las características de estas herramientas es su interfaz para la colaboración

con otras aplicaciones. Además de las clásicas interfaces API, son habituales otros
mecanismos de interacción para intercambio de datos como DDE8, OPC9, COM ó
DCOM10.
8
DDE (Dynamic Data Exchange) provee de un conjunto de protocolos para permitir el
intercambio de información entre aplicaciones a través de memoria compartida y con un
modelo cliente / servidor.
9
OPC (OLE for Process Control), estándares abiertos para conectividad e interoperatividad
en el mundo de la automatización industrial.
10
COM (Component Object Model), arquitectura SW de Microsoft para construir aplicaciones
basadas en componentes. DCOM es una extensión para soportar objetos distribuidos.
Pág. 2-62
Evidentemente, estas herramientas son exclusivas de un tipo de redes, más aún, lo

más habitual es que un fabricante esté especializado en el desarrollo de
aplicaciones para un único bus de campo. Por ello, se va a tomar el bus CAN a
modo de ejemplo y se van a describir las características de algunas herramientas
para este tipo de bus. Herramientas similares existen para otros estándares como
Profibus, ASI, Foundation Fieldbus, etc.
En el caso de CAN, hay una variedad de empresas que ofrecen productos de

similares características para cada uno de los tipos de herramienta que se han
mencionado (www.iologic.com, www.hitex.com, www.ime-actia.com, www.stzp.de).
Pero es interesante destacar cómo las herramientas ofrecidas se estructuran en
forma de familias, de forma que dan al usuario la posibilidad de crear un entorno de
desarrollo formado por varias herramientas conectadas entre sí. Para analizar este
fenómeno, se describen las herramientas de la empresa Vector Informatik
(www.vector-informatik.com) que dispone de uno de los más amplios abanicos de
herramientas del mercado y cubre tanto el protocolo CAN a nivel de enlace como
los protocolos de alto nivel más extendidos (CANopen, DeviceNet):
CANalyzer. Puede ejercer las funciones de un simple monitor (análisis de los

mensajes que circulan por el bus) o puede actuar como controlador de bus
(inicialización de la red y envío activo de mensajes). Puede realizar la
identificación de todos los nodos conectados al bus, la identificación de las
señales que son transportadas en un mensaje, etc. Permite generar programas
(en un pseudo-C denominado CAPL) que regulen el envío activo de mensajes
periódicos o esporádicos (ante eventos de recepción de un determinado
mensaje o pulsación de una tecla).
CANoe (CAN Open Environment). Amplía las capacidades de CANalyzer con la

posibilidad de realizar la simulación de una red completamente virtual o de una
red híbrida compuesta de nodos reales junto con nodos simulados. Los nodos
simulados se construyen gracias al lenguaje CAPL que permite programar el
comportamiento de los mismos enviando y recibiendo mensajes, además de
interactuar con variables de entorno (magnitudes físicas manejadas por el
sistema de control) que modifican su valor por la interacción con mensajes,
teclado o interfaz gráfico de usuario. También se pueden introducir bloques
generadores, repetidores o filtros. Esta potencialidad permite trabajar en el
diseño de las comunicaciones en ausencia de HW, para luego ir sustituyendo
los nodos simulados por nodos reales. Realiza todo tipo de estadísticas sobre
los mensajes que se intercambian, permite construir gráficos en tiempo de
simulación con las señales que extrae de los mensajes, asocia a las señales sus
verdaderas magnitudes físicas (velocidades, posiciones, temperaturas), análisis
off-line de la información almacenada en cada sesión. Se ofrecen interfaces a
Matlab y a LabView que permiten utilizar los modelos de estas herramientas
para simular el comportamiento funcional de los nodos (en lugar de CAPL) y
realizar una simulación conjunta que conjugue el comportamiento funcional del
control con el de la red de comunicación.
Pág. 2-63
CANdb++. Herramienta para la administración de la base de datos compartida

por toda la familia de herramientas. CANdb es la columna vertebral de la
integración de información entre las diferentes herramientas de la familia y en
esta base de datos se va almacenando toda la información en las fases de
diseño, simulación y configuración de la red y los nodos.
CANeds. Herramienta para la generación y modificación de los EDS (Electronic

Data Sheets). Los EDS de CANopen son descripciones de las características de
los dispositivos similares a los ficheros GSD de Profibus. Tienen un formato
estándar que permite identificar las propiedades de todos los nodos conectados
a una red independientemente de su fabricante. Por tanto, habilitan el uso de
herramientas de gestión de proyectos, análisis y configuración independientes
de las marcas de los dispositivos físicos.
DaVinci Tool Suite. Entorno para el diseño funcional de SW para sistemas de

automoción y la generación de SW empotrado para ECUs (Electronic Control
Units). Usa una metodología de diseño de componentes que permite reutilizar
funciones. A través de CANfbl (Flash Bootloader) se descarga el código al target
vía CAN.
ProCANopen. Gestión de proyectos de redes CANopen en las fases de

planificación, desarrollo y mantenimiento. Decisiones como la arquitectura de la
red (maestro-esclavo ó multi-maestro) o la topología se toman en base al
análisis de rendimiento de grupos de nodos.
osCAN. OSEK/VDK es un estándar de Sistema Operativo de la industria

europea del automóvil (www.osek-vdk.org) liderado por BMW, DaimlerChrysler,
Renault y Volkswagen. Está especialmente pensado para desarrollar de forma
conjunta el SW concurrente y las comunicaciones del sistema distribuido y para
minimizar la cantidad de memoria y el tiempo de uso de CPU. Además del
propio kernel (multitarea y con desalojo), el estándar define varios servicios:
NM (Network Management) y COM (Communication), para la gestión de red y
el intercambio de datos entre tareas concurrentes (en la misma o en diferentes
CPUs). osCAN es una implementación del OSEK/VDK que incluye los servicios
NM y COM.
CANbedded. Entorno consistente en componentes adaptativos de código

fuente que cubren los requisitos básicos de comunicación de las aplicaciones de
automoción. Los componentes son ajustados y configurados para el proyecto.
Enfatiza la reutilización de SW empleando una misma pila de protocolos para
todas las aplicaciones.
Como conclusión de este apartado, se puede resumir que también las herramientas
específicas de sistemas distribuidos intentan adaptarse a las necesidades de los
desarrolladores y ampliar el espectro a campos limítrofes: interfaz a herramientas
CACE como Matlab para contrastar las comunicaciones con el comportamiento
funcional del nodo, integración de las comunicaciones con el sistema operativo
(osek/vdk), desarrollo de SW embarcado para la comunicación, etc. Este es un
Pág. 2-64
campo de interés evidente porque tras diseñar el algoritmo de control hay que
distribuirlo en los diferentes nodos en los que se ejecutará, elegir los sensores,
actuadores y topología de red que lo una todo, configurar los nodos, fijar el mapeo
de señales a mensajes, configurar los servicios de red que se usarán, valorar
latencias, ver el efecto que tienen sobre el rendimiento del algoritmo de control,
valorar la interacción con los servicios que se usen del Sistema Operativo, etc.
Pero, al igual que ocurría con las herramientas CACE, estas aplicaciones son
bastante cerradas y sólo se comunican entre sí las del mismo fabricante (para
favorecer el negocio propio), o a lo sumo, implementan algún interfaz propietario a
alguna otra herramienta. Además, es razonable que no vayan a alcanzar el mismo
grado de calidad en campos paralelos como los del control o el desarrollo SW. Por
lo tanto, sigue pareciendo mejor la opción de hacer colaborar estas herramientas
con las herramientas CACE dentro de un entorno abierto y flexible en el que cada
herramienta realice la labor para la que está concebida.
Pág. 2-65
2.3.3 SISTEMAS DE TIEMPO REAL

A diferencia de lo que ocurre con la Ingeniería de Control, el desarrollo de Sistemas
de Tiempo Real sí que ha estado tradicionalmente ligado a las técnicas y
metodologías de la Ingeniería del SW. De todos modos, por tener estos sistemas
unos requisitos tan específicos y estrictos, en la mayoría de los casos es necesario
adaptar, acotar o aplicar con matices las técnicas generales de Ingeniería del SW.
Concretamente, la etapa de análisis, cobra gran importancia en este tipo de
sistemas porque el resultado del análisis debe asegurar que el SW diseñado es
capaz de cumplir los requisitos temporales especificados con los recursos HW y SW
disponibles. Este es un objetivo ambicioso cuyo cumplimiento requiere de un
profundo conocimiento del sistema y condiciona todas las fases del ciclo de vida.
Respecto a las herramientas que los especialistas de tiempo real emplean para
desarrollar sus aplicaciones, no es sencillo estudiarlas de forma aislada debido a su
diversidad. Un criterio para su clasificación puede ser la fase del desarrollo en la
que se emplean, ya que existen herramientas para cubrir las fases de especificación
de requisitos, modelado, análisis, diseño o implementación. Sin embargo, también
existen herramientas que cubren varias fases, por lo que no parece este criterio el
más significativo. Debido a que una de las características fundamentales de estos
sistemas es el aseguramiento del cumplimiento de requisitos temporales, la fase de
análisis se antoja fundamental, y de hecho, casi siempre influye en las demás. Por
ejemplo, se deben introducir en el modelo del sistema aquellos datos que van a ser
necesarios para el análisis, o se diseña el sistema con un estilo de arquitectura sólo
si es analizable con un determinado método asociado ó se implementa el sistema
sólo con algunos de los recursos del lenguaje de programación (aquéllos recogidos
en los supuestos del análisis).
Por todo ello, el modelo de arquitectura elegido por el desarrollador va a influir

decisivamente en la naturaleza del conjunto de herramientas que podrá usar. El
hecho es que las herramientas de análisis se construyen alrededor de un
determinado estilo de arquitectura, y por tanto, otras fases del ciclo de vida (y las
herramientas que se empleen en ellas) también se ven influenciadas por dicho
estilo de arquitectura.
Algunas definiciones quizás permitan entender mejor el párrafo anterior:
La arquitectura de un sistema SW es la organización fundamental de un

sistema, conformada por sus componentes, las relaciones entre ellos y con
el entorno y los principios que guían su diseño y evolución (ANSI/IEEE
2000).
Un estilo de arquitectura es una familia de arquitecturas definidas por un

vocabulario común de componentes y conectores, una topología, un
conjunto de requisitos semánticos y unos métodos de análisis soportados
Pág. 2-66
(Shaw 1995). El estilo de arquitectura está muy ligado a los métodos de

análisis, cuya importancia ya ha quedado patente.
Los requisitos de arquitectura son aquéllos que no pueden ser asignados

a un componente único o a un pequeño grupo de ellos, sino a la totalidad
del sistema. La misma existencia de este tipo de requisitos refuerza aún más
la importancia que tiene la descripción formal de la arquitectura en un
Sistema de Tiempo Real.
El conjunto de estilos o familias de arquitectura empleados en sistemas SW es muy

amplio (Shaw y Clements 1997), pero se ve muy reducido cuando los sistemas SW
tienen requisitos de Tiempo Real, ya que las arquitecturas empleadas deben
permitir cumplir con las restricciones temporales y de seguridad de estos sistemas.
En la práctica, sólo unas pocas arquitecturas SW permiten cumplir
satisfactoriamente estos requisitos y se utilizan para desarrollar Sistemas de
Tiempo Real. La elección de un estilo o familia de arquitecturas determina
decisiones como número y tipo de tareas concurrentes, mecanismos de
comunicación (memoria compartida, mensajes, protocolos) y sincronización
(objetos protegidos, rendezvous, semáforos, mutexes), excepciones, datos
compartidos, interfaces al entorno de ejecución (POSIX, SQL, CORBA,…), etc. Locke
(1999) determina la siguiente taxonomía restringida de estilos de arquitectura para
Sistemas de Tiempo Real:
• Arquitectura secuencial (Timeline), basada en ejecutivo cíclico ó

ventanas. Es la más simple y antigua. Se emplean ventanas de tiempo fijas
en las que se ejecutan los procedimientos constituyentes de la aplicación en
una secuencia predeterminada. Usa un planificador simple dirigido por
tiempo que gestiona la ejecución de los procedimientos de acuerdo a una
tabla secuencial. Este tipo de arquitectura obliga a dividir la aplicación en un
conjunto fijo de procedimientos que se invocan en ventanas o ‘ciclos
menores’, que se agrupan en un ‘macrociclo’. Las ventajas (no hay
necesidad de sincronización explícita ni sobrecarga por cambios de contexto,
Zamorano et al 1997) que supone esta arquitectura se logran a un alto
precio ya que: todo procedimiento debe ser acomodado a su ventana, son
sistemas difíciles de mantener y extender y el programador debe realizar
manualmente (posibilidades de error) mediante técnicas ad hoc unas labores
que muchos de los sistemas operativos modernos pueden hacer
automáticamente y con resultados predecibles.
• Arquitectura dirigida a eventos. En este tipo de arquitectura la

ocurrencia de un evento (llegada de un mensaje, operación de entrada /
salida completada, expiración de un temporizador, pulsación de una tecla)
dispara la ejecución de la parte computacional del SW. La arquitectura
consiste en un conjunto de tareas en las que cada una tiene su prioridad y
espera a un determinado evento para ejecutarse. Esta arquitectura supone
el uso de la concurrencia al nivel de aplicación, lo que obliga al uso de
mecanismos de sincronización y comunicación (semáforos, mutex, objetos
Pág. 2-67
protegidos). La sincronización añade complejidad a la aplicación pero

incrementa la utilización de los recursos, aún dentro de los márgenes
impuestos por los requisitos temporales. El paradigma de arquitectura
dirigida a eventos puede resultar en tiempos de respuesta impredecibles si
se descuidan sus implicaciones hasta las últimas etapas de la integración del
sistema. Es necesario tener en cuenta las implicaciones de esta arquitectura
desde las fases de modelado del sistema para emplear un diseño adecuado y
poder realizar el análisis temporal que asegure el cumplimiento de plazos. El
mayor problema que debe afrontarse es la existencia de algunos eventos
con patrones de llegada de naturaleza explosiva. Habitualmente, estos
patrones de llegada se modelan con distribuciones como la de Poisson, que
hacen imposible un cálculo de la carga máxima del sistema en un intervalo
de tiempo arbitrario, resultando un tiempo de respuesta del sistema
impredecible en esos casos. Esto hace necesario el uso de algoritmos de
reserva de ancho de banda como el del servidor esporádico (Sprunt et al
1989) para lograr tiempos de respuesta predecibles con niveles de
utilización razonables.
• Arquitectura Pipeline. Es similar a la arquitectura anterior pero está

pensada específicamente para ser aplicada en sistemas distribuidos. La
llegada de eventos puede producirse en un procesador, en el que una tarea
realice un procesado inicial, pero el procesado adicional lo harán otras tareas
que se encuentren en el mismo o en cualesquiera otros procesadores del
sistema. Por tanto, se procesan los eventos pero se encarga el procesado
restante y la respuesta final a los eventos a entidades de planificación
ubicadas en otro punto del sistema, a diferencia de la arquitectura anterior
en la que una misma entidad recogía el evento y generaba la respuesta tras
el procesado necesario. En esta arquitectura es habitual que un evento
individual genere procesado en múltiples tareas y que se generen múltiples
salidas como respuesta. El parámetro de rendimiento más importante es la
latencia desde el instante de llegada del evento a la salida de cada una de
las respuestas (tiempo de respuesta extremo a extremo) y su cálculo
supone el seguimiento del flujo del control a lo largo de la secuencia de
tareas que colaboran en el procesado (pipeline). Una tarea que procese
parte del cómputo asociado a un evento específico, no sólo debe competir
por el recurso procesador con tareas relacionadas con otros eventos,
también con tareas que procesan otras partes del mismo evento. Esto hace
que sea difícil decidir la prioridad de cada tarea y en ocasiones se hace en
función de la dirección del flujo del pipeline (prioridades crecientes en esa
dirección minimizan las colas de eventos en etapas intermedias). El uso de
prioridades dinámicas permitiría ajustar la prioridad de cada tarea en
función de la importancia del evento desencadenante.
• Arquitectura Cliente-Servidor. El procesado se basa también en el tipo de

evento pero el flujo de control permanece en el nodo que maneja el evento
inicial porque las etapas sucesivas de procesado se invocan a través de
Pág. 2-68
llamadas a procedimientos remotos desde la tarea inicial, y el control es

devuelto a la misma. De este modo, la raíz del control para cualquier evento
permanece en el manejador de eventos y todo el procesamiento adicional se
realiza en otras entidades servidoras. Esta arquitectura es la que se usa, por
ejemplo, en CORBA, estándar que cuenta con una extensión para tiempo
real sobre la que se puede realizar un análisis de cumplimiento de plazos
más robusto. La asignación de prioridades a tareas se puede hacer en
función de los requisitos temporales o en función de su importancia
semántica, aunque en algunos casos es más efectivo asignar prioridades a
los mensajes y que éstos la propaguen a los clientes. Esta arquitectura da
lugar a sistemas que se depuran de forma más sencilla que los de
arquitectura pipeline porque la secuencia de operaciones está enteramente
controlada por una única tarea.
En general, se consideran las arquitecturas timeline y dirigida a eventos como las

alternativas más apropiadas para sistemas monoprocesador, y excepto en el caso
de sistemas muy críticos, se prefiere la segunda a la primera en términos de
mantenibilidad, fiabilidad, coste y complejidad interna. En el caso de aplicaciones
distribuidas la arquitectura pipeline es una buena elección si se resuelven
adecuadamente la gestión de las prioridades de los mensajes, las latencias de
comunicación (generalmente acotadas sólo de forma estocástica) y la utilización de
los procesadores. Pero cuando maduren las infraestructuras para las
aproximaciones cliente-servidor de tiempo real, esta será una alternativa viable y
de peso. Pero no es objetivo de esta tesis el decantarse por el mejor estilo de
arquitectura para SCDTR. En principio, el entorno disciplinar debe tener una
estructura lo suficientemente flexible como para que se puedan desarrollar
sistemas en cualquiera de los estilos de arquitectura descritos, siempre que haya
herramientas adecuadas.
En definitiva, se pueden extraer dos conclusiones:
El estilo de arquitectura elegido para el sistema es un factor importante que

condiciona aspectos como: el tipo de análisis de cumplimiento de plazos que
hay que aplicar, el algoritmo de asignación de prioridades más adecuado, los
recursos que se podrán emplear del lenguaje de programación y del SO, etc.
Por tanto, será algo a tener en cuenta en el entorno multidisciplinar porque
afecta a varias etapas del ciclo de vida.
Por efecto de la conclusión anterior, hay herramientas pensadas para

trabajar únicamente con un estilo concreto de arquitectura. Entre ellas se
pueden mencionar:
o MAST (Modeling and Analysis Suite for Real-Time Applications,

http://mast.unican.es/). Entorno abierto para modelado, análisis y
diseño de sistemas de tiempo real basados en arquitecturas dirigidas a
eventos. Agrupa un conjunto de herramientas de análisis y simulación
que trabajan sobre una descripción del sistema en un fichero ASCII.
Pág. 2-69
Dispone además de una vista de tiempo real (extensión al metamodelo

UML) que permite añadir en UML la información temporal que se requiere
para el análisis posterior y la construcción de un sistema con técnicas
orientadas a objeto (http://mast.unican.es/umlmast/).
o CARTS (Computer Aided Architectural Analysis of Real Time Systems,

http://www.tcpsi.es/carts/). Herramienta para modelar sistemas críticos
basados en componentes con especial atención en el rendimiento de la
arquitectura SW. Se basa en arquitectura pipeline. Utiliza una extensión
al metamodelo UML llamada PPOOA (Processes Pipelines in Object
Oriented Architectures) para incluir elementos constructivos de la
arquitectura pipeline que permitan el análisis de requisitos, el diseño del
sistema y el análisis temporal RMA (Rate Monotonic Analysis) acordes
con los conceptos de pipelines.
Si el estilo de arquitectura mediatiza mucho, aún más lo hace el seguimiento de

una determinada metodología de desarrollo. Se trata de un concepto aún más
amplio que incluye el seguimiento de un determinado Proceso de Desarrollo. Si bien
en el caso de las herramientas anteriores el objetivo era concebir y describir el
sistema en términos adecuados para asegurar su posterior análisis de
planificabilidad, el seguimiento de una metodología de desarrollo constriñe aún más
las decisiones del desarrollador y le guía hasta la implementación final. Por esta
razón, es difícil que colaboren herramientas comprometidas con diferentes
metodologías. A continuación se enumeran algunas de estas metodologías:
ROOM (Real-Time Object Oriented Methodology, Selic et al 1994). Se basa en

el principio de usar el mismo modelo en todas las fases del desarrollo. Los
modelos se componen de actores que se comunican entre sí a través de
mensajes que siguen ciertos protocolos. Los actores pueden ser descompuestos
jerárquicamente y su comportamiento se describe a través de diagramas ROOM
(variante de los diagramas de estado de Harel). La reutilización de actores,
protocolos y comportamientos se consigue a través de la herencia. Ejemplos de
herramientas: EdROOM (Rodríguez Polo 2003), RoseRT (www.rational.com,
antigua ObjecTime). Parece ser que UML 2.0 va a recoger varios de los
conceptos ROOM en lo referente a sistemas basados en componentes.
HRT-HOOD (Hierarchical Object Oriented Design, Burns y Wellings 1995).

Incluye la especificación explícita de restricciones de tiempo e integra
paradigmas de planificación adecuados en el proceso de diseño, permitiendo
realizar un análisis de planificabilidad. Ejemplos de herramientas: TNI
(www.tni-world.com/), OBOSS (On Board Operations Support SW, http://spd-
web.terma.com/Projects/OBOSS/Home_Page/).
OCTOPUS (Award et al 1996). Metodología y conjunto de herramientas

utilizado por Nokia. Pretende ser un puente entre los Sistemas de Tiempo Real
y las tecnologías orientadas a objeto. Basado en metodologías OMT (Object
Pág. 2-70
Modelling Technique) y Fusion enriquecidas con las necesidades de tiempo real:

diseño de concurrencia, procesos, eventos, prioridades y temporización.
ObjectGeode de Telelogic (www.telelogic.com). Esta metodología (que también

da nombre a la herramienta) cubre el análisis, diseño, verificación y validación
a través de la simulación, generación de código y test de aplicaciones
distribuidas y de tiempo real. Soporta una integración coherente basada en los
lenguajes estándares UML, SDL (Specification and Design Language) y MSC
(Message Sequence Char).
Por último, existen otras herramientas que se ocupan únicamente de la parte más
crítica, la del análisis. Parten de un sistema ya diseñado y se analizan las
características temporales del mismo para asegurar su planificabilidad. La labor de
la herramienta empieza y termina en el análisis por lo que es responsabilidad del
usuario la adecuada descripción del sistema en los términos que la herramienta le
exige, así como el uso correcto de los resultados que se infieren. Ejemplos:
RapidRMA de Tri-Pacific (www.tripac.com). Antiguamente denominada PERTS

(Prototyping Environment for Real-Time Systems), es una herramienta de
análisis para garantizar la planificabilidad bajo condiciones de peor caso.
Soporta análisis RMA (Rate Monotonic Analysis), DMA (Deadline Monotonic
Analysis), EDF (Earliest Deadline First), de ejecutivos cíclicos y probabilístico.
Dispone de varias extensions: interfaces a herramientas UML comerciales para
modelar el sistema siguiendo un perfil adecuado que luego permita el análisis
con RapidRMA; simulación de escenarios diferentes al de peor caso; interfaz
con implementaciones Real Time CORBA y VxWorks.
TimeWiz (www.timesys.com) es un entorno para el modelado, análisis y

simulación de la eficiencia y comportamiento temporal del sistema.
BERTA (Basic Environment for Real Time Análisis, ver anexo A.1). Es una
herramienta para realizar análisis de peores tiempos de respuesta extremo a
extremo y simulación de escenarios arbitrarios de activación en sistemas
distribuidos sobre los buses CAN o Profibus.
En resumen, se comprueba que no es homogéneo el espectro de herramientas

porque algunas cubren una sola etapa del desarrollo, otras cubren todas las etapas
siguiendo una determinada metodología y aún otras se construyen alrededor de
una determinada familia de estructuras SW. Además, se emplean diferentes
lenguajes de modelado, notaciones, metodologías, algoritmos de planificación,
arquitecturas, etc. Es muy difícil alinear las herramientas existentes en base a un
criterio claro, pero una tendencia observada en los últimos años es el uso cada vez
más extendido de UML para modelar y diseñar sistemas de muy diferente
naturaleza. Es un lenguaje cada vez es más universal, y si no lo soporta la propia
herramienta es habitual que disponga de un interfaz a otra herramienta puramente
UML. Ahora bien, aunque se esté generalizando su uso, la ‘manera’ de expresar
Sistemas de Tiempo Real en UML dista mucho de ser estándar, de hecho, la versión
Pág. 2-71
actual de UML dista mucho de ser el lenguaje más adecuado para la descripción de
Sistemas de Tiempo Real. Sobre este punto se discutirá en el siguiente apartado.
2.3.3.1 UML para Sistemas de Tiempo Real
A pesar de ser el lenguaje de modelado más ampliamente utilizado en el desarrollo

de SW, es un hecho que UML carece de algunas capacidades necesarias para el
modelado de Sistemas de Tiempo Real como son: calidad de servicio (QoS),
programación de bajo nivel, seguridad, fiabilidad, análisis determinista y generación
de código. Si se quiere generalizar el uso de UML en la fase de modelado de todo
sistema de tiempo real es necesario enriquecer su capacidad expresiva para que
pueda completar los modelos con todos aquellos datos que los métodos de análisis
requerirán en una fase posterior. Se han tomado varias iniciativas para intentar
paliar esta carencia:
Aproximaciones particulares de herramientas comerciales. Hay herramientas

UML que se han especializado en los sistemas de tiempo real, para ello han
tenido que alejarse del cumplimiento riguroso del estándar y han ampliado el
núcleo UML con extensiones propietarias para expresar conceptos de tiempo
real. Funcionalidades adicionales típicas en estas herramientas son la
personalización de la generación de código, la generación de código para RTOS
comerciales y los interfaces con herramientas de ingeniería de requisitos y de
análisis temporal. Los casos más significativos son:
○ Rational Rose RT de IBM (www.rational.com). Se basa en la metodología

ROOM para ampliar UML.
○ Tau de Telelogic (www.telelogic.com). Usa conceptos de SDL (Specification

and Description Language), muy empleado en el mundo de las
telecomunicaciones, para completar UML.
○ RtS de ARTiSAN (www.artisansw.com). Aproximación no basada en ninguna

metodología adicional pero muy volcada en la generación de código en
diversos lenguajes. La herramienta integra un perfil UML propio para
sistemas de tiempo real.
○ Rhapsody de i-Logix (www.ilogix.com). Aproximación basada únicamente en

el estándar pero con una implementación mejorada de los diagramas de
estados.
Perfil RT-UML de OMG ó Perfil UML para Planificabilidad, Rendimiento y Tiempo

(OMG 2003). Las cuatro empresas especializadas en herramientas de modelado
y diseño para tiempo real que se han mencionado (ARTiSAN, Rational, I-Logix,
Telelogic) y dos especializadas en análisis temporal (TimeSys, Tri-Pacific)
lideran esta iniciativa. Es un perfil UML que define paradigmas estándar de
facto para modelar los aspectos específicos del dominio de los sistemas
empotrados o de Tiempo Real. Esto permite construir modelos que puedan
usarse como predicción cuantitativa de la planificabilidad, rendimiento y
Pág. 2-72
latencias del sistema; la comunicación de diseños entre desarrolladores de un

modo estándar y la interoperatividad entre herramientas de análisis y diseño.
Perfiles no comerciales. Extensiones al metamodelo UML para la inclusión de

nuevos elementos constructivos. La ventaja de extender el metamodelo UML
con los mecanismos que indica la norma (perfiles) es que puede emplearse
cualquier herramienta CASE que cumpla el estándar UML para especificar
modelos (instancias) del presente metamodelo. Ejemplos de perfiles:
○ PPOOA (Processes Pipelines in Object Oriented Architectures). Dentro del

entorno de herramientas de CARTS se utiliza este perfil para describir el
sistema con una arquitectura de pipelines que luego se analiza con RMA.
○ UML-MAST. Extensión de UML para dotarle de la capacidad expresiva

requerida para analizar posteriormente el sistema según las técnicas de
análisis soportadas en MAST (http://mast.unican.es).
○ HRT-UML (Mazzini et al 2003). Mapeo de HRT-HOOD a UML promovido por

la Agencia Aeroespacial italiana.
Evidentemente, la adopción de una notación con suficiente riqueza expresiva no es

más que el primer paso. Normalmente, cada aproximación lleva asociada una
Metodología para el Proceso de Desarrollo, que además de la notación definida
lleva consigo el seguimiento de unas etapas, la definición de las entradas y salidas
de cada etapa, el uso de un conjunto de vistas del sistema para el tratamiento de
diferentes problemas, las guías o principios de diseño que se deben seguir, la
identificación de entidades reutilizables a diferentes niveles (componentes,
microarquitecturas, paquetes) y su estructuración en forma de repositorios que
serán consultados y enriquecidos en el proceso, etc. Los aspectos relacionados con
los Procesos de Desarrollo son materia tradicionalmente tratada por la Ingeniería
del SW y se discutirán en el siguiente apartado, pero es clara la relación que estos
tienen con el modelado UML (y con sus variaciones para tiempo real).
Pág. 2-73
2.3.4 INGENIERÍA DEL SW

Las herramientas CASE (Computer Aided Software Engineering) o herramientas de
ingeniería asistida por ordenador son aplicaciones pensadas para dar soporte en el
proceso de desarrollo del SW, es decir, en aquellas labores involucradas en la
Ingeniería del SW. El objetivo último de estas herramientas sería conseguir la
generación automática de programas desde una especificación a nivel de diseño
pero el desglose de los objetivos parciales que persiguen es el siguiente:
9 Aplicación práctica de metodologías de desarrollo
9 Generación de prototipos y conjuntos de aplicaciones con características

genéricas comunes
9 Simplificación del mantenimiento del SW
9 Estandarización de la documentación
9 Aumento de la portabilidad
9 Aumento de la reutilización de componentes SW
9 Permitir el desarrollo visual de aplicaciones mediante gráficos
9 Automatización del desarrollo del SW, la documentación, la generación de

código, la generación de pruebas, el chequeo de errores y la gestión del
proyecto
Sin embargo, el grado de consecución de estos objetivos está relacionado con el

nivel de madurez de la organización. Por extensión, el uso de herramientas CASE
no supone una solución universal ni se puede concebir del mismo modo para
cualquier organización dedicada al desarrollo de SW, sea cual sea su situación. El
Modelo de Madurez de Capacidad SW permite conocer en qué grado una empresa
sigue un Proceso de Desarrollo consolidado, y por tanto, qué beneficios a corto
plazo caben esperar de la implantación de herramientas CASE.
2.3.4.1 Modelo de Madurez de Capacidad Software (CMM)
El modelo de Madurez de Capacidad SW (CMM, Capability Maturity Model for SW)

(Paulk et al 1995) fue formulado a principios de los 80 por el SEI (Software
Engineering Institute) bajo financiación del DoD (Departamento de Defensa
estadounidense) como reacción a la crisis del SW. Constituye un modelo para guiar
a las organizaciones que se centran en desarrollar y mantener SW. Se formula de
una manera genérica, es independiente de cualquier método (o metodología) y de
cualquier ambiente de tecnología (software o hardware). Se especifican unas
prácticas para mejorar los procesos y conseguir mejorar la calidad de los productos
y su mantenimiento. Se intentan potenciar las capacidades, el uso eficiente de
Pág. 2-74
recursos humanos y técnicos. Tiene como pilares los conceptos de calidad total y
mejora continua.
Dentro de este marco de referencia un Proceso puede considerarse maduro si

cumple con los siguientes criterios:
9 Está definido: El proceso es claro, sistemático y suficientemente detallado.
9 Está documentado: Esta escrito en un procedimiento publicado, aprobado y

fácilmente accesible.
9 El personal ha sido entrenado en el proceso: Cada persona ha recibido

entrenamiento en cada proceso que aplica a su trabajo.
9 Es practicado: El proceso definido debe ser usado en las tareas habituales

llevadas a cabo por los proyectos.
9 Es mantenido: El proceso es revisado regularmente, para asegurarse que

está adaptado para satisfacer las necesidades reales de los proyectos.
9 Está controlado: Los cambios y puestas al día del proceso son revisados,
aprobados y comunicados oportunamente a todos los usuarios.
9 Se verifica: Existen mecanismos para asegurarse de que todos los proyectos

siguen el proceso vigente.
9 Se valida: Se asegura que el proceso mantiene concordancia con los

requerimientos y estándares aplicables.
9 Se mide: La utilización, los beneficios y el rendimiento resultante del

proceso se miden regularmente.
9 Puede mejorarse: Existen mecanismos para revisar e introducir cambios en

el proceso, de manera que se pueda mejorar su eficacia e incorporar nuevas
metodologías.
Los Niveles de Madurez se definen para cuantificar la capacidad de los procesos

de Ingeniería de Software y de administración de proyectos usados en una
determinada organización dedicada al desarrollo de software. Entendiéndose que el
Proceso idealmente maduro (el definido anteriormente) tiene un nivel 5, el proceso
de una determinada organización se calificará con un nivel entre 1 y 5, denotando
la cercanía al proceso ideal.
Pág. 2-75
Figura 2-26. Niveles de madurez proyectos SW.
Con excepción del Nivel 1, cada uno de estos Niveles de Madurez está compuesto
por un cierto número de Áreas Claves de Proceso (KPA, Key Process Area). Cada
KPA identifica una agrupación de actividades y prácticas relacionadas, las cuales
cuando son realizadas en forma colectiva permiten alcanzar las metas
fundamentales del proceso. Las KPAs identifican los aspectos que deben tratarse
para conseguir un determinado nivel de madurez.
Se definen cinco niveles de madurez para los proyectos SW de una organización

(Figura 2-26):
Nivel primero o inicial, en que los procesos son inmaduros, nunca han sido
medidos ni controlados. El proceso es ocasional, caótico, ideado ad hoc en cada
proyecto y el éxito depende del esfuerzo individual.
Nivel segundo o repetible, centrado en la administración de proyectos.

Implementación de prácticas mínimas de administración de proyecto, control
de requisitos, versiones de producto, así como de proyectos realizados por
subcontratistas. El grupo o equipo humano que realizó el proyecto puede
aprovechar su experiencia e inversión en procesos para aplicarla en un nuevo
proyecto. KPAs:
○ Gestión de requisitos
○ Planificación del proyecto de software
Pág. 2-76
○ Seguimiento y Supervisión del proyecto
○ Gestión de subcontratos de software
○ Garantía de calidad de software
○ Gestión de configuración del software
Nivel tercero o proceso definido, que se focaliza en el proceso de ingeniería.

La empresa ha definido un conjunto de procesos, metodologías y herramientas
comunes a todos los proyectos iniciados por la corporación. El proceso común
está suficientemente documentado en una biblioteca accesible a todos los
desarrolladores. Todo el personal ha recibido el entrenamiento necesario para
entender el proceso estándar. Existen pautas y criterios definidos para adaptar
dicho proceso a las necesidades y características propias de cada proyecto. El
nivel de definición es detallado y completo. La dependencia (o el riesgo de
depender) en individuos irreemplazables es baja. KPAs:
○ Enfoque en el proceso de la organización
○ Definición del proceso de la organización
○ Programa de entrenamiento
○ Gestión integrada del software
○ Ingeniería de software del producto
○ Coordinación entre grupos
○ Revisión de pares
Nivel cuarto o proceso gestionado (o controlado) en el cual se mejora la

calidad del producto y del proceso. la corporación mide la calidad del producto
y del proceso de software. Ambos, producto y proceso, son seguidos en forma
cuantitativa y se controlan mediante métricas detalladas. La capacidad de
rendimiento del proceso es previsible. Las mediciones permiten detectar
cuando las variaciones del rendimiento se salen de los rangos aceptables, de
manera que se puedan tomar medidas correctivas para asegurar la calidad.
KPAs:
○ Gestión cuantitativa del proceso
○ Gestión de la calidad del software
Nivel quinto, optimizado o de mejora permanente, llegados a este punto

la mejora de los procesos es continua. Este último nivel es utópico. La
característica principal es la mejora continua del proceso, en base a la
realimentación cuantitativa y al ensayo de ideas y tecnologías innovadoras.
KPAs:
Pág. 2-77
○ Prevención de defectos
○ Gestión del cambio de tecnología
○ Gestión del cambio del proceso
En la realidad actual la mayoría de empresas se encuentran entre los dos primeros

niveles.
2.3.4.2 El Proceso de Desarrollo del SW
La ubicación del proceso SW de una organización dentro de uno de los niveles CMM
es importante para ilustrar en qué punto está y cuáles deben ser sus siguientes
objetivos. Al mismo tiempo, permitirá decidir el grado de uso de una herramienta
CASE porque toda herramienta CASE puede ser considerada como centrada en el
Proceso, en el sentido de que su principal papel es el soporte de algún Proceso de
Desarrollo de SW o de una parte de él. De hecho, el Proceso de Desarrollo
soportado puede ser un criterio de clasificación de herramientas CASE, ya que todo
el funcionamiento interno de la herramienta gira alrededor del Proceso. Un Proceso
define quién está haciendo qué, cuándo y cómo alcanzar un determinado objetivo.
Sirve como guía para todos los participantes (clientes, usuarios, desarrolladores y
directivos).
El Proceso más utilizado y mejor documentado es RUP (Rational Unified Process) de

Jacobson et al (2000). Creado de forma paralela a UML a partir de las
aproximaciones de tres grandes especialistas en metodología e integrado en las
herramientas desarrolladas por Rational. Este proceso se caracteriza por estar
dirigido por casos de uso UML (ver Figura 2-27), estar centrado en la arquitectura y
ser iterativo e incremental.
Pero RUP es un proceso genérico de desarrollo de SW y existen también procesos

específicos para sistemas de tiempo real como: OCTOPUS (Award et al 1996) de
Nokia, ROOM (Real-Time Object Oriented Methodology, Selic et al 1994), RT
Perspective method de ARTiSAN (Moore y Cooling 2000) ó ROPES (Rapid Object-
Oriented Process for Embedded Systems) empleado por i-Logix en Rhapsody.
Pág. 2-78
Figura 2-27. RUP dirigido por los casos de uso.
Como ya se avanzaba en el capítulo inicial, el Proceso es clave porque “envuelve”

de alguna forma a todas las herramientas involucradas en el entorno, ya que el
trabajo de éstas estará coordinado de acuerdo a las pautas marcadas por el
proceso. Por tanto, habrá que elegir un Proceso adecuado para los SCDTR. En
principio, ninguno de los mencionados está pensado específicamente para este tipo
de sistemas, pero cabrían adaptaciones. Parece lógico pensar que los procesos
específicos para Sistemas de Tiempo Real son un punto de partida más adecuado y
ajustado que los procesos genéricos de Ingeniería de SW (como RUP).
El entorno multidisciplinar objetivo del presente trabajo de investigación se

estructurará de acuerdo a un Proceso diseñado específicamente para SCDTR. En
cualquier caso, es importante que el usuario del entorno sea capaz de modificar el
Proceso y adaptarlo a sus necesidades porque nadie mejor que él puede diseñar el
proceso más adecuado para su sistema.
2.3.4.3 Estructura de las Herramientas CASE
Las prestaciones ofrecidas en general por las herramientas CASE pueden resumirse
en la siguiente lista:
• Ayudas a la gestión y control del proyecto
• Ayudas a la implantación de una metodología de trabajo para todo el ciclo de

vida
• Creación de modelos gráficos a partir de los requisitos del usuario
• Creación y simulación de prototipos
Pág. 2-79
• Generación automática de código
• Soporte para la realización de pruebas y validación
• Ingeniería inversa para los sistemas ya existentes
Figura 2-28. Clasificación de herramientas CASE en base a las fases del ciclo de
vida cubiertas.
Sin embargo, dependiendo de qué fases del ciclo de vida cubra la herramienta,
pueden distinguirse las siguientes categorías (ver Figura 2-28):
Planificación y control. Los productos IPSE (Integrated Project Environment)

no se encargan de ninguna fase concreta del ciclo de vida, sino que gestionan
informaciones generales del proyecto concreto en desarrollo. En general,
proporcionan la planificación del proyecto y estimación de tiempos, control de la
documentación y de las versiones, registros de eventos y duraciones de los
paquetes de trabajo, informes de situación, historial de fallos e incongruencias.
Planificación estratégica. Son herramientas de ayuda a la planificación de los

sistemas de información. A través de ellas es posible obtener modelos de datos
corporativos de la organización, permiten definir cuales son las prioridades,
asignar los recursos y fijar los plazos de ejecución.
UPPER CASE (CASE superior). Son productos que cubren las primeras fases
del ciclo de vida: planificación, análisis y diseño. Pueden correr en máquinas
independientes a la máquina donde se vaya a ejecutar la aplicación, aunque la
codificación debe desarrollarse de forma independiente, usando la
documentación generada por la herramienta.
Pág. 2-80
LOWER CASE (CASE inferior). Son productos basados en el uso de la propia

máquina a la que se destina la aplicación y están orientados a la generación de
bases de datos, de programas y de ficheros, dando soporte a la parte final del
ciclo de vida, la codificación y las pruebas.
I-CASE ó CASE integrado. Comprende todos los elementos del CASE superior
y del CASE inferior e intentan así cubrir todas las fases.
Reingeniería. Parten de los sistemas de información antiguos (diseñados sin

utilizar herramientas CASE) y, en un proceso inverso, permiten obtener modelos
conceptuales en los que se basa ese código. Una vez formalizados es posible
regenerar el código con una calidad mucho mayor.
A la vista de esta clasificación, se pueden encontrar similitudes entre el entorno

multidisciplinar objeto de esta tesis y los entornos I-CASE. En ambos casos se
intenta cubrir la totalidad del ciclo de vida. Es por ello que, un estudio en mayor
detalle de las herramientas I-CASE puede arrojar algunas pistas sobre las guías a
seguir en el diseño del entorno multidisciplinar para SCDTR.
Los entornos I-CASE persiguen cubrir todo el ciclo de vida de una aplicación, desde
la fase de análisis hasta la codificación y mantenimiento (algunas de ellas incluyen
también la fase de planificación estratégica). Combinan diferentes herramientas y
diferentes elementos de información, de tal forma que permiten el cierre de la
comunicación entre herramientas, entre el personal involucrado y a lo largo de todo
el proceso de ingeniería del software.
Un entorno CASE integrado debe:
• suministrar un mecanismo para que todas las herramientas contenidas en el

entorno compartan la información.
• permitir que los cambios en un elemento de información sea comunicado a

otros elementos relacionados.
• permitir que los usuarios de cada herramienta tengan una visión consistente
de la interfaz hombre-máquina.
• recoger medidas técnicas y de gestión que puedan ser utilizadas para

mejorar el proceso y el producto.
Para llevar a la práctica estas funcionalidades, se estructuran en los siguientes

elementos recogidos de forma esquemática en la Figura 2-29:
Repositorio dónde se almacenan los elementos definidos o creados y de

donde se recuperarán para su reutilización en otros proyectos.
Metamodelo (no siempre visible). Constituye el marco para la definición de

las técnicas y metodologías soportadas por la herramienta. Hace uso de
metadatos.
Pág. 2-81
Interfaces para entrada y salida de datos de otras aplicaciones.
Mecanismos de activación de los diferentes módulos de forma acorde al ciclo

de vida y comprobación de errores para analizar la exactitud, integridad y
consistencia de los esquemas generados por la herramienta.
Interfaz de usuario textual y gráfico.
Interfaz Usuario
Herramienta Herramienta Herramienta

A B C
Mecanismos de Activación y Control de Errores
Metadatos (Metamodelo)
Repositorio
información
Figura 2-29. Elementos necesarios en entorno I-CASE.
La utilización de estándares asentados permitiría la consecución de entornos que

integraran varias herramientas CASE. En este sentido, es interesante anotar que
para cada uno de los tres primeros elementos existen estándares OMG como son
CWM para los repositorios, UML para el metamodelo y XMI para los interfaces.
Siendo MOF el nivel abstracto superior, común a todos los anteriores, que permite
traducciones automáticas entre ellos.
Como desventaja de los entornos I-CASE se puede mencionar la dependencia de un

sólo vendedor. Ésta provoca que no sea posible seleccionar la mejor herramienta
para cada fase y obliga a ceñirse al uso del paquete cerrado que se ha adquirido.
En resumen, el entorno multidisciplinar para SCDTR comparte algunos objetivos

con los entornos I-CASE y para lograrlos requiere de los mismos elementos: un
repositorio de información común a todas las herramientas, un metamodelo en el
que se definan las técnicas y metodologías soportadas en base a ciertos metadatos,
un motor interno de funcionamiento que imponga la forma predeterminada de
trabajo en todas las fases, interfaces estándar para intercambio de datos,
comprobación global de errores, integridad y consistencia y una interfaz de usuario
común a todas las herramientas.
Así mismo, para evitar las desventajas encontradas en entornos I-CASE en cuanto
a dependencia de un solo fabricante, debería fundamentarse en una arquitectura:
Pág. 2-82
Propia. No basada en ninguna herramienta comercial concreta.
Flexible. Adaptable con facilidad a nuevas necesidades. La visibilidad del

metamodelo permitiría su modificación.
Abierta. Capaz de integrar la más adecuada de las herramientas comerciales en

cada caso. El uso de estándares para la implementación de cada uno de los
elementos facilitará esta labor.
2.3.4.4 Lenguajes de Descripción de Arquitecturas
A pesar de que se ha generalizado el empleo de UML para modelar la arquitectura

(además de otras cosas), también tienen validez otros tipos de lenguajes como MIL
(Module Interconnection Languages) ó ADL (Architecture Description Languages)
para definir la arquitectura del SW.
Tradicionalmente, el modelado de la arquitectura SW se ha hecho a través de

lenguajes sencillos como los lenguajes MIL, que nacieron en los 70 como ayuda
para la interconexión de subsistemas desarrollados independientemente. Sirven
para representar componentes y los flujos de información entre ellos. Evolucionan
hacia ADLs cuando son completados con nociones de protocolos de comunicación
(generalizan el concepto de conector más allá de la invocación de un método) y con
constructores para definir las propiedades semánticas en función del sistema (se
adaptan a diferentes tipos de sistemas).
Los lenguajes ADL describen la estructura y el comportamiento de un sistema SW,

así como de las entidades no-SW con las que interactúa. Los sistemas se
representan formalmente (o semi-formalmente) como un conjunto de
componentes, sus conexiones (ver Figura 2-30) y sus interacciones de
comportamiento. Esta representación promueve el mejor entendimiento del
sistema, un diseño más preciso y es la base de un análisis riguroso del diseño.
Pág. 2-83
Figura 2-30. Ejemplo de descripción en ADL (Darwin).
Por extensión, también se denominan ADLs a los entornos que, además de editores
gráficos y textuales, añaden otras funcionalidades como compiladores,
comprobadores de requisitos, simuladores, etc. Existen múltiples ejemplos de ADLs
desarrollados por Honeywell (Meta-H), Carnegie-Mellon (ACME, AESOP, UNICON y
WRIGHT), Universidad de Texas (GEN-VOCA), Universidad de Stanford (RAPIDE),
Universidad de California Irvine (xADL), Imperial College (Darwin), etc.
Existen algunos esfuerzos de estandarización en el uso de este tipo de lenguajes.

Por ejemplo, AADL (The Avionics Architectural Description Language) está siendo
desarrollado por la SAE (Society of Automotive Engineers, www.sae.org), ADML
(Architecture Description Markup Language) del Open Group (www.opengroup.org)
y el estándar 1471 de IEEE “Recommended Practice for Architectural Description of
Software-Intensive Systems” (www.pithecanthropus.com/~awg/public_html/).
El uso de ADLs para la descripción de un sistema SW enfatiza la importancia de la

arquitectura en la concepción global del sistema y en su influencia a lo largo de
todo el ciclo de vida, y por tanto, de todas las herramientas de apoyo empleadas.
La importancia que en los Sistemas de Tiempo Real se da al estilo de arquitectura
debe ser refrendada por un lenguaje apropiado, capaz de describir sistemas de
acuerdo a los conceptos que recoja su estilo estructural. Para este papel, los ADLs
son grandes candidatos. En esta línea, el grupo ABLE (Architecture Based
Languages and Environments) de Carnegie-Mellon tiene en Aesop (SW Architecture
Design Environment Generator) una herramienta para la construcción de entornos
de desarrollo SW basados en el estilo de arquitectura que el usuario describa.
No ha sido difícil descubrir que XML es muy bueno para representar

especificaciones y que es la notación estándar perfecta para servir de base a los
lenguajes MIL ó ADL (Pruitt et al 1998). Existen múltiples aproximaciones al
respecto, por citar sólo algunas:
Pág. 2-84
BML (Bean Markup Language) es un lenguaje basado en XML para

configuración de componentes basados en el modelo de componentes JavaBean
(www.alphaworks.ibm.com/tech/bml).
xArch (www.ics.uci.edu/pub/arch/xarch/) es un esfuerzo por separarse de los

ADLs propietarios y acercarse a conjuntos de herramientas más abiertos y
flexibles. El núcleo de xArch incluye los elementos comunes a la mayoría de las
arquitecturas SW (componentes, conectores, interfaces y enlaces) y no impone
ningún requisito en la forma en que estas entidades se comporten o se
agrupen. Cuando los diseñadores SW quieran añadir propiedades al lenguaje de
representación para modelar aspectos específicos de su SW, pueden extender
el lenguaje manteniendo la compatibilidad con el núcleo e incrementando las
funcionalidades (como hace xADL). Provee de un núcleo común de notación
XML que puede servir como:
○ Representación independiente para modelado de arquitecturas.
○ Punto de partida para la definición de otras notaciones de arquitectura más

avanzadas y basadas en XML, a través de extensiones del namespace.
○ Mecanismo de intercambio para descripciones de arquitecturas. Pueden

construirse traductores entre cualesquiera lenguajes y xArch, que serviría
como punto de unión.
ADML (www.opengroup.org) es un lenguaje basado en ACME (Carnegie-Mellon)

para la interoperatividad y reutilización de arquitecturas a través de todo tipo
de herramientas (ver Figura 2-31). Gracias a XML, se dota al lenguaje de una
representación estándar (empleo de pársers estándar), de la capacidad de
definir enlaces a objetos fuera de la arquitectura, de la posibilidad de
interactuar con repositorios comerciales y de extensibilidad transparente.
Business Architecture Design Development Test Management

Tools Tool Tools Tools Tools Tools
.xyz .*ml .uml .uml .?ml .?ml

ADML ADML ADML ADML ADML ADML
ADML
(components, connectors, ports, roles, properties, systems, representation maps
Figura 2-31. Interoperatividad a través de ADML.
En resumen, los lenguajes ADL presentan una manera precisa de especificar la

arquitectura SW del sistema y pueden servir de soporte para la información que va
a ser consultada y modificada en las diferentes fases del ciclo de vida. Aún más, la
reciente introducción de XML como tecnología de implementación de los ADLs hace
más sencilla y estándar la colaboración entre herramientas a través de
descripciones del sistema hechas en ADL y expresadas en XML.
Pág. 2-85
Pág. 2-86
22..44 A
APPRRO
OXXIIM
MAAC
CIIO
ONNE
ESS A
ALLA
A
IIN
NTTE
EGGR
RAAC
CIIÓ
ÓNND
DEEH
HEERRRRAAM
MIIE
ENNT
TAASS
Algunas entornos abiertos (no propietarios) de integración desarrollados

por otros grupos de investigación.
Se entiende como sistema de arquitectura abierta aquel que es flexible, adaptable y

capaz de integrar muchos productos de fuentes diversas, no diseñados
originalmente para trabajar en conjunto y desconocidos en el momento de creación
del sistema. En este apartado se describen algunos entornos con arquitectura
abierta que, a diferencia de las soluciones comerciales cerradas comentadas en el
apartado anterior, permiten su adaptación.
Un término que aparece repetidamente para denominar a este tipo de entornos es

el de Framework. Según la definición de Lee (2000), un Framework impone un
conjunto de requisitos a los componentes implicados y a las relaciones entre ellos y
de las restricciones o especializaciones impuestas se derivan un conjunto de
beneficios. Lee distingue cuatro categorías de servicios ofrecidas por la mayoría de
los Frameworks:
• Ontología. Se define qué significa ser un componente, además de ciertas

propiedades semánticas.
• Epistemología. Se definen los estados de conocimiento. Qué sabe el

Framework sobre los componentes, qué saben ellos sobre otros, qué
información comparten, reglas de alcance,…
• Protocolos. Mecanismos que indican cómo interactúan los componentes.
• Léxico. Vocabulario de la interacción entre componentes.
En el área específica de la programación concurrente un framework permitirá

expresar threads (ontología), mecanismos para la gestión de la memoria
compartida (epistemología), semáforos (protocolos) y objetos (léxico). Pero existen
frameworks para Sistemas Operativos, lenguajes de programación, middlewares
(CORBA, DCOM), Java, etc.
Un diseñador de cualquier tipo de sistema necesita conocer y manejarse con soltura

en uno o dos frameworks para llevar a cabo su trabajo especializado. Por eso en el
primer apartado se analizarán algunos entornos capaces de integrar soluciones
orientadas a un determinado dominio (Soluciones Particulares de Dominio)
mediante la gestión de un framework específico.
Pág. 2-87
Sin embargo, cuando el sistema en desarrollo es complejo y no asumido al

completo por ningún dominio específico, se requiere del conocimiento de varios
frameworks. Esto complica el entorno de desarrollo porque se requiere de mayor
generalidad y flexibilidad, y de la gestión coordinada de varios frameworks. En esta
línea, se comentarán algunos entornos que son abiertos tanto en su arquitectura
como en el último propósito de cada una de las herramientas y de todo el conjunto
general (Soluciones Genéricas. METAframework). Como resultado de este análisis
se extraerán algunas ideas sobre aspectos no considerados hasta ahora en el
entorno multidisciplinar.
Pág. 2-88
2.4.1 SOLUCIONES PARTICULARES DE DOMINIO

Se analizarán las características de dos entornos de herramientas orientados hacia
áreas concretas del conocimiento: Netbeans para la generación de clientes Java y
Ptolemy para el diseño de SW de sistemas empotrados.
2.4.1.1 NetBeans
Se trata de un entorno particular de un dominio puesto que se especializa en aunar

utilidades para facilitar la generación de aplicaciones Java.
La mayoría de las aplicaciones de sobremesa tienen requisitos comunes: menús,

gestión de documentos, configuración, etc. Es tedioso escribir una y otra vez la
implementación de estos elementos. Si todo ello está ya desarrollado en forma de
módulos configurables, el diseñador puede centrarse en el verdadero valor añadido
de su aplicación. Con este objetivo surge NetBeans en la forma de un IDE
(NetBeansIDE) para desarrolladores Java y de una plataforma (NetBeans Platform)
que proporciona una infraestructura (‘runtime’) para la ejecución de aplicaciones
complejas. Funcionalidades de NetBeansIDE:
9 Gestión del interfaz de usuario
9 Gestión de datos y representación
9 Editor
9 Gestión de configuración
9 Generación de wizards para guiar a los usuarios en las tareas más complejas
9 Gestión de almacenamiento
9 Plataformas cruzadas diversas
9 Ejemplos de casos de uso (Poseidon, herramienta UML)
Sobre el runtime se hacen correr los módulos propios (ficheros .jar) que
implementan la funcionalidad específica y han sido desarrollados en el IDE. El
resultado final puede distribuirse o venderse. Los módulos, que poseen ficheros con
información sobre sus contenidos, interactúan con los APIs de NetBeans.
El ámbito de uso de este entorno es el del desarrollo de ‘clientes gruesos’. Netbeans

es para éstos lo que J2EE es para la parte servidora de las aplicaciones, es decir:
9 Un contexto de ejecución para la aplicación desarrollada
9 Un conjunto de herramientas de desarrollo
Pág. 2-89
9 Un conjunto de abstracciones que permiten la reutilización de componentes
9 Un conjunto de estándares para enfatizar la interoperatividad y empleo de

aplicaciones y plataformas
2.4.1.2 Ptolemy
Ptolemy (Hylands et al 2003) es un proyecto desarrollado por un grupo de

investigadores que forman parte de Chess (http://chess.eecs.berkeley.edu). Su
objetivo es la investigación de los fundamentos del diseño de sistemas empotrados
y su aplicación para la generación del código final. Ptolemy II supone la tercera
generación de SW de diseño de este grupo (Gabriel y Ptolemy Classic han sido las
anteriores) y su infraestructura está publicada en forma de código Java abierto, con
editores gráficos sobre Swing y XML para la representación persistente de los
datos.
Los principales conceptos de diseño de Ptolemy son los siguientes:
• Polimorfismo de dominio. Los componentes pueden ser diseñados para

operar en múltiples dominios.
• Modelos modales. Las máquinas de estados finitos se combinan

jerárquicamente con otros modelos de computación.
• Diseño orientado a actores (Agha 1986), tal y como se hace con la

metodología ROOM (y hacia donde parece dirigirse UML 2.0) y con las
herramientas particulares Simulink ó LabView. Los sistemas de diseño
basados exclusivamente en tipos describen sólo la estructura estática (la
sintaxis de los programas procedurales), pero no describen la dinámica y la
concurrencia del programa. Los actores y los objetos activos componen un
modelo formal de concurrencia y así se completa el diseño orientado a
objetos enfatizando la concurrencia y la comunicación entre componentes.
• Sintaxis abstracta compuesta por los conceptos de modelo, actor,

puerto, parámetro y canal puede representarse de diversas formas
(varias sintaxis concretas). La semántica (ortogonal a la sintaxis) es
determinada por el modelo de computación, que puede dar reglas de
operación para la ejecución de un modelo, define la naturaleza de las
comunicaciones entre componentes, etc.
• Modelos de computación. Conjunto de reglas o semánticas que gobiernan

la interacción de los componentes en el modelo, proporcionan un framework
en el que el diseñador construye modelos. Se elegirá un modelo de
computación adecuado en cada caso: para la transformación de unos datos
en otros se usa la semántica imperativa propia de lenguajes de
programación; para modelado de sistemas físicos se requiere concurrencia y
tiempo continuo como en Simulink o VHDL, etc. La capacidad de un modelo
de convertirse en una implementación depende mucho del modelo de
Pág. 2-90
computación. Los modelos de computación se describen en un metanivel.

Agrupan patrones de diseño para la interacción de componentes. Todos ellos
comparten una representación común en forma de nodos (entidades) y
arcos (relaciones). Existe un director de dominio para cada modelo de
computación:
o CI (Component Interaction). Sistemas que mezclan un estilo de

diseño dirigido a datos y a demandas. Por ejemplo, las interacciones
a través de web.
o CSP (Communicating Sequential Processes). Procesos concurrentes

que se comunican por rendezvous.
o CT (Continuous Time). Interacción de actores a través de señales de

tiempo continuo. Colaboración con los modelos de eventos distretos
(DE) y con las máquinas de estados finitos (FSM) para el modelado
de señales mixtas y el de modos y sistemas híbridos,
respectivamente.
o DE (Discrete Events) y DDE (Distributed Discrete Events). Eventos

discretos.
o SDF (Synchronous Dataflow). Diagramas de flujo síncronos.
o DT (Discrete Time). Tiempo discreto, extiende SDF.
o FSM (Finite State Machines). Las entidades son estados, no actores,

y las conexiones representan transiciones.
o PN (Process Networks). Envío de mensajes a través de canales con

buffer.
o Giotto. Cada actor es invocado periódicamente con un periodo

específico. Pensado para sistemas de tiempo real estricto.
o SR (Synchronous/Reactive).
o TM (Timed Multitasking). Asume un planificador basado en prioridad

y con desalojo pero permite diseño de sistemas más deterministas
que el uso ad hoc de Sistemas Operativos de Tiempo Real.
El diseño de cualquier sistema estará basado en modelos, actores, puertos,

parámetros y canales formando una estructura jerárquica. Estos elementos
interactúan según la semántica impuesta por el modelo de computación (expresado
en forma de nodos y arcos). Los componentes y los dominios pueden tener
definiciones de interfaces que describan la estructura estática pero también el
comportamiento dinámico.
Las entidades director y manager gobiernan la ejecución de una entidad

compuesta y del modelo general, respectivamente. Un director local es responsable
Pág. 2-91
de la ejecución (planificación, instanciación de threads necesarios, generación de

código) de los componentes dentro de un agregado. Si un agregado no tiene
director el responsable de la ejecución de sus componentes es el director del nivel
superior (como si la estructura fuera plana).
No se usa un lenguaje de descripción de arquitecturas (ADL) sino un lenguaje de

diseño de arquitectura porque el objetivo es promover arquitecturas SW coherentes
imponiendo ciertas estructuras a las interacciones. Más que describir componentes
que existen hay que envolverlos en actores. Se estructura como un conjunto de
paquetes que dan soporte genérico a todos los modelos de computación. Las
semánticas abstractas presentes en todos los diseños permiten interoperar a los
dominios. Los paquetes se interfaz de usuario acceden al formato persistente XML
que emplea el lenguaje MoML (Modeling Markup Language).
Pág. 2-92
2.4.2 SOLUCIONES GENÉRICAS (METAFRAMEWORK)

Lee (2000) propone las siguientes aproximaciones para la definición de un único
entorno que integre todas las tendencias presentes en el diseño de sistemas
empotrados:
Unión de todos los frameworks existentes en uno solo. Opción muy

compleja que hace difícil la validación y el uso.
Elección de un framework y definición de los demás como casos especiales

de éste. Esta solución no reconoce las fortalezas y debilidades de cada uno.
Empleo de ADLs para definir un framework. La parte difícil de esta

aproximación es conseguir que un solo ADL sirva para describir cualquier
arquitectura. Se necesita más bien un lenguaje de diseño de arquitecturas para
poder describir arquitecturas futuras y no sólo las que ya existen.
Mezcla heterogénea de frameworks preservando sus distintas identidades.

Cuanto más especializado (mayor número de requisitos recogidos) es un
framework mayores beneficios se obtienen, pero a la vez, será más difícil de
emplear en sistemas complejos diferentes. Para conjugar ambas cualidades se
requiere la mezcla heterogénea de frameworks.
Esta última aproximación conduce a la creación de un METAframework que

provea de la infraestructura necesaria para la composición de frameworks. A
continuación, se describen dos METAframeworks que constituyen soluciones
genéricas adaptables a cualquier dominio de aplicación.
2.4.2.1 Generic Modelling Environment (GME)
GME es un conjunto de herramientas configurable que soporta la creación de

entornos de modelado para dominios específicos. Los modelos luego se emplean
para construir la aplicación o para generar entradas a herramientas de análisis
COTS. Los modelos de computación de Ptolemy están creados a través de GME.
Los entornos de diseño de dominio específico capturan especificaciones y

automáticamente generan o configuran las aplicaciones para campos particulares
de la ingeniería. Por ejemplo, es lo que hacen las herramientas matlab/simulink
para el procesado de señales o LabView para la instrumentación. Pero no es
rentable económicamente el desarrollo de entornos de dominio específico para
campos de aplicación muy concretos.
La solución es un entorno de diseño configurable para un amplio rango de dominios

(METAframework). Un entorno así debe proveer un conjunto de conceptos
generales suficientemente abstractos para que sean comunes a la mayoría de los
dominios: contenido (composición, agregación, jerarquía), interconexión de
Pág. 2-93
módulos, modelado multi-vista, herencia y atributos numéricos y textuales. Estos

conceptos serán instanciados o configurados para cada dominio.
Figura 2-32. Fundamentos de GME.
Figura 2-33. Entorno GME.
La configuración se logra a través de metamodelos que especifican el paradigma de

modelado (lenguaje de modelado) propio de un dominio de aplicación. El paradigma
de modelado define la familia de modelos que pueden ser creados usando el
Pág. 2-94
entorno resultante. La definición de un paradigma de modelado puede considerarse

como otro problema de modelado en sí mismo, y como tal, también se resuelve en
GME (es como escribir en C compiladores para C). El paradigma está basado en
UML. Las definiciones sintácticas se hacen con diagramas de clases y las
semánticas estáticas con OCL. La información de presentación necesita de ciertas
extensiones a UML.
Cada nivel se describe en términos del superior (Figura 2-32). Por ejemplo, un
lenguaje de máquinas de estados finitos se describe en UML instanciando los
conceptos básicos de GME (Figura 2-33).
2.4.2.2 Eclipse
Eclipse (http://www.eclipse.org) es un proyecto de software abierto que persigue la

creación de un entorno público de herramientas de desarrollo SW, una plataforma
universal de herramientas orientadas a la creación de aplicaciones. Tal y como se
explica en su web: un IDE abierto y extensible para cualquier cosa y para
nada en particular. El proyecto fue lanzado por IBM en noviembre de 2001 con
una donación de 40 millones de dólares, pero hoy en día está soportado por un
consorcio de compañías de entre las que cabe destacar IBM, Rational, Intel, Fujitsu,
QNX, RedHat, Sybase, Borland, Hitachi, HP ó SAP y organizaciones como OMG. De
todos modos, lo más importante no son los nombres de estas compañías privadas,
sino su apuesta decidida por este proyecto de SW abierto. Sólo con esta filosofía
puede alcanzarse el ambicioso objetivo de construir una plataforma ‘universal’. Así,
los resultados que ya se han obtenido en la versión 2.1 (marzo de 2003) son muy
importantes y esperanzadores de cara a un futuro próximo.
El núcleo de la plataforma Eclipse es independiente de cualquier aproximación de

desarrollo de SW. Las herramientas son ‘concectadas’ a Eclipse para ofrecer sus
capacidades específicas orientadas a tipos de desarrollo determinados.
Pág. 2-95
Another
Eclipse Platform
Tool
Java Workbench Help

Development
Tools JFace
(JDT)
SWT
Team Your
Tool
Plug-in Workspace
Development Debug
Environment
(PDE)
Their
Platform Runtime Tool
Eclipse Project
Figura 2-34. Arquitectura de Eclipse
La arquitectura (ver Figura 2-34) está basada en plugins Java que permiten la
integración de herramientas manipulando tipos de contenidos arbitrarios. El plugin
es la unidad mínima de funcionalidad en Eclipse, puede abarcar desde un editor
HTML completo hasta una acción para crear ficheros ZIP. Los plugins no tienen
porqué estar aislados entre sí, pueden comunicarse a través de puntos de
extensión. Cada plugin tiene un manifiesto expresado en XML (declaración de sus
puntos de extensión y sus interconexiones a otros plugins) y su propio java class
loader.
El WorkBench o Espacio de Trabajo agrupa al conjunto de ficheros de usuario sobre

los cuales operan las diferentes herramientas. Es la manera de organizar y
almacenar fuentes de información diferentes que pueden ser empleadas por
diferentes herramientas dentro de un mismo proyecto.
Otro elemento integrador en Eclipse es el interfaz de usuario, construido sobre los

toolkits SWT y JFace. La presentación de la información sigue unas guías comunes
a todas las herramientas (uso de vistas, editores y perspectivas) y existe un
paradigma común de interfaz de usuario.
Además, existen otros bloques comunes como son los de ayuda al usuario o los de
internacionalización (10 idiomas soportados en la última versión).
El trabajo realizado alrededor de Eclipse se organiza en cuatro conjuntos básicos de

proyectos:
Pág. 2-96
Eclipse. Adaptación y evolución de la plataforma para cumplir con las

necesidades de la comunidad y los usuarios y convertir a Eclipse en una
plataforma de referencia para la industria. Subproyectos (Figura 2-35):
○ Plataforma. Define el conjunto común de frameworks y servicios que forman

el integration-ware ó SW creado para integrar componentes.
○ JDT (Java Development Tools). Avanzado entorno de desarrollo Java que

reúne la gran mayoría de las funcionalidades de los actuales entornos de
desarrollo Java comerciales.
○ PDE (Plugin Development Environment) se apoya sobre JDT para ofrecer un

conjunto de herramientas especializadas en el desarrollo de plugins Eclipse.
De alguna forma, se trata del IDE para el desarrollo de nuevos IDEs o el
entorno para ampliar y mejorar las funcionalidades de Eclipse. La creación
de un plugin incluye: creación del manifiesto (plugin.xml), especificación del
código a ejecutar y de otros plugins necesarios, definir puntos de extensión
junto a los XML Schemas que servirán para validar las extensiones (otros
manifiestos), etc.
Entorno para desarrollo PDE

de plugins
Java Development JDT

Tools
Plataforma Eclipse Eclipse
Standard Java2
Java VM
Virtual Machine
Figura 2-35. JDT y PDE sobre Eclipse.
Herramientas Eclipse. Creación, sobre Eclipse, de un amplio abanico de

herramientas de alto rendimiento para campos específicos. Se pretende
coordinar los esfuerzos para maximizar el rendimiento y el uso de componentes
comunes y para evitar proyectos duplicados o solapados. Subproyectos:
○ Hyrades. Herramientas ASQ (Automated Software Quality).
○ CDT (C/C++ Development Tools). IDE para C y C++.
○ GEF (Graphical Editor Framework). Creación de editor gráfico a partir de un

modelo de aplicación.
○ Cobol IDE.
Pág. 2-97
○ EMF (Eclipse Modelling Framework). Este subproyecto tiene gran interés de

cara al modelado formal. Se trata de un framework Java/XML para generar
herramientas y aplicaciones basadas en modelos de clases. A partir del
modelo (en Java anotado, schema XML, XMI o fichero UML de Rational) de
la aplicación genera las clases Java para el modelo, clases adaptadoras que
permiten ver y editar el modelo a través de comandos y un editor básico.
Permite beneficiarse rápidamente de las ventajas del modelado formal ya
que la aplicación completa puede regenerarse cada vez que es modificado el
modelo. Igualmente, los cambios en el código Java también actualizan el
modelo. Lo más importante es que EMF provee de todo lo necesario para
lograr la interoperatividad entre todas las herramientas basadas en EMF.
Resumen de las características de EMF:
∗ Generación configurable del código completo para la aplicación a

partir del modelo. Pueden emplearse plantillas de usuario, escritas
empleando un subconjunto de la sintaxis de JSP, para dirigir esta
generación de código gracias a las herramientas JET (Java Emitter
Templates) y JMerge (Java Merge). JET es un motor de plantillas genéricas
que puede emplearse para generación de SQL, XML, Java u otros formatos
de salida.
∗ Entrada del modelo en diversos formatos: Java anotado modelo UML

de Rational Rose, schema XML, editor gráfico, fichero XMI
∗ Serialización del modelo en formato XMI o XML acorde con un

Schema.
∗ Generación automática de visores estándar y editores para el modelo

de datos de la aplicación.
∗ Manipulación dinámica de objetos de los modelos desde diferentes

herramientas a través de API estándar.
Tecnologías Eclipse. Creación de nuevos canales para que los usuarios

participen en la evolución de Eclipse. Estos esfuerzos se dividen en proyectos
de investigación sobre dominios relevantes para Eclipse, proyectos de
aplicación que añaden nuevas capacidades al SW base de Eclipse y proyectos
de desarrollo de material didáctico. Subproyectos:
○ Generative Model Transformer. Construcción y ensamblado de herramientas

Eclipse con soporte para el desarrollo de SW según MDA.
○ Equinox. Investigación de técnicas para superar las limitaciones de la

configuración estática de herramientas en Eclipse. Servicios como gestión y
reducción de dependencias entre plugins, descubrimiento dinámico de
servicios o mecanismos estándar de distribución de componentes.
Pág. 2-98
○ AspectJ Development Tools Project (AJDT). Proporciona a Eclipse de

herramientas para desarrollar SW de acuerdo a técnicas AOSD (Aspect
Oriented Software Development).
○ Koi. Conjunto de componentes Eclipse para soportar el desarrollo de

actividades de colaboración dinámicas y de granularidad fina. Se trata de
funcionalidad en las que participan múltiples usuarios corriendo diferentes
instancias de Eclipse.
○ Stellation. Sistema de gestión de la configuración de SW basada en la

integración de técnicas SCM (Source Code Management).
○ XSD. XML Schema Infoset Model es una librería de referencia que

proporciona un API para usar en cualquier código que examine, cree o
modifique schemas XML. Con esta API pueden manipularse los componentes
del schema, así como su representación DOM, y mantener ambas
coherentes. Se incluyen servicios como serialización y deserialización de
schemas o comprobaciones de integridad.
Plataforma herramientas web. Construcción de frameworks y servicios

comunes para el desarrollo de herramientas que puedan funcionar en cualquier
servidor de aplicaciones web que soporte la especificación J2EE.
Toda esta jerarquía de proyectos interrelacionados y en desarrollo sirve para

hacerse una idea bastante adecuada de la versatilidad y generalidad de Eclipse. En
http://eclipse.org/community/plugins.html puede accederse a un creciente listado
de productos comerciales desarrollados sobre eclipse y de proyectos de código
abierto sobre Eclipse. Además de aprovecharse de la infraestructura de la
plataforma, los proyectos desarrollados para Eclipse cuentan con la enorme ventaja
de poder colaborar entre ellos. Los proyectos, aún cuando en el momento de su
desarrollo no se conocieran entre sí, pueden colaborar gracias a estar basados en la
misma plataforma común.
Pág. 2-99

4+1 Vistas y Mas Ion

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

4+1 Vistas y Mas Ion

Uploaded by

Copyright:

Available Formats

2 ESTADO DEL ARTE

Posteriormente, el estudio se centra en las Herramientas Específicas de

2.1.2 Modelo de 4+1 vistas

2.1.3 UML (Unified Modeling Language)

2.1.4 Estándares OMG

2.1.5 UML 2.0

2.2 Lenguajes Formales

2.2.4 Generación de Gramáticas a partir de Modelos UML

2.3 Herramientas Específicas de Dominio

2.3.2 Sistemas Distribuidos

2.3.3 Sistemas de Tiempo Real

2.3.4 Ingeniería del SW

2.4 Aproximaciones a la Integración de Herramientas

2.4.2 Soluciones genéricas (METAframework)

Sobre la construcción de un modelo como abstracción de la realidad y

2.1.1 NIVELES DE ABSTRACCIÓN

El uso de la abstracción permite describir, representar, manejar y resolver

En general, pueden definirse tantos niveles de abstracción como se precise para

La representación abstracta de la información es la base en la que se fundamenta la

programación en lenguajes de alto nivel, generación de compiladores, modularidad

Tabla 2-1. Niveles de abstracción en el modelado.

NIVELES DE ENTIDADES LENGUAJES DEFINIDOS

Meta-metamodelo Meta-modelos Lenguaje para la descripción de diferentes tipos de

Meta-modelo Meta-metadatos ó Lenguaje para la descripción de diferentes tipos de datos

Modelo Meta-datos Lenguaje para la descripción de datos concretos

• Nivel de Información. Agregación ‘informal’ de datos a manejar en un

• Nivel de Modelo. Agregación ‘informal’ de meta-datos (datos sobre los

• Nivel de Meta-modelo. Agregación ‘informal’ de modelos o meta-

• Nivel de Meta-metamodelo. Definición de la estructura y la semántica de

modelo que defina el lenguaje con el que describir formalmente al modelo, de

Tabla 2-2. Ejemplo de abstracción jerárquica: lenguajes de programación.

Meta-lenguaje Lenguajes de Lenguaje para la descripción de diferentes lenguajes

Tipos de datos TYPE Lenguaje para la descripción de tipos de datos como

tCuenta = RECORD ...

Variables Nombre, Número Lenguaje para la descripción de variables (y

Información bancaria ‘Aitor Pérez’, 1253456,...

En el caso particular de la programación orientada a objetos se puede decir que los

En general, se puede aplicar el modelado jerárquico en cualquier ámbito, teniendo

Figura 2-1. Arquitectura de metamodelado de UML en 4 niveles.

La Figura 2-1 representa la arquitectura de UML (lenguaje de modelado que se

2.1.2 MODELO DE 4+1 VISTAS

o Componentes: clase, clase parametrizada, categoría de clases

o Conectores: asociación, agregación, uso, herencia, instancia

• Vista de Proceso. Los integradores del sistema la emplean para expresar

o Componentes: proceso, proceso simple, periodicidad

o Conectores: mensaje, RPC (Remote Procedure Call), mensaje

• Vista de Desarrollo. Los programadores la emplean para describir la

o Componentes: módulo, subsistema, nivel

o Conectores: referencia, dependencia de compilación

• Vista Física. Los ingenieros de sistema definen aquí el mapeo del SW en el HW

o Componentes: procesadores, otros dispositivos

o Conectores: línea de comunicación permanente o no, bidireccional o

• Escenarios ó casos de uso. Ilustran el uso y las relaciones entre el resto de

o Componentes: actores, casos de uso

Cada vista posee diferentes:

2.1.3 UML (UNIFIED MODELING LANGUAGE)

Debido a que UML evolucionó a partir de varios métodos orientados a objeto de

Figura 2-3. UML como fusión de varios lenguajes de modelado.

UML es un lenguaje de modelado para la especificación, visualización,

 Como lenguaje, se emplea para la comunicación, es decir, como medio

 Como lenguaje de modelado, se centra en la comprensión del sistema a

vocabulario y reglas se centran en la representación conceptual y física de

 En cuanto a cómo se aplica para especificar sistemas, se puede utilizar

Como lenguaje, se emplea para la comunicación, es decir, como medio

Como lenguaje de modelado, se centra en la comprensión del sistema a

En cuanto a cómo se aplica para especificar sistemas, se puede utilizar

En cuanto a cómo se aplica para visualizar sistemas, se puede usar para

En cuanto a cómo se aplica para construir sistemas, se puede emplear

En cuanto a cómo se aplica para documentar sistemas, se puede utilizar

Un lenguaje de programación visual, sino un lenguaje de modelado visual.

Una herramienta de especificación, sino un lenguaje para modelado de

Un proceso, sino que habilita procesos.