Un pequeño recorrido por UML

María Elizabeth García Talavera y Yazmin Alberto Patiño

Ingeniería en sistemas computacionales, Instituto

Tecnológico de Lázaro Cárdenas

AEF1031: Fundamentos de bases de datos

Esteban Valdez Ramírez

11 de marzo de 2023
Capítulo 2
Un breve recorrido por UML

Antes de presentar los conceptos más importantes de UML en los

capítulos siguientes, explicaremos los antecedentes de este lenguaje de
modelado. Veremos cómo surgió UML y qué significa la "U" de
"Unificado". A continuación, responderemos a la pregunta de cómo se ha
desarrollado el propio UML, es decir, de dónde se extrae el lenguaje. es
decir, ¿de dónde proceden las reglas que dictan el aspecto que debe tener
un modelo válido en UML. Además, esbozamos para qué se utiliza UML.
Por último, ofrecemos un breve resumen de los 14 diagramas UML de la
versión actual 2.4.1 de la especificación estándar UML. Estos diagramas
pueden utilizarse para modelar tanto la estructura como el
comportamiento.
2.1 Historia de UML
Orígenes de la
Introducción de los conceptos orientados a objetos en las tecnologías de la orientación a
información tiene su origen en los trabajos de principios de la década de objetos
1960 [12]. Las primeras ideas fueron orientación implementadas en
sistemas como Sketchpad, que ofrecían un nuevo enfoque de
comunicación gráfica entre el hombre y el ordenador [28, 51]. SIMULA

Hoy en día, el lenguaje de programación SIMULA [24] se considera el

primer lenguaje de programación orientado a objetos. SIMULA se utilizó
principalmente para desarrollar software de simulación y no se
ampliamente. Ya incluía conceptos como clases, objetos, herencia y enlace
dinámico [2].
La introducción de estos conceptos supuso el inicio de una revolución en Lenguajes de
el desarrollo de software. En las décadas siguientes, siguieron Orientación programación
a objetos una multitud de lenguajes de programación basados en los orientados a
lenguajes de programación orientados a objetos [21]. Entre ellos se objetos
encontraban lenguajes como C++ [50], Eiffel [31] y Smalltalk [28]. Ya
contenían muchas de los conceptos de los lenguajes de programación
modernos y aún se utilizan hoy en día.

© Springer International Publishing Switzerland 2015 11 11

M. Seidl et al, UML @ ClassroombUndergraduate Topics

in Computer Science, DOI 10.1007/978-3-319-12742-2_2

2.1 la historia de UML
La aparición e introducción de la orientación a objetos como método de
ingeniería de software está estrechamente relacionada con la aparición de
los lenguajes de programación orientados a objetos. En la actualidad, la
orientación a objetos es y bien establecido para abordar la complejidad de
los sistemas de software. No sólo se aplica a los lenguajes de
programación, sino también a otros ámbitos, como las bases de datos o la
ingeniería de software. también en otros ámbitos, como las bases de datos
o la descripción de interfaces de usuario.
Como ya vimos en la sección 1.2, donde introdujimos la noción de modelo,
los sistemas de software son abstracciones destinadas a resolver problemas
del mundo real con el objetivo de mejorar la calidad de vida de las
personas. Problemas del mundo real con la ayuda de máquinas. Los
lenguajes de programación procedimentales no son necesariamente para
describir el mundo real: las diferencias de concepto entre una descripción
ural de un problema y la implementación práctica como un programa son
enormes. La programación orientada a objetos fue un intento de desarrollar
mejores programas que, sobre todo, fueran más fáciles de mantener [12].
Con el paso de los años, la orientación a objetos se ha convertido en el
paradigma de desarrollo de software más importante. Esto se refleja en
lenguajes de programación orientados a objetos como Java [4] o C# [32] y
lenguajes de modelado orientados a objetos como UM. Sin embargo, el
camino hacia el actual desarrollo de software ha sido largo y tortuoso.
En la década de 1980, el lenguaje de programación Ada, financiado por el Ada
Departamento de Defensa de Estados Unidos, gozaba de gran popularidad
gracias a sus potentes conceptos y eficientes compiladores [25]. Incluso
entonces, Ada soportaba tipos de datos abstractos en forma de paquetes y
concurrencia en forma de tareas. Los paquetes permitían separar la
especificación de la y el uso de objetos y clases de objetos. Ada se
distinguía así fundamentalmente de otros lenguajes populares de la época,
como Fortran y Cobol. Como consecuencia, se produjo una gran demanda
de métodos de análisis y diseño orientados a objetos para facilitar el
desarrollo de programas Ada. Debido a la amplia distribución de Ada y la
presión del Departamento de Defensa de Estados Unidos, estos métodos
de modelado se basaron específicamente en las características método
Booch de Ada. Grady Booch fue uno de los primeros investigadores en
Método Booch
publicar trabajos sobre el diseño orientado a objetos de programas Ada [5].
Con el tiempo, surgieron otros métodos de modelado orientado a objetos
(véase [12] para una visión general). En general, los métodos de modelado
tenían una fuerte referencia a los lenguajes de programación, como el
enfoque OMT de Booch, o una fuerte referencia al modelado de datos,
como el método técnica de modelado de proyecto (OMT) desarrollado por OMT enfoque de
Rumba
James Rumbaugh et al. [42]. OMT apoyaba el desarrollo de objetos
complejos en el sentido de una extensión orientada a objetos del modelo
entidad-relación [14] que se había introducido para describir bases de
datos.
Independientemente, Ivar Jacobson et al. introdujeron el modelo Objeto
Ingeniería de software orientada a objetos (OOSE) [27]. Este enfoque fue OOSE
acercamiento
13 por
desarrollado originalmente para describir sistemas de telecomunicaciones. 2.1 Laet.al
Jacobson historia de UML
En los años 80 y principios de los 90, el mundo del modelado se vio Guerra de
inundado de multitud de lenguajes de modelado diferentes. Se requirió un métodos
esfuerzo considerable para hacer frente a los problemas de compatibilidad
resultantes. Los modelos de los distintos socios del proyecto a menudo no
eran compatibles y no siempre era posible reutilizar los modelos en
proyectos diferentes. El resultado fue discusiones agotadoras sobre las
distintas notaciones, que desviaban la atención de los problemas reales de
modelado. Como cada vez aparecían nuevos lenguajes de modelado, no
estaba claro cuáles merecían la pena invertir y cuáles eran sólo una moda
pasajera. Si un lenguaje no se aceptaba, todas las inversiones que se habían
hecho para establecerlo en un proyecto o una empresa solían desaparecer.
En retrospectiva, esta de numerosos enfoques, a menudo con la diferencia
de ser sólo los detalles, se conoce como la guerra de los métodos
Para poner fin a esta situación insatisfactoria, en 1996 el grupo de Grupo de
administración de objetos (OMG) [33], el más importante grupo de administración
normalización para el desarrollo de software orientado a objetos, pidió la de objetos
especificación de un estándar de modelado uniforme. (OMG)
El año anterior, 1995, Grady Booch, Ivar Jacobson y James Rumbaugh
habían combinado sus ideas y enfoques en la conferencia OOPSLA
(OOPSLA son las siglas de Object-Oriented Programming, Systems,
Languages, and Applications). Desde entonces, Booch, Jacobson y Tres amigos
Rumbaugh son conocidos como los "tres amigos". Ellos los crearon los
siguientes objetivos [1]:
• Uso de conceptos orientados a objetos para representar sistemas
completos en lugar de y no sólo una parte del software
• Establecimiento de una relación explícita entre los conceptos de
modelado y el código ejecutable del programa
• Consideración de los factores de escala inherentes a los sistemas
complejos y críticos.
• Creación de un lenguaje de modelado que pueda ser procesado
por máquinas pero que también pueda ser leído por seres
humanos

El resultado de sus esfuerzos fue el Lenguaje Unificado de Modelado Lenguaje

(UML) que se presentó en su versión 1.0 en 1997 en respuesta al OMG. Unificado de
Varios antiguos competidores participaron en la creación de la versión 1.1 Modelado
que apareció posteriormente en 1998. Uno de los principales objetivos era (UML)
una especificación coherente del núcleo del lenguaje UML que está
documentado en el metamodelo (véase el capítulo 9). El metamodelo
define qué elementos del modelo proporciona el lenguaje UML y cómo Metamodelo
utilizarlos correctamente. Para formular las restricciones que los elementos
del modelo deben cumplir, el lenguaje de restricciones de objetos (OCL)
[36], basado en lógica de predicados. En versiones posteriores, junto con lenguaje de
el Lenguaje (OCL) revisión de ciertos conceptos del lenguaje, se restricciones de
introdujeron mecanismos para el intercambio de modelos en forma del objetos (OCL)
formato de intercambio de metadatos XML

14
 (XMI) [38] fueron agregados. Además de estos pequeños cambios,
en 2000, el OMG inició un proceso de modernización de UML. Este
XML Formato de
intercambio de Metadatos
proceso Finalmente, en 2005 se adoptó el estándar de lenguaje UML
(XMI) 2.0. Con la excepción de pequeños cambios que, a través de versiones
provisionales, dieron lugar a la actual versión 2.4.1, ésta es la
descripción del lenguaje UML que conoceremos y utilizaremos en
este libro.
En la actualidad, UML es uno de los lenguajes de modelado gráfico
orientado a objetos más extendidos. A pesar de las numerosas
revisiones, sus raíces (método Booch OMT, OOSE) siguen siendo
claramente reconocibles. UML es adecuado para modelar tanto
relaciones de objetos complejas como procesos con moneda. UML
es un lenguaje de modelado de propósito general, lo que significa que
su uso no está restringido a un área de aplicación específica.
Proporciona conceptos de lenguaje y conceptos de modelado, así
como una notación gráfica intuitiva para modelar diversas áreas de
aplicación, lo que permite especificar, diseñar, visualizar y
documentar un sistema de software [43]. El resultado de modelado
con UML es un modelo gráfico que ofrece diferentes vistas de un
sistema en forma de varios diagramas.

2.2 Uso
UML no está vinculado a una herramienta de desarrollo específica, a
un lenguaje de programación o a una plataforma específica en la que
deba utilizarse el sistema que se va a desarrollar. que debe utilizarse.
UML tampoco ofrece un proceso de software. De hecho, UML separa
el lenguaje y el método de modelado. Este último puede definirse en
función del proyecto o de la empresa. Sin embargo, los conceptos de
lenguaje de UML favorecen un proceso iterativo e incremental [43].
UML puede utilizarse de forma coherente en todo el proceso de
desarrollo de software. En todas las fases del desarrollo se pueden
utilizar los mismos conceptos de lenguaje en la misma notación. Así,
Uso en el proceso de un modelo puede refinarse por etapas. No es necesario traducir un
desarrollo del software modelo a otro lenguaje de modelado. Esto permite un proceso de
desarrollo de software iterativo e incremental. UML es adecuado para
diversas áreas de aplicación con diferente complejidad, volumen de
Conceptos genéricos del datos, tiempo real, etc.
lenguaje
Los elementos del modelo UML y su uso correcto se especifican en
el metamodelo UML metamodelo [35]. Los conceptos del lenguaje
se definen de forma tan genérica que se consigue una aplicabilidad
Punto de variación amplia y flexible. Para evitar restringir el uso de UML, el estándar es
semántica (intencionadamente) vago en varios puntos, permitiendo diferentes
interpretaciones en forma de puntos de variación semántica. Sin
embargo, esto es un arma de doble filo; también conduce a diferentes
implementaciones del lenguaje estándar por parte de las herramientas
de modelado, lo que, a su vez, dificulta el intercambio de modelos.
 15
2.3 Diagramas

2.3 Diagramas especificar una

implementación concreta.
En UML, un modelo se representa gráficamente en forma También hay diagramas
de diagramas. Un diagrama proporciona una visión de la que representan procesos
parte de la realidad descrita por el modelo. Hay diagramas admitidos y.
que expresan qué usuarios utilizan qué funcionalidad y
diagramas que muestran la estructura del sistema, pero sin
prohibidos. En la versión actual 2.4.1, UML ofrece 14
diagramas que describen la estructura o el comportamiento
de un sistema.

Diagrama

Diagrama de comportamiento
Figura 2.1 Diagrama
Diagrama de estructura
UML

Diagrama Diagrama Diagrama Diagrama de Use el Diagrama

de clase de paquete de objetos maquina de de caso

Diagrama de Diagrama Diagrama de Diagrama de

componente de perfil actividad interacción

Diagrama de estructura
de composición Diagrama de Diagrama general
secuencia de interacción
Diagrama de
implementació Diagrama de Diagrama de
comunicación tiempo

muestra una taxonomía de los 14 diagramas UML [35], que ofrece una Opcionalme
categorización muy aproximada. Una categorización muy aproximada. Como nte, se
muestra la figura, diferenciamos pueden
Notación para marco
especificar
entre diagramas de estructura y diagramas de comportamiento Los diagramas
parámetros a
de diagrama
de comportamiento incluyen los diagramas de interacción, que a su vez constan
continuación
de cuatro diagramas (véase el capítulo 6). Un diagrama suele estar delimitado
de del
por un rectángulo con un pentágono en el centro. Esquina superior izquierda.
nombre que
Este pentágono contiene el tipo de diagrama y el marco del diagrama.
pueden
utilizarse en
 16 2 Un breve recorrido por UML

Figura 2.2
Ejemplos de
diagrama
UML Marcos

contiene dos ejemplos de marcos de diagramas. En concreto, muestra un diagrama de clases

(cd) con el nombre Universidad y un diagrama de secuencia (sd) llamado Inscripción con los
parámetros curso y fecha.
Un concepto que puede aparecer en todos los diagramas es la nota. Una nota puede contener
cualquier forma de expresión que especifique el diagrama y sus elementos con mayor
precisión, por ejemplo, en lenguaje natural o en el lenguaje de restricciones de objetos (OCL).
Las notas pueden adjuntarse a todos los demás elementos del modelo. La figura 2.3 muestra
un ejemplo del uso de una nota que especifica en lenguaje natural que no se permite que las
personas se autocalifiquen. La clase Persona y la asociación grados representan conceptos
del diagrama de clases que se introducirán en el capítulo 4.
 2.3 Diagramas 17

Figura 2.3
Ejemplo de
una nota

2.3.1 Diagramas de estructura

UML ofrece siete tipos de diagramas para modelar la estructura de un sistema
desde diferentes perspectivas. El comportamiento dinámico de los elementos
en cuestión (es decir, sus cambios a lo largo del tiempo) no se tiene en cuenta
en estos diagramas.

El diagrama de clases
Al igual que los conceptos del diagrama de objetos (véase el párrafo
siguiente), los conceptos del diagrama de clases tienen su origen en el
modelado conceptual de datos y el desarrollo de software orientado a
objetos. Estos conceptos se utilizan para especificar las estructuras de datos y
objetos de un sistema. El diagrama de clases diagrama de clases se basa
principalmente en los conceptos de clase, generalización y asociación. Por
ejemplo, en un diagrama de clases, se puede modelar que las clases Curso,
Alumno y Profesor se dan en un sistema. Profesores imparten cursos y los
estudiantes asisten a ellos. Los estudiantes y los profesores tienen propiedades
comunes ya que ambos son miembros de la clase Persona. Esto se expresa
mediante una relación de generalización.

El diagrama de objetos
Basado en las definiciones del diagrama de clases relacionado, un diagrama
de objetos muestra una instantánea concreta del estado del sistema en un
momento de ejecución específico. Por ejemplo, un diagrama de objetos podría
mostrar que un profesor Henry Foster (henryFoster) imparte los cursos
Modelado orientado a objetos (oom) y Programación orientada a objetos
(oop).
18 2 Un breve recorrido por UML

El diagrama de paquetes
El diagrama de paquetes agrupa diagramas o elementos del modelo según
propiedades comunes, como la cohesión funcional. Por ejemplo, en un
sistema de universitario, se pueden introducir paquetes que contengan
información sobre la enseñanza, la investigación y los aspectos
administrativos. Los paquetes suelen integrarse en otros diagramas en lugar
de mostrarse en diagramas separados. en diagramas separados.

El diagrama de componentes

UML rinde homenaje al desarrollo de software orientado a componentes

ofreciendo diagramas de componentes. Un componente es una unidad
ejecutable independiente y ejecutable que proporciona servicios a otros
servicios de otros componentes. UML no prescribe ninguna separación
estricta entre conceptos orientados a objetos y orientados a componentes. De
hecho, estos conceptos pueden combinarse de la forma que se desee. Al
especificar un componente, puede modelar dos vistas explícitamente: la vista
externa (vista de caja negra), que representa la especificación del componente,
y la vista interna (vista de caja blanca), que define la implementación del
componente.

El diagrama de la estructura de composición

El diagrama de estructura de composición permite descomponer

jerárquicamente las partes del sistema. Por lo tanto, puede utilizar un diagrama
de estructura de composición para describir la estructura interna de las clases
o componentes en detalle. Esto permite alcanzar un mayor nivel de detalle
que, por ejemplo, en un diagrama de clases, ya que el modelado es específico
del contexto. Puede especificar detalles de la estructura interna que sean
válidos precisamente para el contexto considerado.

El diagrama de implantación

La topología de hardware utilizada y el sistema de ejecución asignado pueden

representarse mediante el diagrama de despliegue. El hardware comprende
unidades de procesamiento en forma de nodos, así como las relaciones de
comunicación entre los nodos. Un sistema en tiempo de ejecución contiene
artefactos que se despliegan en los nodos.
2.3 Diagramas 19

El diagrama de perfil

Mediante los perfiles, puede ampliar UML para introducir conceptos

específicos del dominio. El núcleo real de la definición del lenguaje UML, el
metamodelo, permanece inalterado. De este modo, puede reutilizar las
herramientas de modelado sin tener que realizar ajustes. Por ejemplo, puede
utilizar perfiles para introducir el concepto de Java Enterprise Beans.

2.3.2 Diagramas de comportamiento

Con los diagramas de comportamiento, UML ofrece la infraestructura que

permite definir el comportamiento en detalle.
El comportamiento se refiere a las consecuencias directas de una acción de al
menos un objeto. Afecta a cómo cambian los estados de los objetos a lo largo
del tiempo. El comportamiento puede especificarse a través de las acciones de
un único objeto o ser el resultado de interacciones entre varios objetos.

El diagrama de casos de uso

UML ofrece el diagrama de casos de uso para poder definir los requisitos que
debe cumplir un sistema. Este diagrama describe qué usuarios utilizan qué
funcionalidades del sistema, pero no aborda detalles específicos de la
implementación. Las unidades de funcionalidad que el sistema proporciona a
sus usuarios se denominan casos de uso. En un sistema de administración
universitaria, por ejemplo, la funcionalidad Registro sería un caso de uso
utilizado por los estudiantes.

El diagrama de la máquina de estados

Dentro de su ciclo de vida, los objetos pasan por diferentes estados. Por
ejemplo, una persona se encuentra en el estado desconectado cuando visita
por primera vez un sitio web. El estado cambia a conectado después de que la
persona haya introducido correctamente el nombre de usuario y la contraseña
(inicio de sesión). En cuanto la persona se desconecta (cierre de sesión),
vuelve al estado de desconexión. Este comportamiento puede representarse en
UML mediante el diagrama de máquina de estados. Este diagrama describe el
comportamiento admisible de un objeto en forma de posibles estados y
transiciones de estado desencadenadas por diversos eventos.
20 2 Un breve recorrido por UML

El diagrama de actividad

Con los diagramas de actividades se pueden modelar procesos de cualquier

tipo: tanto procesos de negocio como procesos de software. Por ejemplo, un
diagrama de actividades puede mostrar qué acciones son necesarias para que
un alumno participe en una clase y en una tarea. Los diagramas de actividad
ofrecen mecanismos de flujo de control, así como mecanismos de flujo de
datos que coordinan las acciones que componen una actividad, es decir, un
proceso.

El diagrama de secuencia

El diagrama de secuencia describe las interacciones entre objetos para realizar

una tarea específica, por ejemplo, la inscripción en un examen en un sistema
de administración universitaria. La atención se centra en el orden cronológico
de los mensajes intercambiados entre los interlocutores. Diversas
construcciones para controlar el orden cronológico de los mensajes, así como
conceptos de modularización, permiten modelar interacciones complejas.

El diagrama de comunicación

De forma similar al diagrama de secuencia, el diagrama de comunicación

describe la comunicación entre diferentes objetos. En este caso, la atención se
centra en las relaciones de comunicación entre los socios de la interacción y
no en el orden cronológico del intercambio de mensajes. No existen
estructuras de control complejas. Este diagrama muestra claramente quién
interactúa con quién.

El diagrama temporal

El diagrama temporal muestra explícitamente los cambios de estado de los

socios de interacción que pueden producirse debido a eventos temporales o
como resultado del intercambio de mensajes. Por ejemplo, una persona se
encuentra en estado conectado en cuanto recibe el mensaje del sistema de
administración de la universidad de que la contraseña enviada es válida.
2.4 Diagramas presentados en este 21

Diagrama general de interacción

El diagrama general de interacción modela la conexión entre diferentes

procesos de interacción estableciendo diagramas de interacción individuales
(es decir, diagrama de secuencia, diagrama de comunicación, diagrama de
temporización y otros diagramas generales de interacción) en una secuencia
causal y basada en el tiempo. También especifica las condiciones en las que
se permite que tengan lugar los procesos de interacción. Para modelar el flujo
de control, se del diagrama de actividades. Por ejemplo, un usuario del sistema
de administración de la universidad primero debe iniciar sesión (lo que ya
representa una interacción independiente con el sistema) antes de que se le
permita utilizar otras funcionalidades.

2.4 Diagramas presentados en este libro

Como ya se explicó en el capítulo 1, este libro se limita a los cinco tipos de

diagramas UML más importantes y extendidos, a saber, el diagrama de casos
de uso, el diagrama de clases (incluido el diagrama de objetos), el diagrama
de máquinas de estados y el diagrama de actividades de estado, diagrama de
secuencia y diagrama de actividad. En este libro, presentamos estos diagramas
en el orden en que se utilizarían generalmente en los proyectos de desarrollo
de software. Empezamos con el diagrama de casos de uso, que especifica la
funcionalidad básica de un sistema de software. A continuación, el diagrama
de clases define qué objetos o qué clases intervienen en la realización de esta
funcionalidad. El diagrama de máquina de estados define el comportamiento
intra-objeto, mientras que el diagrama de secuencia especifica el
comportamiento inter-objeto. Por último, el diagrama de actividades permite
definir los procesos que "implementan" los casos de uso del diagrama de casos
de uso.