4.1 De los requisitos a las aplicaciones: los modelos

Los lenguajes, bien sean de programación, de marcado o de consulta, representan el mascarón de proa de la informática. Sin embargo, antes de proporcionar la secuencia de frases de un lenguaje que constituye el código, que a fin de cuentas es la esencia de toda aplicación informática, cabe preguntarse si es posible, o necesario, dar una caracterización previa de las tareas que conducen a la consecución de dicho objetivo. En aplicaciones simples -aquellas que puede realizar un solo individuo en unas pocas horas- puede no ser necesario, pero cuando se enfrenta el desarrollo de software como un proceso industrial (Booch, 1996) es, sin duda, necesario proporcionar un marco que permita caracterizar cada una de las etapas del proceso de producción de este software. Primero, se debe proporcionar una especificación de requisitos que capture las funciones y restricciones de la aplicación. Tras esta especificación de requisitos, se debe proporcionar un modelo que sirva como paso intermedio entre las especificaciones y la aplicación final. Este modelo es la base para el diseño de la aplicación. Un modelo permite abstraer las características fundamentales de la aplicación y dar una caracterización de la misma suficientemente detallada como para poder obtener, utilizando algún lenguaje informático, el código que cumpla con los requisitos y especificaciones de partida.

Un lenguaje informático se ajusta siempre a un determinado paradigma de programación -por ejemplo, el paradigma imperativo-, y a un determinado modelo por ejemplo, el modelo de objetos. Un modelo de programación provee un marco abstracto en el que entender la sintaxis de los lenguajes concretos que siguen el modelo, y representa la semántica del mismo, así como una filosofía de uso de dicha semántica. Por ejemplo, algunos lenguajes de programación de propósito general como Java se ajustan al modelo de objetos, cuya filosofía puede simplificarse mediante el siguiente enunciado: el mundo está compuesto de una serie de objetos que se comportan de una forma determinada y que intercambian mensajes entre sí, técnicamente estos objetos exhiben las propiedades de “encapsulación, herencia y polimorfismo” (Deitel, 1995).

Para proporcionar modelos de diseño que permitan caracterizar el desarrollo de aplicaciones utilizando un lenguaje de programación se necesita un lenguaje de modelado que sea capaz de capturar la semántica del modelo al que se ajusta el lenguaje de programación. A su vez, el modelo de diseño proporcionado por el lenguaje de modelado debe ser capaz de capturar la semántica del programa que implementa la especificación de requisitos. De esta forma, el modelo de diseño sirve de nexo entre la especificación de requisitos y el programa final. Así por ejemplo, UML (Unified Modeling Language) (Booch, 1999) es un lenguaje de diseño visual que representa, mediante diagramas, el modelo de programación de objetos. Modelos de diseño concretos descritos con UML sirven como guía para la construcción de programas concretos, especificando detalles arquitectónicos del programa, no recogidos inicialmente en la especificación de requisitos.

Algunas veces, puede no resultar conveniente construir una aplicación utilizando un lenguaje de programación de propósito general. Por ejemplo, para construir una aplicación en el dominio hipermedia se dispone, al menos, de dos opciones. La primera, empezar desde cero construyendo cada elemento de la aplicación utilizando un lenguaje de programación de propósito general. La segunda, abstraer los elementos comunes que aparecen en este tipo de aplicaciones, como son, las anclas, los enlaces y los paneles de presentación de información al usuario, y definir un lenguaje que caracterice estos elementos. Este sería, por ejemplo, el caso del lenguaje HTML, utilizando el metalenguaje SGML. Un intérprete de dicho lenguaje constituye, entonces, el núcleo de la aplicación o sistema hipermedia. Este es el caso de los navegadores web (por ej. Explorer y Netscape) cuyo núcleo está formado por un intérprete del lenguaje HTML y el protocolo de comunicación http. La primera aproximación, que se denominará aproximación abierta, es flexible y potente, pero exige mayor esfuerzo de diseño y desarrollo. La segunda, que se denominará aproximación cerrada, es menos flexible, al restringir los elementos que pueden aparecer en una aplicación hipermedia, pero proporciona una aproximación cercana al paradigma documental de desarrollo de aplicaciones descrito en el apartado anterior. No obstante, en ambos casos resulta útil proporcionar un modelo de diseño que permita representar la aplicación como un todo. En el caso de la aproximación abierta se requiere un modelo de los procesos computacionales de la aplicación (expresado, por ejemplo, en UML), y un modelo de la propia aplicación hipermedia. En el caso de la aproximación cerrada sólo se precisa el modelo de la aplicación hipermedia, ya que se supone construido el sistema hipermedia (por ejemplo, un navegador que, a su vez, también debería haber sido especificado a través de un modelo en UML).

El problema de dar un modelo de diseño de una aplicación hipermedia es que no hay una semántica fija que modelar (como en el caso de UML y el modelo de objetos), ni siquiera hay un consenso sobre los elementos concretos que hay que modelar. Por ejemplo, se pueden modelar enlaces unarios o enlaces n-arios. Con independencia de este problema, desde los años 80 han surgido distintos Sistemas de Representación Hipermedia (SRH) cuya finalidad es proporcionar modelos de diseño para aplicaciones hipermedia. A pesar de esta finalidad inicial, estos modelos de diseño terminan utilizándose también como verdaderos modelos semánticos, ya que, en última instancia, definen las capacidades de las aplicaciones que pretenden modelar.
Los SRH son de una naturaleza muy heterogénea. Hay modelos hipermedia propiamente dichos (por ej. el Modelo Trellis) que caracterizan a una aplicación de tal manera que incluso especifican cuál va a ser su semántica de navegación (por ej. el modo en que la información va a ser visitada y presentada al usuario (Stotts, 1989)). Otros son modelos de referencia, con los que contrastar los modelos hipermedia (por ej. el modelo Dexter). Finalmente, existen metodologías (por ej. OOHDM) cuya finalidad es proporcionar una serie de diagramas que guíen la construcción de una aplicación hipermedia. En el próximo apartado se examinan las características principales de estos SRH, así como sus ventajas e inconvenientes.

Índice general I Índice artículo I Siguiente