4+1 Vistas y Mas ion

222 EEESSTTTAAADDDOOO DDDEEELLL AAARRRTTTEEE S

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

222...111 MMMOOODDDEEELLLAAADDDOOO

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.

22..11..11 NNIIVVEELLEESS DDEE AABBSSTTRRAACCCCIIÓÓNN

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 ABSTRACCIÓN

ENTIDADES MANEJADAS

LENGUAJES DEFINIDOS

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

Meta-modelo Meta-metadatos ó Modelos

Lenguaje para la descripción de diferentes tipos de datos (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.

NIVELES ENTIDADES MANEJADAS

LENGUAJES

Meta-lenguaje programación

Lenguajes de programación

Lenguaje para la descripción de diferentes lenguajes de programación

Lenguaje programación Sentencias control flujo, variables, tipos,…

Lenguaje para la descripción de programas como modelos de ejecuciones

Tipos de datos TYPE

tNombre = string [20];

tCuenta = RECORD ...

Lenguaje para la descripción de tipos de datos como modelos de variables

Variables Nombre, Número cuenta,...

Lenguaje para la descripción de variables (y 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


22..11..22 MMOODDEELLOO DDEE 44++11 VVIISSTTAASS

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


22..11..33 UUMMLL ((UUNNIIFFIIEEDD MMOODDEELLIINNGG LLAANNGGUUAAGGEE))

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.

UML

RumbaughJacobson

Meyer

Harel

Wirfs-Brock

FusionEmbly

Gamma et. al.

Shlaer-Mellor

Odell

Booch

Pre- and Post-conditions

State Charts

Responsabilities

Operation descriptions, message numbering

Singleton classes

Frameworks, patterns, notes

Object life cycles UML

RumbaughJacobson

Meyer

Harel

Wirfs-Brock

FusionEmbly

Gamma et. al.

Shlaer-Mellor

Odell

Booch

Pre- and Post-conditions

State Charts

Responsabilities

Operation descriptions, message numbering

Singleton classes

Frameworks, patterns, notes

Object life cycles

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


Casos de Uso

Diagramas de Secuencia

Diagramas de Colaboración

Diagramas de Clases

Diagramas de Estados

Diagramas de Actividad

Diagramas de Componentes

Diagramas de Distribución

C Ó D I G O

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:

El inicio: ¿cuándo y qué actor lo produce?

El fin: ¿cuándo se produce y qué valor devuelve?

La interacción actor-caso de uso: ¿qué mensajes intercambian ambos?

Objetivo del caso de uso: ¿qué lleva a cabo o intenta?

Cronología y origen de las informaciones

Repeticiones de comportamiento: ¿qué operaciones son iteradas?

Pág. 2-11


Situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el

caso de uso?

Actor

Caso de usoActor

Actor

Actor

Caso de uso

Caso de uso

Caso de uso

Actor

Caso de usoActor

Actor

Actor

Caso de uso

Caso de uso

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 Clase

Clase Clase

Clase Clase Clase

{disjunta, completa}

1 .. 4

11 *

1 .. 2

*1 *

*

1

*

1

Clase

Clase

Clase Clase

Clase Clase

Clase Clase Clase

{disjunta, completa}

1 .. 4

11 *

1 .. 2

*1 *

*

1

*

1

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.

:Actor :Actor :Objeto :Objeto :Objeto :Objeto

Mensaje

Mensaje

Mensaje

MensajeMensaje

MensajeMensaje

Mensaje

:Actor :Actor :Objeto :Objeto :Objeto :Objeto

Mensaje

Mensaje

Mensaje

MensajeMensaje

MensajeMensaje

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


Actor

Actor

:Objeto

:Objeto

:Objeto

:Objeto

N: mensaje

N: mensaje

N: mensaje

N: mensajeN: mensaje

N: mensaje

N: mensaje

N: mensaje

Actor

Actor

:Objeto

:Objeto

:Objeto

:Objeto

N: mensaje

N: mensaje

N: mensaje

N: mensajeN: mensaje

N: mensaje

N: mensaje

N: mensaje

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


Estado Estado

Estado

Transición

Transición

TransiciónTransición

Estado Estado

Estado

Transición

Transición

TransiciónTransición

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.

Actividad

Actor Actor Actor

Actividad Actividad

ActividadActividad

Actividad

Actividad

Actividad

Actividad

Actividad

Actividad

Actor Actor Actor

Actividad Actividad

ActividadActividad

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

físico.

Componente

Componente Componente Componente

ComponenteComponente

Componente Componente Componente

Componente

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

Nodo

NodoComponente Componente

Componente


Componente

ComponenteComponenteNodo

Nodo

NodoComponente 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.

Requisitos

Diseño

Implementación

Pruebas

Análisis

iter.#1

iter.#2

iter.#n

iter.#n+1

iter.#n+2

iter.#m

iter.#m+1

FasesActividades

Una iteración en lafase de elaboración

Estudio deoportunidad

Elaboración Construcción Transición

Iteración(es)Preliminar(es)

Requisitos

Diseño

Implementación

Pruebas

Análisis

iter.#1iter.#1

iter.#2iter.#2

iter.#niter.#n

iter.#n+1iter.#n+1

iter.#n+2iter.#n+2

iter.#miter.#m

iter.#m+1iter.

#m+1

FasesActividades

Una iteración en lafase de elaboración

Estudio deoportunidad

Elaboración Construcción Transición

Iteración(es)Preliminar(es)

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


22..11..44 EESSTTÁÁNNDDAARREESS OOMMGG

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


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

amplia difusión, se ha convertido en un estándar para el modelado de SW

madurez tecnológica, está a punto de aparecer la versión UML 2.0

modelado independiente de lenguajes de programación, no está ligado a IDL

como CORBA

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.

DocXML

APIXML

Código propio

Objetos aplicación

Elementos XML

DocXMI

SWXMI

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:

Representación estándar de objetos XML, habilitando el intercambio efectivo

de objetos entre aplicaciones.

Generación automática de schemas, código y documentación a partir de

modelos UML.

Creación de documentos simples que van avanzando según la aplicación

evoluciona.

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.

Permite el modelado con XML incluyéndolo en la estructura del MDA.

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


22..11..55 UUMMLL 22..00

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


222...222 LLLEEENNNGGGUUUAAAJJJEEESSS FFFOOORRRMMMAAALLLEEESSS

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

22..22..11 AALLGGUUNNAASS DDEEFFIINNIICCIIOONNEESS

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

http://foldoc.doc.ic.ac.uk/


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


22..22..22 EEBBNNFF

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


22..22..33 XXMMLL

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:

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.

Se permite un único elemento raíz del que cuelgan todo lo demás.

Los valores de los atributos están encerrados entre comillas.

XML es sensible a mayúsculas y minúsculas

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.

Existen un conjunto de restricciones para los identificadores.

Pág. 2-44


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:

El documento tendrá que estar bien formado, es decir, utilizar

correctamente el lenguaje de marcado XML.

Existirá un schema asociado contra el que se realizará la validación. Este

schema estará escrito con un determinado lenguaje de schema.

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 PARSERXML

Agenda.dtd

Mensajes de error

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


Transf.xsl

PROCESADORXSLT

Doc1.xml Doc2.xml

Transf.xsl

PROCESADORXSLT

Doc1.xml Doc2.xml

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


22..22..44 GGEENNEERRAACCIIÓÓNN DDEE GGRRAAMMÁÁTTIICCAASS AA PPAARRTTIIRR DDEE

MMOODDEELLOOSS UUMMLL

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:

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,…).

Interfaz gráfico. Se facilita la captura de la semántica a través de los

diagramas.

Rápido desarrollo de buenos schemas sin conocer a fondo XML.

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.

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.

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

http://xmlmodeling.com/products/hyperModel/

http://eclipse.org/


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.

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.

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


222...333 HHHEEERRRRRAAAMMMIIIEEENNNTTTAAASSS EEESSSPPPEEECCCÍÍÍFFFIIICCCAAASSS DDDEEE DDDOOOMMMIIINNNIIIOOO R

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

http://www.incose.org/


∗ 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:

¿Cuál es el impacto de un cambio en un requisito?

Pág. 2-55

http://www.paper-review.com/tools/tdb/home.php


¿Dónde se implementa un determinado requisito?

¿Cumple la implementación todos los requisitos?

¿Es este requisito necesario?

¿Qué decisiones de diseño afectan a la implementación de un requisito?

¿Por qué se ha implementado este diseño?, ¿cuáles son las alternativas?

¿Es necesario este elemento de diseño?

¿Cómo se interpreta este requisito?

¿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


22..33..11 IINNGGEENNIIEERRÍÍAA DDEE CCOONNTTRROOLL

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

http://www.acslsim.com/

http://www.programcc.com/


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

http://www.aonix.com/


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


22..33..22 SSIISSTTEEMMAASS DDIISSTTRRIIBBUUIIDDOOSS

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

http://www.iologic.com/

http://www.hitex.com/

http://www.ime-actia.com/

http://www.stzp.de/

http://www.vector-informatik.com/


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

http://www.osek-vdk.org/


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


22..33..33 SSIISSTTEEMMAASS DDEE TTIIEEMMPPOO RREEAALL

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

http://www.rational.com/

http://www.tni-world.com/

http://spd-web.terma.com/Projects/OBOSS/Home_Page/

http://spd-web.terma.com/Projects/OBOSS/Home_Page/


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

http://www.telelogic.com/

http://www.tripac.com/

http://www.timesys.com/index.cfm?bdy=tools_bdy_model.cfm

http://www.timesys.com/


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

http://www.ibm.com/

http://www.telelogic.com/

http://www.artisansw.com/

http://www.ilogix.com/


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


22..33..44 IINNGGEENNIIEERRÍÍAA DDEELL SSWW

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:

Aplicación práctica de metodologías de desarrollo

Generación de prototipos y conjuntos de aplicaciones con características

genéricas comunes

Simplificación del mantenimiento del SW

Estandarización de la documentación

Aumento de la portabilidad

Aumento de la reutilización de componentes SW

Permitir el desarrollo visual de aplicaciones mediante gráficos

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:

Está definido: El proceso es claro, sistemático y suficientemente detallado.

Está documentado: Esta escrito en un procedimiento publicado, aprobado y

fácilmente accesible.

El personal ha sido entrenado en el proceso: Cada persona ha recibido

entrenamiento en cada proceso que aplica a su trabajo.

Es practicado: El proceso definido debe ser usado en las tareas habituales

llevadas a cabo por los proyectos.

Es mantenido: El proceso es revisado regularmente, para asegurarse que

está adaptado para satisfacer las necesidades reales de los proyectos.

Está controlado: Los cambios y puestas al día del proceso son revisados,

aprobados y comunicados oportunamente a todos los usuarios.

Se verifica: Existen mecanismos para asegurarse de que todos los proyectos

siguen el proceso vigente.

Se valida: Se asegura que el proceso mantiene concordancia con los

requerimientos y estándares aplicables.

Se mide: La utilización, los beneficios y el rendimiento resultante del

proceso se miden regularmente.

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.

Repositorioinformación

Metadatos (Metamodelo)

Mecanismos de Activación y Control de Errores

HerramientaC

HerramientaB

HerramientaA

Interfaz Usuario

Repositorioinformación

Metadatos (Metamodelo)

Mecanismos de Activación y Control de Errores

HerramientaC

HerramientaB

HerramientaA

Interfaz Usuario

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

http://www.pithecanthropus.com/~awg/public_html/


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.

ADMLADMLADMLADML ADML ADML

ADML(components, connectors, ports, roles, properties, systems, representation maps

Business Tools

Design Tools

Development Tools

Test Tools

Management Tools

.xyz .uml .uml .?ml .?ml

Architecture Tool

.*ml

ADMLADMLADMLADML ADML ADML

ADML(components, connectors, ports, roles, properties, systems, representation maps

Business Tools

Design Tools

Development Tools

Test Tools

Management Tools

.xyz .uml .uml .?ml .?ml

Architecture Tool

.*ml

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


222...444 AAPPPRRROOOXXXIIIMMMAAACCCIIIOOONNNEEESSS AAA LLLAAA A

IIINNNTTTEEEGGGRRRAAACCCIIIÓÓÓNNN DDDEE HHHEEERRRRRRAAAMMMIIIEEENNNTTTAAASSS E

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


22..44..11 SSOOLLUUCCIIOONNEESS PPAARRTTIICCUULLAARREESS DDEE DDOOMMIINNIIOO

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:

Gestión del interfaz de usuario

Gestión de datos y representación

Editor

Gestión de configuración

Generación de wizards para guiar a los usuarios en las tareas más complejas

Gestión de almacenamiento

Plataformas cruzadas diversas

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:

Un contexto de ejecución para la aplicación desarrollada

Un conjunto de herramientas de desarrollo

Pág. 2-89


Un conjunto de abstracciones que permiten la reutilización de componentes

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


22..44..22 SSOOLLUUCCIIOONNEESS GGEENNÉÉRRIICCAASS ((MMEETTAAFFRRAAMMEEWWOORRKK))

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


Platform Runtime

Workspace

Help

Team

Workbench

JFace

SWT

Eclipse Project

JavaDevelopment

Tools(JDT)

Their Tool

Your Tool

AnotherTool

Plug-inDevelopmentEnvironment

(PDE)

Eclipse Platform

Debug

Platform Runtime

Workspace

Help

Team

Workbench

JFace

SWT

Eclipse Project

JavaDevelopment

Tools(JDT)

Their Tool

Your Tool

AnotherTool

Plug-inDevelopmentEnvironment

(PDE)

Eclipse Platform

Debug

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.

Java VMStandard Java2Virtual Machine

EclipsePlataforma Eclipse

Java DevelopmentTools

JDT

PDEEntorno para desarrollode plugins

Java VMStandard Java2Virtual Machine

Java VMJava VMStandard Java2Virtual Machine

EclipsePlataforma Eclipse EclipseEclipsePlataforma Eclipse

Java DevelopmentTools

JDTJava DevelopmentTools

JDTJDT

PDEEntorno para desarrollode plugins

PDEPDEEntorno para desarrollode plugins

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

http://eclipse.org/community/plugins.html

4+1 Vistas y Mas ion

Documents

Transcript of 4+1 Vistas y Mas ion