01_uml – diagramas de clases – ejercicio 2 – con el mazo dando

8/16/2019 01_UML – Diagramas de Clases – Ejercicio 2 – Con El Mazo Dando

1/17

20/5/2016 UML – Diagramas de Clases – Ejercicio 2 – Con el mazo dando

https://joanpaon.wordpress.com/2013/07/24/uml-diagrama-de-clases-ejercicio-2/ 1/17

Con el mazo dando

Haciendo lo que hay que hacer

UML – Diagramas de Clases – Ejercicio 2

i9 Votes

Introducción

En el ejercicio anterior (h偂ps://joanpaon.wordpress.com/2013/07/01/uml‑diagrama‑de‑clases‑ejercicio‑1/) 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 entreclases. 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 clasesque modele la estructura necesaria para manejar los datos de los encuentros de un torneo detenis de mesa en la modalidad de sorteo y eliminatoria.

https://joanpaon.wordpress.com/https://joanpaon.wordpress.com/https://joanpaon.wordpress.com/https://joanpaon.wordpress.com/https://joanpaon.wordpress.com/author/joanpaon/https://joanpaon.wordpress.com/2013/07/24/uml-diagrama-de-clases-ejercicio-2/https://joanpaon.wordpress.com/2013/07/01/uml-diagrama-de-clases-ejercicio-1/https://joanpaon.wordpress.com/


2/17



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 defederado de la federación de la que es miembro.

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

De cada encuentro interesa conocer los oponentes , el ganador y el resultado final delmarcador 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 lainformación posible. A veces es cuestión de aplicar el sentido común , a veces es cuestión deunir 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 deexperiencia.

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

1. Nombre del proyecto – Torneo2. Nombre del diagrama – EncuentrosTorneo3. Ítems – Elementos significativos del enunciado.

EncuentroFecha del torneo

JugadorNúmero de federado


3/17



PersonaNifNombre completoFecha de nacimientoDiaMesAño

DniLetraOponenteResultado finalPartida

Diseño de clases

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

Se procederá a identificar las clases a partir del enunciado y de encapsular en ellas lainformación relacionada. Este paso se realizará considerando de forma aislada unas clases deotras. 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áscomplejas.

Clase Nif

(h偂ps://joanpaon.files.wordpress.com/2013/06/nif.png)

Clase Fecha

https://joanpaon.files.wordpress.com/2013/06/nif.png


4/17



(h偂ps://joanpaon.files.wordpress.com/2013/06/fecha.png)

Clase Nombre

(h偂ps://joanpaon.files.wordpress.com/2013/06/nombre.png)

Clase Marcador

(h偂ps://joanpaon.files.wordpress.com/2013/07/marcador.png)

Clase Persona

https://joanpaon.files.wordpress.com/2013/07/marcador.pnghttps://joanpaon.files.wordpress.com/2013/06/nombre.pnghttps://joanpaon.files.wordpress.com/2013/06/fecha.png


5/17



(h偂ps://joanpaon.files.wordpress.com/2013/06/persona.png)

Clase Jugador

(h偂ps://joanpaon.files.wordpress.com/2013/07/jugador.png)

Clase Partida

(h偂ps://joanpaon.files.wordpress.com/2013/07/partida.png)

Clase Encuentro

https://joanpaon.files.wordpress.com/2013/07/partida.pnghttps://joanpaon.files.wordpress.com/2013/07/jugador.pnghttps://joanpaon.files.wordpress.com/2013/06/persona.png


6/17



(h偂ps://joanpaon.files.wordpress.com/2013/07/encuentro.png)

Clase Torneo

(h偂ps://joanpaon.files.wordpress.com/2013/07/torneo.png)

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

Herencia

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

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

https://joanpaon.files.wordpress.com/2013/07/torneo.pnghttps://joanpaon.files.wordpress.com/2013/07/encuentro.png


7/17



Persona – Jugador

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

la clase Persona.

(h偂ps://joanpaon.files.wordpress.com/2013/07/persona‑jugador.png)

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

Asociación

Una vez se han resuelto las relaciones de herencia le toca el turno a las relacionesde asociación. Se procederá siempre abordando primero las triviales o más simples ycontinuando por las demás. Para que resulte más claro, el análisis se realizará considerandolas 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 otramanera, la clase Persona tiene una referencia a un objeto de la clase Fecha .

Las asociaciones se representan con unalínea de trazo continuo

que une las clases vinculadas.

https://joanpaon.files.wordpress.com/2013/07/persona-jugador.png


8/17



(h偂ps://joanpaon.files.wordpress.com/2013/07/persona‑fecha‑0.png)

Roles

Así considerado, el atributo fechaNac de la clase Persona pasa a ser el rol de la relación quevincula a ambas clases. Por lo tanto, desaparece de la clase Persona y aparece en la línea devinculació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 laotra. Es evidente que la clase Fecha no tiene información de la clase Persona por lo que lanavegabilidad 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 lanavegabilidad 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

https://joanpaon.files.wordpress.com/2013/07/persona-fecha-2.pnghttps://joanpaon.files.wordpress.com/2013/07/persona-fecha-1.pnghttps://joanpaon.files.wordpress.com/2013/07/persona-fecha-0.png


9/17



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

“¿Por cada instancia de una de las dos clases cuántas instancias de la otra clase pueden en extremointervenir 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 : 1Cuántas fechas de nacimiento como máximo tiene cada persona: 1Cuántas personas pueden nacer como mínimo en una determinada fecha: 0Cuá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 deellas. Obsérvese también que cuando la cardinalidad máxima es múltiple y la cardinalidadmí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 deagregación o de composición. Para que la relación sea de composición es condición necesariaque la cardinalidad de la parte [TODO] sea 1. Como este no es el caso la relación es deagregación.

https://joanpaon.files.wordpress.com/2013/07/persona-fecha-3.png


10/17



(h偂ps://joanpaon.files.wordpress.com/2013/07/persona‑fecha‑4.png)Obsérvese que la parte [TODO] se identifica dibujando un rombo acostado en la línea de larelación. Obsérvese también que el se ha representado el rombo en blanco para identificar unarelación de agregación.

Y este es básicamente el proceso a seguir para analizar las relaciones de asociación entre lasclases de un diagrama de clases UML. En situaciones más complejas habrá que reconsiderareste 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 lacardinalidad 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 , laexistencia de la parte [PARTE] , el objeto de la clase Nif , ya no puede ser utilizado y deberíadesaparecer también. Esta dependencia existencial apunta a una relación de tipoComposición.

(h偂ps://joanpaon.files.wordpress.com/2013/07/16.png)

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

Persona – Nombre

https://joanpaon.files.wordpress.com/2013/07/16.pnghttps://joanpaon.files.wordpress.com/2013/07/persona-fecha-4.png


11/17



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

(h偂ps://joanpaon.files.wordpress.com/2013/07/17.png)

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

Encuentro – Jugador

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

(h偂ps://joanpaon.files.wordpress.com/2013/07/encuentro‑jugador1.png)

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

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

Encuentro – Marcador

https://joanpaon.files.wordpress.com/2013/07/encuentro-jugador1.pnghttps://joanpaon.files.wordpress.com/2013/07/17.png


12/17



En el contexto del supuesto de este ejercicio, en un encuentro se celebran tres partidas , elprimer jugador que llegue a 21 puntos gana la partida. El jugador que gane más partidas deun encuentro gana el encuentro. Obsérvese que no puede haber empate ni en las partidas nien 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 alos puntos del segundo jugador. Uno de ellos debe contener el número 21 y corresponderá alganador de la partida y el otro valor debe estar situado entre 0 y 20.

(h偂ps://joanpaon.files.wordpress.com/2013/07/encuentro‑marcador.png)

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

Torneo – Fecha

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

(h偂ps://joanpaon.files.wordpress.com/2013/07/torneo‑fecha.png)

Torneo – Encuentro

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

https://joanpaon.files.wordpress.com/2013/07/torneo-fecha.pnghttps://joanpaon.files.wordpress.com/2013/07/encuentro-marcador.png


13/17



(h偂ps://joanpaon.files.wordpress.com/2013/07/torneo‑encuentro.png)Nótese que se ha establecido una relación de composición debido a que los encuentroscelebrados 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 algunode los jugadores que han participado en él.

Clase Partida

Llegados a este punto todas las relaciones entre clases están establecidas. A pesar de queinicialmente se modeló la clase Partida para recoger los datos de los participantes de cadapartida y de su resultado, desde el punto de vista al que se ha llegado siguiendo elrazonamiento 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 esmuy normal y conveniente realizar continuos replanteos en la medida que el avance en elrazonamiento clarifica progresivamente la situación.

Interfaces

https://joanpaon.files.wordpress.com/2013/07/torneo-encuentro.png


14/17



Terminado el diseño de los datos encapsulados en las relaciones entre las diferentes clases elsiguiente paso es detectar las posibles capacidades funcionales que deben reunir dichas clasesexpresadas 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 elcontenido de un determinado método, toda clase que represente a una persona que sabe jugara 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 respuestaviene a través de los interfaces. Un interfaz es como un título que faculta a su poseedor en unadeterminada habilidad. Así se reconoce a un jugador por su título, como se conoce a unmédico por su título universitario, un extintor eficaz por su certificado de industria, lareparación de un coche por su factura, etc.

(h偂ps://joanpaon.files.wordpress.com/2013/07/ijugador.png)

En este caso se convendrá en que el interfaz que inviste a una persona como un jugador detenis de mesa se llama IJugador y que el método que corresponde a esa capacidad sellama jugarTenisMesa.

Realizaciones

En esta fase se va a señalar qué clases deben implementar las capacidades funcionalesdefinidas 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 siguienterepresentación.

https://joanpaon.files.wordpress.com/2013/07/ijugador.png


15/17



(h偂ps://joanpaon.files.wordpress.com/2013/07/jugador‑ijugador.png)Adviértase que la clase y el interfaz están vinculados por una línea de trazo discontinuo , conuna punta de flecha cerrada en el lado del interfaz y que en ningún lado se expresa elcontenido del método impuesto por el interfaz.

Diagrama completo

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

https://joanpaon.files.wordpress.com/2013/07/encuentrostorneo.pnghttps://joanpaon.files.wordpress.com/2013/07/jugador-ijugador.png


16/17



(h偂ps://joanpaon.files.wordpress.com/2013/07/encuentrostorneo.png)

Este ejercicio está disponible como un archivo ZIP(h偂ps://dl.dropboxusercontent.com/u/11424209/Torneo.zip) que se corresponde con unproyecto de la herramienta UML llamada Modelio (h偂p://www.modeliosoft.com/). Paraabrirlo 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 Diagramade clases UML.

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

Saludos.

2 pensamientos en “UML – Diagramas de Clases –

Ejercicio 2 ”

pepe flores | 11/01/2013 en 22:44Para mi ha sido muy muy útil, quería saber si tienes más ejercicios de este tipo pero con

bases de datos ( con alguna clase que sea conexión por ejemplo y use bd ), ya que noencuentro por mas que miro y no tengo muy claro las relaciones que tendría que hacer conesta clase.

Responder

Vitmar Aliaga | 12/14/2015 en 16:46 buenisimo… me esta ayudando conprender mas el tema de diagrama de clases… Gracias…

https://joanpaon.wordpress.com/2013/07/24/uml-diagrama-de-clases-ejercicio-2/https://joanpaon.wordpress.com/tag/unified-modeling-language/https://joanpaon.wordpress.com/tag/uml/https://joanpaon.wordpress.com/tag/programacion/https://joanpaon.wordpress.com/tag/java/https://joanpaon.wordpress.com/tag/diagrama-de-clases/https://joanpaon.wordpress.com/category/uml/https://joanpaon.wordpress.com/category/java/https://wordpress.com/about-these-ads/https://googleads.g.doubleclick.net/pcs/click?xai=AKAOjsuey5nLA7LNedV2mUxQzcNipn4kSndAdB3YMIZRTi7PlHsLFnfRDkusf1ePgTFQRwR5-g3lH57zzQUr09L9HrRH6rdWE1lnw6LP5SSHYwM6qEm_Vtf2XCeLJUjbmppwy04yiVGY3hJTPxxk-PkOpUyWL_iWZPj2qZDSyQqtDtPSVtJtlSR1UOSTLaWvd3-NdLn5eA&sai=AMfl-YRRo1465fUKwhwGAYxos2P6abR2nnl6g719Awnn5vNZeB_EeRso7nOdwkgAA70cJuH2ZeuQtlHPEg&sig=Cg0ArKJSzJnbWzwZKYUP&adurl=https://wordpress.com/create%3Futm_source%3Dhouseads%26utm_campaign%3Dcreate-website_passion_mrec_enhttps://joanpaon.wordpress.com/2013/07/24/uml-diagrama-de-clases-ejercicio-2/?relatedposts_hit=1&relatedposts_origin=416&relatedposts_position=0&replytocom=105#respondhttps://plus.google.com/109770230841439054087https://joanpaon.wordpress.com/2013/07/24/uml-diagrama-de-clases-ejercicio-2/?relatedposts_hit=1&relatedposts_origin=416&relatedposts_position=0&replytocom=93#respondhttps://plus.google.com/108104614314771536463http://www.modeliosoft.com/https://dl.dropboxusercontent.com/u/11424209/Torneo.ziphttps://joanpaon.files.wordpress.com/2013/07/encuentrostorneo.png


17/17


Responder

Crea un blog o un sitio web gratuitos con WordPress.com. | El tema Misty Lake.
https://wordpress.com/themes/misty-lake/https://wordpress.com/?ref=footer_websitehttps://joanpaon.wordpress.com/2013/07/24/uml-diagrama-de-clases-ejercicio-2/?relatedposts_hit=1&relatedposts_origin=416&relatedposts_position=0&replytocom=105#respond

01_uml – diagramas de clases – ejercicio 2 – con el mazo dando

Documents