Este documento explica qué es UML y sus principales características. UML es un lenguaje visual para modelar sistemas que facilita la comunicación entre los involucrados en un proyecto. Incluye diagramas para modelar la estructura y dinámica de un sistema. Algunos diagramas comunes son de clases, casos de uso y secuencia.

1. Tema 5. UML

2. Qué es
 El lenguaje unificado de modelado (Unified Modeling Language o UML), es una notación
visual orientada a la elaboración de modelos de procesos y/o productos. Dispone de un
repertorio limitado de unidades con significado (Clases, Acciones, Objetos, Estados,
Casos de Uso), y una gramática que define un conjunto de reglas de combinación para
formar otras unidades de significado más complejas (diagramas, modelos), con una
determinada escala de abstracción y granularidad.
 Las unidades básicas de una construcción UML pueden pertenecer a tres categorías:
estructura, función y conectores. Cada una de ellas está orientada a la representación de
una realidad desde distintas perspectivas, mediante la elaboración de un modelo basado
en múltiples diagramas.
 Las unidades de estructura definen, básicamente, tipos de objetos o instancias de Clases
con sus atributos (indican qué representan), sus responsabilidades (indican qué pueden
hacer) y su nivel de visibilidad (indican con quién pueden relacionarse).
 Las unidades de función expresan acciones y procesos como resultado de la interacción
de los objetos en un escenario acotado (eventos), y modelan la sucesión de estados que
transcurren a lo largo del ciclo de vida de un objeto.
 Los conectores definen las categorías de relación entre Clases, objetos, acciones,
procesos, estados y la trazabilidad entre todas las unidades de estructura y función.

3. Tipos de diagramas
 Los tipos de diagramas definidos en UML 2.0 son los mostrados en la imagen

5.  Como se ve en la figura el conjunto de diagramas se divide en
dos: aquellos que modelan la estructura estática del sistema (el
modelo estático) y los que modelan la estructura dinámica (el
modelo dinámico).
 El modelo estático captura los elementos y las relaciones
estructurales entre elementos; el modelo dinámico muestra
cómo los elementos interactúan para generar el comportamiento
requerido del sistema.
 No existe un orden específico en el que deban crearse los
diagramas aunque, normalmente, se empieza con los diagramas
de casos de uso con el fin de ser capaces de definir el alcance
del sistema. No obstante, es muy habitual, trabajar en varios
diagramas en paralelo refinando cada uno de ellos a medida que
se va descubriendo más información y detalles sobre el sistema
que se está diseñando.

6. Ejemplos
 Los ejemplos se han extraído de una aplicación de comercio
electrónico muy sencilla que permite a los clientes(Customer) comprar
libros y CDs on line. El sistema es gestionado por:
 Encargado (ShopKeeper): puede añadir y quitar productos del catálogo
disponible on line
 Administrador (SystemAdministrator): crea y elimina usuarios para que
puedan utilizar el sistema
 Transportista (Dispatcher): hace llegar a los clientes los productos
adquiridos.
 Inventario (Inventary): gestiona las existencias de los productos que se
comercializan.
 Compañía Gestora de tarjetas de crédito (CardProcessingCompany):
valida el número de tarjeta de crédito del cliente y la disponibilidad de
saldo para efectuar la compra.

7. Diagrama de casos de uso
 Define las funcionalidades del sistema, así
como las relaciones existentes entre ellas.
Además, muestra a los usuarios del mismo y
las funcionalidades del sistema con las que
pueden interactuar. En temas posteriores se
analizará en detalle. Junto con los diagramas
de clase son los más importantes.

9. Estándar UML
 La notación UML (no hay que confundir con las metodologías que utilizan dicha
notación), se ha convertido desde finales de los 90 en un estándar para
modelar con tecnología orientada a objetos todos aquellos elementos que
configuran la arquitectura de un sistema de información y, por extensión, de los
procesos de negocio de una organización. De la misma manera que los planos
de un arquitecto disponen el esquema director a partir del cual levantamos un
edificio, los diagramas UML suministran un modelo de referencia para
formalizar los procesos, reglas de negocio, objetos y componentes de una
organización. La interacción de todos estos elementos es una representación
de nuestra realidad.
 Nuestros límites para entender esta realidad están en nuestro lenguaje. El
mundo es la suma total de lo que podemos definir, organizar y visualizar. Cabe
preguntarse ¿de qué manera un modelo en UML representa nuestra
experiencia?. Enseñar a utilizar un lenguaje formal siempre es problemático. Es
necesario mostrar cómo este lenguaje puede ser aplicado a la realidad tal como
la conocemos y tal como la compartimos con los demás. La clave está en
discriminar cuales son aquellos procedimientos esenciales que nos permiten
evitar costosas confusiones conceptuales.

10.  No es mediante el descubrimiento de nuevos objetos y de sus
múltiples conexiones que avanzamos en las respuestas a
nuestros interrogantes cuando modelamos un dominio, sino
mediante la disolución de las contradicciones que existen entre
los conceptos ya conocidos y, en último caso, mediante la
reducción de su número despejando aquellos conceptos que no
añaden valor a la comprensión de dicho dominio.
 La programación orientada a objetos persigue el antiguo
principio del divide y vencerás. Su objetivo es descomponer la
complejidad en partes más manejables y comprensibles. No
parece que esto sea algo novedoso con respecto a la tradicional
descomposición funcional de los métodos estructurados. Sin
embargo, la gran diferencia reside en aplicar la dualidad
estructura-función en pequeñas unidades capaces de
comunicarse y reaccionar en base a la aparición de una serie de
eventos. El esquema dominante de la separación de estructuras
de datos y funciones (bases de datos y programas) está
amenazado pero aún se resiste a desaparecer.

11.  Mucha gente cree que la principal utilidad de la orientación a objetos es la reutilización del
código para conseguir un desarrollo más rápido de las aplicaciones (Rapid Application
Development). No comparto esta opinion. Si hay algo que caracteriza un entorno de
desarrollo actual es la constante del cambio. Todo proyecto que sobrepase los tres meses
está amenazado por la aparición de nuevas plataformas más exigentes, la extinción de
herramientas sin previo aviso y, de manera sistemática, por la rotación del personal crítico
encargado del proyecto. También está sometido, como no :-), a los cambios de
requerimientos del cliente que a su vez están plenamente justificados por la readaptación
de sus procesos de negocio a un mercado inestable.
 Ante este cuadro de incertidumbre, el mayor desafio de una metodología de desarrollo es
su adaptación para el cambio. Esto significa crear modelos que faciliten la comunicación
entre todos los agentes involucrados en el sistema en construcción; que hagan visible la
trazabilidad entre la concepción de los componentes, su especificación, implementación e
instalación; significa el diseño de arquitecturas que faciliten la gestión de las dependencias
entre estos componentes, que sean en fin, facilmente reemplazables por otros más
optimizados o bien por componentes que aporten una mayor funcionalidad y/o facilidad de
uso.
 La dinámica de cambio no se desarrolla en la ingeniería del software con la misma
velocidad vertiginosa con que nos tiene acostumbrados la tecnología del hardware. La
clave reside en que a diferencia de la electrónica, en los dominios del desarrollo de
software no existe un vocabulario unificado. Desde la fase de concepción de un sistema a
la instalación de sus componentes hay que mapear entre sí una gran diversidad de
lenguajes orientados al análisis, diseño, código ejecutable, esquemas de bases de datos,
componentes de páginas web, entre otros. Esta distancia entre la concepción y la
usabilidad de un producto o de un proceso de negocio, exige cada vez más la capacidad
de cooperación y comunicación de un equipo interdisciplinar muy especializado.

12. ¿Cuando usamos UML?
 Usamos UML cuando necesitamos:
1. Definir un problema que afecta a una organización
(análisis).
2. Plantear una solución de diseño (abstracción).
3. Modelar procesos de negocio (optimización de
flujos de trabajo).
4. Construir un producto de software (concreción de
una abstracción).
5. Certificar la coherencia, completitud y usabilidad del
producto (calidad).
6. Evaluar la arquitectura de una organización
(conocimiento).

13. Cómo
 Necesitamos combinar la notación visual UML con una metodología
para saber:
1. Qué aspectos esenciales hay que modelar (desde un esbozo a un plano
detallado).
2. Qué diagrama es el más apropiado para representar una vista del
modelo (estructura y/o función).
3. En qué proceso de proyecto (Análisis, Diseño, Implementación, Testing,
etc.), hay que realizar un determinado diagrama, y quién participará en
su elaboración (Roles de proyecto).
4. Qué escala de abstracción y qué nivel de dedicación hay que aplicar a
un diagrama en cada fase de proyecto (desde el estudio preliminar en
adelante).
5. Cómo definimos un modelo a través de distintas vistas de arquitectura:
estructura, procesos y Casos de Uso.
6. Cómo delimitamos el alcance de un proyecto en tiempo, coste,
procesos y producto resultante.

14. Conclusión
 UML es un lenguaje visual para modelar sistemas. Facilita un
vocabulario controlado con reglas y símbolos para que todos los
agentes involucrados en un proyecto eviten ambigüedades y
dispersión conceptual.
1. Mejora nuestro nivel de comunicación formal.
2. Abordamos la complejidad con una documentación minimalista.
3. Desarrollamos procesos/productos con una mayor fiabilidad y
calidad.
4. El impacto de nuestras decisiones sobre un proceso/producto es
más visible.
5. Podemos definir, organizar y compartir conocimiento.
6. Nuestro esfuerzo de especificación es más eficiente