Contenido

6.1. ASOCIACIONES......................................................................................................................3
1) Asociación binaria....................................................................................................................4
2) Asociación reflexiva..................................................................................................................4
6.3. Relaciones de dependencia...................................................................................................6
RELACION DE CLASE GENERALIZACION........................................................................................8
BIBLIOGRAFÍA......................................................................................................................12
Anexos........................................................................................................................................13
Introduccion

Sintácticamente, los lenguajes de programación permiten sólo dos tipos de relaciones

entre clases: de herencia, que ya hemos visto, y cliente-servidor. Por relación cliente-

servidor se entiende que un objeto (el cliente) pida a otro (el servidor), mediante un

mensaje, que ejecute una operación de las definidas en la clase del servidor. En lo que

respecta al análisis y el diseño, se consideran otros tipos de relaciones, porque las

relaciones cliente-servidor son demasiado simples para describir el mundo real.

Desacuerdo entre autores y el estándar de tipo relación Lamentablemente, no existe

acuerdo entre los autores más importantes sobre cuáles son estos tipos (y menos todavía

sobre su semántica y notación). Sin embargo, si el UML, convertido en estándar, se

acaba imponiendo, es probable que su versión sea aceptada por todos o casi todos. No

obstante, si el UML permite modelar gráficamente diferentes tipos de relaciones entre

clases (agregación, asociación y uso), el significado de cada uno no queda concretado

en los documentos oficiales del OMG y, por lo tanto, la decisión sobre cuándo se debe

aplicar un tipo de relación u otro será a menudo una interpretación personal.
6.1. ASOCIACIONES
Dentro de este subapartado veremos los conceptos y terminología utilizados para

designar las asociaciones y los diferentes tipos existentes.

6.1.1. Concepto y terminología

Hay una asociación entre clases cuando una clase necesita otra u otras para la

implementación de sus operaciones, lo cual se cumple por medio del paso de mensajes

entre éstas. Una asociación se define partiendo de la clase, y se concreta en la existencia

de enlaces (en inglés, links ) entre objetos concretos de las clases relacionadas por la

asociación.

Dentro de una asociación, se considera que cada clase desempeña un papel (en inglés,

role ) determinado; cada papel tiene asociada una cardinalidad . Entre las mismas clases

puede haber asociaciones diferentes con significado distinto. Una asociación puede

tener nombre, que sirve para identificar su significado, y también se puede dar un

nombre a cada uno de los papeles de las clases.

6.1.2. Asociaciones binarias y n-arias

Asociaciones binarias son las que tienen lugar entre dos clases. Las dos clases pueden

ser la misma (asociación reflexiva), y en este caso es posible permitir que un objeto esté

enlazado consigo mismo o que no lo esté. En una asociación binaria, la cardinalidad de

un papel A es el número de objetos del otro papel B al que puede estar enlazado cada

objeto de A; se indica el valor máximo y mínimo de este número.

Ejemplos de asociaciones binaria y reflexiva
1) Asociación binaria
Como se puede apreciar en la siguiente asociación binaria:

La asociación significa que una persona trabaja en una empresa (no al revés, observad el

sentido indicado por la punta de flecha coloreada); la empresa es la que ofrece el

empleo y la persona desempeña el papel de empleado. Cada persona concreta puede

tener una empresa que ofrece el empleo o ninguna, mientras que una empresa puede

tener un empleado como mínimo y cualquier número como máximo, según indican las

cardinalidades.

La punta de flecha abierta encima de la línea de la asociación indica que se puede

acceder (navegar) de una empresa hacia sus empleados.

2) Asociación reflexiva
Consideremos la figura siguiente:

El significado de esta asociación es que un trabajador depende de un jefe; tanto el jefe

como el subordinado son trabajadores. Cada trabajador puede tener como máximo un
jefe, mientras que un jefe puede tener cualquier número de subordinados (el asterisco

solo indica que el número puede ser cualquiera, incluso el cero). Un trabajador no puede

ser jefe de sí mismo, pero eso no lo indica la notación gráfica.

Una relación ternaria es aquella que tiene tres papeles, y en general una relación n-aria

es la que tiene n papeles. Las relaciones no binarias, ya que no se pueden representar

mediante una línea, se representan por medio de un rombo.

Ejemplo de asociación ternaria

Observemos la siguiente asociación:

Un chófer determinado puede conducir un autocar determinado en cualquier número de

excursiones (“0..*” es equivalente a “*”), pero en una excursión concreta, un chófer

sólo puede conducir un autocar, y en una excursión en particular, un autocar sólo puede

tener un chófer.

El establecimiento de enlaces según una asociación El establecimiento de enlaces entre

objetos según una asociación puede ser una operación de alguna de las clases asociadas,

igual que la navegación de un objeto a otro enlazado a éste.
El significado de la Cardinalidad en una asociación ternaria es el siguiente: la

Cardinalidad del papel A expresa los límites al número de objetos de A que pueden estar

enlazados en cada combinación concreta de un objeto del papel B y otro del papel C.

6.3. Relaciones de dependencia
Una relación de dependencia expresa que un elemento del modelo –denominado

cliente– depende para su implementación o funcionamiento de otro elemento –

denominado suministrador (en inglés, supplier).

El símbolo de una relación de dependencia es una flecha de línea discontinua y punta

abierta.

Existen diferentes estereotipos estándar:

 Derive : significa que un elemento se obtiene de otro por medio de un cálculo o

algoritmo;
 Friend : da acceso al cliente a los elementos de visibilidad private contenidos en

el suministrador;
 Refine : quiere decir que el cliente procede históricamente del suministrador, del

cual es una versión nueva o enriquecida (por ejemplo, una clase descrita en el

análisis en el que se realizan cambios en el diseño);
 trace : relaciona elementos que corresponden desde un punto de vista semántico

al mismo concepto, como por ejemplo un elemento y su implementación;
 call, create y send ;
 extend e include : que existen sólo entre casos de uso.

Representa un tipo de relación muy particular, en la que una clase es instanciada (su

instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene

una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la
creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el

objeto Aplicacion):

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena

dentro del objeto que lo crea (en este caso la Aplicación).
RELACION DE CLASE GENERALIZACION

Indica que una subclase hereda los métodos y atributos especificados por una Super

Clase, por ende, la Subclase además de poseer sus propios métodos y atributos, poseerá

las características y atributos visibles de la Super Clase, ejemplo:

La Generalización es un tipo de relación por herencia, la cual indica una clase que tiene

muchos objetos, entre estas, estos objetos podrían tener comportamientos y atributos

parecidos.

En esta podremos destacar los siguientes puntos:
- La generalización es una relación de tipo es un, ya que cada instancia de una subclase

es además una instancia de la superclase.

- La generalización facilita el modelado estructurando clases y capturando lo que es

similar y lo que es diferente entre las clases.

- La herencia de operaciones resulta de ayuda durante la implementación como un

medio de reutilización de código.

- Los términos herencia, generalización y especialización se refieren a aspectos de la

misma idea y a menudo se usan indistintamente.

- Usamos generalización para hacer referencia a la relación entre las clases.

- Herencia se refiere al mecanismo por el que se comparten atributos y operaciones

usando la relación de generalización.

- Generalización y especialización son dos perspectivas diferentes de la misma relación,

observada desde la superclase o desde la subclase.

- La palabra generalización deriva de que la superclase generaliza a las subclases y

especialización se refiere a que las subclases perfeccionan o especializan a la

superclase.

Una clase descendiente no puede omitir ni suprimir un atributo del ancestro, ya que

entonces no sería una instancia del ancestro. Igualmente, las operaciones sobre la clase

ancestro deben aplicarse a todas las clases descendientes. Una subclase puede añadir

nuevas características (extensión).
- Una subclase puede implementar de nuevo una operación por razones de eficiencia

pero no puede cambiar el protocolo externo.

-Hay varias razones para desear redefinir un aspecto de una clase:

- Especificar un comportamiento que depende de la subclase.

- Ajustar la especificación de ese aspecto.

- Conseguir mejor rendimiento
Ejemplo aplicado:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee

las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que

es Descapotable, en cambio Camión también hereda las características de Vehículo

(Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método Características

aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición publica, en

cambio atributos como Descapotable no son visibles por ser privados.
BIBLIOGRAFÍA

Campderrich, F. B. (2003). Ingeniería del software. Barcelona, ES: Editorial UOC.

Retrieved

http://site.ebrary.com/lib/uagrariaecsp/detail.action?docID=10646149

Kimmel, P. (2008). Manual de UML. México, D.F., MX: McGraw-Hill Interamericana.

http://site.ebrary.com/lib/uagrariaecsp/detail.action?docID=10433806

Departamento de Ciencias de La Computación de la Universidad de Chile
https://users.dcc.uchile.cl/~psalinas/uml/modelo.html
Universidad San Martin De Porres
http://www.usmp.edu.pe/publicaciones/boletin/fia/info67/UML.pdf

Gutierrez, C. C. (2011). Casos prácticos de UML. Madrid, ES: Editorial Complutense.
http://site.ebrary.com/lib/uagrariaecsp/reader.action?docID=10536104
Anexos