Características generales del lenguaje UML. Conceptos básicos del lenguaje de modelado unificado Diagrama de estructura interna de Uml

El diagrama UML es un lenguaje de descripción gráfica especializado diseñado para el modelado de objetos en el desarrollo de varios software... Este lenguaje tiene un perfil amplio y es un estándar abierto que utiliza varios símbolos gráficos para crear un modelo abstracto del sistema. El UML fue creado para proporcionar definición, visualización, documentación y diseño de todo tipo de sistemas de software... Vale la pena señalar que el diagrama UML en sí mismo no es un lenguaje de programación, pero ofrece la posibilidad de generar un código separado basado en él.

¿Por qué es necesario?

UML no se limita a modelar todo tipo de software. Además, este lenguaje se usa activamente hoy en día para modelar varios procesos comerciales, realizar ingeniería de sistemas y mostrar estructuras organizativas.

Con UML, los desarrolladores de software pueden imponer una convención completa en las notaciones gráficas utilizadas para representar conceptos generales como componente, generalización, clase, comportamiento y agregación. Esto logra un mayor grado de concentración en arquitectura y diseño.

También vale la pena señalar que existen varios tipos de tales diagramas.

Diagrama de clase

Un diagrama de clases UML es un diagrama de estructura estática diseñado para describir la estructura de un sistema, así como mostrar atributos, métodos y dependencias entre varias clases diferentes.

Vale la pena señalar el hecho de que existen varios puntos de vista sobre la construcción de tales diagramas, dependiendo de cómo se usarán:

• Conceptual. En este caso, el diagrama de clases de UML describe el modelo de un dominio específico y solo se proporcionan clases de objetos aplicados.
• Específico. El diagrama se utiliza en el proceso de diseño de varios sistemas de información.
• Implementación. El diagrama de clases incluye todo tipo de clases que se utilizan directamente en el código del programa.

Diagrama de componentes

Un diagrama de componentes UML es un diagrama estructural completamente estático. Su objetivo es demostrar la división de un determinado sistema de software en varios componentes estructurales, así como las conexiones entre ellos. Un diagrama de componentes UML como tal puede usar todo tipo de modelos, bibliotecas, archivos, paquetes, archivos ejecutables y muchos otros elementos.

Diagrama de estructura compuesta / compuesta

El diagrama de estructura compuesto / compuesto de UML también es un diagrama de estructura estática, pero se utiliza para mostrar la estructura interna de las clases. Si es posible, este diagrama también puede demostrar la interacción de los elementos que se encuentran en la estructura interna de la clase.

Un subtipo de ellos es el diagrama de cooperación UML, que se utiliza para demostrar los roles, así como la interacción de varias clases dentro de los límites de la cooperación. Son muy útiles cuando necesita modelar patrones de diseño.

Vale la pena señalar que los tipos de diagramas de clases UML y los tipos de estructuras compuestas se pueden usar al mismo tiempo.

Diagrama de implementación

Este diagrama se utiliza para simular nodos de trabajo, así como todo tipo de artefactos que se implementaron en ellos. UML 2 implementa artefactos en varios nodos, mientras que la primera versión implementa exclusivamente componentes. Por lo tanto, el diagrama de implementación de UML se utiliza principalmente en la segunda versión.

Se forma una dependencia manifiesta entre el artefacto y el componente que implementa.

Diagrama de objetos

Esta vista le permite ver una instantánea completa o parcial del sistema que se está creando en un momento determinado. Muestra completamente todas las instancias de clases de un sistema en particular, indicando los valores actuales de sus parámetros, así como los vínculos entre ellos.

Diagrama del paquete

Este diagrama es de naturaleza estructural y su contenido principal son todo tipo de paquetes, así como la relación entre ellos. En este caso, no hay división dura entre varios diagramas estructurales, como resultado de lo cual su uso se encuentra con mayor frecuencia únicamente por conveniencia y no tiene ningún significado semántico. Vale la pena señalar que diferentes elementos pueden proporcionar otros diagramas UML (ejemplos: paquetes y los propios diagramas de paquetes).

Su uso se lleva a cabo para asegurar la organización de varios elementos en grupos de acuerdo con un criterio determinado, para simplificar la estructura y también para organizar el trabajo con el modelo de este sistema.

Diagrama de actividad

El diagrama de actividad UML muestra la descomposición de una actividad específica en varios partes componentes... En este caso, el concepto de "actividad" se refiere a la especificación de un cierto comportamiento ejecutable en forma de paralelo, así como la ejecución secuencial coordinada de varios elementos subordinados: tipos de actividades anidadas y varias acciones, unidas por hilos provenientes del salidas de un determinado nodo a las entradas de otro.

Los diagramas de actividad UML se utilizan a menudo para modelar varios procesos comerciales, cálculos paralelos y secuenciales. Entre otras cosas, simulan todo tipo de procedimientos tecnológicos.

Diagrama de autómata

Esta vista también se denomina diagrama de estado UML. Tiene una máquina de estados presentada con estados y transiciones simples y compuestos.

Una máquina de estados es una especificación de una secuencia de diferentes estados a través de los cuales pasa cierto objeto, o interacción en respuesta a algunos eventos en su vida, así como las respuestas del objeto a tales eventos. Una máquina de estado que usa un diagrama de estado UML se adjunta al elemento fuente y se usa para definir el comportamiento de sus instancias.

Los llamados esquemas de dragones se pueden usar como análogos de tales diagramas.

Diagramas de casos de uso

El diagrama de casos de uso de UML describe todas las relaciones que surgen entre los actores, así como los diversos casos de uso. Su tarea principal es proporcionarse como un medio completo por el cual un cliente, un usuario final o algún desarrollador puede discutir conjuntamente el comportamiento y la funcionalidad de un sistema en particular.

Si se utiliza un diagrama de casos de uso de UML en el proceso de modelado de un sistema, entonces el analista va a:

• Separe claramente el sistema simulado de su entorno.
• Identificar los actores, formas de interacción con este sistema, así como su funcionalidad esperada.
• Establecer en el glosario como área temática varios conceptos que se relacionan con una descripción detallada de la funcionalidad de este sistema.

Si se desarrolla un diagrama de uso en UML, el procedimiento comienza con una descripción textual, que se obtiene al trabajar con un cliente. Al mismo tiempo, vale la pena señalar el hecho de que varios requisitos no funcionales en el proceso de elaboración de un modelo de casos de uso se omiten por completo, y ya se formará un documento separado para ellos.

Comunicaciones

Un diagrama de comunicación, al igual que un diagrama de secuencia UML, es transitivo, es decir, expresa interacción en sí mismo, pero al mismo tiempo lo demuestra. diferentes caminos y, si es necesario, con el grado de precisión deseado, puede convertir uno en otro.

El diagrama de comunicación describe las interacciones que ocurren entre los diversos elementos de la estructura compuesta, así como los roles de la cooperación. La principal diferencia con un diagrama de secuencia es que indica claramente la relación entre varios elementos y el tiempo no se usa como una dimensión separada.

Este tipo se distingue por un formato completamente libre para ordenar varios objetos y enlaces de la misma manera que se hace en un diagrama de objetos. Si es necesario mantener el orden de los mensajes en este formato libre, se numeran cronológicamente. La lectura de este diagrama comienza con el mensaje original 1.0 y luego continúa en la dirección en que los mensajes se pasan de un objeto a otro.

La mayoría de estos diagramas muestran exactamente la misma información que nos proporciona un diagrama de secuencia, sin embargo, debido a que utiliza una forma diferente de presentar la información, ciertas cosas en un diagrama se vuelven mucho más fáciles de identificar que en otro. También vale la pena señalar que el diagrama de comunicación muestra más claramente con qué elementos interactúa cada uno. elemento separado, mientras que el diagrama de secuencia muestra más claramente en qué orden tienen lugar las interacciones.

Diagrama de secuencia

Un diagrama de secuencia UML demuestra las interacciones entre varios objetos, que están ordenados de acuerdo con su momento de ocurrencia. Este diagrama muestra las interacciones ordenadas en el tiempo entre varios objetos. En particular, muestra todos los objetos que participan en la interacción, así como la secuencia completa de mensajes intercambiados por ellos.

Los elementos principales en este caso son las designaciones de varios objetos, así como líneas verticales que muestran el paso del tiempo y rectángulos que proporcionan la actividad de un objeto en particular o el desempeño de alguna función por parte de este.

Diagrama de colaboración

Este tipo de diagramas le permite demostrar interacciones entre varios objetos, abstrayéndose de la secuencia de mensajes de difusión. Este tipo de diagramas de forma compacta muestra absolutamente todos los mensajes transmitidos y recibidos de un determinado objeto, así como los formatos de estos mensajes.

Debido al hecho de que los diagramas de secuencia y los diagramas de comunicación son simplemente vistas diferentes de los mismos procedimientos, Rational Rose proporciona la capacidad de crear un diagrama de comunicación a partir de un diagrama de secuencia o viceversa, y también realiza su sincronización completamente automática.

Gráficos de descripción general de interacciones

Estos son diagramas UML, que son un subconjunto de diagramas de actividad que incluyen tanto elementos de secuencia como construcciones de flujo de control.

Vale la pena señalar el hecho de que este formato combina los diagramas de Colaboración y Secuencia, que brindan una oportunidad desde diferentes puntos de vista para considerar la interacción entre varios objetos en el sistema que se está formando.

Diagrama de sincronizacion

Es un diagrama de secuencia alternativo que muestra claramente el cambio de estado en una línea de vida con una escala de tiempo específica. Puede resultar muy útil en varias aplicaciones en tiempo real.

¿Cuales son los beneficios?

Cabe destacar varias ventajas que distinguen al diagrama de uso de UML de otros:

• El lenguaje está orientado a objetos, por lo que las tecnologías para describir los resultados del análisis y diseño realizado son semánticamente cercanas a los métodos de programación en todo tipo de lenguajes orientados a objetos de tipo moderno.
• Con este lenguaje se puede describir el sistema desde casi cualquier punto de vista posible, y de la misma forma se describen varios aspectos de su comportamiento.
• Todos los diagramas son relativamente fáciles de leer, incluso después de una familiaridad relativamente rápida con su sintaxis.
• UML le permite expandirse, así como introducir sus propios estereotipos gráficos y textuales, lo que contribuye a su uso no solo en la ingeniería de software.
• El idioma se ha generalizado bastante y también se está desarrollando de forma bastante activa.

desventajas

A pesar de que la construcción de diagramas UML tiene muchas de sus ventajas, a menudo son criticados por las siguientes deficiencias:

• Redundancia. En la gran mayoría de los casos, los críticos dicen que el UML es demasiado grande y complejo y, a menudo, esto no está justificado. Incluye una gran cantidad de construcciones y diagramas redundantes o prácticamente inútiles, y la mayoría de las veces esa crítica se dirige a la segunda versión, y no a la primera, porque en las revisiones más recientes hay más compromisos "desarrollados por el comité".
• Varias inexactitudes semánticas. Debido a que UML se define mediante una combinación de sí mismo, inglés y OCL, carece de la rigidez inherente a los lenguajes definidos con precisión por la técnica de descripción formal. En ciertas situaciones, la sintaxis abstracta de OCL, UML e inglés comienzan a contradecirse, mientras que en otros casos son incompletas. La descripción inexacta del lenguaje en sí afecta tanto a los usuarios como a los proveedores de herramientas, lo que en última instancia conduce a la incompatibilidad de las herramientas debido a la forma única de interpretar las diferentes especificaciones.
• Problemas en el proceso de implementación y estudio. Todos los problemas anteriores crean ciertas dificultades en el proceso de introducción y aprendizaje de UML, y esto es especialmente cierto cuando el liderazgo obliga a los ingenieros a usarlo a la fuerza, mientras no tienen habilidades previas.
• El código refleja el código. Otra opinión es que no son los modelos bonitos y atractivos lo que importa, sino los sistemas de trabajo en sí mismos, es decir, el código es el proyecto. De acuerdo con este punto de vista, es necesario desarrollar una forma más eficiente de escribir software. El UML es apreciado por enfoques que compilan modelos para regenerar código fuente o ejecutable. Pero en realidad, esto puede no ser suficiente, porque el lenguaje carece de las propiedades de completitud de Turing, y cada código generado estará limitado en última instancia por lo que una herramienta de interpretación de UML puede asumir o definir.
• Falta de coincidencia de carga. Este término proviene de la teoría del análisis de sistemas para determinar la incapacidad de la entrada de un determinado sistema para percibir la salida de otro. Como en cualquier sistemas estándar notación, UML puede representar algunos sistemas de una manera más eficiente y concisa que otros. Así, el desarrollador se inclina más hacia aquellas soluciones que le resulten más cómodas para tejer todas las fortalezas del UML, así como otros lenguajes de programación. Este problema es más evidente en el caso de que el lenguaje de desarrollo no cumpla con los principios básicos de la doctrina ortodoxa orientada a objetos, es decir, no intenta trabajar de acuerdo con los principios de la POO.
• Intenta ser versátil. UML es un lenguaje de modelado de propósito general que busca ser compatible con cualquier lenguaje de procesamiento disponible en la actualidad. En el contexto de un proyecto específico, para que el equipo de diseño pueda lograr el objetivo final, es necesario seleccionar las capacidades aplicables de ese idioma. Además, las posibles formas de acotar el alcance del UML en un área determinada pasan por un formalismo que no está del todo formulado, pero que en sí mismo es objeto de críticas.

Por tanto, el uso de este lenguaje no es relevante en todas las situaciones.

UML o Unified Modeling Language es un lenguaje de descripción gráfica para el modelado de objetos en el desarrollo de software. Pero el uso de UML no se limita a TI, otra gran área de aplicación práctica de UML es el modelado de procesos de negocios, la ingeniería de sistemas y el mapeo de estructuras organizacionales. UML permite a los desarrolladores de software llegar a un acuerdo sobre la notación gráfica para representar conceptos generales y concentrarse en el diseño y el desarrollo.

Ventajas de UML

• El UML usa símbolos gráficos para los elementos del sistema que se modela, y los diagramas UML son lo suficientemente simples de entender;
• El UML permite describir sistemas desde casi todos los puntos de vista concebibles, teniendo en cuenta diferentes aspectos;
• UML está orientado a objetos: sus métodos de análisis y construcción son semánticamente cercanos a los métodos de programación usados ​​en los lenguajes POO modernos;
• UML es un estándar abierto. El estándar se desarrolla y evoluciona de versión en versión, cumpliendo con los requisitos más modernos para la descripción de sistemas;
• contiene un mecanismo de extensión que permite la introducción de textos y tipos de gráficos adicionales, lo que hace posible el uso del UML no solo en el campo de las tecnologías de la información.

Tipos de diagramas UML

Hay 14 tipos de diagramas en UML. Se pueden dividir en 2 categorías:

• estructural representando estructura de la información;
• conductual que representa el comportamiento del sistema y varios aspectos de las interacciones. Se considera una subespecie separada de diagramas de comportamiento. diagramas de interacción.

Jerarquía de tipo de diagrama UML,
representado por el diagrama de clases

Diagramas estructurales

1. Diagrama de clase es un elemento clave en el modelado orientado a objetos. Con la ayuda de este diagrama (de hecho, a través de clases, su atributos, métodos y dependencias entre clases) describe el modelo de dominio y la estructura del sistema modelado.
2. Diagrama de componentes muestra el desglose del código del programa en bloques grandes (componentes estructurales) y muestra dependencias entre ellos. Los componentes pueden ser paquetes, módulos, bibliotecas, archivos, etc.
3. Diagrama de objetos muestra un corte completo o parcial del sistema modelado en un momento dado en el tiempo. Representa instancias de clase (objetos), su estado (valores de atributo actuales) y las relaciones entre ellos.
4. Diagrama de estructura compuesta Demuestra la estructura interna de clases y, si es posible, las interacciones entre los elementos de esta estructura.
5. Diagrama del paquete muestra paquetes y relaciones entre ellos. Este tipo de diagramas sirve para simplificar la estructura del modelo (y, en consecuencia, trabajar con él) combinando los elementos del modelo en grupos según ciertos criterios.
6. Diagrama de implementación simula el despliegue de componentes de software ( artefactos) sobre recursos informáticos / componentes de hardware ( nodos).
7. Diagrama de perfil describe un mecanismo de extensión que permite que UML se adapte a una variedad de dominios e industrias.

Ejemplo de diagrama de clases UML

Diagramas de comportamiento

1. Diagrama de actividad muestra acciones ( comportamiento) de los cuales alguna actividad ( actividad). Los diagramas de actividad se utilizan para modelar procesos comerciales, flujos de trabajo, computación secuencial y paralela.
2. Use el diagrama del caso(o use el diagrama del caso) describe la relación entre los actores (personajes) y los casos de uso del sistema modelado (sus capacidades). El objetivo principal de un diagrama es ser una ventanilla única para que los clientes, desarrolladores y usuarios finales discutan de forma colaborativa un sistema: sus capacidades y comportamiento.
3. Diagrama de estado describe el comportamiento dinámico de una entidad, mostrando cómo esta entidad, dependiendo de su estado actual, reacciona a varios eventos. Este es esencialmente un diagrama de estados de la teoría de los átomos.
4. Diagrama de comunicación(en versiones anteriores diagrama de cooperación) muestra las interacciones entre las partes de la estructura compuesta y los roles de la colaboración. El diagrama indica claramente la relación entre elementos (objetos).
5. Diagrama de secuencia utilizado para visualizar una secuencia de interacciones de objetos. Muestra el ciclo de vida de un objeto dado y la interacción de los actores (actores) dentro de un caso de uso, la secuencia de mensajes que intercambian.
6. Cuadro de descripción general de la interacción incluye una parte del diagrama de secuencia y las construcciones de flujo de control. Ayuda a considerar la interacción de objetos desde diferentes puntos de vista.
7. Diagrama de sincronizacion- un subtipo separado de diagramas de interacción, especializado en sincronización. Los diagramas de este tipo se utilizan para estudiar el comportamiento de los objetos durante un cierto período de tiempo.

UML es ahora la notación estándar para el modelado visual de sistemas de software, adoptada por Object Managing Group (OMG) en el otoño de 1997, y es compatible con muchos productos CASE orientados a objetos.

El estándar UML ofrece el siguiente conjunto de diagramas para modelar:

· Diagrama de casos de uso: para modelar los procesos comerciales de una organización o empresa y determinar los requisitos para el sistema de información que se está creando;

· Diagrama de clases (diagrama de clases): para modelar la estructura estática de las clases del sistema y las conexiones entre ellas;

Diagramas de comportamiento

· Diagramas de interacción;

· Diagramas de secuencia: para simular el proceso de intercambio de mensajes entre objetos dentro de un solo caso de uso;

· Diagrama de colaboración: para modelar el proceso de mensajería entre objetos dentro de un caso de uso;

· Diagrama de estado: para modelar el comportamiento de los objetos del sistema durante la transición de un estado a otro;

· Diagrama de actividad: para modelar el comportamiento del sistema en el marco de varios casos de uso o actividades de modelado;

Diagramas de implementación:

Diagramas de componentes: para modelar la jerarquía de componentes (subsistemas) de un sistema de información;

· Diagrama de implementación: para modelar la arquitectura física del sistema de información diseñado.

En la Fig. 1.1 presenta un modelo integrado del sistema de información, incluyendo los esquemas básicos que se deben desarrollar en este proyecto de curso.

Arroz. 1. Un modelo integrado de un sistema de información en la notación del lenguaje UML

4.2. Use el diagrama del caso

Un caso de uso es una secuencia de acciones realizadas por el sistema en respuesta a un evento desencadenado por algún objeto externo (actor). Un caso de uso describe una interacción típica entre un usuario y un sistema. En el caso más simple, el caso de uso se determina discutiendo con el usuario las funciones que le gustaría implementar en un sistema de información dado. En UML, un caso de uso se describe de la siguiente manera:

Figura 2. Caso de uso

Actor es el rol que juega el usuario en relación al sistema. Los actores representan roles, no personas específicas o títulos de trabajo. Aunque se muestra como figuras humanas estilizadas en diagramas de casos de uso, el actor también puede ser externo. sistema de informacion que necesita información de este sistema. Muestre actores en su diagrama solo cuando realmente necesiten algunos casos de uso. En UML, los actores se representan como formas:

Fig. 3. Actor (actor)

Hay tres tipos principales de actores:

· Usuarios;

· Sistemas;

· Otros sistemas que interactúan con esto;

El tiempo se convierte en actor si de él depende el lanzamiento de cualquier evento en el sistema.

4.2.1. Relaciones entre casos de uso y actores

En UML, los diagramas de casos de uso admiten varios tipos de relaciones entre los elementos del diagrama:

Comunicación,

Inclusión (incluir),

Extensión (extender),

Generalización.

Enlace de comunicación Es la relación entre el caso de uso y el actor. En UML, los enlaces de comunicación se muestran mediante una asociación unidireccional (línea continua).

Figura 4. Ejemplo de enlace de comunicación

Enlace de inclusión se aplica en situaciones en las que hay una parte del comportamiento del sistema que se repite en más de un caso de uso. Estos enlaces se utilizan normalmente para modelar una función reutilizable.

Enlace de extensión se utiliza para describir cambios en el comportamiento normal de un sistema. Permite utilizar un caso de uso funcionalidad otro caso de uso.

Figura 5. Ejemplo de conexión de inclusión y extensión

Enlace de generalización indica que varios actores o clases tienen propiedades comunes.

Figura 6. Ejemplo de enlace de generalización

4.3.

Diagramas de interacción describir el comportamiento de grupos de objetos que interactúan. Normalmente, un diagrama de interacción cubre el comportamiento de los objetos dentro de un solo caso de uso. Dicho diagrama muestra una serie de objetos y los mensajes que intercambian entre sí.

Mensaje Es el medio por el cual el objeto remitente solicita al objeto destinatario que realice una de sus operaciones.

Mensaje informativo Es un mensaje que proporciona al objeto destinatario alguna información para actualizar su estado.

Mensaje de solicitud (interrogativo) Es un mensaje que solicita la emisión de alguna información sobre el objeto destinatario.

Mensaje imperativo Es un mensaje que le pide al destinatario que realice alguna acción.

Hay dos tipos de diagramas de interacción: diagramas de secuencia y diagramas de colaboración.

4.3.1. Diagramas de secuencia

Diagrama de secuencia refleja el flujo de eventos que ocurren dentro de un solo caso de uso.

Todos los actores (actores, clases u objetos) involucrados en un escenario dado (caso de uso) se muestran en la parte superior del diagrama. Las flechas corresponden a los mensajes que se pasan entre un actor y un objeto, o entre objetos para realizar las funciones requeridas.

En un diagrama de secuencia, un objeto se dibuja como un rectángulo con una línea punteada vertical dibujada hacia abajo. Esta línea se llama la línea de vida de un objeto ... Es un fragmento del ciclo de vida de un objeto en proceso de interacción.

Cada mensaje se representa como una flecha entre las líneas de vida de dos objetos. Los mensajes aparecen en el orden que se muestra en la página, de arriba a abajo. Cada mensaje está etiquetado con al menos el nombre del mensaje. Opcionalmente, puede agregar argumentos y también información de control. Puede mostrar la autodelegación: un mensaje que un objeto se envía a sí mismo, con la flecha del mensaje apuntando a la misma línea de vida.

Arroz. 7. Ejemplo de diagrama de secuencia

4.3.2. Diagrama de colaboración

Diagramas de cooperación mostrar el flujo de eventos dentro de un escenario específico (caso de uso). Los mensajes se ordenan por tiempo, aunque los diagramas de colaboración se centran más en las relaciones entre objetos. Un diagrama de colaboración representa toda la información que contiene un diagrama de secuencia, pero un diagrama de colaboración describe el flujo de eventos de manera diferente. Facilita la comprensión de las conexiones que existen entre los objetos.

En el diagrama de cooperación, como en el diagrama de secuencia, las flechas indican los mensajes intercambiados dentro del marco. esta opción usar. Su secuencia temporal está indicada por la numeración de mensajes.

Arroz. 8. Ejemplo de diagrama de cooperación

4.4. Diagrama de clase

4.4.1. Información general

Diagrama de clase define los tipos de clases del sistema y varios tipos de enlaces estáticos que existen entre ellos. Los diagramas de clases también representan atributos de clase, operaciones de clase y restricciones que se aplican a las relaciones entre clases.

Un diagrama de clases UML es un gráfico, cuyos nodos son elementos de la estructura estática del proyecto (clases, interfaces) y los arcos son las relaciones entre nodos (asociaciones, herencia, dependencias).

El diagrama de clases muestra los siguientes elementos:

· Paquete: un conjunto de elementos del modelo que están relacionados lógicamente entre sí;

· Clase: descripción de las propiedades generales de un grupo de objetos similares;

· La interfaz es una clase abstracta que define un conjunto de operaciones que un objeto de una clase arbitraria asociada con esta interfaz proporciona a otros objetos.

4.4.2. Clase

Clase es un grupo de entidades (objetos) que tienen propiedades similares, a saber, datos y comportamiento. Un representante individual de una clase se denomina objeto de clase o simplemente objeto.

El comportamiento de un objeto en UML se entiende como cualquier regla para la interacción de un objeto con el mundo exterior y con los datos del propio objeto.

En los diagramas, la clase se representa como un rectángulo con un borde sólido, dividido por líneas horizontales en 3 secciones:

La sección superior (sección de nombre) contiene el nombre de la clase y otras propiedades generales (en particular, el estereotipo).

La sección central contiene una lista de atributos.

En la parte inferior hay una lista de operaciones de clase que reflejan su comportamiento (acciones realizadas por la clase).

Es posible que no se muestre ninguna de las secciones de atributos y operaciones (así como las dos a la vez). Para una sección que falta, no es necesario trazar una línea divisoria e indicar de alguna manera la presencia o ausencia de elementos en ella.

Se pueden introducir secciones adicionales, como Excepciones, a discreción de una implementación en particular.

Arroz. 9. Ejemplo de diagrama de clases

4.4.2.1.Estereotipos de clase

Los estereotipos de clase son un mecanismo para categorizar clases.

Hay tres estereotipos de clase principales definidos en UML:

Perímetro

Entidad

Control.

4.4.2.2.Clases de límites

Las clases de límite son clases que se encuentran en el límite del sistema y de todo el entorno. Se trata de pantallas, informes, interfaces con hardware (como impresoras o escáneres) e interfaces con otros sistemas.

Para encontrar las clases de límites, debe examinar los diagramas de casos de uso. Para cada interacción entre un actor y un caso de uso, debe haber al menos una clase de límite. Es esta clase la que permite al actor interactuar con el sistema.

4.4.2.3.Clases de entidad

Las clases de entidad contienen información almacenada. Son de suma importancia para el usuario y, por lo tanto, a menudo usan términos del área temática en sus nombres. Normalmente, para cada clase de entidad, se crea una tabla en la base de datos.

4.4.2.4.Clases de control

Las clases de control se encargan de coordinar las acciones de otras clases. Normalmente, cada caso de uso tiene una clase de control que controla la secuencia de eventos para ese caso de uso. La clase controladora es responsable de la coordinación, pero no tiene ninguna funcionalidad en sí misma, ya que las otras clases no le envían muchos mensajes. En cambio, él mismo envía muchos mensajes. La clase de administrador simplemente delega la responsabilidad a otras clases, por esta razón a menudo se la denomina clase de administrador.

Puede haber otras clases de control en el sistema que sean comunes a múltiples casos de uso. Por ejemplo, puede haber una clase SecurityManager que sea responsable de monitorear los eventos de seguridad. La clase TransactionManager es responsable de coordinar los mensajes relacionados con las transacciones de la base de datos. Puede haber otros administradores que se ocupen de otros elementos de la operación del sistema, como el intercambio de recursos, el procesamiento de datos distribuidos o el manejo de errores.

Además de los estereotipos mencionados anteriormente, puede crear los suyos propios.

4.4.2.5.Atributos

Un atributo es un dato asociado a una clase. Los atributos almacenan datos de clase encapsulados.

Dado que los atributos están contenidos dentro de la clase, están ocultos para otras clases. Por lo tanto, es posible que deba especificar qué clases pueden leer y modificar atributos. Esta propiedad se denomina visibilidad de atributo.

Un atributo puede tener cuatro valores posibles para este parámetro:

Público (general, abierto). Este valor de visibilidad supone que el atributo será visible para todas las demás clases. Cualquier clase puede ver o cambiar el valor del atributo. En notación UML, el atributo común está precedido por un signo "+".

Privado (cerrado, secreto). El atributo correspondiente no es visible para ninguna otra clase. Un atributo privado se indica con un "-" según la notación UML.

Protegido Tal atributo está disponible solo para la propia clase y sus descendientes. La notación UML para un atributo protegido es el signo "#".

Paquete o implementación Asume que atributo dado es común, pero solo dentro de su paquete. Este tipo de visibilidad no está indicado por ningún icono especial.

Con la ayuda de la cercanía o la seguridad, es posible evitar una situación en la que todas las clases del sistema cambian el valor de un atributo. En cambio, la lógica para modificar un atributo se incluirá en la misma clase que el propio atributo. Los parámetros de visibilidad que establezca afectarán el código generado.

4.4.2.6.Operaciones

Las operaciones implementan un comportamiento específico de la clase. Una operación tiene tres partes: nombre, parámetros y tipo de retorno.

Los parámetros son los argumentos recibidos por la operación de "entrada". El tipo de retorno se refiere al resultado de la acción de la operación.

En un diagrama de clases, puede mostrar tanto los nombres de las operaciones como los nombres de las operaciones junto con sus parámetros y el tipo de retorno. Para reducir la carga de trabajo del diagrama, es útil mostrar solo los nombres de las operaciones en algunas de ellas y en otras su firma completa.

En UML, las operaciones tienen la siguiente notación:

Nombre de la operación (argumento: tipo de datos del argumento, argumento 2: tipo de datos del argumento 2, ...): tipo de retorno

Hay cuatro tipos diferentes de transacciones a considerar:

Operaciones de implementación;

Operaciones de control;

Operaciones de acceso;

Operaciones auxiliares.

Operaciones de implementación

Las operaciones del implementador implementan algunas funciones comerciales. Estas operaciones se pueden encontrar examinando los diagramas de interacción. Los diagramas de este tipo se centran en las funciones comerciales y es muy probable que cada mensaje del diagrama se asocie con una operación de implementación.

Cada paso de implementación debe ser fácilmente rastreable hasta el requisito correspondiente. Esto se logra en varias etapas de la simulación. La actividad se deriva de un mensaje en un diagrama de interacción, los mensajes se derivan de Descripción detallada un flujo de eventos que se genera en función del caso de uso y este último se genera en función de los requisitos. La capacidad de rastrear toda esta cadena garantiza que todos los requisitos se implementen en el código y que cada parte del código implemente un requisito.

Operaciones de control

Las operaciones del administrador controlan la creación y destrucción de objetos. Los constructores y destructores de clases entran en esta categoría.

Operaciones de acceso

Los atributos suelen ser privados o protegidos. Sin embargo, otras clases a veces necesitan ver o cambiar sus valores. Hay operaciones de acceso para esto. Este enfoque hace posible encapsular de forma segura los atributos dentro de una clase, protegiéndolos de otras clases, pero aún permite el acceso controlado a ellos. Es una práctica estándar crear operaciones Get y Set para cada atributo de clase.

Operaciones auxiliares

Las operaciones auxiliares son aquellas operaciones de una clase que necesita para cumplir con sus responsabilidades, pero de las que otras clases no deberían saber nada. Estas son operaciones privadas y protegidas de la clase.

Para identificar transacciones, siga estos pasos:

1. Explore los diagramas de secuencia y los diagramas cooperativos. La mayoría de los mensajes de estos diagramas son actividades de implementación. Los mensajes reflectantes serán operaciones auxiliares.

2. Considere las operaciones de control. Es posible que deba agregar constructores y destructores.

3. Considere las operaciones de acceso. Para cada atributo de clase con el que otras clases necesitarán trabajar, debe crear operaciones Get y Set.

4.4.2.7.Conexiones

Una relación es una relación semántica entre clases. Permite que una clase aprenda sobre los atributos, operaciones y relaciones de otra clase. En otras palabras, para que una clase pueda enviar un mensaje a otra en un diagrama de secuencia o un diagrama cooperativo, debe haber una relación entre los dos.

Hay cuatro tipos de relaciones que se pueden establecer entre clases: asociaciones, dependencias, agregaciones y generalizaciones.

Asociación de comunicación

La asociación es el vínculo semántico entre clases. Se dibujan en el diagrama de clases como una línea ordinaria.

Arroz. 10. Asociación de comunicación

Las asociaciones pueden ser bidireccionales, como en el ejemplo, o unidireccionales. En UML, las asociaciones bidireccionales se dibujan como una línea simple sin flechas o con flechas a cada lado. En una asociación unidireccional, solo se representa una flecha que muestra su dirección.

La dirección de la asociación se puede determinar examinando los diagramas de secuencia y los diagramas cooperativos. Si todos los mensajes que se les envían son enviados por una sola clase y son recibidos solo por otra clase, pero no al revés, se produce una relación unidireccional entre estas clases. Si se envía al menos un mensaje a reverso, la asociación debe ser bidireccional.

Las asociaciones pueden ser reflexivas. La asociación reflexiva asume que una instancia de una clase interactúa con otras instancias de la misma clase.

Adicción a la comunicación

Las relaciones de dependencia también reflejan la relación entre clases, pero siempre son unidireccionales y muestran que una clase depende de las definiciones hechas en la otra. Por ejemplo, la clase A usa métodos de la clase B. Luego, cuando la clase B cambia, debe realizar los cambios correspondientes en la clase A.

La dependencia se representa como una línea discontinua entre dos elementos del gráfico, y el elemento anclado al final de la flecha se considera dependiente del elemento anclado al comienzo de esa flecha.

Arroz. 11. Adicción a la comunicación

Al generar código para estas clases, no se les agregarán nuevos atributos. Sin embargo, se generarán las declaraciones específicas del idioma necesarias para respaldar la comunicación.

Agregar un link

Las agregaciones son una forma más estrecha de asociación. La agregación es una conexión entre un todo y una parte de él. Por ejemplo, puede tener una clase para Automóvil, así como clases para Motor, Neumáticos y clases para otras partes del automóvil. Como resultado, un objeto de la clase Car constará de un objeto de la clase Engine, cuatro objetos de Tires, etc. Las agregaciones se visualizan como una línea con un diamante para una clase que es un todo:

Arroz. 11. Agregación de comunicaciones

Además de la agregación simple, UML introduce una forma más fuerte de agregación llamada composición. Según la composición, una parte objeto solo puede pertenecer a un todo único y, además, por regla general, el ciclo de vida de las partes coincide con el ciclo del todo: viven y mueren con él. Cualquier remoción del todo se extiende a sus partes.

Esta eliminación en cascada se considera a menudo como parte de la definición de agregación, pero siempre está implícita cuando la multiplicidad de roles es 1..1; por ejemplo, si es necesario eliminar un Cliente, esta eliminación debe aplicarse a los Pedidos (y, a su vez, a las Líneas de Pedido).

UML es un acrónimo de Unified Modeling Language. De hecho, es una de las técnicas de modelado de procesos de negocios más populares y es una notación estándar internacional para especificar, visualizar y documentar el desarrollo de software. Definido por Object Management Group, surgió como resultado de varios sistemas de notación UML adicionales y ahora se ha convertido en el estándar de facto para el modelado visual. El principio fundamental de cualquier programación orientada a objetos comienza con la construcción de un modelo.

El UML se creó a partir del caos en torno al desarrollo y la documentación de software. En la década de 1990, hubo varios diferentes caminos representaciones de sistemas de software. Había una necesidad de una forma UML visual más unificada de representar estos sistemas y, como resultado, fue desarrollado en 1994-1996 por tres ingenieros de software que trabajaban en Rational Software. Más tarde se adoptó como estándar en 1997 y sigue siéndolo, con solo algunas actualizaciones.

Básicamente, UML es un lenguaje de modelado de propósito general en el campo del desarrollo de software. Sin embargo, ahora se refleja en la documentación de varios procesos comerciales o de flujo de trabajo, como los diagramas de actividad. Los diagramas de tipo UML se pueden utilizar como reemplazo de los diagramas de flujo. Proporcionan una forma más estandarizada de modelar flujos de trabajo y una amplia gama de funciones para mejorar la legibilidad y la eficiencia.

La arquitectura se basa en un metaobjeto que define la base para la creación de UML. Es lo suficientemente preciso como para crear una aplicación completa. El UML totalmente ejecutable se puede implementar en múltiples plataformas utilizando diferentes tecnologías con todos los procesos a lo largo del ciclo de desarrollo de software.

UML está destinado al desarrollo de un lenguaje de modelado visual por parte de los usuarios. Admite conceptos de diseño de alto nivel como estructuras, plantillas y colaboración. UML es una colección de elementos como:

1. Declaraciones del lenguaje de programación.
2. Actores: describe el papel que desempeña el usuario o cualquier otro sistema que interactúe con el objeto.
3. Actividades a realizar para la ejecución del contrato de obra y presentadas en esquemas.
4. Un proceso de negocio que incluye un conjunto de tareas que crean un servicio específico para los clientes, visualizado por un diagrama de flujo de acciones secuenciales.
5. Componentes de software lógicos y reutilizables.

Los diagramas UML se dividen en dos categorías. El primer tipo incluye siete tipos de diagramas que representan información estructural, el segundo incluye los otros siete que representan tipos comunes de comportamiento. Estos diagramas se utilizan para documentar la arquitectura de sistemas y están directamente involucrados en el modelado de sistemas UML.

Los diagramas UML se presentan como vistas estáticas y dinámicas del modelo del sistema. La vista estática incluye diagramas de estructura compuesta y de clases que enfatizan la estructura estática. Una vista dinámica representa la interacción entre los objetos y los cambios en los estados internos de los objetos utilizando diagramas de secuencia, actividad y estado.

Hay disponible una amplia variedad de herramientas de modelado UML para simplificar el modelado, incluidas IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner y Dia.

UML se utiliza de diferentes formas, tanto en la documentación de desarrollo de software como en los procesos de negocio:

1. Bosquejo. En este caso, los diagramas UML se utilizan para transmitir varios aspectos y características del sistema. Sin embargo, esto es solo una representación. nivel superior sistema y muy probablemente no incluirá todos los detalles necesarios para completar el proyecto hasta el final.
2. Diseño avanzado: el diseño del boceto se realiza antes de codificar la aplicación. Esto es para proporcionar una mejor descripción general del sistema o flujo de trabajo que el usuario está intentando crear. Se pueden identificar muchos problemas o fallas de diseño, lo que mejorará la salud y el bienestar general del proyecto.
3. Diseño inverso. Una vez que se escribe el código, los diagramas UML aparecen como una forma de documentación para diferentes actividades, roles, participantes y flujos de trabajo.
4. Plano. En este caso, el diagrama sirve como una construcción completa, que requiere solo la implementación real del sistema o software. Esto se hace a menudo utilizando herramientas CASE (herramientas de ingeniería de software asistidas por computadora). La principal desventaja de utilizar las herramientas CASE es que requieren un cierto nivel de conocimiento, formación de usuarios, gestión y personal.

UML no es un lenguaje de programación independiente como Java, C ++ o Python; sin embargo, con las herramientas adecuadas puede convertirse en un pseudo UML. Para lograr este objetivo, todo el sistema debe estar documentado en diferentes diagramas y, utilizando el software adecuado, los diagramas se pueden traducir directamente a código. Esta técnica solo puede ser útil si el tiempo dedicado a dibujar los gráficos requiere menos tiempo que escribir el código real. Aunque UML se creó para el modelado de sistemas, ha encontrado varios usos en áreas comerciales.

A continuación se muestra un diagrama UML de ejemplo para el modelado de negocios.

Una solución práctica sería visualizar el flujo del proceso de televentas a través de un diagrama de actividad. Desde el momento en que se toma el pedido como entrada, hasta el momento en que se completa el pedido y se da una salida específica.

Hay varios tipos de diagramas UML y cada uno realiza una tarea diferente, ya sea que se desarrolle antes o después de la implementación, como parte de la documentación. Las dos categorías más amplias, que abarcan todos los demás tipos, son el diagrama de comportamiento y el diagrama de estructura. Como sugiere el nombre, algunos diagramas UML intentan analizar y representar la estructura de un sistema o proceso, mientras que otros describen el comportamiento de un sistema, sus participantes y componentes.

Los diferentes tipos se desglosan de la siguiente manera:

1. No todos los 14 tipos diferentes de diagramas UML se utilizan de forma regular al documentar sistemas y arquitecturas.
2. El principio de Pareto también se aplica al uso de diagramas UML.
3. Los desarrolladores utilizan el 20% de los gráficos el 80% del tiempo.

Los elementos más utilizados en el desarrollo de software son:

• diagramas de uso;
• diagramas de clases;
• secuencia.

Los diagramas de acción son los diagramas UML más importantes para crear modelos de procesos comerciales. En el desarrollo de software, se utilizan para describir el flujo de diferentes acciones. Pueden ser secuenciales o paralelos. Describen objetos utilizados, consumidos o producidos como resultado de actividades y la relación entre diferentes actividades.

Todo lo anterior es importante para modelar los procesos de negocio que conducen de uno a otro, ya que están interconectados con un principio y un final claros. En un entorno empresarial, esto también se conoce como mapeo de procesos empresariales. Los actores principales son el autor, editor y editor. Entre los ejemplos de UML se incluyen los siguientes. Cuando un revisor revisa el borrador y decide que es necesario realizar algunos cambios. Luego, el autor revisa el borrador y lo devuelve nuevamente para analizar la descripción general.

Diagrama de uso

Piedra angular del sistema: se utiliza para analizar los requisitos para el nivel del sistema. Estos requisitos se expresan en diferentes casos de uso. Los tres componentes principales de un diagrama UML son:

1. Funcional: presentado como casos de uso.
2. Verbo que describe una acción.
3. Actores: para interactuar con el sistema. El actor puede ser usuarios, organizaciones o una aplicación externa. La relación entre los participantes está representada por flechas rectas.

Por ejemplo, para un gráfico de control de inventario. En este caso, hay un propietario, un proveedor, un gerente, un especialista en inventarios y un inspector de inventarios. Los contenedores redondos representan las acciones que realizan los actores. Posibles acciones: comprar y pagar existencias, comprobar la calidad de las existencias, devolverlas o distribuirlas.

Este tipo de diagrama es muy adecuado para mostrar el comportamiento dinámico entre los participantes de un sistema, simplificando su presentación sin reflejar los detalles de implementación.

Temporal

Los diagramas de tiempo UML se utilizan para representar relaciones de objetos cuando el enfoque depende del tiempo. Al mismo tiempo, no es interesante cómo los objetos interactúan o se cambian entre sí, pero el usuario quiere imaginar cómo actúan los objetos y los sujetos a lo largo de un eje de tiempo lineal.

Cada participante individual está representado a través de una línea de vida, que es esencialmente una línea que forma las etapas, a medida que el participante individual pasa de una etapa a la siguiente. La atención se centra en la duración de los eventos y los cambios que se producen en función de ellos.

Los componentes principales de una tabla de tiempos son:

1. Lifeline es un miembro individual.
2. Cronograma de estado: un solo camino de vida puede pasar por varios estados dentro de un proceso.
3. Restricción de duración: una restricción de intervalo de tiempo que representa la duración requerida para que se cumpla la restricción.
4. Límite de tiempo: limite el intervalo de tiempo durante el cual el participante debe hacer algo.
5. Apariencia de destrucción: la aparición de un mensaje que destruye a un participante individual y representa el final del ciclo de vida de ese participante.

Los diagramas horizontales, también llamados diagramas de estado, se utilizan para describir los diversos estados de un componente dentro de un sistema. Toma un formato de nombre final porque un diagrama es esencialmente una máquina que describe múltiples estados de un objeto y cómo cambia en función de eventos internos y externos.

Un diagrama de estado de máquina muy simple sería en un juego de ajedrez. Un juego de ajedrez típico consiste en movimientos hechos por blancas y movimientos hechos por negras. Las blancas tienen el primer movimiento, lo que inicia así el juego. El final del juego puede ocurrir independientemente de si ganan las blancas o las negras. El juego puede terminar en partido, renuncia o empate (diferentes condiciones de la máquina). Los gráficos de estado se utilizan principalmente en el diseño UML directo e inverso de varios sistemas.

Consecutivo

Este tipo de diagrama es el diagrama UML más importante no solo entre la comunidad informática, sino también como modelo de capa de diseño para desarrollar aplicaciones comerciales. Son populares para describir procesos comerciales debido a su naturaleza visualmente autoexplicativa. Como sugiere el nombre, los diagramas describen la secuencia de mensajes e interacciones que ocurren entre sujetos y objetos. Los actores u objetos solo pueden estar activos cuando sea necesario o cuando otro objeto quiera comunicarse con ellos. Todas las comunicaciones se presentan en orden cronológico.

Para obtener más información, consulte el diagrama de secuencia UML de ejemplo a continuación.

Como muestra el ejemplo, los diagramas de estructura se utilizan para mostrar la estructura de un sistema. Más específicamente, un lenguaje se usa en el desarrollo de software para representar la arquitectura de un sistema y cómo se interconectan los diferentes componentes.

El diagrama de clases UML es el tipo de diagrama más común para la documentación de software. Dado que la mayoría de los programas que se escriben actualmente todavía se basan en el paradigma de programación orientada a objetos, tiene sentido común utilizar diagramas de clases para documentar el software. Esto se debe a que OOP se basa en clases UML y las relaciones entre ellas. En pocas palabras, los gráficos contienen clases, junto con sus atributos, también llamados campos de datos, y su comportamiento, llamado funciones miembro.

Más específicamente, cada clase tiene 3 campos: nombre en la parte superior, atributos justo debajo del nombre, operaciones / comportamiento en la parte inferior. La relación entre las diversas clases (representadas por la línea de conexión) constituye un diagrama de clases. El ejemplo anterior muestra un diagrama de clases básico.

Objetos

Cuando se habla de diagramas estructurales UML, es necesario profundizar en los conceptos de ciencias de la computación. En el desarrollo de software, las clases se consideran tipos de datos abstractos, mientras que los objetos son instancias. Por ejemplo, si hay "Car", que es un tipo abstracto genérico, entonces una instancia de la clase "Car" sería "Audi".

Los diagramas de objetos UML ayudan a los desarrolladores de software a verificar si la estructura abstracta generada está generando una estructura viable cuando se implementa en la práctica, es decir, cuando se crean los objetos. Algunos desarrolladores consideran que esto es un nivel secundario de verificación de precisión. Muestra instancias de clases. Más precisamente, la clase genérica "Cliente" ahora tiene un cliente real, por ejemplo, llamado "James". James es una instancia de una clase más general y tiene los mismos atributos, sin embargo, con valores dados... Lo mismo se hizo con la Cuenta de Cuentas y Ahorros. Ambos son objetos de sus respectivas clases.

Despliegue

Los diagramas de implementación se utilizan para visualizar la relación entre el software y el hardware. Para ser más específico, con los diagramas de implementación, puede crear un modelo físico de cómo se implementan los componentes de software (artefactos) en los componentes de hardware conocidos como nodos.

Un patrón de implementación simplificado típico para una aplicación web incluiría:

1. Nodos (servidor de aplicaciones y servidor de bases de datos).
2. Esquema y base de datos de la aplicación cliente de artefactos.

El diagrama del paquete es similar a las macros para los diagramas de implementación de UML que explicamos anteriormente. Varios paquetes contienen nodos y artefactos. Agrupan diagramas y componentes del modelo en grupos, de manera muy similar a como un espacio de nombres encapsula diferentes nombres que están algo relacionados. En última instancia, varios otros paquetes también pueden crear un paquete para representar sistemas y comportamientos más complejos.

El propósito principal de un diagrama de paquetes es mostrar las relaciones entre los diversos componentes principales que componen un sistema complejo. Los programadores encuentran esta oportunidad de abstracción buena ventaja para usar diagramas de paquetes, especialmente cuando algunos detalles pueden quedar fuera de la imagen.

Como cualquier otra cosa en la vida, hacer algo bien requiere las herramientas adecuadas. Para documentar software, procesos o sistemas, utilice herramientas que ofrezcan anotaciones UML y plantillas de diagramas. Existen varias herramientas de documentación de software que pueden ayudarlo a dibujar un diagrama.

Por lo general, se incluyen en las siguientes categorías principales:

1. El papel y la pluma son fáciles. Toman papel y bolígrafo, abren el código de sintaxis UML de Internet y dibujan cualquier tipo de diagrama que sea necesario.
2. Herramientas en línea: hay varias aplicaciones en línea que puede utilizar para crear su gráfico. La mayoría de ellos ofrecen suscripción paga o un número limitado de diagramas a nivel libre.
3. Las herramientas en línea gratuitas son casi las mismas que las pagas. La principal diferencia es que las de pago también ofrecen tutoriales y plantillas listas para usar para diagramas específicos.
4. Una aplicación de escritorio es una aplicación de escritorio típica que se usa para diagramas y casi cualquier otro diagrama es Microsoft Visio. Ofrece funciones y características avanzadas. El único inconveniente es que tienes que pagarlo.

Por lo tanto, está bastante claro que UML es un aspecto importante asociado con el desarrollo de software orientado a objetos. Utiliza notación gráfica para crear modelos visuales de programas del sistema.

UML es un lenguaje de modelado gráfico de propósito general para especificar, visualizar, diseñar y documentar todos los artefactos creados en el desarrollo de sistemas de software.

Hay muchos buenos libros que describen en detalle sobre UML (en algunos lugares incluso con gran detalle), me gustaría recopilar en un solo lugar los conceptos básicos sobre diagramas, entidades y conexiones entre ellos para recordarlos rápidamente, algo así como una hoja de trucos .

La nota utiliza materiales de libros: Ivanov D. Yu., Novikov F.A. Lenguaje de modelado unificado UML y Leonenkov. Tutorial de UML.

Primero, decidamos sobre el editor. En Linux, probé diferentes editores de UML, sobre todo me gustó UMLet, aunque está escrito en Java, se mueve muy rápido y la mayoría de las plantillas de entidad están en él. También está ArgoUML, un editor UML multiplataforma, también escrito en Java, funcionalmente rico, pero más lento.

Me acomodé en UMLet, ponlo debajo Arch Linux y Ubuntu:

# para Arch Linux yaourt -S umlet # Para Ubuntu sudo apt-get install umlet

En UML, todas las entidades se pueden dividir en los siguientes tipos:

• estructural;
• conductual
• agrupamiento;
• anotación;

Hay cuatro tipos principales de relaciones que se utilizan en UML:

Dependencia- indica que el cambio de entidad independiente afecta de alguna manera a la entidad dependiente. Gráficamente, una relación de dependencia se representa como una línea discontinua con una flecha que apunta desde la entidad dependiente a la entidad independiente.

Asociación- tiene lugar si una entidad está relacionada directamente con otra (o con otras; la asociación puede ser no solo binaria). Una asociación se representa gráficamente como una línea sólida con varias adiciones que conectan entidades relacionadas.

Generalización es una relación entre dos entidades, una de las cuales es un caso especial (especializado) de la otra. Gráficamente, la generalización se representa como una línea con una flecha triangular sin sombrear al final, dirigida de lo particular (subclase) a lo general (superclase).

Implementación- una relación de implementación indica que una entidad es una implementación de otra. Gráficamente, la implementación se representa como una línea discontinua con una flecha triangular sin sombrear al final, dirigida desde la entidad que realiza a la realizable.

V UML 2 se define 13 tipos de gráficos. Según los estándares, cada gráfico debe tener un cuadro con un rectángulo (esquina inferior derecha biselada) en la esquina superior izquierda, que indica el ID (etiqueta) y el título del gráfico.

Diagramas para representar la estructura del sistema.:

• Diagrama de componentes (etiqueta componente);
• Diagrama de implementación (etiqueta despliegue);
• Diagrama de clases (diagrama de clases, etiqueta clase);
• Diagrama de objeto (etiqueta objeto);
• Diagrama de estructura interna (diagrama de estructura compuesta, etiqueta clase);

Diagramas para representar el comportamiento del sistema:

• Diagrama de interacción (etiqueta momento);
• Diagrama de actividad (etiqueta actividad);
• Diagrama de secuencia (etiqueta Dakota del Sur);
• Diagrama de comunicación (etiqueta com);
• Diagrama de la máquina de estado (etiqueta máquina estatal);
• Etiqueta del diagrama de descripción general de la interacción Interacción);

Los diagramas se destacan:

• Diagrama de uso (diagrama de caso de uso, etiqueta de caso de uso);
• Diagrama del paquete (etiqueta paquete);

Diagrama de uso

Diagrama de uso(diagrama de casos de uso) es la representación más general del propósito funcional del sistema.

Si se considera un diagrama de casos de uso como modelo de un sistema, se puede asociar con un modelo de caja negra. Cada caso de uso define una secuencia de acciones que debe realizar el sistema diseñado cuando interactúa con el actor correspondiente.

El diagrama de uso utiliza dos tipos de entidades básicas: casos de uso y actores, entre los cuales se establecen los siguientes tipos básicos de relaciones.

Relación de asociación- Esta relación establece qué rol específico juega un actor al interactuar con una instancia de un caso de uso. Una relación de asociación se indica mediante una línea continua entre el actor y el caso de uso. Esta línea puede tener más leyenda, como nombre y cardinalidad.

Relación de expansión- define cómo las instancias de un caso de uso particular se relacionan con un caso de uso más general, cuyas propiedades se determinan en función de cómo se combinan estas instancias. Entonces, si hay una relación de extensión del caso de uso A con el caso de uso B, esto significa que las propiedades de la instancia del caso de uso B se pueden aumentar debido a la presencia de propiedades en el caso de uso extendido A.

Una relación de extensión entre casos de uso se indica mediante una línea discontinua con una flecha (caso de relación de dependencia) que apunta fuera del caso de uso que es una extensión del caso de uso original.

Relación de generalización sirve para indicar el hecho de que un determinado caso de uso A se puede generalizar al caso de uso B. En este caso, la opción A será una especialización de la opción B. En este caso, B se denomina ancestro o padre en relación con A, y la opción A es descendiente en relación con el uso de opciones de V.

Gráficamente, esta relación se indica mediante una línea sólida con una flecha triangular abierta que indica el caso de uso principal.

Se utiliza una relación de generalización entre casos de uso cuando es necesario tener en cuenta que los casos de uso secundarios tienen todos los atributos y comportamientos de los casos de uso principales.

Proporción de inclusión entre dos casos de uso indica que algún comportamiento especificado para un caso de uso se incluye como un componente compuesto en la secuencia de comportamiento del otro caso de uso.

La relación de inclusión del caso de uso A al caso de uso B indica que cada instancia de la opción A incluye la funcionalidad especificada para la opción B.

Gráficamente, esta relación se indica mediante una línea discontinua con una flecha (caso de relación de dependencia) que apunta desde el caso de uso base al caso de uso incluido.

Diagrama de clase

Diagrama de clase(diagrama de clases) es la forma principal de describir la estructura estática de un sistema.

En un diagrama de clases, se utiliza un tipo principal de entidades: clases (incluyendo numerosos casos especiales de clases: interfaces, tipos primitivos, clases de asociación, etc.), entre las cuales se establecen los siguientes tipos básicos de relaciones: dependencias, asociaciones, generalizaciones. , implementaciones.

Relación de adicción generalmente indica alguna relación semántica entre dos elementos del modelo o dos conjuntos de tales elementos que no es una relación de asociación, generalización o implementación. Una relación de dependencia se utiliza en una situación en la que algún cambio en un elemento del modelo puede requerir un cambio en otro elemento dependiente del modelo.

Una relación de dependencia se representa gráficamente con una línea de puntos entre los elementos correspondientes con una flecha en uno de sus extremos, con la flecha apuntando desde la clase de cliente de dependencia a la clase independiente o fuente.

Por encima de la flecha puede haber un especial palabras clave(estereotipos):

• "acceso": sirve para indicar la accesibilidad de los atributos públicos y las operaciones de la clase fuente para las clases cliente;
• "bind": la clase de cliente puede usar alguna plantilla para su parametrización posterior;
• "derivar": los atributos de la clase cliente se pueden calcular a partir de los atributos de la clase fuente;
• "importar": los atributos públicos y las operaciones de la clase fuente pasan a formar parte de la clase cliente, como si estuvieran declarados directamente en ella;
• "refinar": indica que la clase de cliente sirve como refinamiento de la clase de origen por razones históricas, cuando aparece información adicional mientras trabaja en un proyecto.

Relación de asociación corresponde a la existencia de alguna relación entre las clases. Esta relación se indica mediante una línea continua con caracteres especiales adicionales que caracterizan las propiedades individuales de una asociación en particular. Como adicional caracteres especiales se puede utilizar el nombre de la asociación, así como los nombres y la multiplicidad de las clases de roles de la asociación. El nombre de la asociación es un elemento opcional de su designación.

Relación de agregación tiene lugar entre varias clases en el caso de que una de las clases sea una determinada entidad que incluya a otras entidades como partes constituyentes. Se utiliza para representar las relaciones del sistema de parte a todo.

Relación de composición es un caso especial de una relación de agregación. Esta relación sirve para resaltar una forma especial de la relación "parte-todo", en la que las partes constituyentes, en cierto sentido, están dentro del todo. La especificidad de la relación entre ellos radica en el hecho de que las partes no pueden actuar aisladas del todo, es decir, con la destrucción del todo, se destruyen todas sus partes constituyentes.

Relación de generalización es una relación entre un elemento más general (padre o antepasado) y un elemento más privado o especial (hijo o descendiente). Cuando se aplica a un diagrama de clases, esta relación describe la estructura jerárquica de las clases y la herencia de sus propiedades y comportamiento. Esto supone que la clase descendiente tiene todas las propiedades y comportamiento de la clase antecesora, y también tiene sus propias propiedades y comportamiento que la clase antecesora no tiene.

Diagrama de autómata

Diagrama de autómata(diagrama de la máquina de estado) o diagrama de estado en UML 1 (diagrama de diagrama de estado) es una forma de describir el comportamiento en UML en detalle. En esencia, los diagramas de autómatas, como su nombre indica, son un gráfico de estados y transiciones de un autómata finito cargado con muchos detalles y detalles adicionales.

Un diagrama de estado describe el proceso de cambiar los estados de una sola clase, o más bien, una instancia de cierta clase, es decir, modela todos los cambios posibles en el estado de un objeto en particular. En este caso, un cambio en el estado de un objeto puede ser causado por influencias externas de otros objetos o del exterior. Es para describir la reacción de un objeto a tales influencias externas que se utilizan diagramas de estado.

En el diagrama de autómatas, se usa un tipo principal de entidad: estados y un tipo de relación: transiciones, pero para ambos se definen muchas variedades, casos especiales y notaciones adicionales. El autómata representa los aspectos dinámicos del sistema modelado en forma de grafo dirigido, cuyos vértices corresponden a estados y los arcos corresponden a transiciones.

Estado inicial es un caso especial de un estado que no contiene acciones internas (pseudo estados). El objeto predeterminado está en este estado en el momento inicial. Sirve para indicar en el diagrama de estados la zona de gráficos a partir de la cual comienza el proceso de transición de estados.

Final (final) un estado es un caso especial de un estado que tampoco contiene acciones internas (pseudo-estados). El objeto predeterminado estará en este estado después de que el autómata termine su trabajo en el momento final del tiempo.

Diagrama de actividad

Al modelar el comportamiento de un sistema diseñado o analizado, se hace necesario no solo representar el proceso de cambio de sus estados, sino también detallar las características de la implementación algorítmica y lógica de las operaciones realizadas por el sistema.

Diagrama de actividad(diagrama de actividad) es otra forma de describir el comportamiento que visualmente se asemeja al viejo diagrama de flujo del algoritmo. Se utiliza para simular el proceso de realización de operaciones.

La dirección principal del uso de diagramas de actividad es visualizar las peculiaridades de la implementación de operaciones de clase, cuando es necesario presentar algoritmos para su ejecución.

En el diagrama de actividad, se utiliza un tipo principal de entidad: acción, y un tipo de relación: transiciones (transferencias de control). También se utilizan construcciones como bifurcaciones, fusiones, uniones, ramas. Recomendado como nombre acción simple usar un verbo con palabras explicativas.

Diagrama de secuencia

Diagrama de secuencia(diagrama de secuencia) es una forma de describir el comportamiento del sistema "mediante ejemplos".

De hecho, un diagrama de secuencia es un registro de un protocolo de una sesión específica del funcionamiento del sistema (o un fragmento de dicho protocolo). En la programación orientada a objetos, el tiempo de ejecución más esencial es la transferencia de mensajes entre objetos en comunicación. Es la secuencia de envío de mensajes que se muestra en este diagrama, de ahí el nombre.

En el diagrama de secuencia, se utiliza un tipo principal de entidad: instancias de clasificadores que interactúan (principalmente clases, componentes y actores), y un tipo de relación: los enlaces a través de los cuales se intercambian los mensajes.

Posibles tipos de mensajes (imagen tomada de larin.in):

Diagrama de comunicación

Diagrama de comunicación(diagrama de comunicación) - una forma de describir el comportamiento, semánticamente equivalente a un diagrama de secuencia. De hecho, esta es la misma descripción de la secuencia de intercambio de mensajes de las instancias de clasificador que interactúan, solo expresada en otros medios gráficos.

Por lo tanto, en el diagrama de comunicación, así como en el diagrama de secuencia, se utiliza un tipo principal de entidad: instancias de clasificadores que interactúan y un tipo de relación: enlaces. Sin embargo, el énfasis aquí no está en el tiempo, sino en la estructura de los vínculos entre instancias específicas.

Diagrama de componentes

Diagrama de componentes(diagrama de componentes): muestra la relación entre los módulos (lógicos o físicos) que componen el sistema simulado.

El principal tipo de entidades en un diagrama de componentes son los propios componentes, así como las interfaces a través de las cuales se indica la relación entre los componentes. En un diagrama de componentes, se aplican las siguientes relaciones:

• implementaciones entre componentes e interfaces (un componente implementa una interfaz);
• dependencias entre componentes e interfaces (un componente usa una interfaz);

Diagrama de ubicación

Diagrama de ubicación(diagrama de implementación), además de mostrar la composición y las relaciones de los elementos del sistema, muestra cómo están ubicados físicamente en los recursos informáticos en tiempo de ejecución.

En el diagrama de ubicación, en comparación con el diagrama de componentes, se agregan dos tipos de entidades: un artefacto, que es la implementación de un componente y un nodo (puede ser un clasificador que describe el tipo de un nodo o una instancia específica ), así como una relación de asociación entre nodos, que muestra que los nodos están conectados físicamente en tiempo de ejecución.

Diagrama de objetos

Diagrama de objetos(diagrama de objeto): es una instancia de un diagrama de clases.

En el diagrama de objetos, se utiliza un tipo principal de entidad: objetos (instancias de clase), entre los cuales se indican relaciones específicas (más a menudo, instancias de asociación). Los diagramas de objetos son de naturaleza auxiliar; de hecho, son ejemplos (se podría decir, volcados de memoria) que muestran qué son los objetos y las conexiones entre ellos en algún momento específico del funcionamiento del sistema.

Diagrama de estructura interna(diagrama de estructura compuesta) se utiliza para una presentación más detallada de clasificadores estructurales, principalmente clases y componentes.

El clasificador estructural se representa como un rectángulo, en la parte superior del cual está el nombre del clasificador. Dentro están las partes. Puede haber varias partes. Las partes pueden interactuar entre sí. Esto se indica mediante conectores de varios tipos. La ubicación en el borde exterior de la pieza a la que se conecta el conector se llama puerto. Los puertos también se encuentran en el borde exterior del clasificador estructural.

Diagrama de descripción general de la interacción Un diagrama de descripción general de interacción es un tipo de diagrama de actividad con una sintaxis extendida: los enlaces de uso de interacción definidos por diagramas de secuencia pueden actuar como elementos de un diagrama de descripción general de interacción.

Diagrama de sincronizacion

Diagrama de sincronizacion(diagrama de tiempo) es una forma especial de diagrama de secuencia, en el que se presta especial atención a cambiar los estados de diferentes instancias de clasificadores y su tiempo.

Diagrama del paquete

Diagrama del paquete(diagrama de paquete) es la única herramienta que le permite gestionar la complejidad del modelo en sí.

Los elementos principales de la notación son paquetes y dependencias con diferentes estereotipos.

Modelo entidad-relación (modelo ER)

Término análogo diagramas de clases(UML) tal vez Modelo ER, que se utiliza en el diseño de bases de datos (modelo relacional).

El modelo entidad-relación (modelo ER) es un modelo de datos que le permite describir esquemas conceptuales del dominio. El modelo ER se utiliza en el diseño de bases de datos de alto nivel (conceptual). Con su ayuda, es posible resaltar las entidades clave y designar las conexiones que se pueden establecer entre estas entidades. wikipedia

Cualquier fragmento del área temática puede representarse como un conjunto de entidades, entre las cuales hay una serie de conexiones.

Conceptos básicos:

La esencia(entidad) es una entidad que puede identificarse de alguna manera que la distingue de otras entidades, por ejemplo CLIENTE 777... Una entidad es en realidad un conjunto de atributos.

Conjunto de entidades(conjunto de entidades): un conjunto de entidades del mismo tipo (con las mismas propiedades).

Conexión(relación) es una asociación establecida entre múltiples entidades.

Dominio(dominio): un conjunto de valores (alcance) de un atributo.

Hay tres tipos de enlaces binarios:

• doce y cincuenta y nueve de la noche- una sola instancia de una entidad de una clase está asociada con una sola instancia de una entidad de otra clase, por ejemplo, HEAD - DEPARTMENT;
• 1 a N o uno a muchos- una sola instancia de una entidad de una clase está asociada con muchas instancias de una entidad de otra clase, por ejemplo, DEPARTMENT - EMPLOYEE;
• N a M o muchos a muchos- muchas instancias de una entidad de una clase están asociadas con muchas instancias de una entidad de otra clase, por ejemplo, EMPLEADO - PROYECTO;
Un glosario de conceptos básicos de UML

Objeto- una entidad que es única y encapsula el estado y el comportamiento.

Clase- una descripción de un conjunto de objetos con atributos comunes que determinan el estado y las operaciones que determinan el comportamiento.

Interfaz- un conjunto de operaciones con nombre que define un conjunto de servicios que puede ser solicitado por un consumidor y proporcionado por un proveedor de servicios.

Colaboración- un conjunto de objetos que interactúan para lograr un objetivo.

Actor- una entidad que está fuera del sistema modelado e interactúa directamente con él.

Componente- una parte modular del sistema con un conjunto bien definido de interfaces necesarias y proporcionadas.

Artefacto- un elemento de información que se utiliza o genera en el proceso de desarrollo de software. En otras palabras, un artefacto es una unidad física de implementación que se deriva de un elemento del modelo (como una clase o un componente).

Nodo- un recurso informático en el que se ubican los artefactos y, si es necesario, se ejecutan.

Las entidades de comportamiento están destinadas a describir el comportamiento. Solo hay dos entidades conductuales básicas: estado y acción.

Estado- un período en el ciclo de vida de un objeto, siendo en el que el objeto satisface una determinada condición y realiza su propia actividad o espera la ocurrencia de algún evento.

Acción- Computación atómica primitiva.

Máquina es un paquete que define un conjunto de conceptos necesarios para representar el comportamiento de una entidad modelada en forma de un espacio discreto con un número finito de estados y transiciones.

Clasificador es un descriptor de un conjunto de objetos del mismo tipo.

Lectura adicional

• Fowler M. UML. Fundamentos, 3.ª edición
• Booch G., Rambeau D., Jacobson I. UML. Guía del usuario