Menú  Buscar

Con el mazo dando

Haciendo lo que hay que hacer

Anuncios

REPORT THIS AD

PUBLICADO EN UML

UML – Diagramas de Clases – Ejercicio 2

            19 Votes

Introducción

En el ejercicio anterior se expuso un supuesto práctico sobre el que se tenía que realizar el diseño de un diagrama de
clases. Dicho supuesto recorría casi todas las posibilidades de relación entre clases. En la entrada de hoy se expone
un segundo ejercicio se va a ir un poco más allá, involucrando al interfaz como garante de la realización de
especificaciones funcionales.

Enunciado

Crear un proyecto UML llamado Torneo en el que se diseñe un diagrama de clases que modele la estructura necesaria
para manejar los datos de los encuentros de un torneo de tenis de mesa en la modalidad de sorteo y eliminatoria.
Del torneo interesa conocer la fecha del torneo, los encuentros celebrados y el ganador. De cada jugador, que debe de
conocer perfectamente las reglas, interesa saber el número de federado de la federación de la que es miembro.

De cada persona interesa saber sus datos básicos: NIF, nombre completo y fecha de nacimiento. La clase Fecha se
modela con tres campos (día, mes y año) de tipo entero. La clase Nif se modela con un campo de tipo entero llamado
dni y un campo de tipo carácter llamado letra.

De cada encuentro interesa conocer los oponentes, el ganador y el resultado final del marcador de cada una de las
tres partidas que se juegan a 21 puntos.

Análisis del enunciado

El primer paso a realizar consiste en leer detenidamente el enunciado y de él extraer toda la información posible. A
veces es cuestión de aplicar el sentido común, a veces es cuestión de unir cabos sueltos, a veces es cuestión de
simple lógica y a veces es cuestión de pura deducción, pero siempre siempre es cuestión de razonar por
aproximaciones sucesivas y de experiencia.

Bien, parece que el enunciado refiere únicamente un modelado de datos, no de comportamiento, por lo que se
procederá a realizar una lista de los elementos más significativos para el proyecto que se puedan extraer del
enunciado.

1. Nombre del proyecto – Torneo

2. Nombre del diagrama – EncuentrosTorneo
3. Ítems – Elementos significativos del enunciado.
Encuentro
Fecha del torneo
Jugador
Número de federado
Persona
Nif
Nombre completo
Fecha de nacimiento
Dia
Mes
Año
 Dni
Letra
Oponente
Resultado final
Partida

Diseño de clases

Recuérdese que las clases son entidades que encapsulan información, se trata por tanto de ver qué información de la
lista anterior está relacionada entre sí y ver la forma de encapsularla en sus respectivas clases.

Se procederá a identificar las clases a partir del enunciado y de encapsular en ellas la información relacionada. Este
paso se realizará considerando de forma aislada unas clases de otras. Posteriormente, cuando se vean las relaciones,
se depurará su composición.

En esta fase del modelado se procede siempre desde las clases más triviales a las más complejas.

Clase Nif

Clase Fecha

Clase Nombre
Clase Marcador

Clase Persona

Clase Jugador

Clase Partida

Clase Encuentro
Clase Torneo

Relaciones

En esta fase se va a evaluar qué clases tienen que ver con qué otras, es decir sus relaciones. Para que el
procedimiento resulte lo más sencillo posible se estudiarán las relaciones dos a dos.

Herencia

Primero se abordan las relaciones de herencia empezando por aquellas que resulten triviales o más evidentes.

Aunque no es muy ortodoxo, la regla para detectar una relación de herencia es fijarse en el catálogo de clases
diseñadas en la fase anterior, y ver si existe alguna clase cuyos atributos sean un subconjunto de alguna otra.

Persona – Jugador

En este caso resulta que los atributos de la clase Persona son un subconjunto de los de la clase Jugador y
semánticamente tiene sentido decir que la clase Jugador es una especialización de la clase Persona.

Obsérvese que los atributos que hereda la clase Jugador, que es la clase especializada, no se representan. Obsérvese
también que la flecha que representa esta relación va desde la clase hija a la clase madre, tiene línea continua,  punta
de flecha cerrada, no tiene cardinalidad y no está etiquetada por ningún rol.
Asociación

Una vez se han resuelto las relaciones de herencia le toca el turno a las relaciones de asociación. Se procederá
siempre abordando primero las triviales o más simples y continuando por las demás. Para que resulte más claro, el
análisis se realizará considerando las clases de dos en dos.

Persona – Fecha

Aun a riesgo de resultar tedioso pero con el objetivo de que resulte lo más clarificador posible, el análisis de la relación
entre estas dos clases se realizará paso a paso.

Esta asociación es trivial. La clase Persona tiene un atributo de tipo Fecha, dicho de otra manera, la clase Persona
tiene una referencia a un objeto de la clase Fecha.

Las asociaciones se representan con una línea de trazo continuo que une las clases vinculadas.

Roles
Así considerado, el atributo fechaNac de la clase Persona pasa a ser el rol de la relación que vincula a ambas clases.
Por lo tanto, desaparece de la clase Persona y aparece en la línea de vinculación junto a la clase de su tipo.

Navegabilidad
Ahora hay que abordar la navegabilidad tratando de ver si desde una clase se puede ir a la otra. Es evidente que la
clase Fecha no tiene información de la clase Persona por lo que la navegabilidad desde la clase Fecha no es posible.

Sin embargo, la clase Persona tiene una referencia a la clase Fecha por lo que sí es viable la navegabilidad desde la
clase Persona hacia la clase Fecha. La navegabilidad se expresa con una punta de flecha abierta puesta en el lado de
la clase a la que se llega.

Cardinalidades
El siguiente paso es abordar las cardinalidades o multiplicidades, es decir el número de instancias de cada clase que
intervienen en la relación. Para resolver este paso hay que preguntar:

“¿Por cada instancia de una de las dos clases cuántas instancias de la otra clase pueden en extremo intervenir como
mínimo (Cardinalidad mínima) y como máximo (Cardinalidad máxima)?”

Y luego hacer las preguntas al revés.

Cuántas fechas de nacimiento como mínimo tiene cada persona : 1

Cuántas fechas de nacimiento como máximo tiene cada persona: 1
Cuántas personas pueden nacer como mínimo en una determinada fecha: 0
Cuántas personas pueden nacer como máximo en una determinada fecha: Varias

Obsérvese que cuando la cardinalidad mínima y máxima coinciden sólo se representa una de ellas. Obsérvese
también que cuando la cardinalidad máxima es múltiple y la cardinalidad mínima es cero refiere una cardinalidad
múltiple opcional y se representa con un asterisco.

Todo – Parte
El siguiente paso consiste en considerar qué clase es la parte [PARTE] y qué clase es la parte [TODO]. Dicho de otro
modo quién contiene a quién. En este caso la discriminación es trivial: la clase Persona es la parte [TODO] porque
tiene una referencia a la clase Fecha que es la parte [PARTE].

Agregación – Composición
El siguiente paso consiste en determinar si la relación de asociación entre las clases es de agregación o de
composición. Para que la relación sea de composición es condición necesaria que la cardinalidad de la parte [TODO]
sea 1. Como este no es el caso la relación es de agregación.

Obsérvese que la parte [TODO] se identifica dibujando un rombo acostado en la línea de la relación. Obsérvese también
que el se ha representado el rombo en blanco para identificar una relación de agregación.

Y este es básicamente el proceso a seguir para analizar las relaciones de asociación entre las clases de un diagrama
de clases UML. En situaciones más complejas habrá que reconsiderar este método para introducir los nuevos
elementos involucrados.

Persona – Nif

El análisis de la relación entre estas dos clases determina que cada objeto de la clase Nif está unívocamente unido a
un solo objeto de la clase Persona, y viceversa, por lo que la cardinalidad en ambos lados es la unidad. tanto mínima
como máxima.

Además semánticamente si desaparece la parte [TODO], el objeto de la clase Persona, la existencia de la parte
[PARTE], el objeto de la clase Nif, ya no puede ser utilizado y debería desaparecer también. Esta dependencia
existencial apunta a una relación de tipo Composición.

Obsérvese que la parte [TODO] se identifica dibujando un rombo acostado en la línea de la relación. Obsérvese también
que el se ha representado el rombo en negro para identificar una relación de composición.

Persona – Nombre

La relación entre la clase Persona y la clase Nombre es muy parecida a la relación existente entre la clase Persona y la
clase Fecha.

Obsérvese que al ir expresando los atributos de la clase Persona como roles de sus respectivas relaciones, en el
contexto de este supuesto, el diagrama que representa la clase Persona ya no contiene ningún atributo.

Encuentro – Jugador

La relación entre la clase Encuentro y la clase Jugador es muy interesante. Como se puede apreciar hay tres
relaciones diferentes con sus respectivos roles.

Obsérvese que si se decidiera no discriminar los roles jugador1 y jugador2, sus respectivas relaciones se podrían
fusionar en una sola que se podría codificar utilizando alguna colección de dos elementos.

Respecto a las cardinalidades, obsérvese que todos los jugadores que participen en un encuentro tienen que hacerlo
en alguno de dos roles: jugador1 o jugador2 pero no en los dos al mismo tiempo. Asimismo, aquellos jugadores que
participen en varios encuentros pueden ostentar diferentes roles en cada uno de ellos, o no. Finalmente, el ganador de
un encuentro debe ser uno de los dos participantes del mismo. Estas restricciones se podrían expresar en los
correspondientes diagramas de comportamiento.

Encuentro – Marcador

En el contexto del supuesto de este ejercicio, en un encuentro se celebran tres partidas, el primer jugador que llegue a
21 puntos gana la partida. El jugador que gane más partidas de un encuentro gana el encuentro. Obsérvese que no
puede haber empate ni en las partidas ni en el encuentro.

La clase Marcador encapsula el resultado de una partida mediante dos números de tipo entero, el primer número
corresponde a los puntos de primer jugador y el segundo número a los puntos del segundo jugador. Uno de ellos debe
contener el número 21 y corresponderá al ganador de la partida y el otro valor debe estar situado entre 0 y 20.

Obsérvese que se ha modelizado una relación de Composición porque, a pesar de que en partidas diferentes puedan
darse resultados iguales, los objetos instanciados de la clase Marcador que encapsulan estos resultados no se
comparten, ergo si desaparece el encuentro desaparecen sus resultados.

Torneo – Fecha

La relación entre la clase Torneo y la clase Fecha es muy parecida a la relación existente entre la clase Persona y la
clase Fecha.

Torneo – Encuentro

Para que haya un torneo es necesario que haya al menos un encuentro.

Nótese que se ha establecido una relación de composición debido a que los encuentros celebrados en un sorteo no
son válidos para otro.

Torneo – Jugador

El objetivo de un torneo es tener siempre un ganador. Esa figura la tiene que ostentar alguno de los jugadores que han
participado en él.

Clase Partida

Llegados a este punto todas las relaciones entre clases están establecidas. A pesar de que inicialmente se modeló la
clase Partida para recoger los datos de los participantes de cada partida y de su resultado, desde el punto de vista al
que se ha llegado siguiendo el razonamiento argumentado hasta ahora resulta que esta clase no es necesaria ni
conveniente, por lo que se prescindirá de ella.

Esta decisión no es una vuelta atrás ni mucho menos. En el diseño de diagramas de clases es muy normal y
conveniente realizar continuos replanteos en la medida que el avance en el razonamiento clarifica progresivamente la
situación.

Interfaces

Terminado el diseño de los datos encapsulados en las relaciones entre las diferentes clases el siguiente paso es
detectar las posibles capacidades funcionales que deben reunir dichas clases expresadas en forma de realización de
interfaces.

Interfaz IJugador

Si se conviene en que la capacidad de jugar al tenis de mesa viene proporcionada por el contenido de un determinado
método, toda clase que represente a una persona que sabe jugar a este deporte incorporará este método en su
código.

Sin embargo, ¿Cómo reconocer a un jugador de tenis de mesa sin verlo jugar? La respuesta viene a través de los
interfaces. Un interfaz es como un título que faculta a su poseedor en una determinada habilidad. Así se reconoce a
un jugador por su título, como se conoce a un médico por su título universitario, un extintor eficaz por su certificado de
industria, la reparación de un coche por su factura, etc.
En este caso se convendrá en que el interfaz que inviste a una persona como un jugador de tenis de mesa se
llama IJugador y que el método que corresponde a esa capacidad se llama jugarTenisMesa.

Realizaciones

En esta fase se va a señalar qué clases deben implementar las capacidades funcionales definidas a través de los
interfaces, es decir sus realizaciones.

Jugador – IJugador

Para expresar que la clase Jugador realiza el interfaz IJugador se utiliza la siguiente representación.

Adviértase que la clase y el interfaz están vinculados por una línea de trazo discontinuo, con una punta de flecha
cerrada en el lado del interfaz y que en ningún lado se expresa el contenido del método impuesto por el interfaz.

Diagrama complet o

Ahora se trata de ponerlo todo junto en un diagrama de clases completo.

Este ejercicio está disponible como un archivo ZIP que se corresponde con un proyecto de la herramienta UML
llamada Modelio. Para abrirlo hay que importar este proyecto desde su menú principal.

En la siguiente entrega se abordará un ejercicio un poco más complejo de diseño de Diagrama de clases UML.

Si esta información te ha sido útil házmelo saber y si no … también.

Saludos.

Anuncios

REPORT THIS AD

07/24/2013  4 Respuestas

UML – Diagramas de Clases – Ejercicio 1

            20 Votes
Enunciado

Crear un proyecto UML llamado Asociacion en el que se diseñe un diagrama de clases que modele el proceso de dar
de alta a cada una de las personas que se apuntan a una asociación.

De cada persona interesa saber sus datos básicos: NIF, nombre completo y fecha de nacimiento. Cuando cada nuevo
socio se da de alta, se le asigna un código de asociado alfanumérico y se anota la fecha de alta.

La clase Fecha se modela con tres campos (día, mes y año) de tipo entero. La clase Nif se modela con un campo
de tipo entero llamado dni y un campo de tipo carácter llamado letra.

Análisis del enunciado

El primer paso a realizar consiste en leer detenidamente el enunciado y extraer de él toda la información posible. A
veces es cuestión de aplicar el sentido común, a veces es cuestión de unir piezas, a veces es cuestión de lógica y a
veces es cuestión de pura deducción, pero siempre siempre es cuestión de razonar por aproximaciones sucesivas y de
experiencia.

Bien, parece que el enunciado refiere únicamente un modelado de datos, no de comportamiento, por lo que se
procederá a realizar una lista de los elementos más significativos para el proyecto que se puedan extraer del
enunciado.

1. Nombre del proyecto – Asociacion

2. Nombre del diagrama – AltaAsociacion
3. Ítems – Elementos significativos del enunciado.
Persona
Socio
Nif
Nombre completo
Fecha de nacimiento
Código de asociado
Día
Mes
Año
Dni
Letra
4. Tipos de datos
 Integer
Char
String
Nif
Fecha
Nombre

Diseño de clases

Recuérdese que las clases son entidades que encapsulan información, se trata por tanto de ver qué información de la
lista anterior está relacionada entre sí y ver la forma de encapsularla en sus respectivas clases.

Se procederá a identificar las clases a partir del enunciado y de encapsular en ellas la información relacionada. Este
paso se realizará considerando las clases de forma aislada las unas de las otras. Posteriormente, cuando se vean las
relaciones, se depurará su composición.

En esta fase del modelado se procede siempre desde las clases más triviales a las más complejas.

Clase Nif

Clase Fecha

Clase Nombre

Clase Persona
Clase Socio

Relaciones

En esta fase se va a evaluar qué clases tienen que ver con qué otras, es decir sus relaciones. Para que el procedimiento
resulte lo más sencillo posible se iniciará el estudio por las relaciones dos a dos.

Herencia

Primero se abordan las relaciones de herencia empezando por aquellas que resulten triviales o más evidentes.

Aunque estrictamente hablando no es así del todo, la regla para detectarlas es ver si entre las clases definidas en el
diseño existe alguna cuyos atributos sean un subconjunto de alguna otra.

Persona – Socio

En este caso resulta que los atributos de la clase Persona son un subconjunto de los de la clase Socio y
semánticamente tiene sentido que la clase Socio sea una especialización de la clase Persona.

Obsérvese que los atributos que hereda la clase especializada no se representan. Obsérvese también que la flecha que
representa esta relación va desde la clase hija a la clase madre, tiene linea continua, punta de flecha cerrada, no tiene
cardinalidad y no está etiquetada por ningún rol.

Asociación
Una vez se han resuelto las relaciones de herencia le toca el turno a los demás tipos de relaciones que son
asociaciones. Se procederá siempre abordando primero las triviales o más simples y continuando por las demás. Para
que resulte más claro, el análisis se realizará considerando primero las relaciones dos a dos.

Socio – Fecha

Aun a riesgo de resultar tedioso pero con el objetivo de que resulte lo más clarificador posible, el análisis de la relación
entre estas dos clases se realizará paso a paso.

Roles
Esta asociación es evidente. La clase Socio tiene un campo de tipo Fecha, dicho de otra manera, la clase Socio tiene
una referencia a un objeto de la clase Fecha. Así considerado este campo pasa a ser el rol de la relación que vincula a
ambas clases. Por lo tanto, desaparece de la clase Socio y aparece en la linea de vinculación junto a la clase de su
tipo.

Navegabilidad
Ahora hay que abordar la navegabilidad tratando de ver si desde una clase se puede ir a la otra. Es evidente que la
clase Fecha no tiene información de la clase Socio por lo que la navegabilidad desde la clase Fecha no es posible. Sin
embargo, la clase Socio tiene una referencia a la clase Fecha por lo que si es viable la navegabilidad en este sentido.
La navegabilidad se expresa con una punta de flecha abierta puesta en el lado de la clase a la que se llega.

Cardinalidades
El siguiente paso es abordar las cardinalidades o multiplicidades, es decir el número de instancias de cada clase que
intervienen en la relación. Para resolver este paso hay que preguntar: “¿Por cada instancia de una de las dos clases
cuantas instancias de la otra clase pueden en extremo intervenir como mínimo (Cardinalidad mínima) y como máximo
(Cardinalidad máxima)?”. Y luego hacer las preguntas al revés.

Cuántas fechas de alta como mínimo tiene cada socio : 1

Cuántas fechas de alta como máximo tiene cada socio: 1
Cuántos socios se dan de alta como mínimo en una fecha: 0
Cuántos socios se dan de alta como máximo en una fecha: Varios
Obsérvese que cuando la cardinalidad mínima y máxima coinciden sólo se representa una de
ellas. Obsérvese también que cuando la cardinalidad máxima es múltiple y la cardinalidad mínima es cero refiere una
cardinalidad múltiple opcional y se representa con un asterisco.

Todo – Parte
El siguiente paso consiste en considerar qué clase es PARTE y qué clase es TODO. Dicho de otro modo quién contiene
a quién. En este caso la discriminación es trivial: la clase Socio es la parte TODO porque tiene una referencia a la clase
Fecha que es la parte PARTE.

Agregación – Composición
El siguiente paso consiste en determinar si la relación entre las clases es de agregación o de composición. Para que la
relación sea de composición es condición necesaria que la cardinalidad de la parte TODO sea 1. Como este no es el
caso la relación es de agregación.

Obsérvese que el rombo se ha representado en blanco.

Persona – Fecha

El mismo razonamiento empleado para relacionar las clases Socio y Fecha se puede emplear para relacionar las
clases Persona y Fecha.

Esta vez el rol de la clase Fecha en la relación cambia. Obsérvese como ha desaparecido el campo correspondiente a
la fecha de nacimiento de la clase Persona.

Persona – Nif

El análisis de la relación entre estas dos clases determina que cada objeto de la clase Nif está unívocamente unido a
un solo objeto de la clase Persona, y viceversa, por lo que la cardinalidad en ambos lados es la unidad, tanto mínima
como máxima.
Además, semánticamente hablando, si desaparece la parte TODO (el objeto de la clase Persona), la existencia de la
parte PARTE (el objeto de la clase Nif), carece de sentido y debería desaparecer también. Esta dependencia existencial
apunta a una relación de tipo Composición.

Obsérvese que el rombo se ha representado relleno en negro. Obsérvese también que el campo correspondiente al Nif
ha desaparecido de la clase persona pasando a ser el rol de la relación.

Persona – Nombre

La relación entre la clase Persona y la clase Nombre es muy parecida a la relación existente entre la clase Persona y la
clase Fecha.

Obsérvese que al trasladar el campo nombre al rol de la relación, el diagrama que representa la clase Persona ya no
contiene ningún atributo.

Diagrama de clases completo

Bueno, ahora se trata de ponerlo todo junto en un único diagrama.

Este ejercicio está disponible como un archivo ZIP que se corresponde con un proyecto de la herramienta UML
llamada Modelio. Para abrirlo hay que importar este proyecto desde su menú principal.

En la siguiente entrega se abordará un ejercicio un poco más complejo de diseño de Diagrama de clases UML que
involucre, además de los conceptos vistos en esta entrega, el concepto de realización de interfaces.

Si esta información te ha sido útil házmelo saber y si no … también.

Saludos.

07/01/2013  22 Respuestas

Software de Diagramación UML

            1 Vote

Si tuviera que dar un buen consejo éste seria: usa protector solar. Pero si me pidieran otro más diría: lleva siempre
papel y lápiz encima, o bolígrafo en su defecto.

A pesar de que lo llevo viendo año tras año, no me acostumbro. Me quedo perplejo cuando veo a algún alumno que,
agazapado detrás del ordenador, pretende tomar notas tecleando en el Notepad, un fichero que se perderá en la selva
de Mis Documentos.
No valen los consejos, la LME es más fuerte y más pronto que tarde, ese alumno desconecta y le cede el mando al
puntero del ratón que recorre raudo y veloz los enlaces de YouTube. Esa clase ya se ha perdido.

Usar el papel y el lápiz para apuntar las cosas no sólo es muy sufrido si no que, aunque no lo parezca, se hace con toda
el alma, con todos los sentidos, completamente involucrado. Y cuando se hace y rehace, hasta que queda bien, es tan
clarificador y persiste tanto en el tiempo… A riesgo de parecer dramático, con estos instrumentos las ideas
transcienden a las palabras y las frases, y se expresan en su verdadera naturaleza.

Aunque, con todos estos beneficios, es bien cierto que las notas que toma uno son sólo para uno. Otra persona no las
entenderá tan bien como su autor, seguramente porque esa otra persona es ajena a su realización.

Creo profundamente en la vigencia de ese dicho que dice que vale más un lápiz corto que una memoria larga, aunque
sea una memoria USB. Quiero decir que toda idea, sobre todo si es buena, suele empezar rayando vaguedades sobre el
papel. Escribir, rayar y borrar y volver a empezar hasta que las cosas surgen. Esta es la génesis de muchas buenas
ideas que en el mundo han sido, son y serán.

En el caso de UML no podía ser menos por cuanto toca al uso del papel y el lápiz  Un equipo de personas tiene que
ponerse de acuerdo sobre el diseño de un sistema desde puntos de partida diversos. El papel y el lápiz sobre la mesa,
o también la pizarra y la tiza son tan importantes como los gadgets a la última o la conectividad a Internet.
Los diagramas de UML deben de formar parte de la documentación de un sistema. Y esa documentación tiene que
poder ser interpretada por varias personas, más allá de los autores de los diagramas. Es por ello que los diagramas
deben de tener una representación normalizada.

A partir de aquí, cuando los diagramas definitivos ya se encuentran en papel es muy conveniente digitalizarlos,
y aquí es donde entra el Software de Diagramación UML. Y aquí hay software de diagramación de pago y software de
diagramación gratuito.

El software de diagramación de pago está muy bien, pero suele estar asociado a paquetes de
análisis/diseño/construcción/desarrollo de sistemas y el precio de la licencia parece escandalosamente elevado para
su uso formativo. Aunque en algún caso tienen una versión de demostración por un mes o así, la verdad es que no
suele venir bien para la docencia porque a la limitación temporal se le suele sumar alguna limitación funcional. Las
opciones como guardar, imprimir, exportar, generar código, etc. suelen estar desactivadas. En algún caso hay una
versión académica que no resulta gratuita o bien a la que es difícil adherirse porque está circunscrita a
determinadas áreas geográficas o determinadas entidades.

El software de diagramación gratuito esta dividido en dos grupos. Las versiones recortadas de versiones de pago y las
versiones no recortadas. Por lo que he probado, las versiones recortadas no suelen ser muy interesantes, si no se tiene
la intención de comprar el paquete completo que hay detrás. Respecto de las versiones no recortadas, que no están
vinculadas a ningún interés pecuniario, se pueden encontrar pifias llenas de errores,  monumentos a la cutrez, cosas
que quisieron ser y no fueron, alguna cosa más o menos interesante abandonada por el camino y mucha falta de
cariño.
No obstante, si te sientes armado de paciencia y determinación puedes dar un vistazo a esta extensa lista de
herramientas UML. Como en botica hay de todo. Espero que te resulte de utilidad.

Saludos.

06/08/2013  Responder

UML – Diagramas de Clases – Relaciones

            6 Votes

Introducción

Siguiendo con la letra R, en la entrada anterior se introdujo el concepto de realización referido a los Diagramas de
Clases, que son herramientas de documentación de la estructura estática de una aplicación informática, según los
principios de UML. En esta entrada se introducirá el concepto de relación de UML.

Las relaciones son el tercer pilar fundamental en el que se basan los Diagramas de Clases, después de las clases
mismas y los interfaces. Las relaciones se aplican exclusivamente entre clases y pueden ser binarias o de orden
superior.

Decir que dos clases están relacionadas entre si viene a significar que esas clases tienen algo que ver entre sí. De
cómo sea la naturaleza de la relación definirá un tipo u otro de vinculación. De lo que se trata aquí es de identificar,
caracterizar y ejemplarizar cada una de ellas.

Asociación

La forma más sencilla de relación es aquella denominada asociación. La asociación se utiliza para expresar
simplemente que dos clases están vinculadas entre sí. En ella se expresa la navegabilidad entre la clase origen y la
clase destino, y la cardinalidad de la clase destino en la asociación.
El Diagrama de Clases del ejemplo anterior permite representar, en el contexto de UML,  el hecho de que una mesa
tiene 4 sillas a juego.  Obsérvese que en el diagrama no se expresa más vinculación que la navegabilidad que expresan
que las sillas van con la mesa, ni más restricción que la cardinalidad que expresa que con la mesa van cuatro sillas.

En la figura se observa como aparece el rol silla para vincular la clase Silla a la clase Mesa. Esta vinculación se
sustanciará convirtiendo el rol del la relación en un atributo de la clase origen que referencia la clase destino.

Estrictamente hablando una asociación no tiene que ser únicamente de navegabilidad en un solo sentido, Puede ser en
ambos con los que ambas clases son origen y destino a la vez. Un tipo especial de esta situación acontece cuando la
asociación involucra más de dos clases. En ese caso todas las clases asociadas son origen y destino a la vez.

El ejemplo anterior se modeliza la siguiente situación.

Cada aula alberga uno o más grupos a los que se imparten una o más asignaturas, a su vez cada grupo tiene asignada
una o más aulas en donde recibe docencia de una o más asignaturas, y además cada asignatura se imparte en una o
más aulas a uno o más grupos.

En las asociaciones, el peso de la definición de la relación recae enteramente sobre la parte [TODO]:

La vinculación de define en la parte [TODO] que incluye la referencia a la parte [PARTE].

La multiplicidad de  la parte [PARTE] debe expresarse en la parte [TODO] a través de algún tipo de colección, a la
cual debe de acompañar, en la mayoría de los casos, al menos de sendos métodos para incorporar/desvincular
elementos.

El concepto de asociación entre clases permite representar la semántica de muchas situaciones. Sin embargo la
realidad ofrece situaciones mucho más complejas cuyo modelizado exige evolucionar este concepto de
asociación introduciendo el concepto de pertenencia y el concepto de autonomía.

Pertenencia

Para explicar la semántica de pertenencia de una relación ayuda el plantearla desde un punto de vista de binomio
[PARTE] – [TODO]. Desde esta perspectiva una relación, básicamente binaria, está constituida por un componente
[PARTE] y un componente [TODO].

El componente [PARTE] se caracteriza porque es una pieza, en el sentido constructivo, del componente [TODO]. El
componente [TODO] tiene la capacidad de albergar al componente [PARTE] integrándolo dentro de sí mismo.
Antes de seguir un buen ejemplo ayudaría a fijar los conceptos de [PARTE] y [TODO] en una relación entre clases.

Bien, considérese el ejemplo de la relación de un matrimonio respecto de sus cónyuges. En esa relación el matrimonio
seria la parte [TODO], mientras que los cónyuges serian la parte [PARTE] de la relación. Trasladandando el ejemplo al
contexto UML, si se considera la clase Matrimonio y la clase Conyuge, y dejando para más adelante la explicación de
los detalles involucrados en la relación, el Diagrama de Clases que representaría esta relación podría ser el siguiente:

Otro ejemplo. Considérese la relación que existe entre los operarios de una fábrica y las secciones de trabajo de la
misma. En este caso cada operario trabaja en un momento dado en una sección de la fábrica, aunque después puede
trabajar en otra. Así pues, cada sección de la fabrica alberga un número determinado de operarios.

Autonomía

De lo que se trata de dilucidar en este apartado es, qué ciclo de vida tienen los objetos de la clase [TODO] y qué ciclo
de vida tienen los objetos de la clase [PARTE]. Dependiendo de cómo se concreta esta cuestión la semántica de la
situación define un tipo de asociación u otro entre las respectivas clases.

En concreto, la regla para determina el tipo de asociación es fijarse en el ciclo de vida de los objetos de la clase
[TODO], en concreto en el momento en que se destruye. La pregunta que hay que hacerse es ¿Qué ocurre con los
objetos de la clase [PARTE] cuando se destruye la parte [TODO]?. La respuesta a esta pregunta determina dos tipos de
asociaciones:

Agregación. Cuando el objeto [TODO] se destruye, los objetos [PARTE] pueden seguir existiendo autónomamente.
Composición. Cuando el  objeto [TODO] se destruye también desaparecen los objetos [PARTE], cuya existencia ya
no tiene sentido.

Agregación

Es un tipo de asociación en donde el ciclo de vida de la parte [TODO] está desvinculado del ciclo de vida de la parte
[PARTE], de tal manera que cuando desaparece la parte [TODO] la parte [PARTE] puede seguir existiendo. A este tipo de
vinculación se la denomina también asociación débil o asociación funcional.

Para ejemplarizar este tipo de relación considérese el caso expuesto anteriormente respecto de los operarios y las
secciones de una fábrica.
En el ejemplo, la clase Seccion referencia las instancias de la clase Operario, que se corresponden con los operarios
que están trabajando en ella.

Tomando como referencia el ejemplo anterior, se inferirán las correspondientes reglas respecto a las agregaciones en
los diagramas de clases:

La clase [TODO] se identifica con un rombo en blanco.

La clase [PARTE] se identifica con una flecha de navegación.
La relación se identifica por su rol situado en la clase [PARTE].
La clase [TODO] no tiene un atributo para expresar el rol.
La multiplicidad de la clase [TODO] es diferente de la unidad.
El constructor de la clase [TODO] no instancia la clase [PARTE].
El destructor de la clase [TODO], cuando existe, no altera la clase [PARTE].

La codificación del Diagrama de Clases del ejemplo anterior en Java podría corresponderse con el siguiente código:

1 class Operario {
2    ...
3 }
4 class Seccion {
5    ...
6    ArrayList<Operario> listaOperarios = new ArrayList<Operario>();
7    ...
8 }

Como se puede observar en el código anterior la multiplicidad de la clase [TODO] no se expresa porque depende de la
restricciones funcionales de la clase que instancia la parte [TODO].

Composición

Es un tipo de asociación en donde el ciclo de vida de la parte [PARTE] está vinculado del ciclo de vida de la parte
[TODO], de tal manera que cuando desaparece la parte [TODO] la parte [PARTE] también desaparece. A este tipo de
vinculación se la denomina también asociación fuerte o asociación existencial.

Para ejemplarizar este tipo de relación considérese el caso expuesto anteriormente respecto de los cónyuges y el
matrimonio.

En el ejemplo, la clase Matrimonio referencia cada una de las dos instancias de la clase Conyuge, generalmente a

través de algún tipo de documento en el registro civil.

Tomando como referencia el ejemplo anterior, se inferirán las correspondientes reglas respecto a las agregaciones en
los diagramas de clases:

La clase [TODO] se identifica con un rombo en negro.

La clase [PARTE] se identifica con una flecha de navegación.
La relación se identifica por su rol situado en la clase [PARTE].
La clase [TODO] no tiene un atributo para expresar el rol.
La multiplicidad de la clase [TODO] es siempre la unidad.
El constructor de la clase [TODO] suele instanciar la clase [PARTE].
 El destructor de la clase [TODO], cuando existe, destruye también la clase [PARTE].

La codificación del Diagrama de Clases del ejemplo anterior en Java podría corresponderse con el siguiente código:

1 class Conyuge {
2    ...
3 }
4 class Matrimonio {
5    ...
6    Conyuge[] conyuge = new Conyuge[2];
7    ...
8    Matrimonio() {
9       conyuge[0] = new Conyuge();
10       conyuge[1] = new Conyuge();
11       ...
12    }
13 }

Al igual que en la agregación la multiplicidad de la clase [TODO] no se expresa porque depende de la restricciones
funcionales de la clase que instancia la parte [TODO].

A partir de aquí.

Con esta sesión doy por finalizada esta serie de entradas dedicada a los Diagramas de Clases UML. Ahora lo que
quizás procede es la realización de algunos Ejercicios de Modelado de Diagramas de Clases para reflejar en la práctica
lo dicho más arriba.

Pero eso será en otra ocasión.

Saludos.

06/06/2013  Responder

UML – Diagramas de Clases – Realización

            5 Votes

Introducción

En la entrada anterior se introdujo el concepto de herencia asociado a los Diagramas de Clases, que son herramientas

de documentación de la estructura estática de una aplicación informática, según los principios de UML. En esta
entrada se introducirá la el concepto de realización de UML.
Concepto

El concepto de realización refiere la implementación de un interfaz por parte de una clase. Este proceso tiene dos
partes, en primer lugar la clase debe declarar la implementación del interfaz. En segundo lugar la clase debe de
definir el cuerpo de los métodos impuestos por el interfaz.

Representación

En los Diagramas de Clases no se expresa el contenido del cuerpo de los métodos, únicamente se expresa la
declaración de que la clase implementa un interfaz.

En el Diagrama de Clases del ejemplo que se expone a continuación se puede observar como la clase Zapato
implementa el interfaz ICascador que permite al zapato utilizarlo como cascanueces.

Obsérvese como la relación entre la clase y el interfaz implementado se representa como una linea de trazos dirigida,
que parte de la clase y termina en el interfaz con una punta de flecha cerrada. Por supuesto, los métodos impuestos
por el interfaz no se representan en la clase.

Codificación

El código fuente Java equivalente al diagrama anterior podría corresponder al que se expone a continuación.

1 public interface ICascador {

2    public void cascarNueces();
3 }
4 class Zapato implements ICascador {
5    private int talla;
6    private String color;
7    public void cascarNueces() {
8       System.out.println("Crick Crack");
9    }
10 }

En la siguiente entrega …  ¿Hablaremos del gobierno?

Pues va a ser que no o sí, aunque la idea es abordar el tema de las relaciones entre de clases.

Bon apetit!