ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ

MANUEL FÉLIX LÓPEZ

CARRERA INFORMÁTICA

SEMESTRE SÉPTIMO PERIODO ABR. /SEP.-2015

INGENIERÍA DEL SOFTWARE

TEMA:

RESUMEN#8: TIPOS DE RELACIONES ENTRE CLASES

AUTORA:

DAYANA H. BAILÓN DELGADO

FACILITADORA:

ING. HIRAIDA SANTANA

CALCETA, JUNIO 2015

CAPÍTULO I. INTRODUCCIÓN

Los diagramas de clases permiten al desarrollador el entendimiento del sistema.

Forman parte fundamental al momento de documentar el funcionamiento del

software, facilitando futuras actualizaciones en el mismo realizadas por los

autores y por otros programadores. Además permiten: corregir posibles errores,

a través de ciertos programas generar código automáticamente, proyectar las

relaciones de dependencia entre una clase y otra, entre otras ventajas.

Un elemento fundamental en los diagramas de clases es la relación que existe

entre estas. Por ello, se dedica este capítulo a dicho tema.

Existen tres tipos de relaciones: asociación (conexión entre clases), dependencia

(relación de uso) y relaciones de herencia. A continuación se detalla cada tipo y

su respectiva sub-clasificación.

1.1. OBJETIVO

Definir los tipos de relaciones y sus sub-clasificaciones.

CAPÍTULO II. MARCO TEÓRICO

2.1. TIPOS DE RELACIONES ENTRE CLASES.

Las relaciones existentes entre las distintas clases indican cómo se comunican

los objetos de esas entidades entre sí. Los mensajes “navegan” por las

relaciones existentes. (Guidi, 2011)

2.1.2. ASOCIACIÓN

Es una relación estructural que describe una conexión entre objetos. En la

gráfica, se presenta como una línea continua que une las clases relacionadas.

2.1.2.1. NAVEGACIÒN

Las asociaciones pueden ser unidireccionales o bidireccionales. Son

unidireccionales cuando se recorre hacia un sentido y bidireccionales cuando es

ASOCIACIÓN

NAVEGACIÒN MULTIPLICIDAD INVOLUTIVASCASOS

PARTICULARES

AGREAGACIÓN

COMPOSICIÓN

DEPENDENCIARELACIONES DE

HERENCIA

GENERALIZACIÒN Y

ESPECIALIZACIÓN

HERENCIA MÚLTIPLE

Fig. 2.1. Clasificación y sub-clasificación de las relaciones entre clases.

Fig. 2.2. Ejemplo de asociación entre clases.

hacia ambas direcciones. Si es direccional, es necesario ubicar una flecha al final

para indicar el sentido de dirección.

2.1.2.2. MULTIPLICIDAD

Determina cuántos objetos de cada tipo intervienen en la relación. Cada

asociación tiene dos multiplicidades (una por cada extremo de la relación). En

algunos casos para especificar la multiplicidad de una asociación hay que indicar

la multiplicidad mínima y la máxima. (Gutierrez, 2011)

Multiplicidad Significado

1 Uno y sólo uno.

0..1 Cero o uno.

N..M Desde N hasta M.

* Todo

0..* Cero o varios

1..* Uno o varios, al menos uno.

Fig. 2.3. Ejemplo de asociación unidireccional entre clases.

Fig. 2.4. Ejemplo de asociación bidireccional entre clases.

Tabla 2.1. Multiplicidad

Si la multiplicidad mínima es 0, la relación es opcional.

Una multiplicidad mínima mayor o igual que 1 establece una relación

obligatoria.

Fig. 2.5. Ejemplo de multiplicidad: Uno a uno o ninguno.

Fig. 2.6. Ejemplo de multiplicidad: Muchos a uno.

Fig. 2.7. Ejemplo de multiplicidad: Ninguno, uno o más de uno a uno o más de uno

2.1.2.3. INVOLUTIVAS

Cuando la misma clase aparece en los dos extremos de la asociación.

2.1.2.4. CASOS PARTICULARES

Casos particulares de asociaciones: relaciones entre un todo y sus partes.

Agregación: Las partes pueden o no formar parte de distintos agregados.

La entidad puede funcionar igual con o sin sus partes agregadas.

Fig. 2.8. Ejemplo de relación involutiva. Muchos empleados dirigen a otros empleados.

Fig. 2.9. Ejemplo de relación involutiva. Una persona está casada con otra persona.

Fig. 2.10. Ejemplo de agregación. Una ciudad puede o no tener aeropuertos.

Composición: Es estricta. Si una parte no está presente en el todo, la

clase deja de funcionar.

2.1.2. DEPENDENCIA

Una dependencia es una relación más débil que una asociación y muestra la

relación entre un cliente y el proveedor de un servicio usado por el cliente.

Cliente es el objeto que solicita un servicio.

Servidor es el objeto que provoca el servicio solicitado.

Fig. 2.11. Ejemplo de composición. Un avión no puede funcionar sin dos alas.

Fig. 2.12. Ejemplo de dependencia. Una impresora no podría imprimir un documento inexistente.

2.1.3. RELACIONES DE HERENCIA

Es la relación entre una superclase y una subclase. No es una instancia. Se

utilizan cuando un objeto contiene atributos y/o métodos similares a otro,

entonces se crea una superclase que va a heredar dichas características a las

entidades heredadas. (Guidi, 2011)

2.1.3.1. GENERALIZACIÒN Y ESPECIALIZACIÓN

Expresan relaciones de inclusión entre conjuntos.

El comportamiento de una categoría más general es aplicable a una

categoría particular.

Las subclases heredan características de las clases de las que se derivan

y añaden características específicas que las diferencian.

2.1.3.2. HERENCIA MÚLTIPLE

Cuando existe herencia de más de una clase, es decir cuando una clase tiene

más de una clase padre; y esa clase se denomina clase unión. (Aransay, 2010)

Fig. 2.13. Ejemplo de herencia. Un empleado directivo, técnico y administrativo hereda

atributos y/o métodos de un empleado general.

Fig. 2.14. Ejemplo de herencia múltiple. Un avión hereda propiedades de una clase aparto

volador y de vehículo motorizado.

2.2. EJEMPLO PRÀCTICO

2.2.3. LÍNEA AÉREA

Una línea aérea ofrece distintos vuelos. Los vuelos están compuestos de

segmentos de vuelo que son los destinos o paradas intermedias. Es decir un

vuelo es una sucesión de segmentos de vuelo.

Los pasajeros tienen un asiento por cada segmento de vuelo.

Un segmento de vuelo necesita un avión, un aeropuerto de salida, uno de

llegada, asi como un piloto y copiloto.

CAPÍTULO III. CONCLUSIONES

El diagrama de clases permite ampliar las oportunidades, para que las entidades

involucradas, principalmente los desarrolladores, en un proyecto informático

comprendan de una mejor manera la aplicación o sistema.

Es necesario comprender las asociaciones y relaciones entre clases para

alcanzar el funcionamiento correcto de un software y su posterior

documentación.

La herencia simple y la herencia múltiple brindan grandes beneficios a cualquier

tipo de sistema.

BIBLIOGRAFÍA

Aransay, J. 2010. Relaciones entre clases, herencia entre clases. (En línea). ESP. Consultado, 1 de jul. 2015. Formato PDF. Disponible en http://www.unirioja.es/cu/jearansa/0910/archivos/EIPR_Tema02.pdf

Berzal, F. 2014. Relaciones entre clases: Diagramas de clases UML. (En línea).

ESP. Consultado, 1 de jul. 2015. Formato PDF. Disponible en http://elvex.ugr.es/decsai/java/pdf/3C-Relaciones.pdf

Guidi, F. 2011. Diagramas de clases de UML. (En línea). CHL. Consultado, 10

de jun. 2015. Disponible en http://eii.ucv.cl/pers/guidi/cursos/estructuras/pdf/SE-DiagramasDeClasesUML.pdf

Gutierrez, D. 2011. UML Diagramas de Clases. (En línea). VEN. Consultado, 10

de jun. 2015. Disponible en http://www.codecompiling.net/files/slides/UML_clase_04_UML_clases.pdf

Peña, A. 2006. Ingeniería de Software: Una Guía para Crear Sistemas de

Información. México. (En línea). Consultado, 20 de may. 2015. Formato PDF. Disponible en http://www.wolnm.org/apa/articulos/ingenieria_software.pdf