UML Classroom Español

Temas de pregrado en Ciencias de la Computación
Martina Seidl · Marion Scholz

Christian Huemer · Gerti Kappel
UML @ Classroom
Introducción a
Modelado orientado a objetos
www.allitebooks.com
Temas de pregrado en Ciencias de la Computación
www.allitebooks.com
Temas de pregrado en ciencias de la computación (UTiCS) ofrece contenido instructivo de alta calidad para estudiantes universitarios que estudian
en todas las áreas de la informática y las ciencias de la información. Desde material fundamental teórico y fundamental hasta temas y aplicaciones
de último año, los libros de UTiCS adoptan un enfoque fresco, conciso y moderno y son ideales para el autoaprendizaje o para un curso de uno o
dos semestres. Todos los textos están escritos por expertos establecidos en sus campos, revisados por un consejo asesor internacional y
contienen numerosos ejemplos y problemas. Muchos incluyen soluciones completamente trabajadas.
Más información sobre esta serie en http://www.springer.com/series/7592
www.allitebooks.com
Martina Seidl • Marion Scholz Christian
Huemer • Gerti Kappel
UML @ Classroom
Introducción al modelado orientado a objetos
www.allitebooks.com
Martina Seidl Marion Scholz
Universidad Johannes Kepler Linz Linz, Universidad Tecnológica de Viena Viena,
Austria Austria
Christian Huemer Gerti Kappel

Universidad Tecnológica de Viena Viena, Universidad Tecnológica de Viena Viena,
Austria Austria
Traductor
Tracey Duffy
Traducciones TSD
Editor de series
Ian Mackie
Junta Asesora
Samson Abramsky, Universidad de Oxford, Oxford, Reino Unido
Karin Breitman, Ponti fi cal Catholic University of Rio de Janeiro, Rio de Janeiro, Brasil Chris Hankin, Imperial
College London, Londres, Reino Unido
Dexter Kozen, Universidad de Cornell, Ithaca, EE. UU.
Andrew Pitts, Universidad de Cambridge, Cambridge, Reino Unido
Hanne Riis Nielson, Universidad Técnica de Dinamarca, Kongens Lyngby, Dinamarca Steven Skiena, Universidad
Stony Brook, Stony Brook, Estados Unidos
Iain Stewart, Universidad de Durham, Durham, Reino Unido
Copyright © 2012 de dpunkt.verlag GmbH, Heidelberg, Alemania. Título del

original alemán: UML @ Classroom
ISBN 978-3-89864-776-2
Traducción Copyright © 2014 de Springer International Publishing AG. Todos los derechos
reservados.
ISSN 1863-7310 ISSN 2197-1781 (electrónico)

Temas de pregrado en Ciencias de la Computación ISBN
978-3-319-12741-5 ISBN 978-3-319-12742-2 (libro electrónico)
DOI 10.1007 / 978-3-319-12742-2
Número de control de la Biblioteca del Congreso: 2015930192
Springer Cham Heidelberg Nueva York Dordrecht Londres ©

Springer International Publishing Suiza 2015
Esta obra está sujeta a derechos de autor. Todos los derechos están reservados por el Editor, ya sea que se trate de la totalidad o parte del material,
específicamente los derechos de traducción, reimpresión, reutilización de ilustraciones, recitación, difusión, reproducción en microfilms o de cualquier otra
forma física, transmisión o almacenamiento de información. y recuperación, adaptación electrónica, software de computadora o mediante una metodología
similar o diferente ahora conocida o desarrollada en el futuro.
El uso de nombres descriptivos generales, nombres registrados, marcas comerciales, marcas de servicio, etc. en esta publicación no implica, incluso en ausencia de una
declaración específica, que dichos nombres estén exentos de las leyes y regulaciones de protección pertinentes y, por lo tanto, libres para uso general. utilizar.
El editor, los autores y los editores pueden asumir con seguridad que los consejos y la información de este libro se consideran verdaderos y
precisos en la fecha de publicación. Ni el editor ni los autores ni los editores dan garantía, expresa o implícita, con respecto al material contenido
en este documento o por cualquier error u omisión que pueda haberse cometido.
Impreso en papel sin ácido
Springer International PublishingAGSwitzerland es parte de Springer Science + BusinessMedia ( www.springer.com )
www.allitebooks.com
Prefacio
Los desafíos del desarrollo de software actual son diversos y van mucho más allá de las
tareas de implementación. Van desde la especificación de requisitos sobre el diseño y la
implementación del sistema hasta el mantenimiento y la adaptación adicional del
software, por nombrar sólo algunas fases del ciclo de vida del software. En todas estas
fases del proceso de desarrollo de software, generalmente participan muchas personas
con diferentes antecedentes y experiencias. Estas personas necesitan un lenguaje
común para una comunicación eficiente. Obviamente, tal lenguaje debería ser lo más
preciso posible sin las ambigüedades de un lenguaje natural. Para ello han surgido
lenguajes de modelado. Se utilizan para crear bocetos y planos de sistemas de software,
que a su vez sirven como base para la implementación o incluso la generación
automática de código ejecutable. En el área del desarrollo de software orientado a
objetos, el lenguaje de modelado unificado (UML) pudo prevalecer. Por supuesto, para
utilizar el lenguaje de forma correcta y e fi ciente, es necesario comprender los conceptos
que ofrece UML. Desde 2006, ofrecemos el curso “Modelado orientado a objetos” en la
Universidad Tecnológica de Viena. Este curso es obligatorio para los estudiantes de
informática e informática empresarial en su primer año. En general, tenemos hasta 1,000
estudiantes por año que asisten a nuestro curso. Para tratar con un número tan grande
de estudiantes manteniendo altos estándares de calidad, se ha dedicado mucho esfuerzo
a la preparación de dicho curso. Esto incluye la organización general, el material del
curso y el apoyo al aprendizaje electrónico. Partes del diseño del curso se han
presentado en el Simposio de Educadores de la conferencia MODELS [8, 9, 10, 11, 7,
46].
www.allitebooks.com
vi Prefacio
En particular, enseñamos
• diagramas de clases y objetos,
• diagramas de secuencia,
• diagramas de máquinas de estado,
• diagramas de actividades, y
• diagramas de casos de uso
también como sus interrelaciones. Para ello, introducimos la sintaxis

(la notación de los elementos del lenguaje), la semántica (el significado de los elementos del
lenguaje) y la pragmática (cómo usar los elementos del lenguaje) de estos diagramas UML.
Cubren los conceptos más esenciales del modelado orientado a objetos y se utilizan en
muchas etapas diferentes del proceso de desarrollo de software. El curso está diseñado para
estudiantes que ya conocen los conceptos básicos de lenguajes de programación orientados a
objetos como Java o C #, pero aún no tienen experiencia práctica en ingeniería de software.
Basándonos en nuestra amplia experiencia en la enseñanza de UML, escribimos el libro UML
@ Classroom.En este libro, nos dirigimos tanto a los lectores que deseen aprender UML de
una manera compacta pero no obstante precisa como a los profesores a quienes queremos
inspirar para sus propios ejercicios de curso con nuestro extenso repertorio de ejemplos.
Enseñamos UML lo más cerca posible del estándar e ilustramos todos los conceptos usando
ejemplos intuitivos. El libro se complementa con un sitio web, que contiene un conjunto
completo de diapositivas para enseñar el contenido del libro, así como videos didácticos y
material de e-learning ( http://www.uml.ac.at/ ).
El modelado de software es un campo muy joven de la informática. Experimentó un

crecimiento increíble en las últimas dos décadas. Hoy en día, el uso de modelos va mucho
más allá de la mera documentación. Las técnicas del área del modelado reemplazan
continuamente a la programación convencional. Los modelos son mucho más que imágenes, y
el modelado es mucho más que dibujar. Con nuestro libro UML @ Classroom , queremos
proporcionar una base sólida y una comprensión profunda de los conceptos de modelado
orientado a objetos más importantes. Nuestro objetivo es aumentar el interés y el entusiasmo
por este apasionante y extremadamente importante campo de la informática. UML @
Classroomes un libro de texto, que se dirige explícitamente a principiantes y personas con
poca o ninguna experiencia en modelaje. Introduce conceptos básicos de manera muy precisa,
sin interpretar casos especiales raros. UML @ Classroom se mantiene muy compacto para
permitir que el lector se concentre en los conceptos más utilizados de UML. Se pone mucho
énfasis en ejemplos ilustrativos que dan vida a la teoría que presentamos.
www.allitebooks.com
Prefacio vii
Expresiones de gratitud
Nos gustaría agradecer a las muchas personas que nos apoyaron en la finalización
exitosa de este libro. Un agradecimiento muy especial para nuestras familias que
mostraron gran paciencia con este proyecto de libro. Estamos profundamente en deuda
con Katja Hildebrandt (Universidad Tecnológica de Viena) por dibujar todas las figuras de
este libro y por apoyarnos con un millón de cosas más. Nos gustaría agradecer a Ralf
Gerstner de Springer y Christa Preisendanz de dpunkt.verlag por hacer posible esta
versión en inglés. Además, nos gustaría agradecer a Tracey Duffy por la buena
colaboración en la traducción de la versión alemana de este libro al inglés ya Jeremy
Gibbons (Universidad de Oxford) por la cuidadosa revisión y los valiosos comentarios.
Finalmente,
Linz y Viena, septiembre de 2014 Martina Seidl

Marion Scholz
Christian Huemer
Gerti Kappel
www.allitebooks.com
www.allitebooks.com
Contenido
1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Motivación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Orientación a objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1 Clases. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2 Objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.3 Encapsulación. . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.4 Mensajes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.5 Herencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.3.6 Polimorfismo. . . . . . . . . . . . . . . . . . . . . . . . . . . . La estructura 8
1.4 del libro. . . . . . . . . . . . . . . . . . . . . . . . 9
2 Un breve recorrido por UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.1 La historia de UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3 Diagramas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.1 Diagramas de estructura. . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2 Diagramas de comportamiento. . . . . . . . . . . . . . . . . . . . . . . . Diagramas 19
2.4 presentados en este libro. . . . . . . . . . . . . . . . . . . 21
3 los Use el diagrama del caso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.1 Casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Actores. . . 24
3.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Asociaciones. . . . . . . . . . 25
3.3 . . . . . . . . . . . . . . . . . . . . . . . . . . Relaciones entre actores. . . . . . . . . . . . 27
3.4 . . . . . . . . . Relaciones entre casos de uso. . . . . . . . . . . . . . . . . . 28
3,5 Ejemplos de relaciones. . . . . . . . . . . . . . . . . . . . . . . . Creación de un 30
3.6 diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . 33
3,7 34
3.7.1 Identificación de actores y casos de uso. . . . . . . . . . . . 34
3.7.2 Descripción de casos de uso. . . . . . . . . . . . . . . . . . . . . 35
ix
www.allitebooks.com
X Contenido
3.7.3 Escollos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7.4 Un ejemplo final. . . . . . . . . . . . . . . . . . . . . . . . . . Resumen . . . . . 42
3.8 ................................. 46
4 los Diagrama de clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.1 Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clases. . . . . . 50
4.2 .................................. 52
4.2.1 Notación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.2 Atributos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.3 Multiplicidades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.2.4 Operaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.5 Marcadores de visibilidad. . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.6 Variables de clase y operaciones de clase. . . . . . . . . Asociaciones. 59
4.3 ................................... 60
4.3.1 Asociaciones binarias. . . . . . . . . . . . . . . . . . . . . . . 60
4.3.2 Asociaciones N-Ary. . . . . . . . . . . . . . . . . . . . . . . Clases de 64
4.4 asociación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Agregaciones. . . . . . . . sesenta y cinco
4.5 ........................... 67
4.5.1 Agregaciones compartidas. . . . . . . . . . . . . . . . . . . . . . 68
4.5.2 Composiciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.6 Generalizaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.6.1 Herencia. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.6.2 Clasificación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Clases abstractas 72
4.7 vs. interfaces. . . . . . . . . . . . . . . . . . . . . Tipos de datos . . . . . . . . . . . . . . . 72
4.8 . . . . . . . . . . . . . . . . . . . . . . Crear un diagrama de clases. . . . . . . . . . . . . . 75
4.9 ........... 76
4.9.1 Generalizaciones. . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.9.2 Asociaciones y agregaciones. . . . . . . . . . . . . . Codigo de 78
4.10 GENERACION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5 los Diagrama de máquina de estado. . . . . . . . . . . . . . . . . . . . . . . . . . 85

5.1 Estados y transiciones estatales. . . . . . . . . . . . . . . . . . . . . . . Tipos de 86
5.2 Estados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tipos de transiciones de 89
5.3 estado. . . . . . . . . . . . . . . . . . . . . . . . Tipos de eventos. . . . . . . . . . . . . . . . . . 92
5.4 . . . . . . . . . . . . . . . Estados compuestos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.5 ... 96
5.5.1 El estado ortogonal. . . . . . . . . . . . . . . . . . . . . . 97
5.5.2 Submáquinas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.5.3 Puntos de entrada y salida. . . . . . . . . . . . . . . . . . . . . . 99
5.5.4 El estado histórico. . . . . . . . . . . . . . . . . . . . . . . . . Secuencia de 101
5.6 eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resumen . . . . . . . . . . . . . 102
5.7 ......................... 105
Contenido xi
6 los Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.1 Socios de interacción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intercambiar 108
6.2 mensajes. . . . . . . . . . . . . . . . . . . . . . . . . . . . Mensajes. . . . . . . . . . . . . . . 110
6.3 . . . . . . . . . . . . . . . . . . . . . . . Fragmentos combinados. . . . . . . . . . . . . . . . 112
6.4 ............ 115
6.4.1 Ramas y bucles. . . . . . . . . . . . . . . . . . . . . . . 116
6.4.2 Simultaneidad y orden. . . . . . . . . . . . . . . . . . . . 119
6.4.3 Filtros y afirmaciones. . . . . . . . . . . . . . . . . . . . . . Otros 125
6.5 elementos del lenguaje. . . . . . . . . . . . . . . . . . . . . . . 126
6.5.1 Referencias de interacción. . . . . . . . . . . . . . . . . . . . . 127
6.5.2 Puertas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
6.5.3 Marcadores de continuación. . . . . . . . . . . . . . . . . . . . . 129
6.5.4 Parámetros y atributos locales. . . . . . . . . . . . . 129
6.5.5 Restricciones de tiempo. . . . . . . . . . . . . . . . . . . . . . . . . 130
6.5.6 Invariantes de estado. . . . . . . . . . . . . . . . . . . . . . . . . . . Creación de un 132
6.6 diagrama de secuencia. . . . . . . . . . . . . . . . . . . . . 133
6.6.1 La conexión entre un diagrama de clases y un diagrama de
secuencia. . . . . . . . . . . . . . . . . . . . . . . 133
6.6.2 Descripción de patrones de diseño. . . . . . . . . . . . . . . . . Los 135
6,7 diagramas de descripción general de comunicación, tiempo e interacción. . .
. . . . . . . . . . . . . . . . . . . . . . . . . . Resumen . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6,8 ........... 139
7 los Diagrama de actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

7.1 Actividades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Acciones. . . . . 142
7.2 ................................... 143
7.2.1 Acciones basadas en eventos. . . . . . . . . . . . . . . . . . . . . . 144
7.2.2 Acciones de comportamiento de llamada. . . . . . . . . . . . . . . . . . . . . 145
7.3 Flujos de control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flujos de 146
7.4 objetos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Particiones. . . . . . . . . . . 154
7.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . Manejo de excepciones. . . . . . . . . . . . . . . 156
7,6 . . . . . . . . . . . . . . . Ejemplo final. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
7.7 161
8 Todos juntos ahora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

8.1 Ejemplo 1: Máquina de café. . . . . . . . . . . . . . . . . . . . . . . 167
8.2 Ejemplo 2: Sistema de envío. . . . . . . . . . . . . . . . . . . . 171
8.3 Ejemplo 3: Pila de tipos de datos. . . . . . . . . . . . . . . . . . . . . . 180
8.4 Resumen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
9 Temas adicionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

9.1 Estructuración de modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
9.1.1 Paquetes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
9.1.2 Importación de elementos / paquetes. . . . . . . . . . . . . . . 185
xii Contenido
9.2 El metamodelo UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . Mecanismos de 186

9.3 extensión UML. . . . . . . . . . . . . . . . . . . . . . 187
9.3.1 Estereotipos y perfiles. . . . . . . . . . . . . . . . . . . . 189
9.3.2 Aplicación de estereotipos de un perfil. . . . . . . . . . . . Desarrollo de 191
9.4 software basado en modelos. . . . . . . . . . . . . . . 192
Referencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Índice . . . . . . . . 195
......................................... 199
Capítulo 1
Introducción
los Lenguaje de modelado unificado ( UML) es una consolidación de las mejores prácticas que se Modelado unificado
han establecido a lo largo de los años en el uso de lenguajes de modelado. UML nos permite Lenguaje (UML)
presentar los aspectos ampliamente variables de un sistema de software (por ejemplo, requisitos,
estructuras de datos, flujos de datos y flujos de información) dentro de un marco único utilizando
conceptos orientados a objetos. Sin embargo, antes de adentrarnos demasiado en UML, en este
capítulo explicamos primero por qué el modelado es una parte indispensable del desarrollo de
software. Para ello, analizamos qué son los modelos y para qué los necesitamos. Recapitulamos
brevemente los conceptos básicos de la orientación a objetos antes de continuar con una
descripción general de la estructura del libro.
1.1 Motivación
Imagine que desea desarrollar un sistema de software que un cliente le ha encargado.

Uno de los primeros desafíos a los que se enfrenta es aclarar lo que el cliente realmente
quiere y si ha entendido los requisitos exactos del cliente para el posible sistema. Este
primer paso ya es fundamental para el éxito o el fracaso de su proyecto. La pregunta es,
¿cómo se comunica con su cliente? El lenguaje natural no es necesariamente una buena
opción, ya que es impreciso y ambiguo. Los malentendidos pueden surgir fácilmente y
existe un gran riesgo de que personas con diferentes antecedentes (por ejemplo, un
científico informático y un gerente comercial) hablen con propósitos contradictorios, lo que
puede tener consecuencias graves.
Lo que necesita es poder crear un modelo para su software. Este modelo destaca los
aspectos importantes del software de forma clara
© Springer International Publishing Suiza 2015 1

M. Seidl y col., UML @ Classroom, Temas de pregrado en Ciencias de la
Computación, DOI 10.1007 / 978-3-319-12742-2_1
2 1. Introducción
de notación que es lo más simple posible pero que se abstrae de detalles irrelevantes, al igual que
los modelos en arquitectura, por ejemplo, los planos de construcción. Un plano de construcción
para un edificio contiene información como el plano del piso. Los materiales de construcción que
se utilizarán no se especifican en este momento; son irrelevantes y harían el plan más complicado
de lo necesario. El plan tampoco contiene información sobre cómo se colocarán los cables
eléctricos. Se crea un plan separado para este aspecto para evitar presentar demasiada
información a la vez. Al igual que en la arquitectura, es importante en la tecnología de la
información que personas con diferentes antecedentes (por ejemplo, arquitecto y constructor)
puedan leer, interpretar e implementar el modelo.
Lenguaje de modelado Lenguajes de modelado fueron desarrollados precisamente para tales escenarios y demuestran
reglas claramente definidas para una descripción estructurada de un sistema. Estos idiomas
pueden ser textual por ejemplo, un lenguaje de programación como Java) o visual por ejemplo, un
lenguaje que proporciona símbolos para transistores, diodos, etc. que se pueden combinar entre
sí). Los lenguajes de modelado pueden diseñarse para un dominio específico, por ejemplo, para
describir aplicaciones web. Por un lado, estos lenguajes de modelado específicos de dominio proporcionar
herramientas y pautas para resolver problemas en un campo específico de manera eficiente; por
otro lado, también pueden ser restrictivas. Alternativamente, los lenguajes de modelado pueden
diseñarse para uso general. El lenguaje UML, que es el tema de este libro, es un lenguaje de
modelado de propósito general. Usaremos UML para conocer los conceptos más importantes del
modelado orientado a objetos.
Orientado a objetos Modelado orientado a objetos es una forma de modelado que obedece al paradigma
modelado orientado a objetos. En las dos subsecciones siguientes, veremos brevemente la noción de
modelo y los conceptos principales de orientación a objetos. Esto nos proporcionará una
buena base para nuestro examen posterior del modelado orientado a objetos con UML.
1.2 Modelos
Sistema Los modelos nos permiten describir sistemas de manera eficiente y elegante. UN sistema
es un todo integrado formado por componentes que están relacionados entre sí y se influyen
entre sí de tal manera que pueden percibirse como una unidad única, basada en tareas o
basada en un propósito. En este sentido, se separan del entorno circundante [52]. Ejemplos
de sistemas son cosas materiales, como automóviles o aviones, entornos ecológicos, como
lagos y bosques, pero también unidades organizativas como una universidad o una empresa.
En tecnología de la información, estamos interesados en particular en sistemas de software
y, por lo tanto, en modelos que describen sistemas de software.
Sistema de software
1.2 Modelos 3
Los propios sistemas de software se basan en abstracciones que representan hechos de Abstracción
la realidad procesables por máquina. En este contexto, abstracción significa generalización,
dejando de lado las características específicas e individuales. El abstracto es lo opuesto al
concreto. Por tanto, abstraer significa alejarse de lo específico, distinguir la sustancia de lo
incidental, reconocer características comunes [29].
Al crear sistemas de software, es extremadamente importante seleccionar los medios Seleccionar medios de
adecuados de abstracción: por un lado para la implementación, pero por otro lado también abstracción
para el uso posterior de los sistemas de software. Elegir los medios correctos de abstracción
facilita la programación. Las partes individuales tienen interfaces simples y pequeñas. Se
pueden introducir nuevas funciones sin la necesidad de una reorganización extensa. La
elección de los medios de abstracción incorrectos puede resultar en una serie de sorpresas
desagradables durante la implementación: las interfaces serán complicadas y será difícil
implementar cambios. Sólo puede gestionar la complejidad cada vez mayor de los sistemas de
software modernos con los medios adecuados de abstracción [26]. Aquí es donde el modelado
puede proporcionar valiosos servicios.
Para desarrollar una mejor comprensión de los conceptos de modelado, a continuación

presentamos definiciones generalizadas y generalmente reconocidas de la noción de modelo, así como
las propiedades que debe poseer un buen modelo.
La noción de un modelo es importante no solo en la tecnología de la información sino Modelo
también en muchas otras disciplinas científicas (matemáticas, filosofía, psicología,

economía, etc.). Derivado del latín "module", que designa una escala en la arquitectura,
durante el Renacimiento la palabra "modello" se utilizó en Italia para un objeto ilustrativo
destinado a presentar la forma y el diseño de un edificio proyectado a un cliente y aclarar
cuestiones de diseño y arquitectura. Durante los siglos siguientes, la noción de “modelo”
se ha utilizado en varias ramas de la ciencia para una descripción simplificada de hechos
complejos de la realidad.
En 1973, Herbert Stachowiak propuso una teoría modelo que se distingue por tres Definición de Herbert
características [48]: Stachowiak
1. Cartografía: un modelo es siempre una imagen (mapeo) de algo, un

representación de originales naturales o arti fi ciales que pueden ser modelos ellos mismos.
2. Reducción: un modelo no captura todos los atributos del original,

más bien sólo aquellos que parecen relevantes para el modelador o usuario del modelo.
3. Pragmatismo: pragmatismo significa orientación hacia la utilidad. UN

El modelo se asigna a un original en función de las siguientes preguntas:
¿Para quien? ¿Por qué? ¿Para qué? El modelador o el usuario utiliza un modelo en lugar del original
dentro de un período de tiempo específico y para un propósito específico.
4 1. Introducción
Los modelos soportan una representación de un sistema que se reduce a lo esencial

para minimizar la complejidad del sistema a aspectos manejables. Por lo general, un sistema
no se describe mediante una única vista, sino mediante una serie de vistas que juntas
producen una imagen general unificada. Así, una vista podría describir los objetos
involucrados y su relación entre sí; otra vista podría describir el comportamiento de un grupo
de objetos o presentar las interacciones entre diferentes objetos.
Propiedades de los modelos Los modelos deben crearse con mucho cuidado y la debida consideración. Según Bran
Selic [47], cinco características determinan la calidad de un modelo:
• Abstracción: un modelo es siempre una representación reducida del sistema que

representa. Debido a que los detalles que son irrelevantes en un contexto específico se
ocultan o eliminan, es más fácil para el usuario comprender la esencia del todo.
• Comprensibilidad: simplemente omitir detalles irrelevantes no es suficiente para que un modelo

sea comprensible. Es importante presentar los elementos restantes de la manera más intuitiva
posible, por ejemplo, en una notación gráfica. La comprensibilidad resulta directamente de la
expresividad del lenguaje de modelado. La expresividad se puede definir como la capacidad de
presentar contenido complejo con el menor número posible de conceptos. De esta manera, un
buen modelo reduce el esfuerzo intelectual requerido para comprender el contenido
representado. Por ejemplo, los lenguajes de programación típicos no son particularmente
expresivos para un lector humano, ya que se requiere mucho esfuerzo para comprender el
contenido del programa.
• Exactitud: un modelo debe resaltar las propiedades relevantes del sistema real, reflejando la
realidad lo más fielmente posible.
• Predictividad: un modelo debe permitir la predicción de propiedades interesantes pero no obvias
del sistema que se está modelando. Esto se puede hacer mediante simulación o análisis de
propiedades formales.
• Rentabilidad: a largo plazo, debe ser más económico crear el modelo que crear el
sistema que se está modelando.
Los modelos se pueden utilizar para diversos fines. Así distinguimos entre- descriptivo
Modelo descriptivo y preceptivo modelos [17]. Modelos descriptivos
mostrar una parte de la realidad para facilitar la comprensión de un aspecto concreto. Por ejemplo, un
mapa de la ciudad describe una ciudad de tal manera que ayude a una persona no local a encontrar
Modelo prescriptivo rutas dentro de la ciudad. A diferencia de, modelos prescriptivos se utilizan para ofrecer un manual de
construcción del sistema a desarrollar.
En este libro, veremos cómo se pueden modelar los diferentes aspectos de un sistema de software
utilizando un lenguaje de modelado, el Lenguaje de modelado unificado, de modo que el código
Código ejecutable como ejecutable se pueda derivar de forma manual o (semi) automática, o se pueda obtener documentación
modelo fácilmente comprensible. ser
1.2 Modelos 5
creado. Por cierto, el código ejecutable, desarrollado en cualquier lenguaje de programación,

como Java, también es un modelo. Este modelo representa el problema a resolver y está
optimizado para su ejecución en computadoras.
En resumen, hay tres aplicaciones para los modelos [19]:
• Modelos como croquis

• Modelos como plano
• Modelos como programas ejecutables
Los modelos se utilizan como bosquejo comunicar determinados aspectos de un sistema de forma Modelos como croquis
sencilla. Aquí, el modelo no es un mapeo completo del sistema. Los bocetos se distinguen realmente
por su selectividad, ya que se reducen a los aspectos esenciales para la resolución de un problema.
Los bocetos suelen hacer visibles las soluciones alternativas. A continuación, se analizan en el equipo
de desarrollo. Por tanto, los modelos también se utilizan como base para la discusión.
En contraste con el uso de modelos como bocetos, la integridad es muy importante cuando los
modelos se utilizan como un Plano. Estos modelos deben contener detalles suficientes para permitir a Modelos como plano
los desarrolladores crear sistemas listos para funcionar sin tener que tomar decisiones de diseño. Los
modelos utilizados como planos a menudo no especifican todo el sistema, solo ciertas partes. Por
ejemplo, las de fi niciones de interfaz entre subsistemas se definen en el modelo, por lo que los
desarrolladores son libres de decidir sobre los detalles de implementación interna. Si los modelos son
descripciones de comportamiento, el comportamiento también se puede simular y probar para
identificar fallas por adelantado.
Los modelos como bocetos y planos se pueden utilizar tanto para ingeniería avanzada y ingeniería
hacia atrás. En la ingeniería avanzada, el modelo es la base para la creación de código, mientras que Adelante y hacia atrás
en la ingeniería inversa, el modelo se genera a partir del código para documentar el código de una Ingenieria
manera clara y fácilmente comprensible.
Finalmente, los modelos se pueden utilizar como programas ejecutables. Esto significa que los Modelos como ejecutables
modelos se pueden especificar con tanta precisión que se puede generar código a partir de ellos programas
automáticamente. En el contexto de UML, el desarrollo de software basado en modelos se ha vuelto
extremadamente popular en los últimos años; ofrece un proceso para usar UML como lenguaje de
programación. Abordaremos esto brevemente en el Capítulo 9 de este libro, después de haber discutido
los conceptos básicos de UML. En algunas áreas de aplicación, como el desarrollo de sistemas
integrados, ya se utilizan modelos en lugar de los lenguajes de programación tradicionales. En otras
áreas, se está llevando a cabo una investigación activa para elevar el desarrollo de sistemas de
software a un nivel de abstracción nuevo, más fácil de mantener y menos propenso a errores.
6 1. Introducción
1.3 Orientación a objetos
Si queremos modelar en un estilo orientado a objetos, primero debemos aclarar qué orientación
Orientación a objetos a objetos medio. La introducción de la orientación a objetos se remonta a la década de 1960,
cuando se presentó el lenguaje de simulación SIMULA [24], basado en un paradigma que era lo
más natural posible para los humanos para describir el mundo. El enfoque orientado a objetos
corresponde a la forma en que miramos el mundo real; la vemos como una sociedad de
individuos autónomos, llamados objetos, que ocupan un lugar fijo en esta sociedad y, por tanto,
deben cumplir obligaciones predefinidas.
No hay una única definición de orientación a objetos. Sin embargo, existe un consenso
general sobre las propiedades que caracterizan la orientación a objetos. Naturalmente, los
objetos juegan un papel central en los enfoques orientados a objetos. Visto simplemente, los
objetos son elementos de un sistema cuyos datos y operaciones se describen. Los objetos
interactúan y se comunican entre sí. En general, esperamos los conceptos que se describen a
continuación de un enfoque orientado a objetos.
1.3.1 Clases
Clase En muchos enfoques orientados a objetos, es posible de fi nir clases que describen los atributos y el
comportamiento de un conjunto de objetos (las instancias de una clase) de forma abstracta y, por lo tanto,
agrupan características comunes de los objetos. Por ejemplo, las personas tienen un nombre, una dirección y
un número de seguro social. Los cursos tienen un identi fi cador único, un título y una descripción. Las salas de
conferencias tienen un nombre, así como una ubicación, etc. Una clase también define un conjunto de
operaciones permitidas que pueden aplicarse a las instancias de la clase. Por ejemplo, puede reservar una sala
de conferencias para una fecha determinada, un alumno puede inscribirse para un examen, etc. De esta
manera, las clases describen el comportamiento de los objetos.
1.3.2 Objetos
Objeto Las instancias de una clase se conocen como su objetos. Por ejemplo, lh1,
el Aula 1 de la Universidad Tecnológica de Viena, es una instancia concreta de la clase Sala de
conferencias. En particular, un objeto se distingue por el hecho de que tiene su propia identidad, es
decir, las diferentes instancias de una clase pueden identificarse de forma única. Por ejemplo, el
proyector en la sala de conferencias 1 es un objeto diferente al proyector en la sala de conferencias
2, incluso
1.3 Orientación a objetos 7
si los dispositivos son del mismo tipo. Aquí nos referimos a idéntico dispositivos pero no el mismo dispositivo.
La situación para valores concretos de tipos de datos es diferente: el número 1, que es un valor
concreto del tipo de datos
Entero, no tiene una identidad distinguible.
Un objeto siempre tiene un cierto estado. Un estado se expresa por los valores de sus atributos.
Por ejemplo, una sala de conferencias puede tener el estado
ocupado o gratis. Un objeto también muestra comportamiento. El comportamiento de un objeto se
describe mediante el conjunto de sus operaciones. Las operaciones se activan enviando un mensaje.
1.3.3 Encapsulación
Encapsulamiento es la protección contra el acceso no autorizado al estado interno de un objeto Encapsulamiento
a través de una interfaz de fi nida unívocamente. Los diferentes niveles de visibilidad de las
interfaces ayudan a definir diferentes autorizaciones de acceso. Java, por ejemplo, tiene
marcadores de visibilidad explícitos publico privado, y protegido, que respectivamente permiten
el acceso para todos, solo dentro del objeto, y solo para miembros de la misma clase, sus
subclases y del mismo paquete.
1.3.4 Mensajes
Los objetos se comunican entre sí a través mensajes. Un mensaje a un objeto representa Mensaje
una solicitud para ejecutar una operación. El objeto mismo decide si ejecutar esta operación
y cómo. La operación solo se ejecuta si el remitente está autorizado a llamar a la operación,
esto se puede regular en forma de visibilidades (ver párrafo anterior) y se dispone de una
implementación adecuada. En muchos lenguajes de modelado y programación orientados a
objetos, el concepto de sobrecarga esta apoyado. Esto permite definir una operación de
manera diferente para diferentes tipos de parámetros. Por ejemplo, el operador + se da Sobrecarga
cuenta de un comportamiento diferente dependiendo de si se usa para sumar enteros (p.
Ej., 1 + 1 = 2) o para concatenar cadenas de caracteres (p. ej., “A” + “b” = “ab”).
1.3.5 Herencia
El concepto de herencia es un mecanismo para derivar nuevas clases de clases existentes. Herencia
Una subclase derivada de una clase existente (= su-
www.allitebooks.com
8 1. Introducción
perclass) hereda todos los atributos y operaciones visibles (especificación e implementación) de

la superclase. Una subclase puede:
• Definir nuevos atributos y / u operaciones

• Sobrescribir la implementación de operaciones heredadas
• Agrega su propio código a las operaciones heredadas
La herencia permite clases extensibles y, como consecuencia, la creación de jerarquías de

Jerarquía de clases clases como base para el desarrollo de sistemas orientados a objetos. Una jerarquía de clases
consta de clases con propiedades similares,
por ejemplo, Persona ← Empleado ← Profesor ← ... dónde
UN ← segundo significa que segundo es una subclase de A.
Cuando se usa correctamente, la herencia ofrece muchas ventajas: reutilización de partes del
programa o del modelo (evitando así redundancia y errores), definición consistente de interfaces, uso
como ayuda de modelado a través de una categorización natural de los elementos que ocurren y
soporte para el desarrollo incremental, es decir, un refinamiento paso a paso de conceptos generales
a conceptos específicos.
1.3.6 Polimorfismo
Polimorfismo En términos generales, polimorfismo es la capacidad de adoptar diferentes formas. Durante la

ejecución de un programa, un atributo polimórfico puede tener referencias a objetos de diferentes
clases. Cuando se declara este atributo, un tipo (p. Ej., Clase Persona) se asigna estáticamente en
tiempo de compilación. En tiempo de ejecución, este atributo también se puede vincular
dinámicamente a un subtipo (por ejemplo, subclase Empleado o subclase Estudiante).
Una operación polimórfica se puede ejecutar sobre objetos de diferentes clases y tener una
semántica diferente en cada caso. Este escenario se puede implementar de muchas maneras:
(i) a través de polimorfismo paramétrico, más conocido como genérico, aquí se utilizan
parámetros de tipo. En Java, por ejemplo, las clases concretas se transfieren a las operaciones
como argumentos; (ii) vía polimorfismo de inclusión —Las operaciones pueden aplicarse a
clases y sus subclases directas e indirectas; (iii) vía sobrecarga de operaciones; y (iv) vía coerción,
es decir, la conversión de tipos. Los dos primeros métodos anteriores se conocen como polimorfismo
universal; los otros dos métodos se denominan polimorfismo ad hoc [ 13].
1.4 La estructura del libro 9
1.4 La estructura del libro
En el Capítulo 2 damos una breve descripción de UML recapitulando la historia de su creación y

echando un vistazo breve a sus 14 diagramas diferentes. Luego, en el Capítulo 3, presentamos los
conceptos del diagrama de casos de uso. Este diagrama nos permite describir los requisitos que
debe cumplir un sistema a desarrollar. En el Capítulo 4 presentamos el diagrama de clases. Este
diagrama nos permite describir la estructura de un sistema. Para permitirnos modelar el
comportamiento de un sistema, en el Capítulo 5 presentamos el diagrama de la máquina de
estados, en el Capítulo 6 el diagrama de secuencia y en el Capítulo 7 el diagrama de actividad.
Explicamos la interacción de los diferentes tipos de diagramas en el Capítulo 8 con tres ejemplos.
En el Capítulo 9, examinamos brevemente conceptos avanzados que son de importancia
significativa para el uso práctico de UML.
Todos los conceptos se explican mediante ejemplos, todos ellos basados en el entorno
universitario típico de Austria. En la mayoría de los casos, representan escenarios muy
simplificados. No es nuestra intención en este libro modelar un único sistema continuo, ya
que existe un alto riesgo de que al hacerlo nos perdamos en una multitud de detalles
técnicos. Por lo tanto, hemos seleccionado ejemplos de acuerdo con su beneficio didáctico y
su fuerza ilustrativa de expresión. En muchos casos, por lo tanto, hemos hecho suposiciones
que, por razones didácticas, se basan en presentaciones simplificadas de la realidad.
UML se basa completamente en conceptos orientados a objetos. Esto se nota particularmente en

el diagrama de clases, que se puede traducir fácilmente a un lenguaje de programación orientado a
objetos. Conoceremos el diagrama de clases y las posibles traducciones al código del programa en el
Capítulo 4. Sin embargo, UML no ha sido diseñado para un lenguaje específico orientado a objetos.
En aras de la legibilidad, utilizamos una noción de orientación a objetos como se encuentra en los
lenguajes de programación modernos como Java o C #.
Capitulo 2
Un breve recorrido por UML
Antes de introducir los conceptos más importantes de UML en los siguientes capítulos, primero
explicamos los antecedentes de este lenguaje de modelado. Observamos cómo nació UML y
qué significa realmente la “U” de “Unificado”. Entonces respondemos a la pregunta de cómo se
define UML en sí, es decir, ¿de dónde provienen las reglas que dictan cómo debería verse un
modelo válido en UML? Además, describimos para qué se utiliza UML. Finalmente, damos una
breve descripción de los 14 diagramas UML en la versión actual 2.4.1 de la especificación del
estándar UML. Estos diagramas se pueden utilizar para modelar tanto la estructura como el
comportamiento.
2.1 La historia de UML
La introducción de conceptos orientados a objetos en la tecnología de la información se origina en el Orígenes del objeto
trabajo de principios de la década de 1960 [12]. Las primeras ideas se implementaron en sistemas orientación
como Sketchpad, que ofrecía un nuevo enfoque de comunicación gráfica entre el hombre y la
computadora [28, 51].
En la actualidad, el lenguaje de programación SIMULA [24] se considera el primer SIMULA
lenguaje de programación orientado a objetos. SIMULA se utilizó principalmente para
desarrollar software de simulación y no se utilizó de forma muy generalizada. Ya incluía
conceptos como clases, objetos, herencia y enlace dinámico [2].
La introducción de estos conceptos fue el comienzo de una revolución en el desarrollo

de software. En las décadas siguientes, siguió una multitud de lenguajes de programación Orientado a objetos
basados en el paradigma orientado a objetos [21]. Estos incluyen lenguajes como C ++ lenguajes de programación
[50], Eiffel [31] y Smalltalk [28]. Ya contenían muchos de los conceptos importantes de los
lenguajes de programación modernos y todavía se utilizan hoy.

Computación, DOI 10.1007 / 978-3-319-12742-2_2
12 2 Un breve recorrido por UML
La aparición e introducción de la orientación a objetos como método en la ingeniería de software

está estrechamente relacionada con la aparición de lenguajes de programación orientados a objetos.
Hoy en día, la orientación a objetos es un enfoque probado y bien establecido para lidiar con la
complejidad de los sistemas de software. Se aplica no solo en lenguajes de programación sino
también en otras áreas, como en bases de datos o la descripción de interfaces de usuario.
Como ya comentamos 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
apoyo de máquinas. Los lenguajes de programación procedimental no son necesariamente las
herramientas más apropiadas para describir el mundo real: las diferencias de concepto entre una
descripción natural de un problema y la implementación práctica como programa son enormes. La
programación orientada a objetos fue un intento de desarrollar mejores programas que, sobre
todo, sean más fáciles de mantener [12].
A lo largo 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 los lenguajes de programación orientados a
objetos como Java [4] o C # [32] y en los lenguajes de modelado orientados a objetos como UML.
Sin embargo, el camino hacia el estado actual del desarrollo de software fue largo y tortuoso.
Ada En la década de 1980, el lenguaje de programación Ada, financiado por el Departamento de

Defensa de los Estados Unidos, fue extremadamente popular debido a sus poderosos
conceptos y eficientes compiladores [25]. Incluso en ese entonces, Ada apoyaba tipos de datos
abstractos en forma de paquetes y concurrencia en forma de Tareas. Los paquetes permitieron
la separación de la especificación y la implementación y el uso de objetos y clases de objetos.
Ada se distinguió así fundamentalmente de otros lenguajes populares de la época, como
Fortran y Cobol. Como consecuencia, siguió una gran demanda de métodos de diseño y
análisis 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 los Estados Unidos, estos
métodos de modelado se basaron específicamente en las características de Ada. Grady Booch
fue uno de los primeros investigadores en publicar trabajos sobre el diseño orientado a objetos
de programas Ada [5].
Método booch
Con el tiempo, surgieron varios métodos de modelado orientados a objetos (ver [12]
para una descripción general). En general, los métodos de modelado tenían una fuerte
referencia a los lenguajes de programación, como el método Booch, o una fuerte
Enfoque OMT por referencia al modelado de datos, como el Técnica de modelado de objetos ( OMT)
Rumbaugh y col. desarrollado por James Rumbaugh et al. [42]. OMT apoyó 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.
Acercamiento de OOSE por Independientemente de esto, Ivar Jacobson et al. introdujo el Ingeniería de software
Jacobson y col. orientada a objetos ( OOSE) enfoque [27]. Este enfoque se desarrolló originalmente para
describir los sistemas de telecomunicaciones.
2.1 La historia de UML 13
En la década de 1980 y principios de la de 1990, el mundo del modelado se vio inundado por Método de guerra
una multitud de lenguajes de modelado diferentes. Se requirió un esfuerzo considerable para

hacer frente a los problemas de compatibilidad resultantes. Los modelos de los diferentes socios
del proyecto a menudo no eran compatibles y no siempre era posible reutilizar modelos en
diferentes proyectos. El resultado fue discusiones agotadoras sobre diferentes notaciones, que
restaron valor a los problemas reales de modelado. Como constantemente aparecían nuevos
lenguajes de modelado, no había claridad sobre cuáles eran dignos de inversión y cuáles eran
solo una tendencia de corta duración. Si un idioma no se aceptaba, por lo general se perdían
todas las inversiones que se habían hecho para establecerlo dentro de un proyecto o una
empresa. Mirando hacia atrás, esta vez de numerosos enfoques, a menudo con la diferencia solo
en los detalles, método de guerra.
Para poner fin a esta insatisfactoria situación, en 1996 el Grupo de administración de objetos Gestión de objetos
( OMG) [33], el organismo de estandarización más importante para el desarrollo de software Grupo (Dios mío)
orientado a objetos, pidió la especificación de un estándar de modelado uniforme.
El año anterior, 1995, Grady Booch, Ivar Jacobson y James Rumbaugh habían
combinado sus ideas y enfoques en la conferencia OOPSLA (OOPSLA significa
Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones). Desde
entonces, a Booch, Jacobson y Rumbaugh a menudo se les ha llamado los "tres
amigos". Se fijaron los siguientes objetivos [1]: Tres amigos
• Uso de conceptos orientados a objetos para representar sistemas completos en lugar de solo una
parte del software.
• Establecimiento de una relación explícita entre conceptos de modelado y código de
programa ejecutable.
• Consideración de factores de escala que son inherentes a sistemas complejos y críticos.
• Creación de un lenguaje de modelado que puede ser procesado por máquinas pero también puede ser
leído por seres humanos.
El resultado de sus esfuerzos fue el Lenguaje de modelado unificado ( UML) que se presentó Modelado unificado
en la versión 1.0 en 1997 en respuesta a la convocatoria de OMG. Varios antiguos competidores Lenguaje (UML)
participaron en la creación de la versión 1.1 que apareció posteriormente en 1998. Uno de los
principales objetivos fue una especificación coherente del núcleo del lenguaje de UML que está
documentado en el metamodelo consulte el Capítulo 9). El metamodelo define qué elementos del
modelo proporciona el lenguaje UML y cómo usarlos correctamente. Para formular restricciones Metamodelo
que los elementos del modelo deben cumplir por completo, Lenguaje de restricción de objetos ( OCL)
[36], basado en la lógica de predicados, se introdujo. En versiones posteriores, junto con la
revisión de ciertos conceptos del lenguaje, los mecanismos de intercambiabilidad de modelos en Restricción de objetos
forma de Formato de intercambio de metadatos XML Idioma (OCL)

Metadatos XML (XMI) [38] se agregaron. Además de estos pequeños cambios, en 2000 el OMG inició un
Formato de intercambio proceso de modernización de UML. Esto finalmente llevó a la adopción del estándar de
(XMI) lenguaje UML 2.0 en 2005. Con la excepción de pequeños cambios que, a través de versiones
provisionales, resultaron en la versión actual 2.4.1, esta es la descripción del lenguaje de UML
que conoceremos y conoceremos. utilizar en este libro.
Hoy en día, UML es uno de los lenguajes de modelado orientado a objetos gráficos 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
complejas de objetos como procesos con concordancia. 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 modelado y una notación gráfica intuitiva para
modelar varias áreas de aplicación, lo que permite especificar, diseñar, visualizar y documentar
un sistema de software [43]. El resultado del 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, un lenguaje de programación

específico o una plataforma de destino específica en la que se debe utilizar el sistema que se va a
desarrollar. UML tampoco ofrece un proceso de desarrollo de software. De hecho, UML separa el
lenguaje de modelado y el método de modelado. Este último puede definirse sobre una base
específica del proyecto o de la empresa. Sin embargo, los conceptos del lenguaje UML favorecen un
proceso iterativo e incremental [43].
Uso en el proceso de UML se puede utilizar de forma coherente en todo el proceso de desarrollo de software. En
desarrollo de software todas las etapas del desarrollo, se pueden usar los mismos conceptos de lenguaje en la misma
notación. Por lo tanto, un modelo se puede refinar por etapas. No es necesario traducir un
modelo a otro lenguaje de modelado. Esto permite un proceso de desarrollo de software iterativo
e incremental. UML es adecuado para varias áreas de aplicación con diferentes requisitos en
cuanto a complejidad, volumen de datos, tiempo real, etc.
Los elementos del modelo UML y su uso correcto se especi fi can en el UML metamodelo [ 35].
Lenguaje genérico Los conceptos del lenguaje se definen de manera tan genérica que se logra una aplicabilidad
conceptos amplia y flexible. Para evitar restringir el uso de UML, el estándar es (intencionalmente) vago en
varios puntos, lo que permite diferentes interpretaciones en forma de puntos de variación
Punto de variación semántica semántica. Sin embargo, esta es una espada de dos filos; también conduce a diferentes
implementaciones del estándar de lenguaje mediante herramientas de modelado, lo que a su vez,
desafortunadamente, dificulta el intercambio de modelos.
2.3 Diagramas 15
2.3 Diagramas
En UML, un modelo se representa gráficamente en forma de diagramas. Un diagrama Diagrama

proporciona una vista de esa parte de la realidad descrita por el modelo. Hay diagramas que
expresan qué usuarios utilizan qué funcionalidad y diagramas que muestran la estructura del
sistema pero sin especificar una implementación concreta. También hay diagramas que
representan procesos admitidos y prohibidos. En la versión actual 2.4.1, UML ofrece 14
diagramas que describen la estructura o el comportamiento de un sistema.
Figura 2.1
Diagrama Diagramas UML
Diagrama de estructura Diagrama de comportamiento
Clase Paquete Objeto Máquina estatal Caso de uso

Diagrama Diagrama Diagrama Diagrama Diagrama
Componente Perfil Actividad Interacción

Diagrama Diagrama Diagrama Diagrama
Estructura de composición
Diagrama
Secuencia Descripción general de la interacción
Diagrama Diagrama
Despliegue
Diagrama
Comunicación Sincronización
Diagrama Diagrama
Figura 2.1 muestra una taxonomía de los 14 diagramas UML [35], dando una categorización muy
aproximada. Como muestra la figura, diferenciamos entre diagramas de estructura y diagramas de
comportamiento. Los diagramas de comportamiento incluyen los diagramas de interacción, que a su
vez constan de cuatro diagramas (véase el Capítulo 6).
Un diagrama suele estar rodeado por un rectángulo con un pentágono en la esquina superior Notación para diagrama
izquierda. Este pentágono contiene el tipo de diagrama y el nombre del diagrama. Opcionalmente, cuadro
los parámetros se pueden especificar siguiendo el nombre que luego se puede utilizar dentro del
diagrama. Figura 2.2 estafa-
dieciséis 2 Un breve recorrido por UML
Figura 2.2
Universidad cd
Ejemplos de marcos de diagrama UML
Persona edificio
Profesor Estudiante
* *
en
se
ña
e
ist
as
* * *
en
Curso Sala de conferencias
* 1
Registro sd (curso, fecha)
:Registro
:Estudiante :Base de datos
Sistema
registrarse (curso, fecha)
entrar (curso, fecha)
ingrese: ″ ok ″
registrarse: ″ ok ″
contiene dos ejemplos de marcos de diagrama. En particular, muestra un diagrama de clase ( discos compactos) con el
nombre Universidad y un diagrama de secuencia ( Dakota del Sur) llamado
Registro con los parámetros curso y fecha.

Nota Un concepto que puede aparecer en todos los diagramas es el Nota. Una nota puede contener
cualquier forma de expresión que especifique el diagrama y sus elementos de forma más precisa,
por ejemplo, en lenguaje natural o en el lenguaje de restricción de objetos (OCL). Se pueden
adjuntar notas a todos los demás elementos del modelo. Figura 2.3 muestra un ejemplo del uso de
una nota que especifica en lenguaje natural que las personas no pueden calificarse a sí mismas. La
clase Persona y la asociación Los grados representar conceptos del diagrama de clases que se
presentarán en el capítulo 4.
2.3 Diagramas 17
Figura 2.3
No se permite que las personas se
califiquen a sí mismas Ejemplo de una nota
Persona *
* Los grados
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 en
el tiempo) no se considera 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 diagramaDiagrama de clase
de clase se originan en el modelado de datos conceptuales y el desarrollo de software orientado a (ver Capítulo 4)
objetos. Estos conceptos se utilizan para especificar las estructuras de datos y las estructuras de
Persona
objetos de un sistema. El diagrama de clases se basa principalmente en los conceptos de clase,
generalización, y asociación. Por ejemplo, en un diagrama de clases, puede modelar que las clases Curso, Profe. Estudiante
en
Estudiante, y Profesor ocurren en un sistema. Los profesores imparten cursos y los estudiantes asisten * se *
ña e
ist
a cursos. Los estudiantes y profesores tienen propiedades comunes ya que ambos son miembros de as
* *
la clase. Persona. Curso
Esto se expresa mediante una relación de generalización.
El diagrama de objetos
Basado en las de fi niciones del diagrama de clases relacionado, un diagrama de objeto muestra una Diagrama de objetos
instantánea concreta del estado del sistema en un momento de ejecución específico. Por ejemplo, un (ver Capítulo 4)
diagrama de objetos podría mostrar que un profesor Henry Foster ( henryFoster) imparte los cursos de
oom: curso
Modelización Orientada a Objetos ( oom) y programación orientada a objetos ( oop). HenryFoster
:Profesor
oop: curso
El diagrama del paquete
Diagrama del paquete los diagrama del paquete agrupa diagramas o elementos del modelo según propiedades
comunes, como la cohesión funcional. Por ejemplo, en un sistema de administración
Administración
universitaria, podría introducir paquetes que contengan información sobre la docencia, la
Estudiante investigación y los aspectos administrativos. Los paquetes a menudo se integran en otros
Examen
diagramas en lugar de mostrarse en diagramas separados.
El diagrama de componentes
Diagrama de componentes UML rinde homenaje al desarrollo de software orientado a componentes al ofrecer diagramas
de componentes. Un componente es una unidad ejecutable e independiente que proporciona
CentralData
Administración servicios a otros componentes o utiliza los 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 cualquier forma que se requiera. Al
Biblioteca
especificar un componente, puede modelar dos vistas explícitamente: la vista externa (vista de
Administración
caja negra), que representa la especificación del componente, y la vista interna (vista de caja
blanca), que de fi ne la implementación del componente. .
El diagrama de estructura de composición
Estructura de composición los diagrama de estructura de composición permite una descomposición jerárquica de las partes
diagrama del sistema. Por lo tanto, puede utilizar un diagrama de estructura de composición para describir
la estructura interna de clases o componentes en detalle. Esto le permite lograr un mayor nivel de
Red
detalle que, por ejemplo, en un diagrama de clases porque el modelado es específico del
Servidor Cliente
contexto. Puede especificar detalles de la estructura interna que sean válidos precisamente para
el contexto en consideración.
El diagrama de implementación
Diagrama de implementación La topología de hardware utilizada y el sistema de ejecución asignado se pueden representar
mediante el diagrama de despliegue. El hardware incluye unidades de procesamiento en forma de
"dispositivo"
nodos, así como relaciones de comunicación entre los nodos. Un sistema en tiempo de ejecución
Cliente
"dispositivo" contiene artefactos que se implementan en los nodos.
Servidor
www.allitebooks.com
2.3 Diagramas 19
El diagrama de per fi l
Utilizando perfiles, puede extender UML para introducir conceptos específicos de dominio. El núcleo Diagrama de per fi l
real de la definición del lenguaje de UML, el metamodelo, permanece sin cambios. De este modo,
«Metaclase»
puede reutilizar las herramientas de modelado sin tener que realizar ajustes. Por ejemplo, puede Componente
utilizar perfiles para introducir el concepto de Java Enterprise Beans.
"estereotipo"
Frijol
2.3.2 Diagramas de comportamiento
Con el diagramas de comportamiento, UML ofrece la infraestructura que le permite definir el

comportamiento en detalle.
El comportamiento se refiere a las consecuencias directas de una acción de al menos un objeto.
Afecta cómo cambian los estados de los objetos con el tiempo. El comportamiento puede
especificarse mediante las acciones de un solo objeto o resultar de interacciones entre múltiples
objetos.
El diagrama de casos de uso
UML ofrece la use el diagrama del caso para permitirle de fi nir los requisitos que debe cumplir un Use el diagrama del caso
sistema. Este diagrama describe qué usuarios utilizan qué funcionalidades del sistema, pero no (ver Capítulo 3)
aborda detalles específicos de la implementación. Las unidades de funcionalidad que el sistema Administración
proporciona a sus usuarios se denominan casos de uso. En un sistema de administración
Registro
universitaria, por ejemplo, la funcionalidad Registro sería un caso de uso utilizado por los
estudiantes. Estudiante
El diagrama de la máquina de estado
Dentro de su ciclo de vida, los objetos pasan por diferentes estados. Por ejemplo, una persona está en el estado desconectado
Diagrama de la máquina de estado
cuando visita por primera vez un sitio web. El estado cambia a conectado después de que la persona ingresó (ver el Capítulo 5)
correctamente el nombre de usuario y la contraseña (evento iniciar sesión). Tan pronto como la persona cierre la cerrar sesión
registrado registrado
sesión (evento cerrar sesión), la persona regresa al estado desconectado. Este comportamiento se puede fuera en
iniciar sesión
representar en UML usando el diagrama de la máquina de estado. Este diagrama describe el comportamiento
permisible de un objeto en forma de estados posibles y transiciones de estado desencadenadas por varios
eventos.
El diagrama de actividad
Diagrama de actividad Puede modelar procesos de cualquier tipo utilizando diagramas de actividades: tanto los procesos de negocio
(ver Capítulo 7) como los procesos de software. Por ejemplo, un diagrama de actividades puede mostrar qué acciones son
necesarias para que un estudiante participe en una conferencia y una tarea. Los diagramas de actividades
Lec.
Reg. ofrecen mecanismos de flujo de control así como mecanismos de flujo de datos que coordinan las acciones
Culo. que componen una actividad, es decir, un proceso.
El diagrama de secuencia
Diagrama de secuencia los diagrama de secuencia describe las interacciones entre objetos para realizar una tarea
(ver el Capítulo 6) específica, por ejemplo, el registro para un examen en el sistema de administración de una
:Estudiante :Sistema universidad. La atención se centra en el orden cronológico de los mensajes intercambiados entre
Registrarse
los socios de interacción. Varias construcciones para controlar el orden cronológico de los
(curso, fecha)
mensajes, así como conceptos para modularización, le permiten modelar interacciones complejas.
Registrarse:
"Okay"
El diagrama de comunicación
Diagrama de comunicación De manera similar al diagrama de secuencia, el diagrama de comunicación describe la

(ver el Capítulo 6) comunicación entre diferentes objetos. Aquí, la atención se centra en las relaciones de
:Estudiante
comunicación entre los socios de interacción más que en el orden cronológico del
intercambio de mensajes. No se dispone de estructuras de control complejas. Este diagrama
1: iniciar sesión (usuario, pw)
2: obtener cursos muestra claramente quién interactúa con quién.
:Sistema : DB
1.1: comprobar
(usuario, pw)
El diagrama de tiempos
Diagrama de tiempo los diagrama de tiempo muestra explícitamente los cambios de estado de los socios de interacción que
(ver el Capítulo 6) pueden ocurrir debido a eventos temporales o como resultado del intercambio de mensajes. Por ejemplo,
una persona está en el estado conectado tan pronto como se reciba el mensaje del sistema de administración
iniciar sesión
cerrar sesión de la universidad de que la contraseña enviada es válida.
: DB: Sistema: Estudiante
iniciar sesión
inicio de sesión: ″ ok ″
ocupado
cheque:
ocioso
cheque "Okay"
activo
2.4 Diagramas presentados en este libro 21
El diagrama de descripción general de la interacción
los diagrama de descripción general de interacción Modela la conexión entre diferentes procesos de Descripción general de la interacción
interacción estableciendo diagramas de interacción individuales (es decir, diagrama de secuencia, diagrama
(ver el Capítulo 6)
diagrama de comunicación, diagrama de tiempo y otros diagramas de descripción general de
interacción) en una secuencia causal y basada en el tiempo. También especifica las condiciones bajo registro sd
las cuales se permite que tengan lugar los procesos de interacción. Para modelar el flujo de control, se :Semental. : Sys.
reg. ()
utilizan conceptos del diagrama de actividades. Por ejemplo, un usuario del sistema de administración
reg.:″ ok ″
universitaria debe iniciar sesión primero (lo que ya representa una interacción separada con el sistema)
antes de que se le permita utilizar más funcionalidades. [más]
[autorizado]
Foro sd
2.4 Diagramas presentados en este libro
Como ya se explicó en el Capítulo 1, este libro se limita a los cinco tipos más importantes
y extendidos de diagramas UML, a saber, el diagrama de casos de uso, el diagrama de
clases (incluido el diagrama de objetos), el diagrama de máquina de estados, el
diagrama de secuencia y el diagrama de actividad. En este libro, presentamos estos
diagramas en el orden en que se utilizarían generalmente en proyectos de desarrollo de
software. Comenzamos con el diagrama de casos de uso, que especifica la funcionalidad
básica de un sistema de software. El diagrama de clases luego de fi ne qué objetos o
clases están involucrados en la realización de esta funcionalidad. El diagrama de la
máquina de estados luego define el comportamiento intraobjeto, mientras que el
diagrama de secuencia especifica el comportamiento entre objetos. Finalmente,
Capítulo 3
El diagrama de casos de uso
los use el diagrama del caso nos permite describir los posibles escenarios de uso (casos de uso) Use el diagrama del caso
para los que se desarrolla un sistema. Expresa lo que debe hacer un sistema, pero no trata ningún
detalle de realización como estructuras de datos, algoritmos, etc. Estos detalles están cubiertos por
otros diagramas como el diagrama de clases (ver Capítulo 4) o los diagramas de interacción (ver
Capítulo 6). ). El diagrama de casos de uso también modela qué usuario del sistema usa qué
funcionalidad, es decir, expresa quién trabajará realmente con el sistema que se va a construir.
los caso de uso es un concepto fundamental de muchos métodos de desarrollo orientados a

objetos. Se aplica durante todo el proceso de análisis y diseño. Los casos de uso representan lo
que el cliente quiere que haga el sistema, es decir, los requisitos del cliente del sistema. A un
nivel de abstracción muy alto, los casos de uso muestran para qué es el sistema futuro. También
se puede utilizar un diagrama de casos de uso para documentar la funcionalidad de un sistema
existente y para registrar retrospectivamente qué usuarios pueden usar qué funcionalidad.
Específicamente, podemos emplear un diagrama de casos de uso para responder las siguientes
preguntas:
1. ¿Qué se describe? ( El sistema.)

2. ¿Quién interactúa con el sistema? ( Los actores.)
3. ¿Qué pueden hacer los actores? ( Los casos de uso.)
El diagrama de casos de uso proporciona solo algunos elementos del lenguaje. A primera vista,
este diagrama parece ser extremadamente sencillo de aprender y usar. En la práctica, sin embargo, el
diagrama de casos de uso es un diagrama extremadamente subestimado. El contenido de un diagrama
de casos de uso expresa las expectativas que el cliente tiene del sistema a desarrollar. El diagrama
documenta los requisitos que el sistema debe cumplir. Esto es esencial para un diseño técnico
detallado. Si los casos de uso se olvidan o se especifican de forma imprecisa o

Computación, DOI 10.1007 / 978-3-319-12742-2_3
24 3 El diagrama de casos de uso
incorrectamente, en algunas circunstancias las consecuencias pueden ser extremadamente

graves: los costos de desarrollo y mantenimiento aumentan, los usuarios están insatisfechos, etc.
En consecuencia, el sistema se utiliza con menos éxito y las inversiones realizadas en el
desarrollo del sistema no aportan la retornos esperados. Aunque la ingeniería de software y los
métodos de análisis de requisitos no son el tema de este libro, explicamos brevemente por qué
es esencial crear casos de uso con mucho cuidado. Además, discutimos dónde se cometen a
menudo errores y cómo pueden evitarse con un enfoque sistemático. Para obtener una
introducción detallada a estos temas, consulte, por ejemplo, [3, 45].
3.1 Casos de uso
Caso de uso UN caso de uso describe la funcionalidad que se espera del sistema a desarrollar. Abarca una serie
de funciones que se ejecutan cuando se utiliza este sistema. Un caso de uso proporciona un beneficio
UN
tangible para uno o más actores que se comunican con este caso de uso. El diagrama de casos de
uso no cubre la estructura interna y la implementación real de un caso de uso. En general, un caso de
uso se desencadena por la invocación de un actor o por un acontecimiento desencadenante, en
resumen, un desencadenar. Un ejemplo de un disparador es que el semestre ha terminado y, por lo
Desencadenar tanto, el caso de uso Emitir certi fi cado debe ser ejecutado.
Los casos de uso se determinan mediante la recopilación de los deseos del cliente y el análisis de
problemas especificados en lenguaje natural cuando estos son la base para el análisis de requisitos. Sin
embargo, los casos de uso también se pueden utilizar para documentar la funcionalidad que ofrece un
sistema. Un caso de uso generalmente se representa como una elipse. El nombre del caso de uso se
especifica directamente en o directamente debajo de la elipse. Alternativamente, un caso de uso se
puede representar con un rectángulo que contiene el nombre del caso de uso en el centro y una pequeña
elipse en la esquina superior derecha. Las diferentes alternativas de notación para el caso de uso Consultar
datos de estudiantes se ilustran en
Figura 3.1 . Las alternativas son todas igualmente válidas, pero la primera alternativa, la elipse
que contiene el nombre del caso de uso, es la que se usa con más frecuencia.
Figura 3.1
Alternativas de notación para
casos de uso
Consulta Consulta
datos del estudiante datos del estudiante
Consulta
datos del estudiante
3.2 Actores 25
El conjunto de todos los casos de uso juntos describe la funcionalidad que proporciona un
sistema de software. Los casos de uso generalmente se agrupan dentro de un rectángulo. Este
rectángulo simboliza los límites del sistema para ser descrito. El ejemplo en Figura 3.2 muestra el Administración
Sistema
de estudiantes
sistema, que ofrece tres casos de uso: (1) Consultar datos de estudiantes, ( 2) Emitir certi fi cado, y (3) Anunciar
examen. Estos casos de uso pueden desencadenarse por
el actor Profesor.
Figura 3.2
Administración de estudiantes
Representación del sistema
fronteras
Consulta
Problema
certificado Profesor
Anunciar
examen
3.2 Actores
Para describir un sistema por completo, es esencial documentar no solo lo que el sistema puede
hacer, sino también quién trabaja e interactúa realmente con el sistema. En el diagrama de
casos de uso, actores siempre interactúan con el sistema en el contexto de sus casos de uso, es Actor
decir, los casos de uso con los que están asociados. El ejemplo en Figura 3.2 contiene solo el
actor
Profesor, que puede consultar datos de los estudiantes, anunciar exámenes y emitir certificados. Los actores
están representados por figuras de palitos, rectángulos (que contienen la información adicional "actor"), o por un
X
símbolo libremente definible. Las alternativas de notación se muestran en Figura 3.3 . Estas tres alternativas de
notación son todas igualmente válidas. Como podemos ver en este ejemplo, los actores pueden ser humano por
ejemplo, estudiante o profesor) o no humano por ejemplo, servidor de correo electrónico). Los símbolos
utilizados para representar a los actores en un diagrama de caso de uso específico dependen de la persona
que crea el modelo o la herramienta utilizada. Nótese en particular que los actores no humanos también
pueden ser representados como figuras de palo, incluso si esto parece contradictorio.
Figura 3.3
actores "actor"
Profesor
Estudiante
Servidor de correo electrónico
Un actor interactúa con el sistema utilizando el sistema como un activo actor, lo que
Tipos de actores: significa que el actor inicia la ejecución de casos de uso; alternativamente, la interacción
implica que el actor sea utilizado por el sistema, lo que significa que el actor es un pasivo actor
• Humano / no humano
• Activo pasivo que proporciona funcionalidad para la ejecución de casos de uso. En el ejemplo (a) en Figura
• Primario/ 3.4 , el actor
secundario Profesor es un actor activo, mientras que el actor Servidor de correo electrónico es pasivo. Sin embargo, ambos
son necesarios para la ejecución del caso de uso. Informar al alumno. Además, los diagramas de casos de uso
también pueden contener tanto primario y
secundario actores, que también se muestran en este ejemplo. Un actor principal obtiene un
beneficio real de la ejecución del caso de uso (en nuestro ejemplo, este es el Profesor), mientras que
el actor secundario Servidor de correo electrónico no recibe ningún beneficio directo de la ejecución del
caso de uso. Como podemos ver en el ejemplo (b) en Figura 3.4 , el actor secundario no tiene por
qué ser necesariamente pasivo. Ambos Profesor y el Estudiante participan activamente en la ejecución
del caso de uso Examen, donde el principal beneficiario es el
Estudiante. En contraste, el Profesor tiene un beneficio menor del examen pero es

necesario para la ejecución del caso de uso. Gráficamente, no hay diferenciación entre
actores primarios y secundarios, entre actores activos y pasivos, y entre actores
humanos y no humanos.
Figura 3.4
Administración de estudiantes Universidad
Ejemplos de actores
Profesor Informar Estudiante

Examen
estudiante
Profesor
Servidor de correo electrónico
(un) (segundo)
Un actor siempre está claramente fuera del sistema, es decir, un usuario nunca es parte del sistema
y, por lo tanto, nunca se implementa. Sin embargo, los datos sobre el usuario pueden estar disponibles
dentro del sistema y pueden ser representados, por ejemplo, por una clase en un diagrama de clases
(vea el Capítulo 4). A veces es difícil decidir si un elemento es parte del sistema que se va a
implementar.
3.3 Asociaciones 27
mentado o sirve como actor. En el ejemplo (a) en Figura 3.4 , el Servidor de correo electrónico es un actor:
no es parte del sistema, pero es necesario para la ejecución del caso de uso Informar al alumno. Sin
embargo, si no se requiere un servidor externo para ejecutar este caso de uso porque el sistema de
administración de estudiantes implementa la funcionalidad de correo electrónico por sí mismo o tiene su
propio servidor, el Servidor de correo electrónico ya no es actor. En ese caso, solo el Profesor Se requiere
informar a los estudiantes sobre diversas noticias.
3.3 Asociaciones
En los ejemplos de Figura 3.4 , conectamos a los actores con casos de uso a través de líneas
continuas sin explicar esto con más detalle. Un actor está conectado con los casos de uso a
través de asociaciones que expresan que el actor se comunica con el sistema y utiliza una Asociación
determinada funcionalidad. Cada actor debe comunicarse con al menos un caso de uso. De lo
UN
contrario, tendríamos un actor que no interactúa con el sistema. De la misma manera, cada
X
caso de uso debe estar en relación con al menos un actor. Si este no fuera el caso, habríamos
modelado una funcionalidad que no es utilizada por nadie y, por lo tanto, es irrelevante.
Una asociación es siempre binaria, lo que significa que siempre se especifica entre un caso de
uso y un actor. Se pueden especificar multiplicidades para los fines de la asociación. Si se especifica
una multiplicidad mayor que 1 para el fin de asociación del actor, esto significa que más de una
instancia de un actor está involucrada en la ejecución del caso de uso. Si miramos el ejemplo en Figura
3.5 , de uno a tres estudiantes y precisamente un asistente está involucrado en la ejecución del caso
de uso Realizar examen oral. Si no se especifica una multiplicidad para el final de la asociación del
actor, se asume que 1 es el valor predeterminado. La multiplicidad en el extremo de la asociación del
caso de uso no está restringida en su mayoría y, por lo tanto, rara vez se especifica explícitamente.
Figura 3.5
Asignación de laboratorio
Multiplicidades en
asociaciones
Conducta Asistente
examen oral
1..3
Estudiante
Papel Los actores no representan a un usuario específico, representan roles que adoptan los
usuarios. Si un usuario ha adoptado el rol respectivo, este usuario está autorizado para ejecutar
los casos de uso asociados con este rol. Los usuarios específicos pueden adoptar y dejar de lado
múltiples roles simultáneamente. Por ejemplo, una persona puede participar en el envío de una
determinada tarea como asistente y en otra tarea como estudiante. El concepto de rol también se
usa en otros tipos de diagramas UML, como el diagrama de clases (ver Capítulo 4), el diagrama
de secuencia (ver Capítulo 6) y el diagrama de actividades (ver Capítulo 7).
3.4 Relaciones entre actores
Sinónimos: Los actores a menudo tienen propiedades comunes y varios actores pueden utilizar algunos casos
de uso. Por ejemplo, es posible que no sólo los profesores sino también los asistentes (es decir,
• Generalización
• Herencia todo el personal de investigación) puedan ver los datos de los estudiantes. Para expresar esto, los
actores pueden representarse en un relación de herencia generalización) entre sí. Cuando un actor Y
Generalización para actores
(sub-actor) hereda de un actor X ( super actor), Y participa en todos los casos de uso con los que
X X esta involucrado. En términos simples, la generalización expresa una relación “es un”. Está
representado con una línea del sub-
Figura 3.6 Y
Ejemplo de generalización Administración de estudiantes
para actores
Consulta
Investigación
Asociar
Crear
curso
Problema
certificado
Profesor
0..1
Publicar
tarea
Asistente
3.4 Relaciones entre actores 29
actor al super-actor con una gran punta de flecha triangular en el extremo del super-actor. En el
ejemplo de Figura 3.6 , los actores Profesor y Asistente heredar del actor Investigador asociado, lo que
significa que cada profesor y cada asistente es un investigador asociado. Cada asociado de
investigación puede ejecutar el caso de uso Consultar datos de estudiantes. Solo los profesores
pueden crear un curso nuevo (caso de uso Crear curso); por el contrario, las tareas solo pueden ser
publicadas por asistentes (caso de uso Publicar tarea). Para ejecutar el caso de uso Emitir certi fi cado
en Figura 3.6 , un actor Profesor es requerido; además, un actor Asistente puede participar
opcionalmente, que se expresa por la multiplicidad 0..1.
Existe una gran diferencia entre dos actores que participan en un caso de uso y dos
actores que tienen un superactor común que participa en el caso de uso. En el primer caso,
ambos actores deben participar en el caso de uso (ver Figura 3.7 (a) ); en el segundo caso,
cada uno de ellos hereda la asociación. Luego, cada actor participa en el caso de uso
individualmente (ver Figura 3.7 (b) ).
Figura 3.7
Ejemplo con y sin
Administración de estudiantes Administración de estudiantes generalización
{abstracto}
Investigación
Profesor Consulta
Asociar
Consulta
datos del estudiante datos del estudiante
Asistente
Asistente de profesor
(un) (segundo)
Si no hay una instancia de un actor, este actor se puede etiquetar con la palabra clave { abstracto}.
Actor abstracto
Alternativamente, los nombres de los actores abstractos se pueden representar en cursiva. El actor Investigador
asociado en Figura 3.7 (b)
es un ejemplo de actor abstracto. Se requiere expresar que una

Profesor o un Asistente está involucrado en el caso de uso Consultar datos de estudiantes.
El uso de actores abstractos sólo tiene sentido en el contexto de una relación de

herencia: las propiedades comunes de los sub-actores se agrupan y describen en un
punto, a saber, con el super-actor abstracto común.
La generalización es un concepto fundamental de la orientación a objetos y se puede aplicar a muchos
elementos diferentes del lenguaje de UML. Para obtener una introducción más detallada a la generalización,
consulte el Capítulo 4.
www.allitebooks.com
3.5 Relaciones entre casos de uso
Hasta este punto, sólo hemos aprendido sobre las relaciones entre casos de uso y actores
(asociaciones) y entre los propios actores (generalización de actores). Los casos de uso
también pueden estar en relación con otros casos de uso. Aquí diferenciamos entre "incluir" relaciones,
"ampliar"
relaciones y generalizaciones de casos de uso.
Figura 3.8
Ejemplo de "incluir" y
"ampliar"
reserva
sala de conferencias
r"
plia
"am
Anunciar
conferencia "inc
luir"
Profesor
Asignar
conferenciante
"incluir" Si un caso de uso UN incluye un caso de uso SI, representado como una flecha discontinua de UN a segundo
etiquetado con la palabra clave "incluir", el comportamiento de segundo está integrado en el
UN
comportamiento de A. Aquí, UN se conoce como el caso de uso base y segundo como el caso de uso
"in
clu
incluido. El caso de uso base siempre requiere el comportamiento del caso de uso incluido para poder
ir"
ofrecer su funcionalidad. Por el contrario, el caso de uso incluido se puede ejecutar por sí solo. El uso de "incluir"
segundo
es análogo a llamar a una subrutina en un lenguaje de programación procedimental. En el diagrama de
casos de uso en Figura 3.8 , el uso
casos Anunciar conferencia y Asignar profesor están en un "incluir" relación-

barco, por el cual Anunciar conferencia es el caso de uso base. Por lo tanto, siempre que se anuncie una
nueva conferencia, el caso de uso Asignar profesor también debe ejecutarse. El actor Profesor participa en
la ejecución de ambos casos de uso. También se pueden asignar más conferenciantes a una
conferencia existente, ya que el caso de uso incluido se puede ejecutar independientemente del caso de
uso base. Un caso de uso puede incluir varios otros casos de uso. Un caso de uso también puede
incluirse en varios casos de uso diferentes. En tales situaciones, es importante asegurarse de que no
surja ningún ciclo.
Si un caso de uso segundo está en un "ampliar" relación con un caso de uso UNA, luego
UN puede usar el comportamiento de segundo pero no tiene que hacerlo. Caso de uso segundo por lo tanto, puede ser
activado por UN para insertar el comportamiento de segundo en A. Aquí,

3.5 Relaciones entre casos de uso 31
UN es nuevamente referido como el caso de uso base y segundo como el extender el caso de uso. Un "ampliar"
La relación se muestra con una flecha discontinua del caso de uso extendido. segundo al caso de uso "ampliar"
base A. Ambos casos de uso también se pueden ejecutar de forma independiente. Si miramos el ejemplo
UN
en Higo-
"a
ura 3.8 , los dos casos de uso Anunciar conferencia y Reserva de sala de conferencias son
m
pli
ar
en un "ampliar" relación. Cuando se anuncia una nueva conferencia, es posible (pero no obligatorio)
"
reservar una sala de conferencias. Un caso de uso puede actuar como un caso de uso extendido segundo
varias veces o puede ser extendido por varios casos de uso. Nuevamente, no pueden surgir ciclos.
Tenga en cuenta que la flecha que indica un "ampliar" La relación apunta hacia el caso de uso base,
mientras que la flecha que indica un "incluir" La relación se origina en el caso de uso base y apunta
hacia el caso de uso incluido.
UN condición que debe cumplirse para que el caso de uso base inserte el comportamiento del Condición
caso de uso extendido se puede especificar para cada "ampliar"
relación. La condición se especifica, entre corchetes, en una nota que está conectada con el
correspondiente "ampliar" relación. Una condición está indicada por la palabra clave anterior Condición
seguido de dos puntos. Se muestran dos ejemplos en Figura 3.9 . Dentro del contexto del caso
de uso Anunciar conferencia, una sala de conferencias solo se puede reservar si es gratuita.
Además, solo se puede crear un examen si se han introducido los datos necesarios.
Mediante el uso puntos de extensión, puede definir el punto en el que se debe insertar el Punto de extensión
comportamiento de los casos de uso extendidos en el caso de uso base. Los puntos de extensión se
escriben directamente dentro del caso de uso, como se ilustra en el caso de uso. Anunciar conferencia en
el ejemplo en Figura 3.9 . Dentro del símbolo del caso de uso, los puntos de extensión tienen una
sección separada
Figura 3.9
Ejemplo de extensión
puntos y condiciones
Condición:
{Sala de conferencias gratis}
Punto de extensión:
Seleccionar sala de conferencias reserva
sala de conferencias
r»
plia
Anunciar conferencia
« am
puntos de extensión:
Entrar al examen
Seleccionar sala de conferencias « am
plia
r » Profesor
Anunciar
Condición: examen
{Datos ingresados}
Punto de extensión:
Entrar al examen
ción que se identifica por la palabra clave puntos de extensión. Si un caso de uso tiene varios puntos
de extensión, estos se pueden asignar al correspondiente
"ampliar" relación a través de la especificación en una nota de forma similar a una condición.
Generalización de uso Al igual que para los actores, generalización también es posible entre casos de uso. Por lo tanto, las
casos propiedades comunes y el comportamiento común de diferentes casos de uso se pueden agrupar en un caso de
UN uso principal. Si un caso de uso UN generaliza un caso de uso B, B hereda el comportamiento de UNA, cuales segundo
puede extender o sobrescribir. Luego, segundo también hereda todas las relaciones de A. Por lo tanto, segundo
adopta la funcionalidad básica de UN pero decide por sí mismo qué parte de UN se ejecuta o cambia. Si
segundo
un caso de uso tiene la etiqueta { abstracto}, no se puede ejecutar directamente; sólo los casos de uso
específicos que heredan del caso de uso abstracto son ejecutables.
El diagrama de casos de uso en Figura 3.10 muestra un ejemplo de la generalización de casos de

uso. El caso de uso abstracto Anunciar evento pasa sus propiedades y comportamiento a los casos de
uso Anunciar conferencia y Anunciar charla. Como resultado de una "incluir" relación, ambos casos de uso
deben ejecutar el comportamiento del caso de uso Asignar profesor. Cuando se anuncia una
conferencia, también se puede anunciar un examen al mismo tiempo. Ambos casos de uso heredan la
relación del caso de uso Anunciar evento al actor Profesor. Por lo tanto, todos los casos de uso están
conectados a al menos un actor, el requisito previo estipulado anteriormente para diagramas de casos
de uso correctos.
Figura 3.10
Ejemplo de generalización
de casos de uso
Asignar
conferenciante
luir"
"inc
{abstracto}
Anunciar
evento
Profesor
Anunciar
examen
r"
ia
pl
m
"a
Anunciar Anunciar
hablar conferencia
3.6 Ejemplos de relaciones 33
La generalización nos permite agrupar las características comunes de los dos casos de
uso Anunciar conferencia y Anunciar charla. Esto significa que no tenemos que modelar tanto el "incluir"
relación y la asociación con el profesor dos veces.
3.6 Ejemplos de relaciones
Para explicar de nuevo explícitamente cómo los diferentes tipos de relaciones en un diagrama de casos
de uso interactúan entre sí, echemos un vistazo al diagrama de casos de uso de Figura 3.11 y discutir
algunos casos interesantes que ocurren aquí.
Figura 3.11
S
Ejemplos de relaciones
en un diagrama de caso de uso
"ampliar"
J segundo C
L
H
mi F
"in
clu
ir"
O
UN
" GRAMO
luir
"inc pli ar"
"am norte
re yo
METRO
• El caso de uso UN incluye los casos de uso mi y RE. Un actor O participa en los tres casos de
uso. No hay especi fi cación de si se trata del mismo usuario o de usuarios diferentes, es decir,
diferentes instancias de O.
• El caso de uso H hereda del caso de uso C. Como caso de uso C es ejecutado por el actor L, un
actor L también debe participar en la ejecución de H.
Los actores norte y METRO heredar de L. Por tanto, ambos casos de uso C y
H también puede ser ejecutado por un actor METRO o NORTE.
• El caso de uso J hereda del caso de uso SI. Como resultado de la relación de herencia, un
actor O está involucrado en la ejecución del caso de uso
J. Sin embargo, una asociación con O también está modelado para J directamente. La consecuencia de
esto es que dos actores en el rol O están involucrados en la ejecución de J. Tenga en cuenta que estos
dos actores pueden coincidir.
• El caso de uso F hereda del caso de uso GRAMO. Como resultado de la relación de herencia, un
actor norte está involucrado en la ejecución del caso de uso F. por F, una asociación con el actor L también
se modela directamente. Por tanto, un actor norte y, debido a la relación de herencia de los actores
L, N, y METRO, ya sea un actor L o un actor METRO o un actor adicional norte está involucrado en la
ejecución de F. Si dos actores norte están involucrados, pueden coincidir.
• El caso de uso yo extiende el caso de uso F. Como caso de uso F hereda del caso de uso GRAMO y como yo extiende
el caso de uso GRAMO, esta relación se transmite a F.
Si GRAMO y yo estaban en un "incluir" relación, esta relación también se pasaría a F del

mismo modo.
• El caso de uso J extiende el caso de uso H. Esto es como resultado de las relaciones de
herencia de segundo a J y de C a H.
3.7 Creación de un diagrama de casos de uso
Entonces, ¿cómo se crea un diagrama de casos de uso? Primero debe identificar los actores y los
casos de uso y luego ponerlos en relación entre sí. Luego, describe los casos de uso en detalle. A
primera vista, este diagrama parece simple debido al bajo número de conceptos involucrados. Pero,
de hecho, los diagramas de casos de uso a menudo se crean incorrectamente con muchos errores.
Por lo tanto, aquí echamos un vistazo breve a los principios de creación de casos de uso. Para
obtener más información, consulte la extensa literatura sobre ingeniería de requisitos, por ejemplo [16,
30, 40]. Luego explicamos algunos errores típicos que deben evitarse al modelar diagramas de casos
de uso.
3.7.1 Identificación de actores y casos de uso
Según [30], hay dos formas de identificar casos de uso para el diseño de sistemas
prospectivos:
1. Análisis de los documentos de requisitos

2. Análisis de las expectativas de los futuros usuarios
Los documentos de requisitos son generalmente especificaciones en lenguaje natural que explican
lo que el cliente espera de un sistema. Deberían documentar
3.7 Creación de un diagrama de casos de uso 35
Indique con relativa precisión quién utilizará el sistema y cómo lo utilizará. Si sigue el segundo
enfoque para encontrar casos de uso, primero debe identificar a los futuros usuarios, es decir,
los actores. Para identificar los actores que aparecen en un diagrama de casos de uso, debe
responder las siguientes preguntas:
• ¿Quién usa los principales casos de uso? Preguntas para identificar

• ¿Quién necesita apoyo para su trabajo diario? actores
• ¿Quién es responsable de la administración del sistema?
• ¿Cuáles son los dispositivos / sistemas (software) externos con los que debe comunicarse el
sistema?
• ¿Quién tiene interés en los resultados del sistema?
Una vez que conozca a los actores, puede derivar los casos de uso haciendo las siguientes
preguntas sobre los actores [27]:
• ¿Cuáles son las principales tareas que debe realizar un actor? Preguntas para identificar
• ¿Un actor quiere consultar o incluso modificar la información contenida en el sistema? casos de uso
• ¿Quiere un actor informar al sistema sobre cambios en otros sistemas?
• ¿Se debe informar a un actor sobre eventos inesperados dentro del sistema?
En muchos casos, modela los casos de uso de forma iterativa e incremental. Al hacerlo, a Iterativo e incremental
menudo comienza con los requisitos de "nivel superior" que reflejan los objetivos comerciales que determinación de uso
deben perseguirse con el software. Luego continúe refinándolos hasta que, a nivel técnico, haya casos
especificado lo que el sistema debería poder hacer. Por ejemplo, un requisito de "nivel superior"
para un sistema de administración universitaria podría ser que el sistema se pueda utilizar para la
administración de estudiantes. Si afinamos este requisito, definimos que los nuevos estudiantes
deben poder matricularse en la universidad y matricularse en estudios, que se deben almacenar las
calificaciones de los estudiantes de diferentes cursos, etc.
3.7.2 Descripción de casos de uso
Para garantizar que incluso los diagramas de casos de uso grandes permanezcan claros, es
extremadamente importante seleccionar nombres breves y concisos para los casos de uso. Cuando
surgen situaciones en las que la intención detrás del caso de uso y su interpretación no están claras,
también debe describir los casos de uso. Una vez más, es importante asegurarse de describir los casos
de uso de manera clara y concisa, ya que de lo contrario existe el riesgo de que los lectores solo lean el
documento.
Enfoque estructurado de Una pauta generalmente reconocida para la longitud de las descripciones de casos de uso es
describiendo casos de uso aprox. 1-2 páginas por caso de uso. En [15], Alistair Cockburn presenta un enfoque estructurado
para la descripción de casos de uso que contiene la siguiente información:
• Nombre
• Breve descripción
• Condición previa: condición previa para una ejecución exitosa Condición posterior:
• estado del sistema después de una ejecución exitosa Situaciones de error: errores
• relacionados con el dominio del problema Estado del sistema en caso de error
•
• Actores que se comunican con el caso de uso Desencadenador:
• eventos que inician / inician el caso de uso Proceso estándar:
• pasos individuales a seguir
• Procesos alternativos: desviaciones del proceso estándar
Cuadro 3.1 Nombre: Reserva de sala de conferencias

Descripción de caso de uso para Breve descripción: Un empleado reserva una sala de conferencias en la universidad para un evento.
Reserva de sala de conferencias
Condición previa: El empleado está autorizado a reservar salas de conferencias. El

empleado está conectado al sistema.
Postcondición: Se reserva una sala de conferencias. No hay
Situaciones de error: sala de conferencias gratuita.
Estado del sistema en el evento El empleado no ha reservado una sala de conferencias. de un error:
Actores: Empleado
Desencadenar: El empleado requiere una sala de conferencias.
Proceso estándar: (1) El empleado selecciona la sala de conferencias. (2) El
empleado selecciona la fecha.
(3) El sistema con fi rma que la sala de conferencias es libre. (4) El
empleado con fi rma la reserva. (3 ') La sala de conferencias no es
Procesos alternativos: gratuita.
(4 ') El sistema propone una sala de conferencias alternativa.
(5 ') El empleado selecciona la sala de conferencias alternativa y confirma

la reserva.
Cuadro 3.1 contiene la descripción del caso de uso Reserva de sala de conferencias
en un sistema de administración de estudiantes. La descripción es extremadamente simple pero

totalmente suficiente para nuestros propósitos. El proceso estándar y el proceso alternativo se
podrían perfeccionar más o se podrían considerar otras situaciones de error y procesos
alternativos. Por ejemplo, podría ser posible reservar una sala de conferencias donde ya se está
llevando a cabo un evento; esto tiene sentido si el evento es un examen que podría realizarse en
la sala de conferencias junto con otro examen, lo que significa que hay menos supervisores de
exámenes. necesario. En un proyecto real, los detalles provendrían de los requisitos y deseos de
los clientes.
3.7.3 Escollos
Desafortunadamente, a menudo se cometen errores al crear diagramas de casos de uso. A continuación se
analizan seis ejemplos de tipos típicos de errores. Para un tratamiento más detallado de este tema, consulte
[39].
Error 1: procesos de modelado
Incluso si a menudo es muy tentador modelar procesos (comerciales) completos o flujos de trabajo en un
diagrama de casos de uso, este es un uso incorrecto del diagrama. Supongamos que estamos
modelando el sistema Oficina de estudiantes ( consulte el ejemplo final de este capítulo en la página 42). Si
un estudiante usa la función Recopilar certificado, Primero se debe notificar al estudiante que el certificado
está listo para ser recogido en la oficina del estudiante. Naturalmente, el profesor debe haber enviado el
certificado a la oficina de estudiantes, es decir, se ha emitido el certificado.
Los casos de uso Recopile el certificado, envíe la notificación, y Emitir certi fi cado
pueden estar conectados cronológicamente, pero esto no debe representarse en un diagrama de
casos de uso. Por tanto, es incorrecto relacionar estos casos de uso entre sí utilizando "incluir" o "ampliar"
relaciones como se muestra en
Figura 3.12 . La funcionalidad que ofrece uno de estos casos de uso no es parte de la
funcionalidad que ofrece otro caso de uso, por lo tanto, los casos de uso deben usarse de forma
independiente entre sí.
Figura 3.12
Extracto incorrecto de un diagrama de
caso de uso: modelado
procesos
Recoger "incluir" Enviar "incluir" Problema

certificado notificación certificado
Error 2: establecer límites del sistema incorrectamente
Al modelar un diagrama de casos de uso, debe considerar con mucho cuidado dónde
dibujar los límites del diagrama. Como ya se mencionó, esto a menudo no está claro. Los
actores siempre están fuera de los límites del sistema: si van a estar ubicados dentro del
sistema, son parte del sistema y por lo tanto no debe ser modelados como actores. En Figura
3.13 , el
Empleado se representa dentro de los límites del sistema Administración de estudiantes. Por supuesto, el
sistema de administración de estudiantes incluye empleados. Sin embargo, como queremos crear un
diagrama de casos de uso de este sistema,
debemos considerar si queremos ver a estos empleados como actores o como parte del
sistema de administración de estudiantes. Si son parte del sistema, no deben modelarse
como actores. En ese caso, alguna otra entidad fuera del sistema debería ser un actor. Si
no son parte del sistema pero son necesarios para la ejecución de los casos de uso, deben
representarse como actores, fuera de los límites del sistema.
Figura 3.13
casos de uso: incorrecto
límites del sistema Administración de estudiantes
Problema
información
Empleado Estudiante
Error 3: mezcla de niveles de abstracción
Al identificar los casos de uso, siempre debe asegurarse de que estén ubicados en el mismo nivel
de abstracción. Evite representar casos de uso de "nivel superior" con casos de uso orientados
técnicamente en el mismo diagrama, como es el caso en Figura 3.14 . En este ejemplo, la gestión de
los datos de los estudiantes y la selección de una impresora, que es una característica técnica del
sistema, se muestran juntas. Para evitar este tipo de error, debería proceder de forma iterativa.
Primero, cree un diagrama de casos de uso con casos de uso que se basen en los objetivos
comerciales (en nuestro ejemplo, la gestión de datos de los estudiantes). Luego, refine estos casos
de uso hasta los requisitos técnicos (selección de una impresora).
Figura 3.14
Administración de estudiantes Extracto incorrecto de un diagrama de
caso de uso: mezcla de niveles de
abstracción
Gestionar
Empleado
Seleccionar impresora
Error 4: descomposición funcional
Los casos de uso, incluso los casos de uso incluidos o ampliados, siempre se pueden ejecutar
de forma independiente. Si solo pueden ejecutarse dentro del alcance de otro caso de uso y no
de forma independiente, no son casos de uso y no deben representarse como tales. Su
funcionalidad debe cubrirse luego en la descripción del caso de uso que los usa. En Figura 3.15
(a) , el caso de uso Emitir certi fi cado se divide en las subfunciones individuales necesarias para
ejecutar el caso de uso. Estas subfunciones se modelan como casos de uso, aunque a veces
no son casos de uso independientes significativos, como Introducir datos.
El caso de uso Iniciar sesión tampoco es una funcionalidad que forme parte de Emitir certi fi cado. De
hecho, es una condición previa que el usuario debe iniciar sesión con autorizaciones suficientes para
poder ejecutar este caso de uso. Por lo tanto, un diagrama de casos de uso reducido, como se
muestra en Figura 3.15 (b) , es suficiente. La otra información especificada en Figura 3.15 (a) debe
especificarse en la descripción del caso de uso.
Error 5: asociaciones incorrectas
Si un caso de uso está asociado con dos actores, esto no significa que uno u otro actor esté
involucrado en la ejecución del caso de uso: significa que ambos son necesarios para su
ejecución. En el diagrama de casos de uso en Figura 3.16 (a) , los actores Asistente y Profesor están
involucrados en la ejecución del caso de uso Emitir información, cuál no es la intención. Para
resolver este problema, podemos introducir un nuevo actor abstracto Investigador asociado de
donde los dos actores Asistente y Profesor heredar. El actor Empleado ahora está conectado con
el caso de uso Información del problema ( ver
Figura 3.16 (b) ).
www.allitebooks.com
Figura 3.15
caso de uso: funcional
descomposición
Iniciar sesión
Introducir datos
luir"
"
"inc
luir
"inc
Problema "incluir"
Enviar datos
certificado
"inc
luir
Conferenciante "
Cerrar sesión
(un)
Problema
certificado
Conferenciante
(segundo)
Error 6: Modelado de casos de uso redundantes
Al modelar casos de uso, es muy tentador crear un caso de uso separado para cada situación
posible. Por ejemplo, en el diagrama de casos de uso en
Figura 3.17 (a) , hemos modelado casos de uso separados para crear, actualizar y eliminar cursos.
Muestra las diferentes opciones disponibles para editar un curso en el sistema. En un diagrama de
caso de uso tan pequeño como el que se muestra en Figura 3.17 (a) , no es un problema mostrar
las diferenciaciones a un nivel tan detallado.
Figura 3.16
Administración de estudiantes Administración de estudiantes
casos de uso: incorrecto
asociaciones
Gestionar Problema
datos del estudiante información
{abstracto}
Investigador asociado
Asistente
Problema
Crear curso
información
Profesor Profesor
Gestionar
Crear curso
Asistente
(un) (segundo)
Sin embargo, al modelar una aplicación real, el diagrama rápidamente se volvería

inmanejable. Para contrarrestar esto, podría tener sentido agrupar casos de uso que
tengan el mismo objetivo, es decir, la gestión de un curso. Esto se re fl eja en Figura 3.17
(b) . Los pasos individuales se especifican luego en la descripción del proceso estándar.
Figura 3.17
Administración de estudiantes Administración de estudiantes
Modelado de uso redundante
casos
Crear
curso
Actualizar Gestionar
curso curso
Investigación Investigación
Asociar Asociar
Eliminar
curso
(un) (segundo)
3.7.4 Un ejemplo final
Para concluir este capítulo, creamos un diagrama de casos de uso que describe la funcionalidad del
Sistema de información de sistema de información de una oficina de estudiantes de acuerdo con la siguiente especificación:
la oficina de estudiante de un
Universidad
• Muchas actividades administrativas importantes de una universidad son procesadas por la oficina
de estudiantes. Los estudiantes pueden registrarse para estudiar (matriculación), matricularse y
retirarse de los estudios aquí. La matriculación implica matricularse, es decir, matricularse en
estudios.
• Los estudiantes reciben sus certi fi cados de la oficina de estudiantes. Los certi fi cados los imprime
un empleado. Los profesores envían información sobre las calificaciones a la oficina de
estudiantes. El sistema de notificación informa automáticamente a los estudiantes que se ha
emitido un certificado.
• Hay una diferenciación entre dos tipos de empleados en la oficina de estudiantes: a) aquellos
que se ocupan exclusivamente de la administración de datos de estudiantes (empleado de
servicio, o ServEmp), y b) aquellos que cumplen con las tareas restantes (empleado de
administración, o AdminEmp), mientras que todos los empleados ( ServEmp y AdminEmp) puede
emitir información.
• Los empleados de la administración emiten certificados cuando los estudiantes vienen a recogerlos.
Los empleados de la administración también crean cursos. Al crear cursos, pueden reservar salas
de conferencias.
Para crear un diagrama de casos de uso a partir de esta especificación simplificada,

primero identificamos a los actores y sus relaciones entre sí. Luego determinamos los casos
de uso y sus relaciones entre sí. Finalmente, asociamos a los actores con sus casos de uso.
1. Identificación de actores
Si miramos la especificación textual, podemos identificar cinco actores potenciales: Profesor,

Estudiante, empleados de los tipos ServEmp y AdminEmp, así como el Sistema de noti fi cación. Dado
que ambos tipos de empleados demuestran un comportamiento común, es decir, la emisión

de información, tiene sentido presentar un super-actor común StudOf fi ceEmp a partir del cual ServEmp
y AdminEmp heredar. Asumimos que el Sistema de noti fi cación no es parte de la oficina de
estudiantes, por eso lo incluimos en la lista de actores. Figura 3.18 resume los actores en
nuestro ejemplo.
Figura 3.18
Actores identificados
Conferenciante Estudiante StudOfficeEmp
"actor"
Sistema de notificación
ServEmp AdminEmp
2. Identificación de casos de uso
En el siguiente paso, identificamos los casos de uso (consulte Figura 3.19 ). Al hacerlo, determinamos
qué funcionalidades debe cumplir la oficina de estudiantes.
Figura 3.19
Oficina de estudiantes
Casos de uso identificados
Problema
información
{abstracto}
Administrar estudiante Registrarse
datos
ir"
clu
"in
Retirar Inscribirse
Impresión
certificado
Crear
curso
"a
m
pli
ar
"
Enviar reserva
certificado sala de conferencias
La especificación es muy corta. Sin embargo, sabemos que el objetivo es modelar el sistema de
información que respalda a los empleados de una oficina de estudiantes en lugar de modelar las
funcionalidades que la oficina de estudiantes proporciona a los estudiantes. Si tuviéramos que
modelar este último, necesitaríamos un caso de uso Recopilar certificado, por ejemplo, en el que estaría
involucrado un estudiante. Este caso de uso no está incluido en el sistema de información ya que no
está relacionado con la recolección de los certi fi cados. El caso de uso Certificado de impresión es, sin
embargo. Para imprimir, naturalmente, necesitamos una impresora. ¿Deberíamos agregar esto a
nuestra lista de actores? No hacemos esto porque consideramos que la impresora es una parte
integral del sistema a modelar.
También tenemos las funciones Registrarse, inscribirse, y Retirar. Podríamos agruparlos en un

caso de uso Gestionar datos de estudiantes ya que todos son realizados por un actor ServEmp.
Sin embargo, al hacerlo, perderíamos la información de que la matriculación incluye la
inscripción para estudios. Por lo tanto, no reducimos los tres casos de uso a un caso de
uso. Expresamos la relación entre Registrarse y Inscribirse con un "incluir"
relación. Como los tres casos de uso tienen la asociación de ServEmp

en común, todavía presentamos el caso de uso Gestionar datos de estudiantes y modelar que los casos
de uso Registrarse, inscribirse, y Retirar heredar de este caso de uso. Para expresar que este caso de
uso no puede instanciarse, lo definimos como un caso de uso abstracto.
Los profesores pueden ejecutar el caso de uso Envíe el certi fi cado. Si se envía un certi fi cado a la oficina
del estudiante, se notifica al estudiante afectado. Sin embargo, no modelamos un caso de uso separado Notificar
al estudiante ya que, de acuerdo con la especificación anterior, los estudiantes solo son notificados en el
contexto del caso de uso Envíe el certi fi cado. Si Notificar al estudiante no se puede ejecutar de forma
independiente, esta actividad no es un caso de uso del sistema de información. Además, tenemos los
casos de uso Información de la emisión, conferencia de reserva
salón, y Crear curso, dónde Reserva de sala de conferencias extiende el uso
caso Crear curso. Figura 3.19 muestra los casos de uso resultantes.
3. Identificación de asociaciones
Ahora tenemos que asociar nuestros actores y los casos de uso (ver Figura 3.20 ). Tenga en
cuenta que ahora tenemos dos actores menos que los candidatos potenciales identi fi cados (ver Figura
3.18 ). Ya no hay estudiantes; los estudiantes no pueden usar el sistema de información en la
forma en que lo hemos modelado. Y ya no existe un sistema de notificación ya que se considera
que es parte de la oficina de estudiantes.
Finalmente, necesitamos una descripción significativa de los casos de uso.

Figura 3.20
Oficina de estudiantes
Diagrama de casos de uso del
sistema de información de
Problema la oficina de estudiantes de una
información universidad
StudOfficeEmp
{abstracto}
Administrar estudiante Registrarse
datos
ir"
clu
"in
ServEmp
Retirar Inscribirse
Impresión
certificado
Crear
curso
AdminEmp "a
m
pli
ar
"
Enviar reserva
certificado sala de conferencias
Conferenciante
4. Describiendo los casos de uso
Cuadro 3.2 muestra la descripción del caso de uso Certificado de impresión como ejemplo.
Cuadro 3.2 Nombre: Certificado de impresión

Descripción de caso de uso para Breve descripción: A pedido de un estudiante, un empleado imprime el certificado del estudiante para
Certificado de impresión un curso en papel.
Condición previa: Se han enviado todos los datos relevantes para el certi fi cado y se ha calificado al
estudiante.
Postcondición: El certificado está disponible para el estudiante en forma impresa. La impresora
Situaciones de error: no funciona.
El estado del sistema en el certificado no se imprime. caso de un

error:
Actores: AdminEmp
Desencadenar: El estudiante solicita un certificado impreso.
Proceso estándar: (1) El estudiante ingresa a la oficina del estudiante y solicita un certificado. (2) AdminEmp
ingresa el número de matrícula del estudiante. (3) AdminEmp selecciona el certi fi cado.
(4) AdminEmp ingresa el comando de impresión.
(5) El sistema confirma que el certificado se imprimió. (6) El certificado se

entrega al estudiante. (1 ') El estudiante solicita el certificado por correo
Alternativa electrónico. (2-5) Como arriba
procesos:
(6 ') El certificado se envía por correo.
3.8 Resumen
El diagrama de casos de uso describe el comportamiento de un sistema desde la vista del usuario.
Esto significa que este diagrama presenta las funcionalidades que ofrece el sistema pero no
aborda los detalles de implementación interna. Los límites del sistema (¿qué puede hacer el
sistema y qué no puede hacer?) Están claramente definidos. Los usuarios (actores) siempre están
fuera del sistema y utilizan las funcionalidades del sistema, que se describen en forma de casos
de uso. La relación entre un caso de uso y un actor se conoce como asociación. Para mantener
los diagramas de casos de uso lo más compactos posible, se admite la generalización tanto para
los actores como para los casos de uso, lo que permite la extracción de propiedades comunes.
Los casos de uso también pueden acceder a la funcionalidad proporcionada por otros casos de
uso mediante "incluir" y "ampliar" relaciones. Los elementos de notación más importantes se
resumen en Cuadro 3.3 .
3.8 Resumen 47
Cuadro 3.3
Nombre Notación Descripción
Elementos de notación para el diagrama
Sistema de casos de uso
Límites entre el sistema y los usuarios del

Sistema UN
sistema
X
Caso de uso UN Unidad de funcionalidad del sistema
"actor"
Actor o Rol de los usuarios del sistema
X
X
UN
Asociación X participa en la ejecución de UN
X
UN
Generalización segundo hereda todas las propiedades y todo el
(caso de uso) comportamiento de UN
segundo
X
Generalización Y hereda de X; Y participa en todos los casos de
(actor) uso en los que X participa
UN
"a
m
segundo extiende UN: incorporación opcional de caso de

pli
Extender la relación
ar
uso segundo en caso de uso UN

"
segundo
UN
"in
clu
UN incluye SEGUNDO: incorporación requerida del caso de

ir"
Incluir relación
uso segundo en caso de uso UN
segundo
Capítulo 4
El diagrama de clases
Usamos el diagrama de clase para modelar la estructura estática de un sistema, describiendo Diagrama de clase
así los elementos del sistema y las relaciones entre ellos. Estos elementos y las relaciones
entre ellos no cambian con el tiempo. Por ejemplo, los estudiantes tienen un nombre y un
número de matrícula y asisten a varios cursos. Esta sentencia cubre una pequeña parte de la
estructura universitaria y no pierde validez ni siquiera durante años. Son sólo los estudiantes
y cursos específicos los que cambian.
El diagrama de clases es sin duda el diagrama UML más utilizado. Se aplica en

varias fases del proceso de desarrollo de software. El nivel de detalle o abstracción del
diagrama de clases es diferente en cada fase. En las primeras fases del proyecto, un
diagrama de clases le permite crear una vista conceptual del sistema y de fi nir el
vocabulario que se utilizará. Luego puede refinar este vocabulario en un lenguaje de
programación hasta el punto de implementación. En el contexto de la programación
orientada a objetos, el diagrama de clases visualiza las clases de las que consta un
sistema de software y las relaciones entre estas clases. Debido a su simplicidad y
popularidad, el diagrama de clases es ideal para bocetos rápidos. Sin embargo, también
puede utilizarlo para generar código de programa automáticamente. En la práctica,
Antes de presentar los conceptos del diagrama de clases, primero echemos un vistazo a objetos, que
se modelan en diagramas de objetos. Los diagramas de objetos le permiten representar objetos Diagrama de objetos
concretos que aparecen en un sistema en un momento específico. Las clases proporcionan

esquemas para caracterizar objetos y los objetos son instancias de clases. El diagrama de objetos
visualiza instancias de clases que se modelan en un diagrama de clases.

Computación, DOI 10.1007 / 978-3-319-12742-2_4
50 4 El diagrama de clases
4.1 Objetos
Un sistema contiene numerosos individuos diferentes. Los individuos pueden ser no sólo personas,
sino también animales, plantas, objetos inanimados, artefactos, etc. que pueden identificarse de
forma única. Por ejemplo, como parte de ella Estudios de TI programa, Helen Lewis asiste a la
conferencia Modelado orientado a objetos (OOM) en la Universidad. Helen Lewis, Estudios de TI, y Modelado
orientado a objetos son individuos (objetos concretos) en un sistema de administración universitaria
y están en relación unos con otros.
Figura 4.1
Ejemplo de diagrama de un helenLewis: Estudiante oom: curso
objeto
firstName = "Helen" nombre = "OOM"
lastName = "Lewis" semester = "Verano"
dob = 04-02-1980 horas = 2.0
matNo = "9824321"
mikeFox: Estudiante iprog: curso lh1: LectureHall
firstName = "Mike" nombre = "IPROG" nombre = "LH1"

lastName = "Fox" semester = "Invierno" asientos = 400
dob = 02-01-1988 horas = 4.0
matNo = "0824211"
paulSchubert: Estudiante db: curso lh2: LectureHall
firstName = "Paul" name = "Bases de datos" nombre = "LH2"

lastName = "Schubert" semester = "Verano" asientos = 100
dob = 11-04-1984 horas = 2.0
matNo = "0323123"
En UML, representamos concreto objetos de un sistema y sus relaciones ( Enlaces) utilizando diagramas
Diagrama de objetos de objetos. Figura 4.1 muestra un pequeño diagrama de objetos. Contiene tres objetos de
estudiante: helenLewis, mikeFox, y
paulSchubert. El primer nombre y apellido del objeto. helen Lewis
son Helena y Luis respectivamente. También conocemos la fecha de nacimiento y el número de
matrícula de cada uno de estos objetos. El sistema contiene los tres cursos oom Modelado
orientado a objetos), iprog Introducción a la programación) y db Bases de datos). El curso iprog tiene
lugar en la sala de conferencias lh1 y el curso db tiene lugar en la sala de conferencias lh2. No hay
información correspondiente para oom. Estudiante helen Lewis asiste a los dos cursos oom y iprog. Estudiante
mikeFox también asiste iprog; curso
db es atendido solo por estudiante paulSchubert ( al menos, entre estos tres estudiantes).
www.allitebooks.com
4.1 Objetos 51
Un objeto tiene una identidad única y una serie de características que lo describen con más Objeto
detalle. Rara vez aparece de forma aislada en un sistema; en cambio, generalmente interactúa y
jefe
se comunica con otros objetos. Las relaciones entre los objetos se denominan Enlaces. Las
características de un objeto incluyen su Características estructurales ( atributos) y sus comportamiento Enlace
en forma de operaciones). Si bien se asignan valores concretos a los atributos en el diagrama de
o1 o2
objetos, las operaciones generalmente no se representan. Las operaciones son idénticas para
todos los objetos de una clase y, por lo tanto, generalmente se describen exclusivamente para la
clase.
En el diagrama de objetos, un objeto se muestra como un rectángulo que se puede

subdividir en varios compartimentos. El primer compartimento siempre contiene información en
el formulario objectName: Clase. Esta información está centrada y subrayada. En Figura 4.1 por
ejemplo, helen Lewis y oom
son nombres de objeto y Estudiante y Curso son clases. El nombre del objeto o la especificación
de la clase pueden omitirse. Si solo se proporciona un nombre de clase, debe ir precedido de
dos puntos. Si se omite el nombre de la clase, también se omiten los dos puntos. Si se omite el
nombre del objeto, este objeto se denomina objeto anónimo. Ejemplos de diferentes alternativas
de notación se muestran en Figura 4.2 . Objeto anónimo
Figura 4.2
maxMiller maxMiller: Persona :Persona Alternativas de notación para
objetos
maxMiller maxMiller: Persona :Persona
firstName = "Max" firstName = "Max" firstName = "Max"

lastName = "Miller" lastName = "Miller" lastName = "Miller"
dob = 03-05-1973 dob = 03-05-1973 dob = 03-05-1973
Si el rectángulo tiene un segundo compartimento, este compartimento contiene los

atributos del objeto y los valores actuales de estos atributos (ver Figura 4.1 y Figura 4.2 ). Un
vínculo se representa como una línea continua que conecta los objetos que se relacionan
entre sí. Aunque el nombre de un objeto debe ser único, diferentes objetos pueden tener
atributos con valores idénticos. Si, en nuestro sistema, hubiera dos personas con el primer
nombre Max y el apellido Molinero, y ambos nacieron el mismo día, tendríamos que
representarlos usando diferentes objetos con diferentes nombres de objeto (por ejemplo, maxMiller1
y maxMiller2). Sin embargo, sus valores de atributo serían idénticos.
Los valores de los atributos generalmente cambian con el tiempo. Por ejemplo, si la
persona Max Miller cambia su apellido, el individuo en su conjunto no cambia, solo el
valor del atributo apellido. El ob-
Por tanto, el diagrama del objeto siempre representa sólo una instantánea de los objetos en un momento
específico en el tiempo y los objetos pueden desarrollarse más y cambiar a medida que pasa el tiempo. Si
los objetos específicos no están representados en el diagrama de objetos, esto no significa que no existan;
simplemente expresa que los objetos no registrados no son importantes por el momento.
De objeto a clase Muchos individuos que aparecen en un sistema tienen características y comportamientos
idénticos. Por ejemplo, las personas siempre tienen un nombre, un apellido y una fecha de
nacimiento. Los estudiantes también tienen un número de matrícula. Los cursos siempre tienen un
nombre y un número de horas, así como un semestre en el que se desarrollan. La información
sobre las salas de conferencias incluye el número de asientos disponibles. Si cada persona, cada
curso y cada sala de conferencias del sistema fueran modelados individualmente, el modelo pronto
se volvería demasiado complicado e imposible de mantener. El uso de clases le permite describir
objetos similares sin tener que detallar todos y cada uno de los objetos individualmente.
4.2 Clases
Clase UN clase es el plan de construcción de un conjunto de objetos que aparecen en el sistema que se va a
especificar. Las clases pueden caracterizar, por ejemplo, personas (por ejemplo, estudiantes), cosas (por
UN
ejemplo, edificios), eventos (por ejemplo, cursos o exámenes) o incluso conceptos abstractos como
grupos. En lenguajes de programación orientados a objetos como Java [4], los programas se crean
basándose en clases. Figura 4.3 compara una de fi nición de clase de un diagrama de clase UML con una
de fi nición de clase en Java.
Figura 4.3
clase Curso {
Definición de una clase en Curso
UML y Java Nombre de cadena;
nombre: String SemesterType semestre;
semestre: SemesterType horas de flotación;
horas: flotar
int getCredits ();
getCredits (): int
Lecturer getLecturer ();
getLecturer (): Conferencista
flotar getGPA ();
getGPA (): flotar
}
Ejemplo Los objetos representan las formas concretas de clases y se conocen como sus instancias. Las
Características de características relevantes de las instancias de una clase se describen mediante la definición de
clases ... características estructurales ( atributos) y comportamiento operaciones). Las operaciones
permiten que los objetos se comuniquen entre sí y actúen y reaccionen.
4.2 Clases 53
Un atributo le permite almacenar información que es conocida para todos los casos, pero que . . . son atributos y
generalmente tiene diferentes valores específicos para cada caso. Las operaciones especifican cómo se operaciones
puede activar un comportamiento específico en objetos individuales. Por ejemplo, la clase Curso desde Figura
4.3 tiene los atributos
nombre y horas. Figura 4.1 muestra formas concretas de estos atributos. Las posibles operaciones de
esta clase son getGPA () y getLecturer (), que devuelven el promedio de calificaciones o el profesor de
un curso, respectivamente.
Para asegurar que un modelo siga siendo claro y comprensible, generalmente no Nivel de detalle
modelamos todos los detalles del contenido: solo incluimos la información que es relevante
para el momento y para el sistema a implementar. Esto significa que nosotros abstracto de
la realidad para hacer el modelo menos complejo y evitar una avalancha de información Abstracción
innecesaria. En el modelo, nos limitamos a lo esencial. Por ejemplo, en un sistema de
administración universitaria, es importante poder administrar los nombres y números de
matrícula de los estudiantes; por el contrario, su talla de calzado es irrelevante y, por tanto,
no se incluye.
4.2.1 Notación
En un diagrama de clases, una clase está representada por un rectángulo que se puede subdividir
en varios compartimentos. El primer compartimento debe contener el nombre de la clase, que
generalmente comienza con una letra mayúscula y se coloca centrada en negrita (por ejemplo, Curso
en Figura 4.4 ). De acuerdo con las convenciones de nomenclatura comunes, los nombres de las
clases son sustantivos singulares. El nombre de la clase debe describir la clase usando el
vocabulario típico del dominio de la aplicación. El segundo compartimento del rectángulo contiene el atributos
de la clase, y el tercer compartimento el
Figura 4.4
Curso
Representación de una clase y
Curso sus características.
(un)
+ nombre: String
+ semestre: SemesterType
- horas: flotar
Curso
- / créditos: int
nombre + getCredits (): int

semestre + getLecturer (): Conferencista
horas + getGPA (): flotar
+ getHours (): flotar
obtener créditos()
+ setHours (horas: flotar): void
getLecturer ()
getGPA ()
(C)
(segundo)
operaciones de la clase. El contenido de estos compartimentos está ubicado a la izquierda y

es opcional. En general, el nivel de detalle en estos compartimentos refleja la fase respectiva
del proceso de desarrollo de software en el que se examina la clase. Mientras que el extracto
del diagrama de clases en Figura 4.4 (a) no contiene ningún detalle de la clase Curso, el
diagrama en Figura 4.4 (b) es el resultado de un análisis más detallado de los rasgos
característicos de los cursos, mostrando específicamente que la clase Curso contiene tres
atributos y tres operaciones. El diagrama en Figura 4.4 (c) presenta aún más detalles (como
la información del tipo y las visibilidades), incluida la información que es relevante para la
implementación o para la generación automática de código. Si en el diagrama no se incluye
información específica, esto no significa que no exista; simplemente significa que esta
información no es relevante en este momento o no se incluye por razones prácticas, por
ejemplo, para evitar que el diagrama se vuelva demasiado complicado. Por lo general, se
accede a los atributos y operaciones a través de sus nombres, que, de acuerdo con las
convenciones de nomenclatura, comienzan con una letra minúscula.
4.2.2 Atributos
Atributo Figura 4.5 muestra la sintaxis de los atributos. Un atributo tiene al menos un nombre. El tipo de
atributo se puede especificar después del nombre usando: Tipo. Los posibles tipos de atributos
incluyen tipos de datos primitivos, como enteros y cadenas, tipos de datos compuestos, por
Tipo ejemplo, una fecha, una enumeración o clases definidas por el usuario (consulte la Sección 4.8).
Especificando nombre: String, por ejemplo, definimos el atributo nombre con tipo Cuerda. Figura 4.6 muestra
más ejemplos de tipos de atributos. Veremos la especificación de multiplicidad opcional posterior
con más detalle en la siguiente sección.
Figura 4.5
Sintaxis de la especificación de
Visibilidad / Nombre : Tipo Multiplicidad
atributo
= Defecto { Propiedad }
,
4.2 Clases 55
Para definir un valor por defecto para un atributo, especifica = Defecto , dónde Valor por defecto
Defecto es un valor o expresión de fi nidos por el usuario (ver Figura 4.6 ). El sistema utiliza el valor
predeterminado si el usuario no establece explícitamente el valor del atributo. Por tanto, es imposible que
en algún momento un atributo no tenga valor. Por ejemplo, si en nuestro sistema, una persona siempre
debe tener una contraseña, una contraseña predeterminada pw123 se establece cuando se ingresa una
nueva persona en el sistema. Esta contraseña es válida hasta que se reinicie.
Figura 4.6
Persona Propiedades de los atributos
edad = ahora.getYear ()
firstName: String dob.getYear ()
lastName: String
dob: fecha
dirección: String [1 .. *] {único, ordenado} ssNo:
String {readOnly}
/ edad: int
contraseña: String = "pw123"
personsCounter: int
getName (out fn: String, out ln: String): void updateLastName

(nuevoNombre: String): booleano
getPersonsCounter (): int
Puede especificar adicionales propiedades del atributo entre llaves. Por ejemplo, la Propiedades de los atributos
propiedad { solo lectura} significa que el valor del atributo no se puede cambiar una vez que
se ha inicializado. En el ejemplo de
Figura 4.6 , el número de seguro social ssNo es un atributo que no se debe cambiar. En la
siguiente sección se introducirán otras propiedades dentro de la descripción de las
especificaciones de multiplicidad.
La especificación de una barra inclinada delante de un nombre de atributo indica que el valor
de este atributo se deriva de otros atributos. Un ejemplo de atributo derivado es la edad de una
persona, que se puede calcular a partir de la fecha de nacimiento. En Figura 4.6 , una nota contiene
una regla de cálculo para determinar la edad de una persona. Dependiendo de la herramienta de
desarrollo utilizada, dichas notas se formulan en lenguaje natural, en un lenguaje de programación
o en pseudocódigo. El marcador de visibilidad opcional (+, -, # o
∼) delante de un nombre de atributo o un nombre de operación como se muestra en Figura 4.4 (c) se
analiza en detalle en la página 58.
4.2.3 Multiplicidades
los multiplicidad de un atributo indica cuántos valores puede contener un atributo. Esto le Multiplicidad
permite definir matrices, como en los lenguajes de programación. La multiplicidad se muestra

como un intervalo encerrado por un cuadrado
corchetes en la forma [ mínimo máximo], por lo cual mínimo y máximo son números naturales
que indican los límites inferior y superior del intervalo. El valor del mínimo debe ser menor
o igual que el valor del máximo. Si no hay límite superior para el intervalo, esto se
expresa con un asterisco. ∗. La clase Persona en Figura 4.6 contiene un atributo dirección:
String [1 .. ∗]. Esto denota que una persona tiene al menos una y posiblemente varias
direcciones. Si el mínimo y el máximo son idénticos, no es necesario especificar el
mínimo y los dos puntos. Por ejemplo, [ 5] significa que un atributo adopta exactamente cinco
valores. La expresion [ ∗] es equivalente a [ 0 .. ∗]. Si no especifica una multiplicidad para un
atributo, el valor 1 se asume como predeterminado, que especifica un atributo de un solo
valor. La notación válida para multiplicidades se resume en
Figura 4.7 .
Figura 4.7
*
multiplicidad
[ Min .. Max ]
Si un atributo puede adoptar varios valores, tiene sentido especificar si el atributo es:
• Un conjunto (sin orden fijo de elementos, sin duplicados)

• Un conjunto múltiple (sin orden fijo de elementos, posibles duplicados)
• Un conjunto ordenado (orden fijo, sin duplicados)
• Una lista (orden fijo, posibles duplicados)
Único, no único, Puede realizar esta especificación combinando las propiedades { nonunique} y { único}, que
ordenado, desordenado de fi nen si se permiten o no duplicados, y { ordenado} y { desordenado}, que fuerzan o
cancelan un orden fijo de los valores de los atributos. Por ejemplo, el atributo dirección:
String [1 .. ∗] { único, ordenado} contiene todas las direcciones de una persona (ver
Figura 4.6 ). Como cada dirección solo debe incluirse una vez, el atributo se etiqueta { único}. Al
especificar { ordenado}, expresamos que el orden de las direcciones es importante. Por
ejemplo, la primera dirección podría interpretarse como la residencia principal.
4.2.4 Operaciones
Operación Operaciones se caracterizan por su nombre, sus parámetros y el tipo de valor de retorno (ver Figura
4.8 ). Cuando se llama a una operación en un programa, se ejecuta el comportamiento asignado
a esta operación. En lenguajes de programación, una operación corresponde a una declaración
de método
4.2 Clases 57
Figura 4.8
Visibilidad Nombre ( Parámetro )
operación
: Tipo { Propiedad }
o declaración de función que está de fi nida pero no implementada. El diagrama de clases no es

adecuado para describir el comportamiento de los objetos en detalle, ya que solo modela las firmas de
las operaciones que proporcionan los objetos; no modela cómo se implementan realmente estas
operaciones. UML ofrece diagramas de comportamiento especiales para representar la
implementación de operaciones, por ejemplo, el diagrama de actividad (consulte el Capítulo 7).
En un diagrama de clases, el nombre de la operación va seguido de una lista de parámetros entre Parámetros
paréntesis. La lista en sí puede estar vacía. Un parámetro se representa de manera similar a un
atributo. La única información obligatoria es el nombre del parámetro. La adición de un tipo, una
multiplicidad, un valor predeterminado y otras propiedades, como ordenado, único, o sus
contrapartes negadas es opcional (ver Figura 4.9 ).
El valor de retorno opcional de una operación se especifica con el tipo de valor de Valor devuelto
retorno. En Figura 4.6 , la clase Persona tiene una operación
updateLastName (newName: String): booleano. El único parámetro, nuevo-
Nombre, tiene el tipo Cuerda y especifica el nuevo nombre de una persona. El valor de retorno tiene el tipo booleano.
Si cierto se devuelve, el cambio de nombre se realizó correctamente, de lo contrario falso es regresado.
Si es necesario, también puede anteponer una dirección al nombre del parámetro. Esta dirección Entrada y salida
puede tener uno de los siguientes valores: En fuera, o En fuera ( ver parámetros
Figura 4.9 ). El valor indica si el parámetro es un parámetro de entrada, un parámetro de
salida, o ambos. Si un parámetro tiene la dirección en,
esto indica que cuando se utiliza la operación, se espera un valor de este parámetro. La
especificación de la dirección fuera expresa que luego de la ejecución de la operación, el
parámetro ha adoptado un nuevo valor. Si una operación debe tener múltiples valores de
retorno en lugar de solo uno, puede expresar esto usando múltiples parámetros con la
dirección fuera.
La especificación de En fuera indica un parámetro combinado de entrada / salida. Si no se especifica ninguna
dirección, en es el valor predeterminado. En Figura 4.6 , la op-
eración getName (fuera de fn: String, fuera de ln: String) tiene dos parámetros con el
valor de dirección fuera. Por ejemplo, si usamos la operación getName en un
programa llamando getName (nombre, apellido), por lo cual
primer nombre y apellido son variables en el sentido de un lenguaje de programación

imperativo, la ejecución exitosa de la operación produce los siguientes resultados: la
variable primer nombre contiene el primer nombre y la variable apellido contiene el
apellido del objeto de tipo Persona en el que la operación getName fue llamado.
Figura 4.9
en
Sintaxis de la especificación del
parámetro
fuera
Nombre : Tipo Multiplicidad
En fuera
= Defecto { Propiedad }
4.2.5 Marcadores de visibilidad
Visibilidad los visibilidad de atributos y operaciones especifica quién es y quién no puede acceder a ellos. Si un
atributo u operación no tiene una visibilidad especificada, no se asume una visibilidad predeterminada. Cuadro
4.1 enumera los tipos de visibilidades y su significado en UML. Solo un objeto en sí mismo conoce los
valores de los atributos que están marcados como privado. Por el contrario, cualquiera puede ver los
atributos marcados como público. El acceso a los protegido Los atributos están reservados para la propia
clase y sus subclases. Si una clase tiene un paquete
atributo, solo las clases que están en el mismo paquete que esta clase pueden acceder a este
atributo. En consecuencia, la visibilidad de una operación especifica a quién se le permite usar la
funcionalidad de la operación. Se dan ejemplos en Figura 4.4 (c) en la página 53. Tenga en cuenta
que el significado de las visibilidades puede variar en diferentes lenguajes de programación y
modelado, incluso si tienen el mismo nombre en los diferentes lenguajes.
Ocultación de información Las visibilidades se utilizan para realizar ocultación de información, un concepto importante en
informática. Marcar los atributos que representan el estado de un objeto como privado protege este
estado contra el acceso no autorizado. Por lo tanto, el acceso solo es posible a través de una interfaz
claramente definida, como a través de operaciones declaradas público.
En algunos casos, los diagramas de clases contienen solo aquellos atributos y operaciones que
son visibles externamente. Atributos y operaciones de clases
4.2 Clases 59
que están marcados como privado A menudo se omiten, ya que son importantes para la
realización, es decir, la implementación de una clase, pero no para su uso. Por lo tanto, si los
atributos y operaciones marcados como privado
se especi fi can depende de la intención y el momento de la creación del diagrama de
clases.
Nombre Descripción del símbolo Cuadro 4.1
público + Acceso de objetos de cualquier clase permitida Acceso solo Visibilidades
privado - dentro del objeto mismo permitido

protegido # Se permite el acceso de objetos de la misma clase y sus subclases
paquete ∼ Se permite el acceso de objetos cuyas clases están en el mismo paquete
4.2.6 Variables de clase y operaciones de clase
Los atributos generalmente se definen a nivel de instancia. Si, por ejemplo, una clase se realiza en
un lenguaje de programación, la memoria se reserva para cada atributo de un objeto cuando se
crea. Estos atributos también se denominan variables de instancia o atributos de instancia. En Figura
4.10 por ejemplo, Sinónimos:
apellido y dob son variables de instancia. Si, en un programa orientado a objetos generado a partir
• Instancia variable
de esta clase de diagrama, persona1 es una instancia de la clase Persona, por ejemplo, person1.lastName
• Atributo de instancia
se puede utilizar para hacer referencia al apellido de la persona. El acceso a la fecha de
nacimiento de esta persona no es posible porque la visibilidad del atributo dob es privado. Para
averiguar la fecha de nacimiento de persona1, la función person1.getDob ()
debe ser llamado. Una operación como getDob () sólo se puede ejecutar si se creó de antemano una
instancia correspondiente que ofrezca esta operación. En nuestro caso, esta es la instancia persona1.
Una operación puede utilizar todas las variables de instancia visibles.
A diferencia de las variables de instancia, variables de clase se crean solo una vez para una clase Sinónimos:
en lugar de por separado para cada instancia de esta clase. Estas variables también se conocen como atributos
• Variable de clase
estáticos o atributos de clase. Contadores para el número de instancias de una clase (ver Figura 4.10 ) o
• Atributo de clase
constantes como π a menudo se realizan como atributos estáticos. En el diagrama de clases, los • Estático
atributos estáticos están subrayados, al igual que operaciones estáticas. atributo
Operaciones estáticas, también llamadas operaciones de clase, se puede utilizar si no se creó ninguna
instancia de la clase correspondiente. Ejemplos de operaciones estáticas son funciones matemáticas Sinónimos:
como pecado (x) o constructores. Los constructores son funciones especiales llamadas para crear una
• Operación de clase
nueva instancia de una clase. La invocación del método Person.getPCounter () utiliza la operación
• Operación estática
estática
ción getPCounter () definido en Figura 4.10 ; la operación se llama directamente a través de la clase y no a
través de una instancia. A menos que se indique lo contrario, los atributos y las operaciones denotan
atributos de instancia y operaciones de instancia en la mayoría de los lenguajes orientados a objetos.
También seguimos esta convención en este libro.
Figura 4.10
class Person {
Traducción de una clase de UML Persona
a Java public String firstName;
+ nombre: Cadena public String lastName;
+ apellido: Cadena fecha privada dob;
- dob: fecha dirección de cadena protegida [];
# dirección: Cadena [*] private static int pCounter;
- pCounter: int
public static int getPCounter () {…} public Date getDob ()
+ getPCounter (): int {…}
+ getDob (): Fecha }
4.3 Asociaciones
Asociación Asociaciones entre clases modelan posibles relaciones, conocidas como

Enlaces, entre instancias de las clases. Describen qué clases son posibles socios de
comunicación. Si sus atributos y operaciones tienen las visibilidades correspondientes, los
socios de comunicación pueden acceder a los atributos y operaciones de cada uno. Un
diagrama de clases se puede ver como un gráfico en el que las clases representan los nodos y
las asociaciones representan los bordes. Figura 4.11 representa un diagrama de clases y un
diagrama de objeto válido. El diagrama de clases muestra que las clases Profesor y
Estudiante están relacionados a través de la asociación giveLectureFor. En el rol de conferencista, un
profesor tiene cero o más estudiantes y un estudiante tiene cero o más profesores en el rol de
conferencista. El diagrama de objetos modela un escenario concreto.
4.3.1 Asociaciones binarias
Asociación binaria UN asociación binaria nos permite asociar las instancias de dos clases entre sí. Las
relaciones se muestran como aristas (línea continua) entre las clases asociadas
Dirección de lectura involucradas. El borde se puede etiquetar con el
C
nombre de la asociación opcionalmente seguido por el dirección de lectura, un pequeño triángulo
UN segundo
negro. La dirección de lectura se dirige hacia un extremo
www.allitebooks.com
4.3 Asociaciones 61
giveLectureFor Figura 4.11

Profesor * * Estudiante Ejemplo de una asociación binaria en
+conferenciante
un diagrama de clases y un diagrama
de objeto válido
helenLewis: Estudiante
annaMiller: Profesora
paulSchubert: Estudiante
FrankStone: Profesor
mikeFox: Estudiante
de la asociación y simplemente indica en qué dirección el lector del diagrama debe "leer"
el nombre de la asociación. Ya hemos visto una asociación binaria con la dirección de
lectura en Figura 4.11 . En este diagrama, la dirección de lectura indica que los profesores
dan conferencias para los estudiantes y no al revés.
Si el borde está dirigido, es decir, al menos uno de los dos extremos tiene una punta de flecha Navegabilidad
abierta, es posible la navegación desde un objeto a su objeto asociado. En lenguaje sencillo, navegabilidad
UN segundo
indica que un objeto conoce sus objetos asociados y, por tanto, puede acceder a sus atributos y
operaciones visibles. La dirección de navegación no tiene nada que ver con la dirección de lectura,
como el ejemplo en Figura 4.11 muestra. La dirección de lectura indica que los profesores dan
conferencias para los estudiantes. Sin embargo, la navegabilidad especificada indica que los
estudiantes pueden acceder a las características visibles de los profesores a cuyas conferencias
asisten. En cambio, un profesor no puede acceder a las características visibles de los estudiantes
que asisten a la conferencia del profesor porque el profesor no las conoce.
Un final de asociación no navegable se indica mediante la especificación explícita de un X en No navegabilidad

el extremo de la asociación en cuestión. Por ejemplo, si tal X aparece al final de la asociación de UN
UN segundo
para una asociación entre las clases UN y SI, esto significa que segundo no puede acceder a los
atributos y operaciones de UN —Ni siquiera los públicos. Bordes bidireccionales sin puntas de
flecha o X en sus extremos no aportan ninguna información sobre la dirección de navegación pero
en la práctica se suele asumir la navegabilidad bidireccional. La dirección de navegación
representa una pista para la implementación posterior porque en los lenguajes de programación
orientados a objetos, las asociaciones se realizan como referencias a los objetos asociados. Una
asociación también se puede representar de esta manera en el diagrama de clases, es decir, como
un atributo con la multiplicidad apropiada, por lo que el tipo de atributo es la clase de los objetos
asociados correspondientes. Esta representación tiene la misma semántica que un extremo de
asociación navegable. Figura 4.12
Figura 4.12
Asociaciones en UML y Java Profesor Profesor
+ conferenciante *
* Estudiante
Estudiante
+ conferenciante: Profesor [*]
(un) (segundo)
profesor de clase {…}
clase Student {
Profesor público [] conferenciante;
...
}
(C)
muestra (a) un diagrama de clases en el que la relación alumno-profesor se modela

explícitamente como una asociación, (b) un diagrama de clases en el que la relación está
representada por un atributo en la clase Estudiante, y (c) la traducción a Java. El diagrama de
clases en Figura 4.12 (a) es preferible, ya que aquí la relación entre las clases se visualiza
explícitamente y es visible de inmediato, mientras que en la alternativa en Figura 4.12 (b) , la
asociación entre Estudiante y Profesor solo se puede reconocer leyendo la información de tipo
del atributo conferenciante.
Figura 4.13
Ejemplos de multiplicidad Conferenciante
1 cuestiones
* Asignación
especi fi caciones en binario
asociaciones (un)
1 .. * da 1 .. *
Conferenciante Conferencia
(segundo)
Persona * + examinador
+ examinar * e
examina
(C)
4.3 Asociaciones 63
De la misma manera que se especifican multiplicidades de atributos y parámetros, multiplicidades

de asociaciones se dan como un intervalo en la forma mínimo máximo. Especifican el Multiplicidad
número de objetos que pueden asociarse con exactamente un objeto del lado opuesto.
Los valores que pueden adoptar el mínimo y el máximo son números naturales y un
asterisco. ∗, que expresa que no hay restricción. Si mínimo y
máximo son idénticos, un valor y los puntos se pueden omitir. Otra vez,
0 .. ∗ significa lo mismo que ∗. Figura 4.13 muestra ejemplos de especi fi caciones de multiplicidad para
asociaciones binarias. Figura 4.13 (a) muestra que un profesor puede emitir ninguna, una o varias
asignaciones y que una tarea la emite exactamente un profesor. No puede existir ninguna asignación sin
una asociación a un conferenciante. Figura 4.13 (b) muestra que un conferenciante imparte al menos
una conferencia y una conferencia la imparte al menos un conferenciante. Finalmente,
Figura 4.13 (c) muestra que una persona en el papel de examinador puede examinar cualquier
número ( ≥ 0) de personas y una persona en la función de examinado puede ser examinada por
cualquier número de examinadores. En el ejemplo de Figura 4.13 (c) , el modelo no excluye el caso
de que las personas puedan examinarse a sí mismas. Si esto se prohibiera, se deben especificar
restricciones adicionales.
También puede etiquetar los extremos de la asociación con nombres de roles. UN papel describe Papel
la forma en que un objeto está involucrado en una relación de asociación, es decir, qué papel
juega en la relación. En la asociación en Figura 4.13 (c) , el Persona adopta el papel de examinador o
examinado.
Para expresar que un objeto de clase UN se asocia con un objeto de clase segundo o un restricción xor
objeto de clase C pero no con ambos, puede especificar un
segundo {xor} C
restricción xor exclusivo o). Para indicar que dos asociaciones de la misma clase son mutuamente
excluyentes, se pueden conectar mediante una línea discontinua etiquetada { xor}. Por ejemplo, un UN
examen puede tener lugar en una oficina o en una sala de conferencias, pero no en ambas (ver Figura
4.14 ).
Figura 4.14
Oficina Sala de conferencias Ejemplos de asociaciones
con restricciones xor
1 {xor} 1
* *
Examen
4.3.2 Asociaciones N-Ary
Asociación n-aria Si más de dos objetos socios están involucrados en una relación, puede modelar esto usando
un asociación n-aria. Una asociación n-aria se representa con un diamante hueco en el centro.
UN segundo
El diamante está conectado con todos los socios de la relación por medio de un borde no
C dirigido. El nombre de la asociación se especifica junto al diamante. No hay direcciones de
navegación para asociaciones n-arias; sin embargo, son posibles las multiplicidades y los
Multiplicidades para n-ario nombres de los roles. Las multiplicidades definen cuántos objetos de un rol / clase pueden
asociaciones asignarse a una ( norte - 1) -tupla de objetos de los otros roles / clases.
Figura 4.15 modela la relación Los grados entre las instancias de las clases Profesor, Estudiante, y Examen.
Las multiplicidades se definen de la siguiente manera: un estudiante específico toma un examen
específico sin profesor (es decir, no toma este examen en absoluto) o precisamente con un profesor.
Esto explica la multiplicidad 0..1 para la clase Conferenciante. Por supuesto, un examen específico con
un profesor específico puede ser realizado por cualquier número de estudiantes y un estudiante
específico puede ser calificado por un profesor específico para cualquier número de exámenes. En
ambos casos, esto se expresa por la multiplicidad ∗. En este modelo, no es posible que dos o más
profesores califiquen a un estudiante para el mismo examen.
Figura 4.15
Ejemplo de asociación n-aria Estudiante
(aquí ternaria) ...

*
Examen * Los grados
0..1 + examinador
Conferenciante
Si intentara expresar esta asociación ternaria con dos asociaciones binarias, tendría un
modelo con un significado diferente. En la representación que se muestra en Figura 4.16 , un
examen puede ser calificado por varios profesores. La asociación ternaria en Figura 4.15 muestra
claramente con qué profesor un estudiante aprobó un examen específico; este no es el caso con
el diagrama que se muestra en Figura 4.16 .
Por ejemplo, con el modelo que se muestra en Figura 4.15 , es posible

expresar ese estudiante s1 tomó el examen e1 con profesor l1 y ese estudiante
4.4 Clases de asociación sesenta y cinco
Figura 4.16
* Estudiante . .asociaciones
. versus ejemplo con ...
dos
binarias
*
Examen
+e
xam
* in ado
r
Conferenciante
*
s2 tomó el mismo examen e1 con profesor l2. Con el modelo mostrado en
Figura 4.16 , solo es posible expresar que los estudiantes s1 y s2

tomó el examen e1 y ese examen e1 tiene dos examinadores l1 y l2. Con este modelo, no puede
expresar qué profesor califica a qué estudiante.
Como alternativa a la asociación ternaria en Figura 4.15 , un adicional
Se puede introducir una clase tradicional que está conectada a las clases originales mediante
asociaciones binarias (ver Figura 4.17 ). Sin embargo, en este modelo es posible que un
estudiante sea calificado varias veces para un mismo examen, lo que no es posible con el modelo
de Figura 4.15 .
1 1 Figura 4.17
Examen * Calificación * Estudiante . . . versus ejemplo con
clase adicional
*
Conferenciante
4.4 Clases de asociación
Si desea asignar atributos u operaciones a la relación entre una o más clases en lugar de a una
clase en sí, puede hacerlo usando un clase de asociación. Una clase de asociación está
representada por una clase y una asociación que están conectadas por una línea discontinua. Clase de asociación
La asociación puede ser binaria o n-aria. Aunque la representación incluye múltiples
UN segundo
componentes, una clase de asociación es uno construcción de lenguaje que tiene las
propiedades de una clase y las propiedades de una asociación. Por lo tanto, en un diagrama, la C
clase y la asociación de una clase de asociación deben tener el mismo nombre, aunque no es
necesario nombrar ambas (ver las clases de asociación Inscripción y Grado en Figura 4.18 ). Una
clase de asociación
Figura 4.18
Ejemplos de asociación Programa de estudio
clases
1 .. *
Inscripción
+ startDate: Fecha
*
Certificado
Estudiante
asociación binaria
+ fecha Emitida: Fecha
clase
*
Grado
Examen *
grado + grado: int
0..1 + examinador asociación ternaria

clase
Conferenciante
también puede tener asociaciones con otras clases. En Figura 4.18 , la clase de asociación Grado, que
contiene información sobre la calificación de un estudiante para un examen específico, está asociado
con la clase Certi fi cado.
En general, no puede reemplazar una clase de asociación con una clase "normal" que está
asociada a las dos clases asociadas originales, como se muestra en el siguiente ejemplo.
Supongamos que queremos modelar que un estudiante se inscribe en al menos un programa de
estudios y tiene exactamente una inscripción para cada programa de estudios elegido. A su vez,
cualquier número ( ≥ 0) de los estudiantes pueden inscribirse en un programa de estudio específico.
Esta situación se muestra en Figura 4.19 (a) .
Figura 4.19 (b) muestra el intento de modelar esta situación solo con clases "normales".
Se asigna una matrícula precisamente a un estudiante
Figura 4.19
Intente modelar una clase de Estudiar 1 Estudiar
asociación con una clase Programa Programa
"normal" y las relaciones
correspondientes.
1 .. *
*
Inscripción Inscripción
* 1.
.*
Estudiante Estudiante
1
(un) (segundo)
4.5 Agregaciones 67
y precisamente un programa de estudios, mientras que un programa de estudios está relacionado con
cualquier número de objetos de inscripción. Un estudiante tiene al menos una matrícula. Hasta ahora se
cumplen los requisitos. Sin embargo, si examinamos el diagrama más de cerca, vemos que en Figura 4.19
(b) , un estudiante puede tener múltiples inscripciones para un mismo programa de estudio, lo cual no es la
intención. En contraste, en Figura 4.19 (a) , un estudiante puede inscribirse en un programa de estudio
específico solo una vez.
Si se requieren explícitamente duplicados para una clase de asociación, al menos un extremo de

asociación debe identificarse como { no único}. Si esta propiedad no se especifica explícitamente, el valor
predeterminado { único} se supone. En Figura 4.20 (a) , a un estudiante solo se le puede otorgar una
reunión de examen para discutir el resultado del examen escrito del estudiante una vez. Figura 4.20 (b) muestra
un modelo más amigable para los estudiantes. Allí, el uso de { no único} permite que un estudiante tenga
más de una reunión de examen.
Figura 4.20
Estudiante Estudiante
Ejemplo de { único} y
{no único} asociación
Examen
* Examen
* termina
{no único}
Reunión Reunión
* *
Examen Examen
(un) (segundo)
4.5 Agregaciones
Una agregación es una forma especial de asociación que se usa para expresar que las Agregación
instancias de una clase son parte de una instancia de otra clase. UML diferencia entre dos
tipos: agregación compartida y composición.
Ambos están representados por un diamante en el extremo de asociación de la clase que representa
el "todo". La diferenciación entre composición y agregación compartida está indicada por un diamante Relación partes-todo
sólido para una composición y un diamante hueco para una agregación compartida. Ambas son
asociaciones transitivas y asimétricas. En este caso, transitividad significa que si segundo es parte de UN
y C es parte de ANTES DE CRISTO también es parte de A. La asimetría expresa que no es posible UN ser
parte de segundo y segundo ser parte de UN simultaneamente.
Figura 4.21
LabClass
0..1
* Estudiante
Ejemplos de shared
agregaciones
(un)
Programa de estudio
1 .. *
* Curso
(segundo)
4.5.1 Agregaciones compartidas
Agregación compartida En el estándar UML, un agregación compartida tiene semántica intencionalmente informal. En principio,
una agregación compartida expresa una pertenencia débil de las partes a un todo, lo que significa que las
UN segundo
partes también existen independientemente del todo. La multiplicidad en el extremo de agregación puede
ser mayor que 1, lo que significa que un elemento puede ser parte de varios otros elementos
simultáneamente. Por tanto, las agregaciones compartidas pueden abarcar un gráfico acíclico
direccionado. Figura 4.21 muestra dos ejemplos del uso de una agregación compartida. En Figura 4.21 (a) ,
una clase de laboratorio consta de cualquier número de estudiantes. Sin embargo, un estudiante puede
participar en un máximo de una clase de laboratorio. En Figura 4.21 (b) , un programa de estudios se
compone de cualquier ( ≥ 0) número de cursos. Un curso está asignado a al menos uno ( ≥ 1) programa de
estudios.
4.5.2 Composiciones
Composición El uso de un composición expresa que una parte específica sólo puede estar contenida como
máximo en un objeto compuesto en un punto específico en el tiempo. Esto da como resultado una
UN segundo
multiplicidad máxima de 1 en el extremo de agregación. Por tanto, los objetos compuestos forman un
bosque de árboles, lo que indica una dependencia de existencia entre el objeto compuesto y sus
partes; si se elimina el objeto compuesto, también se eliminan sus partes. Figura 4.22 muestra
ejemplos de composiciones. Una sala de conferencias es parte de un edificio. Debido a la
multiplicidad 1, existe una dependencia de existencia entre elementos de estas dos clases. La sala
de conferencias no puede existir sin el edificio. Si el edificio ya no existe, la sala de conferencias
tampoco existe. La situación es diferente para un proyector que también está asociado con una sala
de conferencias por una composición. Sin embargo, la multiplicidad 0..1 se especifica en el extremo
de agregación. Esto significa que el proyector puede existir sin la sala de conferencias, es decir, se
puede quitar de la sala de conferencias. Si el proyector está ubicado en la sala de conferencias y la
sala de conferencias cesa
4.6 Generalizaciones 69
Figura 4.22
edificio
1
* Sala de conferencias
0..1 1
Beamer Ejemplos de composiciones
de existir —por ejemplo, porque se derriba el edificio—, el proyector también deja de

existir. Sin embargo, si fue retirado de la sala de conferencias de antemano, sigue
existiendo.
Una agregación compartida se diferencia de una asociación solo por el hecho de que
visualiza explícitamente una relación "parte de". En una composición, la dependencia de
existencia significa un vínculo mucho más fuerte entre el objeto compuesto y sus partes, lo que Dependencia de la existencia
significa que una composición y una asociación no son intercambiables. Una composición se usa de las partes de un objeto compuesto
generalmente si las partes están incrustadas físicamente en el objeto compuesto o solo son
visibles para el objeto compuesto. Si se hace referencia a las partes de manera externa, esto
puede indicar que una agregación compartida es suficiente. Además, si el objeto compuesto se
elimina o copia, sus partes también se eliminan o copian cuando se usa una composición.
4.6 Generalizaciones
Las diferentes clases a menudo tienen características comunes. Por ejemplo, en

Figura 4.23 , las clases Estudiante, Investigador Asociado, y Administra-
tiveEmployee todos tienen los atributos nombre, dirección, fecha de nacimiento, y ssNo. Los estudiantes y
empleados de ambos tipos se distinguen por otras características específicas de la clase

respectiva: un estudiante tiene una matrícula
Figura 4.23
Estudiar 1 .. * *
Curso Facultad Diagrama de clases sin
Programa generalización
1 .. *
* 1
1
do
inscribe enseña es asignado

na
ig
as
es
* 1 .. * * *
Investigación Administrativo
Estudiante
Asociar Empleado
nombre nombre nombre
habla a habla a habla a

dob dob dob
ssNo ssNo ssNo
matNo acctNo acctNo
número y se ha inscrito en al menos un programa de estudios; los empleados tienen una cuenta
corriente y están asignados a una facultad. Instancias de la clase
Investigador asociado estan en un enseña relación con cualquier número de instancias de la
clase Curso.
Podemos usar una relación de generalización para resaltar los puntos en común entre las
clases, lo que significa que ya no tenemos que definir estas características comunes varias veces.
A la inversa, podemos usar la generalización para derivar clases más específicas de las clases
existentes. Si queremos agregar una clase Profesor, que es una subclase de Investigador asociado, en
Figura 4.23 , usamos la generalización para evitar tener que copiar las características de la
clase Investigador asociado a la clase Profesor.
4.6.1 Herencia
Herencia de los relación de generalización expresa que las características (atributos y operaciones) y
superclase a subclase asociaciones que se especifican para una clase general ( superclase) se pasan a su subclases.
Por lo tanto, la relación de generalización también se conoce como herencia. Esto significa
Sinónimos: que cada instancia de una subclase es simultáneamente una instancia indirecta de la
superclase. La subclase "posee" todos los atributos de instancia y atributos de clase y todas
• Herencia
las operaciones de instancia y operaciones de clase de la superclase siempre que no se
• Generalización
• "Es una" relación hayan marcado con la visibilidad privado. La subclase también puede tener más atributos y
operaciones o entrar en otras relaciones independientemente de su superclase. En
consecuencia, las operaciones que se originan en la subclase o la superclase pueden
ejecutarse directamente en la instancia de una subclase.
Notación de generalización Una relación de generalización está representada por una flecha con una punta de flecha
triangular hueca de la subclase a la superclase, por ejemplo de Estudiante a Persona en Figura 4.24 .
UN segundo
El nombre de una superclase debe seleccionarse de manera que represente un término general
para los nombres de sus subclases. Para asegurarse de que no haya instancias directas de la
clase
Persona, etiquetamos esta clase con la palabra clave { abstracto}. La clase Persona por lo tanto se
convierte en un clase abstracta y solo se pueden instanciar sus subclases no abstractas. Veremos los
detalles de las clases abstractas en la Sección 4.7 en la página 72.
www.allitebooks.com
4.6 Generalizaciones 71
{abstracto} Figura 4.24

Diagrama de clases con
Persona
Estudiante generalización
nombre
habla a
matNo
dob
ssNo
*
inscribe
1 .. *
Empleado
Programa de estudio * 1
Facultad
es asignado
acctNo
1 .. *
*
Curso
*
enseña
1 .. *
Investigador asociado Empleado administrativo
La relación de generalización también se conoce como una relación “es una”. Por ejemplo, Transitividad de la
cada estudiante es una persona (ver Figura 4.24 ). Todo investigador asociado y todo empleado generalización
administrativo es un empleado y, debido a la transitoriedad de la relación de generalización, relación
todo empleado administrativo es también una persona. Si, como en los lenguajes de
programación orientados a objetos, consideramos que una clase es un tipo, las subclases y Subtipo y supertipo
superclases son equivalentes a subtipos y supertipos. equivalente a
subclase y superclase
UML permite herencia múltiple, lo que significa que una clase puede tener varias Herencia múltiple
superclases. Por ejemplo, un tutor es tanto un empleado de la universidad como un
estudiante (ver Figura 4.25 ). Debido a la transitividad de la herencia, la herencia única crea
una jerarquía de herencia, mientras que la herencia múltiple crea un gráfico de herencia
(acíclico dirigido).
Figura 4.25
Estudiante Empleado Ejemplo de múltiple
herencia
Tutor
4.6.2 Clasificación
Clasi fi cación se refiere a la relación "instanceOf" entre un objeto y su clase. En muchos

lenguajes de programación orientados a objetos, un objeto normalmente solo puede ser la
instancia directa de una clase precisa. En contraste, UML permite clasificación múltiple. Con
Clasificación múltiple la clasificación múltiple, un objeto puede ser una instancia de múltiples clases sin que estas
clases tengan que estar asociadas entre sí en una relación de herencia. En contraste con la
herencia múltiple, no se introduce ninguna clase nueva que herede las características de las
superclases involucradas.
Por ejemplo, instancias de Empleado se pueden diferenciar según su puesto de trabajo, es

decir, si son investigadores o administradores, y si se financian directamente a través de la
universidad o mediante un proyecto. La clasificación múltiple significa que un objeto puede ser una
instancia de múltiples clases cuyas características tiene el objeto. En Figura 4.26 , hemos dividido
las relaciones de generalización en dos grupos. Los conjuntos Trabajo y Financiación formar conjuntos
de generalización que agrupan subclases de acuerdo con múltiples criterios independientes. Los
Conjunto de generalización conjuntos de generalización se pueden describir con mayor precisión mediante las siguientes
restricciones:
• Superposición o desarticular: en un conjunto de generalización superpuesto, un objeto puede ser

una instancia de múltiples subclases simultáneamente. En un conjunto de generalización disjunto,
un objeto puede ser una instancia de un máximo de una subclase.
• Completar o incompleto: en un conjunto de generalización completo, cada instancia de la

superclase debe ser una instancia de al menos una de las subclases. En conjuntos de
generalización incompletos, esto no es necesario.
Esto da como resultado cuatro combinaciones: { completo, superpuesto}, {incom-

plete, superpuesto}, {completo, disjoint}, y { incompleta, disjunta}. Si ninguno
de estas restricciones se especifican explícitamente, { incompleto, inconexo} es el
valor por defecto. Se muestran ejemplos en Figura 4.26 : un empleado debe pertenecer al personal de
investigación o administrativo, pero no a ambos. El empleado puede ser financiado directamente a través
de la universidad, a través de un proyecto, a través de ambos, o de otra forma no especificada, por
ejemplo mediante una beca.
4.7 Clases abstractas frente a interfaces
Clase abstracta Las clases de las que no se pueden crear instancias se modelan como clases abstractas. Estas
son clases para las que no hay objetos; solo se pueden instanciar sus subclases. Las clases
{abstracto}
UN
abstractas se utilizan exclusivamente para resaltar características comunes de sus subclases
y, por lo tanto,
4.7 Clases abstractas frente a interfaces 73
Figura 4.26
ProyectoEmpleado UniversidadEmpleado
Ejemplo de múltiple
clasi fi cación
{incompleto, superpuesto}
Financiación
Empleado
Trabajo
{completo, disjunto}
Investigador asociado Empleado administrativo
sólo es útil en el contexto de relaciones de generalización. Las operaciones de clases abstractas también
se pueden etiquetar como abstractas. Un operación abstracta Operación abstracta
no ofrece ninguna implementación en sí. Sin embargo, requiere una implementación en las subclases
concretas. Las operaciones que no son abstractas transmiten su comportamiento a todas las
subclases.
Las clases abstractas y las operaciones abstractas se escriben en cursiva o se indican mediante
la especificación de la palabra clave { resumen} antes de su nombre (ver Figura 4.27 ). En los
diagramas de clases producidos manualmente en particular, se recomienda el uso de la segunda
alternativa de notación, ya que la escritura en cursiva es difícil de reconocer.
{abstracto} Figura 4.27

Persona Notación para abstracto
Persona
clases
En el ejemplo de Figura 4.28 , la clase Persona es abstracto. Por tanto, no puede haber
instancias de Persona sí mismo, pero puede haber instancias de las subclases específicas Empleado
y Estudiante.
De manera similar a la clase abstracta, un interfaz tampoco tiene implementación ni Interfaz
instancias directas. Una interfaz representa un contrato. Las clases que entran en este
contrato, es decir, las clases que implementan la interfaz, se obligan a proporcionar el
comportamiento especificado por la interfaz. En contraste con la relación entre una clase
abstracta y sus subclases, no es necesaria una relación "es una" entre una interfaz y las
clases que la implementan. Las operaciones de interfaces nunca tienen implementación.
Una interfaz se denota como una clase pero con la palabra clave adicional
"interfaz" antes del nombre. Una flecha de herencia discontinua con una punta de flecha
triangular hueca de una clase a una interfaz significa que esta clase implementa la interfaz.
Una flecha discontinua con la cabeza abierta con la palabra clave "utilizar" expresa que una
clase usa una interfaz. Veamos el ejemplo de Figura 4.28 . Las clases Persona y Curso implementar
la interfaz Imprimible. Las clases que implementan Imprimible debe proporcionar una operación impresión().
Esta operación es diferente para cada clase. Para un curso, se imprime el nombre y la
cantidad de horas; para Persona, el nombre y la dirección están impresos. En la clase Estudiante,
la operacion
impresión() se especifica de nuevo. Esto expresa que el Estudiante extiende el comportamiento de la
operación impresión() heredado de Persona. El método impresión()

se sobrescribe, lo que significa que también se imprime el número de matrícula. por Empleado esto no es
necesario, asumiendo que el comportamiento especificado para impresión() en Persona es suficiente. La
clase Impresora ahora puede procesar cada clase que implementa la interfaz Imprimible. Por tanto, una
especi fi impresión() se puede realizar para cada clase y la clase Impresora permanece sin cambios.
Figura 4.28 "interfaz"

Ejemplo de una interfaz Imprimible
"utilizar"
Impresora
+ imprimir (): vacío
{abstracto}
Curso
Persona
+ nombre: String + nombre: String

+ horas: int + dirección: String
+ nacimiento:
fecha de fecha
+ imprimir (): vacío + ssNo: int
+ getCredits (): flotar
Empleado Estudiante
+ acctNo: int + matNo: int

4.8 Tipos de datos 75
4.8 Tipos de datos
Los atributos, parámetros y valores de retorno de las operaciones tienen un tipo que especifica qué Clase frente a tipo de datos
formas concretas pueden adoptar. Por ejemplo, el nombre de una persona tiene el tipo Cuerda. Un tipo
puede ser una clase o un tipo de datos.
Las instancias de tipos de datos también se conocen como sus valores. A diferencia de las
instancias de clases (objetos), los valores no tienen identidad propia. Si dos valores son
idénticos, no se pueden diferenciar. Por ejemplo, veamos la clase Libro, cuyas instancias son
diferentes copias del libro UML @ Classroom. Estas copias se pueden identificar y diferenciar
de forma única aunque sus atributos tengan el mismo contenido. Sin embargo, diferentes
apariciones de un valor, por ejemplo, el número 2, no se puede diferenciar. Esta diferenciación
se hace evidente en la aplicación de la operación de comparación ==, como lo proporciona
Java, por ejemplo. Si comparamos dos variables del tipo En t ( tipo de datos entero) y ambas
variables tienen el mismo valor, el resultado de la operación de comparación es verdadero. Si
comparamos dos objetos diferentes con ==, el resultado es falso en general incluso si todos
los atributos tienen los mismos valores.
En UML, un tipo de datos se visualiza de la misma forma que una clase, con la diferencia de Tipo de datos
que el nombre del tipo de datos se anota con la palabra clave adicional « tipo de datos " (ver Figura
4.29 (b) ). Como el ejemplo en Figura 4.29 (b)
muestra, los tipos de datos pueden tener una estructura interna en forma de atributos. En UML, también
hay dos formas especiales de tipos de datos, a saber, tipos de datos primitivos y enumeraciones.
Tipos de datos primitivos no tienen ninguna estructura interna. En UML hay cuatro tipos de datos Tipo de datos primitivo
primitivos predefinidos: Booleano, entero, ilimitado natural, y Cuerda. Los tipos de datos primitivos definidos
por el usuario se identifican mediante la especificación de la palabra clave « primitivo ». Los tipos de
datos primitivos pueden tener operaciones (ver Figura 4.29 (a) ) que se ejecutan en sus valores.
Enumeraciones son tipos de datos cuyos valores se definen en una lista. La notación es la Enumeración
misma que para una clase con la identi fi cación específica « enumeración ». En Figura 4.29 (c) , la
enumeración Titulo academico está de fi nido. Esta enumeración enumera todos los títulos
académicos que se conocen en nuestro sistema. Por tanto, atributos del tipo Titulo academico puede
tomar los valores Master de bachiller, y Doctor. Estos valores se llaman literales. Literal
Figura 4.29
"primitivo" "tipo de datos" "enumeración"
Ejemplos de tipos de datos
Flotador Fecha Titulo academico
round (): vacío día soltero
mes Maestro
año Doctor
(un) (segundo) (C)

Los tipos definidos por el usuario se utilizan como se especifica en la descripción de sintaxis de
atributos y operaciones en Figura 4.5 (página 54) y en Figura 4.8
(página 57). Veamos las definiciones de tipo de Figura 4.29 de nuevo. Estos podrían usarse
en las siguientes definiciones de atributos: peso: flotar,
dob: fecha, y title: AcademicDegree [ ∗].
4.9 Crear un diagrama de clases
UML describe la sintaxis y la semántica de las clases y sus relaciones, pero no cómo se
construyen las clases y las relaciones. Lamentablemente, en principio no es posible extraer
completamente las clases y sus características de un texto en lenguaje natural de forma
automática. Sin embargo, existen pautas para crear un diagrama de clases. Sustantivos como
persona, empleado, curso, etc. a menudo indican clases. Por el contrario, los nombres de valores
como Pablo o modelado orientado a objetos y las expresiones que indican las relaciones entre
clases potenciales rara vez son clases. Los valores de los atributos a menudo se expresan
mediante adjetivos o también mediante sustantivos y las operaciones a menudo resultan de los
verbos. Los siguientes tres aspectos son importantes: ¿Qué operaciones puede ejecutar un
objeto de una clase? ¿Qué eventos, a los que el objeto debe poder reaccionar, pueden ocurrir
teóricamente? Y finalmente, ¿qué otros eventos ocurren como resultado? Si los valores de un
atributo pueden derivarse de otro atributo, por ejemplo, si la edad de una persona se puede
calcular a partir de su fecha de nacimiento, debe identificarse como un atributo derivado.
Además, es esencial tener en cuenta no solo los requisitos actuales, sino también la
extensibilidad del sistema.
Como ahora sabemos cómo derivar un diagrama de clases a partir de una especificación textual,
lo haremos para la siguiente especificación de requisitos:
Sistema de información de un • Una universidad consta de múltiples facultades que se componen de varios institutos.
Universidad Cada facultad y cada instituto tiene un nombre. Se conoce una dirección para cada
instituto.
• Cada facultad está dirigida por un decano, que es un empleado de la universidad. Se conoce el
• número total de empleados. Los empleados tienen un número de seguro social, un nombre y una
dirección de correo electrónico. Existe una distinción entre personal de investigación y
administrativo.
• Los investigadores asociados están asignados a al menos un instituto. Se conoce el campo de
estudio de cada investigador asociado. Además, los investigadores asociados pueden participar en
proyectos durante un cierto número de horas, y se conocen el nombre, la fecha de inicio y la fecha de
finalización de los proyectos. Algunos investigadores asociados imparten cursos. Se les llama
conferenciantes. Los cursos tienen un número (ID) único, un nombre y una duración semanal en
• horas.
4.9 Crear un diagrama de clases 77
1. Identificando las clases
Primero, debemos identificar los elementos que ocurren en el sistema Universidad que
identifican las clases. Estos se muestran en Figura 4.30 .
Figura 4.30
Empleado Clases identificadas
Facultad
Administrativo Investigación
Instituto
Empleado Asociar
Curso Proyecto
Conferenciante
Como podemos ver, Universidad no es una clase separada. No lo hemos olvidado, no lo

hemos incluido intencionalmente. Estamos usando el diagrama de clases para describir el
sistema. Universidad, de ahí que la instancia de nuestro modelo contenga aquellos objetos
que ocurren dentro de una universidad, por ejemplo, la Universidad Tecnológica de Viena.
Si incluimos una clase Universidad que a su vez consta de otras clases de Figura 4.30 ,
podríamos modelar múltiples sistemas de información universitarios simultáneamente.
Nuestro modelo también describiría, por ejemplo, la Universidad Johannes Kepler de Linz.
2. Identificando los atributos
Ahora podemos describir nuestras clases con más detalle utilizando atributos. Las clases y
sus atributos se muestran en Figura 4.31 .
Hemos de fi nido tipos de datos significativos para nuestros atributos aunque estos no estén
incluidos en la especificación. También configuramos la visibilidad de todos los atributos
para público para que en esta fase no tengamos que pensar qué atributos son visibles desde
el exterior y cuáles no. El atributo mostrador de la clase Empleado se define como un atributo
de clase ya que sus valores no pertenecen a una instancia. Este atributo aumenta cuando
una instancia de la clase Empleado es creado.
Figura 4.31
Clases y sus atributos Empleado
Facultad
+ ssNo: int
+ nombre: String
+ nombre: String
+ String
correo electrónico:
+ contador: int
Instituto
Empleado Asociar
+ fieldOfStudy: String + nombre: String
+ dirección: String
Curso Proyecto
Conferenciante

+ id: int + inicio: fecha
+ horas: flotar + fin: fecha
3. Identificar las relaciones entre clases
Las clases se pueden vincular entre sí de tres formas. Pueden estar en una relación de subclase /
superclase (generalización), estar relacionados mediante una agregación o vinculados mediante
asociaciones.
4.9.1 Generalizaciones
Las siguientes frases indican claramente una relación de generalización: "Hay una distinción
entre personal de investigación y personal administrativo". y “Algunos investigadores asociados
imparten cursos. Entonces se les llama conferenciantes ”. Modelamos estas relaciones de
generalización como se muestra en Figura 4.32 . Como cada empleado de una universidad
pertenece al personal administrativo o de investigación, podemos configurar la clase Empleado abstraer.
4.9.2 Asociaciones y agregaciones
Para completar el diagrama de clases, necesitamos sumar las asociaciones y agregaciones y sus
correspondientes multiplicidades. Las clases Conferenciante
y Curso están vinculados por medio de la asociación enseña. Un empleado dirige la facultad. Aquí
el empleado asume el papel de un decano. Una facultad
4.9 Crear un diagrama de clases 79
Figura 4.32
{abstracto}
Generalización identificada
Empleado
relaciones
+ ssNo: int
+ nombre: String
+ String
+ contador: int
Empleado Asociar
+ fieldOfStudy: String
Conferenciante
consta de varios institutos. Asumimos que hay una dependencia de existencia que modelamos
con una composición. Los investigadores asociados están asignados a un instituto, lo que
significa que forman parte de un instituto. Usar una composición aquí sería incorrecto ya que
no hay dependencia de existencia entre instancias de Empleado y Instituto. Sin embargo, es
posible una agregación compartida para representar explícitamente la relación partes-todo.
Finalmente, contamos con la implicación de investigadores asociados en los proyectos, por lo
que sabemos el número de horas de participación. Para esto necesitamos la clase de
asociación Participación. Esta clase de asociación detalla más la relación entre el proyecto y la
investigación asociada con el número de horas. Figura 4.33 muestra el diagrama de clases
completo para la tarea dada.
Tenga en cuenta que el modelo resultante no es único ni siquiera para ejemplos tan
pequeños; Depende, por un lado, de la aplicación prevista y, por otro, del estilo del modelador.
Por ejemplo, si hubiéramos creado el modelo con la intención de generar código a partir de él,
tal vez habríamos diseñado las interfaces con más cuidado y habríamos especificado
visibilidades más diferenciadas. Es cuestión de gustos que Conferenciante es una clase separada
pero decano es un papel. También podríamos haber especificado Conferenciante como un rol al
final de la asociación enseña que habría sido de fi nido
entre las clases Investigador asociado y Curso.

Figura 4.33
{abstracto}
Diagrama de clases del sistema de
Empleado
información de una universidad Facultad
1 Guías 0..1
+ ssNo: int
+ decano
+ nombre: String
+ nombre: String
+ String
+ contador: int 1
1 .. *
Instituto
Empleado Asociar 1 .. * 1 .. *
+ fieldOfStudy: String + nombre: String

+ dirección: String
1
..
*
Participación
+ horas: int
Conferenciante
0
..
1 .. *
*
Curso Proyecto
enseña
1 .. *
+ id: int + inicio: fecha
+ horas: flotar + fin: fecha
4.10 Generación de código
Ingeniería avanzada Los diagramas de clases se crean a menudo con la intención de implementar los elementos
modelados en un lenguaje de programación orientado a objetos. Como muchos de los conceptos
del diagrama de clases están disponibles en forma idéntica o similar en lenguajes de programación
orientados a objetos como Java, C # o C ++, en muchos casos una traducción puede tener lugar
automáticamente y solo requiere una mínima intervención manual. El diagrama de clases también
es adecuado para documentar el código de programa existente, con la ventaja de que las relaciones
Ingeniería inversa entre clases se representan gráficamente. Hay una serie de herramientas para el código de
programa de ingeniería inversa en diagramas de clases automáticamente.
El modelado de datos también implica conceptos similares a los del diagrama de clases.
Por ejemplo, aquí se utiliza el diagrama entidad-relación (diagrama ER) [14]; con la excepción
de una notación diferente, es muy similar al diagrama de clases. Ambos diagramas muestran
los elementos (clases o entidades) de un sistema y las relaciones (asociaciones o relaciones)
www.allitebooks.com
4.10 Generación de código 81
entre ellos. En ambos casos, estos elementos se caracterizan por sus atributos. Son visibles
diferencias considerables si comparamos el enfoque de los dos tipos de diagramas.
Mientras que el diagrama ER describe los elementos de una base de datos, el diagrama de
clases muestra cómo implementar el sistema modelado en un lenguaje de programación
orientado a objetos. Por lo tanto, en el diagrama ER, podemos definir los atributos clave que
se requieren para identificar las entradas en una tabla. Esto no es posible directamente en
un diagrama de clases, pero tampoco es necesario, ya que cada objeto se identifica
mediante un ID de objeto único. Por el contrario, la especificación del comportamiento, que
es posible en el diagrama de clases a través de operaciones, no se admite en el diagrama
ER. Por lo tanto, la recomendación es utilizar el tipo de diagrama que sea mejor para el
problema en cuestión. Figura 4.34 ) y el código Java generado a partir de él (ver Figura 4.35 ).
{abstracto}
Figura 4.34
Diagrama de clases a partir del cual se
Miembro de la Universidad
"enumeración"
generará el código
+ nombre: Cadena Semestre
+ apellido: Cadena
invierno
+ ssNo: int
verano
"enumeración"
ERole
conferenciante
Empleado tutor
Estudiante examinador
- acctNo: int
+ matNo: int
+ getAcctNo (): int
* + estudiante
+
*
com
ple
Apoyo
ta
+ rol: ERole
+ horas: flotar
+ cE *
* + cC
Curso Ejecución
Curso
* 1
+ año: int
+ curso
+ semestre: ESemester + courseNo: int
Muchos elementos se pueden traducir 1: 1. Tanto las clases abstractas como las concretas se
adoptan directamente en el código con sus atributos y operaciones. En el código, las asociaciones
se representan como atributos. Tenga en cuenta que la multiplicidad de un extremo de asociación
se refleja en el tipo de
tributo. Si la multiplicidad es mayor que uno, podemos usar, por ejemplo, una matriz, como hicimos
para los cursos. En lugar de matrices, también podríamos usar tipos de datos genéricos, por ejemplo,
el tipo de datos Java Colección; a diferencia de las matrices, con los tipos de datos genéricos no es
necesario conocer el tamaño en la inicialización [4].
Tenemos que asegurarnos de implementar correctamente las instrucciones de navegación. La

información de navegación proporcionada en términos de puntas de flecha en los extremos de la
asociación nos dice qué clase tiene que saber sobre qué otra clase, y esto se realiza a través de los
atributos que modelan los extremos de la asociación.
Algunos conceptos, como clases de asociación o asociaciones n-arias, no existen directamente en

lenguajes de programación comunes como Java. Por tanto, tenemos que considerar cómo simular estos
conceptos. Nuestro ejemplo contiene la clase de asociación Apoyo. En el código, esto se implementa como
una tabla hash. Una tabla hash es una estructura de datos que contiene elementos en el formulario ( llave
de datos). Si se conoce la clave (que debe ser única), los datos relacionados se pueden encontrar de
manera eficiente.
Hasta este punto hemos podido describir la estructura de los elementos y sus
relaciones. No pudimos expresar nuestro comportamiento. En el ejemplo anterior, solo
tuvimos una operación, getAcctNo (), que devuelve el número de cuenta del empleado. El
contenido del cuerpo del método se generó automáticamente ya que es un método getter
que encapsula el acceso a una variable del mismo nombre. Para otras operaciones, por
ejemplo, operaciones que estaban destinadas a calcular algo, la implementación no se
puede derivar automáticamente. UML ofrece otros diagramas para modelar el
comportamiento y los presentaremos en los capítulos siguientes. Para completar este
capítulo, Cuadro 4.2 resume los conceptos más importantes de los diagramas de clases y
objetos.
4.10 Generación de código 83
Figura 4.35
Código Java que se puede generar
clase abstracta UniversityMember { automáticamente desde
público String firstName; Figura 4.34
público String lastName;
público int ssNo;
}
clase Estudiante extiende UniversityMember {

público int matNo;
público CourseExecution [] cC; // completado c.
}
clase Empleado extiende UniversityMember {

int privado acctNo;
público CourseExecution [] cE; // apoyado c.
público int getAcctNo { regreso acctNo; }
}
clase CourseExecution {
público int año;
público ESemester semestre;
público Estudiante [] estudiante;
público Curso del curso;
público Soporte hashtable;
// Clave: empleado
// Valor: (rol, horas)
}
clase Curso {
público int courseNo;
}
Enumeración ESemester {
invierno;
verano;
}
Enumeración ERole {
conferenciante;
tutor;
examinador;
}
Cuadro 4.2
Elementos de notación de los
diagramas de clases y objetos UN
- a1: T1 Descripción de la estructura y el comportamiento de un

Clase - a2: T2
conjunto de objetos.
+ o1 (): vacío
+ o2 (): vacío
UN
Clase abstracta {abstracto} Clase que no se puede instanciar

UN
UN segundo
(un)
Relación entre clases: navegabilidad no
UN segundo especificada (a), navegable en ambas
Asociación
(segundo) direcciones (b), no navegable en una dirección
(c)
UN segundo
(C)
UN segundo
Relación entre N ( en este caso
Asociación n-aria
C
3) clases
UN segundo
Descripción más detallada de una asociación
Clase de asociación
C
segundo {xor} C Un objeto de UN está en una relación con un objeto

relación xor de segundo o con un objeto de C pero no con ambos
UN
Partes dependientes de la existencia

Fuerte agregación = el lacionalismo UN es parte de SI; Si segundo se elimina,
UN segundo
composición instancias relacionadas de UN también se eliminan)
Relación partes-todo ( UN es parte de

Agregación compartida UN segundo SI; Si segundo se elimina, instancias relacionadas de
UN no necesita ser eliminado)
Relación de herencia ( UN hereda de SEGUNDO)

Generalización UN segundo
Objeto jefe Instancia de una clase
Enlace o1 o2 Relación entre objetos

Capítulo 5
El diagrama de la máquina de estado
A lo largo de su vida, cada sistema, o para ser más precisos, cada objeto, pasa por un número
finito de estados diferentes. Usando un diagrama de la máquina de estado, puede modelar los Diagrama de la máquina de estado
estados posibles para el sistema u objeto en cuestión, cómo ocurren las transiciones de estado
como consecuencia de eventos que ocurren y qué comportamiento exhibe el sistema u objeto en
cada estado.
Como ejemplo simple, considere una sala de conferencias que puede estar en uno de dos estados: gratis
o ocupado. Cuando una conferencia comienza en la sala de conferencias, el estado de la sala de
conferencias cambia de gratis a ocupado. Una vez finalizado el acto respectivo en la sala de conferencias
y liberado nuevamente la sala, su estado vuelve a ser gratis ( ver Figura 5.1 ).
comienzo de la conferencia Figura 5.1

gratis ocupado Diagrama de máquina de estados de una
lanzamiento sala de conferencias (presentación
simplificada)
El diagrama de la máquina de estados se basa en el trabajo de David Harel [22] y utiliza conceptos de
autómatas finitos. UML diferencia entre dos tipos de máquinas de estado, a saber, máquinas de estado de
comportamiento y máquinas de estado de protocolo. En este libro, solo presentamos máquinas de estados
de comportamiento, que están muy extendidas en la práctica y también se conocen como diagramas de
máquinas de estados o gráficos de estados.
Al igual que cualquier otro diagrama, un diagrama de máquina de estados solo modela la
parte de un sistema que es necesaria o relevante para el propósito respectivo. Por ejemplo, si
desea modelar solo los estados que puede tomar una sala de conferencias, ya sea para recopilar
requisitos o para fines de documentación, un modelo como se muestra en Figura 5.1 puede ser
suficiente. Sin embargo, si ya se encuentra en una fase tardía del proceso de desarrollo, una
representación cercana al código, como se muestra en Figura 5.2 , es ben-

Computación, DOI 10.1007 / 978-3-319-12742-2_5
86 5 El diagrama de la máquina de estados
e fi cial. Esta figura muestra una clase Sala de conferencias con un atributo gratis que puede tomar los valores cierto
y falso. Llamando a la operación ocupar conjuntos gratis
a falso y el objeto de la sala de conferencias cambia al estado gratis = falso, que corresponde al
estado ocupado en Figura 5.1 . Los eventos en el diagrama de la máquina de estado son el
equivalente a llamar a las operaciones respectivas
de la clase Sala de conferencias.
Figura 5.2
class LectureHall {
Diagrama de la máquina de estado,
booleano privado libre;
diagrama de clase y seudocódigo de Sala de conferencias
public void ocupar () {
una sala de conferencias ocupar() libre = falso;
gratis = gratis =
- gratis: booleano }
cierto falso
lanzamiento() lanzamiento vacío público () {
+ ocupar () gratis = verdadero;
+ liberación ()
}
}
5.1 Estados y transiciones estatales
Estado Un diagrama de máquina de estados es un gráfico con estados como nodos y transiciones de estado como
bordes. En el diagrama, un estado se muestra como un rectángulo con esquinas redondeadas y está
S
etiquetado con el nombre del estado. Cuando un objeto se encuentra en un estado específico, todas las
actividades internas especificadas en este estado pueden ser ejecutadas por este objeto. Si se especifican
actividades internas para un estado, se divide en dos compartimentos: el compartimento superior del
rectángulo contiene el nombre del estado; el compartimento inferior incluye
Actividades internas actividades internas, por lo que una actividad puede constar de múltiples acciones. Presentaremos
la relación entre actividades y acciones en detalle en el Capítulo 7, que analiza los diagramas de
S
entrada / Actividad (...)

actividades.
hacer / Actividad (...) Dentro de un estado, puede modelar tres actividades que se ejecutan en un momento predefinido.
salida / Actividad (...)
Cuando se especifica una actividad después de la palabra clave
entrada, esta actividad debe ejecutarse cuando el objeto entra en estado; a la inversa, el salida la
actividad se ejecuta cuando el objeto sale del estado. Una actividad precedida por la palabra
clave hacer se ejecuta mientras el objeto permanece en este estado, es decir, mientras este
estado sea activo. La actividad respectiva siempre se especifica con una barra inclinada que la
identifica claramente como una actividad.
Figura 5.3 muestra una extensión del ejemplo de Figura 5.1 . Como
mientras una sala de conferencias permanezca en el estado gratis, es decir, siempre que el estado
gratis está activo, la actividad Mostrar como disponible se ejecuta y la sala de conferencias se muestra en el
sistema de reservas. Si la sala de conferencias está ocupada,

5.1 Estados y transiciones estatales 87
cambia del estado gratis al Estado ocupado. En el momento en que la sala de conferencias entra en este
estado, la actividad Guardar reserva de usuario se ejecuta y se guarda el nombre de la persona que ocupa
la sala de conferencias. Mientras la sala de conferencias permanece en el estado ocupado, la actividad Mostrar
como ocupado
es ejecutado. Una vez que la sala de conferencias ya no es necesaria, se libera y cambia al estado gratis.
Cuando la sala de conferencias sale del estado ocupado,
la actividad Eliminar reserva de usuario es ejecutado.
Figura 5.3
gratis ocupado
ocupar Diagrama de máquina de estado de una
hacer / Mostrar como disponible entrada / Guardar reserva de usuario sala de conferencias con actividades
hacer / Mostrar como ocupado internas
lanzamiento
salir / Eliminar reserva de usuario
El cambio de un estado a otro se conoce como transición de estado o simplemente transición.

Una transición se representa con un borde dirigido, es decir, una flecha. La punta de la flecha Transición
refleja la dirección de la transición. El origen de la transición se conoce como estado de origen y e [g] / A
S T
el final de la transición se conoce como el estado de destino. Puede especificar varias
propiedades para una transición:
Sinónimos:
• El evento (también llamado "disparador") que desencadena la transición de estado La guardia • Transición
• Transición de estado
• (también llamada "condición de guardia" o simplemente "condición") que permite la ejecución de la
transición
• Actividades (también llamadas "efectos") ejecutadas durante el cambio al estado de destino
Eventos son estímulos exógenos (es decir, estímulos que provienen del exterior del sistema / Evento (disparador)
objeto) que pueden desencadenar una transición de estado. Si se produce el evento especificado para
la transición, Guardia está chequeado. La guardia es una expresión booleana. En un momento Guardia (condición)
específico en el tiempo, se evalúa como verdadero o falso. Si la guardia es verdadera, todas las
actividades en el estado actual se terminan, cualquier salida se ejecuta la actividad y tiene lugar la
transición. Durante la transición de estado, cualquier ocupaciones definidos para esa transición se
ejecutan. Una transición, al menos desde una perspectiva conceptual, no requiere tiempo. Por lo tanto, Actividad (efecto)
el sistema siempre está en un estado y nunca en una transición. Por lo tanto, las actividades especi fi
cadas para una transición tampoco deben requerir un tiempo significativo.
Si la protección se evalúa como falsa, no hay transición de estado y el evento se pierde y no se

consume. Incluso si la guardia se vuelve verdadera en un momento posterior, el evento debe ocurrir
nuevamente para que tenga lugar la transición. Si no se modela ninguna guardia en una transición, el
valor predeterminado [ cierto] aplica. Si no se especifica ningún evento en una transición, la transición se
activa cuando la actividad de entrada y hacer se completan las actividades del estado actual.
Evento de finalización y Terminar estas actividades crea una evento de finalización que desencadena la transición. Este tipo
transición de finalización de transición también se conoce como transición de finalización. Si ocurre un evento para el cual no
se especifica ningún comportamiento en el estado actual, el evento no se consume y se pierde.
Los guardias siempre se colocan entre corchetes para diferenciarlos de los eventos y
actividades. Las actividades siempre van precedidas de una barra inclinada (incluidas las
actividades en los estados). Figura 5.4 ilustra la sintaxis de una especificación de transición.
Figura 5.4
Sintaxis de una especificación de
Evento ( Parámetro )
transición
,
,
[ Guardia ] / Actividad
Transición interna ... Puedes modelar transiciones internas dentro de los estados. Estas transiciones internas
manejan la ocurrencia de eventos dentro de un estado. Los usa para modelar la reacción a un
S
evento / Actividad (...)

evento cuando el sistema no sale del estado que está actualmente activo, lo que significa que entrada
y salida las actividades no se ejecutan.
Figura 5.5 muestra los dos estados que un estudiante puede tomar con referencia a un
examen, a saber no registrado y registrado. Mientras el estudiante permanezca en el estado no
registrado, cada vez que se publica una nueva fecha de examen, el estudiante verifica si hay tiempo
suficiente para realizar el examen en esa fecha, lo que significa que cada vez que el evento nueva
fecha ocurre la actividad Comprobar Fecha es ejecutado. Si el evento Registrarse ocurre, siempre que
. . . en contraste con el guardia registro posible es cierto, el estudiante cambia al estado

Transición "externa"
evento registrado y la fecha del examen se ingresa en el calendario. Mientras el estado registrado está
S1 / Actividad(...) S2 activo, el alumno está estudiando. Cada vez que el estudiante se encuentra con un
problema, se comenta con sus colegas. Si el evento retirar ocurre en el estado registrado, son
posibles dos casos diferentes. Si el guardia retiro posible es cierto, la actividad Estudiar para el
examen es interrumpido y el estudiante cambia al estado no registrado.
Cuando el estudiante sale del estado registrado, la fecha se elimina del calendario. Sin
embargo, si el guardia retiro posible es falso, el estudiante permanece en el estado registrado
y debe seguir estudiando para el examen. (Lo crea o no, en el país de origen de los
autores es posible retirarse de un examen sin consecuencias).
5.2 Tipos de Estados 89
Registrarse
Figura 5.5
no registrado registrado
[registro posible] Diagrama de máquina de estado del
nueva fecha / fecha de verificación entrada / Introduzca la fecha en el calendario estado de registro para un examen
hacer / Estudiar para el examen
retirar problema / discutir con colegas
[retiro posible] salir / Eliminar fecha
Para ilustrar mejor el concepto de eventos, guardias y actividades,

Figura 5.6 muestra ejemplos abstractos de transiciones. La transición en
Figura 5.6 (a) no tiene evento ni guarda. Por lo tanto, la transición puede tener lugar tan pronto
como A1 esta completado. Figura 5.6 (b) es parecido a Figura 5.6 (a) pero actividad A2 se ejecuta
durante la transición. En Figura 5.6 (c) , la transición tiene lugar tan pronto como el evento e1 ocurre.
Si e1
ocurre, la ejecución del hacer actividad A1 se interrumpe inmediatamente y el sistema cambia al
estado S2. Cuando el sistema sale del estado S1, los
salida actividad A2 es ejecutado.
En Figura 5.6 (d) , Guardia g1 se comprueba tan pronto como e1 ocurre. Si la guardia es
verdadera, A1 se termina y hay un cambio de estado para S2. Si la guardia es falsa, evento e1 está
perdido y A1 no se interrumpe. Figura 5.6 (e) es parecido a 5.6 (d) pero en 5.6 (e) , actividad A2 se
ejecuta además durante la transición.
Figura 5.6 (f) muestra un uso “impuro” de un guardia. El sistema permanece en estado S1 hasta A1
esta completado. Guardia g1 no se comprueba hasta este punto y la transición tiene lugar si g1 es
verdad. Si g1 es falso, el sistema permanece en estado S1 y nunca sera posible salir S1 a través de
esta transición como el evento de finalización de la hacer la actividad se perdió cuando no se
consumió. Este tipo de especificación de transición solo tiene sentido si, por ejemplo, hay una
transición adicional con una protección complementaria, lo que significa que no hay un callejón sin
salida (no se muestra aquí).
5.2 Tipos de Estados
Además de los estados discutidos en la Sección 5.1, existen otros tipos de estado que le
permiten modelar contenido más complejo con diagramas de máquina de estados. Hay una
distinción entre estados "reales" y pseudoestados. Los pseudoestados son transitorios, lo que Los pseudoestados son
significa que el sistema no puede permanecer en un pseudoestado. No son estados en el transitorio

sentido real, sino estructuras de control que permiten estados y transiciones de estados más
complejos. No puede anotar actividades en pseudoestados. Estos pseudoestados incluyen el
estado inicial, el nodo de decisión, los nodos de paralelización y sincronización, el estado
histórico, los puntos de entrada y salida y el nodo de terminación. Estos estan descritos en mas
detalle abajo.
Figura 5.6
S1 S1
Ejemplos de transiciones / A2
hacer / A1 S2 hacer / A1 S2
(un) (segundo)
S1 S1
e1 e1 [g1]
salir / A2
(C) (re)
S1 S1
e1 [g1] / A2 [g1]
(mi) (F)
Estado inicial los estado inicial se representa en el diagrama como un pequeño círculo negro y marca el
"inicio" de un diagrama de máquina de estados o un estado compuesto (presentado en la Sección
5.5). El estado inicial no tiene bordes entrantes y generalmente un borde saliente que conduce al
primer estado "real". Si se utilizan varios bordes de salida, sus condiciones de protección deben ser
mutuamente excluyentes y cubrir todos los casos posibles para garantizar que se alcance
exactamente un estado objetivo. Tan pronto como el sistema está en el estado inicial,
inmediatamente, es decir, sin consumir tiempo, cambia al siguiente estado. Por lo tanto, no puede
especificar ningún evento en el borde de salida desde el estado inicial. La única excepción a esta
regla es el evento que crea el objeto modelado en sí mismo: nuevo() o crear() por ejemplo. Sin
embargo, puede especificar actividades.
Nodo de decisión los nodo de decisión se representa en el diagrama con un diamante. Puede usarlo para
modelar transiciones alternativas. Tiene exactamente un borde entrante y al menos dos bordes
...
salientes. En el borde entrante, modela el evento que desencadena la transición; en los bordes de
salida, especifique las protecciones para las rutas alternativas para la transición de estado.
También puede especificar actividades en el borde entrante y todos los bordes salientes. Si ocurre
el evento modelado en el borde entrante, el sistema ingresa a la transición. Sin embargo, se
detiene brevemente en el nodo de decisión, pero desde una perspectiva conceptual sin consumir
tiempo, para evaluar los resguardos y así seleccionar el borde de salida que se utilizará. Para
evitar que el sistema se "atasque" en el nodo de decisión, debe asegurarse de que los guardias
cubran todas las situaciones posibles. Utilizando [ más] en uno de los bordes le permitirá hacer
esto. Si las protecciones no son mutuamente excluyentes, y si dos o más bordes se evalúan como
verdaderos, uno de estos bordes válidos se selecciona de forma no determinista. Figura 5.7 (a) muestra
un ejemplo del uso del
5.2 Tipos de Estados 91
nodo de decisión. Si evento e1 ocurre, la transición tiene lugar. Una vez que el sistema ha llegado al
nodo de decisión, los guardias [ segundo ≤ 0] y [ b> 0] son evaluados y el sistema cambia al estado S2 o
estado S3. También puede modelar el mismo comportamiento sin utilizar un nodo de decisión, como
se muestra en
Figura 5.7 (b) . A diferencia de, Figura 5.7 (c) y Figura 5.7 (d) mostrar un comportamiento diferente. Figura
5.7 (c) muestra que si evento e1 ocurre, la transición comienza y segundo se incrementa por el valor 1. Luego
se evalúan los guardias. En Figura 5.7 (d) , segundo solo se incrementa por el valor 1 después de la
evaluación de los guardias. Por lo tanto, dependiendo del valor de si, las transiciones a diferentes
estados pueden ocurrir en los dos modelos. Figuras 5.7 (c) y 5.7 (d) por tanto, no son semánticamente
equivalentes.
Figura 5.7
] S2 = 0] S2 Modelado con y sin nodos de
<= 0 e1 [b <
[b
e1
=
decisión
S1
S1
[b>
0] S3 e1 [b> S3
0]
(un) (segundo)
S2 b+1 S2
= 0] 0] / b: =
[b < e1 [b <=
e1 / b: = b + 1
S1
[b>
≠ S1
e1 [b>
0] S3 0] / b: =
b+1 S3
(C) (re)
Figura 5.8 muestra los estados que tiene un estudiante al participar en un curso específico.
Si el estudiante está en el estado no graduado y el evento
grado ocurre, dependiendo de la calificación que reciba el estudiante, el estudiante cambia al
estado positivo o el estado negativo. los X en el modelo se llama nodo terminado, que
presentaremos más adelante en este capítulo.
los nodo de paralelización se representa con una barra negra. Tiene exactamente un borde Nodo de paralelización
entrante y al menos dos bordes salientes y se usa para dividir el flujo en múltiples transiciones
concurrentes. No se pueden especificar eventos o guardias en los bordes salientes de un nodo de
...
paralelización en un diagrama de máquina de estado.
los nodo de sincronización también se representa con una barra negra. Tiene al menos dos bordes Nodo de sincronización
entrantes y exactamente un borde saliente y se usa para fusionar múltiples flujos concurrentes. No se
pueden especificar eventos o guardias en los bordes entrantes de un nodo de sincronización. Para
...
obtener más información sobre estos dos pseudoestados y una descripción del estado del historial,
consulte la Sección 5.5. Tenga en cuenta que los nodos de paralelización no deben confundirse con los
nodos de decisión.
Figura 5.8
Estados de participación de un estudiante
en el curso
retirar
registrado
calificado
actuación
positivo
<5]
do
[gra corrección corrección
no grado
[nuevo [nuevo
calificado
[gra grado <5] grado = 5]
do
=5
]
negativo
Terminar nodo los terminar nodo se representa en el diagrama con una gran X.
Si se alcanza un nodo terminado en un fl ujo, la máquina de estado termina y el objeto modelado
deja de existir. En Figura 5.8 , un objeto de participación en el curso específico para un estudiante
determinado se elimina si está en el estado
registrado y el evento retirar ocurre.
El único otro estado "real", es decir, un no pseudoestado, además de los estados discutidos en la
Estado final ... Sección 5.1 es el estado final. El estado final tiene al menos un borde entrante y ningún borde saliente.
En un diagrama, está representado por un círculo pequeño que contiene un círculo sólido. Marca el final
de la secuencia de estados (ver también la Sección 5.5). El objeto puede permanecer en un estado final
. . . es un estado "real" de forma permanente. Tenga en cuenta que el estado final no debe confundirse con el nodo de
terminación, donde se elimina el objeto modelado. Para obtener una explicación detallada de los puntos
de entrada y salida, consulte la Sección 5.5.3.
5.3 Tipos de transiciones de estado
Como ya se mencionó, hay dos tipos de transiciones de estado, a saber, transiciones internas y
Transición interna transiciones externas. Transiciones internas representan la reacción a un evento que desencadena
una actividad pero no una transición de estado. Como no hay cambio de estado, no entrada o salida las
Actividad de entrada actividades tampoco se ejecutan. Entrada y salida las actividades se modelan con la misma notación
y que cualquier otra transición interna. Sin embargo, requieren las palabras clave entrada y salida en
actividad de salida lugar del nombre del evento desencadenante para especificar que la actividad respectiva se ejecuta
cuando el sistema u objeto entra o sale del estado. Las transiciones internas se modelan dentro de
los estados.
5.3 Tipos de transiciones de estado 93
Cuando el sistema u objeto sale de un estado y entra en otro como reacción a un evento, la
transición se denomina transición externa. Primero el salida actividades del estado fuente, luego las Transición externa
actividades de la transición y, finalmente, las entrada las actividades del estado de destino se
ejecutan como parte de la transición de estado. UN autotransición es un tipo especial de transición
externa en la que el estado de origen y el estado de destino son idénticos. Autotransición
Figura 5.9 muestra ejemplos de transiciones internas y externas.
Figura 5.9
S
Ejemplos de transiciones
S
e / A1 ≈ e / A1 internas y externas.
(un) (segundo)
S S
entrada / A2
salida / A3
e / A1 ≠ entrada / A2
e / A1
salida / A3
(C) (re)
/ A1
S
/ A2
/ A1 S
/ A2 ≈ entrada / A1
salir / A2
/ A1
(mi) (F)
Por ejemplo, Figura 5.9 (b) muestra una transición interna, Figura 5.9 (e)
una transición externa, y Figura 5.9 (a) una autotransición. Los modelos en
Figura 5.9 (a) y Figura 5.9 (b) muestran el mismo comportamiento: en ambos modelos, cuando el evento mi ocurre,
actividad A1 es ejecutado; en ambos modelos, antes del evento mi ocurre, el sistema estaba en estado S tal como
fue después del procesamiento del evento mi. Figuras 5.9 (c) y 5.9 (d) no son de ninguna manera equivalentes,
como en
5.9 (c) , siempre que evento mi ocurre, el sistema sale del estado S y por lo tanto salida
actividad A3 se ejecuta, seguido de A1, y finalmente, cuando el sistema vuelve a entrar en estado S,
entrada actividad A2 es ejecutado. En contraste, en 5.9 (d) , evento mi no desencadena la salida y la entrada
del estado S, por eso no entrada y salida se ejecutan las actividades. Si se modela la misma actividad para
todas las transiciones entrantes de un estado, la ejecución de esta actividad se puede modelar como una entrada
actividad del estado en su lugar. Del mismo modo, las actividades para las transiciones salientes pueden
modelarse como un salida actividad. Por lo tanto,
Figuras 5.9 (e) y 5.9 (f) son semánticamente equivalentes.

5.4 Tipos de eventos
UML de fi ne varios tipos de eventos, siendo los más importantes el evento de señal, evento de
llamada, evento de tiempo, evento de cambio, cualquier evento de recepción y evento de
Evento de señal: finalización. los evento de señal se utiliza para la comunicación asincrónica. En este caso, un
nombre del evento (arg1, arg2) remitente envía una señal a un receptor y no espera una respuesta. El receptor es el objeto
modelado y el emisor puede ser otro objeto o el mismo objeto que el receptor. La recepción de
la señal se procesa como un evento. El nombre del evento corresponde al de la señal y se
pueden especificar argumentos. Por ejemplo, Derecha-
ratón hacia abajo o enviar sms (mensaje) son eventos de señal.
Evento de llamada: Eventos de llamada son llamadas de operación. El nombre del evento corresponde al nombre
opName (par1, par2) de una operación que incluye parámetros, por ejemplo, jefe-
cupy (usuario, sala de conferencias) o registrarse (examen).
Evento de tiempo: Eventos de tiempo habilitar transiciones de estado basadas en el tiempo. El tiempo especificado
después de (período) puede ser relativo, basado en el tiempo de ocurrencia del evento en el estado actualmente activo, o
cuando el tiempo) absoluto. Los eventos de tiempo relativo consisten en la palabra clave después y un lapso de tiempo entre
paréntesis, por ejemplo, después (5 segundos). Los eventos de tiempo absoluto se modelan con la palabra
clave cuando y una hora entre paréntesis, por ejemplo, expresiones como cuando (hora == 16:00)
o cuando (fecha == 20150101) indican eventos de tiempo absoluto.

Cambio de evento: Puedes usar un cambio de evento para monitorear permanentemente si una condición se vuelve
cuando (boolExpr) verdadera. Un evento de cambio consta de una expresión booleana entre paréntesis y la palabra
clave anterior cuando. Ejemplos de cambio
los eventos son cuando (inscripciones == número de asientos) o cuando( x> y). El evento
ocurre tan pronto como el valor de la expresión lógica cambia de falso a verdadero. Se
pierde, como cualquier otro evento, si, por ejemplo, un guardia impide que se procese el
evento. Sin embargo, solo puede ocurrir nuevamente cuando el valor de la expresión
booleana cambia de falso a verdadero nuevamente, lo que significa que la expresión debe
haber sido falsa mientras tanto. En Figura 5.10 , el sistema está en el estado ejecución del curso.
Tan pronto como fin de semestre cambia de falso a verdadero, el sistema verifica si hay calificaciones
disponibles. Si este es el caso, hay un cambio de estado a certi fi cados emitidos. Si no hay calificaciones
disponibles, el sistema permanece en el estado ejecución del curso y el evento de cambio se pierde.
Incluso si el guardia
[calificaciones disponibles] se hace realidad en un momento posterior, no puede haber transición. El
sistema no vuelve a comprobar la protección hasta fin de semestre

ha cambiado a falso y luego verdadero de nuevo. Esto expresa que los certificados solo se pueden
emitir al final de un semestre, y luego solo si hay calificaciones disponibles.
Es importante enfatizar aquí que los eventos de tipo cambio de evento no deben confundirse con
los guardias para transiciones. El sistema comprueba constantemente la expresión booleana de un
evento de cambio y el evento puede disparar
5.4 Tipos de eventos 95
cuando (fin de semestre) Figura 5.10

Ejemplo de un evento de cambio
curso [calificaciones disponibles] certificados
ejecución emitido
ger una transición de estado en el instante en que se hace realidad. Por el contrario, una guardia solo se
evalúa cuando ocurre el evento relacionado. Por lo tanto, un guardia nunca puede desencadenar un
evento por sí mismo. En Figura 5.11 un pequeño ejemplo ilustra esta diferencia. Un estudiante puede estar
en uno de dos estados, a saber asistir a la conferencia o ocio. En (a), el estudiante escucha la conferencia
durante 90 minutos. Después de 90 minutos, hay una transición de estado al estado ocio.
Por el contrario, en (b), el alumno escucha hasta el final de la conferencia, ya que es solo cuando el evento conferencia
terminó Ocurre que el sistema comprueba si la conferencia ya ha durado 90 minutos. Si modelamos el
contenido como se muestra en (a), esto significa que el tiempo libre comienza para el estudiante después de
exactamente 90 minutos. De acuerdo con el modelo (b), el tiempo libre comienza cuando el conferenciante
termina la conferencia, pero como mínimo después de 90 minutos, ya que la guardia solo es verdadera
entonces. Tenga en cuenta que este modelo asume que la conferencia nunca dura menos de 90 minutos.
Figura 5.11
asistir a la conferencia después (90min)
ocio Conferencia y tiempo libre
hacer / escuchar la conferencia
(a) Modelado con ChangeEvent
asistir a la conferencia la conferencia terminó [time≥90min]

ocio
hacer / escuchar la conferencia
(b) Modelado con guardia
Puedes usar un cualquier evento de recepción para especificar un tipo de transición "más". Para Cualquier evento de recepción:
este tipo de evento, la palabra clave todos se adjunta a una transición como un evento que ocurre todos
cuando ocurre cualquier evento que no desencadena otra transición para el estado activo. En Figura
5.12 , el sistema cambia de estado S1 a estado S2 si evento e1 ocurre. Si e2 ocurre, hay una
transición al estado S3. Si ocurre cualquier otro evento, el sistema cambia a S4.
UN evento de finalización tiene lugar cuando se completa todo lo que se debe hacer en el Evento de finalización
estado actual. Esto incluye entrada y hacer actividades, así como la finalización de estados anidados,
si los hay (consulte la sección siguiente). Si un estado tiene una transición saliente sin ningún evento
especificado, el evento de finalización desencadena esta transición.
Figura 5.12
Transición con cualquier evento de e1
S2
recepción
S1
e2
hacer / A1 S3
todos
S4
5.5 Estados compuestos
Un estado simple consta solo de transiciones internas y externas y entrada, hacer y salida actividades,
Estado compuesto ... si las hay. No tiene más subestructura. UN estado compuesto, también conocido como estado
complejo o un estado anidado,
S
es un estado que contiene muchos otros estados, así como pseudoestados. Los estados contenidos
S1 S2 dentro de un estado compuesto se conocen como su subestados.
Un estado compuesto puede tener un estado inicial. Una transición al límite de este estado
compuesto puede entenderse como una transición implícita al estado inicial del estado compuesto.
. . . consta de subestados Si varios estados están anidados entre sí, es decir, si un estado compuesto contiene más estados
compuestos, que a su vez también contienen más estados compuestos, y así sucesivamente, el
Profundidad de anidación arbitraria ciclo de vida de un nuevo objeto siempre comienza en el estado inicial más externo. . Lo mismo se
de subestados aplica al estado final. Si un estado compuesto tiene un estado final, una transición que conduce a
este estado final crea un evento de finalización del estado compuesto en el que se encuentra el
estado final. Alternativamente, las transiciones pueden conducir hacia o desde un subestado de un
estado compuesto.
Figura 5.13 muestra ejemplos de cómo se puede entrar o salir de un estado compuesto. Si un
Sinónimos: objeto está en estado S3 y evento e2 ocurre, estado compuesto
S1 se activa y el estado inicial de S1 es ingresado. Esto desencadena la transición inmediata
• Estado compuesto
• Estado complejo al estado S1.1. Sin embargo, si e1 ocurre mientras el objeto está en S3, estado S1.2 se activa.
• Estado anidado Si el objeto está en estado S1.2
y e4 ocurre, el objeto sale del estado de nivel superior S1, se ejecuta la transición de
finalización asignada y el estado de destino correspondiente S2
Está activado. Sin embargo, si e3 ocurre mientras el objeto está en estado S1.1, el objeto cambia
inmediatamente a estado S2 y no llega S1.2.
Si e3 ocurre mientras el objeto está en estado S1.2, el sistema permanece en
S1.2 y el evento se pierde porque no se consume dentro S1.2,
ni el evento se especifica en una transición que se origina en S1.2 o los estados en los que está
contenido.
5.5 Estados compuestos 97
e1 Figura 5.13
S3
Ejemplo de entrada y salida de
un estado compuesto
e2 S1
e4 e4 e3
S1.1 S1.2 S2
e3
5.5.1 El estado ortogonal
Si un estado compuesto está activo, solo uno de sus subestados está activo en cualquier
momento. Si desea lograr estados concurrentes, un estado compuesto se puede dividir en dos o
más regiones, por lo que un estado de cada región siempre está activo en cualquier momento.
Este tipo de estado compuesto se llama estado ortogonal. Cada región de un estado ortogonal
puede tener un estado inicial. Una transición al límite del estado ortogonal activa los estados Estado ortogonal
iniciales de todas las regiones. Cada región también puede tener un estado final. En este caso, el
S1
evento de finalización del estado de nivel superior no se crea hasta que se alcanza el estado final
región A
en todas las regiones. Si no se va a entrar o salir de un estado ortogonal a través de sus estados
S2
iniciales y estados finales, se requieren los nodos de sincronización y paralelización presentados
brevemente en la Sección 5.2. El borde entrante del nodo de paralelización puede mostrar
región B
eventos, guardias y actividades, pero en los bordes salientes, solo se permiten actividades. Cada
borde de salida debe apuntar a un subestado de una región diferente del mismo estado ortogonal. S3 S4
Por el contrario, todos los bordes que terminan en un nodo de sincronización deben tener su
origen en subestados de diferentes regiones del mismo estado ortogonal. El borde saliente de un
nodo de sincronización puede mostrar eventos, guardias y actividades, pero en los bordes
entrantes, solo se permiten actividades.
Figura 5.14 muestra un ejemplo de cómo se puede entrar o salir de un estado ortogonal. Si S1
se ingresa vía estado S2, los estados iniciales de las dos regiones ortogonales región A y región B están
activados. Sin embargo, si
S1 se ingresa a través de la transición que procede de S3, SA2 y SB2 están activados. Hay cuatro
formas diferentes de salir del estado. S1. Si se ha alcanzado el estado final en ambas regiones, se
crea un evento de finalización y hay una transición de finalización a S4 a través del borde
"desnudo". Si evento
e3 ocurre mientras el objeto está en cualquier subestado de S1, cualquier actividad en curso en S1 terminan,
el objeto sale de todos los subestados de S1, y hay una transición inmediata a S5. Si todas las
actividades en SA3 y SB3 se completaron antes de los eventos e1 y e2 ocurrido, hay una transición a
S5.
Evento e4 ofrece la última oportunidad para salir S1. Si el sistema está en estado
SA2 y evento e4 ocurre, cualquier actividad en curso en S1 están terminados,
el objeto sale de todos los subestados de S1, y hay una transición al estado S4.
Esto tiene lugar independientemente del estado de región B el objeto estaba en el momento del
evento e4 ocurrió.
Figura 5.14 S1
Ejemplo de entrada y salida de
región A
un estado ortogonal e4
e1
S2 SA1 SA2 SA3 S4
S3 S5
región B
e2 e3
SB1 SB2 SB3
5.5.2 Submáquinas
Si varios diagramas de máquinas de estados comparten partes con el mismo comportamiento, no es

práctico modelar el mismo comportamiento varias veces, porque esto haría que los modelos fueran
difíciles de mantener y reutilizar. En esta situación, la recomendación es reutilizar partes de los diagramas
de máquinas de estados en otros diagramas de máquinas de estados. Para hacer esto, modele el
Metralleta comportamiento que se reutilizará en un metralleta se accede desde otro diagrama de máquina de estado estado
de submáquina. Una submáquina es un tipo especial de estado compuesto. El nombre del estado de la
Estado de la submáquina submáquina toma la forma estado: estado de submáquina.
S: SMS
Además, opcionalmente puede anotar el estado de la submáquina con un símbolo de
Símbolo de refinamiento perfeccionamiento. Si se modela un estado de submáquina en un diagrama de máquina de estado,

tan pronto como se activa el estado de submáquina, se ejecuta el comportamiento de la
submáquina. Esto es equivalente a llamar a una subrutina en lenguajes de programación. Si hay
Metralleta ∼ = una transición al límite del estado de la submáquina, se activa el estado inicial de la submáquina
subrutina referenciada. Si se alcanza un estado final en la submáquina, se activa el estado del diagrama de
la máquina de estado de llamada al que conduce la transición desde el estado de la submáquina. Figura
5.15 muestra los estados que un estudiante puede tomar cuando participa en un curso específico,
mediante el cual el modelado de los estados positivo y negativo ha sido transferido a la submáquina
grado, que se hace referencia en el estado calificado.

Figura 5.15
grado Los estados de un estudiante en un curso
no graduado calificado: grado
grado
corrección [nueva calificación = 5]
positivo negativo
corrección [nuevo grado <5]
5.5.3 Puntos de entrada y salida
Si debe entrar o salir de un estado compuesto a través de un estado que no sea el inicial y el final,
puede modelarlo usando entrada y puntos de salida. Un punto de entrada está modelado por un
pequeño círculo en el límite del estado compuesto y tiene un nombre que describe el punto de Punto de entrada
entrada. El punto de entrada tiene una transición al estado donde debería comenzar la ejecución.
Si una transición externa conduce a este punto de entrada, la ejecución puede iniciarse con el
estado deseado sin que la transición externa tenga que conocer la estructura del estado
compuesto. Si el estado compuesto no va a terminar como de costumbre cuando se alcanza el
estado final, sino a través del final de otro estado, puede modelar los puntos de salida de la misma
manera. Un punto de salida se denota en el límite del estado compuesto por un pequeño círculo
que contiene un X y tiene un nombre que describe el punto de salida. Si una transición externa tiene Punto de salida
el punto de salida como estado fuente, esto se relaciona con el estado final determinado
alternativamente, pero sin que la transición externa tenga que conocer la estructura del estado
compuesto. Los puntos de entrada y salida son, por tanto, un tipo de mecanismo de
encapsulación. En la práctica, se utilizan en particular al modelar y utilizar submáquinas.
Estado compuesto con
punto de entrada y salida
S
Figura 5.16 (a) muestra una modi fi cación del ejemplo de Figura 5.13 .
En lugar de la transición que conduce directamente a S1.2, se utiliza un punto de entrada. Del mismo S2
modo, S1.1 se sale por un punto de salida. Figura 5.16 (b) muestra la vista externa de S1. Los puntos de S1
entrada y salida son visibles como interfaces para S1 pero la estructura detallada de S1 permanece S3
invisible para las transiciones externas.
Figura 5.16 e1
S3
Ejemplo de entrada y salida de un
estado compuesto con puntos de
S1.2
entrada y salida (ver Figura 5.13 ) e2 S1
e4
S1.1 S1.2 S2
S1.1 e3
(un)
e1
S3
S1.2
e2 S1
S2
S1.1 e3
(segundo)
Figura 5.17 muestra una modi fi cación del ejemplo de Figura 5.8 , en
que los subestados del estado calificado se ingresan a través de puntos de entrada. Así fuera del estado calificado
sin detalles internos de calificado tiene que ser conocido.
Figura 5.17
Modelado del ejemplo de Figura
5.8 con puntos de entrada
retirar
registrado
calificado
positivo
actuación
positivo
< 5]
a de
[gr
corrección corrección
no grado
[nuevo [nuevo
calificado
[gr grado <5] grado = 5]
ade
=5
]
negativo
negativo
5.5.4 El estado histórico
Estados de historia se utilizan cuando, después de una transición externa que se aleja de un estado
compuesto, el sistema debe regresar al mismo subestado que estaba activo antes de que ocurriera la
transición. El estado histórico recuerda qué subestado de un estado compuesto estuvo activo por Estado histórico
última vez. Si una transición desde el exterior conduce al estado histórico, el estado histórico activa el
subestado "antiguo" y todos entrada las actividades se llevan a cabo secuencialmente desde el exterior
hacia el interior del estado complejo. Un estado de historial puede tener cualquier número de bordes
entrantes pero solo un borde saliente. El borde de salida no debe tener eventos ni guardias. Su
objetivo es el subestado que debe estar activo si el estado compuesto nunca estuvo activo antes y,
por lo tanto, no hay un "último subestado activo", o si el estado compuesto se salió recientemente de
la "forma estándar" mediante el estado final alcanzado.
Hay dos tipos de estados históricos: el estado de historia superficial y el Estado de historia profunda. Estado de historia superficial
Cada estado compuesto puede tener un máximo de un estado histórico superficial y un estado histórico
profundo. El estado de historia superficial restaura el estado que está en el mismo nivel del estado
H
compuesto que el estado de historia superficial en sí. En contraste, el estado de historia profunda señala
el último subestado activo en toda la profundidad de anidación. Estado de historia profunda
H*
Figura 5.18 ilustra la diferencia entre los estados históricos superficiales y profundos
con un ejemplo.
Figura 5.18
S4
Estado de historia superficial y estado
S1 de historia profunda
e2 e3 e5
S1.1 S1.2 S1.3
e10
e7
e9 e4
S5 H
S3
e8 e6
H* S3.1 S3.2
Supongamos que el objeto está en estado S1 y ahí en subestado S1.2

cuando e10 ocurre y fuerza una transición a S5. El estado de historial superficial recuerda que el objeto
estaba previamente en estado S1 porque S1 está al mismo nivel que el propio estado histórico
superficial. En contraste, el estado de historia profunda recuerda que el último estado activo fue en
realidad S1.2, ya que conoce la posición en toda la profundidad de anidación. Si evento e8 ocurre, el
estado de historia profunda activa el estado S1.2. Sin embargo, si e9 ocurre en cambio, el
estado de historia superficial activa estado S1 y, por tanto, el estado inicial de

S1 está activo, lo que activa inmediatamente el primer estado real, S1.1. Supongamos ahora que el
estado S4 en el ciclo de vida de nuestro objeto nunca ha estado activo y el objeto está actualmente
en estado S5. Si e8 ahora ocurre, el estado de historia profunda activa el estado S3 y así
implícitamente S3.1, como apunta el borde saliente del estado histórico profundo S3. Si e9 ocurre en
cambio, el borde del estado de historia superficial apunta al límite de S4 y por lo tanto el estado
inicial de S4 Está activado. A su vez, esto activa S1, que, a través de su estado inicial, activa el primer
estado real, S1.1.
Figura 5.19 muestra los estados que toma un estudiante durante un programa de estudio.
Inicialmente, un programa de estudios es inactivo. Si se han pagado las tasas de matrícula (y, por lo
tanto, el estudiante se ha registrado para el programa de estudios), el programa de estudios se
convierte en activo. Las tasas de matrícula deben pagarse al comienzo de cada semestre. Si esto no
sucede, el programa de estudios se convierte inactivo de nuevo. Durante el curso de un programa de
estudio activo, el estudiante progresa a través de los niveles Master de bachiller, y doctorado. Si el
estudiante no paga las tasas de matrícula para un semestre en particular, por ejemplo, porque el
estudiante quiere tomar un descanso de un semestre, después de este semestre, debería ser posible
que el estudiante regrese a la etapa del programa de estudio que se alcanzó antes del descanso. El
estado de historia profunda asegura que esto sea posible.
5.6 Secuencia de eventos
En un ejemplo final, ilustraremos la relación de eventos, guardias y actividades en estados y

en transiciones de estados. Se presta especial atención al orden en que se ejecutan las
actividades.
Figura 5.20 muestra un ejemplo abstracto de un diagrama de máquina de estados. Dependiendo
de qué eventos ocurran, existen diferentes transiciones de estado. Las variables x, y, y z se establecen
en diferentes valores durante la ejecución de determinadas actividades. Usaremos el ejemplo para
resolver la siguiente pregunta: ¿En qué estado se encuentra la máquina de estados después de las
ocurrencias de los eventos? e2, e1, e3, e4, e1, y e5 ( en ese orden dado) y qué valores son las variables x,
y, y z ¿ajustado a?
Al principio, la máquina de estado está en estado UNA, por lo que antes de la entrada en el estado UNA,
La variable X se le asignó el valor 2. Cuando la máquina de estado entra en estado UNA, variable z se
establece en el valor 0. El sistema ahora permanece en el estado UN hasta el evento e2 Ocurre —el primer
evento en este ejemplo específico—. Tan pronto como e2 ocurre, la máquina de estado sale del estado
A. Cuando sale la máquina del estado UNA, El valor de z se incrementa en el valor 1; z es por
tanto 1. Hay una transición al estado C. Como parte de esta transición, el valor de z se multiplica
por 2; z es por tanto 2. Cuando
5.6 Secuencia de eventos 103
Figura 5.19
Programa de estudio dejar la universidad
Estados de una educación
inactivo
académica
pagar las tasas de matrícula Nuevo semestre dejar la universidad

[tasas de matrícula no pagadas]
programa de estudio activo
H*
soltero
soltero terminó licenciatura

la licenciatura terminado
inscribirse para la maestría
Maestro
maestro terminó maestría

la licenciatura terminado
inscribirse para el doctorado
terminó
doctorado
la máquina de estado entra en estado compuesto C, z aumenta de nuevo en 1 y ahora tiene el valor 3.
Además, y se establece en el valor 2. El estado inicial del estado compuesto C conduce directamente al
estado C1; cuando entra la máquina del estado C1, z se vuelve a multiplicar por 2 y ahora tiene el valor
6.
Si e1 ahora ocurre, la máquina de estado permanece en estado C1, ya que la ocurrencia de este evento
"solo" desencadena una transición interna y se procesa dentro
C1. La variable X se establece en el valor 4. Luego e3 ocurre, y el sistema verifica qué valor z tiene
en este momento. Como z actualmente tiene el valor 6, el guardia [ z == 6] es verdad. Cuando sale la
máquina del estado C1, z se establece en el valor 3 y hay una transición de estado a estado C2. Cuando
entra la máquina estatal C2, y se establece en 0. El siguiente evento de la secuencia es e4, y por lo
tanto la máquina de estado sale C2 y la actividad de salida de
C2 es ejecutado; X por lo tanto se convierte en -1. La máquina de estado luego sale del estado compuesto C y
se ejecuta la actividad de salida de este estado. La variable y
se establece en el valor 1. Cuando la máquina de estado ingresa E, y se incrementa en el valor 1. La

variable y por lo tanto se convierte en 2. La ocurrencia del evento e1 hace que el estado de salida de la
máquina de estado MI. El estado histórico vuelve al último subestado activo de C, eso es para C2. Como
resultado de la ejecución
Figura 5.20
UN segundo
Diagrama de la máquina de estados para
demostrar una secuencia de eventos /x=2 entrada / z = 0 e3 [x <0] / x ++ entrada / y = 2

e1 / y = 1 e4 / x ++
salir / z ++
e2 / z = z * 2 e5 [x == 0]
C
entrada / z ++; y = 2
salir / y = 1
C1 C2
e3 [z == 6]
entrada / z = z * 2 entrada / y = 0 e5
e1 / x = 4 e3 / año-- salir / x = -1
salir / z = 3
e3 [z == 3] e4 e1
re mi
e2
entrada / x = 0 entrada / año ++
e1 / año ++ e3 e2 / z = 1
de las actividades de entrada de C, El valor de z aumenta de 3 a 4 y y se establece en el valor 2. La

ejecución de la actividad de entrada de C2 significa que
y se sobrescribe con el valor 0. El último evento en este ejemplo es e5.
Este evento lleva a la máquina de estados al estado final de estado compuesto
C. Cuando sale la máquina del estado C2, x se establece en el valor -1, que es irrelevante ya que X ya
tiene este valor. Hay una ventaja que se aleja del estado C donde no se especifica ningún evento en
este borde. El evento de finalización creado por el final de C así conduce a una transición completa al
estado UN a través de este borde "vacío". Cuando sale la máquina del estado C, y se establece en el
valor 1. Cuando la máquina de estado ingresa A, z se establece en 0. Por lo tanto, después de los
eventos e2, e1, e3, e4, e1, y e5, nuestra máquina de estado está en estado A, x tiene el valor - 1, y es 1, y
z tiene el valor 0. Cuadro 5.1
resume los pasos individuales.

5.7 Resumen 105
Cuadro 5.1
Estado del evento ingresado X y z Cambios de estado y asignaciones de
variables para x, y, y z
después de la ocurrencia de los eventos
comienzo UN 2 0
individuales
e2 C1 2 6
e1 C1 4
e3 C2 0 3
e4 mi -1 2
e1 C2 0 4
e5 UN -1 1 0
5.7 Resumen
Un diagrama de máquina de estados puede utilizarse para mostrar los estados en los que un
sistema o un objeto puede encontrarse durante su “ciclo de vida”, es decir, desde su creación hasta
su destrucción. El diagrama también muestra las condiciones bajo las cuales ocurren las
transiciones entre estos estados. Los eventos y actividades desencadenados por estos eventos se
pueden modelar en el diagrama. También puede especificar guardias que deben solicitar un evento
para desencadenar actividades relacionadas o una transición de estado. Los conceptos adicionales
le permiten modelar diagramas de máquinas de estados más complejos. Los nodos de
paralelización y sincronización, así como los estados ortogonales, le permiten modelar
simultáneamente estados activos y cadenas de estados. Los estados de historia superficial y
profunda, así como los puntos de entrada y salida, permiten una entrada definida en subestados
transitivos anidados de estados compuestos. Cuadro 5.2 .
Cuadro 5.2
de la máquina de estados S Descripción de un "lapso de tiempo" específico en el que
entrada / Actividad (...) un objeto se encuentra durante su "ciclo de vida". Dentro

Estado
hacer / Actividad (...) de un estado, las actividades se pueden ejecutar en el
salida / Actividad (...) objeto.
mi Transición de estado mi de un estado de origen

Transición S T
S a un estado objetivo T
Estado inicial Inicio de un diagrama de máquina de estados
Estado final Fin de un diagrama de máquina de estados
Terminación del diagrama de máquina de estados de un

Terminar nodo
objeto
Nodo desde el que pueden proceder múltiples
...
Nodo de decisión
transiciones alternativas
División de una transición en múltiples transiciones

Nodo de paralelización ...
paralelas
Fusión de múltiples transiciones paralelas en una

...
Nodo de sincronización
sola transición
Estado histórico superficial y "Dirección de retorno" a un subestado o un subestado

S.S*
profundo anidado de un estado compuesto
Capítulo 6
El diagrama de secuencia
Si bien el propósito del diagrama de la máquina de estados presentado en el último capítulo es

modelar intra- comportamiento del objeto, es decir, el ciclo de vida de un objeto, en este capítulo Comportamiento intraobjeto
examinamos el modelado del enterrar- comportamiento de los objetos, es decir, las interacciones entre versus
los objetos de un sistema. comportamiento entre objetos
Un Interacción especifica cómo se intercambian los mensajes y los datos entre los Interacción
interlocutores. los socios de interacción son humanos, como profesores o estudiantes, o no Socio de interacción
humanos, como un servidor, una impresora o un software ejecutable. Una interacción puede ser
una conversación entre varias personas, por ejemplo, un examen oral. Alternativamente, una
interacción puede modelar protocolos de comunicación como HTTP o representar el intercambio
de mensajes entre humanos y un sistema de software, por ejemplo, entre un profesor y el sistema
de administración de estudiantes cuando el profesor publica los resultados del examen. Una
interacción también puede ser una secuencia de llamadas a métodos en un programa o señales
como una alarma de incendio y los procesos de comunicación resultantes.
Una interacción describe la interacción entre múltiples socios de interacción y comprende una
secuencia de mensajes. El envío o la recepción de un mensaje puede desencadenarse por la Mensaje
ocurrencia de ciertos eventos, por ejemplo, la recepción de otro mensaje, y puede tener lugar a horas
especificadas, por ejemplo, a las 05:00. Las restricciones predefinidas especifican las condiciones
previas necesarias que deben cumplirse para que las interacciones tengan éxito. Por ejemplo, al
continuar con el proceso de comunicación descrito anteriormente, el profesor debe iniciar sesión en el
sistema antes de ingresar las calificaciones de los estudiantes.
En UML, usa diagramas de interacción para especificar interacciones. En un diagrama de interacción, Diagrama de interacción
siempre se modela un escenario concreto, lo que significa que el intercambio de mensajes tiene lugar
dentro de un contexto específico para cumplir una tarea específica. Las interacciones generalmente solo
describen una parte específica de una situación. A menudo hay otras rutas de ejecución válidas que la
interacción

Computación, DOI 10.1007 / 978-3-319-12742-2_6
108 6 El diagrama de secuencia
el diagrama no cubre. Aunque los datos intercambiados a través de los mensajes y procesados o
almacenados por los socios de interacción pueden representarse en diagramas de interacción, el
propósito de modelar interacciones no es especificar exactamente cómo se manipularán estos
datos. Si es necesario, puede agregar este tipo de información a los diagramas de interacción, pero
otros diagramas, como el diagrama de actividades (consulte el Capítulo 7), preferirían modelar esta
información.
Las interacciones ofrecen un mecanismo para describir las secuencias de

comunicación con diferentes niveles de detalle, tanto para los expertos en informática
como para los usuarios finales y los responsables de la toma de decisiones. Por tanto,
Uso de interacción los diagramas de interacción se utilizan en diversas situaciones. Por ejemplo, se utilizan
diagramas para representar la interacción de un sistema completo con su entorno. En este caso, el
sistema se puede interpretar como una caja negra de la que solo se conocen las
interfaces visibles al exterior. También puede utilizar diagramas de interacción para
modelar la interacción entre las partes del sistema a fin de mostrar cómo se puede
implementar un caso de uso específico (consulte el Capítulo 3). En las últimas fases de
diseño, puede utilizar diagramas de interacción para modelar con precisión la
comunicación entre procesos en los que los socios involucrados deben observar ciertos
protocolos.
De los cuatro diagramas de interacción que ofrece UML, el diagrama de secuencia es el que se
utiliza con más frecuencia, a menudo de forma informal para presentar rápidamente secuencias de
interacción. Sin embargo, en este capítulo, describimos los elementos del diagrama de secuencia en
detalle y examinamos cómo aplicarlos de acuerdo con el estándar UML. En la sección 6.7
presentamos brevemente los otros tres diagramas de interacción y los comparamos con el diagrama
de secuencia.
6.1 Socios de interacción
Línea de vida En un diagrama de secuencia, los socios de interacción se representan como líneas de vida.
Una línea de vida se muestra como una línea vertical, generalmente discontinua, que representa la
r: C
vida útil del objeto asociado a ella (ver Figura 6.1 ). En el extremo superior de la línea está la
cabecera de la línea de vida, un rectángulo que contiene una expresión en la forma roleName: Clase ( Figura
6.1 (c) ). Esta expresión indica el nombre del rol y la clase del objeto asociado con la línea de vida.
De la misma forma que para el diagrama de objetos (ver Capítulo 4.1 en la página
50), se puede omitir uno de los dos nombres. Si omite la clase, puede omitir los dos puntos ( Figura
6.1 (a) ); sin embargo, si especifica solo la clase, la
6.1 Socios de interacción 109
dos puntos deben preceder al nombre de la clase ( Figura 6.1 (b) ). Por tanto, puede definir un diagrama de
secuencia tanto a nivel de instancia como a nivel de clase.
También puede utilizar otros símbolos para los socios de interacción en lugar del rectángulo, por
ejemplo, la figura de palo que vimos en el diagrama de casos de uso para actores (consulte el Capítulo
3).
En un diagrama de secuencia, el uso del concepto de rol permite más flexibilidad de
modelado que las instancias o clases simples. Un objeto, es decir, una instancia de una
clase, puede asumir diferentes roles durante su vida. En nuestro sistema universitario, es Papel
bastante concebible que la persona helen Lewis es inicialmente solo un estudiante, que
luego se convierte en tutor y finalmente en profesor. Con cada nuevo rol, hay ciertas
actividades que Helen Lewis ya no puede realizar o que ya no tiene que realizar. Sin
embargo, hay otras actividades que ahora se le permite realizar en su lugar. Si
consideramos solo la clase del objeto helen Lewis Para re fl ejar los diferentes roles que
puede tomar el objeto, cada vez que cambia el rol del objeto tendríamos que borrar el
objeto y crear uno nuevo. Alternativamente, la clase debería cambiarse dinámicamente.
Figura 6.1
conferenciante
conferenciante :Profesor Tipos de líneas de vida
:Profesor
(un rol (b) Clase (c) Rol / Clase
conferenciante [i]
:Hilo yo
:Profesor
(d) Multivalor (e) Objeto activo (f) yo

papel
Los roles también se pueden conectar a más de un objeto. Este tipo de rol se conoce como papel
multivalor. Sin embargo, una línea de vida solo puede representar un objeto específico. Este Rol multivalor
objeto es seleccionado por un selector. El selector se especifica entre corchetes entre el nombre Selector
del rol y los dos puntos. Se puede formular en cualquier idioma, por ejemplo, en lenguaje natural,
pseudocódigo o Java. En el ejemplo de Figura 6.1 (d) , el selector es simplemente una variable
que actúa como índice. Para especificar varios objetos de
un papel como socios de interacción independientes simultáneamente, debe asignar cada objeto a una
línea de vida separada.
Objeto activo Un salvavidas puede representar un objeto activo. Los objetos activos se utilizan para modelar
procesos e hilos. Un objeto activo tiene su propio flujo de control, lo que significa que puede operar
:C
independientemente de otros objetos. La cabeza de una línea de vida que representa un objeto activo
tiene un límite doble a la izquierda y a la derecha. A menudo se usa una barra continua en lugar de la
línea discontinua (ver Figura 6.1 (e) ).
En Figura 6.1 (f) , el encabezado de la línea de vida contiene el nombre yo. Esto es necesario cuando una
clase abarca un determinado contexto de interacción y ella misma está involucrada en la interacción.
6.2 Intercambio de mensajes
El diagrama de secuencia es un diagrama bidimensional (ver Figura 6.2 ). Los socios de

interacción que participan en la interacción se presentan en el eje horizontal y deben
organizarse en un orden claro. El eje vertical modela el orden cronológico de la interacción.
Si el orden cronológico no se ha dejado de lado explícitamente, un evento más arriba en el
eje vertical tiene lugar antes de un evento que está más abajo en el eje vertical, siempre que
ambos eventos se refieran a la misma línea de vida.
En un diagrama de secuencia, las interacciones se consideran como una secuencia de
Especificación del evento especi fi caciones de eventos. Las especi fi caciones de eventos cubren el envío y la recepción de mensajes o
la ocurrencia de eventos basados en el tiempo, como un punto en
Figura 6.2
Acceso a la base de datos sd
Estructura de un diagrama de
secuencia
:Solicitud :Base de datos
Enviar
evento obtener datos()
Time axis
x = getData } Ejecución
especificación
Recibir
evento
processData (x)
Socios de interacción
6.2 Intercambio de mensajes 111
tiempo, por ejemplo. El eje de tiempo vertical determina la secuencia de ocurrencia de eventos en
una línea de vida, aunque esto no define el orden de ocurrencia de eventos en diferentes líneas de
vida. Un pedido a través de múltiples líneas de vida solo se fuerza si se intercambian mensajes
entre las diferentes líneas de vida. A menos que se especifique lo contrario, a continuación
asumimos que la transmisión del mensaje no requiere ningún tiempo, lo que significa que el evento Enviar evento y recibir evento
de envío en el remitente y el evento de recepción en el receptor tienen lugar al mismo tiempo. Esto
nos permite presentar las trazas de forma más compacta porque no tenemos que considerar
secuencias de eventos de envío y recepción y podemos concentrarnos en secuencias de mensajes. Rastro
La conexión cronológica entre un mensaje un y un mensaje segundo se expresa con el símbolo →.
Por ejemplo, un → segundo significa ese mensaje un se envía antes del mensaje segundo. Figura 6.3 resume
posibles secuencias de mensajes. Si los eventos de envío y recepción de dos mensajes tienen lugar a
lo largo de la misma línea de vida, el orden cronológico de estos eventos determina el orden de los
mensajes. En
Figura 6.3 (a) , mensaje un siempre debe tener lugar antes del mensaje C, como el evento de envío
de un tiene lugar antes del evento de envío de C. Si dos mensajes no tienen ningún compañero de
interacción común, no se especifica el orden de estos mensajes. En Figura 6.3 (b) , este es el caso
de los mensajes
un y C. Por tanto, hay dos posibles rastros: un → C y C → a. Si un mensaje segundo se
inserta entre un y C y este mensaje fuerza un y
C en un orden cronológico, el único rastro posible es un → segundo → C ( ver
Figura 6.3 (c) ).
Figura 6.3
Secuencias de mensajes y posibles
un un un rastros
segundo
C C C
T01: una C
T01: una C T01: una segundoC
T02: c un
(un) (segundo) (C)
La ejecución del comportamiento está indicada por dos eventos que inician y terminan esta
ejecución en la misma línea de vida (ver Figura 6.2 ). Este comportamiento se visualiza con una
barra y se denomina especificación de ejecución. Los autores del libro UML @ Work [23] Especificación de ejecución
diferencian entre directo y

indirecto comportamiento de ejecución. En el caso de ejecución directa, el socio de interacción Directo versus indirecto
afectado ejecuta el comportamiento especificado por sí mismo; con ejecución indirecta, el socio de ejecución
interacción delega la ejecución a otros socios de interacción. Las especi fi caciones de ejecución
superpuestas se muestran con barras superpuestas. Si un interlocutor se envía un mensaje a sí
mismo y Mensaje a uno mismo
la especificación de ejecución asociada debe modelarse explícitamente, dos barras de

especificaciones de ejecución se muestran superpuestas, por lo que la flecha del mensaje apunta a
la segunda barra, y en el caso de un mensaje síncrono, una flecha de respuesta discontinua al final
de la ejecución conduce hacia atrás a la barra original (ver processData (x) en Figura 6.2 ).
No tiene especificaciones de ejecución de modelo; son opcionales y se utilizan principalmente para

visualizar cuándo un compañero de interacción ejecuta algún comportamiento. Muchas herramientas
UML dibujan las barras correspondientes automáticamente como barras continuas desde el primer hasta
el último mensaje que afecta a un interlocutor. Por razones de claridad, en este libro generalmente no
mostramos especi fi caciones de ejecución en nuestros diagramas de secuencia.
6.3 Mensajes
Mensaje En un diagrama de secuencia, un mensaje se representa como una flecha del remitente al
receptor. El tipo de flecha expresa el tipo de comunicación involucrada. UN mensaje sincrónico está
Mensaje sincrónico representado por una flecha con una línea continua y una punta de flecha triangular llena. Un mensaje
asincrónico está representado por una flecha con una línea continua y una punta de flecha
abierta. En el caso de los mensajes síncronos, el remitente espera hasta que ha recibido una mensaje
de respuesta Antes de continuar. El mensaje de respuesta está representado por una línea
Mensaje asincrónico
discontinua con una punta de flecha abierta. Si el contenido del mensaje de respuesta y el punto
en el que se envía y recibe el mensaje de respuesta están claros del contexto, entonces el
mensaje de respuesta puede omitirse en el diagrama. En comunicación asíncrona, el remitente
Mensaje de respuesta continúa después de haber enviado el mensaje. Se muestran dos ejemplos en Figura 6.4 .
Figura 6.4
conferenciante conferenciante
Ejemplos de (a) comunicación :Estudiante :Estudiante
:Profesor :Profesor
asíncrona y (b) síncrona
registrarse (curso) registrarse (curso)
confirmar (curso, "ok") registrarse: ″ ok ″
(un) (segundo)
6.3 Mensajes 113
En ambos casos, un estudiante se está comunicando con un profesor para inscribirse

en un curso. En el caso (a), el registro es vía e-mail, es decir, asincrónico. El estudiante no
espera explícitamente la recepción del mensaje de con fi rmación. En el caso (b), el alumno
se registra personalmente con el profesor y, por tanto, la comunicación es sincronizada. El
estudiante espera hasta recibir un mensaje de respuesta.
Los mensajes se identifican por un nombre, con la especificación opcional de

parámetros y un valor de retorno (ver Figura 6.5 ). Los parámetros están separados por
comas y entre paréntesis. El valor de retorno también se puede asignar opcionalmente a
una variable. Por tanto, un mensaje se puede etiquetar con var = m1: valor, por lo cual var es la
variable a la que se le asignará el valor de retorno, m1 especifica el nombre del mensaje, y valor
representa el valor de retorno real.
Figura 6.5
Variable Sintaxis de la especificación del
=
mensaje
Regreso
Nombre ( Parámetro ) :
valor
La recepción de un mensaje por parte de un objeto generalmente llama a la operación

correspondiente especificada en el diagrama de clases (ver Capítulo 4). En principio, los argumentos
pasados deben ser compatibles con los parámetros de la especificación de operación en el diagrama
de clases (ver Figura 4.8 en la página 57). Sin embargo, si usa nombres de parámetros para asignar los
valores a los parámetros correspondientes, ni el número ni el orden de los argumentos tienen que
coincidir con los parámetros en la especificación de operación.
UN mensaje para crear objetos es un tipo especial de mensaje. Está representado por una Crear un mensaje
flecha discontinua con una punta de flecha abierta que termina en la punta de la línea de vida
asociada al objeto a crear. La flecha está etiquetada con la palabra clave nuevo y corresponde a
llamar a un constructor en un lenguaje de programación orientado a objetos. Por ejemplo, en Figura nuevo
6.6 ,
un Profesor crea un nuevo ExamDate.
Si un objeto se elimina durante el curso de una interacción, es decir, una
evento de destrucción ocurre, el final de la línea de vida está marcado con una gran Evento de destrucción
X ( ver Figura 6.6 ). De lo contrario, una línea de vida se extiende hasta el extremo inferior del diagrama de secuencia.
Figura 6.6
Creación de un objeto :Profesor
nuevo
: ExamDate
setDate (fecha)
después de 2 semanas) getStudents ()
Mensaje encontrado Si el remitente de un mensaje es desconocido o no es relevante, puede expresarlo con mensajes
encontrados. En este caso, utiliza un círculo negro como fuente en lugar de especificar un
compañero de interacción que envía el mensaje. En Figura 6.7 , el remitente del mensaje Correo
encontró basura es desconocido.
Figura 6.7
conferenciante
Ejemplo de mensajes perdidos y
:Profesor
encontrados
anuncio (conferencia)
Correo basura
Mensaje perdido La contraparte del mensaje encontrado es el mensaje perdido. Con este tipo de mensaje, es
el receptor el que se desconoce o no es relevante. El receptor también se indica como un círculo
negro. El anuncio de la conferencia en
perdió Figura 6.7 se envía a un receptor arbitrario (y por lo tanto desconocido o irrelevante).
Hasta este punto, hemos asumido implícitamente que los mensajes se transmiten sin
Pérdida de tiempo pérdida de tiempo. Por supuesto, esto no es así siempre. Si desea expresar que el tiempo
mensaje transcurre entre el envío y la recepción de un mensaje, modele el mensaje como una línea
diagonal en el diagrama de secuencia en lugar de una línea horizontal. Como la dimensión
de tiempo se representa verticalmente, esto visualiza la duración requerida para la
transmisión de un mensaje. Este tipo de mensaje se conoce como mensaje que consume
tiempo o mensaje con duración.
Sinónimos: Figura 6.8 muestra un escenario de ejemplo. Un estudiante se inscribe en un programa de estudios
en el sistema de administración de estudiantes. Dentro de los siguientes dos o tres días, el estudiante
• Pérdida de tiempo
mensaje recibe un mensaje de con fi rmación que afirma que la inscripción fue exitosa. Esta con fi rmación se
• Mensaje con envía como una carta tradicional y por lo tanto está en tránsito durante unos días antes de que el
duración estudiante la reciba.
6.4 Fragmentos combinados 115
Figura 6.8
: StudentAdmin
:Estudiante Ejemplo de un mensaje que
Sistema
requiere mucho tiempo
inscribirse()
{2..3 días}
6.4 Fragmentos combinados
En un diagrama de secuencia, puede utilizar fragmentos combinados operadores) para modelar Fragmento combinado
varias estructuras de control explícitamente. Esto le permite describir una serie de posibles rutas de
ejecución de forma compacta y precisa. Dentro de un diagrama, un fragmento combinado se Operador
representa mediante un rectángulo, con el tipo de operador especificado por la palabra clave
respectiva en un pequeño pentágono en la esquina superior izquierda de este rectángulo. UML
ofrece 12 tipos diferentes de operadores. Dependiendo del tipo de operador, contiene uno o varios
operandos que a su vez pueden contener interacciones, fragmentos combinados o referencias a
otros diagramas de secuencia. Los diferentes operandos de un operador están separados entre sí Operandos
por líneas discontinuas horizontales. Las puertas describen las interfaces entre un fragmento
combinado y su entorno (consulte la Sección 6.5.2).
En [23], los 12 tipos diferentes de operadores se dividen en tres grupos:
• Ramas y bucles
• Simultaneidad y orden
• Filtros y afirmaciones
Cuadro 6.1 proporciona una descripción general de los operadores disponibles con las
palabras clave correspondientes y su semántica. A continuación, nos referimos a los diferentes
fragmentos según su operador, por ejemplo, un fragmento combinado con un alt operador se
conoce simplemente como un alt
fragmento.
Los fragmentos combinados se pueden anidar arbitrariamente, por lo que se especifica un marco
para cada fragmento. Alternativamente, los fragmentos anidados pueden compartir un marco. Si este
es el caso, en el pentágono de la esquina superior izquierda del marco, se especifican las palabras
clave correspondientes separadas por un espacio. El operador más a la izquierda está asignado al
fragmento más externo, y el operador más a la derecha está asignado al fragmento más interno (ver Figura
6.9 ).
Cuadro 6.1
Operador Propósito
Operadores para combinados
fragmentos alt Interacción alternativa
optar Interacción opcional

Ramas y bucles
lazo Interacción iterativa
rotura Interacción de excepción
seq Orden débil
estricto Orden estricto

Simultaneidad y orden
par Interacción concurrente
crítico Interacción atómica
ignorar Partes de interacción irrelevantes
considerar Partes de interacción relevantes

Filtros y afirmaciones
afirmar Interacción afirmada
neg Interacción no válida
6.4.1 Ramas y bucles
fragmento alt Puedes usar un alt fragmento para representar secuencias alternativas. Un alt
El operador tiene al menos dos operandos. Cada operando representa una ruta alternativa en la
alt [...]
ejecución, que corresponde aproximadamente a múltiples casos en lenguajes de programación,
[...] por ejemplo, el cambiar declaración en Java. Los guardias se utilizan para seleccionar la ruta a
ejecutar.
Interacción alternativa
Cada operando tiene un Guardia. Una guardia es una expresión booleana encerrada entre
corchetes. Si no hay guardia, entonces [ cierto] se asume como el valor predeterminado. Si varios
Guardia guardias son verdaderos simultáneamente, esto da como resultado un indeterminismo. En este caso,
no hay predicción con respecto a qué operando se selecciona. Esto contrasta con la semántica de las
declaraciones de conmutación en lenguajes de programación comunes, en los que las alternativas se
procesan normalmente de arriba a abajo. Un guardia especial es [ más], que se evalúa como verdadera
Guardia predefinida más si no se cumple ninguna otra condición. Si ninguno de los guardias se evalúa como verdadero, no se
ejecuta ningún operando y continúa la ejecución del fragmento circundante. Figura 6.10 muestra un
ejemplo de la alt
Figura 6.9
neg estricta crítica neg
fragmentos combinados anidados
estricto
crítico
: StudentAdmin Figura 6.10

:Estudiante :Base de datos Ejemplo de un alt y un
Sistema
optar fragmento
registrarse (matNo, examen)
entrar (matNo, examen)
status = enter: status
alt [estado == ok]
[estado == lista de espera gratis]
registro: ″ wl ″
optar [registrarse en WL == verdadero]
enterWL (matNo, examen)
enterWL: ″ ok ″
[más]
registro: ″ error ″
fragmento. Cuando un estudiante quiere registrarse para un examen, pueden ocurrir los
siguientes casos: (1) Todavía hay lugares disponibles y el estudiante puede registrarse. (2)
Hay un lugar disponible en la lista de espera. Luego, el estudiante debe decidir si va a la lista
de espera. (3) Si no hay lugar disponible para el examen o en la lista de espera para el
examen, el estudiante recibe un mensaje de error y no está registrado para el curso.
los optar fragmento corresponde a un alt fragmento con dos operandos, uno de los cuales está opt fragment
vacío. los optar El operador representa así una secuencia de interacción cuya ejecución real en
optar [...]
tiempo de ejecución depende de la guarda. En un lenguaje de programación, este operador se
especificaría como un Si
declaración sin un más rama. Figura 6.10 ilustra el uso de la optar fragmento. Si hay un
Interacción opcional
lugar disponible en la lista de espera, al registrarse para una tarea, el estudiante puede
decidir si tomar el
lugar en la lista de espera. Si el estudiante quiere estar en lista de espera, el estudiante tiene
que registrarse.
fragmento de bucle Puedes usar el lazo fragmento para expresar que una secuencia debe ejecutarse
Interacción repetida repetidamente. Este fragmento combinado tiene exactamente un operando. La palabra clave lazo va
lazo(...) [...] seguido de una especificación opcional del número de iteraciones del ciclo. Esta especificación
toma la forma ( mínimo máximo) o
(mínimo máximo), dónde min especifica el número mínimo de iteraciones que debe atravesar
el bucle y max denota el número máximo de iteraciones. Si min y max son idénticos, puede
omitir uno de los dos números y los puntos. Si no hay un límite superior para el número de
iteraciones de bucle, solo necesita especificar un asterisco ∗. En este caso, se supone que
el número mínimo de iteraciones es cero. Si la palabra clave lazo
no va seguida de ninguna especificación adicional del número de iteraciones,

∗ se asume como el valor predeterminado. Si es necesario, puede especificar una protección, que
luego se verifica para cada iteración dentro de la ( mínimo máximo) límites. Esto significa que la
guardia se evalúa tan pronto como se haya producido el número mínimo de iteraciones. Si la
condición subyacente no se cumple, la ejecución del ciclo se termina incluso si aún no se ha
alcanzado el número máximo de ejecuciones. Figura 6.11 expande el ejemplo de Figura 6.10 para
incluir el inicio de sesión del sistema que es necesario antes de que un estudiante pueda
registrarse para una tarea. La contraseña debe ingresarse al menos una vez y como máximo tres
veces, como se refleja en los argumentos de
lazo. Después del primer intento, el sistema comprueba si la contraseña se puede validar. Si
puede, es decir, la condición Contraseña incorrecta ya no es cierto, la ejecución de las
interacciones dentro del bucle cesa. El sistema también sale del ciclo si el estudiante ingresa
la contraseña incorrectamente tres veces. Este caso se trata luego con más detalle en el
siguiente rotura
fragmento.
romper fragmento los rotura fragmento tiene la misma estructura que un optar operador, es decir, consta de un
Manejo de excepciones solo operando más una guarda. Si la protección es verdadera, se ejecutan las interacciones
dentro de este operando, se omiten las operaciones restantes del fragmento circundante y la
rotura [...]
interacción continúa en el siguiente fragmento de nivel superior. los rotura Así, el operador ofrece
una forma simple de manejo de excepciones. Para nuestro ejemplo en Figura 6.11 , esto significa
que si la contraseña se ingresa incorrectamente tres veces, la condición contraseña incorrecta es
verdad. Así, el contenido de la rotura se ejecuta el fragmento, lo que significa que se envía un
mensaje de error al alumno y no se le permite registrarse para la tarea. El resto de la
interacción después del final de la rotura se omite el fragmento. Después de salir de la rotura operador,
estamos en el fragmento más externo del diagrama de secuencia y, por lo tanto, finaliza la
ejecución de este diagrama de secuencia. Si no estuviéramos en el fragmento más externo, el
diagrama de secuencia continuaría en el fragmento del siguiente nivel superior.

:Estudiante :Base de datos Ejemplo de rotura y
Sistema
lazo fragmento
lazo (1,3) [contraseña incorrecta]
iniciar sesión (nombre, pw)
cheque (nombre, pw)
rotura [contraseña incorrecta]
mensaje de error
6.4.2 Simultaneidad y orden
Como ya se comentó, la disposición de los eventos en el eje vertical representa el orden cronológico
de estos eventos, siempre que haya un intercambio de mensajes entre los socios de interacción
involucrados. Los fragmentos combinados que se describen a continuación le permiten controlar
explícitamente el orden de ocurrencia de eventos.
los seq fragment representa el orden predeterminado. Tiene al menos un operando y expresa fragmento seq
una secuencia débil que se especifica en el estándar UML [35] de la siguiente manera:
seq
1. El orden de los eventos dentro de cada uno de los operandos se mantiene en el resultado.
Interacción secuencial
2. Los eventos en diferentes líneas de vida de diferentes operandos pueden venir en cualquier orden. con orden débil
3. Los eventos en la misma línea de vida de diferentes operandos se ordenan de tal manera que un
evento del primer operando viene antes que el del segundo operando.
Podemos usar el seq fragmento para agrupar mensajes junto con un rotura Aplicación de los fragmentos
fragmento. Si la condición del rotura fragmento se convierte en verdad, los mensajes del seq seq en conjunto
los fragmentos que aún no se han ejecutado se saltan y la ejecución del diagrama de con un fragmento de rotura
secuencia continúa en el fragmento circundante. Figura 6.12 muestra un ejemplo de esto.

Un estudiante quiere registrarse para un examen. Si ya no hay plazas disponibles para
la fecha deseada, el alumno hace una reserva para la próxima fecha ( rotura
fragmento). En este caso, el alumno no es examinado por el profesor y la ejecución del
diagrama de secuencia continúa fuera del seq fragmento. Independientemente de si el
registro fue exitoso o no, el profesor envía el mensaje info () para el estudiante.
Tenga en cuenta que seq is the default order and usually does not have to be modeled
explicitly. But in this case, without the explicit modeling of the
seq fragment, the execution would have ended after the break fragment if incorrect password
was true. This is due to the fact that after executing the content of a break fragment, the
operations of the surrounding fragment are omitted. Without using seq, the surrounding
fragment would have been the outermost structure of the diagram and thus the whole
execution would have ended.
Figure 6.12 :StudentAdmin lecturer

Example of a seq :Student
System :Professor
fragment
seq
register(exam)
break [no free place]
reserve(exam)
examine()
info()
Figure 6.13 shows another sequence diagram together with all pos- sible traces. As this
diagram shows a weak order, the message c is not connected chronologically to messages a
and b and can be interleaved with these messages. As b is sent by interaction partner B and
d is also received by B, there is a chronological order between these two messages. In any
case, e is the last message.
strict fragment The strict fragment describes a sequential interaction with a strict order. The order of
event occurrences on different lifelines between different operands is significant,
strict
meaning that even if there is no message exchange between the interaction partners,
messages in an operand that is higher up on the vertical axis are always exchanged
before the messages in an operand that is lower down on the vertical axis.
Sequential interaction
with a strict order
Figura 6.13
:UNA :SEGUNDO :C :RE
Rastros en un seq fragmento
seq
Rastros:
un
T01: una segundoC re mi
segundo
T02: a C segundore mi
C
T03: c un segundore mi
re
mi
En el ejemplo de Figura 6.14 , un profesor solo imprime un examen cuando un

estudiante se ha registrado para ello. Si el estricto no se especificaron fragmentos, también sería posible
que el profesor imprima el examen antes de que el estudiante se registre.
: StudentAdmin conferenciante
Figura 6.14
:Estudiante :Impresora Ejemplo de estricto
Sistema :Profesor
fragmento
estricto
registrarse (examen)
imprimir (examen)
Figura 6.15 contiene la misma secuencia de mensajes que Figura 6.13 pero esta vez
basado en un orden estricto. Esto significa que los mensajes están en un orden fijo y solo hay
un rastro.
los par fragment le permite dejar de lado cualquier orden cronológico entre mensajes en fragmento par
diferentes operandos. Desde una perspectiva temporal, las rutas de ejecución de los diferentes
par
operandos se pueden intercalar siempre que se respeten las restricciones de cada operando
individual. Por tanto, el orden de los diferentes operandos es irrelevante. Sin embargo, esta
construcción no induce un verdadero paralelismo, es decir, no requiere el procesamiento
simultáneo de los operandos. Esto es contrario a lo que esperaríamos de la palabra clave "par" en par
operadores. De hecho, el par el operador realmente expresa concurrencia, es decir, el orden de los
eventos que se encuentran en diferentes operandos es irrelevante. los par Por lo tanto, el operador
tiene al menos dos operandos. Sin embargo, se debe respetar el orden dentro de un operando, lo Interacción concurrente
que significa que hay ejes de tiempo local para cada operando y estos deben
Figura 6.15
Rastros en un estricto fragmento
estricto
un
segundo
Rastros:
re
mi
adherirse. Figura 6.16 ilustra el uso de par. Al comienzo de un curso, el profesor debe realizar
determinadas actividades. El profesor debe responder a las consultas de los estudiantes, anunciar
las fechas de los exámenes y reservar salas de conferencias. Para hacer todo esto, el profesor debe
comunicarse con diferentes personas y sistemas. UN par El fragmento se utiliza para expresar que el
orden en que se completan estas actividades es irrelevante. Lo importante es que se respete el
orden predeterminado entre los mensajes dentro de un operando, lo que significa que, de acuerdo
con este diagrama de secuencia, un estudiante nunca se registrará en un curso primero y luego
enviará una consulta al profesor.
Figura 6.16 : StudentAdmin conferenciante

Ejemplo de par fragmento :Estudiante
Sistema :Profesor
par
consulta (curso)
registrarse (curso)
anuncieExam (curso)
reserva
LectureHall (curso)
Figura 6.17 muestra los posibles rastros de una interacción concurrente, por lo que de nuevo la
misma secuencia de mensajes que se muestra en Figura 6.13 y
Figura 6.15 se usa pero esta vez con un par fragmento. Ya no existe ninguna conexión
cronológica entre los mensajes de los diferentes operandos, lo que explica la multitud de
posibles rastros. Lo importante es que se respete el orden de los mensajes dentro de un
operando. Por ejemplo, mensaje un siempre debe venir antes del mensaje segundo.
Figura 6.17
Rastros:
:UNA :SEGUNDO :C :RE Rastros en un par fragmento
par T02: a C segundore mi
T03: a C re segundomi
un
T04: a C re mi segundo
segundo
T05: c un segundore mi
T06: c un re segundomi
C
T07: c un re mi segundo
re
T08: c re un segundomi
mi
T09: c re un mi segundo
T10: c re mi un segundo
Alternativamente, puede dejar de lado el orden cronológico de los eventos en una sola línea de
vida utilizando un coregión. Esto le permite modelar eventos concurrentes para una sola línea de vida. Coregion
El orden de ocurrencia de eventos dentro de una coregión no está restringido de ninguna manera,
aunque estén organizados a lo largo de la línea de vida. El área de la línea de vida que será cubierta
por la corregión está marcada por corchetes rotados 90 grados.
Por supuesto, una corregión puede contener más fragmentos combinados ejecutados como
un todo en cualquier orden. En los puntos correspondientes, la revocación del orden cronológico
se extiende a los correspondientes socios de interacción de la línea de vida con la corregión. El
ejemplo modelado en
Figura 6.16 con un par El fragmento está modelado en Figura 6.18 con un coregion.
Semánticamente no hay diferencia entre estos dos diagramas, lo que significa que no se define
ningún orden cronológico para los mensajes que el conferenciante envía y recibe.
:Estudiante conferenciante
Figura 6.18
:Estudiante Ejemplo de uso de una
Administración :Profesor
coregión
consulta (curso)
registrarse (curso)
anuncieExam (curso)
reserva
LectureHall (curso)
Para asegurarse de que ciertas partes de una interacción no se vean interrumpidas por
fragmento crítico eventos inesperados, puede utilizar el crítico fragmento. Esto marca un área atómica en la
interacción. Tenga en cuenta que el orden estándar seq se aplica dentro de un crítico fragmento.
crítico
Podemos ver un ejemplo de esto en Figura 6.19 . Los mensajes getExamDate y Registrarse están
ubicados en un crítico fragmento. Esto asegura que en el tiempo entre la solicitud de una fecha
de examen y el registro real, no puede aparecer ningún mensaje que reserve el lugar mostrado
Interacción atómica
como gratuito para otra persona. Si el crítico Si el fragmento no estaba presente, el profesor
podía ejecutar otra matrícula en el tiempo entre la solicitud de plazas libres y la matrícula de un
alumno, quitándole la plaza al alumno.
Figura 6.19 : StudentAdmin conferenciante

Ejemplo de crítico :Estudiante
Sistema :Profesor
fragmento
par
crítico
getExamDate
registrarse (examen, matNo)
registrarse (examen, matNo)
Figura 6.20 es diferente a Figura 6.17 solo en el hecho de que los mensajes
C y re están encerrados por un crítico fragmento. Esto significa que solo esos rastros son válidos en
qué mensaje re inmediatamente sigue al mensaje C.
Figura 6.20
Rastros en un crítico
fragmento
par Rastros:
un T01: una segundoC re mi
segundo T02: a C re segundomi
T03: a C re mi segundo
crítico T04: c re un segundomi

C
T05: c re un mi segundo
re
T06: c re mi un segundo
mi
6.4.3 Filtros y afirmaciones
Normalmente, un diagrama de secuencia no describe todos los aspectos de una interacción.

Algunas secuencias se resaltan y declaran explícitamente como trazas permitidas. En la mayoría
de los casos, sin embargo, existen más rastros permitidos pero no descritos que pueden ocurrir.
En algunos casos, debe documentar todos los posibles rastros que puedan ocurrir o documentar
los que no deben ocurrir. En resumen, un diagrama de secuencia contiene trazas válidas, no
válidas y no especificadas. Los fragmentos combinados del grupo "filtros y afirmaciones" definen
(i) qué mensajes pueden ocurrir pero no son relevantes para la descripción del sistema, (ii) qué
mensajes deben ocurrir y (iii) qué mensajes no deben ocurrir. Desafortunadamente, la
descripción de los fragmentos en este grupo es muy compacta en el estándar UML, por lo que
en muchas situaciones, numerosas preguntas sobre su significado exacto quedan sin respuesta.
A continuación ofrecemos un breve desglose de estos fragmentos, basando nuestra explicación
lo más cerca posible del estándar.
Los mensajes irrelevantes se indican con ignorar fragment, que expresa que estos mensajes ignorar fragmento
pueden ocurrir en tiempo de ejecución pero no tienen más importancia para las funciones Interacción irrelevante
representadas en el modelo. Los mensajes irrelevantes se indican entre paréntesis después de la
palabra clave ignorar. En Figura 6.21 (a) , el mensaje estado está contenido en el conjunto de
mensajes irrelevantes. Se utiliza únicamente para implementar la comunicación servidor-cliente y
es irrelevante para la presentación de la funcionalidad real.
Figura 6.21
: StudentAdmin : StudentAdmin
:Estudiante :Estudiante Ejemplos de una ignorar
Sistema Sistema
fragmento y un considerar
fragmento
ignorar {status} considere {iniciar sesión, registrarse}
iniciar sesión (usuario, pw) iniciar sesión (usuario, pw)
estado (″ en línea ″) estado (″ en línea ″)
registrarse (examen) registrarse (examen)
(un) (segundo)
En contraste, el considerar fragment especifica aquellos mensajes que son de particular importancia considerar fragmento
para la interacción bajo consideración. Estos mensajes también se muestran en notación de conjuntos Interacción relevante
después de la palabra clave. Todos los mensajes que ocurren en el considerar fragmento pero que no se
especifican en el conjunto de mensajes relevantes se clasifican automáticamente como irrelevantes. Ellos
deben
ser tratados como si estuvieran listados como argumentos de un ignorar fragmento (ver
Figura 6.21 (b) , que es equivalente a Figura 6.21 (a) ). los afirmar El fragmento identifica ciertos rastros
afirmar fragmento modelados como obligatorios. No se permiten las desviaciones que ocurren en la realidad pero que no
Interacción afirmada están incluidas en el diagrama. En efecto, esto significa que la implementación requiere un modelado
preciso y el modelo es una especificación completa. Figura 6.22 (a) contiene un ejemplo
correspondiente. Cuando un estudiante se registra para un examen en el sistema de administración de
estudiantes, el estudiante recibe un correo electrónico después de la inscripción. Si esta secuencia no
se implementa exactamente como se especifica, se produce un error.
fragmento neg Con el neg fragmento modela una interacción no válida, es decir, describe situaciones que no
Interacción no válida deben ocurrir. los neg El fragmento consta exactamente de un operando. Puede utilizar este
fragmento para resaltar explícitamente los errores que ocurren con frecuencia y para representar
secuencias críticas e incorrectas. Sin embargo, no hay límite para el número de posibles
secuencias de interacción que deben o no deben ocurrir, por lo que no debe asumir que el uso de
la neg El fragmento cubrirá todas las situaciones indeseables. Figura 6.22 (b)
expresa que un estudiante nunca puede registrarse para un examen directamente con el profesor.
Figura 6.22
: StudentAdmin conferenciante
Ejemplos de una afirmar :Estudiante :Estudiante
Sistema :Profesor
fragmento y un neg
fragmento
afirmar neg
registrarse (examen) registrarse (examen)
correo de confirmación
(un) (segundo)
6.5 Otros elementos del lenguaje
Para permitirnos especificar interacciones con mayor precisión y representarlas con mayor claridad, el
diagrama de secuencia ofrece los siguientes elementos de lenguaje adicionales que se describen en detalle
a continuación. Referencias de interacción y
marcadores de continuación le permiten dividir los diagramas de secuencia en módulos para

estructurarlos más claramente. Puertas le permite modelar el flujo de mensajes que tiene lugar
entre diferentes diagramas de secuencia
6.5 Otros elementos del lenguaje 127
o fragmentos combinados. Parámetros y atributos locales especificar los valores necesarios para la
ejecución de una interacción. Limitaciones de tiempo definir cuándo deben ocurrir ciertos eventos y invariantes
de estado especificar las condiciones que son necesarias para la ejecución de la interacción.
6.5.1 Referencias de interacción
Un referencia de interacción le permite integrar un diagrama de secuencia en otro Referencia de interacción
diagrama de secuencia. Por un lado, esto le permite reutilizar interacciones que ya ha

modelado y, por otro lado, le permite dividir secuencias de interacción complejas en
módulos y representarlas en forma simple. Al igual que un fragmento combinado, una
referencia de interacción se representa en un rectángulo con un pentágono en la esquina
superior izquierda. El pentágono contiene la palabra clave árbitro. El rectan-
Figura 6.23
sd Iniciar sesión
Ejemplo de una referencia de
interacción
: StudentAdmin
Sistema
lazo (1,3) [contraseña incorrecta]
iniciar sesión (nombre, pw)
cheque (nombre, pw)
rotura [contraseña incorrecta]
mensaje de error
Registro de examen sd
: StudentAdmin
:Estudiante
Sistema
árbitro
Iniciar sesión
gle en sí mismo contiene el nombre del diagrama de secuencia al que se hará referencia, seguido de
argumentos opcionales entre paréntesis y un valor de retorno opcional precedido por dos puntos. Figura
6.23 ilustra el uso de una referencia de interacción. La secuencia para iniciar sesión en el sistema de
administración de estudiantes se modela en el diagrama de secuencia Iniciar sesión, al que se hace
referencia en el diagrama de secuencia Registro de examen.
6.5.2 Puertas
En principio, los mensajes no deben extenderse más allá de los límites de una interacción, una
interacción referenciada o un fragmento combinado, lo que significa que no deben exceder el
marco arbitrariamente. Para permitirle extender el intercambio de mensajes más allá de tales
límites, UML ofrece
portón puertas. El uso de tales puertas le permite enviar y recibir mensajes más allá de los
límites del fragmento de interacción. Una puerta se visualiza con la punta o el final de una
flecha de mensaje, dependiendo de si el
Figura 6.24
sd invitar profesor invitado
Ejemplo de una puerta
p1: profesor p2: Profesor s: Secretario
invitación (fecha)
invitación: ″ ok ″
roomReservation (fecha)
fecha para registrarse)
info (hotel, costos)
info (hotel)
Habitación Reserva SD
:Hotel
:Base de datos
AdminSystem
fecha para registrarse)
reserve (hotel, fecha)
costos = reserva: precio
info (hotel, costos * 1.2)

mensaje es un mensaje entrante o saliente, que toca el límite del marco que representa el
diagrama de secuencia, la referencia de interacción o el fragmento combinado. Las puertas se
identifican por un nombre o por el nombre de un mensaje que usa la puerta, opcionalmente
junto con la dirección del mensaje (por ejemplo, reserva en Figura 6.24 ). Le permiten definir un
remitente específico y un receptor específico para cada mensaje, incluso si el remitente o el
receptor está fuera de la interacción respectiva o fuera del fragmento. No es necesario incluir
puertas de forma explícita para fragmentos combinados, lo que significa que un mensaje puede
apuntar directamente al receptor.
6.5.3 Marcadores de continuación
Marcadores de continuación le permiten modularizar los operandos de un alt Marcador de continuación
fragmento. Esto le permite dividir interacciones complejas en partes y conectarlas entre sí con
marcadores. Aquí un marcador de inicio al final de una parte de interacción apunta a un marcador Marcador de inicio y marcador de
de destino con el mismo nombre al comienzo de otra parte de interacción externa. Los destino
marcadores de continuación se indican dentro de rectángulos con esquinas redondeadas que

pueden extenderse a través de múltiples compañeros de interacción. Los marcadores de
continuación con el mismo nombre deben hacer referencia a los mismos socios de interacción. Figura
6.25 y Figura 6.26 modelar el ejemplo de Figura 6.10
en la página 117 con tres marcadores de inicio diferentes ( Figura 6.25 ) y los respectivos marcadores
de destino correspondientes ( Figura 6.26 ). Si, por ejemplo, el marcador de inicio Okay en Figura 6.25 se
alcanza, el diagrama de secuencia continúa con las interacciones detalladas bajo el marcador de
destino con el mismo nombre en Figura 6.26 . No hay retorno al marcador de inicio, a diferencia de
una referencia de interacción, que se puede comparar con una macro. Un marcador de continuación
también puede ser el único elemento de un operando, aumentando así la claridad del diagrama.
Puede asignar varios marcadores de inicio a un marcador de destino. Los marcadores de destino y de
inicio no tienen que estar ubicados en el mismo diagrama de secuencia.
6.5.4 Parámetros y atributos locales
Al igual que todos los otros tipos de diagramas en UML 2.4.1, el diagrama de secuencia está encerrado por
un marco rectangular con un pequeño pentágono en la esquina superior izquierda. Este pentágono
contiene la palabra clave Dakota del Sur para indicar claramente que el contenido del rectángulo es un
diagrama de secuencia. La palabra clave Dakota del Sur va seguido del nombre del diagrama de secuencia y
opcional
parámetros separados por comas y entre paréntesis. Tú
Figura 6.25 : StudentAdmin

Ejemplo de marcador de continuación :Estudiante :Base de datos
Sistema
(marcadores de inicio)
status = enter: status
alt [estado == ok]
Okay
[estado == lista de espera gratis]
registro: ″ wl ″
Colocar gratis en lista de espera
[más]
registro: ″ error ″
No hay lugar libre
puede declarar atributos locales en cualquier punto del diagrama, por lo que la sintaxis de los atributos
corresponde a las especificaciones de atributo en el diagrama de clases (ver Figura 4.5 en la página
54). Alternativamente, puede declarar atributos locales en una nota.
6.5.5 Restricciones de tiempo
Limitación de tiempo Limitaciones de tiempo especifique el momento en que ocurren los eventos o un período de tiempo
entre dos eventos. Las limitaciones de tiempo se indican entre paréntesis. los expresión de tiempo representa
Expresión de tiempo una especificación de tiempo concreta, por ejemplo, { 12:00}, o una regla de cálculo, como { 12:00 + d}. Puede
especificar tiempos absolutos con la palabra clave a, por ejemplo, { a las 12:00)}.
Tiempos relativos se especifican con referencia a un evento inicial utilizando la palabra clave después, por
ejemplo, { después de (5 segundos)}. En ambos casos, la expresión de tiempo se indica entre corchetes.

:Estudiante :Base de datos Ejemplo de marcador de continuación
Sistema
(marcadores de destino)
alt
Okay
getInfos ()
Colocar gratis en lista de espera
optar [registrarse en WL == verdadero]
No hay lugar libre
getAlternative
Cursos (curso)
También puede especificar intervalos de tiempo. Nuevamente, un intervalo se encierra entre Intervalo
corchetes y contiene una expresión en la forma límite inferior .. límite superior. Para expresar que un
evento tiene lugar entre las 12:00 y las 13:00, por ejemplo, usaría el formulario { 12: 00..13: 00}.
La palabra clave ahora especifica la hora actual. Puede asignarse a cualquier atributo, por ejemplo, t
= ahora. Naturalmente, puede utilizar este atributo en cualquier limitación de tiempo, por ejemplo, { t..t +
5}.
El cálculo de la duración de la transmisión de un mensaje se indica mediante la palabra

clave duración.
Usted asigna una restricción de tiempo a un evento usando un marca de tiempo representado por Marca de tiempo
una línea horizontal corta en el diagrama. Si una restricción de tiempo se refiere a dos eventos, lo que
significa que debe definirse la duración entre dos eventos, especifique esto usando dos marcas de
tiempo. Figura 6.27 muestra algunos ejemplos de limitaciones de tiempo. El diagrama implica la
comunicación entre estudiantes y profesores a través de un foro. El foro envía un boletín a los
estudiantes a las 12:00. En el momento t, un estudiante publica un mensaje
m1. Cinco unidades de tiempo después, el estudiante recibe una notificación de que el mensaje se
está publicando. Un máximo de dos horas después llega la respuesta del profesor.
Figura 6.27
Ejemplos de tiempo :Estudiante :Foro :Conferenciante
limitaciones
enviarNewsletter
{a las 12:00)}
poste (m1)
{t = ahora}
publicar: confirmar
{t + 5}
informar (m1)
{máx. 2 horas}
Enviar respuesta)
informar (responder)
6.5.6 Invariantes de estado
Estado invariante Puede especificar invariantes de estado para una interacción. Un invariante de estado afirma que una
determinada condición debe cumplirse en un momento determinado. Siempre se asigna a una línea de vida
específica. La evaluación de si el invariante es verdadero tiene lugar antes de que ocurra el evento
subsiguiente. Si el invariante de estado no es verdadero, el modelo o la implementación son incorrectos. Los
invariantes de estado pueden hacer referencia a estados del diagrama de máquina de estados relacionado o
pueden ser condiciones lógicas que se refieren a atributos locales.
UML ofrece tres alternativas de notación para invariantes de estado: puede especificar un
invariante de estado entre llaves directamente en una línea de vida; puede adjuntarlo como nota; o
también puede colocarlo en un rectángulo con bordes redondeados en el punto correspondiente de
la línea de vida. Las tres alternativas de notación se muestran en Figura 6.28 . Un estudiante solo
puede inscribirse para un examen (i) si el estudiante está inscrito, (ii) si el examen aún no se ha
realizado y (iii) si es posible inscribirse para el examen.
Figura 6.28 : StudentAdmin

Alternativas de notación para :Estudiante
Sistema
invariantes de estado
{examDate> ahora}
registro
inscrito
posible
6.6 Crear un diagrama de secuencia 133
6.6 Crear un diagrama de secuencia
En lugar de un ejemplo final, en esta sección veremos dos escenarios para los que puede
usar un diagrama de secuencia. En particular, ilustraremos la conexión entre el diagrama
de clases y el diagrama de secuencia. Luego, concluiremos la sección con una aplicación
típica de los diagramas de secuencia, a saber, la descripción de patrones de diseño [20].
6.6.1 La conexión entre un diagrama de clases y un diagrama de

secuencia
Hemos dicho repetidamente que los diferentes diagramas UML no deben considerarse
independientemente unos de otros; simplemente ofrecen diferentes vistas de un determinado
contenido. Por ejemplo, el diagrama de clases que se muestra en
Figura 6.29 modela una parte de un sistema universitario que también incluye el sistema de administración
de estudiantes.
Figura 6.29
StudentAdminSystem Diagrama de clase
+ newRegistration (fecha: Fecha, matNo: int, courseNo: int): void

+ getCourse (courseNo: int): Curso
+ getStudent (matNo: int): Estudiante
1 1
*
*
Curso
Estudiante
+ setRegistration (registro: Registro): void
1
1
* *
Registro
+ setDate (fecha: Fecha): void

+ init (estudiante: estudiante, curso: curso): void
El sistema de administración de estudiantes tiene acceso directo a todos los estudiantes y

cursos. El sistema conoce los datos de registro de estudiantes y cursos que se almacenan en la
clase. Registro.
Queremos representar la comunicación que se requiere para crear un nuevo registro de un
determinado estudiante para un determinado curso. Para hacer esto, el
método nuevo registro de la clase StudentAdminSystem debe ser llamado.
Para crear una nueva matrícula, debemos conocer el objeto de alumno que pertenece al
número de matrícula respectivo y el objeto de curso que pertenece al número de curso
dado. Podemos obtenerlos llamando a las operaciones getCourse y getStudent. Tan pronto
como tengamos esta información, podemos crear un nuevo objeto del tipo Registro y llama al
en eso
operación que establece el alumno y el curso para el objeto de registro. Ahora solo nos
queda establecer la conexión entre la matrícula y el curso, ya que se supone navegabilidad
en ambos sentidos. Hacemos esto llamando al método setRegistration. No tenemos que hacer
esto para el registro y los objetos de los estudiantes, ya que la navegación desde Estudiante a
Registro no es posible. El diagrama de secuencia resultante se muestra en

Figura 6.30 .
Figura 6.30
: StudentAdmin
Basado en diagrama de secuencia
curso: curso estudiante: estudiante
Sistema
en el diagrama de clases
nuevo registro
(fecha, matNo, cursoNo)
curso = obtener
Curso (cursoNo)
getStudent (matNo)
nuevo() registro
:Registro
init (estudiante, curso)
setDate (fecha)
setRegistration
(registro)
6.6 Crear un diagrama de secuencia 135
6.6.2 Descripción de patrones de diseño
Los diagramas de secuencia se utilizan a menudo para describir patrones de diseño. Los
patrones de diseño ofrecen soluciones para describir problemas recurrentes. A continuación,
veremos el patrón Transfer Object Assembler [18], que describe lo que sucede cuando un Modelando el
cliente en un entorno distribuido requiere información de tres objetos de negocio. comunicación del
Transferir objeto
En la solución que se muestra en Figura 6.31 , el cliente requiere conocimientos Patrón de ensamblador
sobre los tres objetos de negocio para acceder a los datos necesarios. Por lo tanto, el cliente está
fuertemente vinculado a los objetos comerciales, lo que generalmente no es deseable. Podemos
utilizar el patrón Transfer Object Assembler para analizar estas dependencias. En este patrón, un
ensamblador fusiona los datos de varios objetos comerciales en un objeto de transferencia que
luego se transfiere al cliente. El cliente recibe así los datos necesarios en forma encapsulada. En
términos concretos, el patrón se implementa como se describe a continuación (ver Figura 6.32 ).
Figura 6.31
:Cliente : BO1 : BO2 : BO3
Escenario de aplicación para
Ensamblador de objetos de transferencia
obtener datos()
patrón
getData: d1
obtener datos()
getData: d2
obtener datos()
getData: d3
Utilizando obtener datos() el cliente solicita la información requerida de un objeto de tipo TransferObjectAssembler
(TOA). los TOA objeto crea el objeto re de tipo DataTransferObject (DTO) y lo llena con los datos
de los tres diferentes objetos comerciales ( BO1, BO2, BO3). Los datos de un objeto comercial
se pueden consultar utilizando obtener datos(). El objeto re ofertas
setData métodos que permiten la entrada de datos. Finalmente, el objeto de tipo
TransferObjectAssembler devoluciones re al cliente.

Figura 6.32
:Cliente : TOA : BO1 : BO2 : BO3
Descripción del patrón Transfer
Object Assembler obtener datos()
usando un diagrama de secuencia
nuevo()
d: DTO
obtener datos()
d1 = getData
setData (d1)
obtener datos()
d2 = getData
setData (d2)
obtener datos()
d3 = getData
setData (d3)
getData: d
6.7 Los diagramas de descripción general de comunicación, tiempo e

interacción
Además del diagrama de secuencia, UML admite tres tipos más de diagramas de
interacción:
• Diagrama de comunicación
• Diagrama de tiempo
• Diagrama de descripción general de la interacción
Los cuatro tipos de diagramas de interacción de UML son generalmente equivalentes para
interacciones simples ya que se basan en los mismos elementos básicos. Con la especificación
de los interlocutores implicados y los mensajes intercambiados, todos describen determinadas
situaciones de comunicación. Sin embargo, el enfoque es diferente para cada tipo de diagrama.
En esta sección, comparamos brevemente los cuatro diagramas de interacción en los

ejemplos. Los ejemplos se ilustran en Figuras 6.33 a 6.36 , mostrando varios aspectos de la
comunicación entre un estudiante y el sistema de e-learning de una universidad.
Figura 6.33 muestra el proceso de inicio de sesión como un diagrama de secuencia. Hay tres
socios de interacción: estudiante, sistema de aprendizaje electrónico y base de datos. El alumno desea
iniciar sesión en el sistema y, por lo tanto, envía un mensaje correspondiente al sistema de e-learning.
Una consulta a la base de datos verifica los derechos de acceso y el alumno recibe una respuesta
positiva
6.7 Los diagramas de descripción general de comunicación, tiempo e interacción 137
: E-Learning Figura 6.33

:Estudiante :Base de datos Ejemplo de secuencia
Sistema
diagrama
iniciar sesión (usuario, pw)
comprobar (usuario, pw)
comprobar: ″ ok ″
getCourses ()
mensaje. No se tienen en cuenta los posibles casos de error. Luego, el estudiante solicita la
lista de cursos suscritos.
los diagrama de comunicación es un diagrama estructurado que modela las relaciones Diagrama de comunicación
entre los socios de comunicación. Por tanto, muestra directamente quién se comunica con
quién. Las relaciones son el resultado del intercambio de mensajes. Aquí, el tiempo no es
una dimensión separada. El orden en el que se intercambian los mensajes se expresa
mediante la clasificación decimal (numeración secuencial) de los mensajes. Figura 6.34
muestra el proceso de inicio de sesión como un diagrama de comunicación. Una vez más, los socios de
interacción son los estudiantes, el sistema de aprendizaje electrónico y la base de datos. El diagrama muestra
que el estudiante se comunica con el sistema de e-learning dos veces: una vez usando iniciar sesión (usuario, pw) y
una vez usando getCourses (). También muestra que el sistema de e-learning se comunica con la base de datos
utilizando
comprobar (usuario, pw). La numeración da como resultado el orden iniciar sesión, comprobar, y getCourses. Los
tres mensajes son mensajes sincrónicos, como lo muestran las puntas de flecha; Los mensajes
asincrónicos se mostrarían con puntas de flecha abiertas como en un diagrama de secuencia. Los
mensajes de respuesta no se muestran en el diagrama de comunicación.
Figura 6.34
:Estudiante Ejemplo de comunicación
diagrama de ción
1: iniciar sesión (usuario, pw)

2: getCourses ()
: E-Learning
:Base de datos
Sistema 1.1: comprobar (usuario, pw)
Diagrama de tiempo los diagrama de tiempo muestra los cambios de estado de los socios de interacción que resultan
de la ocurrencia de eventos. A diferencia del diagrama de secuencia, en el que la disposición de los
interlocutores y el eje del tiempo es exactamente opuesta, en el diagrama de tiempo los interlocutores
se enumeran en el eje vertical y el eje horizontal representa el orden cronológico. En el diagrama de
tiempo, las líneas de vida están representadas por un área completa en la que se pueden representar
estados y transiciones de estado. El nombre de la línea de vida (nombre del rol y / o clase) se anota
verticalmente en el límite izquierdo del área. Figura 6.35 así se muestra la interacción de los socios
entre el estudiante, el sistema de aprendizaje electrónico y la base de datos. Un estudiante puede
estar en el estado conectado o desconectado y el sistema de e-learning puede llevar a los estados ocioso o
ocupado. Para la base de datos solo existe el estado activo. Si el alumno ahora envía el mensaje iniciar
sesión (usuario, pw) al sistema de e-learning, el sistema cambia del estado ocioso al Estado ocupado y
envía el mensaje comprobar (usuario, pw) a la base de datos. La base de datos verifica los datos y, por
lo tanto, se permite al estudiante acceder al sistema. El alumno es informado de ello con el
correspondiente mensaje de respuesta. El estudiante ahora está en el estado conectado. El sistema de
e-learning puede regresar brevemente al estado ocioso hasta que el alumno envíe el getCourses solicitud.
Figura 6.35 conectado

:Estudiante
Ejemplo de diagrama de tiempos

desconectado
getCourses
: E-Learning
ocupado
Sistema
ocioso
comprobar (usuario, pw) comprobar: ″ ok ″

:Base de datos
activo
Descripción general de la interacción los diagrama de descripción general de interacción muestra las diferentes interacciones y
diagrama visualiza el orden y las condiciones en las que tienen lugar. Esto le permite colocar varios
diagramas de interacción en un orden lógico. Para hacer esto, utiliza principalmente los conceptos
del diagrama de actividades (consulte el Capítulo 7). En lugar de especificar nodos para acciones y
objetos, especifica diagramas de interacción completos y referencias de interacción como nodos
que luego puede colocar en orden utilizando las estructuras de control del diagrama de actividad.
Un círculo sólido representa el nodo inicial y un círculo sólido con un círculo circundante
representa un nodo final. Puede implementar diferentes caminos utilizando nodos de decisión
representados por un hueco
6.8 Resumen 139
diamante. Figura 6.36 muestra un diagrama de resumen de la interacción que, además de un

nodo inicial y final, también contiene este tipo de nodo de rama. Si el alumno tiene la
autorización necesaria, el alumno puede ejecutar la interacción Foro, representado como un
diagrama de secuencia.
sd Iniciar sesión
Figura 6.36
Ejemplo de interacción
: E-Learning diagrama general
Sistema

[más]
comprobar (usuario, pw)
comprobar: ″ ok ″
inicio de sesión: ″ ok ″ [autorizado]
getCourses ()
Foro sd
6.8 Resumen
El diagrama de secuencia es uno de los cuatro diagramas de interacción en UML. Los diagramas
de interacción modelan la comunicación entre diferentes socios de interacción, por lo que cada
uno de los cuatro diagramas se centra en un aspecto diferente. En la práctica, el diagrama de
secuencia es el más utilizado de los diagramas de interacción. La presentación de protocolos de
comunicación y patrones de diseño son aplicaciones particularmente destacadas de los
diagramas de secuencia, ya que permiten una especificación clara y compacta. Además de los
socios de interacción, que se representan en forma de líneas de vida, el diagrama de secuencia
contiene diferentes tipos de mensajes (síncronos, asíncronos, mensaje de respuesta, mensaje
de creación). Generalmente se asume que el orden cronológico de los mensajes es de arriba
hacia abajo a lo largo de la línea vertical. Doce tipos de fragmentos combinados le proporcionan
diferentes estructuras de control que le permiten controlar la interacción. Los elementos más
importantes del diagrama de secuencia se resumen en Cuadro 6.2 .
Cuadro 6.2
de secuencia
r: C
UN Socios de interacción involucrados en la
Línea de vida
comunicación
Momento en el que un compañero de interacción deja de

Evento de destrucción
existir
... [...]
Fragmento combinado Construcciones de control
Mensaje sincrónico El remitente espera un mensaje de respuesta
Mensaje de respuesta Respuesta a un mensaje sincrónico
Asincrónico mes- El remitente continúa con su propio trabajo después de

sabio enviar el mensaje asincrónico
Mensaje perdido perdió Mensaje a un receptor desconocido
Mensaje encontrado encontró Mensaje de un remitente desconocido

Capítulo 7
El diagrama de actividad
los diagrama de actividad se centra en el modelado de aspectos de procesamiento de procedimientos de Control de flujo y flujo de datos
un sistema. Especifica el fl ujo de control y el fl ujo de datos entre varios pasos: el comportamiento —Requisito
para implementar una actividad.
En UML 2, los diagramas de actividades utilizan conceptos de lenguaje orientados al fl ujo que
encuentran su origen en lenguajes para definir procesos de negocio. Los diagramas de actividad
también se basan en conceptos establecidos para describir los procesos de comunicación concurrentes,
como el concepto simbólico de las redes de Petri [41]. Una característica particular de los diagramas de
actividad es su soporte para modelar tanto sistemas orientados a objetos como sistemas no orientados a
objetos. Le permiten de fi nir actividades independientemente de los objetos, lo que significa, por
ejemplo, que puede modelar bibliotecas de funciones, así como procesos de negocios y organizaciones Modelado de
del mundo real. orientado a objetos y
no orientado a objetos
El estándar UML no estipula ninguna forma específica de notación para actividades. Además de los sistemas
elementos de notación basados en el flujo de los diagramas de actividad, el estándar también permite
otras formas de notación, como los diagramas estructurales o incluso el pseudocódigo. Además de los
elementos de notación personalizados, han surgido varios patrones de flujo de control y de flujo de datos
recurrentes. Se utilizan en particular para modelar procesos comerciales y han demostrado ser muy
útiles para procesos complejos. Estas construcciones se conocen como "patrones de flujo de trabajo".
Para obtener una descripción general de estos tipos de patrones, así como una guía sobre cómo
modelar los patrones basados en los conceptos de los diagramas de actividad de UML 2, consulte "Patrones de flujo de trabajo"
Wohed et al. [44].
En este capítulo, los lectores observadores notarán que no todos los ejemplos modelan
procesos completos; algunos de los modelos están restringidos a extractos de procesos. Así, por
ejemplo, algunos de los diagramas no contienen nodos inicial y final. En la práctica, sin embargo, un
diagrama de actividad completo debe tener puntos de inicio y finalización claramente definidos.

Computación, DOI 10.1007 / 978-3-319-12742-2_7
142 7 El diagrama de actividades
7.1 Actividades
Un diagrama de actividad le permite especificar el comportamiento definido por el usuario en forma de

Actividad actividades. Un actividad en sí mismo puede describir la implementación de un caso de uso. En un nivel
muy detallado, también puede definir el comportamiento de una operación en forma de instrucciones
individuales, o en un nivel menos detallado, modelar las funciones de un proceso empresarial. Un
proceso comercial define cómo los socios comerciales deben interactuar entre sí para lograr sus
objetivos. También puede describir los procesos internos de una empresa. Por tanto, el comportamiento
se puede definir en diferentes niveles de granularidad. Una actividad puede asignarse a una operación
de una clase pero también puede ser autónoma.
Actividad El contenido de una actividad es, como con las redes de Petri, un gráfico dirigido cuyos nodos
representan los componentes de la actividad como acciones, almacenes de datos y elementos de
Nombre de la actividad
"condición previa"
control y cuyos bordes representan el flujo de control o flujo de objetos, es decir, las posibles rutas de
«Poscondición» ejecución. para la actividad.
... ...
Una actividad se representa como un rectángulo con esquinas redondeadas y, al igual que una
operación, puede tener parámetros. Estos se muestran como rectángulos dispuestos superpuestos
en el límite de la actividad. Para que el diagrama sea más fácil de leer, debe colocar parámetros de
entrada en el límite izquierdo o superior y parámetros de salida en el límite derecho o inferior de la
actividad. Esto permite leer una actividad de izquierda a derecha y / o de arriba a abajo. Los valores
que se transfieren a la actividad a través de los parámetros de entrada están disponibles para
aquellas acciones que están conectadas a los parámetros de entrada por un flanco dirigido (ver la
siguiente sección). De la misma manera, los parámetros de salida reciben sus valores a través de
bordes dirigidos de acciones dentro de la actividad. El ejemplo en Figura 7.1 muestra los pasos
necesarios para ejecutar la actividad Tomar examen. Los parámetros de entrada son el número de
matrícula y la identificación del programa de estudios de un estudiante. Las acciones Registrarse,
escribir examen, y Correcto se ejecutan en esta actividad. El resultado de la actividad es una nota. Sin
embargo, este diagrama de ejemplo no muestra quién realiza qué acción. Para permitir la asignación
de acciones a actores específicos, el diagrama de actividad ofrece el concepto de particiones, que
presentaremos en la Sección 7.5.
Condición previa y Puede especificar condiciones previas y posteriores para una actividad. Indican qué
poscondición condiciones deben cumplirse antes o después de la ejecución de la actividad. Las palabras
clave "condición previa" y «Poscondición»
se utilizan para identificar las condiciones respectivas. En Figura 7.1 , un estudiante que quiera tomar
un examen debe estar inscrito. Despues de la actividad Tomar examen ha sido ejecutado, el estudiante
debe ser calificado.
7.2 Acciones 143
Figura 7.1
Tomar examen
Ejemplo de una actividad
El estudiante de «precondición» está inscrito El
estudiante de «poscondición» está calificado
matNo:
Entero
grado:
Entero
Registrarse Escribir examen Correcto
CARNÉ DE IDENTIDAD:
Cuerda
7.2 Acciones
Los elementos básicos de las actividades son comportamiento. Al igual que una actividad, una acción Acción
se representa como un rectángulo con esquinas redondeadas, en el que el nombre de la acción se
Acción
coloca en el centro del rectángulo redondeado. Puede utilizar acciones para especificar cualquier
comportamiento definido por el usuario. No hay requisitos de lenguaje específicos para la descripción
de una acción. Por lo tanto, puede definir las acciones en lenguaje natural o en cualquier lenguaje de
programación. Por ejemplo, si, como resultado de la ejecución de una acción, el valor de la variable yo se
va a aumentar en uno, puede expresar esto utilizando yo ++ o simplemente escribiendo Incrementar i en
uno.
Las acciones procesan los valores de entrada para producir valores de salida, lo que significa
que pueden realizar cálculos. También pueden cargar datos desde una memoria y pueden
cambiar el estado actual de un sistema. En el ejemplo de Figura 7.1 , Registrarse, escribir examen, y Correcto
son acciones.
Dentro del contexto de una actividad, las acciones son siempre atómicas, es decir, no pueden Atomicidad de acciones
desglosarse más dentro del contexto modelado. Sin embargo, una acción puede hacer referencia a
otra actividad que en sí misma consta de acciones (consulte acción de comportamiento de llamada en
la página 145). Las acciones se consideran atómicas, aunque pueden constar de varios pasos
individuales. Por ejemplo, registrarse para un examen generalmente requiere varios pasos, como
iniciar sesión en el sistema y seleccionar el curso apropiado y la fecha del examen. A pesar de esto,
en Figura 7.1 , hemos modelado intencionalmente Registrarse
como una acción más que como una actividad. Esto se debe a que en el modelo actual, la
ejecución de un registro se considera como un solo paso; Sin embargo, los detalles internos
de este paso no nos interesan y, por lo tanto, no lo desglosamos más.
Como podemos ver en Figura 7.1 , acciones y parámetros están conectados Margen entre acciones
entre sí a través de bordes dirigidos. Estos bordes expresan el orden en el que se ejecutan las
UN segundo
acciones y, por lo tanto, definen los pasos de ejecución de
una actividad. Aquí diferenciamos entre controlar los bordes del flujo y bordes de flujo del
objeto: Los bordes de flujo de control solo definen el orden entre acciones, mientras que
los bordes de flujo de objetos también se pueden usar para intercambiar datos u objetos.
Esto le permite expresar una dependencia de datos entre una acción anterior y una
Control de borde de flujo versus acción posterior. La finalización de una acción puede iniciar la ejecución de otra acción si
borde de flujo del objeto estas dos acciones están conectadas entre sí mediante bordes de flujo de control o
bordes de flujo de objeto. Sin embargo, una acción solo puede ejecutarse si todas las
acciones anteriores se han completado con éxito, todas las protecciones relevantes se
evalúan como verdaderas y todos los parámetros de entrada tienen valores. Los
resguardos son condiciones que deben cumplirse para permitir la transición de una
actividad o acción a otra actividad o acción. Suelen aparecer en relación con ramas
alternativas. Veremos el flujo de control, incluidos los guardias,
Acciones predefinidas En UML, hay una serie de acciones predefinidas, no específicas del idioma, que puede
modelar fácilmente en cualquier idioma de destino debido a su nivel de detalle.
Las acciones predefinidas en UML se pueden clasificar en diferentes categorías en

función de su función y complejidad. Discutiremos las dos más importantes de estas
categorías en las siguientes secciones.
7.2.1 Acciones basadas en eventos
Las acciones basadas en eventos permiten transmitir objetos y señales a los objetos receptores. Le
permiten distinguir entre diferentes tipos de eventos. Puedes usar un aceptar acción de evento para
Aceptar evento (hora) modelar una acción que espera la ocurrencia de un evento específico. El elemento de notación para una
acción acción de evento de aceptación es un “pentágono cóncavo”, un rectángulo con una punta que apunta
hacia adentro desde la izquierda. Si el evento es un evento basado en el tiempo, puede usar un aceptar
mi o
la acción del evento temporal, donde en este caso, la notación es un reloj de arena.
T
Las acciones de eventos de aceptación (tiempo) no necesariamente tienen bordes entrantes. Si no

tienen bordes entrantes, comienzan cuando ocurre el evento correspondiente. Permanecen activos, es
decir, pueden recibir señales hasta que finaliza la actividad que las contiene. Figura 7.2 muestra tres
ejemplos de acciones de evento de aceptación (tiempo): siempre que se activa una alarma de incendio,
la sala de conferencias debe ser evacuada ( Figura 7.2 (a) ); al final de un semestre, se emiten certi fi
cados ( Figura 7.2 (b) ); cuando un estudiante ha tomado un examen, el estudiante espera la calificación
e inspecciona la hoja de examen cuando recibe la calificación ( Figura 7.2 (c) ).
7.2 Acciones 145
Figura 7.2
Alarma de incendios Evacuar Ejemplos de aceptar acciones de
sonidos sala de conferencias eventos (a + c) y aceptar acciones de
eventos temporales (b)

(un)
Problema
certificados
Fin de semestre
(segundo)
Escribir Aprender Inspeccionar
examen grado papel de examen
(C)
Para enviar señales, puede utilizar enviar acciones de señal. Las acciones de envío de señales se indican Enviar acción de señal
con un “pentágono convexo”, un rectángulo con una punta que sobresale hacia la derecha. La acción Enviar
calificación en Figura 7.3 (b) es un ejemplo de una acción de envío de señal.

S
7.2.2 Acciones de comportamiento de llamada
Las acciones pueden llamar actividades en sí mismas. Estas acciones se denominan Acción de comportamiento de llamada
llamar acciones de comportamiento y están marcados con un símbolo de horquilla invertida. Este
UN
símbolo de bifurcación indica una jerarquía. Simboliza que la ejecución de esta acción inicia otra
actividad, dividiendo así el sistema en varias partes. Figura 7.3 (a) muestra un ejemplo de una acción
de comportamiento de llamada. En este diagrama, la acción Emitir certi fi cado en la actividad Organizar
examen se refiere a una actividad que especifica Emitir certi fi cado con más detalle. Dentro del contexto
de la actividad Organizar examen, los pasos internos que conducen a la emisión de un certificado no son
relevantes. Por lo tanto, Emitir certi fi cado se ve aquí como una unidad atómica, aunque implica un
proceso con múltiples acciones.
El contenido de la actividad llamada se puede representar en otra parte de este o incluso en otro
diagrama de actividad en forma de una actividad con la notación habitual para las actividades que ya
hemos visto. Figura 7.3 (b) muestra los detalles de la actividad llamada Emitir certi fi cado con el
parámetro de entrada
grado.
Figura 7.3
Organizar examen
Ejemplo de una acción de comportamiento
de llamada y una acción de envío de señal

Tomar Problema
examen certificado
(un)
Emitir certificado
Seleccione Seleccione Entrar Enviar

curso estudiante grado grado
(segundo)
Acción de operación de llamada Una acción también puede desencadenar la llamada de una operación. Este tipo de acción se
conoce como llamar a la acción de operación. Está representado en un rectángulo con bordes
UN
redondeados. Si el nombre de la operación no coincide con el nombre de la acción, el nombre de la
(Clase :: operación)
operación se puede especificar debajo del nombre de la acción en el formulario ( ClassName ::
operationName).
7.3 Flujos de control
Token para describir Las actividades consisten en otras actividades y acciones que están conectadas entre sí por bordes.
fl ujos Si miramos el gráfico de una actividad, la estructura estática no muestra claramente cómo funciona la
ejecución. Para integrar los aspectos de comportamiento dinámico en el diagrama, necesitamos
semántica de ejecución, lo que significa que tenemos que especificar exactamente cómo se ejecuta
un diagrama de actividad.
Flujo de token El concepto de token, introducido en las redes de Petri [41], es la base para la semántica de
ejecución del diagrama de actividad. Un token es un mecanismo de coordinación virtual que
describe exactamente la ejecución. En este contexto, virtual significa que los tokens no son
Acción1
componentes físicos del diagrama. Son mecanismos que otorgan a las acciones un permiso de
ejecución.
Acción2 Si una acción recibe un token, la acción está activa y se puede ejecutar. Una vez que la acción
ha finalizado, pasa el token a un nodo posterior a través de un borde y, por lo tanto, desencadena la
ejecución de esta acción. Una vez finalizada esta acción, pasa la ficha a los bordes salientes o la
retiene hasta que se cumple una determinada condición.
Guardia El paso de un token puede evitarse mediante un Guardia evaluar como falso. Un resguardo
[gramo] se especifica entre corchetes. En el ejemplo de Figura 7.4 , un examen solo se realiza si los
UN segundo
estudiantes se han inscrito para él.
7.3 Flujos de control 147
Figura 7.4
Anunciar [estudiantes registrados]
Ejemplo de un guardia
Realizar examen
examen
Una acción solo se puede ejecutar si hay tokens presentes en todos sus bordes entrantes. Si
una acción tiene múltiples bordes salientes, se ofrece un token a todos los nodos de destino de estos
bordes, lo que provoca una división en múltiples rutas de ejecución independientes. Los nodos
especiales también están disponibles como alternativa para modelar esta concurrencia. Los veremos
con más detalle más adelante.
Cuando se ejecuta una acción, normalmente se consume una ficha de cada uno de sus
bordes entrantes. Alternativamente, un peso puede colocarse en un borde para permitir que una Peso de un borde
determinada ejecución consuma un cierto número de tokens en ese borde. El peso de un borde se
{peso = X}
UN segundo
especifica entre corchetes con la palabra clave peso. Siempre es un número entero mayor o igual a
cero. Si el peso es cero, esto significa que se consumen todos los tokens presentes.
Alternativamente, todos o ∗ también se puede escribir en lugar de cero. Si no se especifica peso, 1 se
asume como el valor predeterminado. Figura 7.5
da un ejemplo del uso de pesas. Si la señal Registrarse se recibe 30 veces, lo que significa
que al menos 30 estudiantes se han registrado y por lo tanto se ofrecen 30 tokens para la
acción posterior, luego se ejecuta esta acción posterior, consume 30 tokens y se crea un
nuevo grupo.
Figura 7.5
{peso = 30} Crear
Registrarse Ejemplo del peso de un borde
nuevo grupo
Si dos acciones que deben conectarse entre sí a través de un borde están muy separadas
en un diagrama, puede usar conectores para aclarar el diagrama. En este caso, no es necesario Conector
trazar el borde como una línea continua de una acción a la otra; en cambio, el conector actúa
UN y y segundo
como un marcador de continuación comparable a los marcadores de continuación en los
diagramas de secuencia (consulte la página 129). Un conector se representa como un círculo
pequeño que contiene el nombre del conector. Cada conector debe aparecer dos veces en una
actividad: una con un borde entrante y otra con un borde saliente. Figura 7.6 modela una relación
entre dos acciones, una vez sin un conector ( Figura 7.6 (a) ) y una vez con un conector ( Figura
7.6 (b) ). El diagrama de actividad ofrece nodos especiales para controlar el flujo de control.
Estos nodos se llaman nodos de control.
los nodo inicial indica dónde comienza la ejecución de una actividad. No tiene bordes Nodo inicial
entrantes, pero tiene al menos un borde saliente y se indica como un círculo negro sólido. Tan
pronto como una actividad se convierte en
Figura 7.6
Escribir
Ejemplo de un conector Registrarse
examen
(un)
Escribir
Registrarse UN UN
examen
(segundo)
activo, los tokens se proporcionan en todos los bordes salientes de un nodo inicial y, por lo tanto, se
inicia la actividad. Figura 7.7 muestra un ejemplo de un nodo inicial. El diagrama también contiene un
nodo final de actividad que representa el final de una actividad. Veremos el nodo final de la actividad,
señalado por un círculo negro sólido dentro de otro círculo, con más detalle más adelante en este
capítulo.
Figura 7.7
Ejemplo de un nodo inicial Asistir
Registrarse Escribir examen
conferencia
También se permiten varios nodos iniciales para cada actividad. Esto le permite expresar
simultaneidad, lo que significa que múltiples rutas de ejecución pueden estar activas
simultáneamente. Si se invoca una actividad con múltiples nodos iniciales, los bordes salientes de
todos los nodos iniciales reciben fichas simultáneamente. El ejemplo en Figura 7.8 muestra dos
subrutas concurrentes de la actividad Conducir conferencia. Si la actividad Conducir conferencia se
activa, se coloca un token en cada uno de los dos nodos iniciales y, por lo tanto, se activan ambos
subrutas. Una subruta se refiere a las acciones de los estudiantes y la otra subruta se refiere a las
acciones realizadas por un profesor. En la acción Escribir examen ambos caminos se fusionan. Un
token debe estar presente en ambos bordes entrantes para la acción. Escribir examen para ser
ejecutado.
Figura 7.8
Conducir conferencia
Ejemplo con múltiples
nodos iniciales
Asistir
Registrarse
conferencia
Escribir
examen
Preparar Dar
conferencia conferencia
En un diagrama de actividad, puede modelar ramas alternativas usando nodos de Nodo de decisión
decisión. Estos actúan como un punto de conmutación para los tokens y corresponden a la Si declaración
...
en un lenguaje de programación convencional. Un nodo de decisión se representa como un
diamante con un borde entrante y varios bordes salientes. Los bordes salientes tienen
protectores (también conocidos como condiciones). Al igual que en los otros diagramas UML,
los guardias son expresiones booleanas encerradas entre corchetes. Estas condiciones no
deben superponerse, lo que significa que el sistema debe poder decidir claramente qué borde
de salida debe tomar un token en una situación específica. Por ejemplo, tener una ventaja
saliente con la condición [ x> 1] y otra ventaja saliente con la condición [ x <3] no está permitido, ya
que no habría una elección única de la ventaja que un token debería tomar si x = 2 aplica. Si hay
un token en un nodo de decisión, el sistema debe poder decidir claramente, basándose en el
contexto actual (por ejemplo, dependiendo del valor de una variable), qué ruta toma el token
para salir del nodo de decisión. Figura 7.9 muestra un ejemplo de un nodo de decisión. Si la
accion Registrarse se ejecuta, le sigue la acción Selecciona grupo si aún quedan plazas disponibles.
Si este no es el caso, la acción Entrar en lista de espera es ejecutado.
Figura 7.9
Seleccione
Ejemplo de un nodo de decisión
]
d isp onible grupo
[lugar
Registrarse
[no ha
y luga
r disp
onible Entrar a
]
Lista de espera
Puede especificar comportamiento de decisión para un nodo de decisión. Esto significa que Comportamiento de decisión
puede especificar el comportamiento necesario para la evaluación de los guardias. Le permite

«DecisionInput»
evitar situaciones en las que los mismos cálculos deben realizarse varias veces para diferentes comportamiento de decisión
guardias, ya que se puede acceder al resultado del cálculo en cada guardia. Sin embargo, este
comportamiento no debe tener efectos secundarios, lo que significa que la ejecución del
comportamiento definido en un nodo de decisión nunca debe cambiar los valores de los objetos y
las variables. El comportamiento de decisión se adjunta al nodo de decisión como un comentario
con la etiqueta «DecisionInput». Figura 7.10 muestra un ejemplo de esto. Tan pronto como se
conocen los resultados del examen, un departamento central toma una decisión sobre si ofrecer a
los estudiantes la oportunidad de inspeccionar sus exámenes corregidos. Si la decisión es
positiva, los estudiantes pueden inspeccionar sus exámenes. Posteriormente, se emiten sus certi
fi cados. Si la decisión es negativa, los certificados se emiten inmediatamente.
Figura 7.10 [No]

Ejemplo de decisión
comportamiento
Examen [si] Inspeccionar Problema
resultado papel de examen certificado
«DecisionInput»
Permitir inspección
de papel de examen?
Fusionar nodo Si desea volver a juntar subrutas alternativas, puede hacerlo usando el fusionar nodo. Este
nodo también se representa como un diamante pero con múltiples bordes entrantes y solo un
...
borde saliente. En particular, un token solo puede estar presente en un borde entrante como
máximo. Usando nodos de decisión y fusión, ahora podemos modelar pasos de ejecución que
se repiten, es decir, bucles (ver Figura 7.11 ).
Figura 7.11
Ejemplo de bucle Asistir Escribir [¡calificación! = 5]
conferencia examen
[grado == 5]
Decisión combinada y También puede combinar nodos de decisión y fusión. Este nodo combinado tiene entonces
fusionar nodo múltiples bordes entrantes y múltiples bordes salientes.
Para los nodos de decisión y fusión, solo una de las posibles rutas está activa. Como ya se
...
...
mencionó, puede usar múltiples nodos iniciales para modelar la simultaneidad al comienzo de una
actividad. Si una ruta de ejecución se divide en múltiples rutas de ejecución activas simultáneamente
más adelante, puede darse cuenta de esto usando un nodo de paralelización. Un nodo de
Nodo de paralelización paralelización se representa como una barra negra con un borde entrante y varios bordes salientes.
Figura 7.12 muestra un ejemplo de este tipo de nodo. Una vez que un estudiante se ha
...
registrado para un curso, el estudiante asiste a la conferencia y participa en la tarea

simultáneamente. El estudiante solo puede redactar el examen cuando se hayan completado
tanto la lección como la tarea (ver párrafo siguiente).
Nodo de sincronización Puede fusionar subrutas concurrentes utilizando un nodo de sincronización.

Este nodo es la contraparte del nodo de paralelización. Se representa como una barra negra con
múltiples bordes entrantes pero solo un borde saliente. Tan pronto como los tokens estén presentes
...
en todos los bordes entrantes, es decir, tan pronto como se hayan ejecutado todas las acciones
anteriores, todos los tokens entrantes se fusionan en un token que se pasa al borde saliente.
Figura 7.12
Participar en Ejemplo del uso de
asignación paralelización y sincronización
Registrarse Escribir examen nodos de cronización
Asistir
conferencia
De la misma manera que puede combinar nodos de decisión y fusión, también puede Paralelización combinada
combinar nodos de sincronización y paralelización usando una barra con múltiples bordes y sincronización
nodo
entrantes y múltiples bordes salientes.
Para expresar el final de una actividad, el diagrama de actividad ofrece un nodo especial para
...
...
este propósito: el nodo final de actividad. Este nodo se representa como un pequeño círculo que
contiene un círculo sólido y, a menudo, se lo denomina "diana". Si un token está presente en un
borde entrante de un nodo final de actividad, se termina toda la actividad, es decir, se terminan todas
las acciones activas de esta actividad. Esto también incluye subrutas concurrentes activas y, por lo
tanto, se eliminan todos los tokens de la actividad. Una excepción a esta regla son los tokens de Nodo final de actividad
datos que ya están presentes en los parámetros de salida de la actividad (consulte la siguiente
sección). Si un diagrama contiene múltiples nodos finales de actividad, el primero alcanzado durante
la ejecución finaliza toda la actividad. Por ejemplo, la participación en un curso finaliza si la tarea no
se ha aprobado o si se ha realizado el examen (consulte Figura 7.13 ).
Puede fusionar varios nodos finales de actividad en un nodo final de actividad con varios
bordes entrantes. Tan pronto como un token llega al nodo final de la actividad a través de un
borde entrante, se finaliza toda la actividad.
Figura 7.13
«DecisionInput»
Ejemplo de múltiples nodos finales
¿Pasó la asignación?
de actividad en un diagrama de
actividad
Participar en [No]
asignación
[si]
Registrarse Escribir examen
Asistir
conferencia
Si solo desea finalizar una ruta de ejecución, dejando las otras rutas de ejecución activas
simultáneamente sin verse afectadas, debe utilizar la fl ujo de nodo final. Este nodo solo elimina los Nodo final de flujo
tokens que fluyen hacia él directamente, terminando así solo la ruta respectiva. Todos los demás
tokens de la actividad no se ven afectados y pueden seguir existiendo. El nodo final del fl ujo está
representado por un pequeño círculo que contiene un X y solo tiene bordes entrantes.
Figura 7.14
«DecisionInput»
Ejemplo de un nodo final de flujo y
¿Pasó la asignación?
un nodo final de actividad
Participar en [No]
asignación
[si]
Registrarse
Asistir
Escribir examen
conferencia
En Figura 7.14 , el ejemplo de Figura 7.13 ha sido modificado. La participación exitosa en

una tarea y la asistencia simultánea a la conferencia relacionada, combinada con la
realización del examen, son dos caminos de ejecución independientes que terminan con un
nodo final de flujo. Sin embargo, reprobar la tarea finaliza toda la actividad, lo que significa
que si un estudiante tiene una calificación negativa en la tarea, el estudiante ya no puede
tomar el examen final si aún no lo ha hecho.
Utilizando Figura 7.15 , ahora demostraremos la semántica de ejecución

de los nodos de control individuales que aplican el concepto de token.
Si actividad UN está activado, a todos los bordes salientes de todos los nodos iniciales se
les asigna un token. Así, en nuestro ejemplo, la acción A1 recibe un token e inicia la ejecución.
Una vez A1 se ha completado con éxito, pasa el token al nodo de decisión. Dependiendo del
valor de la variable
X, el nodo de decisión pasa el token a A2 Si [ X ≤ 0] es cierto o para A3 Si [ x> 0] es verdad.
El nodo de combinación siguiente pasa cada token que recibe al nodo siguiente. Así, tras
la ejecución de A2 o A3, la acción
A4 Está activado. El nodo de paralelización posterior duplica el token para todos los bordes
salientes, creando así tres tokens y activando A5, A6,
y A7. Las siguientes tres rutas de ejecución se toman simultáneamente:
• Se activa una ficha A5. Tan pronto como la ejecución de A5 ha finalizado, el token pasa al nodo
final del fl ujo que luego finaliza esta ruta de ejecución. Ninguna otra ruta de ejecución se ve
afectada.
• Una ficha adicional se activa A6. Después de la ejecución de A6, todos los bordes salientes de A6 se
asignan tokens y por lo tanto A8 y A9 se ejecutan al mismo tiempo. A10 solo se puede ejecutar
cuando los tokens están presentes en todos los bordes entrantes, es decir, cuando A8 y A9 ha
sido completado. Si miramos el flujo del token, podemos ver que múltiples bordes salientes de
una acción son equivalentes a un nodo de paralelización. Si varios bordes conducen a un nodo
de acción, todas las rutas de ejecución entrantes deben completarse antes de la ejecución de
esta acción. Este comportamiento también se podría modelar utilizando nodos de sincronización
como alternativa. El tercer token se activa A7.
•
Cuando A7 y A10 ambos se han ejecutado con éxito y, por lo tanto, hay un token en
ambos bordes entrantes del nodo de sincronización, estos tokens se fusionan en un
token y A11 Está activado. Dependiendo del valor de la variable y, el nodo de decisión
pasa el token a A12 Si
[y ≤ 0] es cierto o para A13 Si [ y> 0] es verdad. En ambos casos, después de la ejecución de la
actividad respectiva, el token ingresa al nodo final de la actividad. Cuando el token alcanza el
nodo final de la actividad, finaliza toda la actividad. Los tokens restantes se retiran de todas
las acciones. Por tanto, por ejemplo, la ejecución de A5 finaliza si esta acción aún no ha
finalizado en este momento.
Figura 7.15
UN
Ejemplo del concepto de
token
[x≤0]
A2
A1 A4 F1
A3
[x> 0]
A8
A6 A10
A9
F1 A7 F2
A5
[y≤0]
A12
F2 A11
A13
[y> 0]
7.4 Flujos de objetos
Control de tokens vs datos Hasta este punto, nos hemos centrado principalmente en el flujo de control, concentrándonos en la
tokens secuencia lógica de acciones. El concepto de token descrito se utiliza exclusivamente tokens de control. Para
simplificar, hasta ahora nos hemos referido a estos simplemente como tokens. Sin embargo, puede darse
el caso, o incluso es muy probable, que las acciones intercambien datos utilizando tokens de datos. Al
igual que los tokens de control, estos nunca se dibujan en el diagrama y también se usan solo para
describir la semántica de ejecución de los diagramas de actividad. Los tokens de datos también son
tokens de control implícitamente, ya que el intercambio de estos tokens influye en el flujo de la actividad.
Los datos pueden ser el resultado de una acción y también pueden servir como entrada para una acción
posterior. Sin embargo, los datos también se pueden recibir a través de los parámetros de entrada de la
actividad y pasar a los parámetros de salida, como ya se describió anteriormente (ver Figura 7.1 en la
página 143).
Los parámetros de entrada generalmente solo se leen una vez al comienzo de la actividad y los
parámetros de salida se escriben una vez al final de la actividad. Si desea permitir que los parámetros
se lean y escriban continuamente durante la ejecución de la actividad, puede etiquetar el parámetro de
entrada o salida con la palabra clave { corriente}. Figura 7.16 muestra ejemplos de flujos para
parámetros de entrada y salida de actividades o acciones (los parámetros para acciones se describen
a continuación). Los parámetros de transmisión de acciones se pueden señalar mediante un
rectángulo relleno.
Figura 7.16
Transmitir conferencia
Ejemplo de arroyos {corriente} {corriente}
datos: String video: String
Tocar
Cuando finaliza la actividad, a los parámetros de salida que no tienen token se les asigna un
Nodos de objeto token nulo. Dentro de una actividad, puede utilizar nodos de objeto para representar explícitamente
el intercambio de datos. Los nodos de objeto se pueden representar de varias formas. Se
Objeto muestran como un nodo separado como en el diagrama de objetos (consulte la página 49) o se
adjuntan a una acción directamente como pines de entrada o salida. Figura 7.17 da un ejemplo de
un nodo de objeto como un nodo independiente. Se agrega como un rectángulo entre la acción
que entrega los datos y la acción que consume los datos. El rectángulo contiene el nombre del
objeto que representa. Opcionalmente, también puede especificar un tipo de objeto. Entre
corchetes, también puede estipular el estado en el que debe estar el objeto.
7.4 Flujos de objetos 155
Figura 7.17
Flujo de asignación
t: Ejemplo de un nodo de objeto
Tarea
Proceso :Tarea
Correcto
tarea [resuelto]
grado:
Entero
:Tarea
Grado
[corregido]
los notación pin para acciones corresponde a la notación de parámetros de una actividad. Patas
Se usa de la misma manera para representar objetos que sirven como entrada y salida para
Acción
acciones. Se especifica un pequeño rectángulo al principio o al final del borde en el límite de la
acción correspondiente. El pin se puede anotar con la misma información que usamos cuando
representamos explícitamente nodos de objetos como rectángulos. Figura 7.18
muestra un ejemplo.
Figura 7.18
Flujo de asignación
t: grado: Ejemplo de un nodo de objeto en
Tarea Entero notación pin
: Tarea: Tarea
Proceso: Tarea: Tarea
Correcto Grado
tarea
El diagrama de actividad ofrece nodos de objetos especiales para guardar y transferir

tokens de datos: el búfer central y el almacén de datos. los búfer central es un nodo de Búfer central
objeto especial que administra el flujo de datos entre múltiples fuentes y múltiples «CentralBuffer»
receptores. Acepta tokens de datos entrantes de los nodos de objeto y los pasa a otros CB
nodos de objeto. A diferencia de los pines y los parámetros de actividad, un búfer central no
está vinculado a acciones o actividades. Cuando se lee un token de datos del búfer central,
se elimina allí y no se puede volver a consumir. Figura 7.19 muestra un ejemplo del uso de
un búfer central. Para ejecutar la acción Conceder autorización de acceso, Se debe retirar una
llave del KeyCabinet. La clave ya no está en el KeyCabinet hasta que se devuelva en la acción
Retirar la autorización de acceso.

en un Almacén de datos, todos los tokens de datos que fluyen hacia el almacén de datos se guardan de Almacén de datos
forma permanente, lo que significa que se copian antes de que salgan del almacén de datos nuevamente.
"Almacén de datos"
Puede definir consultas con respecto al contenido del almacén de datos en los bordes salientes que van desde DS
el almacén de datos. Estas consultas se adjuntan al borde de salida mediante el símbolo de nota. Por tanto, un
almacén de datos puede modelar la funcionalidad de una base de datos. Figura 7.20 muestra
Figura 7.19
Gestión de claves para la sala de seminarios
Ejemplo de un búfer central
Autorizará el acceso Conducta Retirar el acceso

autorización Tareas autorización
«CentralBuffer»
KeyCabinet
un ejemplo del uso de un almacén de datos. El desempeño de los participantes de un curso se

gestiona en el almacén de datos ExamData. Estos datos incluyen la evaluación de las tareas asignadas
y los resultados de los exámenes necesarios para calcular la calificación general.
Figura 7.20
Escribir
Ejemplo de un almacén de datos
examen
puntos Calcular Problema

Registrarse
grado certificado
estudiante Completar puntos
datos asignación
puntos
"Almacén de datos"
ExamData
Un búfer central representa la memoria transitoria, mientras que un almacén de datos representa la
memoria permanente. Con el primero, la información sólo se puede utilizar una vez, lo que significa que
una vez que se ha leído desde el búfer central y se ha reenviado, se pierde. Con un almacén de datos, la
información se puede utilizar tantas veces como sea necesario, siempre que se haya guardado una vez en
el almacén de datos.
7.5 Particiones
Dividir UN dividir le permite agrupar nodos y bordes de una actividad en función de propiedades comunes. Si
UN segundo
consideramos un proceso de negocio, por ejemplo, podríamos usar una partición para agrupar todas las
acciones que una entidad específica es responsable de ejecutar. UML no tiene reglas estrictas con respecto
a los criterios de agrupación que se pueden utilizar. Generalmente, las particiones reflejan unidades
organizativas
7.5 Particiones 157
o roles que son responsables de la ejecución de las acciones dentro de las particiones. Puede
especificar particiones en diferentes niveles de detalle hasta el nivel de clases individuales. Las
particiones pueden superponerse y anidarse de la forma necesaria. No cambian el significado de la
semántica de ejecución de un diagrama de actividad, que se define mediante tokens. Esto significa
que las particiones no influyen en el flujo del token, sino que simplemente representan una vista
lógica de sus componentes. Las particiones hacen que el diagrama sea más claro, permitiéndole ver
las áreas de responsabilidad rápidamente, introduciendo así información más detallada en el
modelo.
Las particiones se pueden representar gráficamente o en forma textual. Cuando se representan

en forma gráfica, se colocan en la parte superior del diagrama de actividades como rectángulos
"abiertos". Todos los elementos que se encuentran dentro de un rectángulo "abierto" pertenecen a un
grupo común. El nombre de la partición se especifica en un extremo del rectángulo. Debido a su
apariencia, las particiones también se denominan carriles. Figura 7.21 muestra un ejemplo del uso de
particiones en un diagrama de actividades que modela la ejecución de un examen. Las partes Sinónimos:
involucradas son un estudiante, un asistente y un profesor. El uso de particiones permite que a cada
• Dividir
uno de estos actores se le asignen las acciones que deben realizar.
• Carril de natación
Figura 7.21
Profesor Asistente Estudiante Ejemplo de uno
particiones dimensionales
"Almacén de datos"
Inscripciones
Crear Impresión Tomar

examen instrucciones examen
Correcto
examen
Publicar
resultados
Una partición se puede subdividir en múltiples subparticiones. Figura 7.22 muestra un Subpartición
ejemplo de esto. En este ejemplo, los empleados del instituto Profesor y Secretario están
involucrados en la ejecución de un examen.
Figura 7.22
Ejemplo de subparticiones Estudiante Empleado del Instituto
Profesor Secretario
Escribir Correcto Problema

examen examen certificado
Como podemos ver en el ejemplo de Figura 7.23 , las particiones también pueden ser
multidimensional. En este ejemplo, modelamos la correspondencia entre un profesor de

la Universidad Johannes Kepler de Linz ( JKU Linz) y la Universidad Tecnológica de Viena
( TU Viena). los Profesor a TU Viena escribe una carta al Profesor a JKU Linz. El profesor
entrega la carta al Secretario, quien lleva la carta a la oficina de correos. los Secretario a JKU
Linz recoge la carta del buzón tan pronto como llega la carta y la envía al Profesor a JKU
Linz, quien luego lo lee. Esto muestra cómo necesitamos particiones multidimensionales
cuando varios grupos de actores pueden aparecer en diversas formas.
Figura 7.23
Ejemplo de multi- Profesor Secretario
particiones dimensionales
Tomar carta
TU Viena
Escribir carta
a la oficina de correos
Letra
JKU Linz
Vacío
Leer carta
buzón
También puede asignar una acción a una partición o, en el caso de particiones

multidimensionales, a un conjunto de particiones en forma de texto. En esta situación, especifique
las particiones entre paréntesis encima del nombre de la acción. Si la acción pertenece a varias
particiones, estas particiones se enumeran separadas por una coma, por ejemplo ( Partición 1,
Partición 2). Al especificar
7.6 Manejo de excepciones 159
Figura 7.24
(TU Viena, profesor) (TU Viena, secretaria) Ejemplo de multi-
Escribir carta Lleve la carta a la oficina de correos particiones dimensionales
con notación textual
(JKU Linz, secretaria)

Letra
(JKU Linz, profesor) (JKU Linz, secretaria)

Leer carta Buzón vacío
subparticiones, usa dos puntos dobles— ( Partición :: Subpartición) —Expresar una partición
jerárquica. El diagrama de actividad de Figura 7.24
muestra el ejemplo de Figura 7.23 en esta notación.
7.6 Manejo de excepciones
Si ocurre un error durante la ejecución de una acción, la ejecución se termina. En esta situación, no hay
garantía de que la acción dé el resultado esperado. Si una acción tiene un manejador de excepciones para
una situación de error específica, este manejador de excepciones se activa cuando ocurre una Controlador de excepciones
excepción. Con un manejador de excepciones, puede definir cómo reaccionará el sistema en una mi Excepción-
situación de error específica. mi. Esto le permite minimizar los efectos de este error. Usted especifica un Manipulador
manejador de excepciones para un tipo específico de error, es decir, puede usar diferentes
manejadores de excepciones para diferentes errores. Si se produce una situación de error, todos los Acción
tokens de la acción en cuestión se eliminan de inmediato. Si hay un manejador de excepciones
coincidente, esto reemplaza el contenido de la acción en cuestión y, en su lugar, se ejecuta el
contenido del manejador de excepciones. La secuencia luego continúa como la ruta regular de la
actividad como si la acción defectuosa hubiera terminado normalmente. Como un controlador de
excepciones es un nodo de actividad, se representa como un rectángulo con esquinas redondeadas. La
acción protegida por el manejador de excepciones apunta al manejador de excepciones con una flecha
de rayo. La punta de la flecha está etiquetada con el tipo de error. Figura 7.25 muestra dos ejemplos
para manejar excepciones. Si se produce un atasco de papel durante la impresión, la impresión puede
continuar una vez que se haya eliminado el atasco de papel. Si no hay papel en la impresora, se debe
insertar papel para que la impresión continúe hasta que se hayan impreso suficientes copias de las
instrucciones del examen.
Figura 7.25
Ejemplos de excepción
manejo
Crear examen
instrucciones
Mermelada de papel
Resolver
Mermelada de papel
Imprimir examen
[No] instrucciones
Agregar papel
Ir a buscar Insertar
papel papel
bandeja de papel
vacío
«DecisionInput»
[si]
¿Se imprimieron suficientes copias?
Si hay varios manejadores de excepciones coincidentes, no se especifica el manejador que se

ejecutará. Si no hay un manejador de excepciones coincidente, la excepción se reenvía a la
estructura circundante. Si la excepción se pasa a la actividad más externa sin que se encuentre un
manejador de excepciones coincidente, el comportamiento del sistema no está definido.
Un manejador de excepciones no tiene bordes entrantes o salientes explícitos. Tiene los

mismos derechos de acceso a variables y valores que los nodos que protege. Los tokens que
resultan de la ejecución del contenido del manejador de excepciones se convierten en tokens
de resultado del nodo protegido. Por lo tanto, el controlador de excepciones y el nodo
protegido deben tener el mismo número de valores devueltos. Esto asegura que, en caso de
error, cada borde de salida del nodo protegido recibe el token requerido.
Actividad interrumpible los región de actividad interrumpible ofrece una forma más de manejar excepciones. Usando
región este concepto, puede definir un grupo de acciones cuya ejecución debe terminar inmediatamente si
ocurre un evento específico. La región de actividad interrumpible se representa como un rectángulo
segundo
discontinuo con esquinas redondeadas que encierra las acciones relevantes. La ejecución de estos
eventos se monitorea para detectar la ocurrencia de un evento específico, por ejemplo, un error. Si el
mi
evento ocurre durante esta ejecución, entonces, como consecuencia, se ejecuta cierto
comportamiento. Dentro de la región de actividad interrumpible, modela una acción de evento de
UN aceptación que representa el evento especial y conduce desde el borde en forma de rayo a una
actividad fuera de la interfaz.
7.7 Ejemplo final 161
región de actividad rompible. Si ocurre el evento modelado, se eliminan todas las fichas de control
en la región de actividad interrumpible y se activa la acción a la que apunta la acción del evento de
aceptación. Figura 7.26 muestra un ejemplo de una región de actividad interrumpible. Si un
estudiante se da de baja de la universidad mientras asiste a un curso, la acción Retirar estudiante es
ejecutado. Sin embargo, un retiro solo es posible si el estudiante se ha registrado previamente y si
la acción Tomar examen aún no ha terminado. En todos los demás casos se emite un certificado.
Figura 7.26
Ejemplo de una región de actividad
interrumpible
Registrarse
Asistir Completar
conferencia asignación
Retirar
estudiante
Retirar
Tomar
examen
Problema
certificado
7.7 Ejemplo final
En resumen, nos fijamos en el proceso que debe ejecutar un futuro estudiante de una universidad para recibir una
tarjeta de identificación de estudiante (carnet de estudiante). Usamos un diagrama de actividad para modelar este
proceso. En forma textual, el proceso de emisión de una identificación de estudiante se puede describir de la
siguiente manera: Para obtener una identificación de estudiante, el estudiante debe solicitar esta identificación a
un empleado de la oficina de estudiantes. El empleado le entrega al estudiante los formularios que el estudiante
debe llenar para registrarse en la universidad. Estos formularios incluyen la identificación del estudiante, que es
una pequeña tarjeta de cartón de estilo antiguo. los

el estudiante tiene que ingresar datos personales en esta tarjeta y el empleado lo confirma con
un sello después de compararlo con ciertos documentos. La identificación de estudiante solo es
válida si tiene una etiqueta de semestre actual. Una vez que el estudiante ha llenado los
formularios, el estudiante se los devuelve al empleado en la oficina del estudiante y le entrega
documentos tales como identificación con foto, certificado de salida de la escuela y certificado
de nacimiento. El empleado revisa los documentos. Si los documentos están incompletos o el
estudiante no está autorizado para recibir una identificación de estudiante de la universidad, el
proceso se da por terminado de inmediato. Si todos los documentos están en orden, el
empleado verifica si el estudiante ha completado correctamente la identificación del estudiante.
Si hay algún error, esta identificación se destruye y el estudiante debe completar otra. De lo
contrario, se estampa la identificación. Sin embargo,
Dos actores están involucrados en el proceso a modelar: el Estudiante y el Empleado. Para asignar
las acciones individuales de forma precisa, utilizamos particiones. Podemos derivar las acciones y el
flujo de control directamente del texto anterior y estos se muestran en Figura 7.27 . Para modelar la
terminación del proceso en caso de documentos no válidos o incompletos, utilizamos un nodo de
decisión donde una ruta conduce a un nodo final de actividad. El requisito de que parte de todo el
proceso debe repetirse si los formularios se llenan incorrectamente da como resultado el uso de un
bucle. Implementamos esto con un nodo de decisión después de la acción. Verificar ID y un nodo de
fusión antes de la acción Crear ID. Si permitiéramos que el borde condujera directamente al nodo de la
acción Crear ID, necesitaríamos dos tokens para la ejecución de esta acción. Como esto nunca
sucederá, es importante utilizar un nodo de combinación. Si el estudiante ha entregado los
documentos en su totalidad y ha llenado los formularios correctamente, se sella la identificación del
estudiante y el estudiante recibe la etiqueta del semestre actual por correo. Modelamos esta acción
como una acción de evento de aceptación. Para validar la identificación, el estudiante debe pegar la
etiqueta. Esta acción finaliza el proceso que debe ejecutarse para obtener una nueva identificación de
estudiante.
En el diagrama de actividad de Figura 7.27 , hemos modelado solo el

flujo de control. Sin embargo, en este ejemplo, se cambia un objeto: el ID del estudiante. Inicialmente está en
blanco, luego se llena y luego se estampa. Una identificación de estudiante no es válida hasta que se haya
colocado la etiqueta del semestre. Los cambios en la identificación del estudiante se muestran en Figura 7.28 ,
que se expande Figura 7.27 para incluir el flujo de objeto del objeto Identificación del Estudiante. Esto resalta qué
acciones necesitan y procesan el objeto. Identificación del Estudiante.
Los elementos más importantes del diagrama de actividades se resumen en Tablas 7.1 y 7.2
.
Figura 7.27
Estudiante Empleado Diagrama de actividad "Problema
Identificación del Estudiante"
Solicitud Crear
CARNÉ DE IDENTIDAD CARNÉ DE IDENTIDAD
Llenar
CARNÉ DE IDENTIDAD
Entregar Cheque
documentos restante
e identificación documentos
Devolver
documentos
[No está bien]
[Okay]
Cheque
CARNÉ DE IDENTIDAD
Destruir [No está bien]
CARNÉ DE IDENTIDAD
[Okay]
Sello
CARNÉ DE IDENTIDAD
Recibir
etiqueta de semestre
Afijo
etiqueta
Figura 7.28
Diagrama de actividad "Problema
Estudiante Empleado
ID de estudiante ”con control y fl ujo

de objetos
Solicitud Crear
CARNÉ DE IDENTIDAD CARNÉ DE IDENTIDAD
Llenar :CARNÉ DE IDENTIDAD

CARNÉ DE IDENTIDAD [blanco]
Entregar Cheque
documentos restante
e identificación documentos
Devolver
documentos
[No está bien]
[Okay]
:CARNÉ DE IDENTIDAD Cheque

[rellenado] CARNÉ DE IDENTIDAD
Destruir [No está bien]
CARNÉ DE IDENTIDAD
:CARNÉ DE IDENTIDAD
[Okay]
[inválido]
Sello
CARNÉ DE IDENTIDAD
Recibir :CARNÉ DE IDENTIDAD
etiqueta de semestre [sellado]
Afijo :CARNÉ DE IDENTIDAD
etiqueta [válido]
Cuadro 7.1
de actividades
Las acciones son atómicas, es decir, no pueden
Nodo de acción Acción
desglosarse más
Nodo de actividad Actividad Las actividades se pueden desglosar aún más
Nodo inicial Inicio de la ejecución de una actividad
Fin de TODAS las rutas de ejecución de una actividad

Nodo final de actividad
Fin de UNA ruta de ejecución de una actividad

Nodo final de flujo
División de una ruta de ejecución en dos o

más rutas de ejecución alternativas
...
Nodo de decisión
Fusión de dos o más rutas de ejecución

...
Fusionar nodo alternativas en una sola ruta de ejecución
División de una ruta de ejecución en dos o

...
Nodo de paralelización más rutas de ejecución simultáneas
Fusión de dos o más rutas de ejecución

...
Nodo de sincronización simultáneas en una sola ruta de ejecución
Conexión entre los nodos de una actividad

Borde UN segundo
Acción UN se refiere a una actividad del mismo nombre

Acción de comportamiento de llamada UN
Contiene datos y objetos que se crean,

Nodo de objeto Objeto
modifican y leen
Parámetros para activi- Contener datos y objetos como parámetros de

Actividad
corbatas entrada y salida
Parámetros para acciones Contener datos y objetos como parámetros de

Acción
(patas) entrada y salida
Cuadro 7.2
de actividades, parte 2 UN segundo
segundo UN
Agrupación de nodos y aristas dentro de una
Dividir
actividad
Enviar acción de señal S Transmisión de una señal a un receptor
Aceptar asincrónico mi o
Espera un evento mi o un evento temporal T
(tiempo) acción del evento
T
mi Excepción-
Manipulador
El controlador de excepciones se ejecuta en lugar
Controlador de excepciones
de la acción en caso de error. mi
Acción
segundo
Actividad interrumpible El flujo continúa por una ruta diferente si el evento mi es

mi
región detectado
UN
Capítulo 8
Todos juntos ahora
En los capítulos anteriores, hemos examinado en detalle cinco diagramas UML que nos
permiten describir diferentes aspectos de un sistema. En los ejemplos dados, hemos
visto que cada diagrama realiza diferentes vistas de un sistema. Por lo tanto, los
diagramas deben interpretarse juntos como un todo, teniendo en cuenta cómo
interactúan entre sí, en lugar de considerar cada uno de forma aislada. Se
complementan entre sí ilustrando el sistema a desarrollar desde diferentes perspectivas.
En este capítulo, modelamos tres ejemplos concretos de diferentes áreas de aplicación
que muestran la interacción entre los diferentes diagramas.
8.1 Ejemplo 1: Máquina de café
Un dispositivo importante que se encuentra una y otra vez en una universidad es la máquina
de café. Veamos una máquina de café con filtro como se muestra en Figura 8.1 . La máquina
de café consta de un depósito de agua, una placa calefactora, una cafetera y una tubería de
agua que va desde el depósito de agua hasta el fi ltro. Cuando hay agua en el tanque y la
máquina de café está encendida, el agua se calienta. La presión empuja el agua hacia arriba
a través del tubo hacia el fi ltro que contiene el café molido. Finalmente, el café preparado
fluye fuera del fi ltro hacia la cafetera. La máquina de café está disponible en dos versiones
diferentes, una con función “mantener caliente” (modelo A) y otra sin (modelo B). Si el
depósito de agua está vacío y la máquina de café está encendida, en el modelo A se activa
la función “mantener caliente”. En la misma situación, el modelo B simplemente se apaga.
Los diagramas de casos de uso en Figura 8.2 describir la funcionalidad de- Use el diagrama del caso

Computación, DOI 10.1007 / 978-3-319-12742-2_8
168 8 Todos juntos ahora
Figura 8.1
Maquina de cafe
Filtrar
Agua
café
tanque
maceta
Placa calefactora
el modelo A y el modelo B. Mientras que el modelo A ofrece las dos funciones

Caliente el café y Hacer café, el modelo B solo se puede utilizar para hacer café. En ambos casos,
asumimos máquinas de café muy simples que se limitan a las "competencias básicas" de las
máquinas de café.
Figura 8.2
Maquina de cafe Maquina de cafe
Diagramas de casos de uso para una
modelo A modelo B
máquina de café
Hacer
café
Hacer
café
Usuario Calor Usuario
café
Naturalmente, los usuarios pueden encender y apagar la máquina de café. También deben
ser posibles actividades de mantenimiento como llenar la máquina con café o limpiar el fi ltro.
No los hemos modelado intencionalmente como casos de uso separados, ya que son tareas
preparatorias necesarias para lograr el objetivo real: el café preparado o calentado.
Figura 8.3 encender

en
Diagrama de la máquina de estado para la
apagado
máquina de café modelo B hacer / hacer café
8.1 Ejemplo 1: Máquina de café 169
De la descripción, podemos ver que ambos modelos de máquinas de café pueden tomar los Diagrama de la máquina de estado
estados en y apagado. El modelo B sale del estado en cuando se ha hecho el café (ver Figura 8.3 );
en el modelo A, el evento apagar debe ocurrir para este cambio de estado. En el modelo A, el estado en
se puede refinar en los estados Listo ( donde esté disponible la función de calefacción) y en uso ( se
está haciendo el café). La máquina solo puede cambiar al estado en uso
cuando el depósito de agua de la cafetera está lleno (ver Figura 8.4 ).
Figura 8.4
en
Diagrama de la máquina de estado para la
Listo máquina de café modelo A
Listo
hacer / calentar café
]
der [vacío
encen
apagado encen cuando (lleno)
der [lle
no]
en uso
utilizado
hacer / hacer café
apagar
El diagrama de actividad en Figura 8.5 describe cómo usar la máquina de café Diagrama de actividad
modelo B. Primero, la máquina de café está preparada para hacer el café. Esto implica
limpiar el fi ltro, llenar la máquina con café molido, llenar la máquina con agua y
encenderla. Tenga en cuenta que el fi ltro siempre se limpia antes de agregar el café
molido y que el agua se agrega antes de encender la máquina de café; de lo contrario, la
máquina se apaga automáticamente.
Aparte de estas restricciones, las acciones se pueden realizar en cualquier orden. Esto
está representado en el diagrama de actividad por dos subrutas concurrentes, cada una
con un nodo inicial separado. El café no se hace, es decir, el agua no se vierte a través del
filtro, hasta que los dos bordes entrantes del nodo de sincronización obtienen una ficha.
Nuestro diagrama no cubre una situación en la que la máquina de café se usa sin limpiar el
filtro y sin agregar café molido.
El diagrama de actividad en Figura 8.6 describe el uso del modelo A. Tan pronto como
se enciende la máquina de café, ejecuta la acción Caliente el café. Cuando la máquina de
café está completamente preparada para hacer café, es decir, cuando se han agregado café
molido y agua, la función de mantener caliente se apaga y el café está listo. Modelamos esto
con un nodo de sincronización. La señal Apagar finaliza todo el proceso.
Figura 8.5
Diagrama de actividad de la
cafetera modelo B
Añadir Limpiar
agua filtrar
Agregar terreno
Encender
café
Hacer
café
Verter
café
Figura 8.6
Diagrama de actividad de la
cafetera modelo A Encender
Calor
café
Añadir
agua
Limpiar
filtrar
Agregar terreno
café
Apagar
Hacer
café
Verter
café
8.2 Ejemplo 2: Sistema de envío 171
8.2 Ejemplo 2: Sistema de envío
Los diagramas UML se utilizan generalmente para describir sistemas de software, como el
sistema de administración de estudiantes de una universidad, que hemos analizado en este libro
desde varios aspectos. La creación de un modelo continuo y detallado de todo el sistema que
realmente podría implementarse en código ejecutable iría más allá del alcance de este libro. Sin
embargo, volveremos a extraer una parte del sistema para ilustrar la interacción de los diferentes
diagramas. Con este fin, veremos un sistema de envío que se utilizará para gestionar los envíos,
es decir, los trabajos de los estudiantes para las tareas asignadas. Los requisitos para este
sistema son los siguientes:
• Cada curso del sistema tiene profesores asignados. Esto lo hace uno de los administradores del
curso, que también es profesor. Como parte de un curso, los profesores pueden crear tareas y
evaluar los trabajos presentados por los estudiantes. Por lo tanto, los profesores otorgan puntos
y dan su opinión. El administrador del curso define qué profesor evalúa qué documentos. Al final
• del curso, el administrador del curso también se encarga de que se emitan los certificados. La
calificación de un estudiante se calcula en función del número total de puntos obtenidos por las
presentaciones entregadas. Los estudiantes pueden tomar cursos y cargar trabajos.
•
• Todos los usuarios (estudiantes y profesores) pueden administrar sus datos de usuario, ver los cursos y las
tareas establecidas para los cursos (siempre que el usuario respectivo esté involucrado en el curso) y ver
los trabajos enviados, así como los puntos de calificación. Sin embargo, los estudiantes solo pueden ver
sus propios trabajos y las calificaciones relacionadas. Los profesores solo pueden ver los trabajos que se
les asignen y las calificaciones que les hayan dado. El administrador del curso tiene derechos de acceso a
todos los datos.
• Un administrador crea y elimina un curso.

• Cuando se crea un curso, se le debe asignar al menos un administrador. Se pueden asignar más
administradores de cursos en un momento posterior o se pueden eliminar las asignaciones a los
cursos. El administrador también puede eliminar cursos completos.
• La información sobre usuarios y administradores se transfiere automáticamente desde otro

sistema. Por tanto, no son necesarias funciones que permitan la creación de datos de
usuario.
• Todas las funciones del sistema solo pueden ser utilizadas por personas que hayan iniciado sesión.
Los actores y casos de uso para la especificación anterior se resumen en el diagrama de

en casos de uso en Figura 8.7 . En cuanto a los actores,
diferenciar entre los administradores y todos los demás usuarios, que están en
a su vez subdivididos en profesores y estudiantes. Respecto a los disertantes,
diferenciamos aún más a los administradores de cursos.
Figura 8.7
Gestión de envíos
Diagrama de casos de uso para un
sistema de presentación
Ver
evaluación Ver
sumisión
Ver
curso
Usuario
Gestionar
datos del usuario
Ver tarea
Toma curso
Estudiante Subir
papel
Crear tarea
Conferenciante
Ingrese puntos
Gestionar
curso
Asignar papel
para corrección
Curso
Administrador Problema
certificado
Crear curso
"inclu
ir"
Asignar curso
administrador
Administración
Quitar curso
administrador
Eliminar
curso
Podemos derivar los casos de uso directamente de la especificación anterior. Los casos de
uso generalmente no son lo suficientemente detallados para la implementación real del sistema.
Ahora tenemos que resaltar exactamente qué requisitos debe satisfacer el sistema. Sin embargo,
no incluimos esta información en el diagrama de casos de uso, ya que haría que el diagrama
estuviera sobrecargado y fuera difícil de leer. En cambio, lo documentamos en las descripciones
de los casos de uso que aprendimos en el Capítulo 3.
Los procesos de inicio y cierre de sesión no están representados en el diagrama de casos de uso,
ya que no son funciones deseadas por los actores, sino que contribuyen al uso seguro del sistema. El
inicio de sesión se puede considerar como una condición previa para utilizar el sistema.
Ahora que se han especificado los requisitos del sistema, podemos hacer zoom en el
sistema y modelar su estructura y comportamiento. Representamos la estructura interna del
sistema de presentación con el diagrama de clase que se muestra en Figura 8.8 . Notará que
todos los actores que aparecen en el diagrama de casos de uso también están modelados en el
diagrama de clases, aunque dijimos que no son parte del sistema. Es importante entender que
en el diagrama de clases, son los datos de los actores los que están representados y no los
actores mismos. Estos datos son necesarios para implementar autorizaciones, la asignación de
envíos a los estudiantes, etc. La información sobre los usuarios se almacena en la clase. Usuario. Usamos
el atributo autorización diferenciar entre administradores (valor administración) y todos los demás
usuarios (valor estándar). Los administradores pueden ser instancias directas de la clase Usuario y
los profesores y estudiantes son modelados por otras clases que tienen una relación de herencia
con Usuario. En principio, esto significa que es posible que un profesor o incluso un estudiante
también sea administrador. A primera vista, esto contradice nuestro diagrama de casos de uso,
en el que el actor Administración está en una relación de herencia con
Usuario. Sin embargo, si consideramos que los actores en el diagrama de casos de uso representan
roles, nuestro diagrama de clases es correcto. Por supuesto, una persona puede asumir varios
roles. En el diagrama de casos de uso, solo hemos excluido, por ejemplo, que un administrador
pueda ver automáticamente la información de los cursos. Si realmente quisiéramos modelar una
diferenciación estricta aquí, tendríamos que introducir una clase separada Administración o formular
una restricción que prohíba el atributo autorización de tomar el valor
administración para profesores o estudiantes.
En nuestro diagrama de clases, un profesor se convierte en administrador de un curso al estar

en un da relación con un curso. Las tareas siempre se asignan a un curso, de la misma manera que
las entregas se asignan a una tarea. Modelamos la participación de un estudiante en un curso
usando una clase de asociación que contiene información sobre el número total de puntos del
estudiante y la calificación. Ambos valores se calculan automáticamente y, por lo tanto, los atributos
se etiquetan como atributos derivados.
Figura 8.8
"enumeración"
Diagrama de clases para un sistema Usuario
BType
de sumisión
nombre administración
iniciar sesión estándar

contraseña
autorización: BType
notificación()
actualizar datos()
getAuthorization ()
checkPW ()
obtener datos()
Sumisión Conferenciante
papel * evalúa 1 getCourses ()

fecha getCourseAdministration ()
puntos
1 .. * 1 .. *
corrección
courseAdministrator
obtener datos() * para
actualizar datos()
AssignLecturer ()
1
setGrade ()
setPaper () Tarea da participa
* nombre
descripción
1
fecha límite
puntos
Participación
fecha límite de presentación
/puntos totales
* 1 .. *
obtener datos()
/Grado actualizar datos() Curso
certificado emitido getSubmissions ()
nombre
*
obtener puntos()
semestre
getSubmissions ()
1
updatePoints ()
addCourseAdministrator ()
issueCertificate ()
delCourseAdministrator ()
obtener datos()
actualizar datos()
Estudiante addParticipation ()
agregar tarea()
matNo issueCertificate ()
informStudent ()
obtener datos() informLecturer ()
getParticipations () * * informCourseAdministrator ()
certificateInfo () uploadPaper ()
El diagrama de clases en Figura 8.8 no garantiza que un profesor solo pueda evaluar las
tareas de un curso en el que esté involucrado este profesor. Tenemos que especificar estas y
otras restricciones que son importantes para la coherencia del sistema en general. Por lo tanto,
se requieren restricciones adicionales. Estos se pueden especificar en lenguajes como Object
Con- straint Language (OCL) [36], que está más allá del alcance de este libro. Entonces, la
verificación que determina si las instancias de un modelo cumplen con las restricciones
especificadas a menudo se puede realizar automáticamente.
En su forma actual, el diagrama de clases no contiene ninguna información específica de

la plataforma, lo que significa que no hemos definido cómo debería verse la implementación.
Para que se desarrolle la especificación general del sistema, queremos permanecer en este
nivel abstracto en los pasos siguientes.
En el siguiente paso, queremos modelar un escenario de uso típico del sistema de envío,
es decir, cómo los actores, el sistema y las funciones que hemos especificado en el diagrama
de casos de uso interactúan en una situación específica. Podríamos crear un diagrama de
actividades para hacer esto. Sin embargo, como queremos centrarnos en el aspecto de la
comunicación, utilizamos un diagrama de secuencia en su lugar. Figura 8.9 muestra el siguiente
escenario de uso: Un estudiante carga el trabajo de tarea resuelto en el sistema de envío. El
sistema informa al administrador del curso que se ha enviado un nuevo trabajo de tarea y
confirma al estudiante que el trabajo se ha recibido con éxito. En el diagrama de secuencia, no
mostramos la acción necesaria para guardar el trabajo enviado ya que no es relevante para la
representación de este proceso de comunicación específico. A través del sistema de envío, el
administrador del curso asigna un conferenciante al trabajo. Una vez que el sistema ha
informado al profesor que se ha asignado un trabajo, el profesor evalúa el trabajo. Para ello, el
profesor descarga el trabajo del sistema de envío e ingresa la calificación en el sistema. Luego
se informa al estudiante que el trabajo cargado ha sido calificado. El fl ujo de comunicación
descrito tiene lugar no solo una vez, sino para cada tarea que debe completarse para un curso.
Por lo tanto, en el diagrama de secuencia en Figura 8.9 , los mensajes descritos anteriormente
están encerrados por un
lazo fragmento.
Una vez que se hayan procesado todas las tareas, el administrador del curso puede
organizar la emisión de los certificados. El sistema de envío también informa al estudiante de la
nota final.
El diagrama de secuencia descrito en Figura 8.9 re fl eja el uso del sistema de
presentación a un nivel de abstracción muy alto. Aunque esto resalta la función general del
sistema, todavía no se especifican muchos detalles. Por lo tanto, tenemos que acercarnos
más al sistema. Para ilustrar esto, veamos la actividad Emitir certi fi cado se muestra en la Figura
8.10 . Aquí hemos decidido utilizar un diagrama de actividades para ilustrar el proceso
detallado.
Figura 8.9
:Curso :Sumisión :Participación
Flujos de comunicación
Estudiante Curso Conferenciante
Administrador
loop (1, numberTasks)
uploadPaper ()
setPaper ()
notificación()
notificación()
AssignLecturer ()
informar
Conferenciante()
notificación()
obtener datos()
setGrade ()
informStu-
mella()
actualizar
Puntos()
notificación()
issueCertificate ()
issueCer-
tificar ()
certifi-
cateInfo ()
Suponemos que en la interfaz de usuario, el administrador del curso ve una descripción general de
los cursos asignados. En primer lugar, el administrador del curso selecciona el curso para el que se
emitirán los certi fi cados. Se muestran los alumnos que han realizado el curso. El administrador del
curso puede entonces seleccionar si emitir certificados para todos o solo para ciertos estudiantes. En
este último caso, el administrador también debe especificar los estudiantes que obtendrán los
certificados. Las calificaciones se calculan, se envían a la oficina de estudiantes y se informa a cada
estudiante de la calificación. Tenga en cuenta que para la implementación práctica, es extremadamente
importante modelar todos los flujos posibles en tanto
Figura 8.10
Administrador del curso Curso Oficina de estudiantes Diagrama de actividad para "Emitir certi fi
cado"
Seleccione Monitor
curso estudiantes
Seleccione
modo de emisión
[más]
[para todos]
Seleccione
estudiantes
Calcular
Los grados
Enviar Recibir
Los grados Los grados
Problema
certificados
Informar
estudiantes
detalle como sea posible y lo más cerca posible de la realidad. En nuestro diagrama de
actividad no hemos considerado las situaciones de error. Tampoco es posible en nuestro
diagrama corregir manualmente un certificado que ya ha sido emitido. Todos estos casos
también deberían tenerse en cuenta. Modelar los procesos incorrectamente puede llevar a que
el sistema no sea aceptado por sus usuarios. Como resultado, no se logrará la mayor
eficiencia esperada con la introducción del sistema.
Para describir el sistema con precisión, es importante también mostrar los estados que
pueden adoptar los componentes individuales del sistema y el sistema en sí. Como ejemplo,
veamos los diagramas de la máquina de estados para la presentación de un artículo (ver Figura
8.11 ) y para la participación en un curso (ver Figura 8.12 ).
Figura 8.11 subir papel asignar profesor

Diagrama de máquina de estados para creado subido asignado
clase Sumisión
juzgado
cuando (fecha límite de envío <ahora) grado
/ puntos = 0
En nuestro sistema, una instancia de clase Sumisión se refiere a la carga de un trabajo

por parte de un estudiante que luego puede ser evaluado por el profesor. Por tanto, la
presentación se refiere a la administración del expediente que el estudiante entrega al
profesor para la evaluación, y no al expediente en sí. Cuando se crea y libera una tarea
para los estudiantes, cada estudiante puede enviar un trabajo en el sistema. La
presentación tiene inicialmente el estado creado. Sale de este estado cuando el estudiante
carga un trabajo o cuando expira el plazo de presentación; en este último caso, la tarea se
evalúa con cero puntos para el estudiante. La presentación luego cambia al estado juzgado. Si
el estudiante envía el trabajo resuelto en el sistema, el envío cambia al estado subido. Sale
de este estado cuando la presentación se asigna a un profesor para su evaluación. Una vez
realizada la evaluación, el envío toma el estado final. juzgado.
Dado que la información sobre un envío se almacena con fines de documentación, el envío
permanece en el estado juzgado “Para siempre” y no se modela ningún estado final.
Los estados que un participante específico de un curso específico puede tomar se describen de
manera similar (ver Figura 8.12 ). En nuestro ejemplo, la participación se refiere a la participación en
el curso de un determinado estudiante en un determinado curso. Se documenta si un estudiante ha
completado un curso y, si este es el caso, se guarda la calificación que el estudiante recibió para
este curso. Cuando un estudiante se ha registrado para un curso, el estado de participación del
estudiante en este curso específico es inicialmente no evaluado. Esto muestra claramente por qué
describimos los estados de participación en el curso y no los estados de un estudiante. Si un
estudiante tuviera el estado no evaluado, no sería posible diferenciar entre los diferentes cursos que
ha realizado el alumno. Sin embargo, lo que queremos mostrar es el estado de un estudiante con
referencia a un curso específico. En el diagrama de clases, esta información se tiene en cuenta con
la clase de asociación. Participación ( ver Figura 8.8 ).
Para un curso específico, un estudiante está inicialmente en el estado no evaluado, luego
en el estado evaluado parcialmente, y finalmente en el estado certificado emitido,

a menos que el estudiante no sea evaluado en absoluto. Esto puede suceder, por ejemplo, si el
estudiante estaba registrado pero nunca asistió al curso y nunca completó ninguna actividad. El
estado certificado emitido tiene dos subestados: positivo y negativo. Los guardias especifican cuál de
estos estados ocurre. Estos subestados pueden cambiar si se corrige un certificado.
Los diagramas en Figuras 8.7 a 8.12 Ilustre cómo se pueden modelar los diferentes
aspectos de un sistema de presentación y la interacción entre estos aspectos. Sin embargo,
no especifican ningún detalle técnico para la implementación, sino que representan un
esquema que describe cómo debería verse el sistema. Una vez que se han documentado
todos los requisitos en el modelo, puede comenzar la implementación real. Son factibles
diferentes enfoques. Una opción sería iniciar la implementación en código ejecutable
inmediatamente. Sin embargo, como no se especifican interfaces, tarde o temprano los
diferentes componentes ya no encajarán, lo que hace que el mantenimiento del sistema sea
más complicado que con interfaces cuidadosamente diseñadas.
Por lo tanto, recomendamos perfeccionar el modelo hasta que tenga una especificación
exacta del sistema que se va a desarrollar.
Figura 8.12
Diagrama de máquina de estados para la
participación de un estudiante en un curso

no cuando (fin de semestre)
juzgado
updateAssessment
parcialmente
updateAssessment
juzgado
issueCertificate issueCertificate
[≥50% de los puntos] [<50% de puntos]
certificado emitido
corrección [grado <5]

positivo negativo
corrección [grado = 5]
8.3 Ejemplo 3: Pila de tipos de datos
El ejemplo final de este capítulo es el modelado de la estructura de datos

Apilar. Los elementos se pueden colocar en la pila usando el empujar función y se eliminan
de la pila con el popular función. El orden en el que se eliminan los elementos sigue el
principio LIFO (último en entrar, primero en salir), lo que significa que popular siempre entrega
el elemento que se colocó por última vez en la pila con empujar y lo saca de la pila.
Funciones adicionales que la clase Apilar debe soportar son la determinación del tamaño real
de la pila, es decir, el número de elementos en la pila y la consulta sobre si un elemento está
en la pila. Como queremos realizar una pila sin restricción de tamaño, lo hacemos usando
una estructura de datos recursiva como se muestra en el diagrama de clases en Figura 8.13 .
La clase
Apilar solo conoce el elemento superior de la pila. Cada elemento de la pila se refiere a su
predecesor directo. El contenido real de un elemento de la pila se guarda mediante la variable
privada contenido.
Figura 8.13
Diagrama de clases para una pila elemento anterior 0,1
Apilar
StackEl
- / tamaño: int 0,1
0,1 0,1
parte superior - contenido: Objeto
+ getSize (): int
+ empujar (Objeto): vacío + setPrecedingEl (StackEl): void
+ pop (): Objeto + getContent (): Objeto
+ vacío (): booleano + getPrecedingEl (): StackEl
- setTop (StackEl): void
Los estados que puede tomar una pila se muestran en Figura 8.14 . Inicialmente
la pila está en el estado vacío. Si un elemento se coloca en la pila, la pila cambia al
estado no vacío. Cada vez empujar se llama, el tamaño de la pila aumenta en uno. Cada
vez popular se llama, el tamaño se reduce en uno. Si solo hay un elemento en la pila y popular
se llama, entonces la pila cambia al estado vacío.
Figura 8.14 pop [tamaño> 1]

Diagrama de máquina de estados para
/Talla--
una pila
empujar / tamaño = 1
vacío
no vacío
entrada / tamaño = 0
pop [tamaño == 1]
empujar
/ tamaño ++
8.3 Ejemplo 3: Pila de tipos de datos 181
Figura 8.15
:Apilar Diagrama de secuencia para la
Usuario adición de un elemento a la pila
empujar (objeto)
nuevo (objeto)
st: StackEl
setPrecedingEl (arriba)
setTop (st)
La realización de empujar y popular se muestra en los diagramas de secuencia

8.15 y 8.16 . Estos diagramas están muy cerca de las implementaciones y reflejan cómo se
establecen las variables.
Figura 8.16
:Apilar arriba: StackEl Diagrama de secuencia para la
Usuario eliminación de un elemento de la

pila
popular()
descanso [vacío () == verdadero]
pop (): nulo
obtener el contenido()
objeto = getContent (): objeto
getPrecedingEl ()
prev = getPrecedingEl (): anterior
setTop (anterior)
pop (): objeto

Para colocar un objeto objeto en la pila, una nueva instancia de StackEl debe crearse donde el contenido
del atributo se establece en objeto. La corriente parte superior
elemento de la pila se convierte en el predecesor de la nueva pila, que ahora se convierte en el parte
superior elemento en la pila.
los popular operación invierte el efecto de un empujar operación. El contenido de la corriente parte
superior se devuelve el elemento y su predecesor se convierte en el nuevo elemento superior. Si no
hay ningún elemento en la pila, el valor

nulo es regresado.
8.4 Resumen
En los tres ejemplos discutidos en este capítulo, no solo hemos repetido los conceptos más
importantes de UML, sino que también hemos mostrado cómo interactúan los diferentes diagramas.
Esta interacción nos permite describir un sistema completamente sin que al desarrollador se le
suministre toda la información a la vez y se sienta abrumado por esta avalancha de información.
Nos permite enfocarnos en preguntas específicas. La información que se muestra en los diferentes
diagramas contribuye de manera redundante a hacer que el modelo sea más consistente en
general, ya que permite encontrar errores en una etapa anterior de desarrollo y con mayor facilidad.
Capítulo 9
Temas adicionales
En los capítulos anteriores, hemos aprendido los conceptos básicos del modelado orientado a
objetos utilizando numerosos elementos del lenguaje UML. Hemos aprendido a aplicar estos
conceptos para crear diagramas UML. Los diagramas ofrecen diferentes vistas de un sistema
complejo, proporcionando mecanismos de abstracción para hacer manejable la complejidad del
sistema. Con estos mecanismos, UML ofrece una base sólida para muchas aplicaciones y
podríamos llenar muchas páginas examinando más temas. Para dar un ejemplo, el Lenguaje de
Modelado de Sistemas (SysML) [37] fue desarrollado basado en UML y extiende un
subconjunto de UML con conceptos especiales requeridos para modelar sistemas físicos
complejos.
Sin embargo, la introducción de todos los temas adicionales que tengan en cuenta UML iría
más allá de los objetivos de este libro. Como perspectiva, consideraremos brevemente cuatro
áreas más aquí: (i) estructurar modelos, (ii) definir el lenguaje de UML, (iii) mecanismos de
extensión en UML, y (iv) desarrollo de software basado en modelos. Sin entrar en detalles,
transmiten una muestra de lo que es posible con el modelado.
9.1 Estructuración de modelos
Si un diagrama excede un cierto tamaño, existe el peligro de que se vuelva demasiado

complicado. La multitud de elementos del modelo, independientemente de si son clases,
acciones, estados, etc., abruma muy rápidamente al lector humano de un diagrama. Si el
sistema general consta de múltiples subsistemas cuyos elementos están relacionados
mínimamente entre sí, entonces es deseable tener un mecanismo que agrupe los elementos de
manera apropiada. Por ejemplo, en la mayoría de los casos, es confuso si los elementos de la
interfaz de usuario se mezclan con los elementos de la base de datos.

Computación, DOI 10.1007 / 978-3-319-12742-2_9
184 9 Temas adicionales
acceso. En la literatura se han identificado diferentes criterios para agrupar elementos [23]:
• Cohesión funcional: se agrupan los elementos con finalidad similar.

• Cohesión informativa: se agrupan los elementos que están fuertemente relacionados entre sí pero
sólo débilmente relacionados con otros elementos.
• Estructura de distribución: Al desarrollar un sistema distribuido, los elementos se
agrupan de acuerdo con su distribución física, por ejemplo, elementos en el cliente y
elementos en el servidor.
• Estructuración del desarrollo: la estructuración refleja la división de las tareas de desarrollo. Esto es
particularmente importante si hay un equipo de desarrolladores involucrado en el desarrollo del
sistema. Las responsabilidades e interfaces claramente definidas evitan situaciones en las que los
miembros del equipo se interponen en el camino de los demás.
En los lenguajes de programación, se introdujo el concepto de "espacio de nombres" para

permitir la estructuración. En Java, por ejemplo, esto se realiza en forma de paquetes. UML ofrece la diagrama
Diagrama del paquete del paquete para este propósito.
9.1.1 Paquetes
Paquete UNA paquete le permite agrupar elementos del modelo, como clases, tipos de datos, actividades y
estados, etc., pero también puede contener paquetes. La notación de un paquete es un rectángulo
con un rectángulo más pequeño en la esquina superior izquierda, similar a una tarjeta de índice. El
rectángulo grande contiene los elementos que agrupa el paquete (ver Figura 9.1 (a) ). El pequeño
rectángulo contiene el nombre del paquete. Si el contenido del paquete no es relevante, el nombre
del paquete también se puede colocar en el rectángulo grande (ver
Figura 9.1 (b) ). Alternativamente, el contenido del paquete puede representarse fuera del rectángulo
grande y conectarse al paquete mediante líneas que terminan en un círculo que contiene una cruz en
el costado del paquete (ver Figura 9.1 (c) ). Un elemento de modelo puede incluirse en un máximo de
un paquete directamente. Esta inclusión en un paquete de fi ne el espacio de nombres en el que un
Espacio de nombres elemento es visible. El nombre de un elemento debe ser único dentro de un espacio de nombres. Sin
embargo, diferentes elementos pueden tener el mismo nombre dentro de diferentes espacios de
nombres. Por lo tanto, si el paquete P1 contiene una clase C, no se puede confundir con clase C en
paquete P2. La membresía del paquete es, por tanto, un factor de calificación, que permite una clara
diferenciación entre diferentes elementos con el mismo nombre. El nombre único de un elemento se
especifica anteponiendo el nombre del paquete seguido de dos dos puntos. Esto nos da, por ejemplo,
los dos nombres únicos P1 :: C y P2 :: C.
9.1 Estructuración de modelos 185
Figura 9.1
Nombre del paquete Alternativas de notación para
diagramas de paquetes
C1
Nombre del paquete
C2
(una) (si)
Nombre del paquete
C1
C2
(C)
9.1.2 Importación de elementos / paquetes
Los elementos de un paquete específico pueden hacer referencia entre sí y comunicarse entre sí
sin más detalles siempre que esto no esté restringido por la visibilidad y las direcciones de
navegación. Por ejemplo, un elemento mi que se encuentra en un paquete P1 también se puede
utilizar en un paquete P2
previsto P2 no contiene un elemento con el mismo nombre mi y P2 se incluye directa o
indirectamente en P1. Los elementos de otros paquetes se pueden importar o hacer referencia a
ellos mediante nombres cali fi cados. Todos los elementos del paquete importado con la visibilidad
correspondiente se vuelven visibles en el paquete de importación. Por tanto, estos elementos
pueden ser referenciados directamente. El nombre de un elemento importado se agrega al espacio
de nombres del paquete y luego se puede usar sin cali fi cación (es decir, sin
espacio de nombres: :).
Piense en el diagrama de clases (capítulo 4): allí definimos las visibilidades de los
atributos, las operaciones y los roles. Al hacerlo, también nos familiarizamos con la visibilidad paquete,
anotado por ˜ ( ver Lengüeta. 4.1 en la página 59). Esta visibilidad significa que los atributos,
operaciones y roles solo son visibles para elementos dentro del mismo paquete.
Las relaciones de importación se indican mediante una flecha de guiones que apunta en dirección opuesta
al importador y está etiquetada con "importar". Por supuesto, solo se pueden importar elementos que son
visibles externamente, como class C1 en paquete
P3, que se importa por paquete P1 ( Figura 9.2 ).

Importar paquetes Un paquete puede importar paquetes completos de esta manera. Por ejemplo, en
Figura 9.2 , paquete P1 paquete de importaciones P2. Esto hace que todos los elementos visibles del
paquete importado sean visibles en el espacio de nombres del paquete importado. Esto se maneja y
anota como cualquier otra relación de importación.
Para un examen más detallado de este tema, consulte [23].
Figura 9.2
Importar relación
P2
C1
P1
"
ortar
"imp C2
P3
"im
por
tar"
C3
9.2 El metamodelo UML
Los lectores críticos se preguntarán cómo sabemos aplicar los conceptos de los diferentes
Metamodelo diagramas. Esto se describe en el metamodelo. Un metamodelo es un modelo que describe un
lenguaje de modelado. Por lo tanto, dice algo acerca de otros modelos, hecho que se expresa
con el prefijo griego “meta”, que significa “sobre”. De la misma manera que los elementos de un
modelo se denominan elementos de modelo, los elementos de un metamodelo se denominan
elementos de metamodelo.
Superestructura El metamodelo UML, el superestructura [ 35], especifica UML en forma de diagramas de clases.
Usamos diagramas de clases para describir qué elementos puede contener un diagrama UML y cómo
se aplican estos elementos. Sin embargo, esto también significa que un diagrama de clases, que es
parte de UML, se especifica en sí mismo mediante un diagrama de clases. Esto es comparable con
los lenguajes de programación. Aquí es posible y común escribir un compilador para C en C, por
ejemplo. Con los conceptos que conocemos del diagrama de clases, ahora podemos especificar
lenguajes de modelado nosotros mismos. Las clases ya no representan personas, cursos, etc., sino
más bien conceptos de lenguaje.
9.3 Mecanismos de extensión UML 187
conceptos, como clases, asociaciones y generalizaciones, etc. Figura 9.3

muestra un ejemplo de un lenguaje de modelado simple que es muy similar al diagrama de clases
UML y está representado en forma de diagrama de clases. Este metamodelo es similar al
metamodelo del diagrama de clases UML real, pero está muy simplificado. Casi todas las clases
heredan de la clase NamedElement. Todas las instancias directas e indirectas de esta clase tienen
un nombre que las identifica de forma única. Las asociaciones se describen en una clase
separada. Por el contrario, una generalización se representa solo como una relación entre clases.
Por supuesto, también podríamos modelar la generalización como una clase separada. Esto nos
permitiría especificar más propiedades para la generalización, como en UML “real”. Por ejemplo,
en UML, una generalización se puede describir como desarticular o superpuesto ver 4.6.2), que es
algo que no podemos hacer en nuestro metamodelo simplificado.
La sintaxis de UML introducida aquí también se conoce como sintaxis abstracta. Si Sintaxis abstracta
tuviéramos que dibujar una instancia del metamodelo de Figura 9.3 —Es decir, un modelo de
objeto— una asociación se representaría como un elemento separado que conecta otros
elementos. Luego, una clase abstracta se identifica por isAbstract bandera. Esta notación no
es particularmente fácil de usar. Hemos expresado asociaciones simplemente con una
conexión directa entre las clases que están en una relación entre sí y hemos identificado
específicamente clases abstractas. Este tipo de notación es más intuitivo para los usuarios
humanos. Por tanto, además de la sintaxis abstracta, UML de fi ne la sintaxis concreta, que es
una notación optimizada para humanos.
Sintaxis concreta
Por supuesto, hay muchos otros detalles importantes sobre metamodelos y

metamodelos que podríamos discutir. Por ejemplo, la pregunta obvia es cómo se define el
lenguaje utilizado para crear el metamodelo. Para este propósito, UML tiene la infraestructura
[ 34] que introduce los conceptos requeridos. Este es el metametamodelo de UML. Infraestructura
Podríamos continuar con estas de fi niciones hasta el infinito, pero la especificación no va
más allá del metametalevel.
9.3 Mecanismos de extensión UML
Como lenguaje de modelado de propósito general, UML proporciona una base estable para una
amplia variedad de requisitos. No está de fi nido para dominios de aplicación específicos ni para
ninguna tecnología específica. Sin embargo, en algunas circunstancias, UML es demasiado
general y su uso implica un esfuerzo considerable. En tales casos, resulta ventajoso el uso de un
lenguaje optimizado para el dominio dado y, por tanto, que ofrece conceptos especiales.
Figura 9.3
"enumeración" "enumeración"
Metadatos muy simplificados
Visibilidad PType
modelo de un diagrama de clases {resumen}
público cuerda
NamedElement
privado entero
nombre: String protegido booleano
flotador
1 tipo
1 tipo
{resumen}
1 returnType
Tipo
Paquete PrimitiveType
tipo: PType
*
fuente 1 0..1 superclase
Clase
objetivo 1
isAbstract: subclases booleanas *
asociado
ciones *
atributos * * métodos
Asociación Método
Atributo
superior: Int visibilidad: Visibilidad

visibilidad: Visibilidad
inferior: Int isAbstract: booleano
* Parámetro
Este tipo de lenguaje se puede definir de una de las siguientes tres formas:
• Creación de un nuevo metamodelo

• Ampliación y modi fi cación del metamodelo UML
• Extensión del metamodelo UML con mecanismos inherentes al lenguaje
Creación de un nuevo Si la descripción de los sistemas a modelar requiere conceptos de lenguaje que son
metamodelo muy diferentes a los conceptos de lenguaje de UML, probablemente sea más práctico no
usar la definición de lenguaje de UML y definir su propio lenguaje de modelado creando un nuevo
metamodelo.
Como alternativa a la creación de un nuevo metamodelo, también puede extender y Extensión y

modificar el metamodelo UML de acuerdo con sus requisitos. En este caso, introduce nuevas modi fi cación del metamodelo
metaclases y nuevas asociaciones entre las metaclases o sobrescribe propiedades existentes. UML
Este tipo de extensión también se conoce como extensión de peso pesado. En muchos casos,
dificulta la interoperabilidad de las herramientas de modelado, ya que, por supuesto, no todas las
herramientas admiten el metamodelo extendido.
El propio UML ofrece mecanismos de extensión inherentes al lenguaje, es decir, opciones Extensión del metamodelo
de extensión que se proporcionan en el propio idioma. Estos ya están definidos a nivel de UML con
metametamodelo, es decir, en la infraestructura UML. Por tanto, las extensiones se inherente al lenguaje
implementan de forma controlada; Los conceptos lingüísticos existentes sólo pueden mecanismos
extenderse y hacerse más específicos y no deben cambiarse ni generalizarse. Este
mecanismo de extensión ligero conserva la interoperabilidad entre las diferentes herramientas
de modelado. Estas extensiones ligeras se basan en estereotipos y perfiles, que veremos más
de cerca a continuación.
9.3.1 Estereotipos y perfiles
En la Sección 9.2, vimos que el metamodelo UML en sí mismo también es un modelo. Describe
los elementos del lenguaje de UML. El metamodelo de fi ne, por ejemplo, que un diagrama de
clases contiene clases, asociaciones y generalizaciones, etc. Las clases del metamodelo se
denominan metaclases. UNA estereotipo es una metaclase especial en el metamodelo UML. Le
permite extender cualquier metaclase con meta-atributos adicionales (definiciones de etiquetas) Estereotipo
y hacerlo más específico usando restricciones adicionales. Una metaclase para la que se ha
definido un estereotipo permanece inalterada. En el caso más simple, los estereotipos se
utilizan para clasificar metaclases sin introducir meta-atributos y restricciones adicionales.
Un estereotipo se denota como una clase, con la palabra clave "estereotipo"

encima del nombre en el primer compartimento. El segundo compartimento normalmente contiene
los meta-atributos. Las restricciones se pueden especificar después de los meta-atributos o como
una nota. También puede especificar un pictograma para un estereotipo. Este símbolo se utiliza más
tarde con los elementos correspondientes. Figura 9.4 muestra un ejemplo de estereotipo. El
estereotipo
Entidad contiene dos meta-atributos, autor y año, así como dos limitaciones. Una
restricción establece que los valores del metaatributo autor
puede tener un máximo de diez caracteres, con la otra restricción indicando que el valor
del meta-atributo año debe ser menor que 2006.
Un estereotipo extiende una o más metaclases. Esta relación de extensión se Relación de extensión
representa como una flecha con una línea continua y una punta de flecha llena. La flecha
apunta desde el estereotipo a la metaclase. los
Figura 9.4
«Metaclase» «Metaclase»
Especificación del estereotipo
Componente Clase
"Entidad"
{necesario}
"estereotipo"
Entidad
author: String [0..1] {author: length≤10} year:

Integer {year <now}
la metaclase extendida se identifica con la palabra clave «Metaclase». Los estereotipos definidos
de esta forma son opcionales, lo que significa que no es necesario utilizarlos en el modelado.
También puede utilizar elementos de modelo que se basan en la definición original de la
metaclase. Para forzar el uso de un estereotipo, la relación de extensión debe identificarse como
obligatoria mediante el uso de la palabra clave { necesario}. En Figura 9.4 , el estereotipo
Entidad es por tanto opcional para la metaclase Clase pero obligatorio para la metaclase Componente.
Los estereotipos se pueden conectar entre sí mediante una relación de herencia. En este
contexto, se pueden definir como abstractos. Un estereotipo derivado hereda todos los
metaatributos, restricciones y relaciones de extensión de sus estereotipos de nivel superior. Figura
9.5 muestra un ejemplo de herencia por estereotipos. Los estereotipos Entidad y Sesión se
derivan del estereotipo abstracto Frijol. La palabra clave { resumen} en el campo de nombre
identifica Frijol como abstracto. El estereotipo Sesión introduce un nuevo meta-atributo estado. La
relación de extensión entre
Componente y Frijol es obligatorio, lo que significa que cuando se modela un componente, el
estereotipo Frijol siempre debe usarse con un valor específico.

Per fi l Perfiles estereotipos de grupo de fi nidos con un propósito específico. Un per fi l es una
forma especial del paquete que aprendimos al comienzo de este capítulo. Por lo tanto, un perfil
tiene la misma notación que un paquete,
Figura 9.5
{resumen}
Ejemplo de herencia «Metaclase» {necesario}
"estereotipo"
con estereotipos [35] Componente
Frijol
"estereotipo" "estereotipo"
Entidad Sesión
estado: StateKind
Figura 9.6
"perfil"
Ejemplo de perfil [35]
EJB
{resumen}
«Metaclase» {necesario}
"estereotipo"
Componente
Frijol
{Un componente puede

no ser generalizado "estereotipo" "estereotipo"
o especializado} Entidad Sesión
estado: StateKind
"estereotipo"
Remoto "enumeración"
«Metaclase» StateKind
Interfaz apátrida
con estado
"estereotipo"
Hogar
«Metaclase» "estereotipo"
Artefacto TARRO
con la palabra clave «Per fi l» antepuesto al nombre del per fi l. Figura 9.6
muestra un ejemplo de un perfil [35] para Enterprise JavaBeans (EJB).
9.3.2 Aplicación de estereotipos de un perfil
Para usar estereotipos en una aplicación específica, primero debe integrar el perfil que contiene
los estereotipos. Haga esto con una flecha punteada con una punta de flecha abierta apuntando
en dirección opuesta al paquete de la aplicación hacia el perfil. Esta flecha está etiquetada con la
palabra clave "aplicar".
Esto importa los estereotipos definidos en el perfil en el espacio de nombres del paquete. Figura
9.7 muestra un ejemplo de la aplicación de un estereo-tipo. El paquete con el nombre UserModel
contiene un componente Cliente con el estereotipo Sesión. El valor del metaatributo estado
se especifica en una nota. El símbolo que aparece en la esquina superior derecha de Cliente designa
componentes en notación UML.
Figura 9.7
"perfil"
Ejemplo de aplicación de un EJB
estereotipo
{resumen}
«Metaclase» {necesario}
"estereotipo"
Componente
Frijol
"enumeración"
"estereotipo" "estereotipo"
StateKind
Entidad Sesión
apátrida
estado: StateKind
con estado
"aplicar"
UserModel
"sesión"
estado = sin estado
Cliente
9.4 Desarrollo de software basado en modelos
Los modelos suelen servir como planos de construcción de software. Para los desarrolladores,
estipulan qué propiedades debe tener el producto final. Especifican los requisitos que debe cumplir
un sistema de software y describen qué componentes se encuentran en el sistema y cómo
interactúan estos componentes. Por lo tanto, los modelos son la base para el desarrollo de código
ejecutable, que tradicionalmente es creado por programadores humanos. Si el modelo y el código
deben mantenerse actualizados, cualquier cambio realizado debe implementarse tanto en el modelo
como en el código. Esto implica un esfuerzo adicional.
El siguiente paso para simplificar el proceso de desarrollo de software es obvio, es decir, la

generación automática del código a partir de los modelos. Esto nos lleva al desarrollo de software
basado en modelos. Los modelos son significativamente más que imágenes bonitas para
documentar un sistema de software y para usar como bocetos o planos. En el desarrollo de software
basado en modelos, el sistema ejecutable se crea a partir de los modelos. Aquí, por tanto, los
modelos tienen el mismo valor que el código.
Software basado en modelos En desarrollo de software basado en modelos (MBSD), El código fuente se crea parcial o
desarrollo completamente a partir de modelos. Por tanto, la programación se sustituye por el modelado. Los
modelos deben describir la función del sistema a desarrollar con la mayor precisión posible. La
semántica del modelado
9.4 Desarrollo de software basado en modelos 193
Los lenguajes utilizados deben definirse de forma inequívoca para que los elementos del lenguaje se
puedan transformar en código de forma única. Los lenguajes de modelado de propósito general como Propósito general
UML pueden ser muy flexibles, pero a menudo son demasiado generales para aplicaciones lenguaje de modelado
específicas, lo que significa que faltan conceptos específicos. Por ejemplo, en la descripción de una
aplicación web, el “hipervínculo” es un concepto central que no está disponible en UML. Por lo tanto,
en el desarrollo de software basado en modelos, a menudo se utilizan lenguajes más pequeños
adaptados al dominio respectivo. Estos idiomas también se conocen como lenguajes específicos de
dominio (DSL). Por supuesto, se pueden de fi nir en base a UML, como vimos en la sección anterior
sobre estereotipos y per fi les. Dominio específico
idioma (DSL)
En MBSD, los modelos se transforman en otros modelos que, por ejemplo, contienen detalles
específicos sobre la plataforma de destino del sistema. Alternativamente, el código ejecutable se
genera en lenguajes de programación comunes. Por lo tanto, el conocimiento experto que se
requiere para crear un programa ejecutable se invierte en estas transformaciones de modelos. Por
lo tanto, se retiene en una infraestructura que se puede reutilizar nuevamente. En los últimos
años, se han introducido numerosos lenguajes y marcos especiales para crear estas
transformaciones.
El objetivo de MBSD es simplificar signi fi cativamente el desarrollo de aplicaciones sustituyendo

la programación por el modelado, sin que los desarrolladores o modeladores tengan que tener
conocimientos específicos sobre las plataformas utilizadas.
En resumen, el desarrollo de software basado en modelos tiene como objetivo proporcionar las
siguientes ventajas [49]:
• Incrementar la velocidad de desarrollo: El código, que a menudo se repite, se crea

automáticamente y se adapta a la situación actual. Hay una disminución significativa en las
actividades de "copiar y pegar".
• Incrementar la calidad del software: las transformaciones automáticas reducen el riesgo de
errores en la implementación. El código también se crea independientemente de las
habilidades y experiencia de un desarrollador. Gracias al soporte de herramientas, la
implementación de la arquitectura del software es mejor.
• Solución de problemas central: los errores solo deben corregirse en el modelo y luego se
eliminan en las partes de código correspondientes cuando se vuelve a ejecutar la
transformación. Es posible que las reglas de transformación deban adaptarse si ya no
cumplen los requisitos. Sin embargo, esto solo debe hacerse una vez.
• Incrementar la reutilización: Los lenguajes de modelado, en particular los DSL, solo deben
crearse una vez. Agregan conocimiento experto que luego se puede utilizar en diferentes
proyectos.
• Manejo de la complejidad a través de la abstracción: la complejidad del lenguaje de

implementación permanece oculta en los lenguajes de modelado; no es necesario considerar
los detalles técnicos de implementación.
• Portabilidad: el código se puede generar para diferentes plataformas a partir de un modelo.
Los modelos se utilizan no solo para generar la implementación del sistema a desarrollar;
también se utilizan para simulaciones, para analizar las propiedades del sistema, para generar
casos de prueba y para verificar y validar el sistema a desarrollar. El desarrollo de software basado
en modelos se puede implementar de diferentes formas. Para obtener una introducción detallada a
este tema, consulte [6, 49].
Referencias
1. J. Bézivin y PA Muller. UML: El nacimiento y auge de una notación de modelado estándar. En El

lenguaje de modelado unificado. UML'98: más allá de la notación,
volumen 1618 de Notas de conferencias en Ciencias de la Computación, páginas 1–8. Springer, 1999.
2. GM Birtwhistle, OJ Dahl, B. Myhrhaug y K. Nygaard. Simula Begin.

Chartwell-Bratt Ltd., 1979.
3. K. Bittner e I. Spence. Modelado de casos de uso. Addison-Wesley, 2002.
4. J. Bloch. Eficaz Java: una guía de lenguaje de programación. Addison-Wesley
Professional, 2. edición, 2014.
5. G. Booch. Desarrollo orientado a objetos. Transacciones IEEE en software En-
gineering 12 (2): 211-221, 1986.
6. M. Brambilla, J. Cabot y M. Wimmer. Ingeniería de software basada en modelos
en la práctica. Morgan y Claypool, 2012.
7. M. Brandsteidl, T. Mayerhofer, M. Seidl y C. Huemer. Reemplazo de las conferencias tradicionales en el aula
con videos de conferencias: un informe de experiencia. En Simposio de Educadores @MODELS 2012, páginas
21–27. ACM, 2012.
8. M. Brandsteidl, M. Seidl y G. Kappel. Enseñar modelos en GRANDE: Evaluación eficiente de
conceptos de modelado. En Simposio de educadores @ MODELS
2009, 2009.
9. M. Brandsteidl, M. Seidl, M. Wimmer, C. Huemer y G. Kappel. Modelos de enseñanza en GRANDE: cómo
dar a 1000 estudiantes una comprensión del UML. En Promoción del modelado de software a través de
la educación activa, Simposio para educadores @ MODELS 2008, páginas 64–68. Universidad
Tecnológica de Varsovia,
2008.
10. M. Brandsteidl, K. Wieland y C. Huemer. Nuevos medios en la enseñanza de UML en general: un informe de
experiencia. ECEASST, 34 de 2010.
11. M. Brandsteidl, K. Wieland y C. Huemer. Nuevos canales de comunicación en la educación en modelado de
software. En Talleres de MODELOS, volumen 6627 de Notas de la clase en Ciencias de la Computación, páginas
40–54. Springer, 2010.
12. LF Capretz. Breve historia del enfoque orientado a objetos. ACM SIGSOFT
Notas de ingeniería de software, 28 (2): 1–10, 2003.
13. L. Cardelli y P. Wegner. Sobre la comprensión de los tipos, la abstracción de datos y el polimorfismo. Encuestas
de computación ACM, 17 (4): 471-522, 1985.
14. PPS Chen. El modelo entidad-relación: hacia una vista unificada de datos.
Transacciones ACM en sistemas de bases de datos, 1 (1): 9–36, 1976.
15. A. Cockburn. Objetivos y casos de uso. Revista de programación orientada a objetos,
10 (5): 35–40, 1997.

Computación, DOI 10.1007 / 978-3-319-12742-2
196 Referencias
16. A. Cockburn. Redacción de casos de uso eficaz. Addison-Wesley Longman, 2001.

17. S. Finger y JR Dixon. Una revisión de la investigación en diseño de ingeniería mecánica. Parte I: Modelos
descriptivos, prescriptivos y basados en computadora de procesos de diseño. Investigación en diseño de
ingeniería, 1 (1): 51–67, 1989.
18. M. Fowler. Patrones de arquitectura de aplicaciones empresariales. Addison-Wesley
Longman, 2003.
19. M. Fowler. UML destilado: una breve guía para el modelado de objetos estándar
Idioma. Addison-Wesley, edición revisada, 2003.
20. E. Gamma, R. Helm, R. Johnson y J. Vlissides. Patrones de diseño. Elementos
de software orientado a objetos reutilizable. Prentice Hall, 1. edición, 1994.
21. C. Ghezzi y M. Jazayeri. Conceptos de lenguaje de programación. Wiley, 3. edi-
ción, 1997.
22. D. Harel. Statecharts: un formalismo visual para sistemas complejos. Ciencia de
Programación de computadoras, 8 (3): 231-274, 1987.
23. M. Hitz, G. Kappel, E. Kapsammer y W. Retschitzegger. UML @ Trabajo. Transmisión exterior-
jektorientierte Modellierung mit UML 2 (en alemán). dpunkt.verlag, 3. edición,
2005.
24. JR Holmevik. Compilación de SIMULA: un estudio histórico de génesis tecnológica. IEEE Annals of
the History of Computing, 16 (4): 25–37, 1994.
25. JD Ichbiah, JGP Barnes, RJ Firth y M. Woodger. Justificación de la
signo del lenguaje de programación Ada. Prensa de la Universidad de Cambridge, 1986.
26. D. Jackson. Abstracciones de software. La prensa del MIT, 2011.
27. I. Jacobson, M. Christerson, P. Jonsson y G. Overgaard. Orientado a objetos
Ingeniería de software, un enfoque basado en casos de uso. Addison-Wesley Longman, 1992.
28. AC Kay. La historia temprana de Smalltalk. Avisos ACM SIGPLAN, 28 (3): 69–
95, 1993.
29. J. Kramer. ¿Es la abstracción la clave de la informática? Comunicaciones de la ACM,
50 (4): 36–42, 2007.
30. L. Maciaszek. Análisis de Requisitos y Diseño de Sistemas. Educación Pearson,
3. edición, 2007.
31. B. Meyer. Toque de clase, aprender a programar bien con objetos y con-
tratados. Springer, 2. edición, 2013.
32. H. Mössenböck. C # al grano. Pearson Addison Wesley, 2004.
33. Grupo de gestión de objetos. Página de inicio de OMG. http://www.omg.org .
34. Grupo de gestión de objetos. Lenguaje Unificado de Modelado OMG (UML), Infraestructura. Informe
técnico versión 2.4.1, OMG, agosto de 2011.
35. Grupo de gestión de objetos. Lenguaje de modelado unificado OMG (UML), superestructura. Informe
técnico versión 2.4.1, OMG, agosto de 2011.
36. Grupo de gestión de objetos. Lenguaje de restricción de objetos. Informe técnico versión 2.3.1, OMG,
mayo de 2012.
37. Grupo de gestión de objetos. Lenguaje de modelado de sistemas OMG (SysML). Informe técnico,
OMG, 2012.
38. Grupo de gestión de objetos. Intercambio de metadatos XML (XMI). Informe técnico versión 2.4.2,
OMG, abril de 2014.
39. G. Övergaard y K. Palmkvist. Casos de uso: patrones y planos. Addison-
Wesley Longman, 2005.
40. K. Pohl. Ingeniería de requisitos: fundamentos, principios y tecnología
niques. Springer, 2010.
41. W. Reisig. Comprensión de las redes de Petri. Springer, 2013.
42. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy y W. Lorensen. Objeto-
Modelado y Diseño Orientado. Prentice Hall, 1991.
Referencias 197
43. J. Rumbaugh, I. Jacobson y G. Booch. El lenguaje de modelado unificado

Manual de referencia. Pearson Education, 2. edición, 2004.
44. N. Russell, WMP van der Aalst, AHM ter Hofstede y P. Wohed. Sobre la idoneidad de los diagramas de
actividad UML 2.0 para el modelado de procesos de negocio. En 3ra Conferencia Asia-Pacífico sobre
Modelado Conceptual, páginas 95-104. Sociedad Australiana de Informática, Inc., 2006.
45. G. Schneider y J. Winters. Aplicación de casos de uso: un enfoque práctico.

Addison-Wesley, 2001.
46. M. Scholz, P. Kaufmann y M. Seidl. Making UML "hip": Un primer informe de experiencia sobre el uso de
herramientas de enseñanza modernas para el modelado orientado a objetos. En
EduSymp @ MODELOS 2013, volumen 1134 de Actas del Taller CEUR.
CEUR-WS.org, 2013.
47. B. Selic. La pragmática del desarrollo basado en modelos. Software IEEE,
20 (5): 19-25, 2003.
48. H. Stachowiak. Allgemeine Modelltheorie (en alemán). Springer, 1973.
49. T. Stahl y M. Völter. Desarrollo de software basado en modelos: tecnología,
gineering, Management. Wiley, 2006.
50. B. Stroustrup. El lenguaje de programación C ++. Addison Wesley, 4. edición,
2013.
51. IE Sutherland. Sketchpad: un sistema de comunicación gráfica hombre-máquina. Simulación, 2 (5): R –
3 – R – 20, 1964.
52. Wikipedia. Sistema. http://en.wikipedia.org/wiki/System ,
2014.
Índice
tiempo absoluto hacer, 86, 87
diagrama de secuencia, 130 entrada, 86, 88, 92, 101

diagrama de la máquina de estado, 94 salida, 86, 87, 88, 92 estado
resumen histórico, 101
actor abstracto, 29, 39 clase abstracta, 70, interno, 86

72, 78, 81 notación, 73 transición interna, 92
pseudoestado, 89
tipo de datos abstracto, 12 sintaxis, 88
operación abstracta, 73 transición, 87, 102
sintaxis abstracta, 187 diagrama de actividad, 20, 138, 141-166,
caso de uso abstracto, 32, 44 169, 175
abstracción, 3 nodo final de actividad, 151, 153 actor
aceptar la acción del evento, 144–145, 160, 162 aceptan
acción de evento temporal, 144 diagrama de actividad, 157, 158, 162 diagrama de
acción, 86, 143-146, 150, 152, 153 aceptar secuencia, 109, 175 diagrama de casos de uso, 23, 25-27,
evento, 144–145 33, 36,
aceptar la acción del evento, 144, 160, 162 llamada, 37, 39, 171, 173
145-146 resumen, 29, 39
comportamiento de llamada, 145–146 identi fi cación, 34–35, 42
acción de comportamiento de llamada, herencia, 28-29, 34
145 acciones de operación de llamada, Ada, 12 años
146 basadas en eventos, 144–145 después, ver agregación de tiempo

manejo de excepciones, 159, 160 permiso relativo, 67–69, 78–79
de ejecución, 146, 147 parámetro de composición, 68–69

entrada, 155 compartido, 68
parámetro de salida, 155 alt operador, 116

partición, 156 interacción alternativa, ver alt transición alternativa
enviar acción de señal, 145 de operador, 90
tiempo aceptar acción de evento, 144 objeto anónimo, 51
objeto activo, 110 cualquier evento de recepción, 95
actividad afirmar operador, 126

diagrama de actividad, 142, 143, 144 interacción afirmada, ver afirmar asociación de operadores
comportamiento de llamadas, 145-146
diagrama de la máquina de estado diagrama de clases, 60–65
nodo de decisión, 90 bidireccional, 61

Computación, DOI 10.1007 / 978-3-319-12742-2
200 Índice
binario, 60, 64 diagrama de casos de uso, 19, 23–47, 168, 171
composición, 68–69
identi fi cación, 78 navegabilidad bidireccional, 61
multiplicidad, 62–63, 68, 81 n-ario, asociación binaria
64–65 diagrama de clase, 60, 64
navegabilidad, 61 diagrama de casos de uso, 27
no único, 56, 57, 67 descanso operador, 118, 119
ordenado, 56, 57
dirección de lectura, 60 C ++, 11
papel, 63, 78, 79 C #, 12
agregación compartida, 68 acción de comportamiento de llamada,
ternario, 64 evento de llamada 145, 94
único, 56, 57, 67 acción de operación de llamada, búfer
desordenado 56, 57 central 146, 155, 156 evento de cambio,
versus agregación, 69 94
xor restricción, 63 clase, 6, 52–60, 70, 75, 76, 173 resumen, 70, 72,
use el diagrama del caso, 27-28, 34 binario, 78, 81 diagrama de actividades, 142, 146, 157
27 clase de asociación, 65–67, 79, 173 identi fi
error, 39 cación, 77
identi fi cación, 44
multiplicidad, 27 herencia, 69
clase de asociación, 65–67, 79, 173 diagrama de objeto, 51
mensaje asincrónico, 112 diagrama de secuencia, 108, 110,
en, ver tiempo absoluto, diagrama de secuencia 133-134
interacción atómica, ver crítico atributo de operador, 3, 7 subclase 70, 72, 73
superclase, 70
diagrama de clases, 51–53, 54–55, 76 acceso, atributo de clase, ver diagrama de clase de variable de
61 clase, 17, 26, 49–84, 113, 133-134, 173-175, 178,
derivado, 55 180, 187 creación, 76–79
multiplicidad, 55–56, 61
propiedades, 55 jerarquía de clases, 8
sintaxis, 54 operación de clase, 59–60, 70 variable
tipo, 75–76 de clase, 59–60, 70 clasi fi cación, 72
visibilidad, 58–59
identi fi cación, 77 codigo de GENERACION, 80–82, ver también
diagrama de secuencia implementación
atributo local, 129–130 coerción, 8
valor de atributo, 51, 53, 55, 56 cohesión
funcional, 184
ingeniería inversa, 5 cohesión informativa, 184
caso de uso base, 30, 31 diagrama de fragmento combinado, 115-126, 128
comportamiento, 19-21 alt operador, 116
diagrama de actividad, 20, 138, 141-166, afirmar operador, 126
169, 175 descanso operador, 118, 119
diagrama de comunicación, 20, 137 considerar operador, 125

diagrama de interacción, 107, 136 diagrama crítico operador, 123–124
general de interacción, 21, ignorar operador, 125
138 lazo operador, 118, 175
diagrama de secuencia, 20, 107-135, Diagrama de neg operador, 126
máquina de 175 estados, 19, 85-106, optar operador, 117
132, 169, 177–179 par operador, 121–122
diagrama de tiempos, 20, 138 seq operador, 119
Índice 201
estricto operador, 120-121 estado de historia profunda, 101, 102 valor
diagrama de comunicación, 20, 137 predeterminado, 55
completar, 72 diagrama de despliegue, 18

evento de finalización, 88, 95 modelo descriptivo, 4
transición de finalización, 88 patrón de diseño, 135
estado complejo, ver diagrama de componentes de evento de destrucción, 113
estado compuesto, 18 diagrama, 15

estado compuesto, 96-102 diagrama de comportamiento, 19-21
composición, 68–69, ver fuerte diagrama de actividad, 20, 138, 141-166,

agregación 169, 175
diagrama de estructura de composición, 18 sintaxis diagrama de comunicación, 20, 137
concreta, 187 diagrama de interacción, 107, 136 diagrama
concurrencia, ver también paralelismo general de interacción, 21,
diagrama de actividad, 148, 150, 151, 152 diagrama 138
de secuencia, 115, 119-124 diagrama de secuencia, 20, 107-135,
diagrama de máquina de estados, 91 interacción 175
concurrente, ver par condición del operador, ver también Guardia diagrama de la máquina de estado, 19, 85-106,
132, 169, 177–179

diagrama de actividad diagrama de tiempos, 20, 138
poscondición, 142 diagrama de casos de uso, 19, 23–47, 168, 171
condición previa, 142

diagrama de secuencia, 119 marco, 15
use el diagrama del caso diagrama de estructura, 17-19
ampliar relación, 31 diagrama de clases, 17, 26, 49–84, 113, 133-134,

poscondición, 36, 46 173-175, 178, 180, 187 diagrama de
condición previa, 36, 39, 46, 173 componentes, 18
conector, 147 diagrama de estructura de composición, 18
considerar operador, 125 diagrama de despliegue, 18
constructor, 59, 113 diagrama de objeto, 17, 49–52, Diagrama de
marcador de continuación 60 paquetes, 18, 184 diagrama de per fi l, 19
diagrama de actividad, ver diagrama de
secuencia del conector, 126, 129 ejecución directa, 111

flujo de control desarticular, 72
diagrama de actividad, 144, 146-153, 162 diagrama de hacer actividad, 86, 87 duración, ver limitación de
secuencia, 110 tiempo, tiempo
borde de flujo de control, 144 token intervalo, duración de la transmisión

de control, 154, 161 corregión, 123
borde
crear mensaje, 113 diagrama de actividad, 142, 143, 147, 152
crítico operador, 123–124 conector, 147
hora actual, 131 borde de flujo de control, borde de rayo 144, borde
de flujo de objeto 160, diagrama de clases 144, 154, ver
flujo de datos, ver parámetro de flujo de datos de también diagrama de máquina de estado de
flujo de objeto, ver almacén de datos de flujo, 155 asociación, ver también
token de datos, 154, 155 tipo de datos, 7, transición

54, 75–76, 77 comportamiento de efecto, 87
decisión, 149 Eiffel, 11
entrada de decisión, ver comportamiento de decisión nodo más
de decisión diagrama de secuencia, 116
diagrama de actividad, 149, 150, 152, 162 diagrama de diagrama de la máquina de estado, 90, 95
máquina de estados, 90–91 encapsulación, 7

202 Índice
modelo entidad-relación, 12 subfusil, 98

entrada actividad, 86, 88, 92, 101 puntos de fl ujo nodo final, 151, 152 tenedor, ver ingeniería
entrada, 99–100 directa del nodo de paralelización, 5
enumeración, 54, 75
evento mensaje encontrado, 114
diagrama de actividades, 160 fragmento, ver cohesión funcional de fragmentos

acción basada en eventos, 144–145 combinados, 184
diagrama de secuencia, 107
evento de destrucción, 113 puerta, 128

recibir evento, 111 lenguaje de modelado de propósito general, 14,
enviar evento, 111 187, 193
evento inicial, 130 generalización, ver herencia
diagrama de la máquina de estado, 87, 102-104 cualquier relación de generalización, 73
evento de recepción, 95 conjunto de generalización, 72
evento de llamada, 94 completar, 72
cambio de evento, 94 desarticular, 72
evento de finalización, 88, 95 evento incompleto, 72
de señal, 94 superposición 72
evento temporal, 94 genérico, 8
tipos, 94–95 Guardia, ver también condición
use el diagrama del caso diagrama de actividad, 144, 146, 149

desencadenar, 24, 36 diagrama de secuencia, 116-118
especificación del evento, 110 diagrama de la máquina de estado, 87, 89, 90,
acción basada en eventos, 144–145 102, 179

controlador de excepciones, 159–160
manejo de excepciones estado histórico, 101-102

región de actividad interrumpible, diagrama de profundo, 101, 102
secuencia 160-161, 118, interacción de excepción poco profundo, 101
159-161, ver descanso
operador ignorar operador, 125
exclusivo o, ver xor ejecución de implementación, 12
restricciones diagrama de clases, 59, 61, 73
directo, 111 diagrama de secuencia, 126, 132, 181
indirecto, 111 importar relación, 185
ruta de ejecución, ver traza, secuencia importar paquetes, 185–186
diagrama en parámetro, 57
semántica de ejecución, 146, 152, 154, 157 especi fi incluir, 30, 32, 34, 37, 44 caso de
cación de ejecución, 111 uso incluido, 30
dependencia de la existencia, 68, 79 incompleto, 72
salida actividad, 86, 87, 88, 92 punto de ejecución indirecta, 111
salida, 99–100 ocultación de información, 58
ampliar, 30, 37 cohesión informativa, 184
condición, 31 infraestructura, ver metamodelo
caso de uso extendido, 31 punto herencia, 7-8
de extensión, 31 diagrama de clase, 70–71, 78 clase,
relación de extensión, 189 69
transición externa, 92, 96 herencia múltiple, 71
use el diagrama del caso
estado final, 92 actor, 28-29, 34

estado compuesto, 96, 104 estado caso de uso, 32, 34 nodo inicial, 147, 150,
histórico, 101 152, 169 estado inicial, 90
estado ortogonal, 97
Índice 203
estado compuesto, 96, 103 estado lazo operador, 118, 175

ortogonal, 97 perdido, ver mensaje perdido
subfusil, 98 mensaje perdido, 114
En fuera parámetro, 57
parámetro de entrada, ver instancia de parámetro, 6, 52, 59, MBSD, ver software basado en modelos
60, ver también atributo de instancia de objeto, ver nivel de desarrollo
instancia de variable de instancia, 59 fusionar nodo, 150, 152, 162
mensaje, 107, 110-114
operación de instancia, 60, 70 variable de instancia, 59, 70 asincrónico, 112
comportamiento entre objetos, 107, 108 interacción, 107, entre objetos, 7
110, 115 alternativa, ver alt operador afirmó, ver afirmar crear, 113
operador atómico, ver crítico operador concurrente, ver encontrado, 114
par excepción del operador, ver descanso operador perdido, 114
inválido, ver neg operador irrelevante, ver ignorar operador mensaje de respuesta, 112
iterativo, ver bucle operador opcional, ver optar relevante sincrónico, 112
para el operador, ver considerar operador repitió, ver sintaxis, 113
bucle operador secuencial con orden estricto, ver lleva mucho tiempo, 114
estricto intercambio de mensajes, 119
mensaje con duración, ver hora-

mensaje consumidor
metamodelo, 13, 14, 186–187
modelo, 2-5
abstracción, 4
descriptivo, 4
operador prescriptivo, 4
secuencial con orden débil, ver seq desarrollo de software basado en modelos, 5,
operador 192-194
diagrama de interacción, 107, 136 diagrama general lenguaje de modelado, 2
de interacción, 21, 138 específico de dominio, 2
compañero de interacción, 107, 108–110, 111 propósito general, 2
referencia de interacción, 127-128, 138 interfaz, 58, 72–74, clasi fi cación múltiple, 72
79, 179, 184 actividad interna, 86 herencia múltiple
diagrama de clases, 71
transición interna, 88, 92, 96 multiplicidad
región de actividad interrumpible, 160-161 diagrama de clase
comportamiento intraobjeto, 21 asociación, 62–63, 68, 81 atributo,
interacción inválida, ver neg interacción irrelevante 55–56, 61
del operador, ver ignorar funcionamiento, 57
operador diagrama de casos de uso, 27
es un relación, ver interacción iterativa de rol multivalor, 109
herencia, ver bucle operador
asociación n-aria, 64–65

Java, 12, 52, 60–62, 75, 80–82 espacio de nombres, 184
unirse, ver nodo de sincronización navegabilidad, 61
bidireccional, 61
ciclo de vida de un objeto, 19, 96, 102 línea de vida, 108–110, no navegabilidad, 61
111, 113, 123, 132, neg operador, 126
ver también vínculo de pareja de estado anidado, ver estado compuesto
interacción, 51, 60 nuevo, mira nodo de creación de
tipo de lista, ver atributo local de objetos
enumeración, 129–130 diagrama de actividad
lazo, ver bucle operador nodo final de actividad, 151, 153

204 Índice
búfer central, 155, 156 almacén de operación de clase, 59–60, Operación
datos, 155 de 70 instancias, 60, 70 multiplicidad,
nodo de decisión, 149, 150, 152, 162 fl ujo de 57
nodo final, 151, 152 nodo inicial, 147, 150, 152, sintaxis, 56
169 fusionar nodo, 150, 152, 162 nodo de visibilidad, 58–59
paralelización, 150, 152 nodo de sincronización, 150, diagrama de secuencia, 118
152 diagrama de máquina de estados llamar, 113
diagrama de la máquina de estado
llamar, 94
nodo de decisión, 90 operador, ver fragmento combinado

nodo de paralelización, 91, 97 nodo de optar operador, 117
sincronización, 91, 97 no navegabilidad, 61 interacción opcional, ver optar operador
ordenado, 56, 57
no único, 56, 57, 67 estado ortogonal, 97–98
ahora ve tiempo actual fuera parámetro, 57
superposición 72
objeto, 6–7 sobrecarga 7, 8

diagrama de clase, 52, 61, 63, 134 clasi fi
cación, 72 paquete, 184–186
diagrama de objetos, 50–52 importación, 185–186
objeto anónimo, 51 paquete, 58–59, 185

diagrama de secuencia, 108, 109, 113 objeto diagrama del paquete, 18, 184
activo, 110 par operador, 121–122

creación, 113 paralelismo, ver también concurrencia
diagrama de máquina de estado, 85, 86 diagrama de secuencia, 121
creación, 90 diagrama de la máquina de estado, 97
supresión, 92 nodo de paralelización
Lenguaje de restricción de objetos, 13, 16, 175 diagrama de actividad, 150, 152 diagrama de
máquina de estado, 91, 97 parámetro
creación de objetos, 90, 113 diagrama de

objetos, 17, 49–52, Flujo de 60 objetos, 144, 154-156, diagrama de actividad, 142, 143-145, 154,
162 borde de flujo de objetos, 144, 154 Grupo 155
de gestión de objetos, 13 Técnica de modelado diagrama de clase, 57, 75
de objetos, 12 nodos de objetos, 154, 155 en parámetro, 57

En fuera parámetro, 57
fuera parámetro, 57
orientación a objetos, 6–9, 11, 29, 52, 61, diagrama de secuencia, 113, 127,
71, 80, 113 129–130
Ingeniería de software orientada a objetos, diagrama de la máquina de estado,
12 partición 94, 156–159, 162
OCL, ver Lenguaje de restricción de objetos OMG, ver subpartición, 157

Grupo de gestión de objetos OMT, ver Técnica de Red de Petri, 142, 146 pines, 155
modelado de objetos OOSE, ver Software orientado a

objetos polimorfismo, 8–9
Ingenieria poscondición
operando, 115 diagrama de actividades, 142
Operación 7 use el diagrama del caso, 36, 46
diagrama de actividades, 142 condición previa
llamar, 146 diagrama de actividades, 142
diagrama de clases, 51, 52, 54, 56–58 use el diagrama del caso, 36, 39, 46, 173
operación abstracta, 73 modelo prescriptivo, 4

acceso, 54, 61 tipo de datos primitivo, 75
Índice 205
privado, 7, 58–59, 70 diagrama Smalltalk, 11

de per fi l, 19 proceso de desarrollo de software, 14 sistema de
lenguaje de programación, 11, 52, 56, 58, software, 2, 49, 107, 171 estado de origen, 87
59, 61, 71, 80, 82
protegido, 7, 58–59 proceso estándar, 36, 41 estado,
pseudoestado, 89 7, 86–92
público, 7, 58–59, 77 compuesto, 96-102
estado histórico, 101-102
nombre calificado, 185 estado inicial, 90
ortogonal, 97–98
dirección de lectura, 60 pseudoestado, 89
solo lectura, 55 estado de origen, 87
recibir evento, 111 subfusil, 98

tiempo relativo estado de destino, 87
diagrama de secuencia, 130 invariante de estado, 132
diagrama de la máquina de estados, 94 diagrama de la máquina de estado, 19, 85-106,
interacción relevante, ver considerar 132, 169, 177–179

operador transición de estado, ver atributo estático de transición, ver
interacción repetida, ver bucle ingeniería de operación estática variable de clase, ver estereotipo de
requisitos del operador, 34 operación de clase, 189-191
mensaje de respuesta, 112

valor de retorno corriente, 154
diagrama de clase, 56, 75 estricto operador, 120-121

diagrama de secuencia, rol 113, 128 diagrama de estructura, 17-19
diagrama de clases, 17, 26, 49–84, 113, 133-134,
diagrama de clase, 63, 78, 79 173-175, 178, 180, 187 diagrama de componentes,
diagrama de secuencia, 108 18
multivalor, 109 diagrama de estructura de composición, 18
diagrama de casos de uso, 28 diagrama de despliegue, 18
diagrama de objeto, 17, 49–52, Diagrama de
selector, 109 60 paquetes, 18, 184 diagrama de per fi l, 19
yo, 110
autotransición, 93 subclase, 7, 70, 72, 73
enviar evento, 111 subfusil, 98
enviar acción de señal, 145 estado de submáquina, 98
seq operador, 119 subpartición, 157

diagrama de secuencia, 20, 107-135, 175 secuencia subtipo, 71
de eventos, ver rastro superclase, 8, 70
interacción secuencial con orden estricto, superestructura, ver metamodelo
ver estricto operador supertipo, 71

interacción secuencial con orden débil, carril de natación, ver dividir
ver seq operador nodo de sincronización

estado histórico poco profundo, 101 diagrama de actividad, 150, 152 diagrama
agregación compartida, 68 de máquina de estado, 91, 97 mensaje
señal síncrono, 112
diagrama de actividades, 144 sintaxis

recibir, 147 abstracto, 187
enviar, 145 especificación de atributo, 54
diagrama de secuencia, 107 hormigón, 187
diagrama de la máquina de estado, 94 especi fi cación del mensaje, 113
evento de señal, 94 especificación de multiplicidad, 56

SIMULA, 11 especi fi cación de operación, 56
206 Índice
especi fi cación de parámetros, 58 interno, 88, 92, 96

especi fi cación de transición, 88 autotransición, 93
sistema, 2, 23-27, 167, 177, ver también sintaxis, 88
sistema de software transitividad, 67, 71
comportamiento, 160 duración de transmisión, 131
Perímetro, 25, 37 acontecimiento desencadenante, 24, 36 tipo, 54,
interacción, 108 56, 57, 61, 71 tipo de datos, 7, 54, 75–76, 77
estado, 85, 87, 143 tipo de lista, ver tipo de datos primitivos de
estructura estática, 49 enumeración, 75 subtipo, 71
estado de destino, 87
terminar nodo, 92 supertipo, 71

asociación ternaria, 64
hora UML, ver Lenguaje de modelado unificado Lenguaje de
absoluto modelado unificado, 1, 4, 13, 14
diagrama de secuencia, 130
diagrama de la máquina de estado, 94 único, 56, 57, 67

actual, 131 desordenado 56, 57
relativo caso de uso, 23, 24-25, 26, 33 abstracto,
diagrama de secuencia, 94, 130 32, 44
restricción de tiempo, 130-131 caso de uso base, 30, 31
tiempo absoluto descripción, 35–36, 45
diagrama de secuencia, 130 ampliar, 30, 37
diagrama de la máquina de estado, 94 condición, 31
tiempo actual, 131 extendido, 31
tiempo relativo, 130 identi fi cación, 43–44
intervalo de tiempo, 131 incluir, 30, 32, 34, 37, 44
marca de sincronización, 131 incluido, 30
duración de transmisión, 131 herencia, 32, 34
evento temporal, 94 relación con el actor, 27 diagrama de casos de
después, ver tiempo relativo, máquina de estado uso, 19, 23–47, 168, 171 creación, 34–45
diagrama
cuando, mira tiempo absoluto, estado error, 37–41
diagrama de la máquina
intervalo de tiempo, 131 valor

mensaje que consume mucho tiempo, 114 valor de atributo, 51, 53, 55, 56 valor
diagrama de tiempos, 20, 138 predeterminado, 55
marca de sincronización, 131 variable
simbólico variable de clase, 59–60, 70 variable
token de control, 154, 161 token de datos, 154, 155 de instancia, 59, 70 visibilidad, 7, 58–59
concepto de token, 146, 147-153, 157, 159,
paquete, 58–59, 185

162 privado, 7, 58–59, 70
rastro protegido, 7, 58–59
diagrama de secuencia, 111, 115, público, 7, 58–59, 77
120–122, 124, 125
diagrama de máquina de estados, transición cuando, mira tiempo absoluto, máquina de estado
102-104, 86–89, 90, 96 alternativa, 90 diagrama
transición de finalización, 88 XMI, ver Intercambio de metadatos XML

estado compuesto, 96–98 Formato
concurrente, 91 Formato de intercambio de metadatos XML, 14
externo, 92, 96 xor restricción, 63

UML Classroom Español

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

UML Classroom Español

Cargado por

Copyright:

Formatos disponibles

Temas de pregrado en Ciencias de la Computación

Martina Seidl · Marion Scholz

Más información sobre esta serie en http://www.springer.com/series/7592

Christian Huemer Gerti Kappel

Copyright © 2012 de dpunkt.verlag GmbH, Heidelberg, Alemania. Título del

ISSN 1863-7310 ISSN 2197-1781 (electrónico)

Número de control de la Biblioteca del Congreso: 2015930192

Springer Cham Heidelberg Nueva York Dordrecht Londres ©

Impreso en papel sin ácido

Springer International PublishingAGSwitzerland es parte de Springer Science + BusinessMedia ( www.springer.com )

• diagramas de clases y objetos,

• diagramas de máquinas de estado,

• diagramas de casos de uso

también como sus interrelaciones. Para ello, introducimos la sintaxis

El modelado de software es un campo muy joven de la informática. Experimentó un

Linz y Viena, septiembre de 2014 Martina Seidl

2 Un breve recorrido por UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3 los Use el diagrama del caso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 los Diagrama de clase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5 los Diagrama de máquina de estado. . . . . . . . . . . . . . . . . . . . . . . . . . 85

6 los Diagrama de secuencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

7 los Diagrama de actividad. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

8 Todos juntos ahora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

9 Temas adicionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

9.2 El metamodelo UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . Mecanismos de 186

Referencias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Índice . . . . . . . . 195

Imagine que desea desarrollar un sistema de software que un cliente le ha encargado.

© Springer International Publishing Suiza 2015 1

Para desarrollar una mejor comprensión de los conceptos de modelado, a continuación

también en muchas otras disciplinas científicas (matemáticas, filosofía, psicología,

1. Cartografía: un modelo es siempre una imagen (mapeo) de algo, un

2. Reducción: un modelo no captura todos los atributos del original,

3. Pragmatismo: pragmatismo significa orientación hacia la utilidad. UN

Los modelos soportan una representación de un sistema que se reduce a lo esencial

• Abstracción: un modelo es siempre una representación reducida del sistema que

• Comprensibilidad: simplemente omitir detalles irrelevantes no es suficiente para que un modelo

creado. Por cierto, el código ejecutable, desarrollado en cualquier lenguaje de programación,

• Modelos como croquis

1.3 Orientación a objetos

manera, las clases describen el comportamiento de los objetos.

Encapsulamiento es la protección contra el acceso no autorizado al estado interno de un objeto Encapsulamiento

perclass) hereda todos los atributos y operaciones visibles (especificación e implementación) de

• Definir nuevos atributos y / u operaciones

La herencia permite clases extensibles y, como consecuencia, la creación de jerarquías de

Polimorfismo En términos generales, polimorfismo es la capacidad de adoptar diferentes formas. Durante la

1.4 La estructura del libro

En el Capítulo 2 damos una breve descripción de UML recapitulando la historia de su creación y

UML se basa completamente en conceptos orientados a objetos. Esto se nota particularmente en

2.1 La historia de UML

La introducción de estos conceptos fue el comienzo de una revolución en el desarrollo

© Springer International Publishing Suiza 2015 11

La aparición e introducción de la orientación a objetos como método en la ingeniería de software

Como ya comentamos en la sección 1.2, donde introdujimos la noción de modelo, los

A lo largo de los años, la orientación a objetos se ha convertido en el paradigma de desarrollo

Ada En la década de 1980, el lenguaje de programación Ada, financiado por el Departamento de

una multitud de lenguajes de modelado diferentes. Se requirió un esfuerzo considerable para

orientado a objetos, pidió la especificación de un estándar de modelado uniforme.

leído por seres humanos.

forma de Formato de intercambio de metadatos XML Idioma (OCL)

UML no está vinculado a una herramienta de desarrollo específica, un lenguaje de programación

En UML, un modelo se representa gráficamente en forma de diagramas. Un diagrama Diagrama

Diagrama de estructura Diagrama de comportamiento

Clase Paquete Objeto Máquina estatal Caso de uso