Con 

el mazo dando
Haciendo lo que hay que hacer

Inicio Acerca de mí

DIAGRAMA DE CLASES
Estadísticas del
blog
07/24/2013
334.885 visitas

UML – Diagramas de Clases – Ejercicio 2

Introducción Páginas

Acerca de mí
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
marzo 2022
ejercicio se va a ir un poco más allá, involucrando al interfaz
L M X J V S D
como garante de la realización de especi몭caciones
funcionales.
  1 2 3 4 5 6

7 8 9 10 11 12 13
Enunciado
14 15 16 17 18 19 20

Crear un proyecto UML llamado Torneo en el que se diseñe un 21 22 23 24 25 26 27

diagrama de clases que modele la estructura necesaria para
28 29 30 31  
manejar los datos de los encuentros de un torneo de tenis de
mesa en la modalidad de sorteo y eliminatoria.
« Jul    

Privacidad y cookies: este sitio utiliza cookies. Al continuar utilizando esta web, aceptas su
uso. Cerrar y aceptar
Archivos
Para obtener más información, incluido cómo controlar las cookies, consulta aquí: Política
Para obtener más información, incluido cómo controlar las cookies, consulta aquí: Política
de cookies julio 2020 (3) Seguir
agosto 2015 (1)

septiembre 2014 (1)

septiembre 2013 (1)

agosto 2013 (13)

julio 2013 (29)

junio 2013 (15)

Del torneo interesa conocer la fecha del torneo, los encuentros mayo 2013 (6)

celebrados y el ganador. De cada jugador, que debe de marzo 2009 (3)

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 Buscar …
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.
Entradas recientes
De cada encuentro interesa conocer los oponentes, el ganador
Cómo instalar
y el resultado 몭nal del marcador de cada una de las tres
OpenJDK 14.0.2
partidas que se juegan a 21 puntos. para Windows
07/17/2020

Análisis del enunciado How to install

OpenJDK 14.0.2
for Windows
El primer paso a realizar consiste en leer detenidamente el
07/16/2020
enunciado y de él extraer toda la información posible. A veces
¿ Y eso… pa’qué ?
es cuestión de aplicar el sentido común, a veces es cuestión de
07/14/2020
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 How to setup nodejs
with
cuestión de razonar por aproximaciones sucesivas y de
Netbeans 8.1Beta
experiencia. 08/13/2015

NetBeans 8.0.1 is
Bien, parece que el enunciado re몭ere únicamente un modelado
already out there!
de datos, no de comportamiento, por lo que se procederá a 09/11/2014
realizar una lista de los elementos más signi몭cativos para el
proyecto que se puedan extraer del enunciado.

1. Nombre del proyecto – Torneo

Categorías
2. Nombre del diagrama – EncuentrosTorneo
3. Ítems – Elementos signi몭cativos del enunciado. HTML (13)

Encuentro
 Encuentro Java (34)
Fecha del torneo
Mobile OS (1)
Jugador
Número de federado NetBeans (25)

Persona NodeJS (1)

Nif
Pensamientos (8)
Nombre completo
Fecha de nacimiento PHP (2)
Dia Productivity (3)
Mes
Tizen (2)
Año
Dni UML (10)
Letra
Windows (9)
Oponente
Resultado 몭nal
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 identi몭car 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 몭jarse 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 몭echa que representa esta relación va desde la clase hija
a la clase madre, tiene línea continua,  punta de 몭echa
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 clari몭cador 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 몭echa 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 re몭ere 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 identi몭ca 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 identi몭car 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 identi몭ca 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 identi몭car 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 codi몭car 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
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 몭gura

la tiene que ostentar alguno de los jugadores que han participado
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 clari몭ca 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 e몭caz por su certi몭cado 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 de몭nidas 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 몭echa cerrada
en el lado del interfaz y que en ningún lado se expresa el
contenido del método impuesto por el interfaz.

Diagrama completo

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.

Publicado en Java, UML | Etiquetado Diagrama de clases, Java, Programación, UML,

Uni몭ed Modeling Language | 4 comentarios

07/01/2013

UML – Diagramas de Clases – Ejercicio 1

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 re몭ere únicamente un modelado

de datos, no de comportamiento, por lo que se procederá a
realizar una lista de los elementos más signi몭cativos para el
proyecto que se puedan extraer del enunciado.

1. Nombre del proyecto – Asociacion

2. Nombre del diagrama – AltaAsociacion
3. Ítems – Elementos signi몭cativos 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 identi몭car 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 de몭nidas 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 몭echa que representa
esta relación va desde la clase hija a la clase madre, tiene
linea continua, punta de 몭echa 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 clari몭cador 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 몭echa 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 re몭ere 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
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.

Publicado en Java, UML | Etiquetado Diagrama de clases, IDE, Java, POO,

Programación, Uni몭ed Modeling Language | 22 comentarios

06/06/2013

UML – Diagramas de Clases – Relaciones

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 signi몭car

que esas clases tienen algo que ver entre sí. De cómo sea la
naturaleza de la relación de몭nirá un tipo u otro de vinculación.
De lo que se trata aquí es de identi몭car, 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 몭gura 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 de몭nición de la relación recae

enteramente sobre la parte [TODO]:

La vinculación de de몭ne 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 몭jar 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 de몭ne un tipo
de asociación u otro entre las respectivas clases.

En concreto, la regla para determina el tipo de asociación es

몭jarse 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 identi몭ca con un rombo en blanco.

La clase [PARTE] se identi몭ca con una 몭echa de
navegación.
La relación se identi몭ca 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 codi몭cació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 identi몭ca con un rombo en negro.

La clase [PARTE] se identi몭ca con una 몭echa de
navegación.
La relación se identi몭ca 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 codi몭cació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 몭nalizada 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 re몭ejar en la práctica lo dicho más
arriba.

Pero eso será en otra ocasión.

Saludos.

Publicado en Java, UML | Etiquetado Clase, Diagrama de clases, Diagramas de

clases, Java, POO, Programación, UML | Deja un comentario

05/28/2013

UML – Diagramas de Clases – Clases

Introducción

En la entrada anterior se introdujeron los conceptos asociados a

los Diagramas de Clases como herramientas de documentación
de la estructura estática de una aplicación informática según los
principios de UML.

En esta entrega se va a describir cómo es la representación de

las clases en los Diagramas de Clases, mostrando varios
ejemplos.

Representación de una clase

Las clases se representan en UML como una caja con varias

zonas:

1. Zona superior. En ella se escribe el identi몭cador de la

clase, generalmente un nombre en singular que empieza
por mayúscula. Adicionalmente se pueden representar
también la visibilidad de la clase y el estereotipo aplicado.
2. Zona intermedia. En ella aparecen los atributos. Cada
atributo identi몭ca una propiedad de la clase. Un atributo
se representa con tres elementos:
Identi몭cador, generalmente un nombre en
singular que empieza por minúscula.
 Tipo de datos, re몭ere la naturaleza del atributo.
Visibilidad, expresa el alcance del atributo en el
sistema.
3. Zona inferior. En ella aparecen
las operaciones o métodos. Expresan las capacidades
funcionales de una clase y se nombran con un verbo en
in몭nitivo que empieza por minúscula y que expresa una
acción.

La imagen siguiente corresponde a la representación de la

clase Perro. Esta clase tiene un atributo de tipo
texto llamado nombre y un método llamado ladrar que no tiene
parámetros de llamada ni valor de retorno.

Obsérvese el signo más a la izquierda del atributo y también a la

izquierda del método, indica visibilidad pública para ambos. Obsérvese
también que no se ha expresado la visibilidad de la clase.

El proceso de Codi몭car esta clase en un lenguaje

de programación orientado a objetos como Java resulta
sencillo, por ahora, y se correspondería con el siguiente código:

1 class Perro {
2    public String nombre;
3    public void ladrar() {
4       System.out.println("¡Guau, guau!");
5    }
6 }

El siguiente grá몭co muestra la clase de ejemplo Nif que permite

representar los datos de un NIF que son el número de DNI y el
dígito de control.
En la clase del diagrama anterior el número de DNI está
representado por el atributo dni que es de tipo entero, el dígito
de control está representado por el atributo letra que es de
tipo carácter. Ambos tienen visibilidad pública y, como antes, no
se ha expresado visibilidad para la clase.

La codi몭cación del diagrama de clases para la clase

anterior podría corresponderse con el siguiente código:

1 class Nif {
2    public int dni;
3    public char letra;
4 }

El siguiente grá몭co muestra la clase de ejemplo MiPrograma que

ejecuta un programa Java que muestra un número de serie.

En la clase del diagrama anterior se puede apreciar:

La clase se llama MiPrograma y no tiene expresada su

visibilidad.
Un atributo llamado numSerie de tipo String que está
marcado con visibilidad protegida. El subrayado signi몭ca
que el atributo es estático, lo cual tiene por consecuencia
que se puede utilizar sin necesidad de instanciar la
clase.
Un método llamado main que tiene como parámetro
formal un array de String llamado arg y no tiene valor de
retorno. Este método también está marcado como estático
con lo que, al igual que el atributo, puede ser llamado sin
necesidad de instanciar la clase. En este caso, el método
main tiene visibilidad pública.

La codi몭cación del Diagrama de Clases para la clase

anterior podría corresponderse con el siguiente código:

1 class MiPrograma {
2    protected static String numSerie;
3    public static void main(String[] arg) {
4       System.out.printf("Serie: %s\n", numSerie);
5    }
6 }
En la siguiente entrega se tratarán los interfaces en los
Diagramas de Clases.

¿Te ha resultado útil esta información?

Mucho, es justo lo que estaba buscando.

Poco, no es lo que necesito.

Vote View Results Crowdsignal.com

Publicado en UML | Etiquetado Diagrama de clases, Java, UML | Deja un comentario

Crea un blog o un sitio web gratuitos con WordPress.com.