El presente recurso de aprendizaje fue elaborado por la Mtra. Azalia Mndez, M. A.

como resultado
de su prctica docente y apoyada en las siguientes fuentes:
Schmuller J. (2001). Aprendiendo UML en 24 Horas. Prentice Hall
Modelado de Sistemas con UML (s.f.). Recuperado el 01 de diciembre de 2014, de
http://es.tldp.org/Tutoriales/doc-modelado-sistemas-UML/doc-modelado-sistemas-uml.pdf
Lenguaje Unificado de Modelado UML (s.f.). Recuperado el 02 de diciembre de 2014, de
http://datateca.unad.edu.co/contenidos/200609/exeuml/index.html

Fuente de la imagen: http://datateca.unad.edu.co/contenidos/200609/exeuml/modulo_uml.html

Fundamentos de UML
El Lenguaje Unificado de Modelado (UML) es una herramienta que ayuda a
capturar la idea de un sistema para comunicarla posteriormente a quien est
involucrado en su proceso de desarrollo, a travs de un conjunto de smbolos y
diagramas, donde cada diagrama tiene fines distintos dentro del proceso de
desarrollo.
Anterior al UML, el desarrollo de sistemas era prcticamente una propuesta al
azar, puesto que la comunicacin de la idea no era tan clara a quien deba
desarrollar el sistema. Los analistas de sistemas trataban de entender los
requerimientos de los usuarios y comunicrselo a los desarrolladores con la
esperanza de que el producto final cumpliera con lo que el cliente deseaba, lo que
muchas veces conclua con la entrega de un sistema difcil de utilizar y que no
solucionaba el problema original del usuario.
Se necesitaba por tanto un lenguaje no slo para comunicar las ideas a otros
desarrolladores sino tambin para servir de apoyo en los procesos de anlisis de
un problema. Con este objetivo se cre el Lenguaje Unificado de Modelado (UML:
Unified Modeling Language).
UML se ha convertido en ese estndar tan ansiado para representar y modelar la
informacin con la que se trabaja en las fases de anlisis y, especialmente, de
diseo.
1

El lenguaje UML tiene una notacin grfica muy expresiva que permite representar
en mayor o menor medida todas las fases de un proyecto informtico: desde el
anlisis con los casos de uso, el diseo con los diagramas de clases, objetos, etc.,
hasta la implementacin y configuracin con los diagramas de despliegue.
Tal como indica su nombre, UML es un lenguaje de modelado. Un modelo es una
simplificacin de la realidad. El objetivo del modelado de un sistema es capturar
las partes esenciales del sistema. Para facilitar este modelado, se realiza una
abstraccin y se plasma en una notacin grfica. Esto se conoce como modelado
visual.
El modelado visual permite manejar la complejidad de los sistemas a analizar o
disear. De la misma forma que para construir una choza no hace falta un modelo,
cuando se intenta construir un sistema complejo como un rascacielos, es
necesario abstraer la complejidad en modelos que el ser humano pueda entender.
UML sirve para el modelado completo de sistemas complejos, tanto en el diseo
de los sistemas software como para la arquitectura hardware donde se ejecuten.
Otro objetivo de este modelado visual es que sea independiente del lenguaje de
implementacin, de tal forma que los diseos realizados usando UML se pueda
implementar en cualquier lenguaje que soporte las posibilidades de UML
(principalmente lenguajes orientados a objetos).
UML es adems un mtodo formal de modelado. Esto aporta las siguientes
ventajas:
Mayor rigor en la especificacin.
Permite realizar una verificacin y validacin del modelo realizado.
Se pueden automatizar determinados procesos y permite generar cdigo a partir
de los modelos y a la inversa (a partir del cdigo fuente generar los modelos). Esto
permite que el modelo y el cdigo estn actualizados, con lo que siempre se
puede mantener la visin en el diseo, de ms alto nivel, de la estructura de un
proyecto.

Por que es necesario el UML?

Es de vital importancia que el cliente comprenda lo que har el equipo de
desarrolladores. Adems tiene que ser capaz de sealar cambios si no han
captado claramente sus necesidades, o si cambian de opinin durante el proceso.
Por otra parte, los miembros del equipo de desarrollo tienen que saber cul es la
solucin general y que lugar tiene su trabajo en la misma.
2

En otro orden, para poder manejar la complejidad de los sistemas actuales que
involucran la comunicacin de hardware y software a grandes distancias,
mediante una red vinculada a bases de datos, con enormes cantidades de
informacin, es necesario organizar el proceso de diseo de forma tal, que los
analistas, clientes y desarrolladores comprendan el sistema y convengan con l.
Contar con un diseo slido es necesario para reducir el periodo de desarrollo de
sistemas contemporneo; adems la posibilidad de modificar aspectos
importantes de un proyecto de desarrollo en las adquisiciones corporativas.

Historia de UML
El UML es creacin de Grady Booch, James Rumbaugh e Ivar Jacobson. Los
cuales de manera independiente, durante la dcada de los ochenta y principios de
los noventa, disearon su propia metodologa para el anlisis y diseo orientado a
objetos. Sus metodologas predominaron sobre las de sus competidores y a
mediados de los noventa decidieron unirse y realizar su trabajo en conjunto.
Los anteproyectos del UML trajeron consigo considerables modificaciones en la
industria del software, por lo cual se consolid un consorcio del UML, figurando
entre sus miembros Microsoft, Oracle, Hewlett-Packard, Texas Instruments, entre
otros. En 1997 se produjo la versin 1.0 del UML, la cual se puso a consideracin
del OMG (Grupo de administracin de objetos) como una respuesta su propuesta
como un lenguaje modelador estndar, ms adelante se generaron otras
versiones, lo cual ha convertido al UML en un estndar en la industria del
software.

En donde Utilizamos UML

El Lenguaje de Modelado Unificado UML, es para hacer modelos que faciliten
visualizar como es y cmo queremos un sistema. Este modelado es una plantilla
que se usara como gua para el desarrollo de un sistema y as dejar documentado
todo el proceso de produccin del mismo.

Banco y servicios financieros

Telecomunicaciones, transporte
Defensa/industria aeroespacial
Electrnica mdica
mbito cientfico
Tambin se pueden modelar workflows en un sistema jurdico, diseo de
hardware, etc.

Orientacin a objetos
Es importante conocer lo relacionado a la orientacin a objetos para poder trabajar
con el UML. La orientacin a objetos fomenta una metodologa basada en
componentes para el desarrollo de software, de manera que primero se genera un
sistema mediante un conjunto de objetos, luego podr ampliar el sistema
agregndole funcionabilidad a los componentes, y finalmente podr volver a
utilizar los objetos que genero para el sistema cuando cree uno nuevo, con lo cual
se reduce significativamente el tiempo de desarrollo de un sistema.
Un objeto es la instancia de una clase. Usted y yo somos instancia de una clase
llamada persona. Un objeto cuenta con atributos y acciones.
De la clase persona tenemos por ejemplo los siguientes atributos y acciones:
Atributos: altura, peso, edad, entre otros.
Acciones: hablar, caminar, comer, dormir, trabajar, leer, escribir, entre otros.
Adems la de categorizacin la clase tiene otro propsito, es una plantilla para
fabricar objetos
El propsito de la orientacin a objetos es desarrollar software que modele un
esquema del mundo, y mientras ms atributos y acciones se tomen en cuenta,
mayor ser la similitud del modelo con la realidad.
Otros aspectos de la orientacin a objetos son los siguientes:
La abstraccin: es quitar de un objeto las propiedades y acciones y dejar slo las
que sean necesarias.
Herencia: como instancia de una clase, un objeto tiene todas las caractersticas de
la clase a la que pertenece. No importa qu atributos o acciones decida usar en la
clase, siempre cada objeto los heredar.
Un objeto no slo hereda de una clase, sino que una clase puede heredar de otra.
Por ejemplo: lavadoras, microondas, neveras, radios licuadoras, planchas son
clases y forman parte de una ms genrica llamada Electrodomsticos. Y los
Electrodomsticos son una sub-clase de artculos del hogar
Polimorfismo: una operacin tiene un mismo nombre para diferentes clases, pero
cada clase sabe cmo realizar tal operacin.

Encapsulamiento: el objeto oculta la funcionabilidad interna de sus operaciones,

de otros objetos y del mundo exterior. Esta propiedad permite reducir el potencial
de errores que pudieran ocurrir en un sistema que consta de varios objetos. Ahora
bien, un objeto tiene que presentar un rostro al mundo exterior para poder iniciar
sus operaciones, y esto es lo que se conoce como interfaces
Envo de mensajes: permite que en un sistema los objetos trabajen en conjunto.
Un objeto le enva un mensaje a otro para realizar una operacin, y el objeto
receptor ejecutar la operacin.
Asociaciones: los objetos de alguna forma se relacionan entre s, pudiendo darse
en una sola direccin o en dos direcciones. En ocasiones, un objeto podra
asociarse con otro en ms de una forma. Una clase se puede asociar con dos o
ms clases distintas.
Agregacin: un objeto que se conforma de una combinacin de diversos objetos,
donde existe una estrecha relacin entre el objeto agregado y sus componentes,
lo cual se conoce como composicin.
Los objetos y sus asociaciones conforman la base de la funcionabilidad de los
sistemas. Si dominas las posibles asociaciones, tendrs la oportunidad de conocer
sus necesidades y as obtener los requerimientos, pudiendo crear sistemas que
los ayude a alcanzar sus metas de negocio.

Diagramas del UML

El UML est compuesto por diversos elementos grficos que se combinan para
conformar diagramas.
Los diagramas presentan diversas perspectivas de un sistema, a las cuales se les
conoce como modelo.
Diagrama de Caso de Uso
El diagrama de casos de uso representa la forma en como un Cliente (Actor)
opera con el sistema en desarrollo, adems de la forma, tipo y orden en como los
elementos interactan (operaciones o casos de uso). Un diagrama de casos de
uso consta de los siguientes elementos:

Actor.

Casos de Uso.

Relaciones de Uso, Herencia y Comunicacin.

El usuario es una parte importante en un sistema, por lo que es vital comprender

su punto de vista para generar sistemas que sean tanto tiles como funcionales
esto es, que cumpla con los requerimientos y que sea fcil de utilizar.
Un caso de uso es la descripcin de las acciones de un sistema desde el punto de
vista del usuario. Para los desarrolladores del sistema, sta es una herramienta
valiosa, ya que es una tcnica de aciertos y errores para obtener los
requerimientos del sistema desde el punto de vista del usuario.
La importancia de los casos de uso es involucrar a los usuarios en las etapas
iniciales del anlisis y diseo del sistema para aumentar la probabilidad de que el
sistema sea de mayor provecho para la gente a que supuestamente ayudara.
El caso de uso es muy poderoso, pero lo es ms aun cuando se visualiza por
medio del UML, ya que esta visualizacin le permitir mostrar los casos de usos a
los usuarios para que ellos puedan dar mayor informacin, generalmente los
usuarios saben ms de lo que dicen.
Representacin de un Modelo de Caso de Uso
Hay un actor que inicia un caso de uso y otro (posiblemente el que inici, pero no
necesariamente) que recibir algo de valor de l. En un modelo de caso de uso,
una figura representa a un actor; una elipse a un caso de uso y una lnea
asociativa representa la comunicacin entre el actor y el caso de uso.
Uno de los beneficios del anlisis del caso de uso es que le muestra los confines
entre el sistema y el mundo exterior. Generalmente los actores estn fuera del
sistema, mientras que los casos estn dentro de l. Utilizar un rectngulo, con el
nombre del sistema dentro de l, para representar el confn del sistema. El
rectngulo envuelve a los casos de usos del sistema.

Cada caso de uso es una coleccin de escenarios y cada escenario es una

secuencia de pasos. Como puede observar, tales pasos no aparecen en el
diagrama. La pregunta es, Cmo y dnde se hara la secuencia de pasos?
Los diagramas sern parte de un documento de diseo, donde cada diagrama
tendr su propia pgina y cada escenario por igual, donde se listara a modo de
texto:

El actor que inicia el proceso

Condiciones previas para el caso de uso
Pasos en el escenario
Condiciones posteriores cuando finaliza el escenario
El actor que se beneficia del caso de uso

Casos a Incluir y Casos a Extender

Un tema que genera mucha polmica entre la gente que modela casos de uso es
la eleccin entre la relacin de <<inclusin >> y <<extensin >>.
Qu es inclusin y extensin?
Estas, son relaciones que usamos para ligar grficamente dos casos de uso,
cuyos flujos de eventos estn unidos, normalmente en una sola sesin del usuario.
En otras palabras, un caso de uso que est ligado, por medio de una de estas dos
relaciones, a otro caso de uso; tambin podra leerse o ejecutarse como un slo
caso de uso en lugar de dos.
Inclusin: en trminos muy simples, cuando relacionamos dos casos de uso con
un include, estamos diciendo que el primero (el caso de uso base) incluye al
segundo (el caso de uso includo). Es decir, el segundo es parte esencial del
primero. Sin el segundo, el primero no podra funcionar bien; pues no podra
cumplir su objetivo. Para una venta en caja, la venta no puede considerarse
completa si no se realiza el proceso para cobrarla en ese momento. El caso de
uso Cobrar Renta est incluido en el caso de uso Rentar Video, o lo que es lo
mismo Rentar Video incluye (<<include>>) Cobrar Renta.

Extensin: la polmica al querer seleccionar una de las dos relaciones es que en

el extend tambin podemos ver, desde la perspectiva del usuario, a los dos flujos
como si fueran uno slo. Y en ciertos escenarios el caso de uso base no podra
cumplir su objetivo si no se ejecutara la extensin. Pero, una de las diferencias
bsicas es que en el caso del extend hay situaciones en que el caso de uso de
extensin no es indispensable que ocurra, y cuando lo hace ofrece un valor extra
(extiende) al objetivo original del caso de uso base. En cambio en el include es
necesario que ocurra el caso includo, tan slo para satisfacer el objetivo del caso
de uso base. Ejemplo: Puedes Realizar Venta sin Acumular Puntos de Cliente
VIP, cuando no eres un cliente VIP. Pero, si eres un cliente VIP s acumulars
puntos. Por lo tanto, Acumular Puntos es una extensin de Realizar Venta y
slo se ejecuta para cierto tipo de ventas, no para todas.

Casos de abusos
Uno de los riesgos que existe cuando la gente sabe que tiene estas relaciones
como un elemento a utilizar en sus modelos de casos de uso, consiste en su
abuso. Mucha gente, y sobre todo la que arrastra prcticas de mtodos
estructurados, la suele utilizar en exceso. No es raro ver modelos de casos de uso
que llegan a tener decenas de inclusiones y extensiones, incluso las inclusiones y
extensiones se vuelven a extender a varios niveles, generando una maraa de
casos de uso que no ofrecen valor al ser mostrados explcitamente

Es importante comprender que el objetivo de estos tipos de relaciones NO

consiste en motivar la divisin de los casos de uso en la mayor cantidad de
pedazos. Debe de existir una razn importante para que decidamos dividir un caso
de uso en dos que sern unidos por medio de alguna de estas relaciones. Si
entendemos esto y somos congruentes, obtendremos un beneficio real para el
proyecto; fin ltimo del uso de UML.
La razn por la que la gente suele partir sus casos de uso en infinidad de include
y extend es porque quieren conocer, entender y comunicar el mximo detalle de
los casos de uso en el diagrama. Hay quien llega a utilizar, errneamente, estas
relaciones para mostrar el orden en que se ejecutan estos casos de uso. Debemos
de recordar que al modelar el diagrama de casos de uso no buscamos analizar el
detalle, y mucho menos los flujos. Todo ese detalle lo podremos plasmar en otro
tipo de diagramas, como los diagramas de interaccin, de actividad, de estados, o
simplemente un texto en una especificacin.

Aplicacin de los Modelos de Caso de Uso

Supongamos que deber disear una red de rea local para una firma consultora,
y que tendr que comprender la funcionabilidad para poder crearla. Cmo
empezara?
Comprensin del dominio:
Mediante entrevistas al cliente se crear un diagrama de clases que refleje el
mundo de las consultoras, el cual podra tener el siguiente aspecto:

Comprensin de los usuarios:

El objetivo ser entender los tipos de funcionabilidad por crear en el sistema.
Un grupo de usuarios sern consultores, otros oficinistas. Entre otros usuarios
potenciales tendremos funcionarios corporativos, vendedores, administradores de
red, administradores de oficina y administradores de proyecto.

10

Este conjunto de casos de uso constituye los requerimientos funcionales de la

LAN.
La generacin de propuesta es una actividad de suma importancia en una firma
consultora, por tanto haremos el caso de uso Crear propuesta
El actor inicial es el consultor, quien inicia seccin en la LAN y tiene que ser
verificado como usuario vlido, luego tendr que utilizar algn software de oficina
para realizar propuestas. Probablemente la firma consultora tenga un funcionario
corporativo y dos consultores que revisen la propuesta antes de ser envida al
cliente. Por tanto, la propuesta es almacenada en un rea central accesible
mediante la LAN, y enva a los correos electrnicos de los tres revisores un
mensaje indique que la propuesta se encuentra lista y cul es su ubicacin.
Luego de recibir los comentarios y hacer las modificaciones de lugar, el consultor
imprime la propuesta y se la enva al cliente. Cuando termina todo el consultor se
retira de la red.

11

El diagrama de casos de usos de alto nivel de la firma consultora ser el siguiente:

Iniciar una seccin y ser verificado son dos pasos que pueden incluir otros casos
de uso:
Crear una propuesta
Utilizar software de oficina
Finalizar seccin de la red.
En el proceso crear propuesta pudieran otro detalle, como cuando la propuesta va
a un cliente nuevo incluyen informacin promocional de la empresa, que no es
necesaria para clientes constantes; surgiendo as otro caso de uso que extender
crear propuesta:
Crear propuesta para cliente nuevo

12

Por lo que el diagrama de casos de uso que resulta del caso uso crear propuesta
es el siguiente:

Organizacin del UML

Elementos estructurales de la UML

Las clases
Objetos
Actores
Interfaces
Casos de uso

Las relaciones en la UML son:

La asociacin
Generalizacin
Dependencia (inclusin y extensin)
Realizacin

13

Las relaciones: conectan a los elementos y de ese modo conectan a los modelos
con la realidad.
Agrupamiento: el paquete es el nico elemento de agrupamiento en el UML, y
permite organizar los elementos estructurales en un modelo.
Anotacin: la nota es el elemento de anotacin del UML; permitiendo adjuntar
restricciones, comentarios, requerimientos y grafios explicativos a sus modelos.
Extensin: los estereotipos o clises son dos estructuras que el UML proporciona
para extender el lenguaje.

14

Diagrama de Colaboracin
Es un diagrama de interaccin que resalta la organizacin estructural de los
objetos que envan y reciben mensaje.
Para representar un mensaje, se dibuja una flecha cerca de la lnea de asociacin
de los dos objetos, la cual apunta al objeto receptor. El mensaje se muestra en
una etiquete prximo a la flecha; por lo general, el mensaje le indica al objeto
receptor que ejecute una de sus operaciones y dentro de un parntesis los
parmetros con los cuales funcionara la operacin, en caso de que los hubiera

Veamos el diagrama de colaboracin para la compra de un refresco en una

mquina
La secuencia de pasos es la siguiente:

El cliente inserta el dinero en la mquina

El cliente hace su eleccin
El registrador verifica si el refresco elegido esta en el dispensador
Asumimos que si hay refresco y el registrador actualiza su reserva de
efectivo
El registrador hace que el dispensador entregue el re4freco en la fachada
de la mquina
Luego es diagrama es el siguiente:

15

Ahora, agreguemos el caso de cantidad de dinero incorrecta. El diagrama tiene

que contabilizar varias condiciones:
El usuario ha introducido ms dinero de la cuenta
a) La mquina dispone de la cantidad adecuada para el cambio

b) La mquina no dispone de la cantidad correcta para el cambio

16

Diagrama de Clases
En UML el diagrama de clases es uno de los tipos de diagramas o smbolo
esttico y tiene como fin describir la estructura de un sistema mostrando sus
clases, atributos y relaciones entre ellos.
Un diagrama de Clases representa las clases que sern utilizadas dentro del
sistema y las relaciones que existen entre ellas.
Estos diagramas son utilizados durante el proceso de anlisis y diseo de los
sistemas informticos, en donde se intentan conformar el diagrama conceptual de
la informacin que se manejar en el sistema.
En una aproximacin a un Caso de Uso guiado hacia el anlisis orientado a
objetos, el diagrama de clases se desarrolla a travs de informacin obtenida en
los Casos de Uso, Diagramas de Secuencia y Diagramas de Colaboracin. Los
objetos encontrados durante el anlisis son modelados en trminos de la clase a
la que instancian, y las interacciones entre objetos son referenciados a relaciones
entre las clases instanciadas.
Los diagramas de clases tienen las siguientes caractersticas:
Las clases define el mbito de definicin de un conjunto de objetos.
Cada objeto pertenece a una clase.
Los objetos se crean por instanciacin de las clases.

Elementos de un diagrama de clase:

17

Clase. Es la unidad bsica que encapsula toda la informacin de un Objeto, el

cual es la instancia de una clase
Atributos. Los atributos o caractersticas de una Clase pueden ser de tres tipos,
los que definen el grado de comunicacin y visibilidad de ellos con el entorno,
estos son:
public (+): Indica que el atributo ser visible tanto dentro como fuera de
la clase, es decir, es accesible desde todos lados.
private (-): Indica que el atributo slo ser accesible desde dentro de la
clase, slo por sus mtodos..
protected (#): Indica que el atributo no ser accesible desde fuera de la
clase, pero si podr ser accesado por mtodos de la clase adems de
las subclases que se deriven.
Mtodos. Los mtodos u operaciones de una clase son la forma en como sta
interacta con su entorno, stos pueden tener las caractersticas:
public (+): Indica que el mtodo ser visible tanto dentro como fuera de
la clase, es decir, es accesible desde todos lados.
private (-): Indica que el mtodo slo ser accesible desde dentro de la
clase, slo otros mtodos de la clase lo pueden accesar.
protected (#): Indica que el mtodo no ser accesible desde fuera de la
clase, pero si podr ser accesado por mtodos de la clase adems de
mtodos de las subclases que se deriven.

La multiplicidad o bien, cardinalidad de las relaciones indica el grado y nivel de

dependencia, se anotan en cada extremo de la relacin y stas pueden ser:
Uno o muchos: 1..* (1..n)
0 o muchos: 0..* (0..n)
Nmero fijo: m (m denota el nmero).

18

Relaciones entre Clases:

Herencia:
Indica que una subclase hereda los mtodos y atributos
especificados por una Super Clase, por ende la Subclase adems de poseer sus
propios mtodos y atributos, poseer las caractersticas y atributos visibles de la
Super Clase.
Agregacin:
Para modelar objetos complejos, n bastan los tipos de
datos bsicos que proveen los lenguajes: enteros, reales y secuencias de
caracteres. Cuando se requiere componer objetos que son instancias de clases
definidas por el desarrollador de la aplicacin.
Asociacin:
La relacin entre clases conocida como Asociacin,
permite asociar objetos que colaboran entre s. Cabe destacar que no es una
relacin fuerte, es decir, el tiempo de vida de un objeto no depende del otro.
Dependencia:
Representa un tipo de relacin muy particular, en la
que una clase es instanciada (su instanciacin es dependiente de otro
objeto/clase). Se denota por una flecha punteada.
Clase Abstracta: Una clase abstracta se denota con el nombre de la clase y de los
mtodos con letra itlica. Esto indica que la clase definida no puede ser
instanciada pues posee mtodos abstractos (an no han sido definidos, es decir,
sin implementacin). La nica forma de utilizarla es definiendo subclases, que
implementan los mtodos abstractos definidos.

Pasos para el diagrama de clases:

Identificar las clases.

Mostrar los atributos y operaciones (posteriormente)
Dibujar asociaciones
Etiquetar asociaciones y en caso necesario los roles
Indicar multiplicidad
Dibujar fechas de direccin

19

Ilustracin de un diagrama de clase:

Fuente de la imagen: http://www.ctr.unican.es/asignaturas/pp/

20