LECTURA
Lectura 1. Historia de UML, visión general del estándar
El desarrollo moderno de software es un proceso que comprende un gran número de
aspectos, los cuales antes no eran tenidos en consideración de una manera tan extensa. En
el pasado, la complejidad de los desarrollos de software era limitada debido a las
características del mercado, a las necesidades de los clientes y usuarios y al nivel mismo de
desarrollo de la disciplina. En la actualidad, y teniendo en cuenta el enorme número de
aplicaciones y mercados en los que el software resulta necesario, la creciente complejidad
de las necesidades que se deben cubrir con una aplicación y la sofisticación de los usuarios.
El proceso de desarrollo de software presenta factores de complejidad: grandes y crecientes.
Uno de los aspectos en los que más se ha evolucionado es el referente a los procesos de
diseño de las aplicaciones. Tener diseños arquitectónicos y detallado robusto facilita los
demás procesos involucrados en la codificación, prueba y puesta en marcha de una solución
de software, garantizando otros factores tales como la escalabilidad, mantenibilidad y
adaptabilidad en el tiempo de la aplicación desarrollada. Y para contar con un diseño
adecuado, uno de los factores relevantes es contar con modelos y un proceso de modelado
adecuados. Es aquí donde entra en juego el UML (Unified Modeling Language, Lenguaje
Unificado de Modelado).
Para comprender de manera real y completa un UML es necesario comprender su origen, las
circunstancias en que se creó y las condiciones históricas que describieron ese momento.
Para ello, es necesario abordar el proceso a mediados de la década de 1980.
En la década de los ochenta y bien entrada la década de los noventa, existió un número
muy grande de metodologías y aproximaciones al diseño y desarrollo de software. Estas
metodologías surgieron, de manera fundamental, debido a la aparición y gran popularidad
de los lenguajes de programación orientados por objetos, tales como: ADA, Smalltalk, C++, y
otros. A pesar de que existían metodologías de desarrollo desde antes, la aparición del
paradigma orientado por objetos y la ya mencionada popularización de los lenguajes
orientados por objetos (Principalmente C++), hicieron necesario encontrar nuevas maneras de
aproximarse a la solución de los problemas de diseño inherentes a la nueva visión. La mayor
parte de las metodologías de diseño, previamente existentes, estaban orientadas a los datos
o a la programación funcional. Estas aproximaciones no resultaron adecuadas cuando se
hizo el cambio al paradigma orientado por objetos. Era necesario encontrar aproximaciones
que estuvieran a la par con el crecimiento del paradigma.

Entre las múltiples metodologías existentes, algunas de las más extendidas y conocidas fueron
las propuestas por Shlaer-Mellor, Coad-Yourdan, la metodología Booch de Grady Booch,
OMT (Object Modeling Technique) propuesta por james Rumbaugh, y OOSE (Object-
Oriented Software Engineering) de Ivar Jacobson. Es posible nombrar muchas más, pero basta

En alianza con

 
Colombia
 

decir que las mencionadas sólo son una pequeña fracción de las opciones disponibles en
ese momento.
La gran desventaja que presentaba la abundancia de metodologías existente era que
ninguna de las opciones disponibles cubría todas las áreas del proceso de diseño. Algunas
presentaban ventajas en ciertos aspectos, tales como: el levantamiento de requerimientos o
la documentación de la estructura estática de la solución, e incluso la documentación del
comportamiento dinámico en el tiempo del software, pero ninguna metodología ofrecía
herramientas que abarcaran todas las áreas necesarias. Por otro lado, las notaciones
utilizadas por las metodologías disponibles eran diferentes, a veces no de una manera
radical, pero sí lo suficiente como para dificultar la comunicación entre desarrolladores,
utilizando metodologías diferentes. Este tipo de divergencias y carencias de las metodologías
existentes impulsó un fenómeno aun mayor, en el que los desarrolladores generaban “híbridos”
entre diferentes aproximaciones con el fin de aprovechar las fortalezas de cada una. Al mismo
tiempo, reducían el impacto de sus debilidades. Sin embargo, este proceso solamente
contribuyó a generar más división por cuanto las alternativas se multiplicaron, en términos de
cómo aproximarse a un proceso de diseño de software. Y el impacto de estas alternativas no
solamente se sintió en el terreno de los desarrolladores. Los consultores de procesos de
software, cuya labor fundamental consistía en aconsejar potenciales clientes respecto a qué
aproximación tomar para la contratación y desarrollo de una solución de software, tuvieron
que familiarizarse con un ingente número de posibilidades y alternativas con el fin de hacer un
trabajo adecuado.
La existencia de tantos caminos posibles, sumada al apasionamiento de los desarrolladores
por la alternativa escogida por ellos hizo que surgiera lo que se conoció como la “Guerra de
los métodos”, una constante lucha entre los desarrolladores que promovían las ventajas de
sus metodologías predilectas, con el fin de que los demás las adoptaran en sus procesos de
software.
Finalmente, en 1995 tres de los más importantes creadores de enfoques para el diseño de
software (Grady Booch con la metodología Booch, James Rumbaugh y su OMT, Object
Modeling Technique, e Ivar Jacobson con OOSE, Object-Oriented Software Engineering)
unieron fuerzas. Rumbaugh y Booch habían sido contratados por Rational Corporation (Una
compañía especializada en la construcción de herramientas de diseño. Hoy es parte de IBM),
de tal manera que la llegada de Jacobson (Luego de que su compañía Objectory AB fuera
comprada por Rational) reunió bajo un solo techo a los creadores de las tres metodologías
más influyentes de la época. La misión del trabajo de los Three Amigos, como se los llamó, fue
crear a solicitud de Rational un lenguaje único que permitiera dejar atrás las divergencias
generadas por la multitud de opciones existentes del momento. Los requisitos principales del
trabajo solicitado eran que la alternativa final debía ser no propietaria y tener en cuenta las
necesidades reales de los diseñadores de software orientado por objetos. Con el fin de
asegurar esto último, en 1996 se utilizó el espacio ofrecido por OOPSLA (Object-Oriented
Programming, Systems, Languages & Applications, una conferencia anual de la ACM
alrededor de los temas relacionados con el software orientado por objetos) para consultar
con representantes de la industria acerca de opciones y alternativas de mejores prácticas
con el fin de integrarlas a la propuesta de Rational.
A partir del primer bosquejo de la especificación de lo que se convertiría en UML, en 1996 se
creó un consorcio internacional llamado UML Partners. Conformado por grandes compañías
de la industria, tales como Digital Equipment Corporation, Oracle, Microsoft, IBM, Hewlett-
Packard y Texas Instruments entre otras. La misión principal del grupo era completar la

En alianza con

 
Colombia
 

especificación del UML con el fin de presentarla de manera oficial a OMG (Object
Management Group)1. La primera presentación del UML a OMG fue hecha en enero de
1997. Una segunda versión, UML 1.1, fue presentada en agosto de 1997 y aceptada por
OMG en noviembre del mismo año. El propósito fundamental de esta nueva versión fue
aclarar la dimensión semántica de la primera propuesta, a la vez que se integraban las
sugerencias de los miembros del equipo de trabajo. A partir de este punto, y gracias a la
retroalimentación obtenida por parte del creciente número de usuarios del estándar, el UML
maduró de manera sustancial y se propusieron y aceptaron nuevas versiones hasta alcanzar
la versión 2.0, que fue adoptada por la OMG en el año 2005. A pesar de que UML 2.1 no
fue liberado como una especificación formal, se liberaron las versiones 2.1.1 y 2.1.2 en agosto
y noviembre de 2007 respectivamente y UML 2.2 fue liberado en febrero de 2009. En mayo
de 2010, el UML 2.3 fue presentado de manera oficial.

Historia de los métodos y notaciones del desarrollo orientado a objetos – Imagen original por
Axel Scheithauer. Modificada por Marcel Douwe Dekker, licenciada bajo el modo Creative
Commons Attribution-Share Alike 3.0 Unported

                                                        
1
 OMG es un consorcio fundado en 1989 cuyo objetivo original giraba en torno a la especificación de 
estándares para sistemas distribuidos orientados por objetos. Posteriormente, este enfoque cambió y  
actualmente, OMG está enfocado en estándares de modelado. Resulta importante anotar que OMG 
provee especificaciones pero no implementaciones.  

En alianza con

 
Colombia
 

Estructura y clasificación de los diagramas UML

En la actualidad, la versión 2.2. del UML cuenta con 14 diagramas, que se clasifican en dos
grandes grupos: los diagramas de estructura y los diagramas de comportamiento. Cada uno
de estos se encarga de representar características particulares del sistema que se modela, a
través de los diagramas que lo componen. A continuación se presenta una visión estructural
de la clasificación así como, una breve descripción de cada uno de los diagramas
presentados.

UML 

Diagramas de  Diagramas de 
estructura  comportamiento 

Diagrama de 
Diagrama de  Diagrama de  Diagrama de  máquina de  Diagramas de 
clases  casos de uso  acGvidad  interacción 
estados 

Diagrama de  Diagrama de 
componentes  secuencia 

Diagrama de  Diagrama de 
objetos  comunicación 

Diagrama de 
estructura  Diagrama de 
Gempos 
compuesta 

Diagrama general 
Diagrama de perfil  de interacción 

Diagrama de 
despliegue 

Diagrama de 
paquetes 

Diagramas de estructura
Los diagramas de estructura son:
• Diagrama de clases. El diagrama de clases es utilizado para describir la estructura
estática del sistema modelado, a través de la representación de las clases que lo

En alianza con

 
Colombia
 

componen, las relaciones que se presentan entre ellas así como, sus atributos y
comportamientos.
• Diagrama de componentes. El diagrama de componentes ofrece una visión más
general del sistema, representando los componentes en los que se divide así como,
las relaciones derivadas de dicha división.
• Diagrama de objetos. Este diagrama despliega una vista “en un momento del tiempo”
de cómo es la estructura estática del sistema.
• Diagrama de estructura compuesta. El diagrama de estructura compuesta describe
cuál es la estructura interna de una clase, de tal manera que es posible discernir las
relaciones que dicha clase puede tener con base en las características de dicha
estructura.
• Diagrama de perfil. Este diagrama representa el sistema desde una perspectiva
mucho más elevada, recurriendo a la utilización de elementos del metamodelo y
estableciendo relaciones entre dichos elementos y los estereotipos utilizados.
• Diagrama de despliegue. Es un diagrama utilizado para representar los espacios,
físicos y virtuales en los que se desplegará el software, para su funcionamiento en el
ambiente de producción.
• Diagrama de paquetes. El diagrama de paquetes muestra las subdivisiones lógicas
del sistema así como, las relaciones que existen entre dichas subdivisiones.

Diagramas de comportamiento
Los diagramas de comportamiento encontrados en la especificación UML son:
• Diagrama de casos de uso. El diagrama de casos de uso es utilizado para
representar las funcionalidades que ofrece el sistema, desde la perspectiva del
usuario, utilizando para ello el concepto de actores, casos de uso y las relaciones
entre estos elementos.
• Diagrama de actividad. El diagrama de actividad muestra desde una perspectiva
elevada el comportamiento y flujo de control dentro del sistema, mostrando cómo
fluye la información entre los componentes del mismo.
• Diagrama de máquina de estados. Se representa utilizando este diagrama los
estados que puede asumir un componente del mismo, así como las transiciones que
son posibles entre dichos estados.
• Diagramas de interacción. Los diagramas de interacción son un tipo particular de
diagramas de comportamiento. Su propósito fundamental es ofrecer mecanismos para
modelar el flujo de datos. Así como, las alternativas y herramientas de control
existentes entre los elementos que constituyen el sistema que se está modelando.

Los diagramas que están dentro de esta categoría son:

- Diagrama de secuencia. El diagrama de secuencia tiene como objetivo la
representación de cuál es el flujo de comunicación entre los elementos del
sistema, en términos de los mensajes que viajan entre ellos, como el orden en el
tiempo y la duración de dichos intercambios.

En alianza con

 
Colombia
 

- Diagrama de comunicación. Este diagrama muestra la comunicación entre los

objetos en términos de la secuencia de mensajes. En este tipo de diagramas se
representa la estructura dinámica del sistema con base en su estructura estática.
- Diagrama de tiempos. El diagrama de tiempos tiene como principal
responsabilidad la representación de las restricciones, que en términos de
tiempos, tiene las interacciones presentes en el sistema modelado.
- Diagrama general de interacción. Con las representaciones detalladas y las
interacciones dentro el sistema, cubiertas por los demás diagramas, el diagrama
general de interacción muestra desde una perspectiva elevada el orden y las
relaciones de dichas interacciones. En un diagrama general de interacción, los
nodos representan diagramas particulares de interacción dentro del modelo.

En alianza con

 
Colombia