¿Qué información léxica y gramatical se necesita para generar diagramas UML?

Revisión del lenguaje de modelado unificado UML

Shao Weizhong Meihong

Resumen Iniciado recientemente por American Rational Company y lanzado junto con más de una docena de otras empresas** * UML "Lenguaje de modelado unificado" ha recibido una amplia atención en el campo OO. Este artículo presenta primero los antecedentes de UML y su contenido principal, y luego comenta sobre su impacto positivo en la tecnología de modelado OO y los posibles problemas. lenguaje de modelado rico y poderoso, pero aún no es seguro que reemplace varios métodos de diseño y análisis orientados a objetos existentes. Debido a que es solo un lenguaje de modelado, no un método, su complejidad puede convertirse en un obstáculo para ganar. una gran cantidad de usuarios

Palabras clave orientadas a objetos, método de modelado, lenguaje de modelado

Número de clasificación de gráficos de China TP311

REVISIÓN DEL LENGUAJE DE MODELADO UNIFICADO (UML). )

SHAO Wei-Zhong y MEI Hong

(Departamento de Tecnología y Ciencias de la Computación, Universidad de Pekín, Beijing 100871)

Resumen El lenguaje de modelado unificado (UML) ), publicado por Rational Software Corporation y otros socios de UML, está atrayendo gran atención en el área de la tecnología de objetos. Se presentan los antecedentes históricos y los contenidos principales de UML y luego se discute su importancia, su influencia positiva y algunos posibles problemas. UML es un lenguaje de modelado expresivo y poderoso, sin embargo, no se puede concluir que reemplazaría todos los métodos de diseño y análisis orientados a objetos existentes. La razón es que UML es solo un lenguaje de modelado y no un método, y su excesiva complejidad podría volverse. un obstáculo para ganar un gran número de usuarios

Palabras clave orientación a objetos, método de modelado, lenguaje de modelado

1 Antecedentes de UML

Como la importancia de. Los métodos de análisis y diseño orientados a objetos (OOA/OOD) se vuelven cada vez más prominentes, el entusiasmo de la gente por su investigación, desarrollo y aplicación también está aumentando. En 1989, en forma de monografías, artículos o informes técnicos, etc. Hay casi 10 propuestos. Métodos OOA/OOD o lenguajes de modelado OO, y en 1994, su número aumentó a más de 50. La aparición de varios métodos ha contribuido en mayor o menor medida a la investigación y el desarrollo de nuevas tecnologías OOA/OOD.

Esta próspera situación de "dejar florecer cien flores" muestra que los métodos y tecnologías orientados a objetos han sido ampliamente reconocidos y se han convertido en la corriente principal actual. Sin embargo, la popularidad simultánea de múltiples métodos también trae algunos problemas: los conceptos utilizados por varios OOA y. Métodos OOD Hay muchas partes similares pero también ciertas diferencias (por ejemplo, muchos métodos proponen algunos conceptos extendidos basados ​​en los conceptos básicos de OO, y la interpretación semántica de literalmente los mismos conceptos también es diferente en símbolos de representación, modelos OOA y); Las diferencias en la organización de documentos y otros aspectos son aún más obvias. Esta situación a menudo dificulta que algunos usuarios nuevos tomen decisiones al elegir métodos y herramientas de modelado y no favorece el intercambio técnico entre ellos. >Teniendo en cuenta que en este caso, G. Booch y J. Rumbaugh, quienes trabajaron en Rational Software Company en Estados Unidos en 1994, creían que sus respectivos métodos (método Booch [1] y OMT [2]) debían combinarse para forman un método unificado Comenzaron este trabajo en octubre de ese año y lanzaron públicamente la primera versión en octubre de 1995, a saber, el Método Unificado 0.8. En el otoño de 1995, I. Jacobson, el proponente de OOSE [3], se unió a Rational Software. Company, por lo que también se unieron a esta fila G. Booch, J. Rumbaugh e I. Jacobson*** creen que hay tres razones para proponer un lenguaje de modelado unificado: Primero, los métodos que propusieron han evolucionado durante la evolución. es una tendencia a combinarse entre sí; en segundo lugar, avanzar hacia la unificación traerá beneficios de mercado; en tercer lugar, ayudará a mejorar sus respectivos métodos para obtener más estudiantes y resolver algunos problemas que no eran muy buenos en sus respectivos métodos en el pasado.

Para determinar un conjunto de símbolos de representación para el análisis y el diseño, encontraron algunos problemas que debían sopesarse. Uno era la definición del alcance del problema. ¿Se incluirán las especificaciones de requisitos? (La respuesta es sí, debería incluirse parcialmente); ¿Deben incluirse lenguajes de programación visual? (La respuesta es "no"). La segunda es que se debe llegar a un compromiso entre expresividad y simplicidad. Si la representación es demasiado simple, la capacidad para resolver problemas será limitada, y si la representación es demasiado compleja, los desarrolladores comunes lo harán. El tercero es que combinar sus tres métodos originales también requiere que tengan cuidado con el tamaño de los cambios en los métodos originales. Los cambios demasiado grandes causarán confusión entre los usuarios antiguos, y si continúan usando las cosas originales, lo harán. perder la oportunidad de realizar mejoras y ganar más nuevos usuarios. A juzgar por las cuestiones discutidas en la literatura UML, la propuesta de UML no es simplemente encontrar la solución más razonable desde un punto de vista académico y técnico, sino que debe tener en cuenta las relación entre la empresa, los usuarios antiguos y varios métodos originales.

En cualquier caso, hicieron lo que pensaron que era la mejor compensación en este contexto y lanzaron las versiones UML 0.9 y 0.91. y octubre de 1996. A partir de ese momento, el "Método unificado" pasó a llamarse "Lenguaje de modelado unificado" (lenguaje de modelado unificado) porque exactamente no es un método de modelado orientado a objetos, sino un lenguaje de modelado orientado a objetos. Propone un conjunto de elementos y símbolos para modelar y define su semántica, en lugar de describir cómo modelar el sistema. Como señaló M. Fowler en su libro que presenta específicamente UML [4]: ​​"UML se llama construcción Un lenguaje de modelado. , no un método. Al menos en principio, la mayoría de los métodos se componen de un lenguaje de modelado y un proceso. El lenguaje de modelado es un (principalmente gráfico) que representa un símbolo, que se utiliza para expresar los diseños de las personas y es una sugerencia sobre qué pasos; "El libro de M. Fowler está escrito en el contexto de la versión UML 1.0; G. Booch, I. Jacobson y J. Rumbaugh escribieron personalmente el prefacio del libro. Esto al menos muestra que el La evaluación general de UML es reconocida por sus creadores.

En 1996, Rational se preparó para publicar Object Management Group (OMG).

Solicitar el uso de UML como lenguaje de modelado estándar. Para ello, se creó la Organización de Socios de UML, incluida la propia Rational. ***12 empresas se unieron. Lanzaron la versión 1.0 de UML y la presentaron a OMG en enero de 1997 como una solicitud de propuesta preliminar. En 1997, varias otras empresas presentaron sus propias solicitudes de propuestas de lenguaje de modelado a OMG. Como resultado, la organización asociada de UML absorbió estas empresas en sus propias filas. Para reflejar las opiniones de estos nuevos miembros, se modificó UML1.0. y UML1.1 fue producido y enviado a OMG el 1 de septiembre de 1997. Fue adoptado por OMG en noviembre del mismo año. UML1.1 es actualmente la última versión, pero no es la versión final porque las modificaciones continúan. Desde el lanzamiento de UML 1.1, las siguientes 17 empresas han participado en la acción conjunta UML: Rational Software, Microsoft, Hewlett-Packard, Oracle, Sterling Software, MCI Systemhouse, Unisys, ICON Computing, IntelliCorp, i-Logix, IBM, ObjectTime , Platinum Technology, Ptech, Taskon, Reich Technologies y Softeam

2 Descripción general del contenido UML

Según el documento UML, “Unified Modeling Language (UML) es un software estandarizado, lenguaje de documentación y construcción visual para artefactos del sistema que también se puede utilizar para modelado de negocios y otros sistemas que no son de software". UML 1.1 proporciona 6 documentos, todos publicados conjuntamente a nombre de 17 empresas de la organización asociada de UML. Este documento Esta sección primero presenta brevemente estos archivos, y la siguiente sección presentará la guía de notación UML con más detalle.

(1) Resumen de UML: es una introducción general a UML, que incluye su motivación, objetivo, alcance, historia y. situación actual.

(2) Semántica de UML: Define la semántica de UML. La definición utiliza tecnología formal, pero no es una especificación completamente formal. Proporciona especificaciones precisas para la estructura de sintaxis y su semántica dinámica. se describe en lenguaje natural. La sintaxis de UML es una sintaxis abstracta que no tiene nada que ver con símbolos de representación. Aunque no es una formalización completa, su método de definición también es bastante complicado: Se adopta una arquitectura de metamodelo de 4 niveles y la longitud del texto alcanza más de 160 páginas. La Sección 2.2 del documento presenta los 4 niveles del modelo, a saber:

① Meta-metamodelo (meta-metamodelo). ): La arquitectura básica del metamodelo, que define un lenguaje para describir el metamodelo.

② Metamodelo (metamodelo): una instancia del metamodelo, define un lenguaje para describir. el modelo.

③ Modelo: una instancia del metamodelo, que define un lenguaje para describir el dominio de información.

④ Objeto de usuario (objeto de usuario): una instancia de un modelo que define. un dominio de información específico

La forma de definir los elementos del modelo en todos los niveles es dar primero su sintaxis abstracta (utilizando la representación del diagrama de clases de UML para describir las relaciones entre elementos) y luego dar sus reglas formales (. usando lenguaje de restricciones de texto y objetos), y finalmente describir su semántica (usando texto preciso). De esta manera, se definen un total de 118 elementos, divididos en 3 partes y definidos en 9 paquetes. (3) Guía de notación UML: este archivo brinda la representación visual de UML y brinda la representación gráfica de los elementos del modelo a través de símbolos; consulte la siguiente sección para obtener más detalles.

(4) Especificación del lenguaje de restricciones de objetos: Este archivo define

También presenta un lenguaje de restricción de objetos (OCL para abreviar), que se utiliza para ilustrar cierta información de modelado que no se puede expresar completamente en modelos de sistemas gráficos. Es un lenguaje formal, pero fácil de escribir y leer. no representa problemas de implementación, es decir, se utiliza para describir el modelo en detalle, en lugar de ser compilable y ejecutable.

(5) Para software UML Extension for Objectory Process for Software Engineering. Los requisitos en ingeniería de software, se definen algunos conceptos de extensión UML. Por ejemplo, el modelo se divide en modelo de caso de uso, modelo de análisis, modelo de diseño y modelo de implementación, y no se presenta una definición para cada concepto de modelo expandido. el proceso de desarrollo orientado a objetos, ni habla sobre cómo utilizar UML en el proceso. El contenido del documento es muy breve, solo 5 páginas

(6) Extensión UML para modelado empresarial: define. algunos conceptos de extensión UML para modelado de negocios. Es similar al archivo anterior, excepto que su extensión es para la construcción de modelos de procesamiento de negocios en general, no para ingeniería de software.

3 UML. Guía de notación

Este documento brinda una representación visual de UML, brindando elementos del modelo a través de ejemplos. Símbolos de representación gráfica. Desde el nivel del modelo del sistema, la representación UML consta de 9 tipos de diagramas, que son:

<. p>Diagrama de estructura estática, que incluye diagrama de clases y diagrama de objetos

Diagrama de casos de uso

Diagrama de secuencia

Diagrama de colaboración; p>Diagrama de Statechart;

Diagrama de actividad;

Diagrama de implementación, incluido el diagrama de componentes) y Diagrama de implementación

Aunque el documento UML establece que "Notación UML. La guía define la notación y proporciona ejemplos", la declaración exacta debe ser: el documento es El método de representación de elementos modulares proporciona una descripción de texto general, y el método de dibujo de sus gráficos se muestra a través de ejemplos, y no se dan ilustraciones generales. La mayoría Algunas de las ilustraciones de este artículo se basan en el método del trabajo de M. Fowler [4]. Dado en un sentido general,

UML define algunos elementos comúnmente utilizados en varios diagramas, como Cadena, Nombre, Etiqueta. , Palabra clave, Expresión (expresión), Nota (tira de notas), etc., y proporcione sus símbolos de representación. Por ejemplo, las palabras clave se representan mediante una cadena encerrada por los números del título del libro y las tiras de notas se representan mediante texto dentro de un rectángulo con uno. esquina doblada. En varios El elemento utilizado para empaquetar un grupo de elementos del modelo en la figura se llama "Paquete". Su representación es usar un cuadro grande para rodear el grupo de elementos y usar un cuadro pequeño en la esquina. nombre del paquete.

Además, UML también define algunos elementos llamados "mecanismos de expansión". Dichos elementos se pueden adjuntar a otros elementos del modelo para especializar los elementos de modelado originales en una nueva variante semántica. o representar algunos de sus detalles. Estos elementos pueden ampliar o refinar la representación. Son:

Restricción: Las restricciones son restricciones entre elementos del modelo que describen ciertas condiciones.

Una proposición que debe seguir siendo verdadera. Su representación es escribir una cadena de texto que exprese la condición entre llaves { } en un lenguaje que la herramienta pueda reconocer (como OCL proporcionado por UML). ): Un comentario es una cadena de texto escrita dentro del símbolo de la barra de comentarios (un rectángulo con una esquina doblada). El lenguaje utilizado debe ser fácil de entender para las personas y no necesita ser entendido por herramientas. Propiedad del elemento (características del elemento): se utiliza para mostrar algunas características incidentales de los elementos del modelo, como atributos, asociaciones, valores objetivo, etc. La representación consiste en escribir una cadena de texto en forma de palabra clave = valor entre llaves {}, y múltiples cadenas Separadas entre sí con comas.

Estereotipo: solía adjuntarse a otros elementos del modelo para especializar los elementos de modelado originales en una nueva variante con semántica especial. Con tipografía El elemento de modelado puede considerarse como una subcategoría. del elemento de modelado original Tiene la misma forma que el elemento original en términos de atributos, relaciones, etc., pero su propósito es más específico. La plantilla está representada por las palabras clave encerradas en el número del título del libro. de los conceptos anteriores se muestra en la Figura 1.

Figura 1 Elementos gráficos, paquetes y mecanismos de expansión

A continuación se presentan varios gráficos y los elementos y componentes de modelado utilizados en los gráficos.

(1) Diagrama de estructura estática

El diagrama de estructura estática incluye un diagrama de clases (diagrama de clases) y un diagrama de objetos (diagrama de objetos). "El diagrama de clases es un gráfico del modelo de estructura estática". El diagrama de clases es una colección declarada (estáticamente) de elementos del modelo". Con respecto a los diagramas de objetos, el documento dice: "Los diagramas de objetos son un gráfico de instancias, incluidos los valores de objetos y datos. Los diagramas de objetos estáticos son un ejemplo de un diagrama de clases; una instantánea del estado detallado del sistema en un momento dado". El documento también señala: "La utilidad de los diagramas de objetos es muy limitada" y "las herramientas no necesariamente admiten formas independientes de diagramas de objetos. Los diagramas de clases pueden contener objetos. Un diagrama de clases con objetos pero sin clases es un "diagrama de objetos". Sin embargo, el término es útil para describir las diversas formas en que se pueden lograr varios tipos de diagramas utilizados en diagramas de estructura estática. se muestra en la Figura 2, que se presenta por separado a continuación.

Figura 2 La representación de elementos de modelado en el diagrama de estructura estática

Clase: Clase Es una descripción de un grupo de objetos. con estructura, comportamiento y relación similares, UML proporciona tres tipos de representaciones gráficas para clases. El primero es un método de supresión de detalles, que solo proporciona el nombre de la clase en un cuadro; el segundo es un método detallado a nivel de análisis, que proporciona la clase; nombre, nombre y tipo de atributo y nombre de operación en las columnas superior, media e inferior respectivamente; el tercero es un método detallado a nivel de implementación, que proporciona más detalles

Nombre del compartimento (columna de nombre): define las especificaciones de escritura de la columna de nombre del símbolo de clase

Compartimento de lista (columna de lista): define las especificaciones de escritura de la columna de propiedades y la barra de operaciones del símbolo de clase

. Atributo (atributo): especifica el método de escritura del atributo, así como los siguientes tres símbolos de visibilidad: " " significa público (público ***), "#" significa protegido (protección), "-" significa privado (privado)

Operación (operación): especifica el método de escritura de la operación, utilizando los mismos tres símbolos de visibilidad como atributos.

Tipo vs. Clase de implementación (tipo y clase de implementación): Estos. son dos elementos de clase especiales que se obtienen adjuntando la palabra clave de diseño "tipo" o "clase de implementación" al símbolo de clase y brindando detalles de definición de atributos y operaciones en la barra de propiedades y la barra de operaciones. Entre ellos, "Tipo" describe las reglas de variables que. un objeto puede adoptar y luego abandonar; la "clase de implementación" define la estructura de datos físicos y el proceso del objeto cuando se implementa en un lenguaje. Los siguientes siete símbolos de representación se obtienen de esta manera.

Interfaz. es una referencia a una clase u otra entidad (como

Una descripción de la operación visible externamente de una unidad grande, como un paquete), que no explica la estructura de la entidad. Su representación es muy similar a un símbolo de clase, pero no hay una columna de atributos que agregue la palabra clave "interfaz". en la columna de nombre y complete la interfaz en la columna de operación Definición

Clase parametrizada (plantilla) (clase parametrizada, también conocida como plantilla): es una clase con uno o más parámetros formales independientes, por lo que define una familia de clases que toma los parámetros. La vinculación a un valor real describe una de las clases. La representación de una clase parametrizada consiste en agregar un cuadro de puntos en la esquina superior derecha del símbolo de clase y los diferentes tipos de implementación de cada una. Los parámetros se describen en el cuadro.

Elemento vinculado: Su función es conectar (vincular) los parámetros de la plantilla con los valores reales. Su representación es utilizar texto para describir la tabla de valores de parámetros de la plantilla.

Utilidad (programa de utilidad)): Un conjunto de variables y procedimientos globales declarados en forma de clase. No es una construcción básica, sino una conveniencia de programación. Su representación está marcada con la palabra clave ". utilidad" en la columna de nombre de clase del símbolo de clase.

Metaclase (metaclase): es decir, la clase de una clase, y su instancia es una clase. Su representación es agregar la palabra clave "metaclase" en la columna de nombre de clase.

Class Pathname (nombre de ruta de clase): se usa para indicar una referencia a una clase. La notación es usar el símbolo "∷" para indicar el nombre de la clase referenciada donde se encuentra esta clase. referenciado (en otros paquetes).

Importar un paquete (introducir un paquete): indica que se puede hacer referencia a una clase en otro paquete en un paquete. Esta es una relación de dependencia especial. palabra clave "importar" junto al símbolo de dependencia (flecha discontinua) 》.

Objeto: un objeto es una instancia especial de una clase. La representación del objeto dada por UML es un cuadro con solo dos columnas. la columna de nombre con el nombre del objeto (instancia) e indicar a dónde pertenece. El nombre de la clase. El valor de cada atributo se da en la columna de atributos.

Objeto compuesto: Un objeto compuesto de alto nivel. de algunas partes que están estrechamente unidas. Es una clase compuesta). Utilice un cuadro con dos columnas para representarlo. Complete el nombre del objeto combinado en la columna superior e indique su nombre de clase, y dibuje sus diversos objetos parciales. en la columna inferior.

Asociación: dividida en Asociación binaria y asociación múltiple se introducen respectivamente en las siguientes entradas.

Asociación binaria (asociación binaria): Es una asociación entre dos clases. (incluida la asociación de una clase consigo misma) Caso especial). Su representación es utilizar una línea continua para conectar dos símbolos de clase. Esta línea se puede dibujar recta, oblicua o curva según la conveniencia del dibujo. de varios segmentos Los puntos finales de la línea y la clase El lugar donde se conectan los símbolos se llama punto final de la asociación. Se puede observar alguna información útil cerca del punto final para indicar diferentes situaciones de la asociación (también se describe más adelante). lleva información adicional, que incluye: nombre de la asociación. Indica la función de la asociación a través de dicha denominación. El símbolo de clase de la asociación es el mismo que el símbolo de clase ordinario, pero debe adjuntarse a una asociación para indicar los atributos y operaciones de la asociación. Estas cosas son opcionales y no obligatorias.

AssociationEnd (punto final de asociación): el punto final de la asociación no es un elemento independiente y se utiliza para indicar algunos detalles de la asociación. los detalles se pasan agregando algunos caracteres o caracteres al lado del punto final de la asociación representados gráficamente, incluida la multiplicidad, el orden, el calificador, el nombre del rol, la capacidad de cambio y la visibilidad. Otros detalles se representan a través de los puntos finales de las líneas asociadas.

Incluido: la flecha abierta representa la navegabilidad, lo que significa que la instancia de objeto en un extremo de la asociación se puede encontrar con la instancia de objeto asociada a ella en el otro extremo; la flecha hueca en forma de diamante representa la agregación, lo que significa que la instancia de objeto; en un extremo de la asociación se puede encontrar Es un componente de la instancia del objeto en el otro extremo; la flecha de diamante sólido indica una forma fuerte de agregación, llamada composición

Multiplicidad: marca los puntos finales de la asociación. asociación con números (que indica una cantidad específica) o signo "*" (indica múltiples) para indicar cuántas instancias de objeto en este extremo están asociadas con instancias de objeto en el otro extremo

Calificador (límite), con el. símbolo de clase en un extremo de la asociación Dibuje un cuadro rectangular en la interfaz y proporcione algunos valores de atributos en el cuadro para indicar qué condiciones cumple el objeto en el otro extremo de la asociación para ser elegible para asociarse con el objeto. en este extremo es parte de la asociación, no parte de la clase.

La clase de asociación (clase de asociación) se utiliza para indicar que una asociación tiene características de clase (incluidos atributos y operaciones), representadas por ordinarias. símbolos de clase, unidos a la línea de asociación.

Asociación N-Ary (asociación múltiple), la asociación entre más de 3 clases es dibujar líneas de conexión desde un diamante a cada símbolo de clase asociado. /p>

Composición (ensamblaje) según UML, la composición es una de las formas de agregación, lo que significa que el todo tiene una fuerte relación de propiedad y el mismo tiempo de supervivencia para las partes, su representación es agregar un diamante sólido. flecha al punto final de la línea de asociación.

Enlace (Cadena), una cadena es una instancia de asociación, que indica la conexión entre dos objetos. Su representación es dibujar una línea recta entre dos instancias de objetos. /p>

Generalización (Generalización): "Sí. Una relación taxonómica entre un elemento más general y un elemento más específico que es completamente consistente con él pero agrega más información". Este concepto es similar a la "relación de herencia" o ". relación especial general" discutida en la mayor parte de la literatura técnica de OO. Básicamente lo mismo, sin embargo, la generalización de UML no solo se usa para expresar la relación entre clases, sino que también se usa para paquetes, casos de uso y otros elementos. Hay dos formas de notación. Una es la forma de compartir, en los símbolos de elementos generales Dibuja un triángulo al lado y dibuja una línea de conexión desde la base del triángulo, y esta conexión tiene varias ramas, que se conectan a cada elemento especial respectivamente; donde se dibujan varios triángulos al lado del símbolo del elemento general, cada uno dibuja una línea de conexión que conduce a un elemento especial en la base de un triángulo. Puede agregar una etiqueta de texto al lado de la línea de conexión, llamada discriminador, para indicar lo que es. se clasifica por.

Dependencia ( Dependencia): UML define la semántica de la dependencia de la siguiente manera: "Indica la relación semántica entre dos (o más) elementos del modelo. Su significado sólo involucra a estos elementos en sí mismos y no a sus instancias. Señala que en esta dependencia un cambio en el elemento de destino puede requerir un cambio en el elemento de origen." Existen los siguientes tipos de dependencias:

trace-Trace: un vínculo entre dos elementos que representan. el mismo concepto en diferentes niveles ideográficos. Una conexión histórica.

refinamiento-Refinamiento: Una conexión histórica o derivada entre dos elementos con una relación cartográfica (no necesariamente completa). Uso: para el propósito de un elemento, la implementación o funcionalidad correcta requiere la presencia de otro elemento.

bind-Binding: vincula un parámetro de plantilla a un valor real para crear un elemento no parametrizado.

Dependiente La notación consiste en dibujar una línea de puntos con una flecha entre dos elementos del modelo. Al lado, puede indicar a cuál de las dependencias anteriores pertenece la relación de dependencia y también puede agregar un nombre. la guía de notación UML no habla de su relación con el mensaje (¿Cuál es el concepto de mensaje)?

Conexiones y diferencias Los conceptos de UML como "mensaje" y "flujo de mensajes" se utilizan en diagramas de secuencia y diagramas de colaboración (ver más abajo para más detalles), pero no en diagramas de clases. Sin embargo, M. Fowler hizo esto en la literatura [4]. Explicación: "Para las clases, la dependencia puede existir por las siguientes razones: una clase envía mensajes a otras clases; una clase usa otras clases como parte de sus datos; una clase hace referencia a otras clases como parámetros de una operación".

Elemento derivado: Un elemento derivado es un elemento que se puede calcular a partir de otros elementos. Aunque no agrega información semántica, puede hacerlo más claro o más beneficioso para su representación. El método consiste en agregar una barra ". /" antes del nombre del elemento derivado.

(2) Diagrama de casos de uso

"El diagrama de casos de uso se utiliza para expresar la relación entre el actor y el caso de uso "El El modelo de caso de uso representa la función de un sistema o una clase para los interactuantes fuera del sistema". UML define los siguientes elementos que constituyen el diagrama de caso de uso (Figura 3).

Diagrama 3 Diagrama de caso de uso

Caso de uso: Un caso de uso es una unidad funcional compacta proporcionada por un sistema o una clase, que se intercambia entre el sistema y uno o más interactuantes externos (es decir, actores). La secuencia de mensajes y las actividades realizadas por el sistema. se reflejan simultáneamente.

Actor: Actor es el papel que desempeña un objeto externo que interactúa directamente con el sistema.

Relación de caso de uso (relación de caso de uso) incluye las siguientes tres relaciones: comunica (comunicaciones), que es la única relación entre el actor y el caso de uso, y es la participación del actor en el caso de uso se extiende (extensiones), desde el uso La relación de extensión del caso A al caso de uso B indica que las instancias de B; (bajo las condiciones especiales de la especificación de extensión) puede incluir el comportamiento especificado en los usos de A: la relación de uso de A a B indica que las instancias de A también incluyen el comportamiento descrito en B.

(3) Diagrama de secuencia

UML proporciona dos formas de diagramas de interacción (Diagrama de interacción), uno se llama diagrama de secuencia y el otro se llama diagramas de colaboración. Se basan en la misma información básica pero enfatizan diferentes aspectos de una secuencia. El diagrama muestra las interacciones ordenadas en orden cronológico. En particular, muestra las interacciones en las que participan los objetos a lo largo de su "línea de vida" y sus mensajes intercambiados en secuencia temporal. No muestra la relación entre los objetos. Conjunto de mensajes que se intercambian cuando los objetos cooperan para producir las operaciones o resultados requeridos. Hay dos métodos de dibujo: forma simple y forma detallada. El último método de dibujo es generalmente consistente con el diagrama de interacción introducido en trabajos como OOSE [3. ] - muestra varios objetos interactivos en la dirección horizontal e indica el tiempo en la dirección vertical. Todo el plano muestra cada objeto. Las relaciones de tiempo y espacio entre las interacciones, el diagrama de secuencia se muestra en la Figura 4. Los elementos de modelado utilizados para la secuencia; El diagrama es:

Figura 4 Diagrama de secuencia

Línea de vida del objeto (Object Lifeline Lifeline): una línea de puntos vertical que muestra el papel que desempeña un objeto en el período de tiempo desde la creación hasta la destrucción. /p>

Activación (período de actividad): Muestra que un objeto realiza una actividad ya sea directamente o a través de sus procesos subordinados.

Mensaje: Un mensaje es una comunicación entre objetos. se utiliza para transmitir información y esperar que se produzca alguna actividad. La recepción de un mensaje es un evento.

Tiempo de transición: El tiempo que tarda un mensaje en ser enviado o recibido. diferente

(4) Diagrama de Colaboración

Diagrama de Colaboración Es otro tipo de comunicación que llama UML.

Interdiagrama, que representa las operaciones organizadas entre algunos objetos y las cadenas entre ellos. A diferencia del diagrama de secuencia, el diagrama de colaboración representa la relación entre los roles de los objetos en lugar de la secuencia de tiempo. El diagrama de colaboración representa la colaboración entre un grupo de objetos relacionados en un. contexto específico y un conjunto de mensajes que se intercambian cuando este grupo de objetos colabora para producir operaciones o resultados requeridos. La representación gráfica de un diagrama de colaboración utiliza objetos como nodos, y entre nodos hay conexiones de flecha que representan mensajes y hay conexiones que. Representa asociaciones. Hay tres tipos de conexiones de mensajes, que representan tres mensajes diferentes: llamada, flujo de control y asíncrono. Sin embargo, todavía hay algunas situaciones que no se pueden representar, como el bloqueo (obstáculo) y el tiempo de espera, etc. ., se necesitan algunos símbolos más ampliados. Los símbolos asociados utilizados en los diagramas de colaboración también incluyen una variedad de situaciones de puntos finales diferentes, como calificador y composición, etc. El diagrama de colaboración se muestra en la Figura 5.

Figura 5 Diagrama de colaboración

Los conceptos o elementos de modelado definidos por la Guía de notación UML para diagramas de colaboración son: Colaboración (colaboración), Contenido de colaboración (contenido de colaboración), Interacción (interacción), Estructura de patrón, Rol de colaboración, Multiobjeto , Objeto activo, Flujos de mensajes, Marcadores de creación/destrucción, no hay más nombres aquí. Una introducción

(5) Diagrama de estado

El diagrama de estado también se denomina máquina de estados en UML. Representa el comportamiento de un objeto o una interacción a lo largo de su vida. La secuencia de estados cuando es estimulado y sus reacciones y actividades. Se adjunta a una clase o a un método. Los elementos de modelado utilizados para establecer un diagrama de estados son: Estado. , Estado compuesto (estado compuesto), Subestado (subestado), Evento, Transición simple, Transición compleja, Estado anidado, Envío de mensaje, Transición interna, etc. Representación del diagrama de estado y sus elementos relacionados. El método es similar a la mayoría de los OOA/OOD existentes.

(6) Diagrama de actividad

El diagrama de actividad es una variante del diagrama de estado. Su estado representa la actividad realizada por la operación. y su transición se desencadena al finalizar la operación. Representa la máquina de estado de un proceso en sí, que es la implementación de una operación en la clase. Constituye un diagrama de actividad. Los elementos son: Estado de acción (estado de actividad), Decisión. (juicio), Swimlane (carril de natación, dibujado en la imagen como un carril de natación en una piscina, coloque cada grupo de actividades en diferentes carriles de natación para que quede más claro), Relación de flujo de acción-objeto (relación de flujo de actividad-objeto, que representa el mensaje y relación de entrada/salida entre una actividad y objetos relacionados), Icono de control (icono de control, que representa el envío y recepción de señales), etc. El diagrama de actividad se muestra en la Figura 6.

Figura 6 Actividad Diagrama

(7) Diagrama de implementación

El diagrama de implementación muestra los problemas de implementación, incluida la estructura del código fuente y la estructura de implementación del tiempo de ejecución. El diagrama de implementación se divide en dos tipos, uno es el diagrama de componentes. representa la estructura del código en sí, y el otro es el diagrama expandido que representa la estructura del sistema en tiempo de ejecución.

El diagrama de componentes (Diagrama de componentes) representa el código fuente.

Las dependencias entre componentes de software, como código, código binario y código ejecutable, se muestran varios módulos de software en la Figura?/cagt;

.