Documento 621929

UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS
FACULTAD DE INGENIERÍA
PROYECTO CURRICULAR
INGENIERÍA DE SISTEMAS
OCL
(Lenguaje de Restricción de Objetos)
John Haiver Malagón Moreno
Sandra Patricia Lamilla Córdoba
20041020102
20041020108
Presentado a:
Julio Barón
Ingeniería de Software I
Marzo 6 de 2008
Bogotá D.C.
OCL
(Object Constraint Language)
1.- OBJETIVOS ............................................................................................................ 3
2.- INTRODUCCIÓN ..................................................................................................... 4
3.- MARCO TEÓRICO .................................................................................................. 5
3.1. DEFINICIÓN .......................................................................................................... 5
3.2. CARÁCTERÍSTICAS ................................................................................................ 5
3.3. TIPOS DE DEFINICIONES ........................................................................................ 6
3.4. TIPOS DE DATOS .................................................................................................. 7
4.- CONCLUSIONES .................................................................................................... 8
5.- REFERENCIAS ....................................................................................................... 9
2
OBJETIVO GENERAL
Identificar y comprender las características y funciones del lenguaje textual OCL
(Lenguaje de Restricción de Objetos) que provee UML.
OBJETIVOS ESPECIFICOS
Comprender que el Lenguaje de Restricción de Objetos esta incorporado en UML
como un estándar para especificar detalles adicionales, o precisar detalles en la
estructura de los modelos.
Identificar OCL como un lenguaje de expresión, que se utiliza únicamente para
expresar un valor, sin provocar cambios en el modelo; de un lenguaje de modelado,
porque no es ejecutable, no es un lenguaje de programación; y de un lenguaje formal,
porque todos sus elementos han sido definidos formalmente.
3
INTRODUCCIÓN
Una imagen puede describir muchas palabras. De igual modo, un modelo gráfico
puede describir una cierta parte del comportamiento, después de la cual es necesario
rellenar detalles adicionales con palabras. Describiendo algo con palabras, sin
embargo, casi siempre desemboca en ambiguedades; por ejemplo, “¿que quería decir
cuando escribió eso?”. El Lenguaje Restrictivo (constraint) de Objetos (OCL) está
incorporado en UML como un estándar para especificar detalles adicionales, o precisar
detalles en la estrucutura de los modelos.
Desarrollado dentro de la IBM Insurace Division como un lenguaje de modelado de
negocio, el OCL es un lenguaje formal diseñado para ser fácil de leer y de escribir.
OCL es más funcional que el lenguaje natural, pero no tan preciso como un lenguaje
de programación - no puede ser usado para escribir lógicas de lógica de programación
o control de flujo. Puesto que OCL es un lenguaje para la expresión pura, sus
declaraciones están garantizadas de no tener efectos laterales - simplemente
transportan un valor y nunca pueden cambiar el estado del sistema.
4
MARCO TEÓRICO
Definición
El lenguaje de especificación OCL aparece en el documento “Semántica de UML”
como lenguaje propuesto para especificar las restricciones semánticas del diagrama
de clases, junto a otro tipo de definiciones. OCL se puede utilizar en cualquier contexto
en que se use el diagrama de clases al que esté asociado (como por ejemplo, en el
modelo conceptual o en el diseño).
OCL es un lenguaje híbrido orientado a objetos-funcional, y es tipificado, porque usa el
concepto de tipos de datos. Estos tipos de datos se encuentran jerarquizados a través
de relaciones de inclusión. También existen varios tipos básicos predefinidos
(similares a los de cualquier lenguaje), y unos pocos tipos paramétricos (o
estructurados) predefinidos. Los tipos no predefinidos van a estar asociados a las
clases del diagrama de clases.
Características







El componente central construido por este lenguaje es la expresión, que se
manipula a través de operaciones que garantizan la transparencia referencial y
la falta de efectos colaterales. Estas son características compartidas con los
lenguajes funcionales, que son declarativos. Toda expresión válida para el
lenguaje OCL debe tener asociado un tipo de datos.
Las expresiones se pueden mapear fácilmente al concepto de objetos, ya que
cada tipo básico no predefinido se puede vincular a una clase del diagrama, y
algunas de las operaciones de un tipo básico no predefinido se modelan como
atributos y métodos/responsabilidades de la clase original.
Las asociaciones entre clases también se modelan en OCL usando los roles de
ambas clases participantes en la asociación, que deben estar rotulados (en
ambos extremos). El rol de una clase en una asociación con una segunda
clase, expresa que ese rol es un pseudoatributo del tipo de dato vinculado a
esa segunda clase. Todos estos componentes asociados a las clases, también
se ven reflejados en los tipos de OCL.
Las expresiones del lenguaje OCL se estructuran hasta llegar a su punto más
alto, que es el de formar parte de una definición. En cada definición de OCL se
describe cada restricción semántica del diagrama de clases, junto a otras
propiedades también descriptas con expresiones.
Cada definición en OCL se aplica a lo que se llama un contexto, que
representa el destinatario del diagrama de clases sobre quien se aplica esa
definición. Entre estos contextos se encuentran:
 Una clase (se aplica a todas expresiones-objetos cuyo tipo de datos
asociado
es el vinculado a esta clase).
 Un método/responsabilidad de una clase.
 Un atributo derivado de una clase.
 Un método/responsabilidad derivado (también llamado query) de una
clase.
Las expresiones OCL utilizan vocabulario del diagrama de clases UML. Sus
predicados “navegan” el diagrama de clases: “context” especifica el elemento
del cual se está hablando, “self” indica el objeto actual,“result” representa el
valor de retorno.Mediante “->” pueden utilizarse operaciones sobre colecciones
(select, reject, exists, size, forAll, etc…).
las expresiones OCL se pueden referir a: conjunto de nombres de clase, un
conjunto de atributos asociados con las clases, conjunto de operaciones de
5
esas clases sin efectos colaterales, conjunto de nombres de asociaciones y
lista de clases que participan, nombres de roles y multiplicidades.
Tipos de definiciones
1. Invariantes
context idclase
inv: [[Descripción del invariante]] expBool
Representa una condición (restricción semántica) que deben cumplir todas las
expresiones-objetos pertenecientes al tipo de datos vinculados a la clase idclase. La
condición a cumplirse se expresa en la expresión expBool que es de tipo Boolean
(lógico). La expresión booleana debe evaluar en verdadero si se aplica a expresionesobjetos perteneciente al tipo de la clase en cuestión que son válidos bajo este
invariante. Para el resto de las expresiones-objetos (que son inválidas según este
invariante), la expresión debe evaluar en falso.
Estos invariantes pueden tener una descripción optativa (que se escribe entre
corchetes).
2. Invariantes de método/responsabilidad
context idclase::idmetodo(par1:T1, ,parn:Tn)[:Tres]
pre: [[Descripción precondición]] expBool
post: [[Descripción postcondición]] expBool
Define la “aplicabilidad” de un método/responsabilidad (de nombre idmetodo, existente
dentro de la clase idclase con parámetros formales par1 a parn de tipo T1 a Tn , y con
imagen de tipo Tres -sólo en el caso que retorne una expresión-). La cláusula pre
refleja la precondición de este método/responsabilidad, expresada en la primera
expresión booleana expBool, que deberá retornar verdadero sólo para aquellas
expresiones-objetos para la cual este método sea aplicable. La cláusula post refleja la
postcondición de este método/responsabilidad, expresada en la segunda expresión
booleana expBool, que deberá retornar verdadero sólo cuando el estado final de la
expresión-objeto al que se le aplicó este método/responsabilidad es consistente con el
accionar del mismo.
No existirían problemas si el método/responsabilidad retorna una expresión y no
modifica el estado interno de la expresión-objeto original, ya que la postcondición sólo
verificaría el resultado que retorna. Pero si no retorna un valor (porque en realidad
modifica el estado interno de la expresión-objeto original), la naturaleza de la
postcondición es distinta que la anterior, ya que existe un efecto colateral de por
medio. En este último caso no se especifica cómo se actualiza el estado interno de la
expresión-objeto original (ya que esto no sería declarativo), sino la condición en que
debe
quedar
la
expresión-objeto
original
luego
de
aplicarle
este
método/responsabilidad. Este invariante terminaría reflejando en forma declarativa su
definición en sí misma.
3. Definición de atributos derivados
context idclase::idatributo:T
derive: expT
Define un atributo derivado de nombre idatributo existente en la clase idclase, y que
retornará una expresión de tipo T. La expresión retornada por este atributo derivado, al
aplicarla sobre una expresión-objeto de la clase en cuestión, retornará la expresión
expT, que también deberá ser de tipo T.
4. Definición de métodos/responsabilidades derivados (queries):
context idclase::idmetodo(par1:T1, ,parn:Tn):T
[pre: [[Descripción precondición]] expBool]
body: expT
Define un método/responsabilidad derivado Como es un método/responsabilidad, el
contexto es idéntico al de un método/responsabilidad común, con la diferencia que
siempre retornará una expresión (que deberá ser de tipo T) y no provocará efectos
6
colateriales. La cláusula pre optativa determina si es aplicable o no (según el resultado
de expBool) a cada expresión-objeto de la clase. En forma análoga a los atributos
derivados, en la cláusula body se especifica cuál será el valor retornado para cada
expresión-objeto de la clase que sea aplicable, a través de la expresión expT, que será
de tipo T.
Tipos de datos
1. Predefinidos
a) Básicos
 Boolean (valores lógicos)
 Integer (valores enteros)
 Real (valores reales)
 String (valores de cadenas de caracteres)
 OCLAny (el tipo supremo jerárquico de todos los tipos no estructurados)
 OCLType (el tipo asociado a los metatipos -todo tipo puede verse como
una expresión de tipo OCLType)
b) Estructurados
 Collection(T)
 Set(T): corresponde a los conjuntos de expresiones de tipo T, que no contienen
repeticiones y sus expresiones contenidas no poseen un orden posicional.
 Bag(T): corresponde a los bags de expresiones de tipo T, que permiten
contener repeticiones y donde sus expresiones contenidas no poseen un orden
posicional.
 OrderedSet (T): corresponde a los conjuntos “ordenados” de expresiones de
tipo T, que no contienen repeticiones y sus expresiones contenidas poseen un
orden posicional.
 Sequence(T): corresponde a las secuencias (listas) de expresiones de tipo T,
que permiten contener repeticiones y donde sus expresiones poseen un orden
posicional.
 Collection(T): corresponde a las colecciones de expresiones de tipo T. Es un
tipo que es abstracto y superior jerárquico de los cuatro anteriores.
 Tuple{id1:T1,..., idn:Tn}: (con n>0) corresponde a las tuplas (registros/records)
con campos de nombre id1 a idn , donde cada uno de ellos debe tener
asociada una expresión de tipo T1 a Tn respectivamente.
2. No predefinidos
Corresponden a cada clase y enumerado del diagrama de clases. Toda clase o
enumerado C se mapeará al tipo asociado TC de OCL.
En OCL cada atributo de una clase, al aplicarse a una expresión del tipo asociado a la
clase, retorna una expresión que también tendrá un tipo asociado. Con esto, decimos,
que todo atributo tiene también un tipo asociado. Esto ya se dijo en la definición de
atributos derivados, cuando se expresó que éstos retornan una expresión de un tipo
resultante especificado. Con esto, decimos que todo atributo atrib tiene asociado en
OCL el tipo de dato Tatrib. Este tipo no es necesariamente nuevo (como en el caso de
los provenientes de clases o enumerados). Al no definir un tipo necesariamente nuevo,
en este apunte diremos que el tipo retornado es T.
Si utilizamos el diagrama de clases dentro del contexto del diseño, seguramente cada
atributo de cada clase tendrá su tipo de datos asociado en forma explícita en la misma
clase del diagrama, y con esto se puede mapear al tipo correspondiente de OCL. El
problema que existe en el diagrama de clases del modelo conceptual es que en las
clases conceptuales no se especifican tipos de datos. Esto sugiere la idea de
existencia de dominios –como abstracciones respecto a los tipos- (los atributos de las
clases conceptuales retornan un objeto de un dominio, en lugar de una expresiónobjeto de un tipo de datos). En este caso hay que realizar un mapeo implícito de los
dominios de los atributos a tipos básicos de OCL para poder expresar condiciones en
OCL que se apliquen sobre los valores retornados por estos atributos.
7
CONCLUSIONES

La combinación de UML y OCL mejorará definitivamente el proceso de
desarrollo software e incrementará la calidad del software desarrollado.

OCL sólo puede procesar funciones recursivas primitivas y no cualquier función
recursiva. En otras palabras, OCL no es equivalente a la máquina de Turing.

OCL hace práctica la construcción de modelos más formales. De esta forma es
más fácil encontrar los errores en fases más tempranas del proyecto.
Fijándolos durante el modelaje es más barato que al final del código.

OCL es un producto de la familia UML, concebido con la idea de ser fácil de
escribir y leer para alguien familiarizado con este entorno. Por tanto, una de las
grandes ventajas de OCL es que el usuario no necesitará tener fuertes
conocimientos matemáticos o lógicos para poder escribir restricciones.
8
REFERENCIAS
[1] http://www-2.dc.uba.ar/materias/isoft1/is1-2005_2/apuntes/OCL.pdf
[2] http://ing.de.soft1.googlepages.com/OCL.pdf
[3] http://www.dsic.upv.es/asignaturas/facultad/lsi/trabajos/132000.doc
9