OASIS 3.0
Un enfoque formal para el
modelado conceptual orientado a objeto


OASIS 3.0: Un enfoque formal para el modelado conceptual orientado a objeto

Patricio Letelier
Pedro Sánchez 
Isidro Ramos
Oscar Pastor 

Servicio de Publicaciones 
Universidad Politécnica de Valencia SPUPV-98.4011
ISBN 84-7721-663-0
184 páginas,1998


 OASIS 3.0 en formato PDF (1 Mb)

El contenido completo del libro de OASIS 3.0 y por capítulos es el siguiente:

Índice

Parte I. Semántica y formalización de OASIS
  1. Introducción
  2. Clases y Objetos
  3. Clases Complejas
  4  Interacción entre Objetos
  5. La Metaclase OASIS

Parte II. OASIS como lenguaje.
  6. Especificación del Sistema
  7. Ejemplo OASIS 3.0
  8. Conclusiones
  Bibliografía
  Glosario
  Sintaxis de OASIS 3.0

A continuación se presenta un extracto del capítulo 1: Introducción, Historia y Modelado orientado a objeto en OASIS



Introducción

La Ingeniería de Requisitos es un campo de reconocida importancia en el ámbito teórico y práctico de la ingeniería del software. Las mayores deficiencias (y desafíos) en el proceso de desarrollo de software se encuentran en sus primeras fases. La distancia entre el espacio del problema (Universo de Discurso) y el espacio de la solución (producto software) hace necesario que la especificación de requisitos del sistema, resultante del proceso de modelado conceptual, tenga dos importantes propiedades: debe ser abstracta y declarativa.

El modelo conceptual debe ser abstracto para facilitar la captación y modelado de aspectos del problema de una forma lo más cercana posible a los conceptos del dominio del problema. Esto es muy importante para la validación del modelo obtenido, facilitando la participación del usuario en dicha tarea. En este sentido, el enfoque orientado a objeto (OO) posibilita la elaboración de entornos de producción de software que resuelven problemas clásicos asociados a la ya familiar noción de "Crisis del Software''.

Entre las ventajas más destacables del paradigma objetual en este contexto cabe señalar las siguientes:

Por lo anterior, creemos que la orientación a objetos es un enfoque apropiado para el modelado de requisitos de sistemas de información. El modelo que proponemos está basado en dicho enfoque.

Por otra parte, el modelo conceptual debe ser declarativo de manera que permita postergar decisiones de implementación. Esta característica nos separara de lo que denominamos enfoques orientados a objetos clásicos, en los que la especificación es principalmente imperativa y se limita en general a la estructura de los objetos y los perfiles de las operaciones.

La tarea de verificación del modelo exige disponer de algún formalismo preciso y a la vez con toda la capacidad expresiva necesaria para capturar todos los aspectos de interés del problema. Las notaciones gráficas son atractivas pues facilitan el modelado y la legibilidad de una especificación de requisitos, pero pierden estas ventajas cuando se sobrecargan con detalles. Por otra parte, las representaciones puramente textuales, y más aún siendo formales, tienen el grado de detalle que se desee pero exigen más esfuerzo en su utilización. Esto sugiere que metodológicamente la mejor solución es una combinación de ambas técnicas: gráficas y textuales. Como el objetivo es obtener un modelo completo y preciso del sistema, una representación textual final es la más adecuada, pues tanto las técnicas textuales como las gráficas pueden ser finalmente trasladadas a texto para describir el modelo en su totalidad.

OASIS (Open and Active Specification of  Information Systems) es un enfoque formal para especificación de modelos conceptuales siguiendo el enfoque orientado a objetos. OO-METHOD es la propuesta metodológica basada en OASIS. OO-METHOD cubre las fases de análisis, diseño e implementación de un sistema de información desde la perspectiva del paradigma de la programación automática, es decir, haciendo énfasis en la animación automática de la especificación, prototipación automática y generación del producto final. Particularmente, en la fase de modelado conceptual, OO-METHOD provee herramientas gráficas para hacer más fácil la construcción del modelo. La especificación OASIS para un sistema es construido implícitamente mediante las herramientas provistas por OO-METHOD.

Lenguajes con una motivación similar a la de OASIS son TROLL , CMSL , LCM , Albert , Oblog  y Gnome.

Historia

El entorno OO formal y declarativo representado por OASIS y su extensión metodológica (OO-METHOD) constituyen el resultado del intenso trabajo de investigación realizado en el grupo de Modelado Orientado a Objeto en el DSIC-UPV durante los últimos años. Los objetivos de este trabajo de investigación son básicamente:

Definir un marco formal adecuado para dar cuenta del modelo OO.

Elaborar un lenguaje que sea lo suficientemente expresivo para ser empleado como herramienta de modelado conceptual de sistemas de información.

Desarrollar una metodología y herramientas asociadas que permitan el aprendizaje adecuado y uso del modelo propuesto.

El entorno OASIS en su primera versión fue formalizado a través de Teorías de Primer Orden que evolucionan con el tiempo. Este enfoque lo situó históricamente en un entorno de Programación Lógica complementado con un monitor para la gestión de la perspectiva dinámica del sistema. A partir de la segunda versión se cambió de marco formal y se trabajó en el contexto de una variante de Lógica Dinámica que permite representar los operadores de obligación, prohibición y permiso usados en Lógica Deóntica. En este marco, OASIS tiene una base formal más adecuada desde el punto de vista de su comprensión, manteniendo sus buenas propiedades.

Con respecto de la versión anterior OASIS 2.2, en OASIS 3.0 se han introducido las siguientes mejoras:


Modelado orientado a objeto en OASIS

En OASIS, un objeto es un proceso observable cuya vida está caracterizada por la ocurrencia de acciones, tanto si son solicitadas como si son recibidas por el objeto. Así, un objeto puede actuar como cliente o como servidor según esté solicitando u ofreciendo servicios (los conceptos cliente y servidor son usados en su sentido genérico, no se refieren específicamente a arquitecturas distribuidas cliente/servidor). Una acción es una tupla formada por el cliente, el servidor y el servicio solicitado. En la vida de un objeto específico, las acciones cuyo cliente es el mismo objeto son acciones solicitadas. Las acciones cuyo servidor es el mismo objeto son acciones servidas. Un caso particular es el de acciones cuyo cliente y servidor es el mismo objeto. Esto sucede cuando el objeto se solicita un servicio a sí mismo.

Los servicios que un objeto proporciona a nivel `"atómico'' se denominan eventos. Cada objeto tiene un evento de creació}n (que inicia su vida) y opcionalmente uno de destrucción. Los eventos pueden ser estructurados como procesos en un nivel "molecular''. Además de la semántica propia del sublenguaje utilizado para especificar procesos, añadiremos una semántica adicional para distinguir entre procesos de obligación y procesos de prohibición. Un proceso de obligación es un servicio de mayor nivel ofrecido por el objeto. Con este concepto es posible modelar la noción tradicional de algoritmo. Un caso particular de proceso de obligación es cuando, además, se asume que el proceso actúa como "todo o nada'' y lo denominaremos transacción. Un proceso de prohibición impide la ejecución de determinadas secuencias de acciones en la vida del objeto definiendo las secuencias que están permitidas.

En OASIS, un sistema de información es entendido como una sociedad de objetos autónomos y concurrentes (este tipo de concurrencia la denominaremos inter-objetual y permitirá modelar objetos con la capacidad de ser clientes autónomos que interactúan entre ellos mediante acciones). Cada objeto puede solicitar sólo los servicios que le son accesibles de otros objetos. Las interfaces son un mecanismo que permite establecer relaciones de accesibilidad entre objetos, definiendo la visión que tiene cada objeto respecto de la sociedad de objetos.

Cada objeto encapsula su estado y las reglas que rigen su comportamiento. Como es habitual en todo entorno OO, los objetos pueden ser vistos desde dos perspectivas distintas: estática y dinámica. Desde el punto de vista estático, llamaremos atributos al conjunto de propiedades que describen estructuralmente al objeto. Los valores asociados a cada propiedad estructural del objeto caracterizan el estado del objeto en un instante dado. La evolución de los objetos (perspectiva dinámica) viene caracterizada por la noción de cambio de estado: la ocurrencia de una acción puede generar cambios (definidos por evaluaciones y derivaciones) en los valores de atributos. La actividad de un objeto está determinada por un conjunto de reglas: precondiciones, restricciones de integridad, disparos, protocolos y operaciones.

La vida de un objeto puede representarse como una secuencia de pasos. Cada paso está formado por un conjunto de acciones que ocurren en un instante dado de la vida del objeto. Las acciones son abstracciones de cambios atómicos en el estado del objeto. Operacionalmente hablando, la ocurrencia de acciones está asociada a la ejecución de los cambios que pueden producir dichas acciones en el estado del objeto.

Cada objeto tiene un identificador único (oid) proporcionado implícitamente por el sistema. Sin embargo, el objeto es referenciado mediante mecanismos de identificación pertenecientes al espacio del problema. Una función de identificación establece correspondencias entre los mecanismos de identificación y el oid del objeto.

Llamaremos tipo a la plantilla que describe la estructura y el comportamiento de un objeto. Una clase se compone de un nombre de clase, una función de identificación y un tipo.

Pueden definirse nuevas clases reutilizando clases ya definidas. Una clase compleja es aquella definida utilizando otras clases. Los operadores entre clases disponibles en OASIS son agregación y herencia.