Pid 00161676

Abstraccin
y clasificacin
Criterios de modelado
con objetos y clases
Jordi Brnquez Jimnez
Miguel ngel Sicilia Urbn
PID_00161676
FUOC PID_00161676 Abstraccin y clasificacin
ndice
Introduccin ............................................................................................ 5
Objetivos ................................................................................................... 7
1. Complejidad y abstraccin ............................................................. 9

1.1. La complejidad inherente al software ............................................ 9
1.2. La abstraccin en el desarrollo de software .................................... 10
2. Los principios de la clasificacin .................................................. 12

2.1. Modelar pensando en los objetos ................................................... 12
2.2. Modelar pensando en las clases ...................................................... 15
2.3. Identificacin de las operaciones ................................................... 16
3. Relaciones entre clases ..................................................................... 18

3.1. Propiedades de las asociaciones ...................................................... 18
3.1.1. Cardinalidad ........................................................................ 18
3.1.2. Navegabilidad ...................................................................... 21
3.1.3. Roles .................................................................................... 22
3.2. Tipos de asociaciones ..................................................................... 22
3.2.1. Asociaciones reflexivas ........................................................ 22
3.2.2. Asociaciones de agregacin ................................................. 23
3.2.3. Asociaciones de composicin ............................................. 24
3.3. El concepto de clase asociativa ....................................................... 24
3.4. Relacin de generalizacin/especializacin ................................... 25
4. Tcnica simple para identificar clases ........................................ 26

4.1. Descripcin de la tcnica ................................................................ 26
4.2. Ejemplo prctico ............................................................................. 27
5. Tipos de clases .................................................................................... 29

5.1. Clases abstractas ............................................................................. 29
5.2. Clases parametrizadas ..................................................................... 30
5.3. Clases finales ................................................................................... 30
Resumen .................................................................................................... 31
Ejercicios de autoevaluacin ............................................................... 33
Ejercicios de modelado ......................................................................... 33
Solucionario ............................................................................................. 34
Glosario ..................................................................................................... 35
Bibliografa .............................................................................................. 36
FUOC PID_00161676 5 Abstraccin y clasificacin
Introduccin
En este mdulo, planteamos la orientacin a objetos como un mecanismo de

abstraccin centrado en los datos.
Dicho de otra manera, cuando nos enfrentamos al desarrollo de una aplica-

cin para resolver un problema, el dominio del problema es habitualmente
mucho ms amplio y complejo de lo que se requiere capturar estrictamente
para construir la aplicacin.
Ejemplo
Si queremos desarrollar una aplicacin para gestionar las calificaciones de evaluacin

continua de una universidad, el dominio del problema es decir, el universo de concep-
tos y relaciones que queremos representar en la aplicacin tiene que incluir los planes
de estudio, la estructura organizativa del centro, el modelo pedaggico, etc. Sin embargo,
de todos estos elementos y sus detalles tendremos que abstraer es decir, seleccionar los
que son imprescindibles para las funcionalidades concretas que queremos que haga nues-
tra aplicacin. Siguiendo el ejemplo, slo lo que los estudiantes y profesores necesitan
para consultar y actualizar las calificaciones, respectivamente. As, es posible que, para el
problema concreto del registro de evaluaciones, lo nico que necesitemos tener en cuen-
ta respecto de los planes de estudios sea que haya asignaturas, estudiantes y sus califica-
ciones, y podamos obviar, por ejemplo, las dependencias entre unas asignaturas y otras
(aunque, probablemente, este hecho deba ser tenido en cuenta por otras aplicaciones del
mismo centro).
En la orientacin a objetos, la informacin del dominio se representa en dos En el mdulo Clases y objetos, ya
hemos visto los conceptos de clase
y objeto.
niveles, objetos y clases. Los primeros son representaciones de entidades indi-
viduales concretas (por ejemplo, los estudiantes Juan y Mara) y las segundas
representaciones de colecciones de entidades que comparten unas caracters-
ticas determinadas (el concepto de estudiante, del cual son individuos o ins-
tancias concretas Juan y Mara). La estructura de las clases determina qu
informaciones se pueden representar mediante los objetos que pertenecen a
estas clases.
Los objetos representan entidades independientes especficas de elementos del

mundo real. Por ejemplo, podemos tener un objeto que represente a cada estu-
diante de una universidad y un objeto que represente cada asignatura. Los ob-
jetos almacenan valores propios, que estn asociados ntimamente con el objeto
que los contiene. Por ejemplo, el nombre de un estudiante determinado, Juan
Garca, o su fecha de nacimiento, 17/07/1979, son valores posibles que con-
tendra el objeto que representara a este estudiante, y Programacin orientada
a objetos y 7,5 podran ser los valores almacenados por el objeto que re-
presentara una asignatura, que indicaran su nombre y nmero de crditos,
respectivamente. Los objetos tambin tienen un comportamiento, es decir,
les podemos pedir que realicen tareas. Estas tareas son lo que denominamos
operaciones o mtodos.
Por otra parte, los objetos raramente quedan aislados como entidades inde-
pendientes; al contrario, se suelen relacionar con otros objetos. Una de las re-
laciones ms comunes es el enlace. Un enlace representa una relacin
semntica explcita entre dos o ms objetos que es importante tener en
cuenta. Por ejemplo, si con nuestra aplicacin queremos obtener una lista de
los estudiantes de cada asignatura, es imprescindible almacenar la informa-
cin de qu estudiantes estn matriculados y en qu asignaturas. As, podremos
tener un enlace entre el alumno Juan Garca y la asignatura Programacin
orientada a objetos en la qu est matriculado.
Ahora bien, cuando elaboramos un modelo de un problema utilizando la

orientacin a objetos, no solemos hacer un catlogo de todas las instancias y
enlaces posibles. Hay motivos prcticos inmediatos para no hacerlo, dado que
es posible que, por ejemplo, no sepamos qu estudiantes se matricularn ni a
qu asignaturas o que, simplemente, haya demasiados enlaces para que resulte
prctico representarlos todos. No obstante, el motivo fundamental es que,
cuando hacemos un modelo, raramente nos interesan los objetos concretos,
lo que nos interesa son las caractersticas comunes de los grupos de objetos:
las clases.
As, podemos ver que todos los objetos que representan a estudiantes tienen
como valores el nombre y la fecha de nacimiento (entre otros). Esto nos lleva-
r a definir una clase, Estudiante, que representar el conjunto de todos los
estudiantes de nuestro sistema, es decir, ser una abstraccin de este conjunto.
Los valores comunes pasarn a ser atributos de la clase, con un tipo determi-
nado. Por ejemplo, tendremos un atributo nombre de tipo cadena de caracte-
res y un atributo fechaNacimiento de tipo fecha que formarn la clase
Estudiante. De la misma manera, definiramos una clase Asignatura con
los atributos numero y numeroCreditos. Adems, el conjunto de los enlaces
entre los estudiantes y las asignaturas concretas se abstrae en una relacin de
asociacin entre las clases Estudiante y Asignatura.
El recorrido rpido que acabamos de realizar sobre la manera de estructurar la

informacin es uno de los aspectos clave para trabajar mediante la orientacin
a objetos: aprender a modelar problemas con clases (sin olvidar que stas son
moldes de un conjunto de objetos concretos) y a implementar estos modelos
en lenguajes de programacin orientados a objetos.
En este mdulo profundizaremos en las clases, los objetos y sus relaciones

como abstracciones de problemas y despus revisaremos algunos de los casos
especiales de clases que sirven para modelar casos concretos que ocurren fre-
cuentemente. Con esto, pretendemos que seis capaces de hacer modelos de
complejidad media, expresados en notacin UML (olvidndonos del lenguaje
de programacin), y de juzgar si son adecuados a la informacin que se quiere
representar.
Objetivos
Los materiales didcticos de este mdulo proporcionan los conocimientos

fundamentales para que los estudiantes alcancis los objetivos siguientes:
1. Comprender la abstraccin como mecanismo para tratar la complejidad

inherente al software.
2. Conocer los diferentes tipos de abstraccin que se utilizan en el desarrollo

de software, incluido el paradigma de la orientacin a objetos.
3. Entender las clases como abstracciones de los objetos, y tambin compren-

der y saber determinar las relaciones entre clases y objetos.
4. Entender el proceso de abstraccin de la orientacin a objetos siguiendo

una metodologa sencilla para obtener modelos de clases.
5. Conocer las relaciones fundamentales entre las clases y saberlas identificar:

generalizacin/especializacin, asociacin y dependencia.
6. Conocer algunos tipos especiales de clases: clases abstractas, parametriza-

das y finales.
1. Complejidad y abstraccin
Nuestro punto de partida en este mdulo es el concepto de complejidad aso-

ciada al software y a su desarrollo.
1.1. La complejidad inherente al software
Desde hace dcadas, se considera que la complejidad es una caracterstica in-

herente a la misma estructura del software que se incrementa de manera no
lineal con su volumen.
Esta complejidad hace que sea difcil incluso imposible para un nico
desarrollador comprender todos los detalles de los sistemas, excepto en el caso
de sistemas muy simples y especficos, como los desarrollados para resolver
una necesidad personal o los que cumplen finalidades muy sencillas.
La complejidad del software puede tener su origen en el dominio del problema

G. A. Miller,...
pensemos, por ejemplo, en los requisitos de un sistema de navegacin area,
... entre otros autores, sostiene
en el proceso de desarrollo en sistemas grandes puede haber decenas de desa- que la memoria a corto plazo
(o memoria de trabajo) de una
rrolladores implicados que, adems, pueden estar separados geogrficamente, persona est limitada al
con los problemas de comunicacin y coordinacin que se derivan de esto, y manejo simultneo de siete
(ms/menos dos) unidades
tambin en la variabilidad en los diseos para un mismo sistema, desarrolla- de significacin.
G. A. Miller (1956). The
dores diferentes llegarn a modelos diferentes, aunque las diferencias no sean Magical Number Seven, Plus
esenciales. or Minus Two: Some Limits on
Our Capacity for Processing
Information. Psycological
Review (nm. 63, pgs. 81-97).
Por otra parte, hay tantos posibles estados es decir, las posibles combinacio-
nes de datos, variables de entrada y otras condiciones de funcionamiento de
un fragmento de cdigo de volumen medio que este hecho, en s mismo, ya
es una fuente de complejidad: son demasiados detalles para que una sola per-
sona los pueda comprender sin descomponerlos en partes pequeas. Esto
comporta que sea necesario utilizar modelos de diferente ndole para poder
tratar cada uno de los aspectos especficos del sistema de manera separada.
Adems, esta complejidad suele ser desorganizada o arbitraria, ya que la orga-

nizacin interna del software est, muchas veces, determinada por sus interfa-
ces externas o por las decisiones de diseo coyunturales de sus desarrolladores.
Este tipo de complejidad contrasta con la complejidad organizativa de los sis-
temas fsicos, en los que hay principios generales que gobiernan la estructura-
cin de los sistemas complejos.
Puesto que la complejidad es inherente al software, no podemos hacer que

desaparezca. No obstante, podemos desarrollar tcnicas y herramientas que
nos permitan tratarla y gestionarla. Esto es lo que ha hecho la comunidad de

desarrolladores de software en las ltimas dcadas, lo cual ha dado como re-
sultado, entre otros, el paradigma de la orientacin a objetos.
La abstraccin, que trataremos a continuacin, es un principio fundamental

que aparece en la orientacin a objetos y en otras tcnicas para tratar la com-
plejidad del software.
1.2. La abstraccin en el desarrollo de software
La abstraccin es un mecanismo de la inteligencia humana que nos

permite comprender y tratar situaciones complejas.
En todo proceso de abstraccin, siempre hay una parte de la situacin o del

problema que se destaca y otra parte que se ignora o se deja de lado, al menos
momentneamente.
Una de las caractersticas de la abstraccin es su jerarquizacin, de manera que

para una misma situacin o problema se puede hablar de diferentes niveles de
abstraccin, es decir, de diferentes niveles de detalle.
Trasladado al caso, por ejemplo, de una ciudad, podemos observar su plano

general, en el que las entidades inferiores a calles, plazas o islas de edificios no
se consideran. En un nivel inferior, ampliando un bloque determinado, po-
dramos trabajar ms detalladamente y llegar a considerar, incluso, la estruc-
tura interna de las islas de edificios.
Tambin puede haber diferentes abstracciones porque a la hora de construir-

los necesitamos fijarnos en determinados aspectos de la situacin. Por ejem-
plo, para describir un piso que se tiene que construir, podemos tener un plano
de las conducciones de agua o del circuito elctrico.
Otro ejemplo muy claro de abstraccin es la que se puede producir cuando

estudiamos al ser humano. Este estudio se puede hacer en diferentes mbi-
tos: podemos estudiar a los individuos desde el punto de vista de su compo-
sicin, como hacen la qumica y la biologa. Los podemos estudiar desde un
punto de vista mdico, atendiendo a las funciones vitales que desempean
sus rganos. Sin embargo, tambin es posible estudiar la sociologa de las
personas utilizando un nivel de abstraccin todava mayor; para esto, nos fi-
jaramos exclusivamente en su comportamiento social y en sus relaciones in-
terpersonales.
A medida que se ha intentado controlar la complejidad del software, el desa-

rrollo de aplicaciones ha pasado por diferentes fases, en las que han aparecido
distintos tipos de abstracciones en los programas. Algunas de las ms relevan-

tes son las siguientes:
La primera abstraccin se produjo con la llegada del lenguaje ensambla-

dor, que permita al programador abstraerse de los cdigos de operacin de
las instrucciones de mquina del procesador. Aunque el paso se puede con-
siderar pequeo, ya que es una simple traduccin de cdigos binarios a
mnemotcnicos y los programas continuaban dependiendo de la arqui-
tectura de la mquina concreta, represent una mejora considerable des-
de el punto de vista de la facilidad de programacin.
Otro hito importante fue la aparicin de los lenguajes de programacin

de alto nivel, que permiti a los programadores abstraerse de la arquitec-
tura de la mquina, de manera que los programas fuente se podan inde-
pendizar de la mquina en la que se ejecutaban.
Ms tarde, en la dcada de los cincuenta, apareci la abstraccin funcio-

nal (o procedimental) dentro de los lenguajes de alto nivel, que se basa en
la idea de definir subprogramas (procedimientos o funciones) que toman
unos parmetros de entrada y devuelven valores en unos parmetros de sa-
lida. As, los subprogramas son cajas negras que nos abstraen de los detalles
del algoritmo que contienen, ya que nosotros slo trabajamos con entradas
y salidas. Esto permite desarrollar bibliotecas de subprogramas (por ejem-
plo, una biblioteca para el clculo matemtico), que representan un paso
importante en cuanto a la reutilizacin de cdigo.
La aparicin del concepto de tipo abstracto de datos, con el cual se pue-

den utilizar datos definidos por el programador, permite pasar de la abs-
traccin basada en la funcin a la abstraccin centrada en los datos.
La abstraccin basada en los datos evoluciona y da lugar a lo que hoy deno-

minamos orientacin a objetos. La importancia de esta evolucin reside, ms
que en el nivel tcnico de los compiladores, en la manera de obtener las abs-
tracciones, que son un reflejo de las entidades del dominio de la aplicacin
que se construye.
En la actualidad, y vistas las ventajas del enfoque estudiadas previamente, se

Lectura complementaria
utiliza de manera mayoritaria el paradigma de la orientacin a objetos en los
Podis encontrar informa-
proyectos de desarrollo nuevo (aunque el mantenimiento de aplicaciones an- cin sobre la programacin
orientada a aspectos en la
tiguas hace que todava se dediquen muchos recursos a aplicaciones desarro-
Wikipedia:
lladas con enfoques anteriores). Aunque todava no estn consolidadas, http://www.wikipedia.org
tambin se han empezado a investigar posibles evoluciones de la orientacin
a objetos, de entre las cuales se puede destacar, a corte meramente ilustrativo,
la orientacin a los aspectos.
2. Los principios de la clasificacin
En este apartado, nos detendremos en los conceptos clave de clase, objeto y su

estructuracin, y enfatizaremos el hecho de que las clases son representacio-
nes de informacin que tienen un significado preciso.
2.1. Modelar pensando en los objetos
Cuando tenemos que tratar el dominio de un problema, encontramos

que el sistema de software proyectado tendr que representar una serie
de objetos de este dominio. Dependiendo de los requisitos del sistema
que se est construyendo, se pueden hacer diferentes abstracciones de
objetos a partir de un mismo dominio.
Pensemos, por ejemplo, en una aplicacin de gestin de stocks en una fbrica

En un diagrama de clases, pueden
de motores. La fbrica produce diferentes tipos de motores, por ejemplo, TDI aparecer objetos como ejemplos
concretos de aquello que
representan las clases.
1.9 y TDI 2.0. Puesto que la finalidad que se persigue es tener un control
del inventario de estos motores, podramos pensar en representar cada tipo
de motor con un objeto, de manera que podamos saber la cantidad de motores
que hay de cada tipo. As, podramos tener los objetos o1 y o2, como se mues-
tra en el diagrama siguiente, que tienen como valores el nombre del motor
(name), su potencia (power) y la cantidad de motores de este tipo que tenemos
en stock (quantity). Estos objetos pertenecen a una clase, Motor (Engine),
que tambin aparece en el diagrama:
Figura 1. Representacin de objetos y clases
El diagrama representa los objetos o1 y o2 como instancias de la clase Motor,

con valores concretos para cada uno de sus atributos (en el diagrama, para sim-
plificar, hemos omitido los mtodos).
El modelo que tenemos hasta ahora sirve para representar la informacin que
necesitamos, aunque plantea un par de inconvenientes:
La clase Engine representa realmente el concepto de tipo de motores, por

lo cual su nombre puede llevar a interpretaciones incorrectas; sera conve-
niente denominarla EngineType.
En los valores de las instancias, vemos que se mezclan dos informaciones

de naturaleza distinta: caractersticas del tipo de motor e informacin de
inventario. No hemos separado bien los dos elementos, de manera que la
clase Engine, tal y como la hemos definido, no se puede utilizar en otros
contextos. Para comprobarlo, supongamos, por ejemplo, que el sistema re-
quiere gestionar diferentes almacenes, por lo cual necesita guardar diferen-
tes cantidades de cada producto. Esto nos obligara a eliminar el atributo
quantity y a ubicarlo en alguna otra clase, ya que el objeto que represen-
ta el motor TDI 1.9 ser nico en el sistema.
Supongamos ahora que, adems de conocer el stock, queremos hacer un segui-

miento individual de cada motor que se fabrica, de manera que se debe in-
cluir el nmero de serie de cada motor individual (serialNumber) y el ao de
fabricacin (buildYear). En este caso, tendramos que representar con un ob-
jeto cada motor, como mostramos a continuacin:
Figura 2. Representacin de objetos y clases
En esta segunda versin, el stock de los motores es el recuento de los objetos

Engine que hay en el sistema. En este caso, Engine es un nombre apropiado
para la clase, pero hay otro inconveniente: este modelo genera una gran can-
tidad de datos redundantes, ya que los datos de cada tipo de motor (nombre
y potencia) se repiten en cada instancia. Para resolver este problema, lo que
deberamos hacer es introducir un nuevo tipo de clase que nos indique el tipo
de motor y que los objetos de la clase Engine se relacionen con stos, segn
el tipo; de esta manera, evitaramos las redundancias.
Podis ver el resultado en el diagrama siguiente:
Figura 3. Relacin entre instancias de las clases Warehouse (Almacen), Engine (Motor) y MotorType (TipoMotor)
Cada objeto de la clase Engine (Motor) se tiene que enlazar con el objeto
que representa el tipo de motor, EngineType (TipoMotor). De la misma ma-
nera, stos se tienen que enlazar con los objetos de tipo Warehouse (Almacen)
donde estn almacenados.
Con este ejemplo, hemos intentado ilustrar cmo modelos diferentes permiten Las asociaciones entre clases las
veremos ms detalladamente en los
representar distintas informaciones con diferentes grados de detalle. Por este apartados siguientes de este mdulo
didctico.
motivo, hemos partido de los objetos para obtener, a partir de ejemplos

concretos, las clases. Aunque normalmente no se procede de esta manera,
conviene que la tengis presente, ya que permite ver claramente qu se puede
representar con las clases resultantes.
Las clases determinan la estructura y la informacin que pueden guar-

dar los objetos. Es importante comprobar que los modelos realmente
pueden representar la informacin que se requiere y que no contienen
redundancias. Los enlaces son tambin informacin almacenada que,
en ocasiones, permite eliminar redundancias.
Cada uno de los objetos de un modelo o sistema determinados es una entidad

con identidad propia, es decir, es distinguible de cualquier otro objeto por el
mero hecho de existir. Por lo tanto, no es imprescindible que todos los objetos
tengan un atributo que los diferencie de los otros objetos similares (es decir,
no es estrictamente necesario que haya un campo clave, aunque en muchos
casos est).
Ejemplo
Supongamos que se est modelando una herramienta de dibujo asistido por ordenador que
permite dibujar diferentes figuras geomtricas. Algunas de las clases que se tendrn que im-
plementar sern las correspondientes a cada una de las figuras geomtricas que se pueden
trazar: crculo, rectngulo, etc. Cada una de las figuras trazadas ser, por lo tanto, un objeto
de la clase correspondiente.
Imaginemos que hemos pintado un crculo (objeto c1), cuyo centro se encuentra en la
posicin (40, 30), tiene un radio de 5 mm, es de trazo continuo y es de color rojo. A con-
tinuacin, trazamos otro crculo con las mismas caractersticas (objeto c2), posicin, ra-
dio, etc., de manera que los dos objetos quedan superpuestos. Obviamente los dos
crculos son diferentes (c1 y c2), aunque sus atributos tienen todos los mismos valores.
Aunque usar campos clave es comn en determinados casos, como en las ba-
ses de datos relacionales, en la orientacin a objetos esto no es necesario, ya
que las relaciones entre los objetos se representan explcitamente con los en-
laces.
En el ejemplo anterior del almacn, una representacin alternativa a la versin definitiva

habra sido poner un atributo nombreTipoMotor en la clase Motor y eliminar la asocia-
cin entre Motor y TipoMotor -y por lo tanto, indicar que no hay enlaces entre sus ob-
jetos. As, para obtener la potencia de un motor con el atributo nombreTipoMotor de un
valor determinado, habra que buscar entre todos los objetos de la clase Motor los que con-
tienen el valor buscado y se tendra que retornar el valor de la potencia de ste. Este enfo-
que es ms ineficiente porque no sigue los principios de estructuracin de la orientacin a
objetos, segn los cuales las relaciones son explcitas, en forma de enlaces, y no implcitas,
en forma de claves que identifican otros elementos.
Los objetos tienen identidad propia, al margen de cualquiera de sus atribu-

tos. Por este motivo, las relaciones entre objetos se guardan como enlaces, y
no se deben utilizar campos clave para representar relaciones de manera im-
plcita.
Como hemos visto, los objetos pertenecen a una clase determinada. En reali-
Java slo permite..
dad, conceptualmente, un objeto puede pertenecer a ms de una clase, todo
... que un objeto pertenezca a
depender de si el lenguaje de programacin que utilizamos tiene ms o me- una clase; en cambio, C++
permite que un objeto
nos limitaciones en este aspecto. De todos modos, trabajaremos con la premi- pertenezca a tantas clases
sa de que cada objeto slo pertenece a una clase. como sea necesario.
2.2. Modelar pensando en las clases
Prcticamente en todos los casos, se empieza a modelar directamente median-

te diagramas de clases. No obstante, el nivel de los objetos es importante, ya
que permite representar casos concretos que se pueden dar a partir de un
diagrama de clases, de manera que sirve para verificar que el modelo puede re-
presentar toda la informacin necesaria.
Para modelar nuestros problemas, utilizaremos un lenguaje de modelado de- Si queris saber ms sobre el UML,
podis visitar
http://www.uml.org
nominado UML (lenguaje de modelado unificado o Unified Modeling Language).
Este lenguaje nos sirve para representar diagramas de clases de una manera clara
que nos facilite su comprensin.
Los diagramas de clases son aqullos en los que estn todas las clases Hay otros lenguajes de
modelizacin, pero vista su claridad
y sencillez es el que utilizaremos en estos
del problema que queremos modelar (tambin se pueden hacer mdulos.
diagramas de clases de partes del modelo), y tambin las relaciones

entre stas. Como vemos en este mdulo, los diagramas de clases
pueden ser muy complejos y pueden contener mucha informacin,
pero al mismo tiempo son mucho ms claros que los diagramas de
objetos, ya que nos permiten representar conceptos con muy pocos
elementos visuales.
A partir del ejemplo anterior de los motores, podemos extraer del diagrama de
objetos el diagrama de clases siguiente:
Figura 4. Primer diagrama de clases
Lo que vemos en este diagrama es lo que ya hemos comentado anteriormente:

los objetos de tipo Warehouse (Almacen) estn relacionados con objetos de
tipo Engine (Motor), y estos ltimos estn relacionados al mismo tiempo con
objetos de tipo EngineType (TipoMotor).
El modelado con diagramas de clases no es simplemente una conceptualiza-

cin aproximada, sino un esquema preciso de la estructura de objetos, atribu-
tos y relaciones imprescindible para poder representar una informacin
determinada. Aunque para unos mismos requisitos se pueden dar diagramas
de clases con diferencias leves, si hacemos un diagrama de objetos sobre stos
podremos identificar cules son apropiados y cules no.
Los diagramas de objetos son tiles para comprobar si un diagrama de clases El diagrama de objetos
correspondiente a este modelo lo
permite representar una informacin determinada creando ejemplos de posi- tenis en el apartado anterior.
bles sistemas que estn basados en ste.
2.3. Identificacin de las operaciones
En los ejemplos que hemos visto hasta ahora, no nos hemos centrado en iden-
tificar las operaciones de las clases (que al mismo tiempo son operaciones que
se invocarn sobre objetos concretos). Normalmente, identificar las operacio-

nes es un paso que se realiza despus de obtener la estructura de clases y rela-
ciones. stas pueden hacer variar ligeramente la estructura del modelo de
clases, pero si el diseo es bueno, ste seguramente no cambiar.
Tpicamente, las clases tienen dos tipos de operaciones:
Operaciones pblicas, que conforman la interfaz de la clase (y de sus obje-

tos, en consecuencia).
Operaciones privadas, que slo se utilizan desde dentro de la clase, y no

pueden ser invocadas por objetos de las otras clases.
Cuando se conceptualiza un problema, slo se tienen en cuenta las opera-

ciones pblicas y, entre stas, slo interesa capturar las ms significativas.
No es necesario representar las operaciones de acceso y modificacin de los
atributos o las asociaciones, a menos que presenten alguna peculiaridad, ya
que se consideran muy seguras e incluirlas en el diagrama dificultara la
lectura y no aportara ninguna informacin significativa.
Hay que empezar a definir las operaciones privadas cuando, al avanzar en el

Recordad
diseo, se tenga que empezar a pensar en un lenguaje de programacin con-
El diseo descendente divide el
creto. En este momento, se descubrir que algunas de las operaciones defini- problema inicial en subproble-
das son muy complejas y que es necesario aplicar los principios de diseo mas que resuelve de manera
independiente. Estos subpro-
descendente. blemas, si continan siendo
demasiado complejos, se des-
componen sucesivamente has-
ta tener problemas que se
Este proceso de descomponer operaciones en otras menores contina vigente puedan resolver de manera
en la orientacin a objetos, aunque se lleve a cabo sobre las clases individuales sencilla.
y como actividad secundaria de la actividad principal de conceptualizacin

del dominio.
3. Relaciones entre clases
La clase est concebida como la estructura de representacin en la que se basa

la descomposicin modular que caracteriza la metodologa de orientacin a
objetos. Obviamente, una clase no permite describir un problema global de
manera independiente, sino que tendr que colaborar con las otras clases para
poder solucionarlo. Un aspecto muy importante de este proceso es definir las
relaciones que se tienen que establecer entre las clases para poder representar
la realidad definida por el problema que se debe resolver.
Las relaciones entre clases tambin

El conjunto formado por las clases y sus relaciones define el modelo con se denominan asociaciones.
el que se representa la realidad en el contexto del problema que se tiene

que tratar. Este diagrama se denomina diagrama de clases.
3.1. Propiedades de las asociaciones
Las asociaciones binarias son aquellas que representan la relacin que

hay entre dos clases de nuestro modelo.
Esta asociacin puede representar cualquier relacin entre clases (tambin se

pueden dar relaciones entre instancias de la misma clase, como veremos ms
adelante). Como hemos comentado anteriormente, para representar las aso-
ciaciones en los diagramas, uniremos las dos clases con una lnea continua.
Figura 5. Relacin entre clases
Como veremos a continuacin, podemos aadir ciertos modificadores a la l-

nea para dotar la asociacin de significados diferentes.
3.1.1. Cardinalidad
Dado que una asociacin binaria representa una interconexin entre instan-
cias de dos clases, hay que indicar cuntos objetos de cada clase pueden estar
involucrados en esta interconexin. En otras palabras, es necesario indicar la
cardinalidad (o multiplicidad) de la asociacin. Podemos indicar el valor

mximo y mnimo de esta cardinalidad mediante modificadores.
Los modificadores se ponen encima o debajo de la lnea que representa la aso-

ciacin y, dependiendo de los valores, tienen un significado u otro.
Figura 6. Cardinalidad de las relaciones
Podemos expresar la cardinalidad mediante diferentes notaciones:
Nmero exacto (1, 3, etc.). Expresa que una instancia de la clase ClassA * Por ejemplo, una persona tiene
nicamente un pas de origen; un
tiene que estar relacionada exactamente con el nmero indicado de instan- segmento tiene nicamente dos
puntos asociados (el de origen y el
cias de la clase ClassB.* de destino), etc.
Rango de valores (0..1, 3..5, etc.). Con esta notacin, indicamos el n-

** Por ejemplo, una persona siempre
tiene dos progenitores (2); o de 0 a
mero mnimo y mximo de instancias de la clase ClassB con las que tiene 2 (0..2), si slo se contemplan los
vivos; un empleado tiene un jefe o
que estar relacionada una instancia de la clase ClassA.** no lo tiene (0..1), etc.
Muchos (*). Con el asterisco, indicamos que la instancia de la clase ClassA

puede estar relacionada con cualquier nmero de instancias de la clase *** Por ejemplo, una persona puede
no tener coche, o tener uno o ms
ClassB (o incluso con ninguna) y no conocemos su nmero.*** Equivale a de uno; un alumno de la UOC
puede estar matriculado en una,
escribir 0..*. muchas o ninguna asignatura (si
aquel semestre no se matricula),
etc.
Combinaciones de las anteriores. Si queremos expresar ciertos rangos no
consecutivos****, debemos utilizar la coma para separar los rangos. **** Por ejemplo, un camin tiene 4,
6, 8, 10 o 12 ruedas; etc.
Una vez definidas las cardinalidades de las dos clases implicadas en la asociacin,
aparecen infinidad de combinaciones posibles, pero las ms comunes son:
Cardinalidad uno a uno. Una instancia de la clase ClassA se relaciona

con una nica instancia de la clase ClassB, y cada instancia de la clase
ClassB se relaciona con una nica instancia de la clase ClassA.
Representacin
de las instacias
En este diagrama y en los si-

guientes, las instancias de la
clase ClassA se representan
con crculos y las instancias de
la clase ClassB, con rombos.
Figura 7. Representacin de una asociacin 1:1

Cardinalidad uno a muchos. Una instancia de la clase ClassA se relacio-

na con cualquier nmero (de 0 a muchas) de instancias de la clase ClassB,
y cada instancia de la clase ClassB se relaciona con una nica instancia de
la clase ClassA.
Figura 8. Representacin de una asociacin 1:N
Cardinalidad muchos a muchos. Una instancia de la clase ClassA se re-

laciona con varias instancias de la clase ClassB, y cada instancia de la cla-
se ClassB se puede relacionar con cualquier nmero de instancias de la
clase ClassA.
Figura 9. Representacin de una asociacin M:N
Si recuperamos el ejemplo anterior (el de los motores, almacenes y tipos de

motor) y aadimos la cardinalidad a las asociaciones que aparecen, obtendre-
mos el siguiente diagrama de clases :
Figura 10. Diagrama de clases
Como podemos ver, este diagrama representa el que antes hemos dibujado
con objetos y hemos empezado a introducir con el diagrama de clases incom-
pleto.
3.1.2. Navegabilidad
Otra caracterstica que podemos expresar en una relacin dentro de un diagrama

UML es su direccionalidad; es decir, cul de las dos clases (clase ClassA o clase
ClassB) conoce la otra.
Las nicas dos opciones posibles son las siguientes.
Unidireccional: slo una de las dos clases tiene constancia de la existencia

Unidireccionalidad
de la otra.
Se da, por ejemplo, cuando en
un diagrama queremos repre-
sentar que una persona vive en
un pas pero no nos hace falta
tener almacenadas qu perso-
nas viven en el pas.
Figura 11. Representacin de una asociacin unidireccional
Bidireccional: las dos clases tienen constancia de la existencia de la otra

clase. Bidireccionalidad
Por ejemplo, para representar la

relacin entre Student y
Subject, nos interesa cono-
cer, de cada asignatura, la lista
de estudiantes matriculados, y
de cada estudiante, la lista de
asignaturas.
Figura 12. Representacin de una asociacin bidireccional
Como podis ver, para expresar la direccionalidad unilateral se utiliza una l-

nea con una punta de flecha que indica qu clase es la que tiene constancia de
la existencia de la otra; en cambio, para las bidireccionales se utiliza una lnea
sin puntas de flecha.
En la mayora de las relaciones utilizaremos asociaciones bidireccionales, Hay que tener en cuenta...
pero hay que tener en cuenta que tambin podemos utilizar las unidireccio- ... que en algunos manuales de
UML podis encontrar que las
nales si nos conviene. La direccionalidad de las asociaciones est determinada asociaciones bidireccionales se
principalmente por las funcionalidades que unas clases necesitan de las otras, representan con un segmento
con los dos extremos en forma
es decir, si una instancia de la clase ClassA necesita poder invocar mtodos de punta de flecha. Son repre-
sentaciones equivalentes.
de una instancia de la clase ClassB, aparte de existir una asociacin entre las
mismas, implica que la asociacin tiene que permitir la navegabilidad entre la

clase ClassA y la clase ClassB.
3.1.3. Roles
Hasta ahora, hemos visto modificadores que definan el comportamiento de

Los roles, si no son necesarios, no
hay que indicarlos en el diagrama.
las asociaciones respecto del modelo. Los roles en las asociaciones no modifi-
can el comportamiento de las clases relacionadas, sino que nos ofrecen la po-
sibilidad de llamar a los integrantes de la relacin de una manera diferente del
nombre de la clase.
Figura 13. Representacin de los roles en una asociacin
Esta caracterstica se utiliza muy frecuentemente para denominar los extremos

de las asociaciones reflexivas.
3.2. Tipos de asociaciones
3.2.1. Asociaciones reflexivas

Asociaciones reflexivas
Las asociaciones reflexivas son un tipo de asociacin binaria en la que las dos Como ejemplo tpico de aso-
ciaciones reflexivas, podemos
clases, origen y destino de la relacin, son la misma clase. No hay ninguna res- hablar de la relacin entre su-
bordinado (Employee) y jefe
triccin que impida que una instancia de una clase se relacione con otras ins- (Boss) dentro de una empre-
sa. Todas las personas son em-
tancias de la misma clase. pleados de la empresa, y entre
ellas se establece una relacin
en la que cada persona tiene
Se representan con una relacin que entra y sale de la misma clase y, como un jefe (a excepcin del jefe de
la empresa, que no tiene a na-
hemos comentado antes, para poder identificar correctamente los roles de los die por encima) y cada jefe tie-
ne un nmero indeterminado
dos extremos de la asociacin, hay que definirlos con un texto lo bastante de subordinados.
aclaratorio.
Figura 14. Representacin de una asociacin reflexiva
Un buen ejercicio es crear el diagrama de objetos resultante de la asociacin

reflexiva que acabamos de crear; por ejemplo, podramos tener un diagrama
parecido a ste:
Figura 15. Diagrama de objetos de una asociacin reflexiva
En el ejemplo anterior, la estructura resultante ha sido un rbol por las restric-

Un grafo es...
ciones de cardinalidad que habamos dado a la asociacin reflexiva. En otros
... una estructura formada por
casos, dependiendo de la cardinalidad, se pueden dar otras estructuras: por nodos que se interconectan
entre ellos. Hay grafos dirigi-
ejemplo, si queremos representar el hecho de ser conocido de entre objetos dos y no dirigidos (simtricos),
dependiendo de la direcciona-
de la clase Person, tendremos que una persona puede conocer a mucha gente lidad de sus aristas (relaciones
y al mismo tiempo ser conocida por mucha gente; por lo tanto, la estructura entre nodos).
resultante ser un grafo.
3.2.2. Asociaciones de agregacin
En las asociaciones binarias, se asume que las instancias de las dos clases son
independientes, en el sentido de que las instancias de una clase no dependen
de la existencia de las de la otra.
Agregaciones
En la asociacin de agregacin, se asume una subordinacin concep-
tual del tipo todo/parte o bien tiene-un. Por lo tanto, hay que tra- Podemos considerar que una
clase est formada por alum-
tarlas como un caso especial de asociacin binaria. nos, lo cual no implica que
cuando la clase se disuelva, al
final del semestre, los estudian-
tes tengan que desaparecer.
En UML, las agregaciones se representan con un rombo en la parte del ob-

jeto agregado (lo que representa el todo) para expresar grficamente esta si-
tuacin.
Figura 16. Asociacin de agregacin

3.2.3. Asociaciones de composicin

Asociaciones
de composiciones
De la misma manera que sucede con las asociaciones de agregacin, las aso- Un libro est formado por p-
ginas, que nos puede interesar
ciaciones de composicin son un caso especial de asociaciones binarias. De almacenar si estn en blanco, si
son de inicio de captulo, si tie-
manera ms concreta, se trata de un caso especial de agregacin en el que se
nen grficos, si tienen imge-
requiere que una instancia de la clase que representa las partes est asociada, nes, etc. Estas pginas son de
este libro y no tiene sentido
como mximo, con una de las instancias que representan el todo (no puede que existan en ningn otro li-
bro. Por lo tanto, si se diera el
haber cardinalidad mltiple en el extremo del agregado). caso de que desapareciera el li-
bro, las pginas tambin ten-
dran que desaparecer.
En UML, las composiciones se representan con un rombo con el interior relle-
no en la clase que representa el todo.
Figura 17. Asociacin de composicin
3.3. El concepto de clase asociativa
Hasta ahora, hemos utilizado las asociaciones entre clases para expresar una
cierta relacin entre instancias de las clases relacionadas.
Lo que puede suceder es que queramos almacenar cierta informacin en lo

referente a esta relacin. Por este motivo, aparecen las clases asociativas.
Las clases asociativas tambin

Una clase asociativa es aquella clase que est asociada a una relacin y se pueden utilizar en asociaciones
n-arias.
nos permite almacenar datos sobre esta relacin.
En UML, utilizaremos una lnea discontinua que unir la clase asociativa con
la relacin a la cual est asociada.
Clases asociativas
En el diagrama se representa
que una OrderLine
(LineaDePedido) almacena
la cantidad de elementos de
tipo Product (Producto) que
contiene el Order (Pedido).
Figura 18. Clase asociativa

3.4. Relacin de generalizacin/especializacin
Despus de la asociacin binaria, una de las relaciones entre clases ms

importantes en la programacin orientada a objetos es la relacin de
generalizacin/especificacin. En este apartado slo introduciremos el concepto,
ya que en mdulos posteriores profundizaremos ms en las posibilidades que
ofrece para realizar aplicaciones ms complejas.
Ejemplos de este tipo

Como primera definicin, podramos decir que la relacin de genera- de relacin podran ser...
lizacin es una relacin entre dos clases en la que una clase (la clase pa-
... el coche especializa el com-
dre) generaliza el comportamiento de la otra clase (la clase hija). O portamiento de un vehculo;
un vehculo generaliza el com-
dicho de otra manera, la clase hija especializa el comportamiento de la portamiento de un coche, una
motocicleta o un camin.
clase padre.
En UML, esta relacin se representa con un tringulo en la clase ms general.
Relacin de generalizacin/
especializacin
En este diagrama, indicamos

que la clase Car es un subtipo
de la clase Vehicle; por lo
tanto, la clase Car mantiene
todos los atributos y funciona-
lidades del vehculo (por ejem-
plo, el nmero de ruedas) y le
aade alguna ms (en este
diagrama, aade el nmero de
puertas).
Figura 19. Relacin de generalizacin/

especializacin
Este tipo de relacin es un caso especial, dado que no se expresa su cardinali-

dad. Esto es porque no indicamos una relacin entre instancias, sino que re-
flejamos que una clase contiene e incrementa las propiedades de otra.
Las relaciones de generalizacin/especializacin nos permiten llevar a cabo el

mecanismo de herencia. La herencia nos facilita reutilizar el cdigo y es una Ved las reglas de calidad
mencionadas en el mdulo Clases
de las principales reglas de calidad que ya conocemos. y objetos de esta asignatura.
4. Tcnica simple para identificar clases
Para obtener la estructura de clases de un enunciado, o de un dominio en gene-

ral, se tienen que aplicar las capacidades de abstraccin y conceptualizacin y
se deben utilizar como herramienta los conceptos de la orientacin a objetos.
Hay muchos libros que proponen tcnicas para extraer clases que, aunque no
son infalibles, son un buen punto de partida cuando no se tiene demasiada ex-
periencia en el modelado de objetos. La que nosotros recomendamos es un ex-
tracto y una adaptacin de distintas tcnicas.
Hay que comentar que esta tcnica slo ser vlida en problemas pequeos y,
en nuestro caso, en el aprendizaje de la orientacin a objetos.
4.1. Descripcin de la tcnica
Para identificar las clases, os proponemos los pasos siguientes:
1) Enumerar las clases candidatas, todas las que aparezcan o se puedan dedu-
cir de la descripcin del problema. Las clases suelen aparecer como sustantivos
o frases nominales, por lo cual es til y recomendable subrayarlas en el texto.
2) Eliminar de la lista las clases incorrectas utilizando los criterios siguientes:
Clases redundantes (sinnimas).
Clases irrelevantes (que tengan poco que ver o nada con el problema).
Clases vagas (que no sean bastantes especficas).
Atributos (trminos que son informaciones de las otras clases y no entida-

des independientes).
Operaciones (nombres que describan operaciones aplicables a los objetos).
Roles, a excepcin de aquellos que impliquen atributos, operaciones o re-

laciones que los hagan distinguibles de los otros roles y no de la entidad
que lo posee en un momento determinado.
Estructuras o conceptos de la implementacin que no sean propios del do-

minio del problema.
3) Revisar la lista de clases resultante para aadir los atributos, operaciones y

relaciones entre clases que aparezcan en el problema.
4.2. Ejemplo prctico
A continuacin, plantearemos un ejemplo muy sencillo para ver el funciona-

miento de la tcnica propuesta. Slo identificaremos las clases del modelo, y
dejaremos de lado la identificacin de los atributos, operaciones y relaciones
entre clases.
La UOC quiere automatizar su departamento de envos y para esto nos ha pedido que
diseemos una aplicacin a partir de los requisitos siguientes:
Hay tres tipos de envos: envos normales, envos especiales y envos urgentes.
El sistema conoce las diferentes asignaturas que se imparten en la actualidad en la

UOC; para cada asignatura, se pueden dar de alta nuevos materiales asociados (libros,
vdeos, CD, etc.) o se pueden dar de baja materiales antiguos.
Al principio del curso, el sistema decide de manera automtica el contenido del envo
destinado a cada estudiante, ya que sabe las asignaturas de las que se ha matriculado
y los materiales que estn asociados a las mismas.
El sistema gestiona los envos a los consultores de las asignaturas y detecta que cierta
persona es consultora de ms de una asignatura, caso en el que le remite todos los ma-
teriales en un nico envo.
El sistema controla el caso de los consultores que son estudiantes de otras asignaturas
de la UOC para enviarles todo el material en un nico envo.
En todo momento, el receptor futuro del envo puede conectarse al campus e, intro-
duciendo su nombre de usuario, conocer el estado del envo (todava por empaquetar,
empaquetado o enviado por correo).
A partir de este texto, seguiremos los pasos para identificar correctamente las
clases que modelarn nuestro problema.
1) Enumerar las clases candidatas
La UOC quiere automatizar su departamento de envos y para esto nos ha pedido que
diseemos una aplicacin a partir de los requisitos siguientes:
Hay tres tipos de envos: envos normales, envos especiales y envos urgentes.
El sistema conoce las diferentes asignaturas que se imparten en la actualidad en la

UOC; para cada asignatura, se pueden dar de alta nuevos materiales asociados (li-
bros, vdeos, CD, etc.) o se pueden dar de baja materiales antiguos.
Al principio del curso, el sistema decide, de manera automtica, el contenido del en-
vo destinado a cada estudiante, ya que sabe las asignaturas de las cuales se ha matri-
culado el alumno y los materiales que estn asociados a las mismas.
El sistema gestiona los envos a los consultores de las asignaturas y detecta que cierta
persona es consultora de ms de una asignatura, caso en el que le remite todos los ma-
teriales en un nico envo.
El sistema controla el caso de los consultores que son estudiantes de otras asignaturas
de la UOC para enviarles todo el material en un nico envo.
En todo momento, el receptor futuro del envo puede conectarse al campus e, intro-
duciendo su nombre de usuario, conocer el estado del envo (todava por empaque-
tar, empaquetado o enviado por correo).
Una vez enumeradas, confeccionamos una lista con las posibles candidatas:
UOC
Departamento de envos
Aplicacin
Envo
Envos normales
Envos especiales
Envos urgentes
Sistema
Asignaturas
Materiales asociados
Libros
Vdeos
CD
Materiales antiguos
Curso
Estudiante
Alumno
Consultores
Persona
Campus
Nombre de usuario
Envo por empaquetar
Envo empaquetado
Envo enviado por correo
2) Eliminacin de clases incorrectas
Clases redundantes: alumno es sinnimo de estudiante en este contexto.

Clases irrelevantes: UOC (este trmino se refiere a la institucin, pero no contiene in-
formacin relevante para el problema). Se puede decir lo mismo de campus.
Clases vagas: departamento de envos y sistema. No queda claro qu papel cumplen
dentro de nuestro modelo.
Atributos: segn el enunciado, las entidades siguientes representan estados de los obje-
tos de la clase Envio (EnvioPorEmpaquetar, EnvioEmpaquetado, EnvioEnviado).
Tambin se puede considerar que las clases EnvioNormal, EnvioUrgente y EnvioEs-
pecial se pueden modelizar con un atributo de la clase Enviada. La otra opcin sera
considerarlas especializaciones de la clase Enviada, pero segn el enunciado no aaden
informacin, sino que son sus tipos.
Se podra aplicar el mismo razonamiento al material asociado y a los materiales anti-
guos, y a libro, vdeo, etc. En este ltimo caso, sin embargo, es razonable pensar que
se querrn almacenar atributos para cada tipo (por ejemplo, el nmero de pginas de
los libros o la duracin o formato de los vdeos). Por otra parte, nombreDeUsuario es
claramente un atributo, de Persona.
Roles: consultor y estudiante son roles de persona, en las diferentes relaciones con las
asignaturas. No obstante, es muy posible que aparezcan datos especficos de estos roles
que se tengan que guardar (por ejemplo, los datos de matrcula del estudiante o las au-
las asociadas del consultor), por lo cual de momento los dejamos como clases.
Estructuras o conceptos de la implementacin: aplicacin, base de datos interna,
objeto.
3) Lista definitiva de las clases
Una vez realizados los comentarios anteriores, la lista de clases queda de la manera siguiente:
Envo
Asignatura
Material
Libro
Vdeo
CD
Curso
Estudiante
Consultor
Persona
Ahora slo faltara realizar el diagrama de las clases resultantes, poniendo los atributos
de cada clase y marcando las relaciones entre las mismas.
5. Tipos de clases
Hasta ahora, hemos tratado las clases como tipos de objetos que podemos ins-
tanciar en un programa. Sin embargo, para profundizar un poco ms en su co-
nocimiento es necesario ver que hay algunos tipos de clases ligeramente
diferentes de las vistas hasta el momento, y que tienen usos distintos en el di-
seo de aplicaciones.
A continuacin, veremos algunos de los casos ms importantes:
Las clases abstractas

Las clases parametrizadas
Las clases finales
5.1. Clases abstractas
Desde el punto de vista conceptual, una clase abstracta es nicamente

una clase de la cual no se pueden crear instancias. No tiene ningn sen-
tido crearlas.
Aunque puede parecer contradictorio, el hecho de tener definida en el diagra-

Las clases abstractas van vinculadas
ma de nuestra aplicacin una clase de la que no se pueden crear instancias, a las relaciones de generalizacin/
especializacin.
puede resultar muy til en determinadas situaciones. Las clases abstractas nos
permiten de una manera clara clasificar y crear subconjuntos de clases que
comparten unas caractersticas comunes.
Veamos un ejemplo que nos puede servir para ilustrar su utilidad:
En la clasificacin animal, hay conceptos como animal mamfero (mammal), bpedo,

cuadrpedo, etc. De estos conjuntos no hay instancias concretas, ya que, por ejemplo, la
ballena es un mamfero, pero de la subespecie de los cetceos, o el caballo es un cuadr-
pedo de la subespecie de los equinos; sin embargo, la clasificacin hecha con las clases
anteriores nos permite agrupar las clases de una manera ms intuitiva. Lo que no hay son
animales que simplemente sean mamferos y punto. Mamfero es un concepto abstracto,
no especfico. Por lo tanto, no tiene sentido crear objetos mamfero.
En UML, para expresar que una clase es abstracta, tenemos que escribir el
nombre de la clase en letra cursiva.
Figura 20. Representacin

de una clase abstracta
Una vez acabada la etapa de diseo del modelo de nuestro problema, si nos
ponemos a programar, encontraremos que las clases abstractas sirven en gran
manera para permitir y facilitar la reutilizacin de cdigo.
5.2. Clases parametrizadas
Las clases parametrizadas (tambin denominadas clases genricas) son

clases que permiten recibir como parmetro cualquier otro tipo de clase.
El ejemplo por excelencia de clase parametrizada son las denominadas clases

contenedoras (listas, vectores, rboles, pilas, diccionarios, etc.), que nos permi-
ten almacenar objetos y tratarlos de manera diferente segn las propiedades
de los contenedores, pero de manera independiente de la clase de los objetos
almacenados. Esta independencia nos permite no tener que implementar una
clase contenedora para cada clase que queremos almacenar deberamos crear
un VectorDePersonas, VectorDeCoches, VectorDeMamiferos, etc., con
lo que mejoramos la reutilizacin del cdigo.
Para entender un poco ms a qu denominamos nosotros contenedor, aqu tenis una lista
de algunos contenedores y una pequea explicacin de su comportamiento.
Lista: contenedor que almacena objetos, generalmente de manera ordenada (por or-
den de insercin, o por algn otro parmetro).
Pila: contenedor de objetos con un comportamiento LIFO (last in, first out; es decir,
el ltimo elemento almacenado es el primero que se recupera).
Vector: contenedor que implementa una matriz de tamao variable. Permite acceder
a los objetos por medio del ndice en el que estn almacenados.
Diccionario: contenedor que, a partir de una clave, devuelve un objeto (funciona

de la misma manera que los diccionarios de lengua).
No todos los lenguajes de programacin orientados a objetos ofrecen mecanis-

mos para crear clases parametrizadas. En los lenguajes que no ofrecen esta po-
sibilidad, se puede recurrir a tcnicas de programacin para simular las clases
parametrizadas.
5.3. Clases finales
Las clases definidas como finales tienen como propiedad que no se per-
mite su extensin mediante la especializacin.
Este tipo de clases se utiliza cuando no se quiere que puedan especializarse en

otras clases, tanto si es porque en el dominio del problema no tiene sentido la
herencia por ejemplo, si definimos la clase de los nmeros complejos con to-
dos los mtodos, no tiene ningn sentido permitir la herencia, como si es por
cuestiones de seguridad del cdigo.
Resumen
La creacin de software es inherentemente compleja porque ste representa

un dominio que es tambin complejo. Adems, se debe tener en cuenta la ne-
cesidad de gestionar un equipo de desarrollo.
La abstraccin es un mecanismo del pensamiento humano que se utiliza en la

programacin para desarrollar sistemas. La orientacin a objetos se puede con-
siderar un paradigma de la abstraccin centrado en los datos y en la represen-
tacin de la estructura del dominio de los problemas mediante el concepto de
objeto (representacin de una entidad individual del dominio) y de la clase
(representacin de un conjunto de objetos con caractersticas parecidas).
Cuando analizamos un problema mediante la orientacin a objetos, hay que

pensar en dos niveles relacionados ntimamente: el de las clases y el de los ob-
jetos. Aunque en la mayora de los casos en los diagramas que realizaremos
para representar la realidad slo aparecern clases, habr que tener siempre
presente que nuestro programa se basar exclusivamente en la interaccin en-
tre los diferentes objetos relacionados entre s.
Hay metodologas que nos guan en el proceso de modelado de nuestro domi-

nio y, aunque ninguna de stas garantiza un resultado perfecto, algunas se
acercan bastante. Es el diseador quien, con la experiencia, refina estas meto-
dologas para mejorar los diseos.
Las clases no estn aisladas en nuestros dominios, sino que se relacionan con
otras clases, relaciones que representamos en los diagramas como asociacio-
nes. Este concepto tiene muchos elementos que nos permiten definir el com-
portamiento de las asociaciones y es de los ms importantes en el paradigma
de la programacin orientada a objetos.
Un tipo especial de asociacin es el que nos trae el concepto de generali-

zacin/especializacin, que hemos introducido vagamente (hemos visto las
posibilidades que nos ofrece) y que veremos ampliado en mdulos posteriores.
Unos tipos de clases que nos pueden servir en determinadas ocasiones para fa-
cilitar la tarea de modelizacin son las clases abstractas, las clases parametriza-
das y las clases finales. No hay que utilizarlas en todos los diseos, pero s que
es necesario conocerlas para poder utilizarlas cuando sea necesario.
Ejercicios de autoevaluacin
1. Razonad si en el modelado de una aplicacin de dibujo geomtrico se podran incluir las
clases siguientes:
Punto
Circulo
Elipse como especificacin de la clase Circulo
TrianguloRectangulo como especificacin de la clase Triangulo
FiguraGeometrica
FiguraGeometrica como clase abstracta
2. Explicad cmo se tendra que representar la relacin entre las novelas y los autores, como
una asociacin o como una agregacin?
3. A partir del diagrama de clases siguiente:
Si todo el mundo debe tener algn padre biolgico en el mundo real, por qu razn tenemos
la cardinalidad 0..2 en el extremo de Parent? De dnde sale este 0 y por qu tiene sentido?
Ejercicios de modelado
1. Se quiere modelar un carrito de la compra para los usuarios registrados (mediante usuario
y contrasea) de una tienda virtual de venta de libros y CD musicales. Un carritode la compra...
De los libros es necesario que almacenis los autores y el ndice o tabla de contenidos es
... permite ir almacenando
decir, la lista de captulos y posibles subcaptulos; de los CD tambin es necesario que al- productos hasta que se decida
macenis al autor que, por ejemplo en el caso de las recopilaciones, puede ser ms de uno. realizar el pedido con los pro-
Un cliente puede tener varias direcciones postales y diferentes tarjetas de crdito (VISA, ductos guardados, y despus
Mastercard, AMEX, etc.). En el momento de realizar el pedido, tenis que permitir que se- queda vaco para volver a
leccione una de sus tarjetas para pagar y una de las direcciones postales que haya inserta- empezar.
do. Debis tener en cuenta que un cliente puede realizar varios pedidos con una direccin
postal y una tarjeta de crdito diferente para cada caso.
Slo es necesario que hagis el modelo de clases, no hace falta que modelis los distintos
pedidos que se generan a partir del contenido de los carritos. No es necesario que definis
todas las operaciones, slo
las ms importantes.
2. Se intenta realizar un modelo que sirva para mantener un registro de los resultados de la liga
de hockey sobre hielo. En este modelo, tenis que representar los partidos y los equipos, pero
no es necesario que almacenis ninguna informacin referente a los rbitros, estadios o a
otros elementos que no sean imprescindibles para cubrir las funcionalidades pedidas.
Las funcionalidades que se esperan del modelo son:
Obtener la tabla de clasificacin actual.
A partir de un equipo, obtener el calendario de los partidos que falta disputar.
Obtener al mximo goleador del campeonato hasta el momento y hacer la lista de los
goles anotados en cada partido, con el minuto en el que fue marcado. Supondremos
que los jugadores no cambian de equipo durante la temporada.
En el caso de que haya jugadores extranjeros, es necesario que almacenis su nacionalidad.
Solucionario
Ejercicios de autoevaluacin
1. Razonad si en el modelado de una aplicacin de dibujo geomtrico se podran incluir las
clases siguientes.
Punto: es una clase que se podra incluir, ya que un punto es una figura geomtrica.
Circulo: tambin se podra incluir, por las mismas razones que la clase Punto.
Elipse como especificacin de la clase Circulo: no tiene sentido porque una elipse no
es un caso especfico de crculo; por lo tanto, no tendra sentido crear una relacin de
especializacin.
TrianguloRectangulo como especificacin de la clase Triangulo: podra tener senti-
do, porque un tringulo rectngulo es, en esencia, un tringulo con una propiedad dife-
renciadora, pero habra que ver si esta distincin realmente es necesaria para la aplicacin.
FiguraGeometrica: en principio, no tendra ningn sentido ya que es un concepto abs-
tracto que no puede ser representado en un dibujo.
FiguraGeometrica como clase abstracta: en este caso s que tiene sentido tener una clase
abstracta que sirva para agrupar todas las formas geomtricas posibles y definir unas pro-
piedades y funcionalidades comunes.
2. La asociacin entre novelas y autores siempre ser una asociacin, ya que no hay ninguna
relacin semntica todo/parte entre los mismos. Aparte, los objetos que representen las
novelas y los autores no tienen por qu tener unos tiempos de vida coincidentes.
3. En este caso, la cardinalidad 0..2 nos indica que, aunque en el mundo real toda persona
necesita a un hombre y una mujer para nacer, se puede dar el caso de que en nuestra apli-
cacin no almacenemos los datos de ambos, porque desconocemos los datos, porque no
nos interesan para nuestro dominio o por cualquier otra razn.
El 0 se puede interpretar de muchas maneras, pero la ms sencilla es la falta de los datos
de los padres de una persona.
Ejercicios de modelado
1. El diagrama que resuelve el problema planteado podra ser parecido a ste:

2. Puesto que nos piden que almacenemos la mnima cantidad de informacin posible, hay
que ver cules son los datos que necesitamos para poder ofrecer las funcionalidades que
nos piden.
La nica cosa necesaria para poder mantener una clasificacin son los equipos y los resul-
tados de los partidos que juegan entre s. El resultado se puede almacenar como el valor
de los goles del partido y despus calcularemos su resultado, sabiendo cul es el equipo
local y el visitante.
Es necesario que el partido est relacionado con los equipos que juegan con dos roles para
distinguir el equipo local y el visitante.
Para saber quin es el mximo goleador y poder realizar todas las operaciones pedidas, hay
que asociar a los jugadores con los equipos, y tambin con todos los partidos en los que haya
marcado goles. Y mediante una clase asociativa, el registro del minuto en el que los marc.
Finalmente, para saber la nacionalidad de los jugadores extranjeros, necesitaremos una
clase que herede de Jugador y que almacene el nombre del pas.
Glosario
abstraccin f Capacidad de concebir un concepto sin pensar en ningn ejemplo especfico.
asociacin f Relacin entre dos o ms clases de objetos.
asociacin asociativa f Relacin entre dos instancias de clases diferentes en la que se de-
ben almacenar datos de esta relacin.
asociacin de agregacin f Relacin entre dos clases de objetos en la que una contiene
una unin de entidades de la otra.
asociacin de composicin f Relacin entre dos clases de objetos en la que una contiene
un grupo de entidades de la otra y en la que stas no tienen sentido fuera de la relacin.
asociacin reflexiva f Relacin entre dos instancias de una misma clase.
cardinalidad f Manera de describir el nmero de entidades con el que est relacionada cada
instancia de una relacin.
clase f Concepto que permite definir entidades con propiedades comunes mediante la abs-
traccin.
clase abstracta f Clase que queda definida, pero que no acepta instancias concretas.
clase final f Clase de la que no se pueden especializar las otras clases.
clase parametrizada f Clase que define el comportamiento sin que se tenga en cuenta el
tipo objeto sobre el cual se actuar.
especializacin f Accin de crear una clase a partir de otra aadindole significado.
generacin f Accin de crear una clase mediante otras buscando los trminos comunes.
navegabilidad bidireccional f Propiedad que ofrece a ambas clases el conocimiento de

la existencia del otro lado de la asociacin.
navegabilidad unidireccional f Propiedad que ofrece nicamente a una clase de la aso-

ciacin el conocimiento de la existencia del otro lado.
objeto m Instancia de una clase de objetos.
rol m Nombre que identifica cada extremo de una asociacin.
Bibliografa
Booch, G.; Jacobson, I.; Rumbaugh, J. (1999). El lenguaje unificado de modelado. Madrid:
Addison Wesley.
Meyer, B. (1997). Object-oriented software construction. Santa Brbara: Prentice Hall.
Gamma, E.; Helm, R.; Johnson, R.; Vlissides, J. (1995). Design patterns. Elements of
reusable object-oriented design. Addison Wesley.
Rumbaugh, J.; Blaha, M.; Premernali, W.; Eddy, F.; Lorensen, W. (1996). Modelado
y diseo orientado a objetos. Madrid: Prentice Hall.

Pid 00161676

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Pid 00161676

Transféré par

Droits d'auteur :

Formats disponibles

Abstraccin

1. Complejidad y abstraccin ............................................................. 9

2. Los principios de la clasificacin .................................................. 12

3. Relaciones entre clases ..................................................................... 18

4. Tcnica simple para identificar clases ........................................ 26

5. Tipos de clases .................................................................................... 29

Ejercicios de autoevaluacin ............................................................... 33

Ejercicios de modelado ......................................................................... 33

En este mdulo, planteamos la orientacin a objetos como un mecanismo de

Dicho de otra manera, cuando nos enfrentamos al desarrollo de una aplica-

Si queremos desarrollar una aplicacin para gestionar las calificaciones de evaluacin

Los objetos representan entidades independientes especficas de elementos del

Ahora bien, cuando elaboramos un modelo de un problema utilizando la

El recorrido rpido que acabamos de realizar sobre la manera de estructurar la

En este mdulo profundizaremos en las clases, los objetos y sus relaciones

Los materiales didcticos de este mdulo proporcionan los conocimientos

1. Comprender la abstraccin como mecanismo para tratar la complejidad

2. Conocer los diferentes tipos de abstraccin que se utilizan en el desarrollo

3. Entender las clases como abstracciones de los objetos, y tambin compren-

4. Entender el proceso de abstraccin de la orientacin a objetos siguiendo

5. Conocer las relaciones fundamentales entre las clases y saberlas identificar:

6. Conocer algunos tipos especiales de clases: clases abstractas, parametriza-

Nuestro punto de partida en este mdulo es el concepto de complejidad aso-

1.1. La complejidad inherente al software

Desde hace dcadas, se considera que la complejidad es una caracterstica in-

La complejidad del software puede tener su origen en el dominio del problema

Adems, esta complejidad suele ser desorganizada o arbitraria, ya que la orga-

Puesto que la complejidad es inherente al software, no podemos hacer que

nos permitan tratarla y gestionarla. Esto es lo que ha hecho la comunidad de

La abstraccin, que trataremos a continuacin, es un principio fundamental

1.2. La abstraccin en el desarrollo de software

La abstraccin es un mecanismo de la inteligencia humana que nos

En todo proceso de abstraccin, siempre hay una parte de la situacin o del

Una de las caractersticas de la abstraccin es su jerarquizacin, de manera que

Trasladado al caso, por ejemplo, de una ciudad, podemos observar su plano

Tambin puede haber diferentes abstracciones porque a la hora de construir-

Otro ejemplo muy claro de abstraccin es la que se puede producir cuando

A medida que se ha intentado controlar la complejidad del software, el desa-

distintos tipos de abstracciones en los programas. Algunas de las ms relevan-

La primera abstraccin se produjo con la llegada del lenguaje ensambla-

Otro hito importante fue la aparicin de los lenguajes de programacin

Ms tarde, en la dcada de los cincuenta, apareci la abstraccin funcio-

La aparicin del concepto de tipo abstracto de datos, con el cual se pue-

La abstraccin basada en los datos evoluciona y da lugar a lo que hoy deno-

En la actualidad, y vistas las ventajas del enfoque estudiadas previamente, se

2. Los principios de la clasificacin

En este apartado, nos detendremos en los conceptos clave de clase, objeto y su

2.1. Modelar pensando en los objetos

Cuando tenemos que tratar el dominio de un problema, encontramos

Pensemos, por ejemplo, en una aplicacin de gestin de stocks en una fbrica

Figura 1. Representacin de objetos y clases

El diagrama representa los objetos o1 y o2 como instancias de la clase Motor,

La clase Engine representa realmente el concepto de tipo de motores, por

En los valores de las instancias, vemos que se mezclan dos informaciones

Supongamos ahora que, adems de conocer el stock, queremos hacer un segui-

Figura 2. Representacin de objetos y clases

En esta segunda versin, el stock de los motores es el recuento de los objetos

Podis ver el resultado en el diagrama siguiente:

motivo, hemos partido de los objetos para obtener, a partir de ejemplos

Las clases determinan la estructura y la informacin que pueden guar-

Cada uno de los objetos de un modelo o sistema determinados es una entidad

En el ejemplo anterior del almacn, una representacin alternativa a la versin definitiva

Los objetos tienen identidad propia, al margen de cualquiera de sus atribu-