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
Top Related