Definicin.

UML (Unified Modeling Language) es un lenguaje grfico para visualizar, especificar,

construir y documentar los artefactos de un sistema con gran cantidad de software. Cure
tanto aspectos conceptuales (procesos de negocio, funciones del sistema) como cosas
concretas (clases, es!uemas de ases de datos, componentes reutilizales).
Breve historia
Los lenguajes de modelamiento orientados a ojetos aparecieron entre mediados de los "#$s
y fines de los %#$s, deido a dos factores fundamentales& la aparici'n de lenguajes
orientados a ojetos, y la aparici'n de aplicaciones cada vez ms complejas. (n )*%*
+a,an apro-imadamente )# m.todos orientados a ojetos. (n )**/ ms de 0#. (sta .poca
fue llamada la 1guerra de los m.todos1.
(ntre todos estos m.todos destacaron tres& el de 2ooc+, el 334( (Object-Oriented
Software Engineering) de 5acoson, y el 3M6 (Object Modeling Technique) de 7umaug+.
3tros m.todos importantes fueron& 8usion, 4+laer9Mellor y Coad9:ourdon.
; mediados de los *#$s cada autor de los tres m.todos ms reconocidos (2ooc+, 5acoson y
7umaug+) empieza a adoptar ideas de los otros < m.todos. (n )**/ 7umaug+ se une a
2ooc+, y sacan la versi'n #.% de Unified Method, el cual es pulicado en )**0. Luego
5acoson se une a 7ational, y sacan la versi'n #.* de UML, en junio de )**=.
>osteriormente sacan la versi'n ).# en enero de )**", con la aproaci'n de un grupo de
empresas llamado 3M? (Object Management Group). (l lenguaje es aierto a otras
empresas, y con nuevas oservaciones y recomendaciones sale la versi'n ).) en noviemre
de )**", y la versi'n ).< en junio de )**%. ; fines de )**% sale la actual versi'n ).@.
Casos de Uso
AingBn sistema se encuentra aislado. Cual!uier sistema interactBa con actores +umanos o
mecnicos !ue lo utilizan con algBn ojetivo. Un caso de uso especifica el comportamiento
de un sistema o una parte del mismo, y es una descripci'n de un conjunto de secuencias de
acciones, donde cada secuencia representa la interacci'n de los elementos e-ternos del
sistema (sus actores) con el propio sistema. Un caso de uso representa un re!uerimiento
funcional del sistema. >or ejemplo, un caso de uso fundamental en un anco, es el
procesamiento de pr.stamos. ?rficamente, los casos de uso se representan mediante
elipses.
Los casos de uso se emplean para capturar el comportamiento deseado del sistema en
desarrollo, sin tener !ue especificar c'mo se implementa ese comportamiento.
>roporcionan un medio para !ue los desarrolladores, los usuarios finales del sistema y los
e-pertos del dominio lleguen a una comprensi'n comBn del sistema. ;dems ayudan a
validar la ar!uitectura y a verificar el sistema mientras evoluciona a lo largo del desarrollo.
Ejemplo: Un juego de dados
4e tiene un juego de dados en !ue un jugador lanza dos dados. 4i el total otenido es siete,
el jugador gana, de lo contrario pierde.
Caso de uso: 5uega un juego.
Participantes (actores): 5ugador.
Descripcin: (ste caso de uso comienza cuando el jugador recoge y tira los dados.
4i los puntos suman siete, gana y pierde si suman cual!uier otro nBmero.
(l diagrama UML correspondiente a este caso de uso ser,a similar a este&
Cada caso de uso dee tener un nomre !ue lo distinga de otros casos de uso. Los nomres
pueden ser nombres simples o nombres de camino. (stos Bltimos constan del nomre del
caso de uso, precedido del nomre del pa!uete en el !ue se encuentra. (jemplo&
Un actor representa un conjunto co+erente de roles !ue juegan los usuarios de los casos de
uso cuando interactBan con .stos. Los actores pueden ser personas o sistemas mecnicos.
4e pueden definir categor,as generales de actores (como cliente en el ejemplo de aajo) y
especializarlos (como lienteomercial) a trav.s de relaciones de generalizaci'n. (jemplo&
Los casos de uso pueden ser versiones especializadas de otros casos de uso, casos de uso
incluidos como parte de otros casos de uso, y casos de uso !ue e-tienden el
comportamiento de otros casos de uso sicos.
Orani!acin de casos de uso
Los casos de uso pueden organizarse agrupndolos en pa!uetes. 6ami.n se pueden
especificar relaciones de generalizaci'n, inclusi'n y e-tensi'n. Generali!aci"n significa
!ue el caso de uso +ijo +ereda el comportamiento y el significado del caso de uso padre,
donde el +ijo puede agregar o redefinir el comportamiento del padre. La generalizaci'n
entre casos de uso se representa como una l,nea continua con una punta de flec+a vac,a.
Una relaci'n de inclusi"n entre dos casos de uso significa !ue un caso de uso ase
incorpora e-pl,citamente el comportamiento de otro caso de uso en el lugar especificado en
el caso ase. ;!u, el caso de uso ase toma el comportamiento del caso de uso proveedor.
(sta relaci'n se usa para evitar descriir el mismo flujo de eventos repetidas veces,
poniendo el comportamiento comBn en un caso de uso aparte (!ue ser incluido por un caso
ase). Una relaci'n de inclusi'n se representa como una dependencia, usando la palara
include. >ara especificar la posici'n en un flujo de eventos, se usa la palara include
seguido del caso de uso !ue se !uiere incluir. >or ejemplo, para descriir el flujo de Seguir
pedido&
#lujo de e$entos principal% 3tener y verificar el nBmero de pedido. include
(validar usuario). (-aminar el estado de cada parte del pedido y preparar
un informe para el usuario.
Una relaci'n de e-tensi'n entre casos de uso significa !ue un caso de uso ase incorpora
impl,citamente el comportamiento de otro caso de uso en el lugar especificado
indirectamente por el caso de uso !ue e-tiende al ase. Un caso de uso puede e-tenderse
solamente en ciertos puntos, llamados puntos de e&tensi"n. La e-tensi'n se puede ver como
!ue el caso de uso !ue e-tiende, incorpora su comportamiento en el caso de uso ase. 4e
representa como una dependencia con la palara e&tend. Los puntos de e-tensi'n s'lo son
eti!uetas !ue pueden aparecer en el flujo del caso de uso ase. >or ejemplo, el flujo de
'acer pedido podr,a escriirse as,&
#lujo de e$entos principal% include (Validar usuario). 7ecoger los
,temes del pedido del usuario. (establecer prioridad). (nviar el pedido
para ser procesado.
Una relaci'n de e-tensi'n se usa para modelar la parte de un caso de uso !ue el usuario
puede ver como comportamiento opcional del sistema. Ce esta forma se separa el
comportamiento opcional del oligatorio. (s decir, un caso de uso ase puede, ajo ciertas
condiciones, incorporar el comportamiento de otro caso de uso en el lugar especificado.
"odelando el comportamiento de un elemento
>or lo general, los casos de uso se utilizan para modelar el comportamiento de un elemento,
ya sea un sistema completo, un susistema o una clase. (s importante centrarse en lo !ue
+ace el elemento, no en c'mo lo +ace. Los casos de uso sirven de ase para proar cada
elemento segBn evoluciona durante el desarrollo. ;l proar continuamente cada elemento
frente a sus casos de uso, se est validando su implementaci'n a lo largo del desarrollo.
>ara modelar el comportamiento de un elemento se dee&
9 Ddentificar los actores !ue interactBan con el elemento.
9 3rganizar los actores similares en jerar!u,as, identificando los roles.
9 Considerar las formas ms importantes !ue tiene cada actor de interactuar con el
elemento. 6ami.n +ay !ue considerar las formas e-cepcionales (puntos de
e-tensi'n).
9 3rganizar estos comportamientos como casos de uso, usando las reglas de
inclusi'n (para factorizar el comportamiento comBn) y de e-tensi'n (para distinguir
el comportamiento e-cepcional).
Ejemplo #: Sistema de ventas. Un sistema de ventas dee interactuar con clientes, los
cuales efectBan pedidos. ;dems los clientes pueden +acer un seguimiento de sus propios
pedidos. (l sistema env,a los pedidos y las facturas a los clientes. (n algunos casos, segBn
la urgencia de los clientes, se puede adelantar parte del pedido (pedidos parciales).
Como se muestra en la figura anterior, el comportamiento de este sistema se puede modelar
usando los casos de uso Hacer pedido, Seguir pedido, Enviar pedido,
Facturar cliente. (l comportamiento comBn puede factorizarse (Validar
cliente) y tami.n pueden distinguirse sus variantes (Enviar pedido parcial).
Cada caso de uso dee incluir una especificaci'n de su comportamiento.
Ejemplo $:Validacin de tarjetas de crdito. La figura de aajo muestra el conte-to de un
sistema de validaci'n de tarjetas de cr.dito. 4e puede ver !ue e-isten dos categor,as de
clientes& clientes individuales, clientes corporativos. (stos actores
representan los roles !ue juegan las personas !ue interactBan con el sistema. 6ami.n +ay
actores !ue representan otras instituciones, como Comercio, con el cual el cliente realiza
una transacci'n para comprar un art,culo o servicio, y Entidad financiera, !ue por
lo general es una entidad ancaria donde el usuario tiene la tarjeta de cr.dito.
Modelado del conte-to de un sistema
"odelando los re%uerimientos de un sistema
Un requisito es una caracter,stica de diseEo, una propiedad o un comportamiento de un
sistema. Cuando se enuncian los re!uisitos de un sistema, se est estaleciendo un contrato
entre los elementos e-ternos al sistema y el propio sistema, !ue estalece lo !ue se espera
!ue el sistema +aga. Ce a!u, la importancia de !ue antes de construir un sistema, e-ista un
acuerdo sore !u. deer,a +acer el sistema. 4in emargo, es casi seguro !ue la comprensi'n
de los re!uisitos va a evolucionar conforme se vaya implementanto el sistema de manera
iterativa e incremental. La mayor,a de los re!uerimientos funcionales de un sistema, si no
todos, se pueden e-presar con diagramas de casos de uso. >ara e-presar los re!uerimientos
funcionales tami.n puede usarse desde te-to sin estructura, +asta e-presiones en un
lenguaje formal.
La principal diferencia al modelar re!uerimientos funcionales, es !ue se introducen en los
diagramas, casos de uso adicionales !ue pueden ser invisiles para los actores, pero !ue son
comportamientos fundamentales del sistema. La siguiente figura e-tiende el diagrama de
casos de uso anterior.
Modelado de los re!uisitos de un sistema