You are on page 1of 14

Contenido

6.1. ASOCIACIONES......................................................................................................................3
1) Asociacin binaria....................................................................................................................4
2) Asociacin reflexiva..................................................................................................................4
6.3. Relaciones de dependencia...................................................................................................6
RELACION DE CLASE GENERALIZACION........................................................................................8
BIBLIOGRAFA......................................................................................................................12
Anexos........................................................................................................................................13
Introduccion

Sintcticamente, los lenguajes de programacin permiten slo dos tipos de relaciones

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

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

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

respecta al anlisis y el diseo, se consideran otros tipos de relaciones, porque las

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

Desacuerdo entre autores y el estndar de tipo relacin Lamentablemente, no existe

acuerdo entre los autores ms importantes sobre cules son estos tipos (y menos todava

sobre su semntica y notacin). Sin embargo, si el UML, convertido en estndar, se

acaba imponiendo, es probable que su versin sea aceptada por todos o casi todos. No

obstante, si el UML permite modelar grficamente diferentes tipos de relaciones entre

clases (agregacin, asociacin y uso), el significado de cada uno no queda concretado

en los documentos oficiales del OMG y, por lo tanto, la decisin sobre cundo se debe

aplicar un tipo de relacin u otro ser a menudo una interpretacin personal.


6.1. ASOCIACIONES
Dentro de este subapartado veremos los conceptos y terminologa utilizados para

designar las asociaciones y los diferentes tipos existentes.

6.1.1. Concepto y terminologa

Hay una asociacin entre clases cuando una clase necesita otra u otras para la

implementacin de sus operaciones, lo cual se cumple por medio del paso de mensajes

entre stas. Una asociacin se define partiendo de la clase, y se concreta en la existencia

de enlaces (en ingls, links ) entre objetos concretos de las clases relacionadas por la

asociacin.

Dentro de una asociacin, se considera que cada clase desempea un papel (en ingls,

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

puede haber asociaciones diferentes con significado distinto. Una asociacin puede

tener nombre, que sirve para identificar su significado, y tambin 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 (asociacin reflexiva), y en este caso es posible permitir que un objeto est

enlazado consigo mismo o que no lo est. En una asociacin binaria, la cardinalidad de

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

objeto de A; se indica el valor mximo y mnimo de este nmero.

Ejemplos de asociaciones binaria y reflexiva


1) Asociacin binaria
Como se puede apreciar en la siguiente asociacin binaria:

La asociacin significa que una persona trabaja en una empresa (no al revs, observad el

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

empleo y la persona desempea 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 mnimo y cualquier nmero como mximo, segn indican las

cardinalidades.

La punta de flecha abierta encima de la lnea de la asociacin indica que se puede

acceder (navegar) de una empresa hacia sus empleados.

2) Asociacin reflexiva
Consideremos la figura siguiente:

El significado de esta asociacin es que un trabajador depende de un jefe; tanto el jefe

como el subordinado son trabajadores. Cada trabajador puede tener como mximo un
jefe, mientras que un jefe puede tener cualquier nmero de subordinados (el asterisco

solo indica que el nmero puede ser cualquiera, incluso el cero). Un trabajador no puede

ser jefe de s mismo, pero eso no lo indica la notacin grfica.

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

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

mediante una lnea, se representan por medio de un rombo.

Ejemplo de asociacin ternaria

Observemos la siguiente asociacin:

Un chfer determinado puede conducir un autocar determinado en cualquier nmero de

excursiones (0..* es equivalente a *), pero en una excursin concreta, un chfer

slo puede conducir un autocar, y en una excursin en particular, un autocar slo puede

tener un chfer.

El establecimiento de enlaces segn una asociacin El establecimiento de enlaces entre

objetos segn una asociacin puede ser una operacin de alguna de las clases asociadas,

igual que la navegacin de un objeto a otro enlazado a ste.


El significado de la Cardinalidad en una asociacin ternaria es el siguiente: la

Cardinalidad del papel A expresa los lmites al nmero de objetos de A que pueden estar

enlazados en cada combinacin concreta de un objeto del papel B y otro del papel C.

6.3. Relaciones de dependencia


Una relacin de dependencia expresa que un elemento del modelo denominado

cliente depende para su implementacin o funcionamiento de otro elemento

denominado suministrador (en ingls, supplier).

El smbolo de una relacin de dependencia es una flecha de lnea discontinua y punta

abierta.

Existen diferentes estereotipos estndar:

Derive : significa que un elemento se obtiene de otro por medio de un clculo o

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

el suministrador;
Refine : quiere decir que el cliente procede histricamente del suministrador, del

cual es una versin nueva o enriquecida (por ejemplo, una clase descrita en el

anlisis en el que se realizan cambios en el diseo);


trace : relaciona elementos que corresponden desde un punto de vista semntico

al mismo concepto, como por ejemplo un elemento y su implementacin;


call, create y send ;
extend e include : que existen slo entre casos de uso.

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

instanciacin es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso ms particular de este tipo de relacin es para denotar la dependencia que tiene

una clase de otra, como por ejemplo una aplicacin grafica que instancia una ventana (la
creacin del Objeto Ventana esta condicionado a la instanciacin proveniente desde el

objeto Aplicacion):

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

dentro del objeto que lo crea (en este caso la Aplicacin).


RELACION DE CLASE GENERALIZACION

Indica que una subclase hereda los mtodos y atributos especificados por una Super

Clase, por ende, la Subclase adems de poseer sus propios mtodos y atributos, poseer

las caractersticas y atributos visibles de la Super Clase, ejemplo:

La Generalizacin es un tipo de relacin por herencia, la cual indica una clase que tiene

muchos objetos, entre estas, estos objetos podran tener comportamientos y atributos

parecidos.

En esta podremos destacar los siguientes puntos:


- La generalizacin es una relacin de tipo es un, ya que cada instancia de una subclase

es adems una instancia de la superclase.

- La generalizacin 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 implementacin como un

medio de reutilizacin de cdigo.

- Los trminos herencia, generalizacin y especializacin se refieren a aspectos de la

misma idea y a menudo se usan indistintamente.

- Usamos generalizacin para hacer referencia a la relacin entre las clases.

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

usando la relacin de generalizacin.

- Generalizacin y especializacin son dos perspectivas diferentes de la misma relacin,

observada desde la superclase o desde la subclase.

- La palabra generalizacin deriva de que la superclase generaliza a las subclases y

especializacin 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 sera una instancia del ancestro. Igualmente, las operaciones sobre la clase

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

nuevas caractersticas (extensin).


- Una subclase puede implementar de nuevo una operacin 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 especificacin de ese aspecto.

- Conseguir mejor rendimiento


Ejemplo aplicado:

En la figura se especifica que Auto y Camin heredan de Vehculo, es decir, Auto posee

las Caractersticas de Vehculo (Precio, VelMax, etc) adems posee algo particular que

es Descapotable, en cambio Camin tambin hereda las caractersticas de Vehculo

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

Cabe destacar que fuera de este entorno, lo nico "visible" es el mtodo Caractersticas

aplicable a instancias de Vehculo, Auto y Camin, pues tiene definicin publica, en

cambio atributos como Descapotable no son visibles por ser privados.


BIBLIOGRAFA

Campderrich, F. B. (2003). Ingeniera del software. Barcelona, ES: Editorial UOC.

Retrieved

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

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

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

Departamento de Ciencias de La Computacin 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 prcticos de UML. Madrid, ES: Editorial Complutense.


http://site.ebrary.com/lib/uagrariaecsp/reader.action?docID=10536104
Anexos

You might also like