El Lenguaje Unificado de Modelado

La mayoría de las ideas fundamentales de la ciencia son esencialmente sencillas y,

por regla general pueden ser expresadas en un lenguaje comprensible para todos

Albert Einstein
Resumen

Inicialmente se habla del Lenguaje Unificado de Modelado, presentado aspectos

como su origen, modelo conceptual y funcionalidad, para posteriormente presentar
las características que debe tener la metodología de software que haga uso de
éste estándar. Además se presentan algunas observaciones, a nivel de
recomendación con el fin de evitar errores en la construcción del modelo de casos
de uso en particular, y en general en la utilización del estándar.

Durante varios años la Ingeniería de software no contó con un estándar que le

permitiera la construcción de planos de software que pudieran ser interpretados
por cualquier ingeniero del área. Se realizaron varios intentos, uno de ellos fue “...
la publicación en 1976 por parte del CCITT, el organismo internacional para la
estandarización en el área de las telecomunicaciones, del Lenguaje de
Especificación y Descripción (Specification and Description Language, SDL) para
el comportamiento funcional de los sistemas de telecomunicación”1. Dicho
lenguaje es un estándar de modelado de objetos especializado, desarrollado
cuando el paradigma de la Orientación a Objetos no había madurado, por lo tanto
no contó con la acogida que se esperaba.

Fue sólo hasta el 14 de noviembre de 1997 cuando el Grupo Administrador de

Objetos (Object Management Group, OMG) publicó como estándar la versión 1.1
del Lenguaje Unificado de Modelado (Unified Modeling Language, UML)2. Sin
embargo, los problemas no terminan aquí. Aunque han pasado más de seis años
desde la definición del estándar, aún es frecuente encontrar publicaciones en
Internet y documentos, como revistas y libros, que presentan algunas
inconsistencias al momento de utilizarlo, razón por la cual es pertinente a través
de este artículo, dar a conocer al lector algunas Notas de interés sobre El
Lenguaje Unificado de Modelado, identificadas a partir de un profundo estudio del
estándar, y de la experiencia obtenida en la dirección de proyectos de aula en el
área de Ingeniería de software.

Para lograr el objetivo propuesto, inicialmente se hará claridad sobre la definición

de lenguaje que manejará el artículo, luego se explicará que es y que no es UML,
posteriormente se presentarán las características que debe tener cualquier

1
JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James, El Proceso Unificado de Desarrollo de
Software, Ed. Addison Wesley. 2000. Pág. XX
2
JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James, El Lenguaje Unificado de Modelado,
Addison Wesley. 1999. Pág. XXIII
metodología de construcción de software que utilice el estándar UML, haciendo
énfasis en las diferentes vistas del modelo arquitectónico; para finalmente
presentar, a nivel de recomendación, algunas observaciones con el fin de evitar
errores en la construcción del modelo de casos de uso, y en la representación de
las relaciones en los diferentes tipos de diagramas.

Debido a que el término lenguaje presenta diferentes acepciones, se hace

necesario resaltar la diferencia entre el Lenguaje Natural, como “conjunto de
sonidos articulados con que las personas manifiestan lo que piensan o sienten”3, y
Lenguaje Formal como el conjunto o colección de palabras de algún alfabeto4,
entendiendo por alfabeto el conjunto no vacío y finito de símbolos, y por palabra la
secuencia finita de símbolos yuxtapuestos pertenecientes al alfabeto5. En el
contexto que nos ocupa, se hará referencia al término lenguaje teniendo en cuenta
la segunda acepción presentada.

En el caso concreto de UML se dice que es un lenguaje estándar para escribir

planos de software, que se utiliza para visualizar, especificar, construir y
documentar los artefactos de un mismo sistema que involucra una gran cantidad
de software6. Su alfabeto está constituido por elementos y relaciones, los cuales
al combinarse cobran sentido al armar una colección de palabras formando
diferentes tipos de diagramas.

Los elementos de UML se clasifican en estructurales (Clases, interfaces.

Colaboraciones, casos de uso, clases activas, componentes y nodos), de
comportamiento (interacciones y máquinas de estado), de agrupación (paquetes) y
de anotación (notas). A su vez, hay cuatro tipos de relaciones: De Dependencia,
de asociación, de agrupación y de realización. Para construir un plano de software
que tenga sentido, lo que se hace es combinar los elementos estructurales con
sus respectivas relaciones, según sea el caso, obteniendo como resultado un uno
de los nueve diagramas que existen en UML, a saber: De clases, De objetos, de
casos de uso, de secuencia, de colaboración, de estados, de actividades, de
componentes y de despliegue.

Si se quiere construir un modelo bien formado, o sea, un modelo semánticamente

autoconsistente y en armonía con todos sus modelos relacionados7, se deben
tener en cuenta las reglas semánticas del Lenguaje para el manejo de nombres, el

3
EL MUNDO.ES. Diccionarios. Disponible:
http://diccionarios.elmundo.es/diccionarios/cgi/lee_diccionario.html. Adquirido: 5 de noviembre de
2003
4
KELLEY, Dean. Teoría de Autómatas y Lenguajes Formales. Ed. Prentice Hall. 1ª Edición. 1995
Pág. 31.
5
JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James, El Lenguaje Unificado de Modelado, Ed.
Addison Wesley. 1999. Pág. 30
6
Ibid, Pág. 11
7
Ibid. Pág. 22
alcance, la visibilidad, la integridad y la ejecución del modelo; así como también
los diferentes mecanismos comunes que presenta el estándar, representados por
medio de especificaciones, adornos, divisiones comunes y mecanismos de
extensibilidad. Todo esto constituye lo que los autores del Lenguaje Unificado de
Modelado han denominado el modelo conceptual de UML

Es de vital importancia tener en cuenta que “UML es sólo un lenguaje y por lo

tanto es tan sólo una parte de un método de desarrollo de software”8, que se
utiliza para visualizar, especificar, construir y documentar los artefactos que se
obtienen como resultado de un proceso de construcción de software, lo cual lo
convierte en una herramienta estándar para escribir planos de software, mas no
en un proceso o metodología de desarrollo de software, entendida ésta como el “...
conjunto de actividades necesarias para transformar los requisitos de un usuario
en un sistema software.”9 Aunque UML es independiente del proceso, se
recomienda ser utilizado por una metodología dirigida por casos de uso, centrada
en la arquitectura, iterativa e incremental, como lo es el Proceso Unificado de
Desarrollo de Software, propuesto por los mismos autores del estándar UML.

Con el fin de hacer claridad respecto a las características del proceso

anteriormente mencionadas, a continuación se hace una breve explicación de
cada una de ellas.

Una metodología de desarrollo de software es dirigida por casos de uso, si cada

una de las actividades o disciplinas de su proceso (análisis de requerimientos,
diseño, implementación y prueba) es dirigida en su ejecución por los casos de uso.
Esto quiere decir que el ingeniero de software especifica los requerimientos por
medio del modelo de casos de uso, el cual sirve como referente principal para la
construcción del modelo de diseño, representado básicamente por medio de los
diagramas de clase y de secuencia. Así mismo, éste último modelo junto con el de
casos de uso, son el fundamento que soporta la creación del modelo de
implementación realizado por los desarrolladores, para que finalmente los
ingenieros de prueba, puedan definir una estrategia, a partir del modelo de casos
de uso, que permita identificar si el producto obtenido cumple con las
especificaciones funcionales, requeridas por el usuario. En este orden de ideas, es
fácil concluir que los casos de uso se convierten en el hilo conductor del proceso
de desarrollo de software.

Se dice que una metodología de desarrollo de software se centra en la

arquitectura, en la medida en que pueda representar en forma clara y completa el
sistema software que se va a construir, mediante diferentes vistas, incluyendo sus
aspectos estáticos y dinámicos más representativos; teniendo en cuenta que “La

8
Ibid. Pág 11
9
JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James. El Proceso Unificado de Desarrollo de
Software. Ed. Addison Wesley. 2000. Pág. 4
arquitectura de un sistema es su estructura en términos de componentes
especificados por separado.”10 De allí la importancia de describir en forma clara y
completa los elementos del modelo que son más importantes para la construcción
del software.

Así como en la construcción de un edificio, el arquitecto tiene la responsabilidad

de integrar todos los subsistemas que conforman el proyecto (sistema eléctrico, de
calefacción, de distribución de gas, etc.), sin ser experto en cada uno de ellos, el
ingeniero de software es el encargado de definir la organización del sistemas
software, identificando los elementos estructurales y su comportamiento, con el fin
de diseñar modelos por medio de componentes, interfaces y colaboraciones.

Este objetivo se logra haciendo uso de diferentes vistas y niveles de abstracción.

En este punto es pertinente aclarar que el software nunca será un producto cien
por ciento terminado, ya que constantemente se encuentra en evolución, es por
eso que nos hemos acostumbrado a que en ciertos lapsos de tiempo aparecen
nuevas versiones de las aplicaciones que utilizamos. Esto obliga al ingeniero de
software a hacer revisiones permanentes del diseño, con el fin de mejorarlo, sin
que esto implique volver a construirlo, lo cual indicaría graves problemas
estructurales en los diseños anteriores.

Para facilitar el mantenimiento de la arquitectura del sistema software se tiene las

siguientes vistas del modelo11:

• Modelo de casos de uso: presenta los actores y casos de uso más

importantes, junto con su descripción completa. Cabe resaltar el hecho de que
cada modelo puede representarse en diferentes niveles de abstracción, según
sea la necesidad. Es así como el modelo de casos de uso puede presentarse
en los siguientes grados de formalidad12:
o Breve : Resumen conciso de un párrafo del escenario principal de éxito.
o Informal: Múltiples párrafos que comprenden varios escenarios.
o Completo: Se escriben con detalle todos los pasos y variaciones,
presentando secciones de apoyo, como precondiciones y garantías de
éxito.

• Modelo de análisis: Su objetivo es permitir identificar nuevos clasificadores y la

posibilidad de utilizar los ya existentes, definiendo en su etapa inicial las

10
COULOURIS, George. Sistemas Distribuidos. Conceptos y Diseño. 3 edición. Ed. Addison
Wesley. 2001. Pág. 28
11
JACOBSON, Ivar, BOOCH, Grady, RUMBAUG, James, El Proceso Unificado de Desarrollo de
Software. Ed. Addison Wesley. 2001. Pág. 20
12
LARMAN, Craig. UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al
proceso unificado. 2 edición. Ed. Addison Wesley. 2003. Pág. 47
 responsabilidades de los diferentes componentes del sistema. Se representa
por medio de los diagramas de colaboración.
• Modelo de diseño: Presenta los subsistemas e interfaces más importantes, así
como sus clases, con el fin de mostrar la realización de los casos de uso. Se
representa por medio de los diagramas de clase y de secuencia.
• Modelo de despliegue: Define la arquitectura física del sistema por medio de
nodos interconectados. Estos nodos son elementos de hardware sobre los
cuales pueden ejecutarse los elementos software. Se representan por medio
de los diagramas de despliegue.
• Modelo de implementación: Es una correspondencia de modelo de diseño y de
despliegue. Muestra la organización y las dependencias entre el conjunto de
componentes que conforman el sistema. Se representa por medio de los
diagramas de componentes.

En situaciones muy especiales, tales como proceso de reingeniería, o el desarrollo

de una única aplicación, se requiere de un modelo adicional, denominado modelo
del negocio, el cual incluye el modelo de objetos del dominio y la representación
dinámica de los procesos del negocio de toda la empresa, por medio de los
diagramas de actividades.

Continuando con la explicación de las características que debe cumplir la

metodología de construcción de que utilice UML, es el momento de indicar en que
consiste el hecho de que sea iterativo e incremental.

Las iteraciones hacen referencia a los pasos que se realizan durante las diferentes
actividades del desarrollo del software (análisis de requerimientos, diseño,
implementación y prueba) y los incrementos al crecimiento del producto13. Es por
eso que cada iteración se puede ver como un miniproyecto, que permita una
mayor efectividad al planificar el conjunto de tareas que se deben realizar para la
obtención de cada incremento de proyecto, permitiendo controlar los riesgos de
coste, y el ritmo del esfuerzo de desarrollo en su totalidad, ya que los
desarrolladores trabajan de manera más eficiente para obtener resultados claros a
corto plazo. Es importante tener en cuenta que el resultado de una iteración no es
un prototipo experimental o desechable, sino un subconjunto con calidad de
producción del sistema final.

Según lo expuesto anteriormente, es fácil identificar la importancia que tienen los

casos de uso en el proceso de construcción de software, por tal motivo a
continuación se presentan algunas observaciones, a nivel de recomendación con
el fin de evitar errores en la construcción del modelo de casos de uso.

13
JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James, El Proceso Unificado de Desarrollo de
Software. Ed. Addison Wesley. 2000. Pág. 25
Ante todo, como lo afirma Craig Larman en su libro UML y Patrones, los casos de
uso no son orientados a objetos, son una herramienta para el análisis de
requerimientos, introducida en 1.986 por Ivar Jacobson, uno de los creadores del
estándar UML y del Proceso Unificado de Desarrollo de Software, que puede ser
utilizada en proyectos no orientados a objetos.

Con el fin de evitar ambigüedad en la implementación de los casos de uso, se

hace necesario tener siempre presente que existen diferentes grados de
formalidad para escribirlos (breve, informal y completo, descritos anteriormente),
dependiendo la necesidad y el nivel de abstracción que se requiera, teniendo en
cuenta que para la construcción de los diagramas de secuencia se hace necesaria
una descripción completa y detallada, que permita identificar en forma clara y
precisa los diferentes escenarios que se pueden presentar en la realización del
caso de uso. De los diferentes formatos que he podido observar me parece que el
más completo es el que presenta Craig Larman en la segunda edición de su libro
UML y patrones, ya que además del escenario principal y los flujos alternativos,
permite documentar aspectos adicionales, tales como: Personal involucrado e
intereses, precondiciones, garantías de éxito (poscondiciones), requisitos
especiales, listas de tecnología y variaciones de datos, frecuencia y temas
abiertos; que permiten comprender los requerimientos funcionales de una forma
más detallada y precisa, facilitando la construcción de los modelos de análisis y
diseño, lo cual no se logra a partir de una descripción ambigua de los escenarios
de éxito y alternativos.

Además es pertinente aclarar que los únicos estereotipos que se aplican a las
relaciones de dependencia entre casos de uso son14:

1. Extend: Especifica que un caso de uso destino extiende el comportamiento

del origen.
2. Include: especifica que el caso de uso origen incorpora explícitamente el
comportamiento de otro caso de uso en la posición especificada por el
origen.

La razón que lleva a hacer ésta aclaración, radica en el hecho de que, con mucha
frecuencia se encuentran documentos que representa la relación de dependencia
<<use>> entre casos de uso, lo cual representa un error, ya que dicho estereotipo
se aplica exclusivamente a las dependencias entre clases y objetos en los
diagramas de clase, según lo afirman los autores del estándar15. Posiblemente lo
más grave de éste error, consiste en que se presenta en documentos tan
importantes, como el libro Ingeniería de Software un enfoque práctico de Roger

14
JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James, El Lenguaje Unificado de Modelado.
Ed. Addison Wesley. 1999. Pág. 122
15
Ibid.
Pressman, en su capítulo análisis orientado a objetos16. De igual forma, algunas
herramientas CASE para UML, como SoftModeler, presentan inconsistencias de
esta naturaleza, razón por la cual considero pertinente unirme a las peticiones
hechas por Craig Larman a los vendedores de herramientas CASE para UML17:

1. Implementación correcta de la notación actual de UML en la herramienta.

2. Que el propio equipo de desarrollo de la herramienta CASE, haya dibujado,

leído y revisado seriamente diagramas UML (incluyendo el proceso de
ingeniería inversa de los diagramas), en el proceso de construcción de la
propia herramienta para UML

3. Utilizar la versión N de la herramienta para crear la versión N +1

4. Proporcionar el soporte para los procesos de ingeniería directa e inversa de

los diagramas de secuencia; la mayoría de las herramientas sólo lo
soportan para el diagrama de clases.

También es común encontrar que las relaciones de dependencia entre casos de

uso (<<include>> y <<extend>>) se representan con líneas continuas, haciendo
caso omiso a lo establecido por el estándar: “... una dependencia es una relación
semántica entre dos elementos, en la cual un cambio a un elemento (elemento
independiente) puede afectar a la semántica del otro elemento (elemento
dependiente). Gráficamente una dependencia se representa con una línea
discontinua, posiblemente dirigida, que incluye a veces una etiqueta..”18

Este error de notación es similar a los errores de ortografía en el lenguaje natural,

dentro de los cuales, uno de los más comunes es el de manejo de tildes, a las que
no se les da la importancia que realmente tienen, ignorando que cuando no se le
marca la tilde a una palabra, su significado cambia completamente, (no es lo
mismo práctica que practica). De igual manera en UML el hecho de utilizar una
línea continua o discontinua, cambia la semántica de la representación simbólica,
razón por la cual se debe tener mucho cuidado al aplicar el estándar, en el
momento de construir los respectivos planos de software.

Como última observación, no es recomendable afirmar que un diagrama sea

exclusivo de una de las actividades del proceso de construcción de software, ya
que, como sucede con los diagramas de clase, pueden ser utilizados para
representar el modelo del dominio, al igual que el modelo de diseño, lo mismo
16
PRESSMAN, Roger. Ingeniería de software Un enfoque práctico. 5 Edición. Ed. Mc Graw Hill.
2002. Pág. 368
17
LARMAN, Craig. UML y Patrones. Una introducción al análisis y diseño orientado a objetos y al
proceso unificado. 2 edición. Ed. Addison Wesley. 2003. Pág. 535
18
JACOBSON, Ivar, BOOCH, Grady, RUMBAUGH, James, El Lenguaje Unificado de Modelado.
Ed. Addison Wesley. 1999. Pág. 20
sucede con los diagramas de casos de uso, los cuales se pueden utilizar para la
representación del modelo del negocio, así como también se usan en la actividad
orientada a identificar los requerimientos de la aplicación.

En conclusión, se puede afirmar que la importancia de UML radica en que se ha

convertido el la herramienta estándar que permite la construcción de planos de
software, y que es responsabilidad del ingeniero de software el construir modelos
bien formados, o sea, semánticamente auto consistentes y en armonía con todos
sus modelos relacionados, teniendo en cuenta las reglas semánticas del Lenguaje
para el manejo de nombres, el alcance, la visibilidad, la integridad y la ejecución
del modelo; así como también los diferentes mecanismos comunes que presenta
el estándar, representados por medio de especificaciones, adornos, divisiones
comunes y mecanismos de extensibilidad.