Hola y bienvenidos nuevamente. En esta ocasión hablaremos de otro tipo de asociaciones. En el video pasado hablamos de asociaciones de agregación de tipo compuesto, ahora hablaremos de las asociaciones de agregación de tipo compartidas, "shared" en inglés, y en GenMyModel. Al final de esta lección podrás leer diagramas de clases que contengan asociaciones de tipo compartido. Las asociaciones de tipo compartido representan relaciones de tipo agregación. Si recuerdas esto de nuestro video anterior, una agregación representa una asociación entre dos clases en las que una es un todo y la otra es una parte de dicho todo. En otras palabras, las partes de un todo. Las asociaciones compartidas según la especificación de UML 2.5 tienen menos restricciones que las compuestas, Pero también nos abren la puerta a toda una dimensión de posibilidades para modelar nuestros problemas. Veamos bien de qué se trata. Hablemos de cómo representar una asociación compartida en UML. Usamos una línea, pero en el extremo que corresponde a la clase que hace las veces del todo, o la que está compuesta de varias partes, dibujaremos un rombo vacío. Revisemos un ejemplo. Una universidad tiene varios programas y a un programa pueden pertenecer varios estudiantes. En este caso vemos que, aunque los estudiantes tienen que hacer parte necesariamente de un programa, es posible conseguir instancias de estudiantes que no dependan como tal de los programas. Esto nos lleva entonces a considerar la cardinalidad de las asociaciones compartidas. A diferencia de las asociaciones compuestas, hay menos restricciones asociadas. En particular, la cardinalidad del lado del todo no está limitada, un estudiante puede ser parte de varios programas. Por ejemplo, quizás esté haciendo una doble titulación o una triple, si es que eso es posible. Al igual que en las asociaciones compuestas, en una asociación compartida las partes pueden tener cualquier cardinalidad, en este caso, será muchas. La navegabilidad también puede hacerse explícita en esta relación. Es posible restringir qué objetos tienen visibilidad sobre otro pero, y esto es un pero muy importante, debido a la naturaleza de la asociación, a lo sumo podemos tener una navegabilidad desde la clase que hace del todo hacia las partes, pero no de modo contrario, así como sucede las asociaciones compuestas. Entonces, los cursos saben qué estudiantes los toman y los estudiantes qué cursos están tomando. Es posible imaginar una situación en la que queramos restringir las cosas, pero tendría poco sentido no dejar que los cursos manejen o conozcan a sus estudiantes. Las demás convenciones también se aplican normalmente. Podemos nombrarlas y asignarles rol de acuerdo con lo que representan, como en nuestros ejemplos anteriores, y sus convenciones de nombramiento se mantienen. Podemos tener una instancia de la clase Universidad que llamaremos "U1". Esa instancia puede tener dos programas un programa de Ingeniería Industrial y un programa de Ingeniería de Sistemas, y en cada programa habrán inscritos estudiantes. Podemos pensar en una instancia "e1" de la clase Estudiante, "e2" y "e3". En este caso, la Universidad tiene dos programas y "e1" podría estar inscrito en Ingeniería Industrial, al igual que "e2", "e3" podría estar inscrito en Ingeniería de Sistemas y "e2" estará haciendo doble programa con Ingeniería Industrial. Entonces, lo que sucederá es que las instancias de la clase Estudiante no dependerán de la existencia de la clase Programa. Esto es, si la universidad en algún momento decide acabar con el programa de Ingeniería Industrial, en ese caso los estudiantes no desaparecerán. Entonces, notemos cómo al eliminar el programa de Ingeniería Industrial, los estudiantes "e2" y "e3" siguen inscritos a un programa y, de acuerdo a la definición de nuestro problema, el estudiante "e1" podría pasarse a otro programa o dejar de estar inscrito en la universidad. Y entonces es aquí cuando podrías preguntarte, "¿no hace falta de pronto una relación para ese tipo de situaciones?" Y sí, la respuesta es sí. Falta una relación que modele la inscripción de los estudiantes a la universidad. Y eso tiene un impacto directo porque hace falta una asociación entre la clase Universidad y la clase Estudiante. Esta asociación será uno a varios. Con esto acabamos nuestra anotación de conjuntos, que no hace parte de UML, pero nos sirven para representar cómo funcionan las instancias en el caso de las asociaciones compartidas. Antes de terminar vale la pena mencionar un tipo muy especial de relaciones entre las clases, las dependencias. Las dependencias modelan la relación entre dos clases, una de las cuales necesita de otra para su implementación, ya sea a nivel semántico o a nivel estructural. Las relaciones de dependencia también se les conoce como "relaciones de cliente-proveedor", ya que hay una clase que provee elementos, el proveedor, a otra para su implementación, el cliente. Las dependencias se expresan como una flecha punteada de forma dirigida desde el cliente hasta el proveedor, junto con el estereotipo adecuado, si se quiere ser más claro con el tipo de dependencia. Notemos que, como una dependencia no es una asociación "per se", los roles, el nombre más allá del estereotipo, y la cardinalidad no son indicados. Aunque las dependencias pueden tomar múltiples formas, instanciación llamado "uso" en GenMyModel, en el contexto de nuestro curso sólo usaremos dependencias para tipo "uso", que significa que una clase usa, justamente, instancias de un proveedor como parámetros de sus métodos. Pensemos en una clase "Hoja de Asistencia" que es parte de una asociación compuesta de la clase "Curso". Esta clase tendrá un método "agregar Estudiante" que registra el nombre y código de un estudiante a la Hoja de Asistencia. Para funcionar necesita como parámetro una instancia de la clase "Estudiante", pero podemos decir que no es necesario que exista una asociación entre "Hoja de Asistencia" y "Estudiante". ¿Por qué? Porque dicha asociación sería mucho menos relevante. En este caso se establece la dependencia porque a través del parámetro del método "agregar Estudiante" de la clase "Hoja de Asistencia" se conoce o se usa a la clase "Estudiante". Con esto termina este video sobre las asociaciones compartidas y las relaciones de dependencia. Estos son los tipos de asociaciones que veremos en este curso junto con la asociación compuesta, y te invito a que sigamos en los videos de construcción usando estas asociaciones. ¡Manos a la obra!
