¿Lenguaje de modelado orientado a objetos?
Shao Weizhong Meihong
Recientemente, el lenguaje de modelado unificado (UML) iniciado por la American Rational Company y lanzado conjuntamente por más de una docena de otras empresas ha causado Un revuelo en el campo OO recibió amplia atención. Este artículo presenta primero los antecedentes y el contenido principal de UML, y luego revisa su impacto positivo y posibles problemas en la tecnología de modelado orientado a objetos. UML es un poderoso lenguaje de modelado con ricas capacidades expresivas. Pero todavía no se puede concluir que reemplazará varios métodos de diseño y análisis orientados a objetos existentes, porque es sólo un lenguaje de modelado, no un método, su complejidad puede convertirse en un obstáculo para ganar un gran número de usuarios;
Orientado a objetos, métodos de modelado, lenguajes de modelado
Número de clasificación de la biblioteca de China TP311
Descripción general del lenguaje de modelado unificado
Shao Weizhong y Hong Mei
(Departamento de Ingeniería y Ciencias de la Computación; Tecnología, Universidad de Pekín, Beijing 100871)
El lenguaje de modelado unificado (UML) publicado por Rational Software Corporation y otros socios de UML está en El campo de la tecnología de objetos ha atraído una amplia atención. Se presentan los antecedentes históricos y el contenido principal de UML, y se discute su importancia, impacto positivo y posibles problemas. UML es un lenguaje de modelado expresivo y poderoso, sin embargo, no se puede concluir que reemplazará todos los métodos de diseño y análisis orientados a objetos existentes; La razón es que UML es solo un modelo de modelado, no un método, y su excesiva complejidad puede convertirse en un obstáculo para conquistar una gran cantidad de usuarios.
Palabras clave orientada a objetos, método de modelado, lenguaje de modelado
1 Antecedentes de UML
Debido a la creciente importancia del método OOA/OOD, la gente está pagando más La atención al entusiasmo por su investigación, desarrollo y aplicación también está creciendo. En 1989, había casi 10 métodos OOA/OOD o lenguajes de modelado OO en forma de monografías, artículos o informes técnicos. En 1944, el número de métodos OOA había aumentado a más de 50. La aparición de diversos métodos ha aportado contribuciones más o menos nuevas a la investigación y el desarrollo de la tecnología OOA/OOD. Esta situación en auge 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 varios métodos también trae algunos problemas: los conceptos adoptados por varios métodos OOA y OOD tienen muchas similitudes y también algunas diferencias (por ejemplo, muchos métodos en la misma parte), en términos de notación de representación, Las diferencias en los modelos OOA y la organización de los documentos son aún más obvias, lo que 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.
En respuesta a esta situación, G. Booch y J. Rumbaugh, que trabajaron en Rational Software Company en Estados Unidos en 1994, creyeron que sus respectivos métodos (método Booch [1] y OMT [2] ) deben combinarse. Comenzaron el trabajo ese junio. Y en 1995, la primera versión se lanzó públicamente el 10 de octubre de 1995, que era el método unificado 0.8. En el otoño de 1995, el iniciador de OOSE, I. Jacobson [3], se unió a Rational Software Company y, por lo tanto, se unió a las filas. . G. Booch, J. Rumbaugh y I. Jacobson. Hay tres razones para proponer un lenguaje de modelado unificado: 1. Los métodos respectivos se han combinado en la evolución; segundo, avanzar hacia la unificación traerá beneficios para el mercado; tercero, ayudará a mejorar los métodos respectivos, obteniendo así más estudiantes; resolver algunos problemas que sus respectivos métodos no pudieron resolver bien en el pasado.
Para determinar un conjunto de símbolos para el análisis y el diseño, se encontraron con algunas compensaciones. Primero, defina el alcance del problema. Por ejemplo, ¿deberían incluirse especificaciones de requisitos? (La respuesta es sí, debería incluirse parcialmente); ¿deberían incluirse lenguajes de programación visual? (La respuesta es "no"). En segundo lugar, es necesario llegar a un compromiso entre expresividad y brevedad. Una representación demasiado simple limitará la capacidad de resolver problemas, y una representación demasiado compleja dejará perdidos a los desarrolladores comunes.
En tercer lugar, tuvieron que combinar según sus tres métodos originales, lo que también les hizo preocuparse por el tamaño de los cambios en los métodos originales. Hacer demasiados cambios confundirá a los usuarios antiguos y, si conserva el material original, perderá la oportunidad de realizar mejoras y ganar más usuarios nuevos. De acuerdo con estas cuestiones mencionadas 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 algunos antecedentes prácticos relacionados con la empresa, los usuarios antiguos y los 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 el 10 de junio y junio respectivamente. Desde entonces, el "Método unificado" pasó a llamarse "Lenguaje de modelado unificado" porque no es exactamente un método de modelado orientado a objetos. Es un lenguaje de modelado orientado a objetos. Simplemente proporciona un conjunto de elementos y símbolos para modelar y define su semántica, en lugar de decir cómo modelar el sistema. Como señaló M. Fowler en su libro sobre UML [4], "UML se llama lenguaje de modelado, no método. Al menos en principio, la mayoría de los métodos constan de un lenguaje de modelado y un proceso * * * . El lenguaje de modelado es uno de ellos. El proceso es una recomendación sobre qué pasos se deben seguir en el diseño "Este libro de M. Fowler está escrito en el contexto de UML1.0, por G. Booch, I. Jacobson y J. Rumbaugh escribieron el prefacio. al libro mismo. Esto al menos demuestra que la evaluación general de UML en la especificación es reconocida por su fundador.
En 1996, Rational se preparó para postularse al Object Management Group (OMG) para utilizar UML como lenguaje de modelado estándar. Entonces se estableció una organización asociada a UML, que incluía a la propia Rational y a 12 empresas. Lanzaron la versión UML1.0. En 1997 se presentó una solicitud a OMG como propuesta preliminar. En 1997, varias otras empresas presentaron sus propias solicitudes de propuestas de lenguaje de modelado a OMG. Por lo tanto, los socios de UML incorporan estas empresas a sus filas. Para reflejar las opiniones de estos nuevos miembros, se revisó UML 1.0. Uml 1.1 se produjo el 1 de septiembre de 1997 y se envió a OMG, que lo adoptó ese mismo año. Actualmente UML1.1 es la última versión, pero no es la versión final. Porque todavía se está modificando. A partir del lanzamiento de UML 1.1, las siguientes 17 empresas participan en la Iniciativa 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 lenguaje de construcción y documentación visual para especificaciones de productos de sistemas de software, y también se puede utilizar para modelado de negocios y otros sistemas que no son software." UML 1.1 proporciona seis documentos, todos publicados conjuntamente bajo los nombres de 17 empresas de la organización asociada de UML. Esta sección presenta brevemente estos documentos y luego los presenta en la siguiente sección.
(1) Descripción general de UML: Es una introducción general a UML, incluyendo su motivación, objetivos, alcance, historia y situación actual.
(2) Semántica de UML: define la semántica de UML. Esta definición emplea técnicas formales pero no es una especificación completamente formal. Las estructuras sintácticas se describen con precisión 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 y se puede asignar a diferentes sistemas de símbolos. Aunque no es completamente formal, su definición es bastante compleja: adopta una arquitectura de metamodelo de cuatro niveles y la extensión del texto alcanza más de 160 páginas.
En la Sección 2.2 de este documento, se presentan los cuatro niveles del modelo, a saber:
Metamodelo: la arquitectura básica del metamodelo, que define el lenguaje para describir el metamodelo.
Metamodelo: Meta: un ejemplo de metamodelo que define un lenguaje para describir un modelo.
Modelo: Un ejemplo de metamodelo que define un lenguaje para describir un dominio de información.
④Objeto de usuario: una instancia del modelo que define un dominio de información específico.
La definición de los elementos del modelo en cada nivel es la siguiente: primero se proporciona su sintaxis abstracta (usando la representación del diagrama de clases UML para describir la relación entre elementos), y luego se dan sus reglas formales (usando texto y lenguaje de restricción de objetos) y finalmente describir su semántica (usando texto exacto). Esto define un total de 118 elementos, divididos en 3 partes y 9 paquetes.
(3) Guía de notación UML: este documento brinda una representación visual de UML y proporciona símbolos de representación gráfica de elementos del modelo a través de ejemplos. Consulte la siguiente sección para obtener más detalles.
(4) Especificación del lenguaje de restricción de objetos: este documento define e introduce un lenguaje de restricción de objetos (OCL), que se utiliza para explicar algunas funciones que no se pueden usar en el modelo de sistema gráfico. Es un lenguaje formal, pero fácil de escribir y leer. Como lenguaje de modelado, no pretende ser un problema de implementación. En otras palabras, se utiliza para explicar el modelo en detalle, no para compilarlo.
(5) Extensión UML del proceso objetivo de ingeniería de software: según las necesidades de la ingeniería de software, se definen algunos conceptos de extensión UML. Por ejemplo, los modelos se dividen en cuatro tipos: modelos de casos de uso, modelos de análisis, modelos de diseño y modelos de implementación. Se dan definiciones de cada concepto de modelo extendido. No presenta el proceso de desarrollo orientado a objetos ni habla sobre cómo utilizar UML en el proceso. El documento es muy breve, sólo 5 páginas.
(6) Extensión UML para modelado de negocios: Define algunos conceptos de extensión UML para modelado de negocios, similar al documento anterior, excepto que su extensión es para modelado de procesamiento de negocios general, no para proyectos de software. El expediente también es muy breve.
3 Guía de notación UML
Este documento proporciona una representación visual de UML y proporciona símbolos de representación gráfica de elementos del modelo a través de ejemplos. Desde la perspectiva del nivel del modelo del sistema, la representación UML consta de nueve tipos de diagramas, que son:
Diagrama de estructura estática, incluidos diagramas de clases y diagramas de objetos;
Diagrama de casos de uso;
Diagrama de secuencia;
Diagrama de colaboración;
Diagrama de gráfico de estado;
Diagrama de actividad;
Diagrama de implementación , incluido el diagrama de componentes y el diagrama de implementación.
Aunque el documento UML dice "La Guía de símbolos UML define símbolos y proporciona ejemplos", la declaración exacta debería ser: el documento proporciona una descripción general de los símbolos de los elementos de modelado y el dibujo de sus gráficos utiliza ejemplos. Representación, no se da ningún diagrama general. La mayoría de las ilustraciones de este artículo se dan en un sentido general con referencia al libro de M. Fowler [4].
UML define algunos elementos de uso común en varios diagramas, como cadenas (nombres), etiquetas (etiquetas), palabras clave (palabras clave), expresiones (expresiones), comentarios (columnas de comentarios) y espere. , y se dan sus símbolos. Por ejemplo, las palabras clave están representadas por cadenas contenidas en los títulos de los libros. El campo de comentarios está representado por texto en un rectángulo con las esquinas dobladas. En varios diagramas, el elemento utilizado para encapsular un grupo de elementos del modelo se denomina "paquete", que está representado por un cuadro grande que rodea el grupo de elementos y un cuadro pequeño en la esquina que indica el nombre del paquete.
Además, UML también define algunos elementos llamados "mecanismos de extensión". Estos elementos se pueden adjuntar a otros elementos del modelo, especializar los elementos de modelado originales en nuevas variantes con semántica especial o expresar algunos detalles sobre ellos. Estos elementos pueden servir para ampliar o perfeccionar la representación. Ellos son:
Restricciones: Las restricciones son relaciones semánticas entre elementos del modelo que explican ciertas condiciones y algunas proposiciones que deben seguir siendo verdaderas.
Su representación consiste en escribir una cadena de texto que represente la condición entre llaves en un lenguaje que pueda ser reconocido por herramientas (como OCL proporcionada por UML).
Comentario: Un comentario es una cadena de texto escrita en el símbolo de la columna de comentarios (un rectángulo con las esquinas dobladas). El lenguaje utilizado debe ser fácil de entender para las personas, ya sea que la herramienta lo entienda o no.
Atributos de elementos: se utilizan para mostrar algunas características incidentales de los elementos del modelo, como atributos, asociaciones, valores objetivo, etc. Su expresión es utilizar llaves para escribir cadenas de texto en forma de palabras clave = valores y separar varias cadenas con comas.
Prototipo (Estereotipo): se utiliza para adjuntar a otros elementos del modelo y especializar los elementos del modelo original en nuevas variantes con semántica especial. Un elemento de modelo con diseño puede considerarse una subclase del elemento de modelo original, que tiene la misma forma que el elemento original en términos de atributos y relaciones, pero de uso más específico. El tipo de placa se indica mediante la palabra clave contenida en el título del libro. En la Figura 1 se muestra una representación de los conceptos anteriores.
Figura 1 Elementos gráficos, paquetes y mecanismos de extensión
A continuación se presentan varios gráficos y los elementos de modelado y representaciones utilizados en los gráficos.
(1) Diagrama de estructura estática
El diagrama de estructura estática incluye diagrama de clases y diagrama de objetos. "Un diagrama de clases es una representación gráfica de un modelo estructural estático." "Un diagrama de clases es una colección (estáticamente) declarada de elementos de modelo". Con respecto a los diagramas de objetos, la documentación dice: "Un diagrama de objetos es un diagrama de una instancia". Incluyendo los valores de los objetos y los datos, un diagrama de objetos estáticos es un ejemplo de un diagrama de clases. Muestra una instantánea del estado detallado del sistema en un momento determinado. La documentación también establece que "los gráficos de objetos son de uso muy limitado" y "no se requieren herramientas para admitir gráficos de objetos independientes". Los diagramas de clases pueden contener objetos. Un diagrama de clases que contiene objetos pero no clases es un "diagrama de objetos". Sin embargo, el término sigue siendo útil para describir el "uso especial" que se puede implementar de varias maneras. En la siguiente figura se muestra una representación de los distintos elementos de modelado utilizados en un diagrama de estructura estática.
Figura 2. Estructura estática Representación de elementos de modelado en diagramas
Clase: Una clase es una descripción de un grupo de objetos con estructura, comportamiento y relaciones similares. UML proporciona tres representaciones gráficas para una clase 1. Es una especie de oculta. Método de detalles, solo se proporciona el nombre de la clase en un cuadro. El segundo método es el método detallado a nivel de análisis, y el nombre de la clase, el nombre del atributo, el tipo y el nombre de la operación se proporcionan en las columnas superior, media e inferior respectivamente. ; el tercer método es el método de detalles a nivel de implementación, que proporciona más detalles.
Intervalo de nombre: define la especificación de escritura de la columna de nombre del símbolo de clase. escritura de la columna de atributos y la columna de operación del símbolo de clase
Especificación de atributo: especifique el método de escritura del atributo y los siguientes tres símbolos de visibilidad: "" significa público, "#" significa protegido y ". -" significa operación privada.: Especifica cómo se escribe la operación, utilizando tres símbolos de visibilidad iguales que el atributo.
Tipo y clase de implementación: estos son dos elementos de clase especiales, al agregar la palabra clave de diseño "tipo " al símbolo de clase. " o "clase de implementación", obtenida al proporcionar los detalles de definición de los atributos y operaciones en la columna de atributos y la columna de operaciones. Entre ellos, "tipo" describe las reglas mutables que un objeto puede adoptar y luego descartar. ; “clase de implementación” define Los siguientes siete símbolos se derivan de las estructuras y procesos de datos físicos cuando un objeto se implementa en un lenguaje.
Interfaz: Una interfaz es una descripción de las operaciones visibles externamente de una clase. u otra entidad (como un paquete). No describe la estructura de la entidad. Se representa como un símbolo de clase, pero no hay una columna de atributo. Agregue la palabra clave "interfaz" en la columna de acción. >
Clase parametrizada.(Plantilla): Es una clase con uno o más parámetros formales independientes, por lo que define una familia de clases y vincula los parámetros formales a un valor real para explicar la representación de una de las clases. un cuadro de puntos en la esquina superior derecha del símbolo de clase. En este cuadro se explican los diferentes tipos de implementación de cada parámetro formal.
Elemento de enlace: Su función es asociar los parámetros de la plantilla con el valor real. (Encuadernación). Su función es explicar la tabla de valores de parámetros de la plantilla en texto.
Utilidades: Conjunto de variables y procedimientos globales declarados como una clase. No es una estructura básica, sino una herramienta 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: Una clase de clases cuyas instancias son clases. La actuación consiste en agregar la palabra clave "metaclase" en la lista de nombres de clases.
Nombre de ruta de clase: se utiliza para representar una referencia a una clase. El símbolo es el símbolo "∷" utilizado para representar el nombre de la clase a la que se hace referencia (en otros paquetes) donde se hace referencia a esta clase.
Importar paquete: Indica que se puede hacer referencia a una clase en otro paquete en un paquete. Este es un tipo especial de dependencia. Toma la forma de agregar la palabra clave "importar" 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 "Nombre" se completa con el nombre del objeto (instancia) e indica el nombre de la clase a la que pertenece. El valor de cada atributo se proporciona en la columna de atributos.
Objeto compuesto: un objeto de alto nivel compuesto por algunas partes estrechamente relacionadas. Es un ejemplo de una clase compuesta. Está representado por un cuadro con dos columnas. Complete el nombre del objeto compuesto en la columna superior e indique su nombre de clase, y dibuje sus objetos parciales individuales en la columna inferior.
Asociación: Se divide en asociación binaria y asociación múltiple. Se introducen los siguientes elementos respectivamente.
Asociación binaria: Es una asociación entre dos clases (incluyendo un caso especial de asociación entre una clase y ella misma). Se expresa conectando dos símbolos de clase con una línea continua. Esta línea puede trazarse como una línea recta, una línea diagonal o una curva según la conveniencia del dibujo, o puede estar compuesta por varios segmentos. El lugar donde el punto final de la línea cruza el símbolo de clase se llama punto final asociado, y se puede marcar información útil cerca del punto final. Indique diferentes casos de asociación (que se describen más adelante). La asociación completa también puede contener información adicional, que incluye: nombre de la asociación, que indica la función de la asociación. Los símbolos de clase son los mismos que los símbolos de clase ordinarios, pero deben adjuntarse a una asociación para indicar los atributos y operaciones de la asociación. Estas cosas son opcionales, no obligatorias.
AssociationEnd: El final de la asociación no es un elemento independiente, sino una parte de la asociación, que se utiliza para mostrar algunos detalles de la asociación. Algunos detalles se expresan añadiendo algunos caracteres o gráficos al lado del final de la asociación. Incluye diversidad, ordenamiento, calificadores, nombres de roles, mutabilidad y visibilidad. Otros detalles están representados por las diferentes formas de los puntos finales de la línea de asociación, que incluyen: Una flecha hueca representa la navegabilidad, lo que indica que se puede encontrar la instancia del objeto en un extremo de la asociación. Una flecha de diamante hueca representa agregación, lo que indica que la instancia de objeto en un extremo de la asociación es un componente de la instancia de objeto en el otro extremo; una flecha de diamante sólida representa una forma fuerte de agregación, llamada composición.
Multiplicidad: marque el punto final de la asociación con un número (que representa un número específico) o * (que representa múltiples) para indicar cuántas instancias de objeto están asociadas con la instancia de objeto en el otro extremo.
Calificador, dibuje un cuadro rectangular donde un extremo de la asociación interactúa con el símbolo de clase y proporcione algunos valores de atributo en el cuadro para indicar qué condiciones tiene el objeto en el otro extremo de la asociación. se reúne para poder comunicarse con el objeto en este extremo. Es parte de una asociación, no de una clase.
La clase de asociación se utiliza para indicar que una asociación tiene las características de una clase (incluidos atributos y operaciones), expresadas con símbolos de clase ordinarios y adjuntas a la línea de asociación.
La asociación N-aria, la asociación entre tres o más clases, se representa trazando una línea de conexión desde el diamante hasta cada símbolo de clase relacionado.
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 con las partes y tiene el mismo tiempo de supervivencia. Se representa agregando una flecha de diamante sólida al final de la línea de asociación.
Enlace (cadena) es una instancia de asociación, que representa la conexión entre dos objetos. Su rendimiento es trazar una línea recta entre dos instancias de objetos.
Generalización: “Es una relación taxonómica entre un elemento más general y un elemento más específico que es completamente coherente con él, añadiendo más información.
"Este concepto es básicamente el mismo que la" relación de herencia "o" relación especial general "mencionada en la mayoría de los documentos técnicos de OO. Sin embargo, la generalización de UML no solo se usa para expresar la relación entre clases, sino también para elementos como paquetes. y casos de uso. Hay dos formas de expresarlo: una es el método de disfrute * * *, dibuja un triángulo al lado del símbolo del elemento general y dibuja una línea de conexión desde la parte inferior del triángulo. varias ramas, que están conectadas a cada elemento especial; la otra está descentralizada, dibujando múltiples triángulos al lado del símbolo del elemento general y dibujando una línea en la parte inferior de cada triángulo que conduce a un elemento especial. etiqueta denominada discriminador al lado de la línea. Indica qué es confidencial.
Dependencia: UML define la semántica de dependencia de la siguiente manera: "Indica la relación semántica entre dos (o más) elementos del modelo. Su significado se refiere sólo a los elementos mismos, no a sus instancias. Indica que los cambios en el elemento de destino en esta dependencia pueden requerir cambios en el elemento de origen. Existen los siguientes tipos de dependencias:
Traza-traza: la conexión histórica entre dos elementos que representan el mismo concepto en diferentes niveles de significado.
Refinamiento-Refinamiento: Una conexión histórica o derivada entre dos elementos que tiene una relación mapeada (no necesariamente completa).
Finalidad-Uso: La correcta implementación o desempeño funcional de un elemento requiere de otro elemento.
Bind-Binding: vincula parámetros de plantilla a valores reales para crear elementos no paramétricos.
Las dependencias se representan dibujando una línea de puntos con una flecha entre dos elementos del modelo, al lado de donde pertenece la dependencia, o agregando un nombre. La "Guía de notación UML" no habla de su conexión y diferencia con el concepto de mensaje al introducir relaciones de dependencia. Conceptos UML como "mensaje" y "flujo de mensajes" se utilizan en diagramas de secuencia y dibujos de colaboración, respectivamente (ver más adelante). Sin embargo, M.Fowler explicó en la referencia [4]: "Para una clase, la existencia de dependencias puede deberse a las siguientes razones: una clase envía mensajes a otras clases; una clase usa otras clases como parte de sus datos; Una clase se refiere a otras clases como parámetros de una operación.
Elementos derivados: Los elementos derivados son elementos que se pueden calcular a partir de otros elementos, pero que pueden hacerlo más claro o más beneficioso para el diseño. agregue una barra diagonal "/" 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 actores y casos de uso. Relación. "El modelo de caso de uso expresa la funcionalidad del sistema o clase a los interactuantes fuera del sistema". UML define los siguientes elementos que componen el diagrama de caso de uso (que se muestra en la Figura 3).
Figura 3 Diagrama de casos de uso
p>Caso de uso: un caso de uso es una unidad compacta de funcionalidad proporcionada por un sistema o clase, que está representada por la secuencia de mensajes intercambiados entre el sistema y uno o más interactuantes externos ( es decir, actores) y las actividades realizadas por el sistema.
Actor: un actor es un rol desempeñado por un objeto externo que interactúa directamente con el sistema.
Las relaciones de casos de uso incluyen. las siguientes tres relaciones: Comunicación, que es entre actores y casos de uso. La única relación es la participación del actor en la extensión del caso de uso, la relación de extensión del caso de uso A al caso de uso B indica una instancia de B (bajo el especial); condiciones descritas por la extensión) pueden contener el comportamiento descrito en A; uso: de A a B La relación de uso indica que la instancia de A también incluye el comportamiento descrito en B.
(3) Diagrama de secuencia
UML proporciona dos formas de diagramas de interacción, uno se llama diagrama de secuencia y el otro se llama diagrama de colaboración. Se basan en la misma información básica pero enfatizan diferentes aspectos. En particular, muestra las interacciones en las que participan los objetos. en su línea de vida y en el tiempo. Mensajes intercambiados secuencialmente. No muestra la relación entre objetos. Un diagrama de secuencia representa un conjunto de mensajes intercambiados cuando los objetos colaboran para producir una operación o resultado requerido. forma y forma detallada Un método de dibujo es básicamente consistente con el diagrama de interacción introducido en trabajos como OOSE [3] - que muestra los objetos que participan en la interacción horizontal y verticalmente.
El plano completo muestra la relación espaciotemporal entre objetos y el diagrama de secuencia se muestra en la Figura 4. Los elementos de modelado utilizados para los diagramas de secuencia son:
Figura 4 Diagrama de secuencia
Línea de vida del objeto: una línea de puntos vertical que muestra el papel de un objeto en el rango de tiempo desde su creación hasta su cancelación.
Activación: Muestra el período de tiempo durante el cual un objeto realizó actividades directamente o a través de sus procesos subordinados.
Mensaje: Mensaje es comunicación entre objetos, se utiliza para transmitir información y esperar determinadas actividades. La recepción de un mensaje es un evento.
Tiempo de transmisión: El tiempo que se tarda en enviar o recibir un mensaje. Los dos pueden ser iguales o diferentes.
(4) Diagrama de colaboración
El diagrama de colaboración es otro diagrama de interacción mencionado por UML. Representa las operaciones organizadas entre algunos objetos y las cadenas entre ellos. A diferencia de los diagramas de secuencia, los diagramas de colaboración representan relaciones entre roles de objetos en lugar de orden temporal. Un diagrama de colaboración describe la colaboración entre un conjunto de objetos relacionados en un contexto específico. y un conjunto de mensajes intercambiados cuando este conjunto de objetos colaboran para producir una operación o resultado deseado. La representación gráfica de un diagrama de colaboración utiliza objetos como nodos, incluidas líneas de flechas que representan mensajes y líneas de conexión que representan asociaciones entre nodos. Hay tres tipos de líneas de mensajes, que representan tres mensajes diferentes, a saber, llamada, flujo de control y asíncrono. Sin embargo, hay algunas situaciones que no se pueden expresar, como la resistencia y el tiempo de espera. Se requiere alguna notación más ampliada. Los símbolos relacionados utilizados en los diagramas de colaboración también incluyen muchos casos de puntos finales diferentes, como calificadores, combinaciones, 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 incluyen colaboración, contenido de colaboración, interacción, estructura de patrón, rol de colaboración, múltiples objetos y Los objetos activos, el flujo de mensajes y las etiquetas de creación/destrucción no se introducirán aquí.
(5) Gráfico de estados
El gráfico de estados también se denomina máquina de estados en UML. Representa la secuencia de estados de un objeto o de una interacción cuando es estimulado a lo largo de su vida, así como sus reacciones y actividades. Está adjunto a una clase o método. Los elementos de modelado utilizados para construir diagramas de estado son: estado, estado compuesto, subestado, evento, transición simple, transición compleja y estado de anidamiento (Nested State), envío de mensaje (Sending Message), cambios internos, etc. La representación del diagrama de estado y sus elementos relacionados es similar a la mayoría de los métodos OOA/OOD existentes y no se describirá en detalle aquí.
(6) Diagrama de actividad
El diagrama de actividad es una variación del diagrama de estado. Su estado indica la actividad realizada por la operación y sus transiciones se activan cuando la operación se completa. Representa la máquina de estados del proceso mismo. Un proceso es la implementación de una operación dentro de una clase. Los elementos que componen el diagrama de actividades son: estados de acción, decisiones, carriles de nado (los carriles de nado se dibujan en el diagrama como una piscina, y cada grupo de actividades se coloca en un carril de nado diferente para que quede más claro), acción-objeto. relación de flujo (Relaciones de flujo actividad-objeto, que representan mensajes y relaciones de entrada/salida entre una actividad y objetos relacionados), iconos de control (que representan el envío y recepción de señales), etc. El diagrama de actividades se muestra en la Figura 6.
Figura 6 Diagrama de actividades
(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. Hay dos tipos de diagramas de implementación, uno es el diagrama de componentes que muestra la estructura del código y el otro es el diagrama de extensión que muestra la estructura del sistema de tiempo de ejecución.
Un diagrama de componentes muestra las dependencias entre los componentes de software, como el código fuente, el código binario y el código ejecutable. La figura muestra varios módulos de software.