hogar / Programas/ Diagramas básicos del lenguaje UML. Modelado UML

Diagramas básicos del UML. Modelado UML

UML o lenguaje de modelado unificado: un lenguaje de descripción gráfica para el modelado de objetos en desarrollo. 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 símbolos gráficos presentar conceptos generales y concentrarse en el diseño y 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 una versión a otra, respondiendo a la mayoría requisitos modernos a 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

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.
Diagrama de componentes muestra la división código de programa en grandes bloques (componentes estructurales) y muestra dependencias entre ellos. Los componentes pueden ser paquetes, módulos, bibliotecas, archivos, etc.
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.
Diagrama de estructura compuesta Demuestra la estructura interna de clases y, si es posible, las interacciones entre los elementos de esta estructura.
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 de acuerdo con ciertos criterios.
Diagrama de implementación simula el despliegue componentes de software ov artefactos) sobre recursos informáticos / componentes de hardware ( nodos).
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

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.
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 propósito principal de un diagrama es ser una ventanilla única para que los clientes, desarrolladores y usuarios finales discutan de manera colaborativa un sistema: sus capacidades y comportamiento.
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.
Diagrama de comunicación(v primeras versiones 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).
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.
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.
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.

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 usa varias notaciones gráficas 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. Tiene la intención de demostrar la división de un cierto sistema de software en una variedad de componentes estructurales, así como en las conexiones entre ellos. El 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 imagen completa o parcial. el 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

Un diagrama de actividad UML describe la descomposición de una actividad específica en varios 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 ofrece 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 la colaboración y el diagrama de secuencia, que brindan una oportunidad desde diferentes puntos de vista para considerar la interacción entre varios objetos en el sistema generado.

Diagrama de sincronizacion

Representa Opción alternativa un diagrama de secuencia que demuestra claramente el cambio de estado en la línea de vida con una línea 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 se acercan semánticamente 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 manera 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 estas críticas se dirigen a la segunda versión, y no a la primera, porque las revisiones más recientes contienen gran cantidad 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. Según esta opinión, es necesario desarrollar más método efectivo software de escritura. El UML es apreciado por enfoques que compilan modelos para regenerar ejecutables o código fuente... 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.

Modelo UML(Modelo UML) es una colección de un conjunto finito de construcciones de lenguaje, las principales de las cuales son entidades y relaciones entre ellas.

Las entidades y relaciones del modelo en sí mismas son instancias de las metaclases del metamodelo.

Considerando Modelo UML Desde el punto de vista más general, podemos decir que se trata de un gráfico (más precisamente, un multi-pseudo-hiper-dígrafo cargado) en el que los vértices y aristas se cargan con información adicional y pueden tener una estructura interna compleja. Los vértices de este gráfico se llaman entidades y los bordes son relaciones... El resto de la sección contiene un superficial (preliminar), pero descripción completa tipos de entidades y relaciones disponibles. Afortunadamente, no hay demasiados. En los siguientes capítulos del libro, todas las entidades y relaciones se consideran nuevamente, con más detalle y con ejemplos.

1.4.1. Entidades

Para facilitar la visualización, las entidades en UML se pueden subdividir en cuatro grupos:

estructural;
conductual
agrupamiento;
anotación.

Las entidades estructurales, como puede adivinar, están destinadas a describir la estructura. Normalmente, las entidades estructurales incluyen lo siguiente.

Un objeto(objeto) 1 es una entidad que es única y encapsula el estado y el comportamiento.

Clase(clase) 2: descripción de un conjunto de objetos con atributos comunes que determinan el estado y las operaciones que determinan el comportamiento.

Interfaz(interfaz) 3 es 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.

Cooperación(colaboración) 4 - una colección de objetos que interactúan para lograr un objetivo.

Actor(actor) 5 es una entidad que está fuera del sistema modelado e interactúa directamente con él.

∇ Ciertamente existe tal relación, que se expresa en la Fig. Jerarquía de tipos de diagrama para UML 1 como una relación de dependencia con un estereotipo refinado.

∇∇ En UML 1, surgió una asociación involuntaria entre un diagrama de cooperación y una entidad del mismo nombre, lo cual no era del todo cierto y en ocasiones engañoso.

∇∇∇ En UML 2, la carga sintáctica y semántica del diagrama de estado ha cambiado tanto que el nombre ya no refleja el contenido.

A continuación se muestra una lista de los nuevos gráficos y sus nombres utilizados en este libro.

Diagrama estructura interna(Diagrama de estructura compuesta)
Diagrama del paquete
Diagrama de la máquina de estado
Diagrama de comunicación
Diagrama de descripción general de la interacción
Diagrama de tiempo

En la Fig. Jerarquía de tipos de diagrama para UML 2 (Partes 1 y 2) es un diagrama de clases que muestra la relación de los diagramas en UML 2.

Más adelante en este capítulo describiremos muy brevemente los trece diagramas canónicos para tener un cierto contexto y vocabulario para una presentación posterior. Los detalles se exponen en los capítulos restantes del libro.

Pero antes de pasar a la siguiente sección, hagamos una pequeña digresión sobre cómo el estándar requiere que se formatee los diagramas. La plantilla de presentación del gráfico general se muestra a continuación.

Hay dos elementos principales de diseño: un marco exterior y una etiqueta con el nombre del diagrama. Si todo es simple con el marco: es un rectángulo que delimita el área en la que deben ubicarse los elementos del diagrama, entonces el nombre del diagrama se escribe en un formato especial, que se muestra en la Fig. Notación para gráficos.

La forma compleja indicada de la pestaña no es compatible con todas las herramientas. Sin embargo, esto no es necesario, ya que la semántica es primaria y la notación es secundaria. De ahora en adelante, usaremos un rectángulo como etiqueta para todo el diagrama, y esto no debería causar confusión.

Las posibles etiquetas (tipos) para gráficos se muestran en la siguiente tabla. Las etiquetas que ofrece el estándar están escritas en la segunda columna. Sin embargo, como ha demostrado la práctica, las reglas propuestas por la norma no siempre son convenientes y están fundamentadas lógicamente, por lo que la tercera columna de la tabla contiene una alternativa razonable en nuestra opinión.

Pestaña. Tipos de gráficos y etiquetas

Titulo del gráfico	Etiqueta (estándar)	Etiqueta (sugerida)
Diagrama de uso	caso de uso o uc	caso de uso
Diagrama de clase	clase	clase
Diagrama de autómata	máquina estatal o stm	máquina estatal
Diagrama de actividad	actividad o actuar	actividad
Diagrama de secuencia	Interacción o Dakota del Sur	Dakota del Sur
Diagrama de comunicación	Interacción o Dakota del Sur	comm
Diagrama de componentes	componente o cmp	componente
Diagrama de ubicación	indefinido	despliegue
Diagrama de objetos	indefinido	objeto
Diagrama de estructura interna	clase	clase o componente
Diagrama de descripción general de la interacción	Interacción o Dakota del Sur	Interacción
Diagrama de sincronizacion	Interacción o Dakota del Sur	momento
Diagrama del paquete	paquete o paquete	paquete

11.1. Estructura del lenguaje de modelado unificado

Lenguaje de modelado unificado (UML) en en la actualidad es el estándar de facto para describir (documentar) los resultados del diseño y desarrollo de sistemas orientados a objetos. El desarrollo de UML comenzó en 1994 por Grady Booch y James Rambeau de Rational Software. En el otoño de 1995, Ivar Jacobson se unió a ellos, y en octubre del mismo año, se lanzó una versión preliminar 0.8 del Método Unificado. Desde entonces, se han lanzado varias versiones de la especificación UML, dos de las cuales tienen el estatus de estándar internacional:

UML 1.4.2 - "ISO / IEC 19501: 2005. Tecnología de la información. Procesamiento distribuido abierto. Lenguaje de modelado unificado (UML). Versión 1.4.2" (ing. "Tecnología de la información. Procesamiento distribuido abierto. Lenguaje de modelado unificado (UML). Versión 1.4.2 ");

UML 2.4.1 - "ISO / IEC 19505-1: 2012. Tecnología de la información. OMG UML. Parte 1. Infraestructura" (ing. Tecnología de la información - Lenguaje de modelado unificado del grupo de gestión de objetos (OMG UML) - Parte 1: Infraestructura ") e "ISO / IEC 19505-2: 2012. Tecnología de la información. Lenguaje unificado de modelado del grupo de gestión de objetos (OMG UML). Parte 2. Superestructura" (ing. "Tecnología de la información - Lenguaje unificado de modelado del grupo de gestión de objetos (OMG UML) - Parte 2 : Superestructura ").

La última especificación oficial del idioma se puede encontrar en www.omg.org.

La estructura general de UML se muestra en la siguiente figura.

Arroz. 11.1. Estructura UML

11.2. Semántica y sintaxis de UML

Semántica - una sección de lingüística que estudia el significado de las unidades del lenguaje, principalmente sus palabras y frases.

Sintaxis - formas de combinar palabras y sus formas en frases y oraciones, combinar oraciones en oraciones complejas, formas de crear declaraciones como parte del texto.

Así, cuando se aplica al UML, la semántica y la sintaxis definen un estilo de presentación (construcción de modelos) que combina lenguajes naturales y formales para representar conceptos básicos(elementos modelo) y mecanismos para su expansión.

11.3. Notación UML

La notación es una interpretación gráfica de la semántica para su presentación visual.

El UML define tres tipo de entidad :

Estructural: una abstracción que es un reflejo de un objeto conceptual o físico;

Agrupación: un elemento utilizado para cierta unificación semántica de elementos del diagrama;

Explicativo (anotación): un comentario a un elemento del diagrama.

La siguiente tabla proporciona una breve descripción de las principales entidades utilizadas en la notación gráfica y las principales formas de mostrarlas.

Cuadro 11.1. Entidades

Tipo de	Nombre	Designacion	Definición (semántica)
Estructural	(clase)		El conjunto de objetos que tienen estructura general y comportamiento
	(objeto)		Una abstracción de una entidad real o imaginaria con límites conceptuales claramente definidos, individualidad (identidad), estado y comportamiento. Desde una perspectiva UML, los objetos son instancias de clase (instancias de entidad)
	(actor)	Ingeniero servicios de ruta	Una entidad externa al sistema que interactúa con el sistema y lo usa. funcionalidad para lograr ciertos objetivos o para resolver problemas particulares. Por tanto, el actor es fuente externa o receptor de información
	(caso de uso)		Descripción de las acciones realizadas por el sistema, que conducen a un resultado significativo para el actor.
	(estado)		Descripción del momento en la vida de una entidad cuando satisface una determinada condición, realiza alguna actividad o espera la ocurrencia de algún evento.
	Cooperación (colaboración)		Descripción de un conjunto de instancias de actores, objetos y su interacción en el proceso de resolución de un determinado problema.
	(componente)		La parte física del sistema (archivo), incluidos los módulos del sistema que proporcionan la implementación de un conjunto coherente de interfaces.
	(interfaz)	iCalculation	Un conjunto de operaciones que definen un servicio (conjunto de servicios) proporcionado por una clase o componente.
	(nodo)		La parte física del sistema (computadora, impresora, etc.) que proporciona recursos para resolver el problema.
Agrupamiento	(paquete)		Mecanismo general de agrupación de elementos. A diferencia de un componente, un paquete es un concepto puramente conceptual (abstracto). Casos particulares del paquete son el sistema y el modelo.
	(fragmento)		El área de interacción específica entre instancias de actor y objeto.
	(partición de actividad)		Un grupo de operaciones (área de responsabilidad) realizadas por una entidad (actor, objeto, componente, nodo, etc.)
	(región de actividad interrumpible)		Un grupo de operaciones, cuya secuencia normal puede interrumpirse como resultado de una situación no estándar.
Explicando	Nota (comentario)		Comentario del artículo. Se adjunta al elemento comentado con una línea discontinua.

En algunas fuentes, en particular [,], las entidades conductuales también se distinguen interacciones y máquinas de estados finitos, pero desde un punto de vista lógico, deberían clasificarse como diagramas.

Algunas de las entidades anteriores según las implican Descripción detallada en los diagramas de descomposición. En el diagrama nivel superior están marcados con un icono o etiqueta especial.

La siguiente tabla proporciona una descripción de todos los tipos. relación UML utilizado en diagramas para indicar relaciones entre entidades.

Cuadro 11.3. Relación

Nombre	Designacion	Definición (semántica)
Asociación		Una relación que describe una relación significativa entre dos o más entidades. La mayoría forma general relación
Agregación		Un subtipo de asociación que describe la relación "parte" - "todo", en el que la "parte" puede existir por separado del "todo". El rombo se indica desde el lado "completo". La relación se indica solo entre entidades del mismo tipo
Composición		Un subtipo de agregación en el que las "partes" no pueden existir por separado del "todo". Como regla general, las "partes" se crean y destruyen al mismo tiempo que el "todo"
Dependencia		Relación entre dos entidades en la que un cambio en una entidad (independiente) puede afectar el estado o comportamiento de otra entidad (dependiente). Una entidad independiente se indica en el lado de la flecha.
Generalización		La relación entre una entidad genérica (antepasado, padre) y una entidad especializada (hijo, hijo). El triángulo se especifica desde el lado del padre. La relación se indica solo entre entidades del mismo tipo
Realización		Una relación entre entidades, donde una entidad define una acción que la otra entidad se compromete a realizar. Las relaciones se utilizan en dos casos: entre interfaces y clases (o componentes), entre casos de uso y colaboraciones. El lado de la flecha indica la entidad que define la acción (interfaz o caso de uso)

Para asociación, agregación y composición se pueden especificar multiplicidad (Multiplicidad inglesa), que caracteriza el número total de instancias de entidades que participan en la relación. Por lo general, se indica en cada lado de la relación cerca de la entidad correspondiente. La multiplicidad se puede especificar de las siguientes formas:

- * - cualquier número de copias, incluida ninguna;

Entero no negativo: la multiplicidad es estrictamente fija e igual al número especificado (por ejemplo: 1, 2 o 5);

Rango de enteros no negativos "primer número .. segundo número" (por ejemplo: 1..5, 2..10 o 0..5);

Un rango de números desde un valor inicial específico hasta un "primer número .. *" final arbitrario (por ejemplo: 1 .. *, 5 .. * o 0 .. *);

Enumeración de números enteros no negativos y rangos separados por comas (por ejemplo: 1, 3..5, 10, 15 .. *).

Si no se especifica la multiplicidad, entonces se asume que su valor es 1. La multiplicidad de las instancias de entidad que participan en la dependencia, generalización e implementación siempre se asume que es 1.

La siguiente tabla describe mecanismos para expandir utilizado para aclarar la semántica de entidades y relaciones. En general, el mecanismo de extensión es una cadena de texto entre corchetes o comillas.

Cuadro 11.4. Mecanismos de extensión

Nombre	Designacion	Definición (semántica)
Estereotipo (estereotipo)	« »	Una designación que especifica la semántica de un elemento de notación (por ejemplo: una dependencia con el estereotipo "incluir" se considera una relación de inclusión y una clase con un estereotipo "límite" es una clase límite)
Condición de guardia (condición de guardia)		Condición booleana (por ejemplo: o [identificación completada])
Limitación (restricción)	{ }	Regla que limita la semántica del elemento del modelo (por ejemplo, (tiempo de ejecución inferior a 10 ms))
Valor etiquetado (valor etiquetado)	{ }	Propiedad nueva o calificada de un elemento de notación (por ejemplo: (versión = 3.2))

Además de los estereotipos, indicados como una cadena de texto entre comillas, los estereotipos gráficos se pueden utilizar en los gráficos. La siguiente figura muestra ejemplos de visualización estándar y estereotipada.


a) designación estándar		b) designación estándar con estereotipo de texto		c) estereotipo gráfico

Arroz. 11.2. Ejemplos de visualización de clase estándar y estereotipada

Diagrama es una agrupación de elementos de notación para representar algún aspecto de la sistema de informacion... Los diagramas suelen ser un gráfico conectado en el que las entidades son vértices y las relaciones son arcos. La siguiente tabla da una breve descripción de Diagramas UML.

Cuadro 11.5. Diagramas

Diagrama			Cita
				por el grado de realización física	mostrando dinámica	por aspecto mostrado
(caso de uso)			Muestra funciones del sistema, interacción entre actores y funciones.	Lógico	Estático	Funcional
(clase)			Muestra un conjunto de clases, interfaces y relaciones entre ellas.	Lógico o físico	Estático	Funcional e informativo
(paquete)			Muestra un conjunto de paquetes y la relación entre ellos.	Lógico o físico	Estático	Componente
Comportamiento (comportamiento)	(máquina estatal)		Muestra los estados de una entidad y las transiciones entre ellos durante su ciclo de vida.	Lógico	Dinámica	Conductual
	(actividad)		Muestra los procesos comerciales en el sistema (descripción de los algoritmos de comportamiento)
	Interacciones (Interacción)	(secuencia)	Muestra la secuencia de transmisión de mensajes entre objetos y actores.
		(comunicación)	Similar a un diagrama de secuencia, pero el énfasis está en la estructura de interacciones entre objetos.
Implementación (implementación)	(componente)		Muestra los componentes del sistema (programas, bibliotecas, tablas, etc.) y los vínculos entre ellos.	Físico	Estático	Componente
	(despliegue)		Muestra la ubicación de los componentes por hosts, así como su configuración.

El estándar UML 2.x también define diagramas adicionales altamente especializados:

Un diagrama de objetos es similar, pero los objetos se muestran en lugar de clases;

Diagrama de tiempo: describe el estado de un objeto a lo largo del tiempo;

Diagrama de estructura compuesta: describe los puertos (incluidas las interfaces) de una clase para interactuar con otras clases;

Diagrama de perfil: similar a la descripción de las clases incluidas en ellos;

El diagrama de descripción general de la interacción es similar, pero con fragmentos de interacción ocultos (fragmentos con una etiqueta ref). Es contextual (conceptual), cuyos elementos se concretarán en diagramas de descomposición separados.

Con el propósito de una representación conceptual ampliada de la arquitectura interna del sistema, la mayor parte de la construcción permite el uso de estereotipos gráficos establecidos para el llamado. Dicho diagrama se llama 1, pero no pertenece a la lista de diagramas definida por el estándar UML.

Al desarrollar un modelo separado del sistema, se construyen varios tipos de diagramas. Además, al desarrollar un modelo de un sistema complejo, por regla general, se construyen varios diagramas del mismo tipo. Al mismo tiempo, es posible no crear tipos de diagramas separados, si esto no es necesario. Por ejemplo, los diagramas y son intercambiables; están construidos solo para objetos con comportamiento complejo. La siguiente tabla proporciona orientación sobre la necesidad de desarrollar (refinar) diagramas por modelo de sistema.

Cuadro 11.6. Vinculación de modelos y diagramas

La tabla no muestra el modelo de prueba, ya que en el marco de su construcción, los diagramas no se desarrollan, sino que se verifican (prueban) para verificar que estén completos y sean coherentes.

Parte de los diagramas después de su construcción requiere desarrollo y refinamiento como parte del desarrollo del siguiente modelo ( proceso tecnológico). Entonces, por ejemplo, debe aclararse durante el desarrollo. En modelos.

4. Dé una definición al concepto "".

UML es un lenguaje de modelado gráfico unificado para describir, visualizar, diseñar y documentar sistemas OO. UML está diseñado para apoyar el proceso de modelado de sistemas de software basados en el enfoque OO, para organizar la relación de conceptos conceptuales y de software, para reflejar los problemas de escalar sistemas complejos. Los modelos en UML se utilizan en todas las etapas del ciclo de vida del sistema de software, desde el análisis comercial hasta el mantenimiento del sistema. Diferentes organizaciones pueden aplicar UML como mejor les parezca, dependiendo de sus áreas problemáticas y tecnologías utilizadas.

Una breve historia del UML

A mediados de los 90, varios autores propusieron varias docenas de métodos de modelado OO, cada uno de los cuales utilizó su propia notación gráfica. Al mismo tiempo, cualquiera de estos métodos tenía sus puntos fuertes, pero no permitía construir un modelo PS suficientemente completo, mostrándolo "desde todos los lados", es decir, todas las proyecciones necesarias (Ver artículo 1). Además, la falta de un estándar de modelado OO hizo que a los desarrolladores les resultara difícil elegir el método más apropiado, lo que impidió el uso generalizado del enfoque OO para el desarrollo de software.

A pedido del Object Management Group (OMG), la organización responsable de la adopción de estándares en el campo de las tecnologías de objetos y bases de datos, los autores de los tres métodos OO más populares resolvieron el problema urgente de la unificación y estandarización: G Buch, D. Rambo y A. Jacobson, quienes unieron sus esfuerzos crearon UML 1.1, que fue aprobado por la OMG en 1997 como estándar.

UML es un lenguaje

Cualquier idioma consta de un vocabulario y reglas para combinar palabras para obtener construcciones significativas. Entonces, en particular, los lenguajes de programación están organizados, como el UML. Su rasgo distintivo es que el diccionario de idiomas está formado por elementos gráficos. Cada símbolo gráfico tiene una semántica específica, por lo que un modelo creado por un desarrollador puede ser entendido sin ambigüedades por otro, y también herramienta de software interpretando el UML. De esto, en particular, se deduce que un modelo PS presentado en UML se puede traducir automáticamente a un lenguaje de programación OO (como Java, C ++, VisualBasic), es decir, si existe una buena herramienta de modelado visual que soporte UML , construyendo el modelo, recibiremos una preparación del código del programa correspondiente a este modelo.

Cabe destacar que UML es un lenguaje, no un método. Explica a partir de qué elementos crear modelos y cómo leerlos, pero no dice nada sobre qué modelos deben desarrollarse y en qué casos. Para crear un método basado en UML, es necesario complementarlo con una descripción del proceso de desarrollo del software. Un ejemplo de tal proceso es el Proceso Unificado Racional, que se discutirá en artículos posteriores.

Vocabulario UML

El modelo se representa en forma de entidades y relaciones entre ellas, que se muestran en diagramas.

Entidades Son abstracciones que son los elementos principales de los modelos. Hay cuatro tipos de entidades: estructurales (clase, interfaz, componente, caso de uso, cooperación, nodo), de comportamiento (interacción, estado), agrupación (paquetes) y anotación (comentarios). Cada tipo de entidad tiene la suya representación grafica... Las entidades se discutirán en detalle al explorar diagramas.

Relación mostrar varias relaciones entre entidades. El UML define los siguientes tipos de relaciones:

Adiccion muestra tal conexión entre dos entidades, cuando cambiar una de ellas - independiente - puede afectar la semántica de la otra - dependiente. La dependencia está representada por una flecha punteada que apunta desde la entidad dependiente a la entidad independiente.
Asociación Es una relación estructural que muestra que los objetos de una entidad están relacionados con los objetos de otra. Una asociación se muestra gráficamente como una línea que conecta las entidades que se vinculan. Las asociaciones se utilizan para navegar entre objetos. Por ejemplo, la asociación entre las clases "Pedido" y "Producto" se puede utilizar para buscar todos los bienes especificados en un pedido en particular, por un lado, o para encontrar todos los pedidos en los que hay un producto determinado, por otro. . Es evidente que los programas correspondientes deben implementar un mecanismo para dicha navegación. Si solo se requiere una dirección para navegar, se indica con una flecha al final de la asociación. Un caso especial de asociación es la agregación, una relación de la forma "todo" - "parte". Gráficamente, se resalta con un diamante al final cerca del todo de la entidad.
Generalización Es una relación entre una entidad padre y una entidad descendiente. Básicamente, esta relación refleja la propiedad de herencia para clases y objetos. La generalización se muestra como una línea que termina con un triángulo que apunta hacia la entidad principal. El hijo hereda la estructura (atributos) y el comportamiento (métodos) del padre, pero al mismo tiempo puede tener nuevos miembros de estructura y nuevos métodos. UML permite la herencia múltiple cuando una entidad está asociada con más de una entidad principal.
Implementación- la relación entre la entidad que define la especificación del comportamiento (interfaz) con la entidad que define la implementación de este comportamiento (clase, componente). Esta relación se usa comúnmente en el modelado de componentes y se describirá con más detalle en artículos posteriores.

Diagramas. El UML proporciona los siguientes diagramas:

Diagramas que describen el comportamiento del sistema:

Diagramas de estado,
Diagramas de actividad,
Diagramas de objetos,
Diagramas de secuencia,
Diagramas de colaboración

Diagramas que describen la implementación física del sistema:

Diagramas de componentes
Diagramas de implementación

Vista de control de modelo. Paquetes.

Ya hemos dicho que para que un modelo sea bien entendido por una persona, es necesario organizarlo jerárquicamente, dejando un pequeño número de entidades en cada nivel de la jerarquía. UML incluye un medio para organizar una representación jerárquica de un modelo: paquetes. Cualquier modelo consta de un conjunto de paquetes que pueden contener clases, casos de uso y otras entidades y diagramas. Un paquete puede incluir otros paquetes para crear jerarquías. No hay diagramas de paquetes separados en UML, pero pueden aparecer en otros diagramas. El paquete se muestra como un rectángulo con una pestaña.

Qué proporciona UML.

una descripción jerárquica de un sistema complejo mediante la asignación de paquetes;
formalización de requisitos funcionales para el sistema utilizando el aparato de casos de uso;
detallando los requisitos del sistema mediante la construcción de diagramas de actividades y escenarios;
resaltar clases de datos y construir un modelo de datos conceptual en forma de diagramas de clases;
resaltando las clases que describen la interfaz de usuario y creando un esquema de navegación de pantalla;
una descripción de los procesos de interacción de objetos al realizar funciones del sistema;
descripción del comportamiento de los objetos en forma de diagramas de actividades y estados;
descripción de componentes de software y su interacción a través de interfaces;
una descripción de la arquitectura física del sistema.

Y el último ...

A pesar de todo el atractivo de UML, sería difícil usarlo en el modelado de software real sin herramientas de modelado visual. Estas herramientas le permiten presentar rápidamente diagramas en la pantalla, documentarlos, generar códigos de programa en blanco en varios lenguajes de programación OO y crear esquemas de bases de datos. La mayoría de ellos incluyen la posibilidad de reingeniería de códigos de programas, restaurando ciertas proyecciones del modelo PS mediante el análisis automático de los códigos fuente de los programas, lo cual es muy importante para garantizar la consistencia del modelo y los códigos y al diseñar sistemas que heredan la funcionalidad del predecesor. sistemas.