PDF de programación - Clase 19. Modelos conceptuales

Clase 19. Modelos conceptuales

La misma notación de modelado de objetos que hemos utilizado para describir la estructura
de la pila en programas que se están ejecutando –es decir, qué objetos hay y cómo se hallan
relacionados por campos– puede emplearse de un modo más abstracto para describir el
estado espacial de un sistema o del entorno en el que éste opera. Denominaremos a estos
modelos "modelos conceptuales", aunque el libro de texto se refiere a ellos como "modelos
de datos". Ya hemos construido algunos de estos modelos en los ejemplos preparatorios del
ejercicio 4, y también al describir mediante la notación de modelado de objetos la
estructura del sistema de metro de Boston.

La notación en sí es sumamente sencilla, y los modelos se interpretan fácilmente una vez
dejemos de lado el enfoque orientado a la implementación y sustituyamos los objetos de
Java por entidades reales, los campos por relaciones, etc. Tras esta clase, el estudiante
estará en disposición de leer modelos conceptuales sin ningún tipo de problema.

Escribirlos, en cambio, requiere una mayor práctica, ya que implica crear las abstracciones
apropiadas, al igual que cuando se diseña la interfaz de un tipo de datos abstractos.
Construir correctamente las abstracciones es una tarea difícil, aunque la dificultad no tiene
que ver con el modelado de objetos en particular, sino con el hecho de que siempre resulta
complicado captar la esencia de un problema y articularlo de un modo conciso.

Una vez hayamos superado este obstáculo y construido un modelo conceptual, nos
hallaremos ya encaminados hacia la solución del problema. Como se suele decir, describir
un problema con exactitud es el primer paso para solucionarlo, y en el campo del desarrollo
de software una descripción exacta supone haber recorrido más de la mitad del camino.

No espere ser capaz de crear modelos conceptuales sin la práctica necesaria. Poner en
práctica sus habilidades de modelado le resultará muy entretenido y a medida que las
perfeccione descubrirá que se va convirtiendo en un diseñador más competente. Al ir
ganando claridad en sus estructuras conceptuales, las estructuras de su código se harán a su
vez más simples y más nítidas, y la codificación resultará más productiva.

En la clase propiamente dicha trataremos de dar una idea de cómo los modelos se crean
incrementalmente. En estas notas de clase, en cambio, los modelos se muestran en su forma
final.

19.1 Átomos, conjuntos y relaciones

Las estructuras de los modelos se pueden construir a partir de conjuntos, relaciones y
átomos. Un átomo es una partícula elemental que se caracteriza por ser:

· indivisible: no se puede descomponer en partes más pequeñas;

· invariable: sus propiedades no se alteran con el paso del tiempo; y
· no interpretable: carece de propiedades internas, al contrario de lo que, por ejemplo,
ocurre con los números.

Aparte de estas partículas elementales, muy pocas cosas en el mundo físico tienen
estructura atómica. Sin embargo, nada nos impide modelarlas de este modo; de hecho, el
modelado que proponemos no incluye ninguna idea de composición. Así, para modelar una
parte x formada por las partes y y z, consideraremos que tanto x como y y z son atómicas y
representaremos las restricciones mediante una relación explícita entre ellas.

Un conjunto es una suma de átomos no sujeta a las nociones de orden o cuenta de
repetición. Por su parte, una relación es una estructura que crea correspondencias entre los
átomos. Desde el punto de vista matemático, consiste en un conjunto de pares, cada uno de
ellos formado por dos átomos y dispuestos en un orden determinado. Podemos imaginar
una relación como una tabla de dos columnas en la que cada entrada es un átomo. El orden
en el que se hallan dispuestas las columnas es importante, mientras que el orden de las filas
no lo es. Cada fila debe tener una entrada en cada columna.

Resulta conveniente definir algunos de los operadores de conjuntos y relaciones. En
principio, nos servirán para explicar los modelos gráficos, aunque también pueden
utilizarse para escribir reglas más expresivas.

Dados dos conjuntos s y t, podemos tomar su suma (s+t), su intersección (s&t) o su
diferencia (s-t). Así, escribiremos no s para decir que una expresión indica un conjunto
vacío, y some s si lo que indica es un conjunto no vacío. Si lo que deseamos decir es que
cada miembro de s es a la vez miembro de t, escribiremos s in t; y s = t cuando cada
elemento de s sea un elemento de t y viceversa.

Dados un conjunto s y una relación r, escribiremos s.r para la imagen de s vinculada a la
relación r: el conjunto de elementos al que r asocia los elementos de s, lo que podemos
definir formalmente como:

s.r = {y | some x: s | (x,y) in r}

Dada una relación r, escribiremos ~r para indicar el intercambio de r: la relación de imagen
invertida, definida como:
~r = {(y,x) | (x,y) in r}


Por último, escribiremos +r para indicar el cierre transitivo de r: se trata de la relación que
asocia x a y, cuando existe alguna secuencia finita de átomos z1, z2, …, zn tal que

(x,z1) in r (z1,z2) in
r (z2,z3) in r

(zn,y) in r

y *r para indicar el cierre transitivo reflexivo de r, un cierre básicamente igual que el
transitivo, pero que además relaciona cada átomo consigo mismo. El cierre transitivo

tomaría la imagen a partir de una, dos, tres o más aplicaciones de la relación, mientras que
el cierre transitivo reflexivo no incluiría ninguna aplicación.


Veamos algunos ejemplos. Supongamos que tenemos un conjunto de gente llamado Person
que existe actualmente o existió en un momento dado, los conjuntos Man y Woman de
personas de sexo masculino o femenino, la relación parents que asocia a una persona con
sus padres, y la relación spouse que asocia a una persona con su cónyuge.
Interprete cada una de las siguientes afirmaciones. ¿Cuáles son válidas en el mundo real?

no (Man & Woman)
Man + Woman = Person
all p: Person | some p.spouse => p.spouse.spouse = p all p:
Person | some p.spouse
all p: Person | some p.parents
no p: Person | p.spouse = p
all p: Person | p.sisters = {q: Woman | p.parents = q.parents} all
p: Person | p.siblings = p.parents.~parents

Hasta aquí, hemos mostrado observaciones elementales relativas al mundo real y a
definiciones de términos. Las que planteamos a continuación, en cambio, se adentran en
terrenos más problemáticos:

no p: Person | some (p.parents & p.spouse.parents)
Man.spouse in Woman
some adam: Person | all p: Person | adam in p.*parents all
p: Man | no q, r: p.spouse | q != r

Suponiendo que el estudiante es capaz de comprender la notación lógica básica, hemos
introducido la definición de hermana (sister)
¿Cómo se escribirían las siguientes frases según esta notación?:

Todo el mundo tiene una madre
Nadie tiene dos madres
Los primos son personas que tienen un abuelo en común


La primera afirmación ilustra un punto interesante e importante: es muy cómodo dar por
supuesto que el significado de un término es siempre el más obvio, pero resulta muy
peligroso cuando hablamos de desarrollo de software. En este campo, la ambigüedad y la
indefinición en el significado de los términos son una fuente constante de problemas. Si los
desarrolladores entienden los requisitos de maneras distintas, acabarán implementando
módulos incompatibles entre sí, o que no sirvan para satisfacer las necesidades del cliente.




Por lo tanto, es necesario tener cuidado a la hora de expresar lo que significa cada conjunto
y cada relación. En este caso concreto, se debe precisar el significado del término mother.
¿Se trata de la madre legal o de la madre biológica? ¿O el término se refiere a algo distinto?
Al construir un modelo conceptual en el que se emplean términos que no se hallan
definidos en el contexto en el que estamos trabajando, se debe elaborar un glosario. Así, en
este ejemplo, escribiríamos en el glosario:
mother: (p,q) in mother significa que la persona q es la madre biológica de la persona p.

19.2 Notación gráfica

No es necesario volver a explicar detalladamente la notación gráfica, que ya vimos en la
clase de modelado de objetos. En esta clase nos limitaremos a reinterpretar la notación de
un modo más abstracto.

Fijémonos en el modelo de objeto correspondiente al árbol de familia. Cada cuadro indica
un conjunto de átomos, no un conjunto de objetos de un programa de Java ni de una clase.
Las flechas con la punta abierta indican la relación entre un conjunto y otro. Se trata de una
asociación abstracta, no de un campo ni de una variable de instancia.

Obviamente, las consecuencias semánticas son distintas dependiendo de cuál sea el sentido
de la flecha: es muy diferente decir que p es el padre de q o decir lo contrario. Sin embargo,
en cualquier relación podemos utilizar por igual una relación diferente que sea su inversa:
hijos (children) en vez de padres (parents), por ejemplo. No existe una noción de
navegabilidad, ni tampoco la idea de que una relación pertenezca a un conjunto del mismo
modo que una variable de instancia pertenece a una clase.





La flecha de trazo grueso con la punta cerrada indica un subconjunto. Dos conjuntos que
comparten una flecha son disjuntos. Podemos rellenar la punta de la flecha para indicar que
los subconjuntos son también exhaustivos; es decir, que cada elemento que forma el
superconjunto forma parte de al menos uno de los subconjuntos. En el presente ejemplo,
hemos expresado que cada persona (Person) es un hombre (Man) o una mujer (Woman).


Los conjuntos que no tienen superconjuntos se conocen como dominios (domains