INSTITUTO TECNOLÓGICO NACIONAL DE MÉXICO

INSTITUTO TECNOLÓGICO DE TUXTEPEC

INVESTIGACIÓN NOTACIÓN UML

CARRERA:

INGENIERÍA EN SISTEMAS COMPUTACIONALES

ASIGNATURA:

FUNDAMENTOS DE INGENIERIA DE SOFTWARE

PROFESORA:

ABIGAIL ROMERO RODRIGUEZ

ALUMNA:

GONZALEZ SANCHEZ JHOSSELYN N° CONTROL 19350296

FECHA DE ENTREGA:

29 DE NOVIEMBRE DEL 2021

 INTRODUCCIÓN
En este documento vamos a explicar que es el lenguaje unificado de modelado
(UML, por sus siglas en inglés, Unified Modeling Language), así como sus
elementos, diagramas y su importancia para el desarrollo de software.

Es importante remarcar que UML es un “lenguaje de modelado” para

especificar o para describir métodos o procesos, pero que no tiene nada que
ver con el lenguaje que se use. El utilizar un lenguaje u otro lo único que hará
será cambiar la interpretación de ese diagrama y la codificación de este, de
todas formas, el comportamiento descrito debe ser el mismo
independientemente de la plataforma.

Comprenderemos las diversas formas de trabajar con este lenguaje de

modelado y de cómo cada una nos puede llevar a un mejor resultado a que si
lo hiciéramos un software sin estas herramientas. Ya que, al no poder crear un
modelo inicial, se perdería mucho tiempo y recursos al plantear, en el momento
de estar creando los softwares, las ideas vagamente creadas en el aire.
INDICE
INTRODUCCIÓN ................................................................................................................... 2
NOTACION UML ................................................................................................................... 4
ELEMENTOS GRÁFICOS .................................................................................................... 7
¿QUÉ DIAGRAMAS COMPONEN UML?......................................................................... 22
TIPOS DE DIAGRAMAS UML ........................................................................................... 24
IMPORTANCIA DE LA NOTACIÓN UML ......................................................................... 30
CONCLUSIÓN ..................................................................................................................... 32
BIBLIOGRAFÍA ................................................................................................................... 33
 NOTACION UML
Es uno del lenguaje de modelado de sistemas de software más conocido y
utilizado en la actualidad. Especialmente está presente en los sistemas
orientados a objetos. Su función es la de mediante un lenguaje gráfico poder
visualizar, especificar, construir y documentar un sistema.

Es importante remarcar que UML es un “lenguaje de modelado” para

especificar o para describir métodos o procesos, pero que no tiene nada que
ver con el lenguaje que se use. El utilizar un lenguaje u otro lo único que hará
será cambiar la interpretación de ese diagrama y la codificación del mismo, de
todas formas, el comportamiento descrito debe ser el mismo
independientemente de la plataforma.

No entraremos mucho más en detalle, simplemente añadir que el lenguaje

puede estar estructurado de varias formas:

Diagrama de clases

Diagrama de objetos

Diagrama de componentes

Diagrama de estructura compuesta

Diagrama de paquetes

Diagrama de despliegue

Nosotros emplearemos diagramas de clases.

Elementos básicos de lenguaje

Los diagramas de clases son los más utilizados. Describen los tipos de objetos
en el sistema y las distintas relaciones estáticas que existen entre ellos:

Ejemplo de asociaciones: Un cliente puede alquilar un número de vídeos

Ejemplo de subtipos: Una enfermera es un tipo de empleado

También los atributos y operaciones de una clase y ciertas restricciones que se

aplican al modo en que se conectan los objetos como, por ejemplo: la
navegabilidad, la cardinalidad…
Según Martin Fowler, podemos distinguir las siguientes perspectivas

Conceptual: se dibujan diagramas que representan los conceptos del dominio.

Especificación: atendemos a las interfaces del software y no a su

implementación.

Implementación: atendemos a las propias clases.

La diferencia entre las dos perspectivas software (de especificación y de

implementación) era tan sutil que Fowler decidió juntarlas en una sola: la
perspectiva de software (aunque normalmente deberemos seguir es
forzándonos por enfatizar las interfaces de los objetos más que los detalles de
implementación).

Entidades o clases

Las entidades o clases que son los rectángulos: Order, Customer, OrderLine y
Producto.

Asociaciones

Las asociaciones son las lineas que los unen. Representan las relaciones entre
las clases. Debemos tener claros los conceptos de multiplicidad y
navegabilidad.

Multiplicidad: situada en los extremos de una relación representa cuantos

objetos de esa clase pueden participar en dicha relación. Multiplicidades
comunes: 1, * (muchos o, lo que es lo mismo, 0..n) y 0..1.

Atributos y métodos

Los elementos están dentro de los rectángulos, en un primer nivel, son los
atributos de la propia clase y un segundo nivel los métodos o funciones de la
clase. En los atributos y métodos únicamente tenemos que tener claro que: Si
es público (+), privado (-) o protegido (#). Lo demás son añadidos que en
muchas ocasiones molestas. Con especificar el nivel de acceso, el nombre y el
tipo es suficiente. Todo esto depende del lenguaje.

En Java, la clase OrderLine podría quedar así:

public class OrderLine {

 private int quantity;

private Money price;

private Order order;

private Product product;

// getters y setters

En C#, que tiene la noción de propiedades, se correspondería con

public class OrderLine {

public int quantity { get; set; }

public Money price { get; set; }

public Order order { get; set; }

public Product product { get; set; }

Interfaces y clases abstractas

Hasta ahora solo habíamos hablado de clases “normales”. La especificación de

una interfaz o una clase abstracta la podemos ver en la siguiente imagen. Es
importante observar como en la imagen también observamos como podemos
representar la implementación (que una clase implemente una interfaz) y la
extensión (que una clase herede de otra clase sea o no abstracta).
 ELEMENTOS GRÁFICOS
Diagrama de Clases

Clase Abstracta

Las clases se representan con rectángulos divididos en tres áreas: la superior

contiene el nombre de la clase, la central contiene los atributos y la inferior las
acciones.

Clase Aviones

En el área superior figura el nombre de la clase que utilizamos como ejemplo, en

la central están sus atributos y en la inferior las acciones que ella realiza. Note
que las acciones llevan paréntesis al final del nombre dado que las mismas son
funciones y por lo tanto devuelven un valor.

Asociaciones

Las asociaciones son las que representan a las relaciones estáticas entre las
clases. El nombre de la asociación va por sobre o por debajo de la línea que la
representa. Una flecha rellena indica la dirección de la relación. Los roles se
ubican cerca del final de una asociación. Los roles representan la manera en que
dos clases se ven entre ellas. No es común el colocar ambos nombres, el de la
asociación y el de los roles a la vez. Cuando una asociación es calificada, el
símbolo correspondiente se coloca al final de la asociación, contra la clase que
hace de calificador.

Multiplicidad

Las notaciones utilizadas para señalar la multiplicidad se colocan cerca del final
de una asociación. Estos símbolos indican el número de instancias de una clase
vinculadas a una de las instancias de la otra clase. Por ejemplo, una empresa
puede tener uno o más empleados, pero cada empleado trabaja para una sola
empresa solamente.

Asociación Tripartita
A este tipo de asociación se le conoce como tripartita; esto quiere decir que
hay tres clases involucradas. ... Es posible contar con más de tres clases en
una asociación. En nombre de la generalización, el UML la trata
como asociación múltiple.

Composición y Agregación

Composición es un tipo especial de agregación que denota una fuerte posesión

de la Clase “Todo”, a la Clase “Parte”. Se grafica con un rombo diamante relleno
contra la clase que representa el todo. La agregación es una relación en la que
la Clase “Todo” juega un rol más importante que la Clase "Parte", pero las dos
clases no son dependientes una de otra. Se grafica con un rombo diamante vacío
contra la Clase “Todo”.

Generalización

Generalización es otro nombre para herencia. Se refiere a una relación entre dos
clases en donde una Clase “Específica” es una versión especializada de la otra,
o Clase “General”. Por ejemplo, Honda es un tipo de auto, por lo que la Clase
“Honda” va a tener una relación de generalización con la Clase “Auto”.
 Diagrama de Objetos

Nombre de los objetos

Cada objeto es representado como un rectángulo, que contiene el nombre del

objeto y su clase subrayadas y separadas por dos puntos.

Atributos

Como con las clases, los atributos se listan en un área inferior. Sin embargo,
los atributos de los objetos deben tener un valor asignado.
 Diagrama de Casos de Uso

Sistema

El rectángulo representa los límites del sistema que contiene los casos de uso.
Los actores se ubican fuera de los límites del sistema.

Casos de Uso

Se representan con óvalos. La etiqueta en el óvalo indica la función del

sistema.

Actores

Los actores son los usuarios de un sistema.

Relaciones

Las relaciones entre un actor y un caso de uso, se dibujan con una línea
simple. Para relaciones entre casos de uso, se utilizan flechas etiquetadas
"incluir" o "extender." Una relación "incluir" indica que un caso de uso es
necesitado por otro para poder cumplir una tarea. Una relación "extender"
indica opciones alternativas para un cierto caso de uso.
 Diagrama de Estados

Estado

El estado representa situaciones durante la vida de un objeto. Se representa

con un rectángulo que tiene sus esquinas redondeadas.

Transición

Una flecha representa el pasaje entre diferentes estados de un objeto. Se

etiqueta con el evento que lo provoca y con la acción resultante.

Estado Inicial

Estado Final

Ejemplo de Diagrama de Estado

 Diagrama de Secuencias

Rol de la Clase

El rol de la clase describe la manera en que un objeto se va a comportar en el

contexto. No se listan los atributos del objeto.

Activación

Los cuadros de activación representan el tiempo que un objeto necesita para

completar una tarea.
Mensajes

Los mensajes son flechas que representan comunicaciones entre objetos. Las
medias flechas representan mensajes asincrónicos. Los mensajes asincrónicos
son enviados desde un objeto que no va a esperar una respuesta del receptor
para continuar con sus tareas.

Líneas de Vida

Las líneas de vida son verticales y en línea de puntos, ellas indican la

presencia del objeto durante el tiempo.

Destrucción de Objetos

Los objetos pueden ser eliminados tempranamente usando una flecha

etiquetada "<>" que apunta a una X.
Loops

Una repetición o loop en un diagrama de secuencias, es representado como un

rectángulo. La condición para abandonar el loop se coloca en la parte inferior
entre corchetes [ ].

Diagrama de Actividades

Estados de Acción

Los estados de acción representan las acciones no interrumpidas de los

objetos.
Flujo de la Acción

Los flujos de acción, representados con flechas, ilustran las relaciones entre los

estados de acción.

Flujo de Objetos

El flujo de objetos se refiere a la creación y modificación de objetos por parte

de actividades. Una flecha de flujo de objeto, desde una acción a un objeto,
significa que la acción está creando o influyendo sobre dicho objeto. Una flecha
de flujo de objeto, desde un objeto a una acción, indica que el estado de acción
utiliza dicho objeto.

Estado Inicial

Estado inicial de un estado de acción.

Final State

Estado final de un estado de acción.

Ramificación

Un rombo representa una decisión con caminos alternativos. Las salidas

alternativas deben estar etiquetadas con una condición.

Sincronización

Una barra de sincronización ayuda a ilustrar la ocurrencia de transiciones

paralelas, así quedan representadas las acciones concurrentes.

Marcos de Responsabilidad

Los marcos de responsabilidad agrupan a las actividades relacionadas en una

misma columna.
 Diagrama de Colaboraciones

El diagrama de colaboraciones describe las interacciones entre los objetos en

términos de mensajes secuenciados. Los diagramas de colaboración
representan una combinación de información tomada de los diagramas de
clases, de secuencias y de casos de uso, describiendo el comportamiento,
tanto de la estructura estática, como de la estructura dinámica de un sistema.

Rol de la Clase

El rol de la clase describe cómo se comporta un objeto. Los atributos del objeto
no se listan.

Rol de las Asociaciones

Los roles de asociación describen cómo se va a comportar una asociación en

una situación particular. Se usan líneas simples etiquetadas con un
estereotipo*. (ver al final del documento)

Mensajes

Contrariamente a los diagramas de secuencias, los diagramas de colaboración

no tienen una manera explícita para denotar el tiempo, por lo que entonces
numeran a los mensajes en orden de ejecución. La numeración puede
anidarse; por ejemplo, para mensajes anidados al mensaje número 1: 1.1, 1.2,
1.3, etc. . La condición para un mensaje se suele colocar entre corchetes. Para
indicar un loop se usa * después de la numeración.

Ejemplo de Diagrama de Colaboración

Este ejemplo agrega un velocímetro al conjunto de clases que constituyen a un

“Avión”. Al alcanzar una cierta velocidad el velocímetro indicará al timón que
debe elevarse y al tren de aterrizaje que debe retraerse.

Diagrama de Componentes
Un diagrama de componentes describe la organización de los componentes
físicos de un sistema.
Componente
Un componente es un bloque de construcción física del sistema.
Interfase
Una interfase describe a un grupo de operaciones usada o creada por
componentes.

Dependencias
Las dependencias entre componentes se grafican usando flechas de puntos.

Diagrama de Distribución
Nodo
Un nodo es un recurso físico capaz de ejecutar componentes de código. .
(Procesador)

Asociación
La asociación se refiere a la conexión física entre los nodos, como por ejemplo
Ethernet.

Componentes y Nodos
 Otras características
Paquetes
Volver En algunas ocasiones se encontrará con la necesidad de organizar los
elementos de un diagrama en un grupo. Tal vez quiera mostrar que ciertas
clases o componentes son parte de un subsistema en particular. Para ello, se
pueden agrupar en un paquete, que se representa por una carpeta tabular.

Notas Volver
Es frecuente que alguna parte del diagrama no presente una clara explicación
del porqué está allí o la manera en que trabaja. Cuando éste sea el caso, la
nota UML será útil. La nota tiene una esquina doblada y se adjunta al elemento
del diagrama conectándolo mediante una línea punteada.
Estereotipos
Algunos sistemas requieren de elementos hechos a medida que no se
encuentran en el UML. Para ello, los estereotipos o clisés le permiten tomar
elementos propios del UML y convertirlos en otros que se ajusten a las
necesidades. Se representan como un nombre entre dos pares de paréntesis
angulares.

¿QUÉ DIAGRAMAS COMPONEN UML?

El Lenguaje Unificado de Modelado o UML (“Unified Modeling Language”) es
un lenguaje estandarizado de modelado. Está especialmente desarrollado para
ayudar a todos los intervinientes en el desarrollo y modelado de un sistema o
un producto software a describir, diseñar, especificar, visualizar, construir y
documentar todos los artefactos que lo componen, sirviéndose de varios tipos
de diagramas.

Estos diagramas contenidos en UML son la forma más común y más utilizada
de modelado de software. Modelar consiste en crear un diseño previo de una
aplicación antes de proceder a su desarrollo e implementación, aunque en
ocasiones concretas puede hacerse posteriormente. De la misma forma que un
arquitecto dibuja y diseña planos sobre el edificio que va a construir, un analista
de software (u otros perfiles que cargan con este rol) crea distintos diagramas
UML que sirven de base para la posterior construcción/mantenimiento del
sistema. El modelado es la principal forma de visualizar el diseño de una
aplicación con la finalidad de compararla con los requisitos antes de que el
equipo de desarrollo comience a codificar.

El modelado es vital en todo tipo de proyectos, pero cobra especial importancia

a medida que el proyecto crece de tamaño. Para que una aplicación funcione
correctamente, debe ser diseñada para permitir la escalabilidad, la seguridad y
la ejecución. Utilizando diagramas UML se consigue visualizar y verificar los
diseños de sus sistemas de software antes de que la implementación del
código haga que los cambios sean difíciles y demasiado costosos.

Estos diagramas de UML son representaciones gráficas que muestran de

forma parcial un sistema de información, bien esté siendo desarrollado o ya lo
haya sido. Suelen estar acompañados de documentación que les sirve de
apoyo, adoptando estas múltiples formas. Además, UML no excluye la
posibilidad de mezclar diagramas, algo que, de hecho, suele ser bastante
común. Siempre teniendo en cuenta una de las máximas de UML: Una imagen
vale más que mil palabras.

Como principal desventaja ampliamente mencionada de UML podemos

nombrar el hecho de que se trata de un lenguaje muy amplio, haciendo, en
ocasiones, complicado utilizar todas las posibilidades que ofrece. No obstante,
los analistas tienden a utilizar los diagramas de forma sencilla, consiguiendo
que sean entendidos fácilmente por cualquier persona que accedan a ellos.

El Lenguaje Unificado de Modelado (UML) desempeña un rol importante no

solo en el desarrollo de software, sino también en los sistemas que no tienen
software en muchas industrias, ya que es una forma de mostrar visualmente el
comportamiento y la estructura de un sistema o proceso. el UML ayuda a
mostrar errores potenciales en las estructuras de aplicaciones, el
comportamiento del sistema y otros procesos empresariales.

¿Por qué UML?

El UML se implementó por primera vez en la década de los 90 gracias a tres

ingenieros de software: Grady Booch, Ivar Jacobson y James Rumbaugh. Ellos
querían desarrollar una forma menos caótica de representar el cada vez más
complejo desarrollo de software, a la vez que separaban la metodología del
proceso. Hoy, el UML sigue siendo la indicación estándar para los
desarrolladores, así como para gestores de proyectos, propietarios de
negocios, empresarios tecnológicos y profesionales de distintos sectores.

¿Cuáles son las ventajas del UML?

• Simplifica las complejidades

• Mantiene abiertas las líneas de comunicación
• Automatiza la producción de software y los procesos
• Ayuda a resolver los problemas arquitectónicos constantes
• Aumenta la calidad del trabajo
• Reduce los costos y el tiempo de comercialización
 TIPOS DE DIAGRAMAS UML
Existen dos tipos principales de diagramas UML: diagramas de estructura y
diagramas de comportamiento (y dentro de esas categorías se encuentran
varios otros). Estas variaciones existen para representar los numerosos tipos
de escenarios y diagramas que usan los diferentes tipos de personas.

Desde clientes y gestores de proyectos hasta autores técnicos, diseñadores,

analistas, codificadores y encargados de pruebas y control de calidad, cada rol
utilizará un diagrama específico que se adapte a sus necesidades. Eso significa
que cada disposición requiere un enfoque y nivel de detalle diferente. El
objetivo es que el UML exprese visualmente diagramas que sean fáciles de
entender para todos.

• Diagrama UML básico

• Ejemplo de secuencia básica del UML. Plantilla disponible para
descarga
• Echemos un vistazo más de cerca:
• Diagramas estructurales

Los diagramas estructurales representan la estructura estática de un software o

sistema, y también muestran diferentes niveles de abstracción e
implementación. Estos se usan para ayudarlo a visualizar las diversas
estructuras que componen un sistema, como una base de datos o aplicación.
Muestran la jerarquía de componentes o módulos y cómo se conectan e
interactúan entre sí. Estas herramientas ofrecen orientación y garantizan que
todas las partes de un sistema funcionen según lo previsto en relación con
todas las demás partes.

Diagramas de comportamiento

Empieza tu negocio con un curso intensivo de Microsoft 365

Capacita a tu equipo para que sea productivo todos los días, desde
prácticamente cualquier lugar, con Microsoft 365.
El enfoque aquí está en los aspectos dinámicos del sistema de software o
proceso. En estos diagramas se muestra la funcionalidad de un sistema y se
enfatiza lo que debe ocurrir en el sistema que se está modelando.

Echemos un vistazo a los muchos tipos diferentes de diagramas UML que se

encuentran en cada categoría:

1. Diagramas UML estructurales

Diagrama de clases. Este diagrama, el más común en el desarrollo de

software, se usa para representar el diseño lógico y físico de un sistema, y
muestra sus clases. Tiene un aspecto similar al del diagrama de flujo porque
las clases se representan con cuadros. Este diagrama ofrece una imagen de
las diferentes clases y la forma en la que se interrelacionan, y cada clase posee
tres compartimientos:

Sección superior: nombre de clase

Sección central: atributos de clase

Sección inferior: métodos u operaciones de clase

Diagrama UML de interfaz de clases

Ejemplo de diagrama UML de interfaz de clases. Plantilla disponible para

download.

Diagrama de objetos. A menudo, este diagrama se usa como una forma de

comprobar la revisión de un diagrama de clases para fines de precisión. En
otras palabras, ¿funcionará en la práctica? Muestra los objetos de un sistema y
sus relaciones, y ofrece una mejor visión de los potenciales defectos de diseño
que necesitan reparación.

Diagrama de componentes. También conocido como diagrama de flujo de

componentes, muestra agrupaciones lógicas de elementos y sus relaciones. En
otras palabras, ofrece una vista más simplificada de un sistema complejo al
desglosarlo en componentes más pequeños. Cada una de las piezas se
muestra con una caja rectangular, que tiene su nombre escrito dentro. Los
conectores definen la relación/las dependencias entre los diferentes
componentes.
Diagrama de estructura compuesta. Este lo utilizan rara vez las personas
externas al campo de desarrollo de software. ¿Por qué? Aunque es similar a un
diagrama de clases, adopta un enfoque más profundo, que describe la
estructura interna de múltiples clases y muestra las interacciones entre ellas.
Salvo que usted sea desarrollador, la vista de nivel superior probablemente le
entregará información suficiente.

Diagrama de despliegue. Este diagrama muestra los componentes de hardware

(nodos) y software (artefactos) y sus relaciones. Ofrece una representación
visual exacta del lugar donde se implementa cada componente de software.

Diagrama de paquetes. Este se utiliza para representar las dependencias entre

los paquetes que componen un modelo. Su objetivo principal es mostrar la
relación entre los diversos componentes grandes que forman un sistema
complejo.

Diagrama de perfiles. Este es más similar a un lenguaje que a un diagrama. Un

diagrama de perfil ayuda a crear nuevas propiedades y semántica para los
diagramas UML al definir estereotipos personalizados, valores marcados y
restricciones. Estos perfiles le permiten personalizar un metamodelo de UML
para diferentes plataformas (por ejemplo, Java Platform, Enterprise Edition
(Java EE) o Microsoft .NET Framework) y dominios (por ejemplo modelado de
proceso empresarial, arquitectura orientada a servicios, aplicaciones médicas y
más).

2. Diagramas UML de comportamiento:

Diagrama de actividades. Este representa un proceso paso a paso con un inicio

y final claros. Es un conjunto de actividades que deben realizarse para lograr
un objetivo. Muestra cómo cada actividad conduce a la siguiente y cómo todas
estas se conectan. Además del desarrollo de software, estas se pueden utilizar
en casi cualquier entorno empresarial. También se denominan asignación o
modelado de proceso empresarial.

Diagrama UML básico de casos de uso

Ejemplo de un diagrama UML básico de casos de uso. Plantillas disponibles

para download.
Diagrama de casos de uso. Este describe lo que un sistema hace las cosas,
pero no la forma en que las hace. Un caso de uso es un conjunto de eventos
que ocurren cuando un “actor” usa un sistema para completar un proceso. Un
actor se define como cualquier persona o cualquier cosa que interactúa con el
sistema (persona, organización o aplicación) desde fuera del sistema. Por lo
tanto, un diagrama de casos de uso describe visualmente ese conjunto de
secuencias y representa los requisitos funcionales del sistema.

Diagrama de descripción general de interacción. Este diagrama, a menudo

complejo, es similar al diagrama de actividad, ya que ambos muestran una
secuencia paso a paso de las actividades. Sin embargo, un diagrama de
descripción general de interacción es un diagrama de actividad que se
compone de diferentes diagramas de interacción. Usan la misma composición
que un diagrama de actividad (nodos iniciales, final, decisión, unión, fork y join)
e incorpora elementos como la interacción, el uso de la interacción, restricción
de tiempo y restricción de la duración.

Diagrama de tiempos. Cuando el tiempo ocupa un lugar central, se usa este

diagrama de UML. También conocido como un diagrama de secuencia o
eventos, no muestra la forma en que los objetos interactúan o cambian entre sí.
Funcionalmente, muestra cómo los objetos y actores se desempeñan en una
línea de tiempo. El enfoque aquí está en la duración de los eventos y los
cambios que se producen en función de las restricciones de duración. Las
principales partes de un diagrama de plazos incluye:

Línea de vida: participante individual

Línea de tiempo de estado: estados diferentes por los que pasa la línea de vida
dentro de una canalización

Restricción de duración: tiempo necesario para que se cumpla una restricción

Restricción de tiempo: un periodo en el que el participante debe completar una

acción

Destrucción: cuando finaliza la línea de vida de un objeto. Después de que se

realiza la destrucción en una línea de tiempo, no se produce otra ocurrencia.
Diagrama de máquina de estados. También denominado gráfico de estados,
este diagrama se aplica cuando el comportamiento de un objeto es complejo y
el detalle es esencial. Ayuda a describir el comportamiento de un objeto (o a
veces de un operador) y la forma en que cambia según los eventos internos y
externos.

Diagrama de secuencia. Popular más allá de la comunidad de diseño, este

diagrama visualmente atractivo es bueno para mostrar todo tipo de procesos
empresariales. Simplemente revela la estructura de un sistema, mostrando la
secuencia de mensajes e interacciones entre actores y objetos
cronológicamente. Los diagramas de secuencia muestran iteraciones y
ramificaciones simples. Es favorable al realizar múltiples tareas.

Diagrama de comunicación. Un diagrama de comunicación o colaboración es

similar a un diagrama de secuencia. Sin embargo, enfatiza la comunicación
entre objetos. Muestra la organización de los objetos que participan en una
interacción y presenta iteraciones y ramificaciones más complejas.

Modelos de base de datos

El UML también ha ganado popularidad como indicación para modelar bases

de datos. Estos modelos son una gran herramienta visual para generar ideas,
diagramas de forma libre y colaborar en ideas.

Si bien el UML no tiene especificaciones para el modelado de datos, puede ser

una herramienta útil para la creación de diagramas, especialmente porque los
datos de las bases de datos se pueden usar en la programación orientada a
objetos.

Echemos un vistazo a los diferentes tipos de modelos de bases de datos que

puede crear:

Modelo de base de datos jerárquico. Un modelo antiguo, pero bueno. Los datos
de este modelo están organizados en una estructura de árbol. El árbol está
compuesto por varios grupos llamados segmentos. Utiliza una relación de uno
a muchos. El acceso a los datos también es predecible.

Modelo de red. Este modelo adopta la forma de un gráfico, donde los tipos de
relación son arcos y los tipos de objeto son nodos. A diferencia de otros
modelos de bases de datos, el esquema del modelo de red no se limita a una
red o jerarquía.

Modelo de base de datos orientado a objetos. Este modelo utiliza una colección
de objetos, o elementos de software reutilizables, con características y métodos
asociados. Por ejemplo, una base de datos multimedia podría tener imágenes
que no se pueden almacenar en una base de datos relacional. O una base de
datos de hipertexto permite establecer vínculos con otros objetos.

Modelo relacional. Aquí, los datos se estructuran utilizando relaciones o

estructuras matemáticas similares a una cuadrícula que tienen columnas y filas.
Básicamente, es una tabla.

El modelo objeto-relacional. Como su nombre lo indica, este modelo es una

combinación de los dos mencionados anteriormente. Admite objetos, clases,
herencia y otros elementos orientados a objetos, pero también admite tipos de
datos, estructuras tabulares y más, como en un modelo de datos relacionales.

Modelo entidad-relación. Este se compone de tipos de entidad (personas,

lugares o cosas). Muestra las relaciones que pueden existir entre ellos. Al
definir las entidades, sus atributos y mostrar las relaciones entre ellas, un
diagrama ER ilustra la estructura lógica de las bases de datos.

Modelo de documento. Está diseñado para almacenar y administrar

documentos o datos semiestructurados, en lugar de datos atómicos. Tiene una
estructura de árbol en la que cada nodo es un objeto que representa una parte
del documento.

Modelo de entidad-atributo-valor. En el EAV o los modelos de esquema abierto,

los datos se registran en tres columnas:

La entidad (lo que se describe)

El atributo o parámetro (por ejemplo, nombre, descripción, tipo de datos)

El valor del atributo.

Esquema de estrella. Esta es la versión más simple de un modelo dimensional,

en el que los datos se organizan en dimensiones y hechos. Se utiliza en
inteligencia empresarial y almacenamiento de datos, ya que es adecuado para
consultar conjuntos de macrodatos.

Simplificación con software

Cuando crea modelos de base de datos o diagramas UML con una herramienta
de software, el proceso se simplifica y mejora. Asegúrese de elegir uno que le
permita:

Crear diagramas profesionales con plantillas prediseñadas y miles de formas

en un ecosistema de contenido que cumpla las normas del sector como la UML
2.5, BPMN 2.0 e IEEE.

Dar vida a sus diagramas con la superposición de datos, los colores y los
gráficos para hacer que sean más fáciles de comprender, incluyendo la
visualización de datos de Excel en un paso.

Colaborar con otros usuarios mediante la coautoría, los comentarios y las

anotaciones.

Comunicar una única versión de la realidad y obtener acceso a los diagramas

desde casi cualquier lugar con un explorador o mediante las aplicaciones para
dispositivos.

En el desarrollo de software y sistemas que no son de software en muchas

industrias, el uso de diagramas visuales UML puede desempeñar un papel vital
en el éxito de la construcción de procesos y estructuras de comportamiento.

IMPORTANCIA DE LA NOTACIÓN UML

El UML es un estándar para describir y documentar los procesos utilizados en
las diferentes partes de un software. También es utilizado para poder diseñar el
software antes de hacer cualquier aplicación, optimizando la planificación para
asegurar la calidad.

El OMG define los propósitos de UML de la siguiente manera:

Brindar a arquitectos de sistemas, ingenieros y desarrolladores de software las

herramientas para el análisis, el diseño y la implementación de sistemas
basados en software, así como para el modelado de procesos de negocios y
similares.

Hacer progresar el estado de la industria permitiendo la interoperabilidad de

herramientas de modelado visual de objetos. No obstante, para habilitar un
intercambio significativo de información de modelos entre herramientas, se
requiere de un acuerdo con respecto a la semántica y notación.

UML cumple con los siguientes requerimientos:

Establecer una definición formal de un metamodelo común basado en el

estándar MOF (Meta-Object Facility) que especifique la sintaxis abstracta del
UML. La sintaxis abstracta define el conjunto de conceptos de modelado UML,
sus atributos y sus relaciones, así como las reglas de combinación de estos
conceptos para construir modelos UML parciales o completos.

Brindar una explicación detallada de la semántica de cada concepto de

modelado UML. La semántica define, de manera independiente a la tecnología,
cómo los conceptos UML se habrán de desarrollar por las computadoras.

Especificar los elementos de notación de lectura humana para representar los

conceptos individuales de modelado UML, así como las reglas para
combinarlos en una variedad de diferentes tipos de diagramas que
corresponden a diferentes aspectos de los sistemas modelados.

Definir formas que permitan hacer que las herramientas UML cumplan con esta
especificación. Esto se apoya (en una especificación independiente) con una
especificación basada en XML de formatos de intercambio de modelos
correspondientes (XMI) que deben ser concretados por herramientas
compatibles.
 CONCLUSIÓN
El lenguaje Unificado de modelado UML es una notación que es el resultado de
la evolución de las notaciones previas en ingeniería de software, toma los
aspectos fuertes de tres metodologías anteriores: OMT, Booch y OOSE.

La notación UML se fundamenta en principios de modelado, lo cual es

importante para toda implementación de un sistema de información.

El UML debe adoptar el Proceso Unificado de Desarrollo para modelar las

actividades de un proyecto.

Los diagramas para utilizar en las diferentes etapas del desarrollo de los
sistemas de información pueden variar dependiendo del tamaño y tipo de
sistema, por lo que es necesario organizarlos según las fases del Proceso
Unificado.
 BIBLIOGRAFÍA
1. BARRIENTOS Aleida Proceso Metodológico de Auditoría Informática
aplicado a la evaluación y seguimiento de Sistemas de Gestión
desarrollados con el estándar de modelado UML, Tesis de Maestría en
Ingeniería Informática, Universidad de Oriente La Habana Cuba –
Universidad Autónoma Tomás Frías, Potosí-Bolivia, 2002.
2. BOOCH Grady et al. El lenguaje Unificado de Modelado, Primera
Edición, Editorial Addison Wesley, 1999.
3. LARMAN Craig UML y Patrones Una introducción al Análisis y Diseño
Orientado a Objetos y al Proceso Unificado, Segunda Edición, Editorial
Prentice Hall, 2002.
4. JACOBSON Ivar et al. El Proceso Unificado de Modelado, Primera
Edición, Editorial Addison Wesley, 1999.
5. RUMBAUGH James Modelado y Diseño Orientado a Objetos con OMT,
Primera Edición, Editorial Addison Wesley, 1998