Tutorial de UML

Tutorial de UML
Introducción:
E l Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un
lenguaje gráfico para vis ualizar, es pecificar y documentar cada una de las partes
que comprende el des arrollo de s oftware. UML entrega una forma de modelar
cos as conceptuales como lo s on proces os de negocio y funciones de s is tema,
además de cos as concretas como lo s on es cribir clas es en un lenguaje
determinado, es quemas de bas e de datos y componentes de s oftware reus ables .
Objetivos:
E ntregar un material de apoyo que le permita al lector poder definir diagramas
propios como también poder entender el modelamiento de diagramas ya
exis tentes .
Audiencia:
E l pres ente documento es ta orientado a alumnos que ya pos een ciertos conceptos
de OOP (o es tan haciendo un curs o) y a s u vez conocen algún lenguaje Orientado
a Objetos (ejemplo: C++ o Java), por lo tanto no es un curs o en s i, s ino más bien
un material de apoyo al es tudiante.
Contenidos:
E l documento contempla el es tudio de tres diagramas :
•
•
•
Modelamiento de Clases
Casos de Uso
Diagrama de Interacción
A s u vez el es tudio de un problema completo que los involucra (E l Hotel),
http://www.dcc.uchile.cl/~ps alinas /uml/ejemplo/ejemplo.html
utilizando como herramienta cas e R ational R os e http://www.rational.com
Modelo de Clases
Introducción
Un diagrama de clas es s irve para vis ualizar las relaciones entre las clas es que
involucran el s is tema, las cuales pueden s er as ociativas , de herencia, de us o y de
contenimiento.
Un diagrama de clas es es ta compues to por los s iguientes elementos :
•
•
Clase: atributos, métodos y visibilidad.
Relaciones: Herencia, Composición, Agregación, Asociación y Uso.
E lementos
•
Clase
E s la unidad bás ica que encaps ula toda la información de un Objeto (un
objeto es una ins tancia de una clas e). A través de ella podemos modelar el
entorno en es tudio (una Cas a, un Auto, una Cuenta Corriente, etc.).
E n UML, una clas e es repres entada por un rectángulo que pos ee tres
divis iones :
E n donde:
o
o
o
Superior: Contiene el nombre de la Clase
Intermedio: Contiene los atributos (o variables de instancia) que
caracterizan a la Clase (pueden ser private, protected o public).
Inferior: Contiene los métodos u operaciones, los cuales son la forma como
interactúa el objeto con su entorno (dependiendo de la visibilidad: private,
protected o public).
E jemplo:
Una Cuenta Corriente que pos ee como caracterís tica:
o
Balance
Puede realizar las operaciones de:
o
o
o
Depositar
Girar
y Balance
E l dis eño as ociado es :
Atributos y Métodos :
o
Atributos:
Los atributos o caracterís ticas de una Clas e pueden s er de tres tipos ,
los que definen el grado de comunicación y vis ibilidad de ellos con el
entorno, es tos s on:
♣
public (+,
): Indica que el atributo será visible tanto dentro
como fuera de la clase, es decir, es accsesible desde todos lados.
♣
private (-,
): Indica que el atributo sólo será accesible desde
dentro de la clase (sólo sus métodos lo pueden accesar).
protected (#,
): Indica que el atributo no será accesible desde
fuera de la clase, pero si podrá ser accesado por métodos de la clase
además de las subclases que se deriven (ver herencia).
Métodos:
♣
o
Los métodos u operaciones de una clas e s on la forma en como és ta
interactúa con s u entorno, és tos pueden tener las caracterís ticas :
♣
public (+, ): Indica que el método será visible tanto dentro como
fuera de la clase, es decir, es accsesible desde todos lados.
♣
private (-,
): Indica que el método sólo será accesible desde
dentro de la clase (sólo otros métodos de la clase lo pueden accesar).
protected (#,
): Indica que el método no será accesible desde
fuera de la clase, pero si podrá ser accesado por métodos de la clase
además de métodos de las subclases que se deriven (ver herencia).
Relaciones entre Clases:
♣
•
Ahora ya definido el concepto de Clas e, es neces ario explicar como s e
pueden interrelacionar dos o más clas es (cada uno con caracterís ticas y
objetivos diferentes ).
Antes es neces ario explicar el concepto de cardinalidad de relaciones : E n
UML, la cardinalidad de las relaciones indica el grado y nivel de
dependencia, s e anotan en cada extremo de la relación y és tas pueden s er:
o
o
o
iv.
uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
número fijo: m (m denota el número).
Herencia (Especialización/Generalización):
Indica que una s ubclas e hereda los métodos y atributos
es pecificados por una S uper Clas e, por ende la S ubclas e además de
pos eer s us propios métodos y atributos , pos eerá las caracterís ticas y
atributos vis ibles de la S uper Clas e (public y protected), ejemplo:
E n la figura s e es pecifica que Auto y Camión heredan de Vehículo,
es decir, Auto pos ee las Caracterís ticas de Vehículo (Precio, VelMax,
etc) además pos ee algo particular que es Des capotable, en cambio
Camión también hereda las caracterís ticas de Vehiculo (Precio,
VelMax, etc) pero pos ee como particularidad propia Acoplado, T ara y
Carga.
Cabe des tacar que fuera de es te entorno, lo único "vis ible" es el
método Caracteris ticas aplicable a ins tancias de Vehículo, Auto y
Camión, pues tiene definición publica, en cambio atributos como
Des capotable no s on vis ibles por s er privados .
v.
Agregación:
Para modelar objetos complejos , n bas tan los tipos de datos bás icos
que proveen los lenguajes : enteros , reales y s ecuencias de
caracteres . Cuando s e requiere componer objetos que s on ins tancias
de clas es definidas por el des arrollador de la aplicación, tenemos
dos pos ibilidades :
Por Valor: Es un tipo de relación estática, en donde el tiempo de
vida del objeto incluido esta condicionado por el tiempo de vida del
que lo incluye. Este tipo de relación es comunmente llamada
Composición (el Objeto base se contruye a partir del objeto incluido,
es decir, es "parte/todo").
♣ Por Referencia: Es un tipo de relación dinámica, en donde el tiempo
de vida del objeto incluido es independiente del que lo incluye. Este
tipo de relación es comunmente llamada Agregación (el objeto base
utiliza al incluido para su funcionamiento).
♣
Un E jemplo es el s iguiente:
E n donde s e des taca que:
Un Almacen posee Clientes y Cuentas (los rombos van en el objeto
que posee las referencias).
♣ Cuando se destruye el Objeto Almacen también son destruidos los
objetos Cuenta asociados, en cambio no son afectados los objetos
Cliente asociados.
♣ La composición (por Valor) se destaca por un rombo relleno.
♣ La agregación (por Referencia) se destaca por un rombo
transparente.
♣
La flecha en es te tipo de relación indica la navegabilidad del objeto
refereniado. Cuando no exis te es te tipo de particularidad la flecha s e
elimina.
vi.
Asociación:
La relación entre clas es conocida como As ociación, permite as ociar
objetos que colaboran entre s i. Cabe des tacar que no es una
relación fuerte, es decir, el tiempo de vida de un objeto no depende
del otro.
E jemplo:
Un cliente puede tener as ociadas muchas Ordenes de Compra, en
cambio una orden de compra s olo puede tener as ociado un cliente.
vii.
Dependencia o Instanciación (uso):
R epres enta un tipo de relación muy particular, en la que una clas e es
ins tanciada (s u ins tanciación es dependiente de otro objeto/clas e).
S e denota por una flecha punteada.
E l us o más particular de es te tipo de relación es para denotar la
dependencia que tiene una clas e de otra, como por ejemplo una
aplicación grafica que ins tancia una ventana (la creación del Objeto
Ventana es ta condicionado a la ins tanciación proveniente des de el
objeto Aplicacion):
Cabe des tacar que el objeto creado (en es te cas o la Ventana gráfica)
no s e almacena dentro del objeto que lo crea (en es te cas o la
Aplicación).
•
Casos Particulares:
o
Clase Abstracta:
Una clas e abs tracta s e denota con el nombre de la clas e y de los
métodos con letra "itálica". E s to indica que la clas e definida no puede
s er ins tanciada pues pos ee métodos abs tractos (aún no han s ido
definidos , es decir, s in implementación). La única forma de utilizarla
es definiendo s ubclas es , que implementan los métodos abs tractos
definidos .
o
Clase parametrizada:
Una clas e parametrizada s e denota con un s ubcuadro en el extremo
s uperior de la clas e, en donde s e es pecifican los parámetros que
deben s er pas ados a la clas e para que es ta pueda s er ins tanciada.
E l ejemplo más típico es el cas o de un Diccionario en donde una
llave o palabra tiene as ociado un s ignificado, pero en es te cas o las
llaves y elementos pueden s er genéricos . La genericidad puede venir
dada de un T emplate (como en el cas o de C++) o bien de alguna
es tructura predefinida (es pecialización a través de clas es ).
E n el ejemplo no s e es pecificaron los atributos del Diccionario, pues
ellos dependerán exclus ivamente de la implementación que s e le
quiera dar.
E jemplo:
S upongamos que tenemos tenemos un el cas o del Diccionario implementado
mediante un árbol binario, en donde cada nodo pos ee:
•
•
key: Variable por la cual se realiza la búsqueda, puede ser generica.
item: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo también
puede ser genérico.
Para es te cas o particular hemos definido un Diccionario para almacenar S tring y
Pers onas , las cuales pueden funcionar como llaves o como item, s olo s e
mos trarán las relaciones para la implementación del Diccionario:
Casos de Uso (Use Case)
Introducción
E l diagrama de cas os de us o repres enta la forma en como un Cliente (Actor)
opera con el s is tema en des arrollo, además de la forma, tipo y orden en como los
elementos interactuan (operaciones o cas os de us o).
Un diagrama de cas os de us o cons ta de los s iguientes elementos :
•
•
•
Actor.
Casos de Uso.
Relaciones de Uso, Herencia y Comunicación.
E lementos
•
Actor:
Una definición previa, es que un Actor es un rol que un us uario juega con
res pecto al s is tema. E s importante des tacar el us o de la palabra rol, pues
con es to s e es pecifica que un Actor no neces ariamente repres enta a una
pers ona en particular, s ino más bien la labor que realiza frente al s is tema.
Como ejemplo a la definición anterior, tenemos el cas o de un s is tema de
ventas en que el rol de Vendedor con res pecto al s is tema puede s er
realizado por un Vendedor o bien por el Jefe de Local.
•
Caso de Uso:
E s una operación/tarea es pecífica que s e realiza tras una orden de algún
agente externo, s ea des de una petición de un actor o bien des de la
invocación des de otro cas o de us o.
•
Relaciones:
o
Asociación
E s el tipo de relación más bás ica que indica la invocación des de un
actor o cas o de us o a otra operación (cas o de us o). Dicha relación s e
denota con una flecha s imple.
o
Dependencia o Instanciación
E s una forma muy particular de relación entre clas es , en la cual una
clas e depende de otra, es decir, s e ins tancia (s e crea). Dicha
relación s e denota con una flecha punteada.
o
Generalización
E s te tipo de relación es uno de los más utilizados , cumple una doble
función dependiendo de s u es tereotipo, que puede s er de Uso
(<<us es >>) o de Herencia (<<extends >>).
E s te tipo de relación es ta orientado exclus ivamente para cas os de
us o (y no para actores ).
extends: S e recomienda utilizar cuando un cas o de us o es s imilar a
otro (caracterís ticas ).
uses: S e recomienda utilizar cuando s e tiene un conjunto de
caracterís ticas que s on s imilares en más de un cas o de us o y no s e
des ea mantener copiada la des cripción de la caracterís tica.
De lo anterior cabe mencionar que tiene el mis mo paradigma en
dis eño y modelamiento de clas es , en donde es ta la duda clás ica de
usar o heredar.
E jemplo:
Como ejemplo es ta el cas o de una Máquina R ecicladora:
S is tema que controla una máquina de reciclamiento de botellas , tarros y jabas . E l
s is tema debe controlar y/o aceptar:
•
•
•
•
•
Registrar el número de ítemes ingresados.
Imprimir un recibo cuando el usuario lo solicita:
a. Describe lo depositado
b. El valor de cada item
c. Total
El usuario/cliente presiona el botón de comienzo
Existe un operador que desea saber lo siguiente:
a. Cuantos ítemes han sido retornados en el día.
b. Al final de cada día el operador solicita un resumen de todo lo depositado en
el día.
El operador debe además poder cambiar:
a. Información asociada a ítemes.
b. Dar una alarma en el caso de que:
i.
Item se atora.
ii.
No hay más papel.
Como una primera aproximación identificamos a los actores que interactuan con el
s is tema:
Luego, tenemos que un Cliente puede Depos itar Itemes y un Operador puede
cambiar la información de un Item o bien puede Imprimir un informe:
Además podemos notar que un item puede s er una Botella, un T arro o una Jaba.
Otro as pecto es la impres ión de comprobantes , que puede s er realizada des pués
de depos itar algún item por un cliente o bien puede s er realizada a petición de un
operador.
E ntonces , el dis eño completo del diagrama Us e Cas e es :
Diagrama de Interacción
Introducción
E l diagrama de interacción, repres enta la forma en como un Cliente (Actor) u
Objetos (Clas es ) s e comunican entre s i en petición a un evento. E s to implica
recorrer toda la s ecuencia de llamadas , de donde s e obtienen las
res pons abilidades claramente.
Dicho diagrama puede s er obtenido de dos partes , des de el Diagrama E s tático de
Clas es o el de Cas os de Us o (s on diferentes ).
Los componentes de un diágrama de interacción s on:
•
•
•
Un Objeto o Actor.
Mensaje de un objeto a otro objeto.
Mensaje de un objeto a si mismo.
E lementos
•
Objeto/Actor:
E l rectángulo repres enta una ins tancia de un Objeto en particular, y la línea
punteada repres enta las llamadas a métodos del objeto.
•
Mensaje a Otro Objeto:
S e repres enta por una flecha entre un objeto y otro, repres enta la llamada
de un método (operación) de un objeto en particular.
•
Mensaje al Mismo Objeto:
No s olo llamadas a métodos de objetos externos pueden realizars e,
también es pos ible vis ualizar llamadas a métodos des de el mis mo objeto en
es tudio.
E jemplo
E n el pres ente ejemplo, tenemos el diagrama de interacción proveniente del
s iguiente modelo es tatico:
Aquí s e repres enta una aplicación que pos ee una Ventana gráfica, y és ta a s u vez
pos ee internamente un botón.
E ntonces el diagrama de interacción para dicho modelo es :
E n donde s e hacen notar las s uces ivas llamadas a Draw() (entre objetos ) y la
llamada a Paint() por el objeto Botón.
Ejemplo - Tutorial UML
"Hotel"
E l dueño de un hotel le pide a us ted des arrollar un programa para cons ultar s obre
las piezas dis ponibles y res ervar piezas de s u hotel.
E l hotel pos ee tres tipos de piezas : s imple, doble y matrimonial, y dos tipos de
clientes : habituales y es porádicos . Una res ervación almacena datos del cliente, de
la pieza res ervada, la fecha de comienzo y el número de días que s erá ocupada la
pieza.
E l recepcionis ta del hotel debe poder hacer la s iguientes operaciones :
•
•
•
•
•
•
•
Obtener un listado de las piezas disponible de acuerdo a su tipo
Preguntar por el precio de una pieza de acuerdo a su tipo
Preguntar por el descuento ofrecido a los clientes habituales
Preguntar por el precio total para un cliente dado, especificando su numero de RUT,
tipo de pieza y número de noches.
Dibujar en pantalla la foto de un pieza de acuerdo a su tipo
Reservar una pieza especificando el número de la pieza, rut y nombre del cliente.
Eliminar una reserva especificando el número de la pieza
E l adminis trador puede us ar el programa para:
•
•
•
Cambiar el precio de una pieza de acuerdo a su tipo
Cambiar el valor del descuento ofrecido a los clientes habituales
Calcular las ganancias que tendrán en un mes especificado (considere que todos los
meses tienen treinta días).
E l hotel pos ee información s obre cuales clientes s on habituales . E s ta es tructura
puede manejarla con un diccionario, cuya clave s ea el número de R UT y como
s ignificado tenga los datos pers onales del cliente.
E l dis eño a des arrollar debe facilitar la extens ibilidad de nuevos tipos de pieza o
clientes y a s u vez permitir agregar nuevas cons ultas .
E l pres ente ejemplo contempla los s iguientes diagramas :
•
•
•
Casos de uso
Diagrama de clases
Dos diagramas de interacción
E l contenido del pres ente ejemplo lo puedes obtener des de el s iguiente archivo:
hotel.zip (requerimientos : R ational R os e 98i).
CASOS DE USO
DIAGRAMA DE CLASES
DIAGRAMA DE INTERACCION