RELACIONES ENTRE CLASES

ESCUELA SUPERIOR POLITÉCNICA AGROPECUARIA DE MANABÍ

MANUEL FÉLIX LÓPEZ

CARRERA INFORMÁTICA

    SEMESTRE  SÉPTIMO           PERIODO  ABR 2015/SEP 2015

TEMA:

RELACIONES ENTRE CLASES

MATERIA:

INGENIERÍA DE SOFTWARE

AUTOR:

CARLOS A. ZAMBRANO VIDAL

FACILITADORA:

ING. HIRAIDA SANTANA

CALCETA,  JULIO 2015

INTRODUCCIÓN

En la sección anterior hablamos de los diagramas de clases, ahora vamos a enfocarnos en los tipos de relaciones que pueden existir en un diagrama de clases cómo funcionan como van ubicados entre sí como se relacionan en nuestro diagrama ya que es muy importante conocer cómo se utilizan las relaciones entre clases porque es necesario para nuestro diagrama final este bien realizado y que sea entendible para nuestros analistas y cliente.

MARCO TEÓRICO

RELACIONES ENTRE CLASES

Ahora ya definido el concepto de Clase, es necesario explicar cómo se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:

ü  uno o muchos: 1..* (1..n)

ü  0 o muchos: 0..* (0..n)

ü  número fijo: m (m denota el número).

HERENCIA (ESPECIALIZACIÓN/GENERALIZACIÓN)

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 (public y protected), ejemplo:

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 pública, en cambio atributos como Descapotable no son visibles por ser privados.

AGREGACIÓN

Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:

·         Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido está condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").

·         Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente:

En donde se destaca que:

· Un Almacén posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).

· Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.

· La composición (por Valor) se destaca por un rombo relleno.

·  La agregación (por Referencia) se destaca por un rombo transparente.

·  La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.

ASOCIACIÓN:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre sí. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.

DEPENDENCIA O INSTANCIACIÓN (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 está condicionado a la instanciación proveniente desde el objeto Aplicación):

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).

CASOS PARTICULARES:

CLASE ABSTRACTA

Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos.

CLASE PARAMETRIZADA

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos. La generalidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura predefinida (especialización a través de clases).

CONCLUSIÓN

Se concluye que las relaciones entre clases juegan un papel importante en el desarrollo de nuestro diagrama de clase ya que de estos depende como estén relacionadas nuestras clases, también nos enseña como la relación entre un objeto y otro, la herencia de propiedades de otro objeto, estas son algunas de las funcionalidades de las relaciones entre clases.

BIBLIOGRAFÍA

Pressman, R. 2010. INGENIERÍA DEL SOFTWARE. Un enfoque práctico. Séptima edición.

Larman, Craig. UML y Patrones. Introducción al análisis y diseño orientado a objetos. Prentice Hall, México, 1999.