I. INTRODUCCIÓN
“La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas, y otros sistemas[…]. La tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto”. (Ingeniería del Software, Frederick P. Brooks)
Para que un software tenga éxito, es necesario seguir estándares, uno de ellos es el Lenguaje Unificado Modelado, en el cual existen distintos tipos de modelos a seguir. Un modelo muy importante, es aquel que sirve de ayuda a los desarrolladores de software, y es conocido como diagrama de clases.
El diagrama de clases es el modelo capaz de ser entendido fácilmente por un desarrollador, lo cual es una ventaja significativa, cuando el software necesita ser actualizado o se necesita mantenimiento del mismo, y el desarrollador original no está disponible, entonces tendrá que realizar las tareas un desarrollador nuevo que probablemente no sepa mucho de la funcionabilidad del software, pero el diagrama de clases le servirá de guía.
La relación que existe en los diagramas de clases, es esencial para conformar los mismos, es por esta razón que en esta publicación hablare detalladamente de las relaciones entre clases, en el diagrama de clases.
II. OBJETIVO
Aprender a relacionar las clases con los distintos tipos de relaciones que existen.
III. MARCO TEÓRICO
Los diagramas de clases están especificados por relaciones que permiten establecer la forma en la que las clases componentes del sistema se comunican, las relaciones que existen y sus subrelaciones están especificadas en la imagen 3.1 mostrada a continuación.
Imagen 3.1. Clasificación de las relaciones
3.1. ASOCIACIONES
Simple: Una asociación es la manera en la que una clase está asociada con otra, o relacionada de modo que exista una comunicación, por ejemplo, en la imagen 3.2 podemos ver como un pasajero ocupa un asiento, lo cual constituye una relación simple.
Imagen 3.2. Relación simple
Inversa: En la imagen 3.3 podemos apreciar como existe una relación inversa es decir una comunicación bidireccional debido a que un vuelo debe llegar a un areopuerto y también salir de uno.
Imagen 3.3. Relación inversa
En la imagen 3.4 se puede ver que una clase puede tener muchas clases relacionadas a sí misma en un sistema.
Imagen 3.4. Relación múltiple
Reflexiva: Una asociación es reflexiva cuando distintos objetos son relacionados a una misma clase.
Imagen 3.5. Relación reflexiva
Agregación: Representa una relación de pertenencia a una parte, sin embargo, si una parte es eliminada el todo sigue existiendo, ya que esa parte no es esencial en el todo, por ejemplo una persona puede vivir sin apéndice.
Imagen 3.6. Relación de agregación
Composición: Es parecida a la agregación pero más estricta, en este un todo no puede existir sin una parte determinada por ejemplo una persona no puede existir sin corazón. En la imagen 3.6 se muestra otro ejemplo.
Imagen 3.6. Composición
3.2. HERENCIA
3.2.1. ESPECIALIZACIÓN /GENERALIZACIÓN
Con este tipo de relación una o más clases heredan métodos y atributos, de una clase padre, de manera que se hace una reutilización de código. El funcionamiento de la herencia en las clases es el expuesto en la imagen 3.7.
Imagen 3.7. Herencia
3.3. EJEMPLO COMPLETO
Enunciado: 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, así como un piloto y copiloto.
Imagen 3.8. Ejemplo
IV. CONCLUSIÓN
Identificar la manera en la que se relacionan las clases es muy importante para realizar un diagrama de clases, ya que al entender para qué sirve cada relación y cómo son representadas gráficamente, es mucho más fácil realizar una documentación del software, si bien es cierto, algunos autores de libros enfocados al correcto diseño del software indican que la documentación principal de un sistema es aquella que indica cómo funciona el mismo, de una manera técnica, es decir una manera que quizá no sea entendida por el usuario o cliente, pero que si será entendida por un programador, el diseño de un diagrama de clases es una de las partes más complejas de realizar, y si no se tiene claro para qué sirve cada componente y no se especifican todos los métodos, objetos y relaciones, el software estaría mal esquematizado y por lo tanto mal realizado.
Las relaciones entre clases indican la manera en la que éstas se conectan y dan funcionabilidad al plantear el software, la herencia, las asociaciones simples y complejas, reflexivas, entre otras como agregación y composición, son componentes de la diagramación de clases.
V. BIBLIOGRAFÍA
Ceria, S. s.f. Casos de Uso. (En línea). ES. Consultado 2 de Jul. del 2015. Formato PDF. Disponible en: http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/CasosDeUso.pdf
Gutiérrez, D. 2011. UML Diagramas de clases. (En línea). VE. Consultado, 10 de Jun. 2015. Formato PDF. Disponible en: http://www.codecompiling.net/files/slides/UML_clase_04_UML_clases.pdf
Gutierrez, J. 2008. Diagramas UML de casos de uso y de requisitos. (En línea). ES. Consultado 2 de Jul. del 2015. Formato PDF. Disponible en: http://www.lsi.us.es/~javierj/cursos_ficheros/metricaUML/CasosUsoUML.pdf
Kendall, K y Kendall, J. 2011. Análisis y diseño de sistemas. 8 ed. México. Pearson Education. p 600