UNIDAD 2 RELACIONES DE OBJETOS. DIAGRAMA DE CLASES

Programación Orientada a Objetos
Analista Programador Universitario Plan 2008
Año 2010
UNIDAD 2
RELACIONES ENTRE OBJETOS
DIAGRAMA DE CLASES UML
INTRODUCCION
Un concepto fundamental que debemos tener en cuenta a la hora de modelar la realidad por medio
de objetos es que los mismos no son entidades aisladas. Los objetos interactúan entre ellos
constantemente por medio de mensajes. De esta forma se definen las responsabilidades de los
objetos. Es decir, cuando modelamos una realidad y abstraemos de ellas objetos definimos
principalmente sus responsabilidades. Una responsabilidad es una descripción de lo que de lo que
hará el objeto.
En otras palabras al modelar determinamos objetos y para cada uno de ellos primero definimos su
“contrato u obligación”. Esta obligación o contrato en los objetos representa que información es
valiosa y/o que operaciones (o sea sus atributos y operaciones) se necesitan de ese objeto.
Cada objeto tiene al menos una responsabilidad y no debería poseer una “gran cantidad” de
responsabilidades. ¿Por qué? Porque esto indicaría que es probable que de una misma clase se
pueda crear otras clases, por lo cual se podría distribuir las responsabilidades entre las nuevas
clases.
Dijimos que los objetos interactúan entre ellos, que no son entidades aisladas. Por lo tanto solicitan a
través de los mensajes algunas de las responsabilidades de los otros objetos. Esta interacción
provoca un vínculo o conexión entre los objetos. Esta conexión se denomina relación.
Una relación es una conexión semántica entre objetos (es decir podemos claramente identificarla por
una frase, como veremos más adelante) y proveen un camino de comunicación entre los objetos.
Existen diversos tipos de relaciones entre objetos. En esta sección daremos sus conceptos y luego
en esta misma unidad al ver los diagramas de clases de UML se especificarán las notaciones de los
mismos
RELACIÓN DE ASOCIACIÓN
Es una relación que se da cuando existe un vínculo conceptual entre objetos. Se podría decir que es
una relación que se da cuando un objeto necesita algo de la otra, entonces de esta forma se
establece el vínculo. La notación semántica usual que se utiliza es “está conectado” o “se asocia”.
Esto sólo sirve para identificar la asociación, ya que normalmente a la asociación se le establece la
palabra real que se utiliza para la asociación
Ejemplos:
Una persona enciende el televisor. En esta relación fijarse que se da la situación de que una persona
(que es un objeto) quiere ver televisión. Por lo tanto para ello necesita prenderla. Entonces el vínculo
entre ellas es que la persona puede encender el televisor para poder ver televisión.
Además entre objetos puede haber más de un vínculo de asociación. En el ejemplo anterior la
persona no solo está vinculada a la televisión por la relación Encender, sino que posee por ejemplo:
Apagar, Cambiar de Canal, Configurar.
Otro ejemplo: Observe la imagen
Ariel Alejandro Vega
13
Programación Orientada a Objetos
Analista Programador Universitario Plan 2008
Año 2010
UNIDAD 2
RELACIONES ENTRE OBJETOS
DIAGRAMA DE CLASES UML
Tom (que es un objeto de la clase Persona) está vinculado con Bill (otro objeto de la misma clase) de
dos formas: resulta que ambos trabajan en el mismo lugar y después de un tiempo se hicieron
amigos. Por lo tanto Tom es colaborador de Bill y, además Tom es amigo de Bill.
Por otro lado observen que el vínculo es verdadero leído desde ambos extremos. Es decir Bill
también es colaborador y amigo de Tom, aunque esto podría no ser verdad, a lo mejor Tom lo
considera amigo a Bill, pero no ocurre lo mismo con Bill. Ya veremos que existen formas de indicar si
el vínculo es unidireccional (se establece en un solo sentido) o bidireccional (se establece en ambos
sentidos)
Un ejemplo más: Observe la imagen
Aquí podemos ver que un objeto se puede relacionar con más de un objeto. Por ejemplo Juan viaja a
su trabajo en auto. Pero resulta que el día de hoy el auto no arrancó porque se agotó su batería.
Entonces tuvo que viajar en colectivo. Esto quiere decir que se establece un nuevo vínculo de
asociación entre Juan y el Colectivo. Además fijarse que la relación de asociación puede o no darse
al mismo tiempo. En este caso diríamos que no es al mismo tiempo, pero en otros ejemplos si puede
existir. Por ejemplo supongamos que Juan atiende una llamada en el colectivo, entonces se
establece un vínculo entre Juan y su celular. Juan habla por Celular. Y esto ocurre al mismo tiempo
que Juan viaja en colectivo.
Y para finalizar con asociaciones, otro ejemplo más:
Ariel Alejandro Vega
14
Programación Orientada a Objetos
Analista Programador Universitario Plan 2008
Año 2010
UNIDAD 2
RELACIONES ENTRE OBJETOS
DIAGRAMA DE CLASES UML
Aquí vemos que un alumno puede estar inscripto a varias asignaturas (2 en este caso). A su vez la
materia puede considerarse un objeto y obviamente posee al menos un alumno, es decir se podría
considerar un conjunto de alumnos. Y finalmente tenemos 2 profesores, el Prof. A imparte
únicamente POO y el Prof. B imparte ambas materias. En pocas palabras podemos indicar con la
asociación la cantidad de objetos de una Clase que está asociado a otro objeto de otra clase. Este
concepto recibe el nombre de multiplicidad.
Resumiendo:
•
•
•
•
La relación de asociación permite indicar un vínculo entre dos o más objetos. En términos de
objetos se dice que un objeto se asocia a otro. Por ejemplo: Si una persona llama usando su
celular, en objetos se dice que la persona se asocia al celular.
La frase usual es “se asocia” o “se conecta”, que luego es representada por la frase real, por
ejemplo: Persona utiliza Celular.
La relación puede ser unidireccional o bidireccional
En esta relación se puede indicar la cantidad de objetos a la cual otro objetos se asocia. Esto
se llama multiplicidad.
LA ASOCIACIÓN DE AGREGACIÓN
La agregación es una relación muy importante en el mundo del modelado de objetos. Básicamente
podemos de decir que un objeto puede estar conformado por otros objetos. Imaginemos nuestra
habitación. Nuestra habitación está conformada mínimamente por una cama, tal vez un escritorio,
algún mueble, el ropero, etc. Ahora bien estos muebles son también objetos. Por lo tanto un objeto
puede estar conformado por otros objetos, formando un nuevo objeto (recordar que todo objeto es
único por la identidad de los objetos)
Otro ejemplo: un objeto sándwich, estará conformado por pan, lomito, huevo, jamón, quizás queso,
etc. Estos ingredientes son otros objetos. Nuevamente un objeto está conformado por otros objetos,
formando un objeto completamente nuevo.
Una agregación es un tipo específico de relación de asociación. Básicamente la agregación es
aquella relación que permite que un objeto sea compuesto/descompuesto en otros objetos.
La notación semántica que permite identificar relaciones de agregación es la frase “forma parte de”
o “formado por”.
Mencioné que esta relación es muy importante, ¿Porqué? Imaginemos el siguiente escenario:
Cuando se trata de escribir o leer desde una unidad de CD, se considera la unidad de CD como un
objeto individual. También se puede analizar cómo interactúa la unidad de CD con el sistema de la
computadora personal; los sistemas de computación también se tratan como un objeto individual.
Ariel Alejandro Vega
15
Programación Orientada a Objetos
Analista Programador Universitario Plan 2008
Año 2010
UNIDAD 2
RELACIONES ENTRE OBJETOS
DIAGRAMA DE CLASES UML
Si se llama a un ingeniero para que repare un problema de una unidad de CD, su perspectiva de la
unidad de CD es más detallada. El ingeniero examina el motor de giro de la unidad de CD, la bandeja
de la unidad y el haz de láser o el lector.
Cada uno de estos elementos es un componente del objeto unidad de CD y es un objeto por sí
mismo. Las distintas perspectivas sobre la unidad de CD son igualmente válidas y cada una se
puede expresar en momentos diferentes.
Al trabajar con objetos, resulta útil emplear un nivel de abstracción lo más alto posible. De este modo,
puede conceptualizar mejor los objetos importantes y entender mejor cómo funciona el sistema.
Hasta aquí lo que se comentó, ¿qué me aporta?:
1. Hemos delimitado la perspectiva de del sistema a la parte que nos interesa. Si no funciona la
lectora llamamos al técnico y él se limita a reparar la unidad lectora, él no intentaría ver el
procesador para saber qué pasó la lectora.
2. Si queremos colocar una lectora de DVD en lugar de una de DVD, simplemente sacamos la
lectora de CD y colocamos la otra. De esta forma vemos que trabajar con agregación de
objetos podemos facilitar la integración, sin embargo esto requiere un buen mecanismo de
integración. En el caso de la lectora, todo está preparado para que podamos reemplazar una
lectora por otra. En los sistemas que realicemos esta facilidad la debemos poder implementar
usando algún mecanismo: usar objetos facilita esta operación porque recordemos que cada
objeto encapsula su responsabilidad, además con el uso de interfaces, es posible desacoplar
aún más la funcionalidad. Entonces los objetos se pueden comportar como componentes. Y
cada componente es un objeto. Esto simplifica mucho la tarea. Por ejemplo en el caso de la
lectora: luego de instalar la nueva lectora es probable que el sistema detecte la configuración
más eficiente de usarla porque el sistema simplemente usará la interface de la lectora, es
decir no se conecta directamente al funcionamiento electrónico, esto es lo que permite
colocar cualquier lectora.
3. En caso de que pudiéramos mejorar el funcionamiento de nuestra lectora, podemos hacerlo
sin afectar al resto del sistema. En nuestro caso real, no podemos hacerlo, porque no somos
técnicos, ni siquiera los técnicos pueden hacerlo, porque las lectoras vienen de fábrica. Pero
la idea central es esa, que al dividir un objeto en otros objetos, Podemos mejorar o modificar
cada uno de ellos sin afectar a los otros, ya que el mecanismo de integración estaría
asegurado.
De todas formas estas ventajas serán evidentes a la hora de programar, así que lo importante es
entender el concepto de agregación.
LA ASOCIACIÓN DE COMPOSICIÓN
La relación de composición es un tipo de agregación con un vínculo muy fuerte, de tal modo que no
se puede concebir que exista un objeto compuesto fuera del todo al que pertenece.
Ariel Alejandro Vega
16
Programación Orientada a Objetos
Analista Programador Universitario Plan 2008
Año 2010
UNIDAD 2
RELACIONES ENTRE OBJETOS
DIAGRAMA DE CLASES UML
Por ejemplo: Un tablero de ajedrez está compuesto por 64 casillas, es decir hay una relación de
agregación entre tablero y las casillas, las 64 casillas forman el tablero; por otro lado si hacemos que
desaparezca el tablero las casillas también desaparecerán.
Otro ejemplo: Una guitarra está compuesta por 6 cuerdas, el diapasón, el clavijero y la caja de
resonancia. Si desaparece la guitarra los elementos no tienen sentido fuera de ella.
Una última aclaración sobre las relaciones de agregación y de composición: Como distinguir si una
relación es de agregación o de composición. Existen algunos puntos clave:
En la relación de agregación un objeto componente (se dice objeto compuesto) puede llegar a
pertenecer a más de un objeto “todo” (por ejemplo un control remoto universal puede formar parte del
televisor y del reproductor de dvd) mientras que en la composición sí o sí un objeto componente
pertenece un objeto de una clase a la vez.
LA RELACIÓN DE GENERALIZACIÓN
En la unidad 1 se presentaron las propiedades de los objetos. Uno de ellas es la herencia. La
herencia es también un tipo de relación entre objetos. Por lo tanto es importante considerar la
importancia de la herencia, no sólo como una propiedad, sino como una relación entre objetos. Al
igual que la agregación y la composición la generación (o especialización) de los objetos resulta ser
fácil de representar con los objetos.
La generalización clarifica el diseño y mejora la productividad.
La notación semántica para representar objetos es la frase “es un tipo de” o “es una”.
OTRAS RELACIONES DE INTERÉS
•
•
La realización: Es una relación de contrato con otra clase. Se utiliza para implementar
clases. Supongamos que definimos que tenemos una Clase que representa una colección de
personas. Supongamos que el sistema debe permitir la consulta por dni o nombre y no se
permite que no estén presentes estas consultas. Además no se permite ningún otro tipo de
consulta. Con esta relación definimos un objeto que es el contrato el cual otro objeto debe
respetar. Generalmente se utilizan para las denominadas interfaces. Supongamos que para
el ejemplo anterior. Definimos una interfaz que se llama ConsultadorDePersonas (el cual
posee las operaciones buscarPorDni y buscarPorNombre) y tenemos la clase Persona,
entonces la relación sería Persona “implementa” ConsutadorDePersonas.
La Dependencia: Es una relación de uso. Es decir una clase utiliza otra clase. Y si esta
última se altera, la anterior se puede ver afectada. En cambio si la primera se modifica sus
cambios no afectan a la segunda. Este tipo de relación provoca lo que se denomina
acoplamiento, el cual debe ser en lo posible evitado. La notación semántica es la frase “usa”
Existen diversos tipos de casos de dependencia, los cuales serán detallados posteriormente
en esta misma unidad. Por ejemplo se suele utilizar para indicar que una aplicación invoca a
otra y se genera entonces una ventana, es decir desde una ventana se invoca a otra
ventana, para ello es necesario que la aplicación genere un objeto de la clase Ventana y
entonces mostrarla. Si por alguna razón modificamos la ventana esto puede afectar a la
aplicación, en cambio si modificamos la aplicación la clase Ventana se mantiene igual.
UML Y EL DIAGRAMA DE CLASES
UML es una herramienta para modelar aspectos de un desarrollo de software (aunque no solo se
limita al software) que es el resultado de varias experiencias que fueron integradas y modificadas por
el aporte de diversos autores y empresas que conformaron lo que se conoce el Consorcio de UML.
Sus padres oficialmente reconocidos son: Grady Booch, James Rumbaugh e Ivar Jacobson.
Cada uno de ellos en sus diversas experiencias de desarrollo creó sus propias metodologías de
desarrollo y aportaron la creación de diversos modelos para el análisis y diseño orientado a objetos.
Ariel Alejandro Vega
17
Programación Orientada a Objetos
Analista Programador Universitario Plan 2008
Año 2010
UNIDAD 2
RELACIONES ENTRE OBJETOS
DIAGRAMA DE CLASES UML
La empresa Rational terminó sumando a sus filas a estos 3 desarrolladores, entonces ellos apostaron
a unificar los diversos modelos que crearon, de esta experiencia surgió UML (Lenguaje de Modelado
Unificado).
A la propuesta original o anteproyecto de UML se le sumaron numerosas modificaciones como
respuesta a las reacciones del “mercado” las cuales fueron acertadamente aceptadas, con lo cual
tuvo una amplia retroalimentación.
En 1997, con el aporte de los númerosos miembros del Consorcio de UML (DEC, Microsoft, HP,
Intellicorp, Oracle, Rational, entre otros) se produjo la versión 1.0 de UML y se puso a disposición de
la OMG.
Desde entonces con diversas modificaciones y evoluciones UML se ha convertido en el Estándar que
recomienda la OMG (Group Management Objetcs) para la Industria del Software.
Lo que ofrece UML es un conjunto de diagramas conformados por elementos gráficos. Cada
diagrama puede modelar uno o varios aspectos del software y pueden llegar a ser más o menos
útiles dependiendo de la etapa del ciclo de desarrollo en la que se el grupo de desarrollo se
encuentre.
UML es un Lenguaje porque define reglas que dirigen la forma en que deben combinarse los
componentes
Entonces lo importante es conocer para qué cosa funciona cada diagrama, y luego ver la notación
que se puede utilizar. Incluso UML permite cierta libertad a la hora de usar los elementos de cada
Diagrama, para poder incluso combinarlos.
No es el objetivo de la asignatura estudiar UML, sin embargo dado que se realizó una introducción al
modelado orientado a objetos, la definición de los objetos, sus propiedades y relaciones, resulta
apropiado utilizar un modelo para representar las clases, algunas de sus propiedades y las
relaciones. UML aporta un modelo ampliamente utilizado por los desarrolladores para modelar las
clases denominado Diagrama de Clases.
El Diagrama de Clases es un diagrama del tipo estático (dado que no refleja la interacción entre las
clases, simplemente refleja la estructura del mismo, como si fuera una foto).
En el Diagrama de Clases una clase puede representarse de 3 formas:
•
Como un rectángulo, es este caso solo se representa el nombre de la clase. Por ejemplo
•
Como un rectángulo dividido en dos partes, en este caso se representa el nombre de la clase
y sus atributos u operaciones. Por ejemplo
•
Como un rectángulo dividido en 3 partes, en este caso se representa el nombre de la clase,
sus atributos y sus operaciones. Observe que las operaciones son acciones que inician con
un verbo en infinitivo seguido de un paréntesis. Por ejemplo
El Diagrama de Clases puede ser utilizado en cualquier ciclo de vida del desarrollo de un sistema
(típicamente análisis, diseño, implementación, prueba, mantenimiento). En cada una de estas fases
Ariel Alejandro Vega
18
Programación Orientada a Objetos
Analista Programador Universitario Plan 2008
Año 2010
UNIDAD 2
RELACIONES ENTRE OBJETOS
DIAGRAMA DE CLASES UML
puede adoptar nuevos conceptos. Por ejemplo en el análisis y diseño nosotros podemos indicar que
un atributo es numérico, fecha, o cadena de caracteres. Mientras que en la implementación nosotros
podemos indicar el tipo de dato del atributo según el lenguaje de programación.
La visibilidad
En el Diagrama de Clases de UML nosotros podemos indicar la visibilidad de los atributos y de las
operaciones.
La visibilidad permite definir el grado en el cual un atributo u operación estará disponible para que
sea usado por otras clases. Por tal razón la visibilidad está relacionada con la relación de realización.
Existen 3 tipos o niveles de visibilidad:
• Público (+): en este nivel de visibilidad el atributo u operación de una clase está disponible
para todas las demás clases. Esto es, una clase cualquiera puede leer o asignar valores al
atributo de clase que es definido como público. De la misma forma cualquier clase puede
invocar una operación que ha sido definida como pública.
• Protegido (#): en este nivel de visibilidad el atributo u operación de una clase está disponible
únicamente para sus subclases.
• Privado (-): en este nivel de visibilidad el atributo u operación de una clase no está
disponible para ninguna otra clase. Solo pueden ser usadas por las operaciones de la misma
clase.
He aquí algunos ejemplos de visibilidad de atributos y operaciones
En el caso de la Clase Televisión se puede observar que tiene 2 atributos públicos, dado que la
marca y el modelo son características que deben estar disponibles para cualquier otra clase
También debería ser posible que cualquier clase pueda modificar el volumen de la Televisión. Sin
embargo la operación colorearImagenEnPantalla() es una operación interna.
En el caso de la Clase Automovil tiene una operación protegida llamada actualizarKilometraje().
Observe que cualquier subclase de Automovil puede usar esta operación con lo cual se evita la
necesidad de volver a crear esta operación en cada subclase.
La Generalización
La generalización se representa mediante una flecha dirigida desde la subclase hasta su superclase.
En la unidad uno se usó esta notación para representar el concepto de herencia.
La generalización permite que una clase “hija” herede todos los atributos y propiedades de
la clase “madre”. Por ejemplo las clases vertebrados e invertebrados pueden heredar de animal.
Observe que únicamente se está representando la herencia a nivel de nombres de clases. En este
caso se habla de generalización porque la superclase posee los atributos y operaciones comunes de
todas sus hijas.
Pero además la herencia permite lo que se denomina especialización. Esto es, una hija puede
agregar atributos y operaciones no contemplados en la superclase y puede modificar las operaciones
definidas en la superclase de acuerdo a sus necesidades “específicas”.
Ariel Alejandro Vega
19
Programación Orientada a Objetos
Analista Programador Universitario Plan 2008
Año 2010
UNIDAD 2
RELACIONES ENTRE OBJETOS
DIAGRAMA DE CLASES UML
La Asociación
En el diagrama de clases la asociación se representa mediante una línea que une dos clases.
Comúnmente se escribe en la línea una frase que representa la asociación. Cuando se realiza de
esta forma se dice que la asociación es bidireccional, es decir la relación es en ambos sentidos.
A veces puede que la asociación sea unidireccional. En ese caso la misma se puede representar de
dos formas: haciendo que la línea sea una flecha que indique la dirección
O usando lo que se denomina navegadores. Por ejemplo
Cualquiera de las dos opciones es válida.
También es posible indicar el papel de cada una de las clases que intervienen en la relación. Para
ello se coloca el papel en el extremo de cada clase. Por ejemplo
También en la relación de asociación es posible establecer la multiplicidad. La multiplicidad indica la
cantidad de objetos de una clase que se relacionan con el objeto de una clase asociada. Existe una
diversidad de notaciones para la multiplicidad, los cuales son indicados a continuación:
A continuación se describen varios ejemplos de multiplicidad
Ariel Alejandro Vega
20
Programación Orientada a Objetos
Analista Programador Universitario Plan 2008
Año 2010
UNIDAD 2
RELACIONES ENTRE OBJETOS
DIAGRAMA DE CLASES UML
La Agregación
Se representa mediante un rombo que señala cual es la clase que está conformada por otras clases.
Se pueden aplicar las reglas de la multiplicidad.
La Composición
Se representa mediante un rombo relleno que señala cual es la clase que está conformada por otras
clases. Se pueden aplicar las reglas de la multiplicidad.
•
•
Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las
referencias).
Cuando se destruye el Objeto Almacen también son destruidos los objetos Cuenta
asociados, en cambio no son afectados los objetos Cliente asociados.
Dependencias
La dependencia se establece mediante una flecha punteada. Para el ejemplo de la aplicación que
instancia una ventana, sería
Cabe destacar que la instanciación no es el único ejemplo de dependencia.
Otros caso de dependencia aparece cuando una operación recibe como parámetro un objeto y por lo
tanto la operación depende del tipo de parámetro que reciba. Por ejemplo: supongamos que estamos
Ariel Alejandro Vega
21
Programación Orientada a Objetos
Analista Programador Universitario Plan 2008
Año 2010
UNIDAD 2
RELACIONES ENTRE OBJETOS
DIAGRAMA DE CLASES UML
ante una aplicación y que se debe mostrar un formulario en una ventana, el cual será elegido desde
un menú de opciones. Esto se puede representar de esta forma
Donde la operación implementada sería así mostrarFormulario(f:Form) y Form representa un tipo de
formulario específico.
La Realización
La realización se representa mediante una línea punteada con una flecha sin relleno. Por ejemplo
supongamos que Tenemos una clase Persona y tenemos una Clase Factura. Ambas deben poseer
una operación que les permita ordenar personas por nombre y facturas por fecha. Imagine entonces
un contrato que define la operación ordenar mediante una Interfaz denominada Ordenacion.
Entonces ambas clases deben implementar este contrato. Cada una en su forma específica realiza la
operación ordenar() pero no puede obviarla o evitarla. Tampoco se permite que realicen otra
operación. También observe que la interfaz tiene un identificador <<interfaz>> que indica que es una
interfaz. Este identificador se denomina estereotipo. Otra forma de representar la interfaz es colocar
es iniciar el nombre de la Clase con la letra I. En el ejemplo sería IOrdenacion el nombre de la
interfaz.
BIBLIOGRAFIA
•
•
•
UML y Patrones de Diseño. Una introducción al análisis y diseño orientado a objetos y al
proceso unificado. Segunda Edición. Pearson Prentice Hall.
Aprendiendo UML en 24 horas. Joseph Schmuller. Prentice Hall.
Oracle 10g. Programación JAVA. Guía del Alumno Volúmen 1. Jeff Gallus.
Ariel Alejandro Vega
22