Modelos

orientados a
objetos

Análisis de
Sistemas

1
Características de los Modelos
Orientados a Objetos
El Paradigma Orientado a Objetos
En los Modelos Orientados a Objetos, el sistema se puede ver (en términos
de percepción) como una colección de objetos que colaboran entre sí para
obtener un objetivo común. Las operaciones que modifican el estado de los
objetos son sencillas; los objetos se construyen a partir de otros objetos lo
que lleva a que los sistemas se puedan construir a partir de componentes
probados.

Por lo enunciado anteriormente, las técnicas orientadas a objetos se

pueden utilizar como medios para el diseño sencillo de sistemas complejos.

La orientación a objetos es muy poderosa cuando se combinan varias

tecnologías: metodologías de Análisis y Diseño Orientado a Objetos,
herramientas CASE (Ingeniería de Software Asistida por Computadora),
Programación Visual, Generadores de Código, entre otras.

El análisis y diseño orientado a objetos tiene algunas características

importantes:

Cambian nuestra forma de pensar sobre los sistemas. Para la

mayoría de las personas la forma de pensar OO es más
natural. Comenzamos a aprender sobre ellos desde la
infancia (por ejemplo, al agitar un sonajero éste hace ruido).
Desde una etapa muy temprana categorizamos los objetos y
descubrimos su comportamiento.

Los sistemas suelen construirse a partir de objetos ya

existentes. Esto lleva a un alto grado de reutilización, a una
disminución de costos, un menor tiempo de desarrollo y una
mayor confiabilidad del sistema.

La complejidad de los objetos que podemos utilizar sigue

en aumento, puesto que nuevos objetos se construyen a
partir de otros, que a su vez están constituidos por otros
objetos, y así sucesivamente.

2
 Ayuda a explotar la potencia expresiva de los lenguajes de
programación basados en objetos y orientados a objetos.

Elementos del Modelo de Objetos

Para todo lo que se considere “orientado a objetos” (un lenguaje de
programación, un herramienta CASE, técnicas de modelado, un proceso de
desarrollo, por ejemplo) el marco de referencia conceptual es el modelo de
objetos. Hay cuatro elementos fundamentales en este modelo:

 Abstracción
 Encapsulamiento
 Modularidad
 Jerarquía

Al decir fundamentales se quiere significar que cualquier modelo que

carezca de alguno de estos elementos no se considera “orientado a
objetos”.

Desarrollamos a continuación el concepto de cada uno de los elementos

fundamentales.

Abstracción

Como la define Grady Booch, la abstracción “denota las características

esenciales de un objeto que lo distinguen de todos los demás tipos de
objeto y proporciona así fronteras conceptuales nítidamente definidas
respecto a la perspectiva del observador”. (Booch Grady, 1996, pág. 46).

Una abstracción se centra en la visión externa de un objeto y sirve para

separar el comportamiento esencial de un objeto de su forma de
implementación.

En el desarrollo del modelo de objetos de un sistema se tratará de

construir abstracciones de entidades que imiten directamente el
vocabulario de un determinado dominio de problema.

Se puede caracterizar el comportamiento de un objeto considerando los

servicios que presta a otros objetos, así como las operaciones que puede
realizar sobre otros objetos. Este punto de vista nos lleva a concentrarnos
en la visión exterior del objeto, lo que algunos llaman el modelo
contractual; la vista exterior de cada objeto define un contrato del que
pueden depender otros objetos y que a su vez es llevado a cabo por la vista
interior del propio objeto (a menudo en colaboración con otros objetos).

3
Este contrato abarca las responsabilidades de un objeto, es decir el
comportamiento del que se le considera responsable.

Por ejemplo, en un banco uno de los servicios ofrecidos es del de Caja de

Ahorro. Desde una vista externa una caja de ahorro en un objeto que sabe
cuál es su número de cuenta, a quién pertenece y cuál es su saldo (de
manera simplificada). ¿Qué es su número de cuenta? Un valor numérico de
ocho dígitos y su saldo será un valor que represente el monto de dinero
actualmente depositado en ella. Sus responsabilidades serán, entre otras:

 Conocer su saldo actual

 Conocer su número
 Incrementar su saldo por un depósito
 Disminuir su saldo por una extracción
 Conocer quién es su titular
 Mostrar sus dato
 Conocer su fecha de cierre

Encapsulamiento

La abstracción y el encapsulamiento son conceptos complementarios: la

abstracción se centra en el comportamiento observable de un objeto,
mientras el encapsulamiento se centra en la implementación que da lugar
a este comportamiento. El encapsulamiento se consigue mediante la
ocultación de información, por el cual se ocultan todos los aspectos de un
objeto que no contribuyen a sus características esenciales. Normalmente lo
que se oculta es la estructura de datos de un objeto así como la
implementación o codificación de sus métodos.

Grady Booch define el encapsulamiento como “el proceso de almacenar en

un mismo compartimiento los elementos de una abstracción que
constituyen su estructura y su comportamiento; sirve para separar la
interfaz contractual de una abstracción y su implantación”. (Booch Grady,
1996, pág. 54,56).

En nuestro ejemplo de la caja de ahorro, por ejemplo, la propiedad saldo

podría estar internamente almacenada como:

Saldo: campo de tipo real con dos decimales

O podría estar almacenada de la siguiente manera:

Importe entero: campo entero que almacena la cantidad entera del saldo

Importe decimal: campo entero que almacena la cantidad decimal del saldo

4
Cualquier objeto “titular” que solicite a “caja de ahorro” que muestre su
saldo recibirá como respuesta, por ejemplo, $ 100,50 y nunca se enterará
de qué manera está internamente guardado este dato, así como tampoco
sabrá cómo operan los métodos de caja de ahorro para mostrar este saldo.

De igual manera, cuando a un objeto “titular” le llega una solicitud de

servicio (mensaje) por el cual se le pide mostrar su nombre, éste retornará
una cadena de caracteres en la que figuran su apellido, primer nombre y
segundo nombre, si lo tuviera. El objeto que hizo la solicitud no sabe si el
objeto titular tiene:

 Un atributo “apellidoYNombre”
 Dos atributos: apellido
Nombre
 Tres atributos: Apellido
Primer Nombre
Segundo Nombre

De este modo el encapsulamiento permite que se pueda cambiar la

implementación de un objeto y que ninguna otra parte del sistema deba
ser modificada siempre que no modifique su interfaz (abstracción), que es
lo que los otros objetos conocen para poder comunicarse con este objeto.

Modularidad

Como afirma Booch –citando a Liskov– “la modularización consiste en

dividir un programa en módulos que pueden compilarse separadamente,
pero que tienen conexiones con otros módulos”. (Booch Grady, 1996, pág.
61).

En algunos lenguajes las clases y objetos forman la estructura lógica de un

sistema; se sitúan, entonces, estas abstracciones en módulos para producir
la arquitectura física del sistema.

Los módulos sirven como contenedores físicos en los que se declaran las
clases y objetos del diseño lógico realizado. Especialmente para
aplicaciones grandes en las que puede haber varios cientos de clases el uso
de módulos es esencial para ayudar a manejar la complejidad. Para
problemas muy pequeños el desarrollador podría decidir declarar todas las
clases en el mismo paquete. Para cualquier situación que se salga de lo
trivial, es mejor solución agrupar las clases que se relacionan lógicamente
en el mismo módulo.

5
Desde nuestra perspectiva, concluye Booch, “la modularidad es la
propiedad que tiene un sistema que ha sido descompuesto en un conjunto
de módulos cohesivos y débilmente acoplados”. (Booch Grady, 1996, pág.
61).

Jerarquía

La jerarquía es una forma de clasificar u ordenar las abstracciones.

Frecuentemente un conjunto de abstracciones forma una jerarquía y la
identificación de estas jerarquías en el análisis y diseño simplifica en gran
medida la comprensión del problema.

Las dos jerarquías más importantes son:

 Su estructura de clases: la “jerarquía de clases” está dada por la

herencia.
 Su estructura de objetos: la “jerarquía de objetos” está dada por la
agregación.

No desarrollamos aquí estos conceptos porque se verán más adelante en

las secciones “Relaciones entre Clases” y “Relaciones entre Objetos”.

Objetos y Clases

OBJETO

Concepto

Como lo plantea Booch, desde la “perspectiva de la cognición humana” un

objeto puede ser:

 Una cosa tangible y/o visible.

 Algo que puede comprenderse intelectualmente.
 Algo hacia lo que se dirige un pensamiento o acción”. (Booch Grady,
1996, pág. 96).

A esta definición informal podemos agregar que un objeto modela alguna

parte de la realidad y es por lo tanto algo que existe en el tiempo y en el
espacio.

Ahora bien, los objetos del mundo real no son el único tipo de objeto de
interés en el desarrollo de software. Existen otros tipos importantes de
objetos que son invenciones del proceso de diseño cuyas colaboraciones
con objetos semejantes sirven como mecanismos para desempeñar algún

6
comportamiento de nivel superior. Esto nos lleva a una definición
mejorada según la cual “un objeto representa un elemento, unidad o
entidad individual e identificable, ya sea real o abstracta, con un papel bien
definido en el dominio del problema”.

Un objeto tiene estado, comportamiento e identidad; la estructura y

comportamiento de objetos similares están definidos en su clase común.

Estado:

Booch nos proporciona la siguiente definición “el estado de un objeto

abarca todas las propiedades (normalmente estáticas) del mismo más los
valores actuales (normalmente dinámicos) de cada una de esas
propiedades”. (Booch Grady, 1996, pág. 98).

Una propiedad es una característica inherente o distintiva, un rasgo o

cualidad que hace que ese objeto sea ese y no otro. Las propiedades suelen
ser estáticas porque estos atributos suelen ser inmutables y fundamentales
para la naturaleza del objeto.

Todas las propiedades tienen algún valor. Este valor puede ser una mera
cantidad o puede denotar otro objeto. Se dice que los valores son
“normalmente” dinámicos porque en algunos casos los valores son
estáticos, como en nuestro ejemplo de “Caja de Ahorro” la propiedad (o
atributo) número no cambia, va a cambiar seguramente el valor del
atributo saldo y probablemente el del atributo fechaDeCierre...

Siguiendo con este ejemplo el estado de un objeto caja de ahorro estará

dado por los valores que adopte la propiedad saldo y fechaDeCierre. Así los
estados posibles serán:

 Con saldo: si el valor de saldo es mayor a cero

 Sin saldo: si el valor de saldo es igual a cero
 Cerrada: si el valor de fechaDeCierre es distinto a vacío.

Comportamiento:

Ningún objeto existe de forma aislada. Los objetos reciben acciones y ellos
mismos actúan sobre otros objetos.

“El comportamiento es cómo actúa y reacciona un objeto, en términos de

sus cambios de estado y paso de mensajes” (Booch Grady, 1996, pág. 101).
es decir, el comportamiento de un objeto representa su actividad visible y
comprobable exteriormente. Una operación representa un servicio que
todos los objetos de una clase ofrecen a sus clientes. Se reconocen cinco

7
tipos de operaciones sobre un objeto. Los tres tipos más comunes de
operaciones son los siguientes:

Modificador: Una operación que altera el estado de un

objeto (modifica el valor de alguno/s de sus atributos. Por
ejemplo: depositar, extraer, transferir para un objeto
cajaDeAhorro.

Selector: Una operación que accede al estado de un objeto

(a alguno/s de sus atributos) pero no altera ese estado. Por
ejemplo: mostrarTitular, mostrarSaldo,
mostrarNumeroCuenta.

Iterador: Una operación que permite acceder a todas las

partes de un objeto en algún orden perfectamente
establecido. Por ejemplo, si un objeto Titular tiene una
propiedad nroTeléfono con múltiples valores (para el
teléfono particular, laboral, celular) la operación
mostrarTeléfono será una operación iteradota.

Hay otros dos tipos de operaciones habituales, que representan la

infraestructura necesaria para crear y destruir objetos (instancias de una
clase):

 Constructor: Una operación que crea un objeto y/o inicializa su estado.

 Destructor: Una operación que libera el estado de un objeto y/o
destruye el propio objeto.

Unificando las definiciones de estado y comportamiento, Rebecca Wirfs-

Brock definió las responsabilidades de un objeto de manera que éstas
incluyen el conocimiento que un objeto mantiene y las acciones que puede
llevar a cabo.

Las responsabilidades de un objeto son todos los servicios que éste

proporciona.

Identidad:

En el paradigma orientado a objetos, la identidad es la propiedad que tiene

un objeto que le permite distinguirse de todos los demás objetos. La
mayoría de los sistemas de bases de datos utilizan claves de identificación
para distinguir objetos persistentes, mezclando el valor de un dato con la
identidad.

8
En el mundo de los objetos podemos tener dos de ellos con valores iguales
en todas sus propiedades y seguir siendo dos objetos distintos cada uno
con su propia identidad. Por ejemplo, puede haber dos objetos Persona
que tengan exactamente el mismo nombre, apellido, dirección y teléfono,
pero eso no significa que sean la misma persona (tenemos muchos casos
conocidos de padres e hijos con los mismos nombres y mientras vivan en la
misma casa también la misma dirección); en el paradigma orientado a
objetos cada uno de esos objetos tiene su propia “identidad” y son
perfectamente identificables.

Los sistemas de bases de datos relacionales son incapaces de distinguir

entre dos objetos o instancias con valores iguales, por ello se hace
indispensable contar con una clave identificatoria, que en nuestro ejemplo
de padre e hijo sería por ejemplo el número de documento. Esta será una
cuestión importante a considerar si llegado el momento de decidir la forma
de persistencia de nuestro modelo orientado a objetos la elegida es una
base de datos relacional. En este momento habrá que disponer de un
mecanismo que salve las diferencias de ambos esquemas de
representación.

CLASE

Concepto:

Los conceptos de clase y objeto están estrechamente relacionados, porque

no puede hablarse de un objeto sin atención a su clase. Sin embargo,
existen diferencias entre ambos términos. Mientras que un objeto es una
entidad concreta que existe en el tiempo y en el espacio, una clase
representa sólo una abstracción, la “esencia” de un objeto.

En el contexto del análisis y diseño orientado a objetos, Booch define una

clase como “un conjunto de objetos que comparten una estructura común
y un comportamiento común” (Booch Grady, 1996). Esto significa que una
clase es una descripción de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semántica.

Las clases son los bloques de construcción más importantes de cualquier

sistema orientado a objetos. Se pueden utilizar para capturar el
vocabulario del sistema que se está desarrollando. Estas clases pueden
incluir abstracciones que formen parte del dominio del problema, así como
clases que constituyen el dominio de una determinada solución
tecnológica. Se pueden utilizar clases para representar cosas que sean
software, hardware o puramente conceptuales.

9
Responsabilidades de una clase:

Una responsabilidad es un contrato o una obligación de una clase. Al crear

una clase, se está expresando que todos los objetos de esa clase tienen el
mismo tipo de estado y el mismo tipo de comportamiento. A un nivel más
abstracto, estos atributos y operaciones son simplemente las
características por medio de las cuales se llevan a cabo las
responsabilidades de una clase.

Al modelar clases, un buen comienzo consiste en especificar las

responsabilidades de los elementos del vocabulario. Una clase puede tener
cualquier número de responsabilidades, aunque en la práctica cada clase
bien estructurada tiene al menos una responsabilidad y a lo sumo unas
pocas. Al ir refinando el modelo se traducirán estas responsabilidades en el
conjunto de atributos y operaciones que mejor satisfagan las
responsabilidades de la clase.

Las responsabilidades se enuncian como texto libre: una frase, una

sentencia o, como mucho, un párrafo corto.

Vistas de una clase:

Debemos distinguir entre la visión externa (interfaz), y la visión interna,

(implementación), de una clase.

La interfaz de una clase proporciona su visión externa y por lo tanto

enfatiza la abstracción a la vez que oculta su estructura y su
comportamiento. Esta interfaz se compone principalmente de las
declaraciones de todas las operaciones aplicables a instancias de esta clase
(objetos), pero también puede incluir la declaración de constantes,
variables y excepciones que se necesiten para completar la abstracción.

Por otro lado, la implementación de una clase es su visión interna, que

engloba los secretos de su comportamiento. La implementación de una
clase se compone de la implementación de todas las operaciones definidas
en la interfaz de la misma.

Se puede especificar la interfaz de una clase con cualquiera de los tres

niveles de visibilidad disponibles:

 Pública: Una declaración accesible a todos los clientes de esa clase.

 Protegida: Una declaración accesible sólo a la propia clase, sus subclases
y clases amigas.
 Privada: Una declaración accesible sólo a la propia clase y sus clases
amigas.

10
A lo que nos indica la bibliografía clásica podemos agregar un tipo más de
visibilidad generalmente soportado por los lenguajes orientados a objetos
y las herramientas automatizadas de modelado que es la “visibilidad de
paquete”, esto significa que el elemento el público dentro del paquete o
subsistema en el que se encuentre alojado.

La implementación de estas características dependerá de cómo lo maneje

el lenguaje de programación elegido.

A continuación se muestra una forma de representación gráfica para una

clase, utilizada en UML (Lenguaje Unificado de Modelado, ver Unidad 2 de
este módulo)

Figura 1

Nombre: Cada clase ha de tener un nombre que la distinga de otras clases.

Una clase puede dibujarse mostrando sólo su nombre, como se muestra a
continuación:

Figura 2

Atributos: Un atributo es una propiedad de una clase identificada con un

nombre, que describe un rango de valores que pueden tomar las instancias
de la propiedad. Una clase puede tener cualquier número de atributos o no
tener ninguno. Un atributo representa alguna propiedad del elemento que
se está modelando que es compartida por todos los objetos de esa clase.
Un atributo es una abstracción de un tipo de dato o estado que puede
incluir un objeto de la clase.

11
Operaciones: Una operación es la implementación de un servicio que
puede ser requerido a cualquier objeto de la clase para que muestre su
comportamiento, es decir, una operación es una abstracción de algo que se
puede hacer a un objeto y que es compartido por todos los objetos de la
clase. Una clase puede tener cualquier número de operaciones y por lo
menos una operación. A menudo, pero no necesariamente, la invocación
de una operación sobre un objeto cambia los datos o el estado del objeto.
En nuestro ejemplo sería el caso de las operaciones “depositar ()” y
“extraer()”. Dependiendo del nivel de abstracción en que se esté
modelando nos referiremos a responsabilidades (a nivel modelado de
requisitos y análisis), operaciones (en general a nivel diseño) y métodos
(normalmente durante la etapa de implementación/codificación), para
referirnos a los servicios que prestan los objetos de una clase.

RELACIONES ENTRE OBJETOS

Un objeto por sí mismo no es demasiado interesante. Los objetos

contribuyen al comportamiento de un sistema colaborando con otros. Hay
dos tipos de relaciones que se pueden dar entre objetos: enlaces y
agregación.

Enlaces:

Como nos cita Booch “… el término enlace es definido por Rumbaugh como
una conexión física o conceptual entre objetos”. (Booch Grady, 1996).

Un objeto colabora con otros a través de sus enlaces con éstos. Esto quiere
decir que un enlace denota la asociación específica por la cual un

objeto (el cliente) utiliza los servicios de otro objeto (el servidor) o a través
de la cual un objeto puede comunicarse con otro.

Un concepto esencial en el paradigma orientado a objetos, es el hecho de

que los objetos “colaboran” entre sí para llevar a cabo un comportamiento
superior.

Una colaboración representa la solicitud de un servicio desde un objeto

cliente a un objeto servidor para cumplir una responsabilidad del cliente.
Los objetos de una clase pueden cumplir una responsabilidad por sí solos o
pueden requerir la asistencia de otros objetos (de otras clases).

Se dice que un objeto S colabora con otro objeto C, si el objeto C para

cumplir con una responsabilidad, necesita enviar algún mensaje a S
solicitándole un servicio. Desde el punto de vista del cliente, “C”, cada una

12
de sus colaboraciones están asociadas con una responsabilidad particular
implementada por el servidor, “S”.

Un mensaje enviado de un objeto a otro representa la existencia de un

enlace entre ambos. Los mensajes se muestran como líneas dirigidas, que
representan su dirección, con una etiqueta que nombra al propio mensaje.
Aunque el paso de mensajes es iniciado por el cliente y dirigido hacia el
servidor los datos pueden fluir en ambas direcciones a través de un enlace:

 del cliente al servidor: parámetros

 del servidor al cliente: respuesta

Supongamos que el objeto “cajaDeAhorro”, que conoce quién es su

“titular”, como parte de su responsabilidad de mostrar sus datos
completos debe mostrar el nombre del titular. Entonces necesita pedirle al
objeto Titular que le retorne su nombre, para ello le enviará un mensaje
indicándole tal solicitud. El objeto Titular responderá retornándole su
nombre. Así se manifiesta el enlace entre ambos objetos. Esto puede
representarse gráficamente de la siguiente manera:

Figura 3

El gráfico donde se muestran los enlaces entre objetos se denomina

“Diagrama de Colaboraciones” y en general se utiliza durante el modelado
de análisis.

Agregación:

La agregación denota una jerarquía todo/parte, en la cual un objeto del

todo tiene o contiene objetos de la parte.

La agregación puede o no denotar contención física. Por ejemplo, un

aeroplano se compone de alas, motores, tren de aterrizaje: es un caso de
contención física. En otro ejemplo, un accionista tiene acciones, pero las
acciones no son de ninguna manera parte física del accionista. Esta última
relación todo/parte es más conceptual y por lo tanto menos directa que la
agregación física de las partes que forman un aeroplano.

13
Se desarrolla este tema con más detalle en el punto siguiente, “Relaciones
entre Clases”.

RELACIONES ENTRE CLASES

Las clases, al igual que los objetos, no existen aisladamente. Antes bien,
para un dominio de problema específico las abstracciones clave suelen
estar relacionadas por vías muy diversas e interesantes, formando la
estructura de clases.

Existen tres tipos básicos de relaciones entre clases, en UML:

Generalización/Especialización, que denota una relación del tipo “es un”,

“padre/hijo”, conocida como herencia.

Asociación, que denota alguna dependencia semántica entre clases de otro

modo independientes.

Dependencia, es una relación de uso, se usarán cuando se quiera indicar

que un elemento utiliza a otro. Uno de los usos más frecuentes de la
dependencia es para modelar una visibilidad temporal desde los objetos de
una clase hacia los objetos de otra.

Herencia:

La herencia es una implantación de la generalización. La generalización

establece que las propiedades de un tipo se aplican a sus subtipos. La
herencia hace que la estructura de datos y operaciones de una clase
(padre) estén disponibles para su reutilización por parte de sus subclases
(hijos). La herencia de las operaciones de una superclase permite que las
clases compartan el código (en vez de volverlo a definir). La herencia de
estructura de datos permite la reutilización de la estructura.

En términos sencillos, la herencia es una relación entre clases en la que una

clase comparte la estructura y/o el comportamiento definidos en una
(herencia simple) o más clases (herencia múltiple). La clase de la que otras
heredan se denomina superclase o clase padre y la clase que hereda de
otra o más clases se denomina subclase o clase hija.

14
A menudo, una subclase añade atributos y operaciones a los que hereda de
sus padres, pero también puede redefinir el comportamiento heredado.
Una operación de un hijo con la misma signatura (nombre, parámetros y
valor de retorno) que una operación del padre, redefine la operación
heredada del padre; esto se conoce como polimorfismo, haciendo alusión a
una operación que adopta varias formas de implementación según haya
sido redefinida en las clases hijas.

Una clase puede tener uno o más padres o bien no tener ninguno. Una
clase sin padres y uno o más hijos se denomina raíz o clase base. Una clase
sin hijos se denomina clase hoja. Una clase con un único padre se dice que
utiliza herencia simple; una clase con más de un padre se dice que utiliza
herencia múltiple.

Las clases hojas son de las que se espera que existan instancias, es decir
objetos, por ello se las denomina también clases concretas. Las clases sin
instancias se llaman clases abstractas. Una clase abstracta se redacta con la
idea de que las subclases añadan elementos a su estructura y
comportamiento, usualmente completando la implementación de sus
métodos. De modo que nunca existirán objetos de una clase abstracta.

Gráficamente, la generalización se representa como una línea dirigida

continua, con una punta de flecha vacía apuntando al padre, como se
muestra en el siguiente ejemplo:

Figura 4

15
Observación: La simbología que se está utilizando para graficar las
relaciones entre clases es la establecida por UML.º

Asociación:

Una asociación es una relación estructural que especifica que los objetos
de una clase están conectados con los objetos de otra. Una asociación sólo
denota una dependencia semántica entre dos clases pero no establece la
forma exacta en que una clase se relaciona con la otra; sólo puede
denotarse esa semántica nombrando el papel que desempeña cada clase
en relación con la otra.

Dada una asociación entre dos clases se puede navegar desde un objeto de
una clase hasta un objeto de la otra.

Gráficamente, una asociación se representa como una línea continua que

conecta la misma o diferentes clases:

Figura 5

Un concepto importante a modelar respecto de una asociación es la

navegación. La navegación de una asociación específica que dado un
objeto perteneciente a la clase de un extremo se puede llegar fácil y
directamente a los objetos de la clase del otro extremo, normalmente
debido a que el objeto inicial almacena algunas referencias a los objetos en
el destino. La dirección de la navegación indica qué clase es la que
contiene la referencia hacia la otra (determina “quién conoce a quién”).

Figura 6

Puede ocurrir que en algunos casos la asociación necesite ser navegable en

ambos sentidos. Por ejemplo:

16
 Para mostrar los datos completos de una factura es necesario que
factura conozca al cliente al que corresponde.
 Para mostrar un resumen de cuenta de un cliente es necesario que
cliente conozca las facturas que le corresponden.

Esta situación se modela de la siguiente manera:

Figura 7

O también se puede modelar así:

Figura 8

Es legal que ambos extremos de una asociación estén conectados a la

misma clase. Esto significa que, dado un objeto de una clase, se puede
conectar con otro/s objeto/s de la misma clase. A este tipo de asociaciones
se les denomina reflexivas. Por ejemplo:

17
Figura 9

En este ejemplo se recurrió a otro elemento con el que podemos “adornar”

una asociación: la definición de un rol. Cuando una clase participa en una
asociación, tiene un rol específico que juega en la asociación; un rol es
simplemente la cara que la clase de un extremo de la asociación presenta a
la clase del otro extremo.

En muchas situaciones de modelado, es importante señalar cuántos

objetos pueden conectarse a través de una instancia de la asociación. Este
“cuántos” se denomina multiplicidad de la asociación y se escribe como
una expresión que se evalúa a un rango de valores o a un valor explícito.
Cuando se indica una multiplicidad en un extremo de una asociación se
está especificando que para cada objeto de la clase en el extremo opuesto
debe haber tantos objetos en este extremo. Se puede indicar una
multiplicidad de exactamente uno (1), cero (0), muchos (*), uno o más
(1..*) o un valor exacto (por ejemplo, 5). La multiplicidad se indica en el
extremo que corresponde a la navegación.

18
Figura 10

Agregación:

La agregación es un tipo especial de asociación. Las relaciones de

agregación entre clases tienen un paralelismo directo con las relaciones de
agregación entre los objetos correspondientes a esas clases. La agregación
es una relación “todo/parte” en la cual una clase representa una cosa
grande (el “todo”), que consta de elementos más pequeños (las “partes”).
Representa una relación del tipo “tiene un”, o sea, un objeto del todo tiene
objetos de la parte.

Gráficamente la agregación se representa como se muestra a continuación:

Figura 11

La agregación puede o no denotar contención física. Tenemos entonces

dos posibilidades en cuanto a la relación de agregación:

Agregación por Valor: Es un tipo de relación, en la que el tiempo de vida

del objeto incluido está condicionado por el tiempo de vida del que lo

19
incluye. Este tipo de relación es también llamada Composición (el Objeto
base se construye a partir del objeto incluido, es decir, es "parte/todo").

En este tipo de relación el objeto “parte” no existe independientemente

del objeto “todo” que lo contiene. Esto significa que el tiempo de vida de
ambos objetos está íntimamente relacionado: cuando se crea una instancia
del todo, se crea también por lo menos una instancia de la parte; cuando
se destruye el objeto “todo” esto implica la destrucción de todos los
objetos “parte” relacionados a él.

En el ejemplo, cuando se crea una instancia de Pedido (un objeto pedido)

es porque existe al menos una instancia (objeto) de la clase DetallePedido.

Figura 12

Agregación por Referencia: Es un tipo de relación, en donde el tiempo de

vida del objeto incluido es independiente del que lo incluye. Este tipo de
relación es comúnmente llamada Agregación (el objeto base utiliza al
incluido para su funcionamiento). Algunos autores llaman también a esta
forma de agregación “compartida” porque es posible que un objeto “parte
o contenido” corresponda a más de un objeto “todo o contenedor” Por
ejemplo:

Esta forma de graficar la agregación es opcional. No es obligatorio

determinar el tipo de agregación sobre todo durante el modelado de
requerimientos o análisis, pero es útil comprender el significado de ambas
y es más útil determinar concretamente el tipo de agregación en la
actividad de diseño.

Dependencia:

Este tipo de relación se define en el libro de UML como “una relación de

uso que declara que un cambio en la especificación de un elemento puede

20
afectar a otro elemento que la utiliza”, esto representa la dependencia que
tiene una clase de otra. (Booch, Rumbaugh y Jacobson, 1999)

Generalmente las dependencias se utilizan para indicar que una clase

utiliza a otra como argumento en la signatura de una operación, esto
significa que la clase dependiente obtiene visibilidad de la otra clase
porque recibe un objeto como parámetro de alguna operación. Esto es
claramente una relación de uso: si la clase utilizada cambia, la operación de
la otra clase puede verse también afectada, porque la clase utilizada puede
presentar ahora una interfaz o comportamientos diferentes.

Gráficamente estas relaciones se representan con una línea discontinua

dirigida hacia la clase de la cual se depende, como se muestra a
continuación:

Figura 13

La dependencia se utiliza para representar la visibilidad de parámetro. En

nuestro ejemplo CondicionPago se hace visible para Cuota porque un
objeto de esta última clase recibirá como parámetro de entrada para su
operación “calcularRecargo”, un objeto de la clase CondicionPago.

DIAGRAMA DE CLASES

Los diagramas de clases son los más utilizados en el modelado de sistemas

orientados a objetos. Un diagrama de clases muestra un conjunto de clases
así como sus relaciones.

Los diagramas de clases se utilizan para modelar la vista de diseño estática

de un sistema (ver el punto 2.1 Vistas de UML en este mismo módulo).
Principalmente esto incluye modelar el vocabulario del sistema. Un

diagrama de clases se puede utilizar para modelar las clases lógicas, que
son típicamente la clase de cosas de las que habla la gente de negocios de
una organización (los usuarios). En este caso se usa el diagrama de clases

21
para modelar el “dominio del problema” pero también se utiliza el
diagrama de clases para mostrar las clases de implementación, que son las
“cosas” con las que trabajan los programadores. Este enfoque se aplica a
partir de la actividad de Diseño de un sistema.

En un diagrama de clases podemos encontrar:

 Clases
 Relaciones: herencia, asociación (su variante: agregación), dependencia.
 Indicadores de multiplicidad y navegabilidad
 Nombre de Rol

En este diagrama podemos representar las clases indicando sólo su

nombre (en este caso sería un diagrama abreviado) o mostrando también
los atributos y/o operaciones.

A continuación se muestra un fragmento de un diagrama de clases uniendo

algunos de los ejemplos individuales ya vistos:

Simbología del Diagrama de Clases

En el gráfico que figura a continuación, se resumen todos los elementos

que pueden estar presentes en un diagrama de clases:

Figura 14

22
Metodologías estructuradas vs.
Metodologías Orientadas a
Objetos
El tema del carácter del software es tratado por Grady Booch entre otros
autores, al explicar que la “complejidad innata” del software se deriva de:

 La complejidad del dominio del problema.

 La dificultad de gestionar el proceso de desarrollo.

 La flexibilidad que se puede alcanzar a través del software.

 Los problemas de caracterizar el comportamiento de sistemas discretos.

La técnica para dominar la complejidad de un sistema es descomponerlo

en partes más y más pequeñas, cada una de las cuales se puede refinar en
forma independiente. Tenemos dos formas de descomponer un sistema
complejo:

Descomposición algorítmica: Es la forma de descomposición

sustentada por el análisis y diseño estructurado. En este
caso se divide el sistema en elementos funcionales
relacionados estructuralmente entre sí. Esta visión enfatiza
el orden de los eventos.

Descomposición orientada a objetos: En este caso la

descomposición consiste en determinar un conjunto de
agentes autónomos (objetos) que colaboran para llevar a
cabo algún comportamiento de nivel superior. Esta visión
resalta los agentes que causan acciones o son sujetos de
estas acciones.

En el libro “Lenguaje Unificado de Modelado” (ver bibliografía) se plantea

que una de las debilidades de las técnicas de análisis y diseño estructurado
es el hecho de que hay una desconexión básica entre el modelo de análisis
y el modelo de diseño del sistema; no poder salvar este abismo genera que
el sistema concebido y el sistema construido difieran a medida que

23
transcurre el tiempo. En los sistemas orientados a objetos, es posible
conectar todas las vistas casi independientes de un sistema en un todo
semántico.

Los métodos de diseño estructurado surgieron para guiar a los

desarrolladores que intentaban construir sistemas complejos utilizando los
algoritmos como bloques fundamentales para su construcción. El diseño
estructurado tiene un enfoque descendente: la unidad fundamental de
descomposición es el subprograma y se va modelando en forma de un
árbol de modo que cada subprograma realiza su función llamando a otros
subprogramas.

Por otro lado, el diseño estructurado no contempla los problemas de

abstracción de datos y ocultación de información, tampoco responde bien
al cambio de tamaño cuando se aplica a sistemas muy complejos.

Los métodos de diseño orientado a objetos surgieron para ayudar a los

desarrolladores a aprovechar la potencialidad de la programación
orientada a objetos que utiliza las clases y objetos como bloques básicos de
construcción. La descomposición orientada a objetos produce sistemas
más pequeños a través de la reutilización de mecanismos comunes; a su
vez los sistemas orientados a objetos son también más resistentes al
cambio y por lo tanto están mejor preparados para evolucionar en el
tiempo ya que su diseño está basado en formas intermedias estables.

24
Referencias
Bell Donald, “UML BasicsPart III: TheClassDiagram”, artículo publicado en el sitio
IBM Rational en Noviembre/2003.

Booch Grady, “Análisis y diseño orientado a objetos, con aplicaciones”, EE.UU,

Editorial Addison-Wesley Iberoamericana S.A., (1996). Capítulos: 1, 2, 3

Booch Grady, Rumbaugh James, Jacobson Ivar, (1999), “El lenguaje de

Modelado Unificado”, España, Editorial Addison Wesley Iberoamericana.
Capítulos: 1, 2, 4, 5, 8

Evans Gary, “Getting from Use. Case to code Part 1: Use Case Analysis”,
artículo publicado en el sitio IBM Rational en Julio/2004.

Jacobson Ivar, Booch Grady, Rumbaugh James, (2000), “El Proceso

Unificado de Desarrollo de Software”, España, Editorial Addison Wesley. Capítulos:
1, 3, 4, 5

Piattini Mario, Calvo-Manzano, Cervera, Fernández, (2004), “Análisis y Diseño de

aplicaciones informáticas de gestión. Una perspectiva de Ingeniería de Software”,
Alfaomega Grupo Editor. Capítulo: 4

Pressman Roger, (2006), “Ingeniería de Software. Un enfoque práctico”

6ta. edición, Ed. McGraw Hill.

25