umlToJava v2 PDF

Programación Orientada a Objetos 1
Notación UML para modelado Orientado a

Objetos
Universidad Rey Juan Carlos – curso 04/05 – Soto Montalvo

2 Notación UML para modelado Orientado a Objetos
Índice
1.1. ¿Qué es UML?.................................................................................................. 3

1.2. ¿Por qué interesa UML en la asignatura de Programación Orientada a
Objetos? ........................................................................................................................ 3
1.3. ¿Qué se va a modelar? ...................................................................................... 3
1.4. Diagramas......................................................................................................... 4
1.4.1. Diagramas de Clases................................................................................. 4
1.4.2. Diagramas de Objetos............................................................................... 5
1.4.3. Diagramas de Interacción ......................................................................... 6
1.4.3.1. Diagramas de secuencia........................................................................ 6
1.4.3.2. Diagramas de colaboración .................................................................. 8
1.5. Clases................................................................................................................ 8
1.5.1. Clases Abstractas...................................................................................... 9
1.5.2. Interfaces .................................................................................................. 9
1.6. Objetos............................................................................................................ 10
1.7. Relaciones....................................................................................................... 10
1.7.1. Detalles ................................................................................................... 10
1.7.1.1. Navegabilidad..................................................................................... 11
1.7.1.2. Multiplicidad ...................................................................................... 11
1.7.1.3. Rol ...................................................................................................... 12
1.7.2. Composición........................................................................................... 13
1.7.3. Uso.......................................................................................................... 13
1.7.4. Asociación .............................................................................................. 13
1.7.5. Herencia.................................................................................................. 14
1.8. Recapitulación ................................................................................................ 15
1.9. Consideraciones.............................................................................................. 16
1.10. Bibliografía................................................................................................. 17

1.1. ¿Qué es UML?
El Lenguaje Unificado de Modelado (UML, Unified Modeling Language) es un

lenguaje estándar, basado en una notación gráfica, que se utiliza para modelar software.
Es un lenguaje de propósito general que pretende ser un estándar mundial y se

utiliza para visualizar, especificar, construir y documentar las diferentes “piezas” de un
sistema.
¿Qué es un modelo? Una simplificación de la realidad.
¿Por qué se modela? Se construyen modelos para poder entender mejor el

sistema a desarrollar, o bien, un sistema desarrollado.
1.2. ¿Por qué interesa UML en la asignatura de Programación Orientada a

Objetos?
En la asignatura de Programación Orientada a Objetos se aprende un nuevo

paradigma de programación: el paradigma orientado a objetos. A su vez, se utiliza el
lenguaje Java para implementar el código de los programas orientados a objetos.
Para modelar los programas de forma gráfica, viendo las relaciones entre las
clases y cómo colaboran unos objetos con otros, se prefiere utilizar una notación
estándar. De esta manera, el alumno va conociendo parte de la notación, UML en este
caso, lo cual le será útil por varias razones:
Le permite ir familiarizándose con un lenguaje de modelado estándar que

verá en otras asignaturas de la titulación.
Le permite entender modelos con esta notación.
Por todo ello, se verá cómo implementar en código Java un modelo diseñado con
UML. De esta manera, se podrán hacer diagramas modelando los programas orientados
a objetos que se implementen con el lenguaje Java.
1.3. ¿Qué se va a modelar?
Se presentará una selección de las características más representativas de UML.

De éstas no se detallará todo de forma completa, sino sólo aquello que nos interese para
representar nuestros diseños orientados a objetos implementados con el lenguaje Java.

Además, conviene dejar claro que:
• UML es un lenguaje de modelado
• Java es un lenguaje de implementación
Por lo tanto, no existe una representación única para código Java, ni tampoco
unas reglas exactas de “dado cierto código, entonces cierta representación”, que se
puedan seguir siempre. De hecho, dos modelados diferentes pueden tener el mismo
código asociado, por lo que no “hay viaje de vuelta”. Es decir, dado un código no es
posible determinar las relaciones entre las diferentes clases y, por lo tanto, cual es la
representación UML. Se trata de un modelado a nivel conceptual.
El estándar UML no pide que se indique todo en los diagramas, sino que lo que
se refleje en ellos sea cierto.
En nuestro caso, dado un programa orientado a objetos nos interesa tanto su

visión estática como su visión dinámica. La visión estática se puede ver como un
conjunto de clases que permiten alcanzar altas cotas de abstracción, encapsulación,
modularidad y jerarquía. Por otra parte, la visión dinámica de un programa se puede ver
como un conjunto de objetos, los cuales colaboran entre sí mediante el
desencadenamiento de instanciaciones y de paso de mensajes.
Por ello, se van a modelar tanto los aspectos estáticos como los aspectos
dinámicos de un programa orientado a objetos.
Los aspectos estáticos se modelan mediante diagramas de clases y diagramas de

objetos. Los primeros se componen de un conjunto de clases y las relaciones entre ellas,
mientras que en los segundos las relaciones se dan entre un conjunto de objetos.
Los aspectos dinámicos se modelan mediante diagramas de interacción. Éstos,

presentan la forma en la que interactúan los diferentes objetos del diagrama.
1.4. Diagramas
1.4.1. Diagramas de Clases
Los diagramas de clases proporcionan una perspectiva estática del código. Se

componen de:
• Clases
o Gráficamente se representan mediante un rectángulo con el nombre de

la clase.
• Relaciones
o De forma gráfica se trata de una línea que une las clases que relaciona.
Un ejemplo de diagrama de clases se presenta en la figura 1.

Ter
Turno Tablero
Jugador
Ficha Coordenada
Figura 1. Diagrama de clases
1.4.2. Diagramas de Objetos
Los diagramas de objetos proporcionan una perspectiva estática de una

ejecución del código. Presentan instantáneas de instancias de los elementos que
aparecen en los diagramas de clases. En definitiva, muestran un conjunto de objetos y
sus relaciones en un momento concreto (“fotografía” de un momento determinado).
Básicamente se componen de:
• Objetos
o De forma gráfica se representa mediante un rectángulo con el nombre del

objeto.
• Relaciones
Un ejemplo de diagrama de objetos se presenta en la figura 2.

:Ter
:Turno
:Tablero
:Coordenada
...
:Jugador
:Coordenada
:Jugador
:Ficha
:Ficha
:Ficha
Figura 2. Diagrama de objetos
La diferencia clara entre un diagrama de clases y un diagrama de objetos es que

el primero representa los aspectos estáticos del sistema, y el segundo los aspectos
estáticos de una interacción concreta entre los objetos.
1.4.3. Diagramas de Interacción
En los diagramas de interacción se puede ver el patrón de comportamiento de un

conjunto de mensajes intercambiados entre un conjunto de objetos, dentro de un
contexto para lograr un propósito. Son dos los tipos de diagramas de interacción:
secuencia y colaboración. Ambos están basados en la misma información, aunque cada
uno enfatiza un aspecto diferente: el diagrama de secuencia destaca la ordenación
temporal de los mensajes y el diagrama de colaboración destaca la organización
estructural (qué objetos colaboran con otros) de los objetos que intercambian mensajes.
1.4.3.1. Diagramas de secuencia
Estos diagramas presentan, ordenados temporalmente, los objetos que participan

en una interacción y los mensajes que se intercambian.
En el diagrama, en cada eje vertical se coloca un objeto. Los mensajes se

representan mediante flechas horizontales de un objeto a otro, donde el retorno se
representa mediante una línea punteada del objeto pasivo al objeto agente del mensaje.
El tiempo fluye de arriba hacia abajo.
Un ejemplo de diagrama de secuencia de presenta en la figura 3.

ter:Ter turno:Turno t:Tablero j:Jugador
jugar()
mostrar()
poner(t)
cambiar()
mostrar()
...
Figura 3. Diagrama de secuencia
Para especificar quién y cuándo se crean los objetos, se utiliza el estereotipo1

“<<create>>”. Como ejemplo se presenta el diagrama de la figura 4.
j:Jugador t:Tablero
poner(t)
<<create>> c:Coordenada
recoger()
poner(c,f)
...
Figura 4. Diagrama de secuencia con estereotipos
1
Estereotipo: mecanismo de extensibilidad de UML para representar una distinción de uso. Es aplicable a
cualquier elemento de modelado.

1.4.3.2. Diagramas de colaboración
Un diagrama de colaboración también muestra la interacción entre los objetos,

pero basándose en las relaciones entre ellos. En la figura 5 se puede ver un ejemplo de
diagrama de colaboración.
5: mostrar()
1: jugar() 2: mostrar()
ter:Ter t:Tablero
4: c am
bi ar(
)
3: poner(t)
turno:Turno
j:Jugador
Figura 5. Diagrama de colaboración
El diagrama de secuencia y el diagrama de colaboración son equivalentes,

ambos muestran una interacción entre los objetos. Simplemente uno de ellos destaca la
ordenación temporal y el otro la estructura de la interacción.
1.5. Clases
Las clases de Java se representarán tal como aparece en la figura 6. Se trata de

un rectángulo dividido en tres partes: la parte superior indica el nombre de la clase; la
parte central contiene los atributos y, por último, la parte inferior presentará las
operaciones de la clase.
NombreClase
Atributos
Operaciones
Figura 6. Representación de una clase con UML
Los niveles de visibilidad de los elementos se representan como sigue:
Privado: -
Protegido: #
Público: +
En la figura 7 se presenta un ejemplo de clase Java junto con su representación

UML.

Ficha class Ficha {
private char color;

-color:char
public void mostrar() {...}
public boolean igual(Ficha ficha) {...}
}
+mostrar()
+igual(Ficha):boolean
Figura 7. Ejemplo de representación de una clase con UML
1.5.1. Clases Abstractas
La representación para las clases abstractas es igual que para las clases normales,
salvo que el nombre de la clase se escribe en cursiva, como se puede apreciar en la
figura 8.
ClaseA
abstract class ClaseA {
...
}
Figura 8. Representación de una clase abstracta con UML
1.5.2. Interfaces
Una interfaz se representa exactamente igual que una clase normal, salvo que se
añade un estereotipo (“<<interface>>” en este caso) en la parte superior del
rectángulo, indicando, precisamente, que se trata de una interfaz y no de una clase
normal. En la figura 9 se presenta un ejemplo.
<<interface>>
InterfazA
interface InterfazA {
...
}
Figura 9. Representación de un interfaz con UML

1.6. Objetos
Para representar una instancia concreta de una clase con la notación UML
también se utiliza un rectángulo con tres partes. En la primera se especifica el nombre
del objeto separado por dos puntos del nombre de la clase, todo ello subrayado. En la
segunda parte aparecerán los atributos del objeto con sus valores. Aquellos atributos
compartidos por todas las instancias de una clase no se añaden aquí. Por último, en la
parte inferior del rectángulo van las operaciones que puede realizar el objeto por
pertenecer a una clase determinada, aunque éstas se pueden omitir.
También es posible, entre otras cosas, omitir la parte central del rectángulo e,
incluso, poner sólo la clase del objeto sin hacer referencia a su nombre.
Ejemplos de esta notación se pueden ver en la figura 10.
f:Ficha f:Ficha
color=`× ´ :Ficha
Figura 10. Notación UML para representar objetos
En nuestro caso utilizaremos la notación en la que aparece simplemente el

nombre de la clase a la que pertenece el objeto (ver figura 11). La razón es porque
¿realmente qué nombre tienen los objetos?, es decir, ¿qué ocurre si se tienen muchas
referencias al mismo objeto? (¿cuál de todos los nombres de esas referencias se refleja
en el diagrama?).
:Ficha
Figura 11. Notación UML para objetos con nombre de clase únicamente
1.7. Relaciones
Cuando se realizan abstracciones son pocas las clases que actúan solas; lo
normal es que existan diferentes relaciones entre las clases.
Entre clases pueden existir cuatro tipos de relación: composición, asociación,

uso y herencia. Las tres primeras se dan cuando objetos de las clases colaboran entre sí.
Sin embargo, el hecho de que exista una relación de herencia entre dos clases no implica
que los objetos de dichas clases colaboren, puede que nunca lo hagan.
1.7.1. Detalles
Se tendrán en cuenta una serie de detalles para todas las relaciones. Estos
detalles deberán acompañar a la relación en los diagramas.

1.7.1.1. Navegabilidad
Se contemplará la navegabilidad en las relaciones, es decir, el sentido de las

mismas. Se representará mediante una flecha, la cual indica que es posible “navegar”
desde el objeto de la clase origen al objeto de la clase destino. Por tanto, el objeto de la
clase origen conoce a los objetos de la clase destino, de manera que podrá invocar
operaciones de éstos. En la figura 12 se presenta un ejemplo de navegabilidad.
class Jugador {
Jugador Ficha
private Ficha ficha;
}
Figura 12. Navegabilidad entre clases
Si se observa la figura anterior, atendiendo solo a la navegabilidad, se puede ver

que un objeto de la clase Jugador conoce a un objeto de la clase Ficha, por
consiguiente, le puede lanzar mensajes, y no al revés.
1.7.1.2. Multiplicidad
La multiplicidad consiste en especificar el rango de cardinalidades que puede

asumir un conjunto, de forma que se indica cuántos objetos de una clase se relacionan
con objetos de la otra clase que forma parte de la relación.
Las restricciones de multiplicidad se deberán indicar en el diagrama. En UML es

posible especificar la multiplicidad de una clase mediante una expresión en la esquina
superior derecha de la misma e, incluso, también se puede especificar la multiplicidad
para los atributos.
En nuestro caso, simplemente reflejaremos la multiplicidad en los diagramas de

clases a nivel de las relaciones entre clases. Por lo tanto, se especificará el número de
instancias de una clase que se relaciona con instancias de otra clase, y se indicará al lado
de la clase cuyo número de instancias se intenta precisar. En la figura 13 se puede ver
un ejemplo.
class Jugador {
Jugador Ficha
}
Figura 13. Multiplicidad de la relación entre clases
Las multiplicidades con valor 1 no se suelen representar, lo cual queda patente

mediante el diagrama presentado en la figura anterior. En este caso, un objeto de la
clase Ficha forma parte de un único objeto de la clase Jugador y, a su vez, un objeto
de la clase Jugador tiene un único objeto de la clase Ficha.
Para representar una multiplicidad de varios elementos, donde no se sabe el

número exacto que tienen, se suele indicar mediante el rango posible. Por ejemplo: “0..

*”,“1..*”, etc. En nuestro caso, simplemente indicaremos la parte máxima del rango y,
además, utilizaremos una restricción2 para indicar el tipo de secuencia de elementos que
es. Por ejemplo: “{array}” (si es una tabla normal), “{ArrayList}” (si se trata de un
objeto de la clase ArrayList de Java), “{List}” (si se trata de un objeto de la clase List
de Java), etc. Un ejemplo se presenta en la figura 14.
Ter Jugador
{array} 2
class Ter {
private final Jugador [ ] JUGADORES = new Jugador[2];

}
Figura 14. Uso de restricciones en la multiplicidad de la relación entre clases
En el ejemplo presentado en la figura 14 se conoce el número exacto de la

multiplicidad. En caso de ser mayor que 1 y no conocerse con exactitud se indicará con
“*”.
1.7.1.3. Rol
Por último, con respecto al nombre de la relación, éste no será especificado. Lo

que si se reflejará en los diagramas será el rol que juega en la relación la clase destino
de la navegación.
El rol es el comportamiento de una entidad que participa en un contexto

particular. Es decir, se indica el rol que juega una clase dentro de la relación con otra
clase.
De forma general se presenta un ejemplo en la figura 15. El nombre del rol que
desempeña la clase se especifica al lado de ésta.
Empresa Empleado
trabajador
Figura 15. Roles de las clases
Además, en nuestro caso, el rol de la clase será el nombre del atributo. Un

ejemplo se presenta en el diagrama de la figura 16.
class Jugador {
Jugador Ficha
ficha
}
Figura 16. Rol de la clase Ficha en la relación con Jugador
2
Restricción: restricción de la semántica de un elemento de UML, que permite añadir nuevas reglas o
modificar las existentes.

1.7.2. Composición
La relación de composición es la relación entre el “todo” y la “parte”, siendo

responsabilidad del “todo” lo que le ocurra a cada una de las “partes”.
En UML, para referirse a este tipo de relación, se hace distinción entre

Composición y Agregación. Nosotros simplemente vamos a referirnos a composición,
representando la relación como una línea acabada en un rombo en el extremo de la clase
que representa el “todo” (ver figura 17).
Tablero
tablero
Ter class Ter {
private Tablero tablero;

Jugador private final Jugador [ ] JUGADORES;
}
2
JUGADORES
Figura 17. Relación de composición entre clases
1.7.3. Uso
La relación de uso (en UML se denomina de dependencia) es una relación

momentánea que se establece entre un “cliente” y un “servidor”. La responsabilidad de
manejar un objeto “servidor” no tiene porqué depender únicamente de la clase “cliente”.
En UML se representa mediante una línea punteada que une ambas clases. En la
figura 18 se presenta un ejemplo de relación de uso.
class Jugador {
Jugador Coordenada public void mover(Tablero tablero) {
Coordenada c = new Coordenada();
c.recoger();
...
}
Figura 18. Relación de uso entre clases
En el caso de la relación de uso no hay posible rol a establecer (siguiendo la

pauta de que el rol sea el nombre del atributo).
1.7.4. Asociación
La relación de asociación es una relación que perdura entre un “cliente” y un

“servidor”, donde la responsabilidad de manejar el objeto de la clase “servidor” no tiene
porqué depender, únicamente, de la clase “cliente”.
Esta relación se representa en UML mediante una línea que une ambas clases,
como se puede apreciar en la figura 19.

class Jugador {
Jugador Ficha
ficha
...
}
Figura 19. Relación de asociación entre clases
1.7.5. Herencia
La relación de herencia (en UML denominada Generalización) es aquella que se

establece entre dos clases, transmitiendo tanto atributos como métodos de la clase padre
a la clase hija. La clase hija será una especialización de la clase padre.
En este caso la representación UML se realiza mediante un triángulo en el

extremo de la relación donde se encuentra la clase más general, la clase padre (ver
figura 20).
ClasePadre
class ClaseHija extends ClasePadre {

...
}
ClaseHija
Figura 20. Relación de herencia entre clases
La representación es la misma si la relación de herencia se da entre interfaces

(ver figura 21), o si una clase hereda por implementación de una interfaz (ver figura 22).
<<interface>>
InterfazPadre
interface InterfazHijo extends InterfazPadre {

...
}
<<interface>>
InterfazHijo
Figura 21. Relación de herencia entre interfaces

<<interface>>
InterfazPadre
class ClaseHija implements InterfazPadre {

...
}
ClaseHija
Figura 22. Relación de herencia por implementación
1.8. Recapitulación
Una vez estudiados todos los detalles de clases, objetos y relaciones, en este
apartado se presentan de nuevo los diagramas de clases y objetos mostrados en el
apartado 1.4. Dichos diagramas se han completado indicando los tipos de relaciones
entre las clases, la navegabilidad, la multiplicidad, los roles, etc.
El diagrama de clases completo se presenta en la figura 23.
Ter
turno
tablero
JUGADORES 2 {array}
Turno Tablero
Jugador
ficha
FICHAS
{array}
* Coordenada
Ficha
Figura 23. Diagrama de clases completo
El diagrama de objetos que se tenía se ha completado añadiendo la

navegabilidad, quedando como se muestra en la figura 24.

:Ter
:Turno
:Tablero
:Coordenada
...
:Jugador
:Coordenada
:Jugador
:Ficha
:Ficha
:Ficha
Figura 24. Diagrama de objetos completo
1.9. Consideraciones
Observando la notación gráfica de UML para las clases, se puede apreciar que se
indican los diferentes atributos de una clase. Estos atributos pueden ser objetos de otras
clases, lo que va a marcar seguro algún tipo de relación entre ellas. Por lo tanto, es
necesario tomar una decisión con respecto al lugar en el que se ponen dichos atributos,
de forma que en el diagrama de clases no sea redundante.
Un ejemplo de esta situación se muestra en la figura 25.
Persona Libro
fechaNacimiento: Fecha publicacion: Fecha
(a)
Persona Fecha Libro
fechaNacimiento publicacion
(b)
Figura 25. Equivalencia “parcial” entre notaciones

Como se puede apreciar, en la figura 25(a) el atributo que hace referencia a la

fecha de nacimiento de una persona va incluido en la parte central de la notación gráfica
de la clase Persona. Sin embargo, en la figura 25(b) la fecha de nacimiento de la
persona se manifiesta a través de una relación entre clases.
Para intentar unificar la forma de representar nuestros programas orientados a

objetos, en principio se va a optar por la segunda opción (figura 25(b)), y sólo en aquel
caso en el que el diagrama esté muy “cargado”, se optará por representar algunos
atributos mediante la primera opción (figura 25(a)).
1.10. Bibliografía
G. Booch, I. Jacobson, J. Rumbaugh; “El Lenguaje Unificado de Modelado. Manual de

Referencia”. Addison Wesley.

umlToJava v2 PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

umlToJava v2 PDF

Cargado por

Copyright:

Formatos disponibles

Programación Orientada a Objetos 1

Notación UML para modelado Orientado a

Universidad Rey Juan Carlos – curso 04/05 – Soto Montalvo

1.1. ¿Qué es UML?.................................................................................................. 3

Universidad Rey Juan Carlos – curso 04/05 – Soto Montalvo

1.1. ¿Qué es UML?

El Lenguaje Unificado de Modelado (UML, Unified Modeling Language) es un

Es un lenguaje de propósito general que pretende ser un estándar mundial y se

¿Qué es un modelo? Una simplificación de la realidad.

¿Por qué se modela? Se construyen modelos para poder entender mejor el

1.2. ¿Por qué interesa UML en la asignatura de Programación Orientada a

En la asignatura de Programación Orientada a Objetos se aprende un nuevo

 Le permite ir familiarizándose con un lenguaje de modelado estándar que

1.3. ¿Qué se va a modelar?

Se presentará una selección de las características más representativas de UML.

Universidad Rey Juan Carlos – curso 04/05 – Soto Montalvo

Además, conviene dejar claro que:

• UML es un lenguaje de modelado

• Java es un lenguaje de implementación

En nuestro caso, dado un programa orientado a objetos nos interesa tanto su

Los aspectos estáticos se modelan mediante diagramas de clases y diagramas de

Los aspectos dinámicos se modelan mediante diagramas de interacción. Éstos,

1.4.1. Diagramas de Clases

Los diagramas de clases proporcionan una perspectiva estática del código. Se

o Gráficamente se representan mediante un rectángulo con el nombre de

Un ejemplo de diagrama de clases se presenta en la figura 1.

Universidad Rey Juan Carlos – curso 04/05 – Soto Montalvo

Figura 1. Diagrama de clases

1.4.2. Diagramas de Objetos

Los diagramas de objetos proporcionan una perspectiva estática de una

Básicamente se componen de:

o De forma gráfica se representa mediante un rectángulo con el nombre del

Un ejemplo de diagrama de objetos se presenta en la figura 2.

Universidad Rey Juan Carlos – curso 04/05 – Soto Montalvo

Figura 2. Diagrama de objetos

La diferencia clara entre un diagrama de clases y un diagrama de objetos es que

1.4.3. Diagramas de Interacción

En los diagramas de interacción se puede ver el patrón de comportamiento de un

1.4.3.1. Diagramas de secuencia

Estos diagramas presentan, ordenados temporalmente, los objetos que participan

En el diagrama, en cada eje vertical se coloca un objeto. Los mensajes se

Un ejemplo de diagrama de secuencia de presenta en la figura 3.

Universidad Rey Juan Carlos – curso 04/05 – Soto Montalvo

ter:Ter turno:Turno t:Tablero j:Jugador

Figura 3. Diagrama de secuencia

Para especificar quién y cuándo se crean los objetos, se utiliza el estereotipo1

Figura 4. Diagrama de secuencia con estereotipos

Universidad Rey Juan Carlos – curso 04/05 – Soto Montalvo

1.4.3.2. Diagramas de colaboración

Un diagrama de colaboración también muestra la interacción entre los objetos,

Figura 5. Diagrama de colaboración

El diagrama de secuencia y el diagrama de colaboración son equivalentes,

Las clases de Java se representarán tal como aparece en la figura 6. Se trata de

Figura 6. Representación de una clase con UML

Los niveles de visibilidad de los elementos se representan como sigue:

En la figura 7 se presenta un ejemplo de clase Java junto con su representación

Universidad Rey Juan Carlos – curso 04/05 – Soto Montalvo

Ficha class Ficha {

private char color;

Figura 7. Ejemplo de representación de una clase con UML

1.5.1. Clases Abstractas

Figura 8. Representación de una clase abstracta con UML

Figura 9. Representación de un interfaz con UML

Le permite ir familiarizándose con un lenguaje de modelado estándar que