Introduccin al lenguaje

unificado de modelado, UML

UML es un lenguaje estndar que sirve para escribir los planos del software,
puede utilizarse para visualizar, especificar, construir y documentar todos los
artefactos que componen un sistema con gran cantidad de software. UML
puede usarse para modelar desde sistemas de informacin hasta aplicaciones
distribuidas basadas en Web, pasando por sistemas empotrados de tiempo
real. UML es solamente un lenguaje por lo que es slo una parte de un mtodo
de desarrollo software, es independiente del proceso aunque para que sea
optimo debe usarse en un proceso dirigido por casos de uso, centrado en la
arquitectura, iterativo e incremental.
UML es un lenguaje por que proporciona un vocabulario y las reglas para
utilizarlo, adems es un lenguaje de modelado lo que significa que el
vocabulario y las reglas se utilizan para la representacin conceptual y fsica
del sistema.
UML es un lenguaje que nos ayuda a interpretar grandes sistemas mediante
grficos o mediante texto obteniendo modelos explcitos que ayudan a la
comunicacin durante el desarrollo ya que al ser estndar, los modelos podrn
ser interpretados por personas que no participaron en su diseo (e incluso por
herramientas) sin ninguna ambigedad. En este contexto, UML sirve para
especificar, modelos concretos, no ambiguos y completos.
Debido a su estandarizacin y su definicin completa no ambigua, y aunque no
sea un lenguaje de programacin, UML se puede conectar de manera directa a
lenguajes de programacin como Java, C++ o Visual Basic, esta
correspondencia permite lo que se denomina como ingeniera directa (obtener
el cdigo fuente partiendo de los modelos) pero adems es posible reconstruir
un modelo en UML partiendo de la implementacin, o sea, la ingeniera inversa.
UML proporciona la capacidad de modelar actividades de planificacin de
proyectos y de sus versiones, expresar requisitos y las pruebas sobre el
sistema, representar todos sus detalles as como la propia arquitectura.
Mediante estas capacidades se obtiene una documentacin que es valida
durante todo el ciclo de vida de un proyecto.

Vista general de UML

Para conocer la estructura de UML, en la figura 3 vemos una vista general de
todos sus componentes, esto har que nos resulte ms fcil la comprensin de
cada uno de ellos.
El lenguaje UML se compone de tres elementos bsicos, los bloques de
construccin, las reglas y algunos mecanismos comunes. Estos elementos

interaccionan entre s para dar a UML el carcter de completitud y noambigedad que antes comentbamos.
Los bloques de construccin se dividen en tres partes: Elementos, que son
las abstracciones de primer nivel, Relaciones, que unen a los elementos entre
s, y los Diagramas, que son agrupaciones interesantes de elementos.
Existen cuatro tipos de elementos en UML, dependiendo del uso que se haga
de ellos: elementos estructurales, elementos de comportamiento, elementos
de agrupacin y elementos de anotacin. Las relaciones, a su vez se dividen
para abarcar las posibles interacciones entre elementos que se nos pueden
presentar a la hora de modelar usando UML, estas son: relaciones de
dependencia, relaciones de asociacin, relaciones de generalizacin y
relaciones de realizacin.
Se utilizan diferentes diagramas dependiendo de qu, nos interese representar
en cada momento, para dar diferentes perspectivas de un mismo problema,
para ajustar el nivel de detalle..., por esta razn UML soporta un gran numero
de diagramas diferentes aunque, en la practica, slo se utilicen un pequeo
nmero de combinaciones.

UML proporciona un conjunto de reglas que dictan las pautas a la hora de

realizar asociaciones entre objetos para poder obtener modelos bien formados,
estas son reglas semnticas que afectan a los nombres, al alcance de dichos
nombres, a la visibilidad de estos nombres por otros, a la integridad de unos
elementos con otros y a la ejecucin, o sea la vista dinmica del sistema.
UML proporciona una serie de mecanismos comunes que sirven para que cada
persona o entidad adapte el lenguaje a sus necesidades, pero dentro de un
marco ordenado y siguiendo unas ciertas reglas para que en el trasfondo de la

adaptacin no se pierda la semntica propia de UML. Dentro de estos

mecanismos estn las especificaciones, que proporcionan la explicacin
textual de la sintaxis y semntica de los bloques de construccin. Otro
mecanismo es el de los adornos que sirven para conferir a los modelos de
ms semntica, los adornos son elementos secundarios ya que proporcionan
ms nivel de detalle, que quiz en un primer momento no sea conveniente
descubrir. Las divisiones comunes permiten que los modelos se dividan al
menos en un par de formas diferentes para facilitar la comprensin desde
distintos puntos de vista, en primer lugar tenemos la divisin entre clase y
objeto (clase es una abstraccin y objeto es una manifestacin de esa
abstraccin), en segundo lugar tenemos la divisin interfaz / implementacin
donde la interfaz presenta un contrato (algo que se va a cumplir de una
determinada manera) mientras que la implementacin es la manera en que se
cumple dicho contrato. Por ultimo, los mecanismos de extensibilidad que
UML proporciona sirven para evitar posibles problemas que puedan surgir
debido a la necesidad de poder representar ciertos matices, por esta razn
UML incluye los estereotipos, para poder extender el vocabulario con nuevos
bloques de construccin, los valores etiquetados, para extender las
propiedades un bloque, y las restricciones, para extender la semntica.
De esta manera UML es un lenguaje estndar abierto-cerrado siendo posible
extender el lenguaje de manera controlada.

Bloques de construccin de UML

A continuacin se van a describir todos los elementos que componen los
bloques estructurales de
UML, as como su notacin, para que nos sirva de introduccin y se vaya
generando un esquema conceptual sobre UML. En temas sucesivos se tratar
con ms profundidad cada uno de los bloques.

Elementos Estructurales
Los elementos estructurales en UML, es su mayora, son las partes estticas del
modelo y representan cosas que son conceptuales o materiales.

Clases
Una clase es una descripcin de un conjunto de objetos que comparten los
mismos atributos, operaciones, relaciones y semntica. Una clase implementa
una o ms interfaces. Grficamente se representa como un rectngulo que
incluye su nombre, sus atributos y sus operaciones (figura 3).

Interfaz
Una interfaz es una coleccin de operaciones que especifican un servicio de
una determinada clase o componente. Una interfaz describe el
comportamiento visible externamente de ese elemento, puede mostrar el
comportamiento completo o slo una parte del mismo. Una interfaz describe
un conjunto de especificaciones de operaciones (o sea su signatura) pero
nunca su implementacin. Se representa con un crculo, como podemos ver en
la figura 4, y rara vez se encuentra aislada sino que ms bien conectada a la
clase o componente que realiza.

Colaboracin
Define una interaccin y es una sociedad de roles y otros elementos que
colaboran para proporcionar un comportamiento cooperativo mayor que la
suma de los comportamientos de sus elementos. Las colaboraciones tienen
una dimensin tanto estructural como de comportamiento. Una misma clase
puede participar en diferentes colaboraciones. Las colaboraciones representan
la implementacin de patrones que forman un sistema. Se representa
mediante una elipse con borde discontinuo, como en la figura 5.

Casos de Uso

Un caso de uso es la descripcin de un conjunto de acciones que un sistema

ejecuta y que produce un determinado resultado que es de inters para un
actor particular. Un caso de uso se utiliza para organizar los aspectos del
comportamiento en un modelo. Un caso de uso es realizado por una
colaboracin. Se representa como en la figura 6, una elipse con borde continuo.

Clase Activa
Es una clase cuyos objetos tienen uno o ms procesos o hilos de ejecucin por
lo y tanto pueden dar lugar a actividades de control. Una clase activa es igual
que una clase, excepto que sus objetos representan elementos cuyo
comportamiento es concurrente con otros elementos. Se representa igual que
una clase (figura 3), pero con lneas ms gruesas (figura 7).

Componentes
Un componente es una parte fsica y reemplazable de un sistema que conforma
con un conjunto de interfaces y proporciona la implementacin de dicho
conjunto. Un componente representa tpicamente el empaquetamiento fsico
de diferentes elementos lgicos, como clases, interfaces y colaboraciones.

Nodos
Un nodo es un elemento fsico que existe en tiempo de ejecucin y representa
un recurso computacional que, por lo general, dispone de algo de memoria y,
con frecuencia, de capacidad de procesamiento. Un conjunto de componentes
puede residir en un nodo.

Estos siete elementos vistos son los elementos estructurales bsicos que se
pueden incluir en un modelo UML. Existen variaciones sobre estos elementos
bsicos, tales como actores, seales, utilidades (tipos de clases), procesos e
hilos (tipos de clases activas) y aplicaciones, documentos, archivos, bibliotecas,
pginas y tablas (tipos de componentes).

Elementos de comportamiento
Los elementos de comportamiento son las partes dinmicas de un modelo. Se
podra decir que son los verbos de un modelo y representan el comportamiento
en el tiempo y en el espacio. Los principales elementos son los dos que siguen.

Interaccin
Es un comportamiento que comprende un conjunto de mensajes
intercambiados entre un conjunto de objetos, dentro de un contexto particular
para conseguir un propsito especfico. Una interaccin involucra otros muchos
elementos, incluyendo mensajes, secuencias de accin (comportamiento

invocado por un objeto) y enlaces (conexiones entre objetos). La

representacin de un mensaje es una flecha dirigida que normalmente con el
nombre de la operacin.

Maquinas de estados
Es un comportamiento que especifica las secuencias de estados por las que
van pasando los objetos o las interacciones durante su vida en respuesta a
eventos, junto con las respuestas a esos eventos. Una maquina de estados
involucra otros elementos como son estados, transiciones (flujo de un estado a
otro), eventos (que disparan una transicin) y actividades (respuesta de una
transicin)

Elementos de agrupacin
Forman la parte organizativa de los modelos UML. El principal elemento de
agrupacin es el paquete, que es un mecanismo de propsito general para
organizar elementos en grupos. Los elementos estructurales, los elementos de
comportamiento, incluso los propios elementos de agrupacin se pueden
incluir en un paquete.
Un paquete es puramente conceptual (slo existe en tiempo de desarrollo).
Grficamente se representa como una carpeta conteniendo normalmente su
nombre y, a veces, su contenido.

Elementos de anotacin

Los elementos de anotacin son las partes explicativas de los modelos UML.
Son comentarios que se pueden aplicar para describir, clasificar y hacer
observaciones sobre cualquier elemento de un modelo.
El tipo principal de anotacin es la nota que simplemente es un smbolo para
mostrar restricciones y comentarios junto a un elemento o un conjunto de
elementos.

Relaciones
Existen cuatro tipos de relaciones entre los elementos de un modelo UML.
Dependencia, asociacin, generalizacin y realizacin, estas se describen a
continuacin:

Dependencia
Es una relacin semntica entre dos elementos en la cual un cambio a un
elemento (el elemento independiente) puede afectar a la semntica del otro
elemento (elemento dependiente). Se representa como una lnea discontinua
(figura 14), posiblemente dirigida, que a veces incluye una etiqueta.

Asociacin
Es una relacin estructural que describe un conjunto de enlaces, los cuales son
conexiones entre objetos. La agregacin es un tipo especial de asociacin y
representa una relacin estructural entre un todo y sus partes. La asociacin se
representa con una lnea continua, posiblemente dirigida, que a veces incluye
una etiqueta. A menudo se incluyen otros adornos para indicar la multiplicidad
y roles de los objetos involucrados, como podemos ver en la figura 15.

Generalizacin
Es una relacin de especializacin / generalizacin en la cual los objetos del
elemento especializado (el hijo) pueden sustituir a los objetos del elemento
general (el padre). De esta forma, el hijo comparte la estructura y el
comportamiento del padre. Grficamente, la generalizacin se representa con
una lnea con punta de flecha vaca (figura 16).

Realizacin
Es una relacin semntica entre clasificadores, donde un clasificador especifica
un contrato que otro clasificador garantiza que cumplir. Se pueden encontrar
relaciones de realizacin en dos sitios: entre interfaces y las clases y
componentes que las realizan, y entre los casos de uso y las colaboraciones
que los realizan. La realizacin se representa como una mezcla entre la
generalizacin (figura 16) y la dependencia (figura 14), esto es, una lnea
discontinua con una punta de flecha vaca (figura 17).

Diagramas
Los diagramas se utilizan para representar diferentes perspectivas de un
sistema de forma que un diagrama es una proyeccin del mismo. UML
proporciona un amplio conjunto de diagramas que normalmente se usan en

pequeos subconjuntos para poder representar las cinco vistas principales de

la arquitectura de un sistema.

Diagramas de Clases
Muestran un conjunto de clases, interfaces y colaboraciones, as como sus
relaciones. Estos diagramas son los ms comunes en el modelado de sistemas
orientados a objetos y cubren la vista de diseo esttica o la vista de procesos
esttica (s incluyen clases activas).

Diagramas de Objetos
Muestran un conjunto de objetos y sus relaciones, son como fotos instantneas
de los diagramas de clases y cubren la vista de diseo esttica o la vista de
procesos esttica desde la perspectiva de casos reales o prototpicos.

Diagramas de Casos de Usos

Muestran un conjunto de casos de uso y actores (tipo especial de clases) y sus
relaciones. Cubren la vista esttica de los casos de uso y son especialmente
importantes para el modelado y organizacin del comportamiento.

Diagramas de Secuencia y de Colaboracin

Tanto los diagramas de secuencia como los diagramas de colaboracin son un
tipo de diagramas de interaccin. Constan de un conjunto de objetos y sus
relaciones, incluyendo los mensajes que se pueden enviar unos objetos a otros.
Cubren la vista dinmica del sistema. Los diagramas de secuencia enfatizan el
ordenamiento temporal de los mensajes mientras que los diagramas de
colaboracin muestran la organizacin estructural de los objetos que envan y
reciben mensajes. Los diagramas de secuencia se pueden convertir en
diagramas de colaboracin sin prdida de informacin, lo mismo ocurren en
sentido opuesto.

Diagramas de Estados
Muestran una maquina de estados compuesta por estados, transiciones,
eventos y actividades. Estos diagramas cubren la vista dinmica de un sistema
y son muy importantes a la hora de modelar el comportamiento de una
interfaz, clase o colaboracin.

Diagramas de Actividades
Son un tipo especial de diagramas de estados que se centra en mostrar el flujo
de actividades dentro de un sistema. Los diagramas de actividades cubren la
parte dinmica de un sistema y se utilizan para modelar el funcionamiento de
un sistema resaltando el flujo de control entre objetos.

Diagramas de Componentes
Muestra la organizacin y las dependencias entre un conjunto de componentes.
Cubren la vista de la implementacin esttica y se relacionan con los
diagramas de clases ya que en un componente suele tener una o ms clases,
interfaces o colaboraciones

Diagramas de Despliegue
Representan la configuracin de los nodos de procesamiento en tiempo de
ejecucin y los componentes que residen en ellos. Muestran la vista de
despliegue esttica de una arquitectura y se relacionan con los componentes
ya que, por lo comn, los nodos contienen uno o ms componentes.

Arquitectura
El desarrollo de un sistema con gran cantidad de software requiere que este
sea visto desde diferentes perspectivas. Diferentes usuarios (usuario final,
analistas, desarrolladores, integradores, jefes de proyecto...) siguen diferentes
actividades en diferentes momentos del ciclo de vida del proyecto, lo que da
lugar a las diferentes vistas del proyecto, dependiendo de qu interese ms en
cada instante de tiempo.
La arquitectura es el conjunto de decisiones significativas sobre:
La organizacin del sistema
Seleccin de elementos estructurales y sus interfaces a travs de los cuales
se constituye el sistema.
El Comportamiento, como se especifica las colaboraciones entre esos
componentes.
Composicin de los elementos estructurales y de comportamiento en
subsistemas progresivamente ms grandes.
El estilo arquitectnico que gua esta organizacin: elementos estticos y
dinmicos y sus interfaces, sus colaboraciones y su composicin.

La una arquitectura que no debe centrarse nicamente en la estructura y en el

comportamiento, sino que abarque temas como el uso, funcionalidad,
rendimiento, capacidad de adaptacin, reutilizacin, capacidad para ser
comprendida, restricciones, compromisos entre alternativas, as como aspectos
estticos. Para ello se sugiere una arquitectura que permita describir mejor los
sistemas desde diferentes vistas, figura 18, donde cada una de ellas es una
proyeccin de la organizacin y la estructura centrada en un aspecto particular
del sistema.
La vista de casos de uso comprende la descripcin del comportamiento del
sistema tal y como es percibido por los usuarios finales, analistas y encargados
de las pruebas y se utilizan los diagramas de casos de uso para capturar los
aspectos estticos mientras que los dinmicos son representados por
diagramas de interaccin, estados y actividades.
La vista de diseo comprende las clases, interfaces y colaboraciones que
forman el vocabulario del problema y de la solucin. Esta vista soporta
principalmente los requisitos funcionales del sistema, o sea, los servicios que el
sistema debe proporcionar. Los aspectos estticos se representan mediante
diagramas de clases y objetos y los aspectos dinmicos con diagramas de
interaccin, estados y actividades.
La vista de procesos comprende los hilos y procesos que forman mecanismos
de sincronizacin y concurrencia del sistema cubriendo el funcionamiento,
capacidad de crecimiento y el rendimiento del sistema. Con UML, los aspectos
estticos y dinmicos se representan igual que en la vista de diseo, pero con
el nfasis que aportan las clases activas, las cuales representan los procesos y
los hilos.

La Vista de implementacin comprende los componentes y los archivos que un

sistema utiliza para ensamblar y hacer disponible el sistema fsico. Se ocupa
principalmente de la gestin de configuraciones de las distintas versiones del
sistema. Los aspectos estticos se capturan con los diagramas de
componentes y los aspectos dinmicos con los diagramas de interaccin,
estados y actividades.
La vista de despliegue de un sistema contiene los nodos que forman la
topologa hardware sobre la que se ejecuta el sistema. Se preocupa
principalmente de la distribucin, entrega e instalacin de las partes que
constituyen el sistema. Los aspectos estticos de esta vista se representan
mediante los diagramas de despliegue y los aspectos dinmicos con diagramas
de interaccin, estados y actividades.

Ciclo de Vida
Se entiende por ciclo de vida de un proyecto software a todas las etapas por
las que pasa un proyecto, desde la concepcin de la idea que hace surgir la
necesidad de disear un sistema software, pasando por el anlisis, desarrollo,
implantacin y mantenimiento del mismo y hasta que finalmente muere por
ser sustituido por otro sistema.
Aunque UML es bastante independiente del proceso, para obtener el mximo
rendimiento de UML se debera considerar un proceso que fuese:
Dirigido por los casos de uso, o sea, que los casos de uso sean un artefacto
bsico para establecer el comportamiento del deseado del sistema, para
validar la arquitectura, para las pruebas y para la comunicacin entre las
personas involucradas en el proyecto.
Centrado en la arquitectura de modo que sea el artefacto bsico para
conceptuar, construir, gestionar y hacer evolucionar el sistema.
Un proceso iterativo, que es aquel que involucra la gestin del flujo de
ejecutables del sistema, e incremental, que es aquel donde cada nueva versin
corrige defectos de la anterior e incorpora nueva funcionalidad. Un proceso
iterativo e incremental se denomina dirigido por el riesgo, lo que significa que
cada nueva versin se ataca y reducen los riesgos ms significativos para el
xito del proyecto.

Este proceso, dirigido a los casos de uso, centrado en la arquitectura, iterativo

e incremental pude descomponerse en fases, donde cada fase es el intervalo
de tiempo entre dos hitos importantes del proceso, cuando se cumplen los
objetivos bien definidos, se completan los artefactos y se toman decisiones
sobre si pasar o no a la siguiente fase. En el ciclo de vida de un proyecto
software existen cuatro fases, vanse en la figura 19. La iniciacin, que es
cuando la idea inicial est lo suficientemente fundada para poder garantizar la
entrada en la fase de elaboracin, esta fase es cuando se produce la
definicin de la arquitectura y la visin del producto. En esta fase se deben
determinar los requisitos del sistema y las pruebas sobre el mismo.
Posteriormente se pasa a la fase de construccin, que es cuando se pasa de
la base arquitectnica ejecutable hasta su disponibilidad para los usuarios, en
esta fase se reexaminan los requisitos y las pruebas que ha de soportar. La
transicin, cuarta fase del proceso, que es cuando el software se pone en
mano de los usuarios.
Raramente el proceso del software termina en la etapa de transicin, incluso
durante esta fase el proyecto es continuamente reexaminado y mejorado
erradicando errores y aadiendo nuevas funcionalidades no contempladas.

Un elemento que distingue a este proceso y afecta a las cuatro fases es una
iteracin, que es un conjunto de bien definido de actividades, con un plan y
unos criterios de evaluacin, que acaban en una versin del producto, bien
interna o externa.