Surgimiento del UML

El trabajo en el U M L comenz oficialmente en Octubre de 1994 cuando

Rumbaugh se uni a Booch en Rational. Su objetivo era el de crear un nuevo
mtodo, el "Mtodo Unificado," que unira el mtodo de Booch y el mtodo
OMT-2. L a versin 0.8 del M todo U nificado fue liberada en Octubre de 1995.
Alrededor de la misma fecha Ivar Jacobson - el hombre detrs de los mtodos
OOSE y Objectory se uni a ellos y el alcance del UML fue expandido para
incorporar OOSE. Rational Software tambin compr Objective Systems, la
empresa sueca que desarroll y distribuy el Objectory.
En este momento, los futuros desarrolladores del UML tambin se dieron
cuenta que su trabajo estaba dirigido ms directamente hacia la creacin de un
lenguaje de modelaje estndar, y renombraron su trabajo como Lenguaje de
Modelaje Unificado. Tener xito en el establecimiento de un lenguaje de
modelaje estndar era una tarea ms simple que hacer la misma cosa para un
proceso, debido a que el proceso difiere sustancialmente entre las diferentes
compaas y culturas. Es dudoso, si del todo posible, crear un proceso estndar
que pueda ser utilizado por todos.
Uso del UML
El UML es utilizado para modelar sistemas, cuyo rango es muy amplio: muchos
tipos diferentes de sistemas pueden ser descritos. El UML puede ser utilizado
tambin en las diferentes fases del desarrollo de un sistema, desde la
especificacin de los requerimientos hasta la prueba del sistema terminado.
Diferentes tipos de sistemas
El objetivo del UML es describir cualquier tipo de sistema, en trminos de
diagramas orientados a objetos. Naturalmente, el uso ms comn es crear
modelos de sistemas de software, pero el UML tambin es utilizado para
describir sistemas mecnicos sin ningn software o la organizacin de un
negocio. Aqu hay algunos tipos diferentes de sistemas y sus caractersticas
ms comunes.

Sistemas de Informacin: Almacenan, recuperan, transforman y presentan

informacin a los usuarios. Manejan grandes cantidades de datos con
relaciones complejas, los cuales son almacenados en bases de datos
relacinales o de objetos.
Sistemas Tcnicos: Mantienen y controlan equipo tcnico tal como procesos
de telecomunicaciones, procesos de sistemas militares o procesos industriales.
Deben mantener las interfaces especiales del equipo y tienen menos software

que los sistemas de informacin. Los sistemas tcnicos son a menudo sistemas
de tiempo real.
Sistemas de Tiempo Real Empotrados: Se ejecutan en un hardware simple
empotrado en cualquier otro equipo tal como un telfono mvil, un carro, un
utensilio del hogar, etc. Esto es llevado a cabo a travs de programacin de
bajo nivel que requiere soporte de tiempo real. Estos sistemas a menudo
carecen de dispositivos tales como pantalla, disco duro, etc.
Sistemas Distribuidos: Distribuidos en una serie de mquinas donde los datos
son transferidos fcilmente de una m quina a otra. Requieren de mecanismos
de comunicacin sincronizada para asegurar la integridad de los datos y son
construidos a menudo sobre mecanismos de objetos tales como CORBA.
COM/DCOM, o Java Beans/RMI.
Software de Sistemas: Definen la infraestructura tcnica que utiliza otro
software. Los sistemas operativos, bases de datos, e interfaces de usuario
realizan operaciones de bajo nivel en el hardware, mientras presentan
interfaces genricas para ser utilizadas por otro software.
Sistemas de Negocios: Describen los objetivos, los recursos (humanos,
computadoras, etc.), las reglas (leyes, estrategias del negocio, polticas, etc.), y
el trabajo actual en el negocio (procesos del negocio).

Es necesario que el usuario tenga visin del alcance y la estructura del UML.
Ahora daremos un vistazo a las diferentes partes del UML:
Vistas: Las vistas muestran diferentes aspectos de los sistemas que son
modelados. U na vista no es un grfico, pero es una abstraccin que consiste
en una serie de diagramas. Solamente definiendo una serie de vistas, cada una
mostrando un aspecto paiticular del sistema, puede ser construida una imagen
completa del sistema. Las vistas tambin enlazan el lenguaje de modelaje al
proceso/mtodo escogido para el desarrollo.
Diagramas: Son los grficos que describen los contenidos en una vista. El
UML tiene nueve tipos diferentes de diagramas que son utilizados en
combinacin para proporcionar todas las vistas del sistema.
Elementos del modelo: Los conceptos utilizados en los diagramas son los
elementos del modelo los cuales representan conceptos orientados a objetos
comunes, tales como clases, objetos, mensajes, y las relaciones entre estos
conceptos incluyendo asociacin, dependencia y generalizacin. U n elemento
del modelo es utilizado en varios diagramas diferentes, pero siempre tiene el
mismo significado y smbolo.

 Mecanismo Generales: Los mecanismos generales proporcionan comentarios

extras, informacin, o semntica acerca de un elemento del modelo; ellos
proporcionan tambin mecanismos de extensin para adaptar o extender el
UML a un mtodo, proceso, organizacin o usuario especfico.

Vista de Casos de Uso: Es una vista que muestra la funcionalidad de un

sistema como es percibida por los actores externos.
Vista Lgica: Es una vista que muestra como es diseada la funcionalidad
dentro del sistema, en trminos de las estructuras estticas del sistema y su
comportamiento dinmico.
Vista de Componentes: Es una vista que muestra la organizacin de los
componentes de cdigo.
Vista de Procesos: Es una vista que muestra la concurrencia en el sistema,
resolviendo problemas de comunicacin y sincronizacin que estn presentes
en un sistema concurrente.
Vista de Despliegue: Es una vista que muestra el despliegue de un sistema
dentro de una arquitectura fsica con computadoras y dispositivos llamados
nodos.

Diagrama de Casos de Uso

Un diagrama de casos de uso es una vista grfica de algunos o todos los
actores, casos de uso y sus interacciones, identificados para un sistema. Cada
sistema tpicamente tiene un diagrama de Caso de Uso Principal, el cual es la
imagen de las fronteras del sistema (actores) y la funcionalidad principal
proporcionada por el sistema (casos de uso). Otros diagramas de caso de uso
pueden ser creados cuando sea necesario. Algunos ejemplos son:
Un diagrama que muestre todos los casos de uso para un actor determinado.
Un diagrama que muestre todos los casos de uso implementados en una
iteracin.
Un diagrama que muestre un caso de uso y sus relaciones.
Diagrama de Estados
Un diagrama de estados es tpicamente un complemento de la descripcin de
una clase. Muestra todos los estados posibles que los objetos de la clase
puedan tener, y qu eventos causan un cambio de estado. Un evento puede
ser otro objeto que enva un mensaje - por ejemplo, que el tiempo especificado

se ha terminado - o que alguna otra condicin ha sido cumplida. Un cambio de

estado es llamado transicin. Una transicin puede tener tambin una accin
conectada a l para especificar qu sera hecho en conexin con el estado de
transicin.
Los diagramas de estados 110 son dibujados para todas las clases, solamente
para aquellas que tienen una serie de estados bien definidos y en donde el
comportamiento de la clase es afectado y cambiado por los estados diferentes.
Los diagramas de estados pueden tambin ser dibujados para el sistema en su
totalidad.

Las relaciones son tambin elementos del modelo, y son utilizadas para
interconectar otros elementos del modelo unos a otros. Algunas relaciones
diferentes son:
Asociacin: Conecta elementos y enlaza instancias.
Generalizacin: Tambin llamada herencia, esto significa que un elemento
puede ser la especializacin de otro elemento.
Dependencia: Muestra que un elemento depende de alguna manera de otro
elemento.
Agregacin: Es una forma de asociacin en la cual un elemento contiene
otros elementos.
Refinamiento: Es una forma de generalizacin entre un elemento a mayor
nivel de detalle que otro pero que representan lo mismo.

La siguiente figura muestra ejemplos de las relaciones antes descritas: