Como reforzar Diagramas de Clases UML aplicando OCL y Object-Z: un caso práctico

Transcripción

1 Como reforzar Diagramas de Clases UML aplicando OCL y Object-Z: un caso práctico Elizabeth Vidal-Duarte 1 Cristian Vidal Silva 2 1 Universidad Católica San Pablo Perú 2 Universidad Autónoma de Chile e.vidal@usp.edu.pe cvidals@talca.uas.cl Resumen Este artículo busca mostrar el uso de dos lenguajes de especificación formal para reforzar diagramas de clases UML. Como lenguaje de especificación formal se utilizan los lenguajes OCL y Object-Z. En este artículo se muestra la aplicabilidad de estos dos lenguajes y un análisis comparativo entre ellos. Como caso de estudio se hace uso de un subsistema de atención de clientes de un banco para mostrar la aplicabilidad y la importancia de las especificaciones formales. 1. Introducción Es ampliamente conocido que la parte más crítica del desarrollo de software corresponde a la identificación y especificación de requerimientos [Sommerville, 2001]. Para facilitar el proceso de desarrollo de software, muchos desarrolladores trabajan con una variedad de métodos y herramientas reconocidos. Por ejemplo el Lenguaje de Modelado Unificado (UML) [Booch, Rumbaugh and Jacobson, 1998] [Rumbaugh, Jacobson, and Booch, 1998]. Aunque UML es el lenguaje estándar para modelamiento aún no está suficientemente refinado como para proveer toda la información relevante en una especificación. Los diagramas UML están sujetos muchas veces a interpretaciones subjetivas. Esto podría llevar a implementaciones que corren el riesgo de no cumplir con los requerimientos reales. Existe la necesidad de describir restricciones adicionales acerca de los objetos en el modelo de clases. Dichas restricciones son descritas por lo general en lenguaje natural. La experiencia ha mostrado que esto siempre resulta en ambigüedades. Para evitar dichas ambigüedades se han desarrollado los llamados lenguajes formales. Algunos de los lenguajes formales más utilizados en la academia y la industria son: Abstract State Machine [Abstract State Machines, 2006], B-Method [The B-Method, 2006], RAISE [George, 1992] [Asger, 2001], VDM [Information on VDM and VDM++, 2006] y Z [The Z Notation, 2006]. Si se quiere que los métodos formales sean utilizados en el desarrollo de proyectos de software, se requiere habilitar a los desarrolladores en el uso de especificaciones formales. En este artículo se muestra dos formas de especificación formal. Para este propósito se hace uso de OCL (Object Constraint Language) [Warner, J. and Kleppe, A., 1999] y de Object-Z (extensión del conocido lenguaje formal Z [Vidal, and Andrades, 2007]). OCL permite expresar restricciones adicionales en los modelos orientados a objetos. OCL permite la especificación de restricciones formales en el contexto de modelos UML. Object-Z es una extensión conservativa del lenguaje Z y también es posible trasladar formalmente un modelo de datos o clases UML en una especificación formal de Object- Z. La principal contribución de este artículo es mostrar la aplicabilidad de especificaciones formales en los diagramas de clases UML. Si bien las especificaciones que se muestran no cubre todo el comportamiento del subsistema en estudio, si permiten mostrar como pueden capturarse las restricciones del comportamiento deseado del subsistema. Cabe señalar que esto no es posible utilizando solamente diagramas UML. El resto del artículo esta organizado de la siguiente manera: en la Sección 2 se presenta como caso de estudio un subsistema de atención a clientes de un banco. Se describen los requerimientos funcionales de manera informal para luego modelar el diagrama de clases junto con las especificaciones formales OCL (Sección 3) y Object-Z (Sección 4). En la Sección 5 se expone el análisis de la experiencia de la aplicación de OCL y Object-Z. En la Sección 6 se presentan algunos trabajos relaciones y trabajo futuro. Finalmente en la Sección 7 se exponen las conclusiones.

2 2 Caso de Estudio: Subsistema Atención de Clientes 2.1 Los Requerimientos Se ha considerado un caso simple que corresponde a un subsistema de atención de clientes de un banco. Se asume que el banco en estudio tiene varias estaciones de atención denominadas ventanillas. Un cliente se acerca a una ventanilla para ser atendido. En caso hubiese mas clientes en una determinada ventanilla el cliente se coloca al final de una fila de clientes. Los clientes son atendidos de acuerdo al orden de llegada, esto es, el primero en llegar es el primero en ser atendido (se ha decidido dejar el manejo de atención por prioridades para un trabajo futuro). Se sabe que una ventanilla tiene asociada: a) una fila de clientes b) un estado (cerrada: no atiende clientes, abierta: nuevos clientes pueden colocarse en la fila o cerrando: atiende a los clientes que están actualmente en la fila pero no permiten que nuevos clientes se sumen a la fila) y c) disponibilidad (ocupada o libre). Se asume que si una ventanilla está ocupada entonces es el primer cliente en la fila quien esta siendo atendido. Este subsistema sólo presenta tres operaciones: a) añade un nuevo cliente al final de la fila b) atendiendo un cliente, que es cuando el primer cliente de la fila pasa a la ventanilla y c) cambia el estado de la ventanilla a cerrada, permitiendo así que una ventanilla culmine su proceso de atención. 2.2 El Diseño Siguiendo el Proceso de Desarrollo de Software RUP [Rumbaugh, Jacobson, and Booch, 1998] un modelo de diseño puede ser presentado por un diseño de un subsistema. Se asume que el subsistema debe contener clases con sus respectivos atributos y operaciones, relaciones de asociación con otras clases de manera que cada asociación esta detallada con su respectivo rolname y multiplicidad. El diagrama de clases para el subsistema en estudio se muestra Figura 1. Figura 1: Diagrama de Clases: Subsistema de Atención de Clientes Es importante resaltar que los componentes de la clase Ventanilla deben satisfacer varias restricciones de manera que la descripción de su comportamiento se ajuste al mundo real. Por ejemplo si la ventanilla esta cerrada, entonces no puede estar actualmente atendiendo a un cliente y además su estado debe ser libre. Si está actualmente ocupada debe haber algunos clientes que estas siendo atendidos, lo que significa que la fila no puede estar vacía. Dichas restricciones no pueden ser deducidas a simple vista en el diagrama de clases. Para ello se hace necesario el uso de lenguajes de especificación formal. 3. Especificación con OCL OCL [OMG, 1999] [Rational Software Corporation, 2006] parte del estándar UML [OMG, 1999], es un lenguaje que nos permite la especificación de restricciones formales en el contexto de los modelos UML. Las restricciones son condiciones en todos los estados y las transiciones entre los estados de un sistema implementando un modelo determinado. Las restricciones son usadas principalmente para expresar invariantes en las clases y precondiciones y postcondiciones en las operaciones. Una invariante es una expresión referida a todos los objetos en una clase, cuyo valor de verdad debe ser mantenido por las operaciones que pueden ocurrir sobre un objeto de la clase.

3 Adicionalmente, precondiciones y postcondiciones permiten determinar especificaciones sobre el comportamiento de las operaciones antes y después de su ejecución. Según [Warner, and Kleppe, 1998] el lenguaje provee variables y operaciones que pueden ser combinadas para construir expresiones. OCL define un número de tipos de datos que van desde enteros y booleanos hasta tipos que manejan colecciones de objetos. Todas las expresiones OCL son libres de efectos secundarios, esto es, la evaluación de una expresión no produce un cambio en el estado del sistema. Las expresiones OCL son declarativas en el sentido que dicen que restricciones deben permanecer, pero no como deben ser implementadas. Buscando facilitar la compresión de este artículo, se presentan las palabras reservadas de OCL en letra itálica y negrita. 3.1 Expresiones Booleanas y Tipos Las expresiones en OCL son construídas utilizando los operadores booleanos: and, or, not e implies. OCL define tipos de datos básicos tales como Int, Bool y String. También define tipos que nos permiten manejar colecciones de objetos [Warner, and Kleppe, 1999]. OCL soporta los tipos colección: Set, Bag y Sequence. Un tipo Set se refiere a conjuntos según definición matemática (no contiene elementos duplicados). El tipo Bag es como un conjunto pero puede tener elementos duplicados. El tipo Sequence es como el tipo Bag pero sus elementos están ordenados. OCL presenta operaciones predefinidas que son comunes a todos los tipos colección [Ritchie, 2004] (ver Tabla 1). La navegación directa en el diagrama de clases UML resulta en un conjunto (Set). Así por ejemplo en el diagrama de clases (en el diagrama de la Figura 1, se puede decir que un objeto de la clase Ventanilla tiene un conjunto de clientes. La navegación entre asociaciones rotuladas con {ordered} resulta en el tipo Sequence. En la Tabla 2 presentamos las operaciones para el tipo Sequence por ser relevantes para el caso de estudio. En [Ritchie, 2004] se encuentra el detalle y explicación de todas las operaciones sobre colecciones. 3.2 Definiendo el Contexto La declaración del contexto especifica el elemento del modelo en el cual será definida la restricción. Para las invariantes la declaración del contexto será una clase. Para las precondiciones y postcondiciones el contexto será una clase seguida de la signatura de la operación. Tomando como referencia el diagrama de clases en la Figura 1 podemos especificar: context Ventanilla: addcliente(c: Cliente) En donde el contexto se refiere a la operación addcliente( ) de la clase Ventanilla 3.3 El uso de Self Tabla 1: Operaciones comunes a todos los tipos Colección Tabla 2: Operaciones sobre el tipo Sequence Cada expresión OCL es escrita en el contexto de una instancia de un tipo específico. Se utiliza la palabra reservada self para referirnos a esa instancia. Por ejemplo: context Ventanilla

4 self.estado El valor de la subexpresión self.estado se refiere al valor del atributo estado en una instancia particular de la clase Ventanilla. El tipo de esta expresión es el mismo tipo del atributo estado que en este caso es del tipo <<enumerativo>> Estado. 3.4 Invariantes Las invariantes son condiciones que deben ser verdaderas durante el tiempo de vida del sistema para todas las instancias de una determinada clase. La condición es expresada con una expresión de tipo booleano. La semántica de las invariantes requiere que la expresión sea verdadera para todos los objetos de la clase dada como contexto [Hamie, Howse, and Kent, 1998] [Meyre, 1997].. De acuerdo a los requerimientos del sistema se puede expresar: context Ventanilla inv: Inv1: self.estado=cerrada implies self.fila isempty() and self.disponible=libre inv Inv2: self.disponible=ocupada implies self.fila notempty() La primera invariante expresa que cuando una ventanilla esta cerrada no debe haber una fila de clientes esperando ser atendidos. Esta propiedad, en la fase de implementación, se refiere a que no debe haber tickets de atención generados para dicha ventanilla. La segunda parte refuerza la invariante al asegurar que una ventanilla cerrada no esta atendiendo a ningún cliente. La segunda invariante expresa que si una ventanilla está ocupada la fila de clientes no puede estar vacía. En ambos ejemplos el contexto es la clase Ventanilla. Ambas expresiones se refieren a una relación de asociación entre objetos. Para acceder al atributo del objeto asociado (en este caso Cliente) hacemos uso del rolname fila. Esta es la forma en la que OCL nos permite realizar navegabilidad entre los diferentes objetos del modelo. En ambos ejemplos se ha añadido un nombre a cada invariante: Inv1 e Inv2. Esto puede ser de utilidad cuando se quiera agrupar las invariantes en paquetes. 3.5 Precondiciones y poscondiciones La idea principal de las precondiciones y postcondiciones es que una clase y sus usuarios tienen un contrato [Meyre, 1997]. El usuario debe garantizar ciertas condiciones antes del llamado a la operación (precondición) y por su parte la clase garantiza que ciertas propiedades serán verdaderas cuando termine la operación (postcondición) [Hamie, Howse, and Kent, 1998] [Meyre, 1997]. En la postcondición la se refiere al valor del contexto antes del llamado de la operación. El operador permite acceder a operaciones de tipo colección. context: Ventanilla:: nuevocliente(c:cliente) pre: estado < >Cerrada or estado < > Cerrando post: fila = fila@pre append(c) La precondición definida para el método nuevocliente() garantiza que solo se colocará un nuevo cliente al final de la fila siempre y cuando se satisfaga que la ventanilla no este cerrada o en proceso de cierre. En la postcondición, para añadir un nuevo cliente se ha hecho uso de la operación append() definida en la Tabla 2. La operación append() añade un elemento al final de una secuencia de elementos. context: Ventanilla:: atendercliente() pre: fila notempty() and estado=libre post: fila= fila@pre first() El método atendercliente() tiene como precondición que la fila no esté vacía y que la ventanilla no se encuentre ocupada. Si estas condiciones son satisfechas la operación llama al primer cliente de la fila utilizando la operación first() definida en la Tabla 2.

5 context: Ventanilla:: cambiar_a_cerrada() pre:.fila isempty() post: estado= Cerrada and disponible=libre Finalmente el método cambiar_a_cerrada() evalúa que no existan clientes en la fila para cambiar su estado. Estudios en [Larsson, and Mostowski, 2003] han demostrado que incluyendo simples precondiciones en la especificación y utilizando herramientas de verificación incrementa la correctitud del software. Una herramienta que nos permite verificar expresiones OCL es Octopus (OCL Tool for Precise UML Specifications) [The Octopus WebPage, 2006]. 4. Especificación Object-Z Object-Z es una extensión del lenguaje Z para facilitar la escritura de una especificación en un estilo orientado a objetos. Esta es una extensión conservativa en el sentido de que la sintaxis y semántica existentes del lenguaje Z, son retenidas en esta extensión y nuevas características son agregadas. La mayor nueva característica es el esquema clase el cual captura la noción de clase del mundo de orientación a objetos, donde se encapsula el esquema de estado inicial y todos los esquemas de operaciones los cuales pueden cambiar el valor de las variables del objeto o los objetos de la clase [Vidal, and Andrades, 2007]. La principal ventaja de Object-Z, además de su formalidad (característica muy popular en el área de Ingeniería de Software), es la orientación a objetos del mismo. Esto facilita que una especificación escrita en Object-Z sea directamente comprendida, diseñada en UML orientado a objetos e implementada en un lenguaje de programación orientado a objetos como C++ o Java. Como se señala en [Vidal, and Andrades, 2007], Object-Z es una extensión de Z en la cual la semántica y sintaxis existente de Z son retenidas y nuevos constructores son introducidos para facilitar la especificación en un estilo orientado a objetos. Además, el hecho de ser una extensión de un lenguaje de especificaciones formales famoso y popular como lo es el lenguaje Z, hace que Object-Z como extensión de Z sea comprendido y usado sin mayores sobresaltos en la comunidad informática global. Como se señaló anteriormente, las principales ventajas son su orientación a objetos y el popular lenguaje al que extiende. En lo que resta de esta sección se hará uso del caso de estudio para explicar los principales conceptos de Object-Z. 4.1 Definición de Tipos Los tipos básicos son tipos estándar de una especificación particular de Z y Object-Z. En este sistema existen los siguientes tipos básicos: [ID_Cliente] [Nombres] [Apellidos] [OK] [Error] Estos tipos se ocuparán en la especificación formal, sin especificar su definición. Además, los tipos básicos se usarán para definir tipos de datos compuestos. Los tipos compuestos, permite definir tipos estilo Estructuras de los lenguajes de programación y tipos estilo Tablas de las Bases de Datos tradicionales. No es relevante a nivel de especificación preocuparse de cómo se implementan los tipos básicos del sistema. A continuación se muestran tipos compuestos que se usarán en este subsistema. Cliente == ID_Cliente X Nombres X Apellidos Mensaje == OK Error 4.2 Definición de Esquemas Un esquema es una parte de una especificación Z u Object-Z. Un esquema permite definir un sistema y sus invariantes, además del estado inicial del sistema y las operaciones que se realizan en el sistema, ya sean de cambio

6 o para el despliegue o visualización de información. Un esquema en Z y Object-Z está dividido (salvo el esquema para mostrar el estado inicial de un sistema o clase) en dos partes. La primera parte (antes de la línea horizontal media) es para definir las componentes de entrada y/o salida del esquema, además en el caso de esquemas que describan operaciones, un símbolo que refleja que elementos de los utilizados en la operación de la clase se cambian o cuales no cambian. Si un elemento de la clase no se utiliza en la operación, no es necesario incluirlo en el esquema. Se asume que estos elementos, los no incluidos en el esquema, no cambian. En la Figura 2 se define el esquema base para el subsistema de ventanillas. Como se puede apreciar, el sistema mantiene una secuencia de Clientes (Fila_Clientes). En el esquema que se muestra en la Figura 2, se aprecian tres invariantes del Sistema (restricciones). La primera invariante hace referencia a la unicidad de los clientes, que ya fue descrito anteriormente. La segunda y tercera invariante, tienen relación con el Estado de la ventanilla. Si el Estado de la ventanilla es Cerrada, entonces la secuencia de clientes (Fila_Clientes) está vacía y la Disponibilidad de esta ventanilla es Libre (segunda invariante). Si el Estado de la ventanilla es Ocupada, entonces se tiene que el Fila_Clientes es distinto de vacío (esta secuencia es distinta de la secuencia vacía). Fila_Clientes: Seq Cliente Estado : Abierta Cerrada Ocupada Disponibilidad : Libre Ocupada x1, x2 : Clientes # {Fila_Clientes {x1}} 0 ^ # {Fila_Clientes {x2}} 0 x1.id_cliente = x2.id_cliente x 1 = x 2 Estado = Cerrada Fila_Clientes = < > ^ Disponibilidad = Libre Estado = Ocupada Fila_Clientes < > Figura 2: Esquema Base del Sistema. Adicionalmente al esquema de la Figura 2, que corresponde al primer esquema del sistema en donde se definen las reglas, restricciones o invariantes del sistema, es necesario definir un esquema que indique cual es el estado inicial del Sistema. Se asume que cuando una ventanilla comienza a trabajar, ella no tiene clientes, su Estado es Abierta y su Disponibilidad es Libre. El esquema propuesto se presenta en la Figura 3. A diferencia del esquema principal de la clase Ventanilla, tendrá un nombre: Inicio. Inicio Fila_Clientes = <> Estado =: Abierta Disponibilidad = Libre Figura 3: Esquema Inicial del Sistema. Según el diagrama de clases expresado en la Figura 1, la clase Ventanilla tiene un conjunto de operaciones. En OCL, se define el resultado de estas operaciones como postcondiciones y los requisitos necesarios para llevar a cabo cada operación se representan como precondiciones de cada operación. En la Sección 3.4, se puede apreciar la especificación de las operaciones de clase Ventanilla en OCL. En las Figuras 4, 5 y 6 se describirán cada una de las operaciones de la clase Ventanilla en Object-Z. Cabe señalar que en lenguaje Z y Object-Z, se distingue entre operaciones que cambian el estado de algún elemento del dato u objeto y operaciones que mantiene el estado de datos y/o objetos. Para representar una operación que efectúa un cambio sobre datos u objetos, se escribe el símbolo acompañado del nombre de los datos que serán cambiados o alterados. Es importante resaltar que estos datos podrían ser objetos. Todos estos datos fueron especificados en el primer esquema (Figura 2) de la especificación Object-Z. Para representar una operación que no cambia el estado de datos, pero que debe ser, generalmente, de carácter informativa, se utiliza el símbolo X acompañado de los datos que serán usados para dar información. Ahora se especificarán cada una de las operaciones de este sistema de atención de clientes en Object-Z. Estas operaciones se deben declarar como esquemas de operación. En la Figura 4 nos centraremos en la especificación de la operación añadir nuevo cliente.

7 » nuevocliente Æ D Fila_Clientes Æ C? : Cliente Æ M! : Mensaje «Æ(Estado Cerrada ^ Estado Cerrando ^ {Fila_Clientes (C?.ID_Cliente, _,_) } = <> ^ Æ Fila_Clientes = Fila_Clientes C? ^ M! = OK) (( Estado = Cerrada Estado = Cerrando Æ {Fila_Clientes (C?.ID_Cliente, _,_) } <>) ^ M! = Error) Figura 4: Esquema Operación nuevocliente. Como parte inicial de este esquema, se declara que elementos serán afectados en esta operación. Se declaran los elementos cuyo contenido o valor podría cambiar (en este caso el Fila_Clientes). No es necesario declarar aquellos elementos que no son afectados y son utilizados en la operación (el elemento Estado). Además se aprecia, como valor de entrada (elemento con el símbolo?, en este caso C?), el cliente que se desea agregar al conjunto de clientes y como valor de salida (elemento con el símbolo!, en este caso M!), que puede ser OK o Error. Como se puede apreciar en este esquema, hay dos elementos que podrían ser verdaderos de manera excluyente. Hay tres condiciones (o precondiciones) que deben ser verdaderas, para agregar un nuevo cliente a la secuencia de clientes. Si se cumple que el Estado no es Cerrada y el Estado no es Cerrando, además si se cumple que el cliente no pertenece a la secuencia, entonces el nuevo Conjunto o nueva Secuencia de Clientes (Fila_Clientes ) se expande para contener al nuevo Cliente y se reporta el mensaje OK. En caso de que alguna de estas condiciones no se cumpla, M! (valor de salida) toma el valor Error. A continuación se verán los dos esquemas correspondientes a las dos operaciones restantes del Sistema: atender a un cliente (Figura 5) y cambiar el estado de la ventanilla a cerrada (Figura 6). Finalmente, en la Figura 7, se muestra el esquema general de la clase Ventanilla. atendercliente D Fila_Clientes, Estado, Disponibilidad M! : Mensaje (Estado = Libre ^ Fila_Clientes <> ^ Fila_Clientes = Tail(Fila_Clientes ^ Estado = Ocupando ^ M! = OK) ((Estado Libre Fila_Clientes = <>) ^ M! = Error) Figura 5: Esquema Operación atendercliente. cambiar_a_cerrada D Estado, Disponibilidad X Fila_Clientes M! : Mensaje (Fila_Clientes = <> ^ Estado = Cerrada ^ Disponibilidad = Libre ^ M! = OK) Æ(Fila_Clientes <> ^ M! = Error) Figura 6: Esquema Operación cambiar_a_cerrada 4.3 Esquema de clase Ahora se define el esquema de la clase ventanilla, el cual se compone de los tipos (básicos y compuestos), datos de la clase y operaciones sobre los datos de la clase. Acá se definen un conjunto de esquemas los cuales (casi todos) equivalen a las operaciones sobre los datos de la clase (métodos). En general, los esquemas analizados en la sección anterior, están presentes en la clase.

8 » Ventanilla Æ [ID_Cliente] [Nombres] [Apellidos] [OK] [Error] Æ Cliente == ID_Cliente x Nombres x Apellidos Æ Mensaje == OK Error Æ» Æ ÆFila_Clientes: Seq Cliente Æ ÆEstado : Abierta Cerrada Ocupada Æ ÆDisponibilidad : Libre Ocupada Æ «Æ ÆA x1, x2 : Clientes # {Fila_Clientes {x1}} 0 ^ Æ Æ # {Fila_Clientes {x2}} 0. x1.id_cliente = x2.id_cliente x 1 = x 2 Æ Æ Æ Æ Estado = Cerrada Fila_Clientes = <> ^ Disponibilidad = Libre Æ Æ Estado = Ocupada Fila_Clientes <> Æ Æ» Inicio Æ ÆFila_Clientes = <> Æ ÆEstado =: Abierta Æ ÆDisponibilidad = Libre Æ Æ» nuevocliente Æ Æ D Fila_Clientes Æ Æ C? : Cliente Æ Æ M! : Mensaje Æ «Æ Æ(Estado Cerrada ^ Estado Cerrando ^Æ{Fila_Clientes (C?.ID_Cliente, _,_) } = <> ^ Æ Æ Fila_Clientes = Fila_Clientes C? ^ M! = OK) (( Estado = Cerrada Estado = Cerrando Æ Æ Æ {Fila_Clientes (C?.ID_Cliente, _,_) } <>) ^ M! = Error) Æ» atendercliente Æ Æ D Fila_Clientes, Estado, Disponibilidad Æ Æ M! : Mensaje Æ «Æ Æ(Estado = Libre ^ Fila_Clientes <> ^ Fila_Clientes = Tail(Fila_Clientes ^ Estado = Ocupando ^ Æ Æ M! = OK) (( Estado Libre Fila_Clientes = <>) ^ M! = Error) Æ Æ» cambiar_a_cerrada Æ ÆD Estado, Disponibilidad Æ ÆX Fila_Clientes Æ ÆM! : Mensaje Æ «Æ Æ( Fila_Clientes = < > ^ Estado = Cerrada ^ Disponibilidad = Libre ^ M! = OK) Æ Æ( Fila_Clientes < > ^ M! = Error) Æ Figura 7: Esquema Clase Ventanilla 5. Comparación de OCL y Object-Z De la experiencia práctica expuesta en las Secciones 3 y 4 se puede decir que: todas las expresiones principales de una especificación OCL (invariantes, precondiciones y postcondiciones) están presentes en una especificación Object-Z. La especificación de contexto (context) de OCL equivale a la especificación de esquemas de una clase particular en Object-Z. Lo referente a la instanciación contextual de OCL está presente en Object-Z en la especificación de una clase en particular. Object-Z obliga a definir toda la información relevante de una clase, en el

9 esquema asociado a la clase. Ambos lenguajes ofrecen una amplia profundidad en lo que a orientación a objeto se refiere. La ventaja de Object-Z, es que este es una extensión de un conocido lenguaje orientado a modelos. Todos los tipos y operaciones los tipos de OCL están presentes en Object-Z. Matemáticamente, Object-Z tiene un mayor conjunto de características que OCL. La definición de Tipos de Datos Básicos y Compuestos, además de los Tipos propios del lenguaje, muchos de ellos presentes también en OCL, hacen de Object-Z de un gran lenguaje para especificaciones formales. El principal problema encontrado durante el desarrollo del caso de estudio fue el manejo de los tipos colección (Set y Sequence). La correcta aplicación de restricciones OCL y Object-Z sobre estos tipos requiere que el diagrama de clases esté completo. Es decir que tenga navegabilidad, rolname y si fuera el caso etiquetas del tipo {ordered}. Si no se tiene un diagrama de clases detallado las especificaciones formales orientadas a objeto, OCL y Object-Z en este caso, podrían no ser lo suficientemente exactas en cuanto al manejo de colecciones. Por otro lado aun teniendo un diagrama de clases básico es posible definir invariantes, precondiciones y postcondiciones que no involucren tipos colección. Con esto se quiere decir que siempre es posible incluir especificaciones formales en su forma más básica. Se piensa firmemente que una especificación formal es mejor que ninguna, precisamente gracias al formalismo presente en ella el cual no está presente en otras formas de especificación. 6. Trabajos relacionado y Trabajo Futuro Además de los lenguajes de especificación mencionados en la Sección 1 existen nuevas propuestas desarrolladas en los últimos años. Una de ellas es el Lenguaje de Modelado de Java (JML) [The Java Modeling Language, 2006]. JLM es utilizado para especificar un diseño detallado de las clases e interfaces en Java. Especifica precondiciones, postcondiciones, invariantes entre otras propiedades. El objetivo de JML es ofrecer un lenguaje de especificación fácil de utilizar para los programadores en java La diferencia con OCL esta en que JML utiliza anotaciones embebidas en el mismo código Java y aplica la misma sintaxis utilizada por los programadores. Existen herramientas que asisten la verificación de expresiones JML de forma dinámica tal como el compilador de JML: jmlc [The Java Modeling Language, 2006] o de forma estática como ESC/Java2 [The ESC/Java2 Project, 2006]. También se han desarrollado herramientas como Daikon [Daikon invariant detector distribution, 2006] para la generación automática de invariantes. La otra propuesta pertenece al grupo de investigación de Microsoft. Ellos proponen Spec# [Microsoft Research: Spec#, 2006], una especie de JML para C#. Spec# es una extensión de C#. Extiende su sistema de tipos para incluir tipos no-nulos y verificar excepciones. También provee diseño por contrato en la forma de precondiciones y postcondiciones. En cuanto a las herramientas desarrolladas presenta un compilador integrado en Microsoft Visual Studio y un Verificador de Programa Estático [Microsoft Research: Spec#, 2006]. Al igual que OCL y JML permite el manejo de invariantes. Como trabajo futuro se retomará el subsistema presentado como caso de estudio para añadir el manejo de prioridades de atención a clientes. Así mismo encontramos necesario realizar un mapeo entre nuestro diseño propuesto y algún lenguaje de implementación que nos permita verificar la correctitud de nuestras especificaciones. Una buena alternativa seria Java puesto que permite especificaciones formales embebidas en el código y existe gran variedad de herramientas. 7. Conclusiones En este artículo se han presentado dos formas de realizar especificaciones formales. La especificación se ha centrado en restricciones sobre los diagramas de clases UML. Se han aplicado invariantes, precondiciones y postcondiciones utilizando el lenguaje de restricciones sobre objetos OCL y Object-Z. Uno de los aspectos más importantes de OCL es que es parte de UML, actualmente el lenguaje de modelamiento estándar bajo el auspicio de OMG (Object Management Group) [Microsoft Research: Spec#, 2006]. Si bien OCL presenta muchas mas funcionalidades que las descritas en este artículo, hemos tomado solo una pequeña parte para mostrar como especificar restricciones de manera formal en los diagrama de clases.

10 La gran propiedad de Object-Z es la de ser una extensión conservativa de un lenguaje de especificaciones formales como Z. El lenguaje Object-Z es muy útil para la especificación de sistemas críticos. Aquellos donde se requiere una seguridad de que su diseño e implementación futura son garantías de calidad absoluta Con respecto a los lenguajes de especificación mencionados en la Sección 4 una de las ventajas que es encontrada en OCL sobre JML y Spec# es que OCL y Object-Z es independiente del lenguaje de implementación. OCL y Object-Z es utilizado en las primeras etapas del desarrollo de software mientras que JML y Spec# son utilizados en la fase de implementación, cuando descubrir los errores puede costarnos demasiado caro [Asger, 2001]. Nuestro objetivo es incrementar el uso de especificaciones formales en el proceso de desarrollo. Creemos que el uso de precondiciones, postcondiciones e invariantes en las primeras etapas del desarrollo nos permite incrementar la correctitud del software que estamos desarrollando. 8. Referencias [Hamie, Howse, and Kent, 1998] A. Hamie, J. Howse and S. Kent (1998). Interpreting the Object Constraint Language. Division of Computing, University of Brighton, Lewes Rd., Brighton, UK. [Abstract State Machines, 2006] Abstract State Machines (2006). A Formal Method for Specification and Verification. [Meyre, 1997] Meyer, B. (1997). Object-oriented Software Construction. New York, NY, second edition, Prentice Hall. [George, 1992] George, C. (1992). The RAISE Specification Language. The RAISE Language Group. [Larsson, and Mostowski, 2003] D. Larsson W. Mostowski (2003). Specifying JAVACARD API in OCL. Computing Science Department Chalmers University of Technology Goteborg, Sweden, Electronic Notes in Theoretical Computer Science. [Daikon invariant detector distribution, 2006] Daikon invariant detector distribution (2006). [Asger, 2001] Asger, E. (2001). Specification with RAISE a brief introduction. Department of Civl Engineering and Informatics and Mathematical Modeling, Technical University of Denmark. [Sommerville, 2001] Sommerville, I. (2001). Software Engineering. Sixth Edition, Addison Wesley. [Information on VDM and VDM++, 2006] Information on VDM and VDM++ (2006). [Booch, Rumbaugh, and Jacobson, I. 1998] G. Booch, J. Rumbaugh, and I. Jacobson (1998). The Unified Modeling Language User Guide. Addison-Wesley. [Rumbaugh, Jacobson, and Booch, G. 1998] J. Rumbaugh, I. Jacobson, and G. Booch (1998). The Unified Modeling Language Reference Manual. Addison-Wesley. [Warner. and Kleppe, 1999] J. Warmer and A. Kleppe (1999). OCL: The constraint language of the UML. Journal of Object-Oriented Programming. [Warner, and Kleppe, 1998] J. Warmer and A. Kleppe (1998). The Object Constraint Language: Precise Modeling with UML. Addison-Wesley. [Ritchie, 2004] Richters, M. (2004). A Precise Approach to Validating UML Models and OCL Constraints. PhD thesis Universitat Bremen, Fachbereich.

11 [Microsoft Research: Spec#, 2006] Microsoft Research: Spec# (2006). [OMG,1999] OMG (1999). UML Notation Guide. In OMG Unified Modeling Language Specification. Version 1.3. [Rational Software Corporation, 2006] Rational Software Corporation (2006). The Object Constraint Language Specification Version [The B-Method, 2006] The B-Method (2006). [The ESC/Java2 Project, 2006] The ESC/Java2 Project (2006). [The Java Modeling Language, 2006] The Java Modeling Language (2006). [The Octopus WebPage, 2006] The Octopus WebPage (2006). [The Z Notation, 2006] The Z Notation (2006). [Vidal, and Andrades 2007] Vidal C. and Andrades M. (2007). Especificación Formal de un Electrocardiógrafo Digital en Object-Z. Seminario Internacional de Calidad en las Tecnologías de la Información. Cuba.