PDF de programación - Clase 8: Modelos de objetos e invariantes

Clase 8: Modelos de objetos e invariantes

En este tema se consolidan muchas de las ideas fundamentales sobre objetos, representaciones y abstracción,
tratadas en temas anteriores. Explicaremos detalladamente la notación gráfica del modelado de objetos y
repasaremos los invariantes de representación, las funciones de abstracción y la exposición de representación.
Después de leer este tema, es posible que desee volver a los temas del principio para darles un repaso, ya que
éstos incluyen más detalles en relación a los ejemplos tratados aquí.


8.1 Modelos de objetos
Un modelo de objeto es una descripción de una colección de configuraciones. En este tema, nos centraremos en
modelos de objeto en forma de código, en los que las configuraciones son estados de un programa. Sin embargo,
a lo largo de la asignatura, veremos que se puede utilizar una misma notación, de forma más genérica, para
describir cualquier tipo de configuración, como el formato de un sistema de archivos, una jerarquía de seguridad,
una topología de red, etc.

Las nociones básicas que yacen bajo los modelos de objeto son increíblemente simples: conjuntos de objetos y las
relaciones entre ellos. Lo más complicado para los estudiantes es aprender a construir un modelo útil: cómo
capturar las partes interesantes y complicadas de un programa y cómo no entusiasmarse con el modelado de las
partes irrelevantes y acabar ante un modelo enorme y de difícil manejo, o por el contrario, decir muy poco, y
verse ante un modelo que resulta inútil.

Tanto los modelos de objeto como los diagramas de dependencia de módulos, poseen recuadros y flechas. He
aquí la única similitud entre ellos. Bueno, de acuerdo, admito que existen algunas conexiones sutiles entre el
modelo de objeto y el diagrama de dependencia de módulos de un programa. Sin embargo, a primera vista, es
mejor pensar en ellos como si fuesen completamente diferentes. El diagrama de dependencia de módulos aborda
la estructura sintáctica, es decir, las descripciones textuales que existen, y cómo éstas están relacionadas entre sí.
El modelo de objeto se centra en la estructura semántica, es decir, qué configuraciones se crean en tiempo de
ejecución, y qué propiedades poseen.

8.1.1 Clasificación

Un modelo de objeto expresa dos tipos de propiedades: la clasificación de objetos y las relaciones entre ellos.
Para expresar la clasificación, dibujamos un recuadro para cada clase de objetos. En un modelo de objeto en
forma de código, estos recuadros corresponderán a las clases e interfaces de Java; en una definición más general,
simplemente representarán clasificaciones arbitrarias.

47

List

List

ArrayList

LinkedList

ArrayList

LinkedList

Una flecha con la punta gruesa y cerrada, desde la clase A hasta la
clase B, indica que A representa un subconjunto de B: es decir, todo A es también un B. Para demostrar que dos
recuadros representan subconjuntos distintos, hacemos que éstos compartan la misma punta de flecha. En el
diagrama de arriba, LinkedList y ArrayList son subconjuntos distintos de List.
En Java, cada declaración implements y extends da como resultado una relación de subconjuntos en un modelo de
objetos. Ésta es una propiedad del sistema de tipos: si un objeto o se crea con un constructor de una clase C, y C
extiende a D, entonces se considera que o también posee al tipo D. El diagrama de arriba muestra el modelo de
objetos a la izquierda.
El de la derecha es un diagrama de dependencia de módulos. Sus recuadros representan descripciones
textuales, como el código de las clases. Sus flechas, tal como usted recordará, representan la relación
"meet" (satisfacer). Por tanto, la flecha que parte de ArrayList hacia List indica que el código
de ArrayList satisface la especificación List.. Dicho de otro modo, los objetos de la clase ArrayList se comportan
como listas abstractas. Esta es una propiedad sutil que es verdadera debido a los detalles del código. Como
veremos más adelante en el tema sobre subtipado (o derivación), es fácil engañarse con esta característica y crear
una clase que extiende o implementa a otra sin que exista una relación “meet” entre ellas (en un diagrama de
dependencia de módulos, el compartir la punta de la flecha no tiene ninguna importancia).


8.1.2 Campos

Una flecha con una punta abierta desde A hacia B indica que existe una relación entre los objetos de A y los de B.
Dado que pueden existir muchas relaciones entre dos clases, le damos nombre a las relaciones y etiquetamos las
flechas con los nombres. Un campo f en una clase A, cuyo tipo es B, da como resultado una flecha desde A hasta
B etiquetada como f (el nombre del campo).
Por ejemplo, el siguiente código produce estructuras que pueden ilustrarse a través del diagrama que se muestra a
continuación (ignore por el momento las marcas al final de las flechas):


48

prev

!

!

List

?
header
!

Entry

element
?

Object

!

!

next

class LinkedList implements List {

Entry header;
…
}

class Entry {
Entry next;
Entry prev;
Object elt;
…
}

8.1.3 Multiplicidad

Hasta ahora, hemos visto la clasificación de los objetos en clases y las relaciones que muestran que los objetos de
una clase pueden estar relacionados con los objetos de otra. Una cuestión básica sobre la relación entre las clases
es la multiplicidad: cuántos objetos de una clase pueden estar relacionados con un determinado objeto de otra
clase.


49

Los símbolos de multiplicidad son:
· * (cero o más)
+ (uno o más)
·
? (cero o uno)
·
! (exactamente uno).
·
Cuando se omite un símbolo, * es el símbolo que se asume por defecto (que no indica nada). La interpretación de
estas marcas consiste en que cuando hay una marca n en el final B de una flecha de campo f que parte de la clase
A hacia la clase B, existen n miembros de la clase B asociados por f con cada A. Esto también funciona al revés; si
hay una marca m en el inicio A de una flecha de campo f que parte desde A hacia B, cada B es asociada por los m
miembros de la clase A.
En el final de la flecha, es decir, hacia donde mira la punta de la misma, la multiplicidad le indica cuántos objetos
puede referenciar una variable. Hasta ahora, no hemos asignado ningún uso a las marcas * y +, pero veremos
cómo éstas se utilizan con campos abstractos. La elección de ? o ! depende de si un campo puede o no ser null.
Al inicio de la flecha, la multiplicidad señala cuántos objetos pueden apuntar a un determinado objeto. Dicho de
otro modo, nos da información sobre el hecho de compartir.
Observemos algunas de las flechas y veamos qué nos indican sus multiplicidades:
. Para el campo header, el símbolo ! al final de la flecha, indica que cada objeto de la clase List está
relacionado exactamente con un objeto de la clase Entry por el campo header. El símbolo ? al inicio de la flecha,
indica que cada objeto Entry es el objeto header de un objeto List como máximo.


·

Para el campo element, el símbolo ? al final de la flecha indica que el campo element de un objeto Entry
apunta a cero o a uno de los objetos de la clase Object. Dicho de otro modo, éste puede ser null: un objeto List
puede almacenar referencias null. La ausencia de un símbolo al inicio de la flecha, indica que un objeto puede
estar apuntado por el campo element de cualquier número de objetos Entry. Es decir, una List puede almacenar
duplicados.


· Para el campo next, el símbolo ! al final y al inicio de la flecha indica que el campo next de todo objeto Entry

apunta a un objeto Entry, y todo objeto Entry queda apuntado por el campo next de un objeto Entry.


8.1.4 Mutabilidad

Hasta ahora, todas las características del modelo de objetos que hemos descrito restringen a los estados
individuales. Las restricciones de mutabilidad describen cómo pueden alterarse los estados. Para mostrar que una
restricción de multiplicidad se ha violado, es necesario exhibir un único estado, pero para exponer la violación de
una restricción de mutabilidad, necesitamos mostrar dos estados que representen el estado anterior y posterior a la
alteración global del estado. Las restricciones de mutabilidad se pueden aplicar a ambos conjuntos y relaciones,
pero por ahora, tendremos en cuenta únicamente una forma limitada, en la cual una barra (figura de arriba)
opcional se puede usar para marcar el final de una flecha de campo. Cuando está presente, esta marca indica que
un objeto con el cual un determinado objeto está relacionado a través de un campo, debe ser siempre el mismo.
En este caso, decimos que el campo es inmutable, estático, o más exactamente, target static (o estático al final de
la flecha, dado que más tarde facilitaremos un significado para una barra situada al inicio de la flecha).


50

En nuestro diagrama, por ejemplo, la barra al final de la relación header indica que un objeto List, una vez creado,
siempre apunta a través de su campo header al mismo objeto Entry. Un objeto es inmutable si todos sus campos
son inmutables. Se dice que una clase es inmutable si sus objetos son inmutables.


8.1.5 Diagramas de instancia

El significado de un modelo de objetos es una colección de configuraciones, es decir, todas las que satisfacen las
restricciones del modelo. Éstas se pueden representar en diagramas de instancia o snapshots (un snapshot es una
representación simplificada), que son simplemente grafos que se componen de objetos y referencias que los
conectan. Cada objeto está etiquetado con la clase (la más específica) a la que pertenecen. Cada referencia está
etiquetada con el campo que representa.
La relación entre un snapshot y un modelo de objeto es igual que la relación entre una instancia de un objeto y
una clase, o como la relación entre una sentencia y la gramática.
La figura de abajo muestra un snapshot legal (que pertenece a la colección representada por el modelo de objeto