1

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.

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

2

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.

3

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.

4

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.

5

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.

6

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.

7

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 y .

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 () Cobrar Renta.

8

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.

9

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.

10

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.

11

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.

12

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

13

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

14

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.

15

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:

16

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

17

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:

18

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).

19

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

20

Ilustracin de un diagrama de clase:

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