3.

1 Fundamentos de UML
El Lenguaje Unificado de Modelado (UML) fue creado para forjar un lenguaje de
modelado visual común y semántica y sintácticamente rico para la arquitectura, el
diseño y la implementación de sistemas de software complejos, tanto en estructura
como en comportamiento. UML tiene aplicaciones más allá del desarrollo de
software, p. ej., en el flujo de procesos en la fabricación.
Es comparable a los planos usados en otros campos y consiste en diferentes tipos
de diagramas. En general, los diagramas UML describen los límites, la estructura y
el comportamiento del sistema y los objetos que contiene. UML no es un lenguaje
de programación, pero existen herramientas que se pueden usar para generar
código en diversos lenguajes usando los diagramas UML. UML guarda una
relación directa con el análisis y el diseño orientados a objetos (studocu, 2022)

3.2 Estándares de modelado

Diagrama de casos de uso:
Muestra los distintos requisitos funcionales que se esperan de una aplicación o
sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones).
Elementos de un diagrama de casos de uso:
 Elipses: Representan requisitos funcionales del sistema.
 Actores: Un actor es una entidad que utiliza alguno de los casos de uso del
sistema.
 Relaciones: Son líneas que conectan actores y casos de uso. Los tipos de
relaciones son:
 Comunica (<<communicates>>): Relación entre un actor y un caso de uso
que denota la participación del actor en dicho caso de uso.
 Usa (<<uses>>) (o <<include>>): Relación de dependencia entre dos casos
de uso que denota la inclusión del comportamiento de un escenario en otro.
 Extiende (<<extends>>): Relación de dependencia entre dos casos de uso
que denota que un caso de uso es una especialización de otro.
En la figura 1 se hace referencia a un diagrama de casos de uso, que modela un
sistema de información de ventas de productos.

Figura 1. Diagrama de casos de uso.

Diagrama de clases:
Son diagramas de estructura estática que muestran las clases del sistema y sus
interrelaciones (incluyendo herencia, agregación, asociación, etc.). Los diagramas
de clase son el diagrama básico del modelado con UML, siendo utilizados tanto
para mostrar lo que el sistema puede hacer (análisis), como para mostrar cómo
puede ser construido (diseño). Un diagrama de clases está compuesto por:
Clases:
· Nombre de la clase.
· Atributos.
· Métodos.
Relaciones entre clases. Puede ser:
· Asociación.
· Dependencia.
· Agregación.
· Herencia.

Figura 2. Diagrama de clase.

Diagrama de secuencia:
El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar
interacción entre objetos en un sistema. Un diagrama de secuencia se modela
para cada caso de uso. Incluye los objetos y clases que se usan para implementar
el escenario y mensajes pasados entre los objetos. Un diagrama de secuencia
muestra los objetos que intervienen en el escenario con líneas discontinuas
verticales, y los mensajes pasados entre los objetos como vectores horizontales.
Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a
la parte inferior; la distribución horizontal de los objetos es arbitraria.
Los elementos de los diagramas de secuencia son:
 Objetos.
 Líneas de tiempo.
 Mensajes.
Figura 3. Diagrama de secuencia.
Diagrama de colaboración:
Es una forma alternativa al diagrama de secuencia de mostrar un escenario. Este
tipo de diagrama muestra las interacciones entre objetos organizadas en torno a
los objetos y los enlaces entre ellos.
 Objeto: Se representa con un rectángulo que contiene el nombre y la clase
del objeto en un formato nombreObjeto : nombreClase.
 Enlaces: Un enlace es una instancia de una asociación en un diagrama de
clases. Se representa como una línea continua que une a dos objetos, se
complementa con un número que indica el orden dentro de la interacción.
 Flujo de mensajes: Expresa el envío de un mensaje.
 Marcadores de creación y destrucción de objetos: Especifican cuando
son creados (new) y destruidos los objetos (delete).
 Objeto compuesto: Es una representación alternativa de un objeto y sus
atributos. En esta representación se muestran los objetos contenidos dentro
del rectángulo que representa al objeto que los contiene.
La diferencia entre un diagrama de colaboración y uno de secuencia es que no
muestra el tiempo como una dimensión aparte, por lo que resulta necesario
etiquetar con números de secuencia tanto la secuencia de mensajes como los
hilos concurrentes.
Figura 4. Diagrama de colaboración.
Diagrama de estados:
Un estado es una condición durante la vida de un objeto, de manera similar a una
persona que tiene diferentes estados, según la relación en la sociedad (padre,
hijo, docente, trabajador), de forma que cuando dicha condición se satisface se
lleva a cabo alguna acción o se espera por un evento. El estado de un objeto se
puede caracterizar por el valor de uno o varios de los atributos de su clase,
además, el estado de un objeto también se puede caracterizar por la existencia de
un enlace con otro objeto. Un diagrama de estados muestra el comportamiento de
una clase en un instante determinado.
Los elementos son:
 Estado inicial (círculo lleno).
 Estado final (doble círculo).
 Objetos.
 Relaciones.

Figura 5. Diagrama de estados.

Diagrama de objetos:
Un diagrama de objetos muestra un conjunto de objetos y sus relaciones en un
momento concreto. Contiene un conjunto de instancias de los elementos
encontrados en el diagrama de clases, representando sólo la parte estática de una
interacción, consistiendo en los objetos que colaboran, pero sin ninguno de los
mensajes intercambiados entre ellos. Muestran las instancias que se pueden
representar en una clase. Por ejemplo, la clase "empleado" puede ser jefe,
secretaria, director.
Figura 6. Diagrama de objetos.
Diagrama de actividades:
Son un caso especial de diagrama de estados y detallan las operaciones que se
realizan, ya sea en una clase o en un caso de uso, todos los estados del diagrama
de actividades son acciones de las cuales derivan otros estados, ya sea
consecutivos o con bifurcación. Permite expresar el orden en que se realizan
ciertos procesos y son enlazados por medio de flechas. De manera general, los
diagramas son empleados en procedimientos administrativos para detallar los
pasos que deben seguir para realizar determinada actividad. En la Figura 7 se
muestra un diagrama de actividades para venta de productos en línea. (clavijero,
2022)

3.3 Lenguajes de Modelado Elementos y Estereotipos del

Modelado
Las clases son los bloques de construcción más importantes de cualquier sistema
orientado a objetos.
Como se puede observar en la figura, una clase es una descripción de un conjunto
de objetos que comparten los mismos atributos, operaciones, relaciones y
semántica.

Figura
Nombre
origen
Atributos
Mover()
Suspender()
VaciarCola()
Operaciones

Objetivos:

Se utilizan para capturar el vocabulario del Sistema que esta modelando.

Se pueden utilizar para representar cosas que sean software, hardware o
puramente conceptuales.
Las clases bien estructuradas forman parte de una distribución equilibrada de
responsabilidades en el sistema.

Representación gráfica:
Esta notación permite visualizar una abstracción (características esenciales de
una entidad que la distingue entre otras entidades, una abstracción define una
frontera) independientemente de cualquier lenguaje de programación especifico y
de forma que permite resaltar las partes más importantes de una abstracción: su
nombre, sus atributos, sus operaciones y responsabilidades.

Nombre:
Es aquel nombre que la distinga de otras clases. Este nombre es una cadena de
texto, y por lo general son nombres cortos o expresiones nominales extraídos del
vocabulario del sistema , y existen 2 tipos :

Nombre simple: Nombre de camino: Nombre de la clase precedido por el

nombre del paquete en el que se encuentra.

Atributos:

Es una propiedad de una clase identificada con un nombre, que describe un rango
de valores que pueden tomar las instancias de la propiedad.
Esta propiedad es compartida por todos los objetos de esa clase.
En un momento dado un objeto de una clase tendrá valores específicos para cada
uno de los atributos de su clase.

Cliente Cliente

nombre Nombre: char

atributos dirección Dirección: char
teléfono Clave: int

Un atributoNombredirección
se puede especificar más su clase y su valor

Operaciones:

Una operación es una abstracción de algo que se puede hacer a un objeto y que
es compartido por todos los objetos de la clase.
 operaciones Alta
Bajas
cambios

Responsabilidades:

Es un contrato o una obligación de la clase, cuando se crea la clase se especifica

que todos los objetos de ésta tienen el mismo tipo de estado y el mismo tipo de
comportamiento.

Al modelar las clases, un buen comienzo consiste en especificar las

responsabilidades de los elementos del vocabulario:

-Solicitar pedidos
responsabilidades -Presentar
documentación

Otras características:

A veces se necesita visualizar o especificar otras características, como la

visibilidad de atributos y operaciones individuales, por ejemplo si es polimórfica o
constante, de las cuales se hablará en capítulos posteriores.

Finalmente se dirá que las clases rara vez se encuentran solas. Al construir los
modelos uno se centra en grupos de clases que interactúan entre si. En UML
estas sociedades de clases forman colaboraciones y normalmente se representan
en Diagramas de Clases.

Técnicas comunes de modelado

MODELADO DEL VOCABULARIO DE UN SISTEMA:

Los usuarios identifican las abstracciones, extrayéndolas normalmente de objetos

que ellos ya usan para describir su sistema.
Las técnicas como las tarjetas CRC y el análisis de casos de uso son formas para
ayudar a los usuarios a encontrar esas abstracciones.

Para modelar el vocabulario de un sistema:

Identificar aquellas cosas que utilizan los usuarios, para describir el problema o la
solución.
Para cada abstracción hay que identificar un conjunto de responsabilidades bien
repartidas
Definir los atributos y operaciones necesarias en cada clase para cumplir estas

Al ir aumentando de tamaño los modelos, muchas de las clases tienden a

agruparse en grupos relacionados conceptual y semánticamente.

En UML se pueden utilizar los paquetes para modelar estos grupos de clases.

MODELADO DE LA DISTRIBUCIÓN DE RESPONSABILIDADES DE UN

SISTEMA:

Una vez que se ha modelado, habrá que asegurarse que se tenga un equilibrio de
responsabilidades. Esto es que no se desea que ninguna clase sea demasiado
grande ni demasiado pequeña. UML ayuda a visualizar y especificar este reparto
de responsabilidades.

1.- Identificar un 3.- Dividir las clases

conjunto de clases con demasiadas
que colaboren entre responsabilidades.
ellas para realizar un Así como meter las
comportamiento pequeñas en otras
mayores

Modelar la
Distribución de
Responsabilidad
es en un Sistema

2.- Identificar 4.- Equilibrar las

responsabilidades responsabilidades
para cada una de las para que ninguna
clases clase en colaboración

MODELADO DE COSAS QUE NO SON SOFTWARE:

UML tiene como objetivo principal el modelado de sistemas con gran cantidad de
software, pero a veces, las cosas que se modelan pueden no tener un equivalente
en el software. Para modelar lo que no es software:

Hay que modelar la cosa que se esta abstrayendo como una clase.

Para distinguirlos de los bloques de construcción de UML . Crear un nuevo bloque

de construcción utilizando estereotipos para especificar la nueva semántica y
proporcionar una representación visual que lo caracterice.
Si lo que se está modelando según el tipo de hardware que a su vez contiene
software ,hay que considerar modelarlo como un tipo de nodo, de forma que más
tarde sea posible completar su estructura.

MODELADO DE TIPOS PRIMITIVOS:

Las cosas que se modelan pueden extraerse directamente del lenguaje de

programación que se utilice para implementar la solución. Normalmente, estas
abstracciones involucrarán tipos primitivos ,como enteros, cadenas e incluso tipos
enumerados ,que uno mismo podría crear.
Para modelar tipos primitivos:

Hay que modelar la cosa que se esta abstrayendo como un tipo o una
enumeración ,que se representa como una clase con el estereotipo adecuado.

Si se necesita especificar el rango de valores asociado al tipo ,hay que utilizar

restricciones
<<type>>
Int
{valores entre
-2**31-1 y +2**31}
Figura 7. Diagrama de actividades.
Diagrama de componentes:
Los diagramas de componentes describen los elementos físicos del sistema y sus
relaciones. Muestran las opciones de realización, incluyendo código fuente, binario
y ejecutable. Los componentes representan todos los tipos de elementos de
software que entran en la fabricación de aplicaciones informáticas. Pueden ser
simples archivos, bibliotecas cargadas dinámicamente, etc. Las relaciones de
dependencia se utilizan en los diagramas de componentes para indicar que un
componente utiliza los servicios ofrecidos por otro componente.
Componente: Es una parte física reemplazable de un sistema que empaqueta su
implementación y es conforme a un conjunto de interfaces a las que proporciona
su realización.
Algunos componentes tienen identidad y pueden poseer entidades físicas, que
incluyen objetos en tiempo de ejecución, documentos, bases de datos, etcétera.
Diagramas de despliegue:
Muestra la configuración de los componentes hardware, los procesos, los
elementos de procesamiento en tiempo de ejecución y los objetos que existen en
tiempo de ejecución. En este tipo de diagramas intervienen nodos, asociaciones
de comunicación, componentes dentro de los nodos y objetos que se encuentran,
a su vez, dentro de los componentes.
Un nodo es un objeto físico en tiempo de ejecución, es decir, una máquina que se
compone habitualmente de, por lo menos, memoria y capacidad de
procesamiento, así mismo, puede estar formado por otros componentes. (dsi.fceia,
2022)
Estereotipos en UML
Si bien UML es un lenguaje apropiado para el modelado de sistemas de software,
es indudable que estos sistemas van a contener tantas particularidades que
ningún formalismo o lenguaje, va a poder describirlos todos a la vez. Es por esto
que parte de la especificación del UML se dedica a definir mecanismos de
extensión con miras a incrementar el campo de aplicación del lenguaje.
Uno de estos mecanismos de extensión, quizás el más usado, son los llamados
estereotipos; pequeñas etiquetas que aplicadas a los elementos o relaciones de
un diagrama indican significado adicional. Es decir, que por medio de los
estereotipos vamos a poder aplicar las herramientas UML a nuevas áreas de
modelado, presuponiendo que estas áreas trabajan con los conceptos básicos del
lenguaje y requieren solo de expresar las ideas propias del sector.
La definición de un estereotipo es muy simple, basta con una tabla como la
siguiente:
Nombre: include
Aplica a: dependencias entre casos de uso
Significado: El caso de uso base refiere al caso de uso incluido como parte de su
flujo de eventos.
Especificación de un estereotipo
Luego, utilizamos esta definición como parte de nuestros modelos simplemente
etiquetando a los elementos a los que aplica con el nombre del estereotipo.
El significado de un estereotipo puede estar más o menos formalizado, según
nuestra necesidad; en aquellos casos en que se requiere una definición formal del
nuevo significado, UML nos propone el Lenguaje de Restricción de Objetos u OCL
por sus siglas en inglés.
Las herramientas de modelado más avanzadas pueden aceptar las definiciones de
los estereotipos y comprobar que se haya aplicado correctamente en el modelo, a
lo largo de todos los diagramas. Esto es una forma muy útil de incrementar la
capacidad de las herramientas de software, transformándolas en medios útiles en
áreas tan dispares como la planificación de proyectos o la simulación de eventos
discretos.
Por ultimo, siendo UML un lenguaje visual, como parte de la definición de un
estereotipo podemos incluir una imagen o icono de manera de hacer más
atractivos y legibles a nuestros diagramas. De hecho, cuando vemos un diagrama
UML con imagenes ocupando el lugar de elementos, lo que estamos viendo es en
realidad, elementos estereotipados. (synergix, 2022)
 Referencias
amps. (22 de Agosto de 2022). Obtenido de
https://www.tamps.cinvestav.mx/~vjsosa/clases/sd/Middleware_Recorrido.p
df
clavijero. (01 de Noviembre de 2022). Obtenido de
https://cursos.clavijero.edu.mx/cursos/178_pds/modulo3/contenido/tema3.2.
html?opc=1
dsi.fceia. (01 de Noviembre de 2022). Obtenido de
https://www.dsi.fceia.unr.edu.ar/downloads/informatica/info_II/Resumen_um
l.doc
hmong.es. (22 de Agosto de 2022). Obtenido de https://hmong.es/wiki/Middleware
studocu. (01 de Noviembre de 2022). Obtenido de
https://www.studocu.com/latam/document/universidad-tecnologica-de-el-
salvador/lenguaje-unificado-de-modelado-uml/ut-fundamentos-de-uml-nota-
8/17725483
synergix. (1 de Noviembre de 2022). Obtenido de
https://synergix.wordpress.com/2008/07/20/estereotipos-en-uml/