Menú
Es gratis
registro
casa  /  Firmware/ Diagrama UML. Tipos de diagramas UML

Diagrama UML. Tipos de diagramas UML

UML (Unified Modeling Language) es un lenguaje de descripción gráfica para el modelado de objetos en el desarrollo de software. UML es un lenguaje de base amplia, un estándar abierto que usa notación gráfica para crear un modelo abstracto de un sistema llamado modelo UML. El UML fue creado para definir, visualizar, diseñar y documentar principalmente sistemas de software. UML no es un lenguaje de programación, pero la generación de código es posible mediante la ejecución de modelos UML como código interpretado. Wikipedia

Productos comerciales

Microsoft Visio

Tipo: software comercial

Popular software de Microsoft, que le permite dibujar diagramas enriquecidos, incluido UML:

A partir de la versión 2010, fue posible publicar diagramas en la web (SharePoint + Visio Services):

Visor de Visio- un programa gratuito que le permite ver diagramas de Visio creados previamente. Puede descargar por% D1% 81% D1% 81% D1% 8B% D0% BB% D0% BA% D0% B5% 20.

% 0A

Microsoft% 20Visual% 20Studio% 202010

% 0A

% D0% A2% D0% B8% D0% BF:% 20% D0% BA% D0% BE% D0% BC% D0% BC% D0% B5% D1% 80% D1% 87% D0% B5% D1% 81% D0% BA% D0% BE% D0% B5% 20% D0% 9F% D0% 9E% 20 (% D0% B5% D1% 81% D1% 82% D1% 8C% 20% D0% B1% D0 % B5% D1% 81% D0% BF% D0% BB% D0% B0% D1% 82% D0% BD% D0% B0% D1% 8F% 20 Expreso% 20% D0% B2% D0% B5% D1% 80 % D1% 81% D0% B8% D1% 8F).

% 0A

% D0% 92% 20% D0% BF% D0% BE% D1% 81% D0% BB% D0% B5% D0% B4% D0% BD% D0% B5% D0% B9% 20% D0% B2% D0 % B5% D1% 80% D1% 81% D0% B8% D0% B8% 20 Microsoft% 20Visual% 20Studio% 202010% 20% D0% BF% D0% BE% D1% 8F% D0% B2% D0% B8% D0% BB% D1% 81% D1% 8F% 20% D0% BD% D0% BE% D0% B2% D1% 8B% D0% B9% 20% D1% 82% D0% B8% D0% BF% 20% D0% BF% D1% 80% D0% BE% D0% B5% D0% BA% D1% 82% D0% B0% 20-% 20 Modelado,% 20% D0% BA% D0% BE% D1% 82% D0 % BE% D1% 80% D1% 8B% D0% B9% 20% D0% BF% D0% BE% D0% B7% D0% B2% D0% BE% D0% BB% D1% 8F% D0% B5% D1 % 82% 20% D1% 80% D0% B8% D1% 81% D0% BE% D0% B2% D0% B0% D1% 82% D1% 8C% 20% D1% 80% D0% B0% D0% B7 % D0% BB% D0% B8% D1% 87% D0% BD% D1% 8B% D0% B5% 20UML% 20% D0% B4% D0% B8% D0% B0% D0% B3% D1% 80% D0 % B0% D0% BC% D0% BC% D0% B0% 20% D0% B8% 20% D0% BF% D1% 80% D0% BE% D0% B2% D0% B5% D1% 80% D1% 8F % D1% 82% D1% 8C% 20% D0% BD% D0% B0% D0% BF% D0% B8% D1% 81% D0% B0% D0% BD% D0% BD% D1% 8B% D0% B5 % 20% D1% 80% D0% B5% D1% 88% D0% B5% D0% BD% D0% B8% D1% 8F% 20% D0% BD% D0% B0% 20% D1% 81% D0% BE % D0% BE% D1% 82% D0% B2% D0% B5% D1% 82% D1% 81% D1% 82% D0% B2% D0% B8% D0% B5% 20% D1% 81% 20% D0 % BD% D0% B5% D0% BE% D0% B1% D1% 85% D0% BE% D0% B4% D0% B8% D0% BC% D0% BE% 20% D0% B0% D1% 80% D1 % 85% D0% B8% D1% 82% D0% B5% D0% BA% D1% 82% D1% 83% D1% 80% D0% BE% D0% B9.

% 0A

% D0% 9F% D0% BE% D0% B7% D0% B2% D0% BE% D0% BB% D1% 8F% D0% B5% D1% 82% 20% D0% B3% D0% B5% D0% BD % D0% B5% D1% 80% D0% B8% D1% 80% D0% BE% D0% B2% D0% B0% D1% 82% D1% 8C% 20 Secuencia% 20 Diagrama% 20% D0% BD% D0% B0% 20% D0% BE% D1% 81% D0% BD% D0% BE% D0% B2% D0% B0% D0% BD% D0% B8% D0% B8% 20% D0% BA% D0% BE% D0% B4% D0% B0,% 20% D0% B2% D0% B8% D0% B7% D1% 83% D0% B0% D0% BB% D0% B8% D0% B7% D0% B8% D1% 80 % D0% BE% D0% B2% D0% B0% D1% 82% D1% 8C% 20% D1% 81% D0% B2% D1% 8F% D0% B7% D0% B8% 20% D0% B2% 20 % D0% BF% D1% 80% D0% BE% D0% B5% D0% BA% D1% 82% D0% B5% 20% D0% BC% D0% B5% D0% B6% D0% B4% D1% 83 % 20% D0% BA% D0% BE% D0% BC% D0% BF% D0% BE% D0% BD% D0% B5% D0% BD% D1% 82% D0% B0% D0% BC% D0% B8 ,% 20% D1% 81% D0% B1% D0% BE% D1% 80% D0% BA% D0% B0% D0% BC% D0% B8% 20% D0% B8% 20% D1% 81% D1% 81% D1% 8B% D0% BB% D0% BA% D0% B0% D0% BC% D0% B8% 20% D0% B8% 20% D1% 82.% D0% B4.

% 0A

% D0% 9F% D1% 80% D0% B8% D0% BC% D0% B5% D1% 80% 20Uso% 20case% 20% D0% B4% D0% B8% D0% B0% D0% B3% D1% 80 % D0% B0% D0% BC% D0% BC% D1% 8B,% 20% D0% BD% D0% B0% D1% 80% D0% B8% D1% 81% D0% BE% D0% B2% D0% B0% D0% BD% D0% BD% D0% BE% D0% B9% 20% D0% B2% 20Visual% 20Studio% 202010:

% 0A% 0A

% D0% 9A% D1% 80% D0% BE% D0% BC% D0% B5% 20% D1% 82% D0% BE% D0% B3% D0% BE,% 20% D0% B4% D0% BE% D1% 81% D1% 82% D1% 83% D0% BF% D0% B5% D0% BD% 20 Visualización% 20 y% 20 Modelado% 20 Característica% 20 Paquete% 20 (% D0% B4% D0% BB% D1% 8F% 20 % D0% BF% D0% BE% D0% B4% D0% BF% D0% B8% D1% 81% D1% 87% D0% B8% D0% BA% D0% BE% D0% B2% 20MSDN),% 20 % D0% BA% D0% BE% D1% 82% D0% BE% D1% 80% D1% 8B% D0% B9% 20% D0% BF% D0% BE% D0% B7% D0% B2% D0% BE % D0% BB% D1% 8F% D0% B5% D1% 82:

% 0A
  • % D0% B3% D0% B5% D0% BD% D0% B5% D1% 80% D0% B8% D1% 80% D0% BE% D0% B2% D0% B0% D1% 82% D1% 8C% 20 % D0% BA% D0% BE% D0% B4% 20% D0% BD% D0% B0% 20% D0% B1% D0% B0% D0% B7% D0% B5% 20UML% 20% D0% B4% D0 % B8% D0% B0% D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% 20% D0% BA% D0% BB% D0% B0% D1% 81% D1% 81% D0 % BE% D0% B2
    • % 0A
  • % D1% 81% D0% BE% D0% B7% D0% B4% D0% B0% D0% B2% D0% B0% D1% 82% D1% 8C% 20UML% 20% D0% B4% D0% B8% D0 % B0% D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% D1% 8B% 20% D0% B8% D0% B7% 20% D0% BA% D0% BE% D0% B4 % D0% B0
    • % 0A
  • % D0% B8% D0% BC% D0% BF% D0% BE% D1% 80% D1% 82% D0% B8% D1% 80% D0% BE% D0% B2% D0% B0% D1% 82% D1 % 8C% 20UML% 20% D0% B4% D0% B8% D0% B0% D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% D1% 8B% 20% D0% BA% D0 % BB% D0% B0% D1% 81% D1% 81% D0% BE% D0% B2,% 20% D0% B4% D0% B8% D0% B0% D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% D1% 8B% 20% D0% BF% D0% BE% D1% 81% D0% BB% D0% B5% D0% B4% D0% BE% D0% B2% D0% B0% D1% 82% D0% B5% D0% BB% D1% 8C% D0% BD% D0% BE% D1% 81% D1% 82% D0% B5% D0% B9,% 20% D0% B4% D0% B8 % D0% B0% D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% D1% 8B% 20% D0% B2% D0% B0% D1% 80% D0% B8% D0% B0 % D0% BD% D1% 82% D0% BE% D0% B2% 20% D0% B8% D1% 81% D0% BF% D0% BE% D0% BB% D1% 8C% D0% B7% D0% BE % D0% B2% D0% B0% D0% BD% D0% B8% D1% 8F% 20% D1% 81% 20XMI% 202.1
    • % 0A
  • % D1% 81% D0% BE% D0% B7% D0% B4% D0% B0% D0% B2% D0% B0% D1% 82% D1% 8C% 20% D0% B4% D0% B8% D0% B0 % D0% B3% D1% 80% D0% B0% D0% BC% D0% BC% D1% 8B% 20% D0% B7% D0% B0% D0% B2% D0% B8% D1% 81% D0% B8 % D0% BC% D0% BE% D1% 81% D1% 82% D0% B5% D0% B9% 20% D0% B4% D0% BB% D1% 8F% 20ASP.NET,% 20C% 20% D0% B8% 20C ++% 20% D0% BF% D1% 80% D0% BE% D0% B5% D0% BA% D1% 82% D0% BE% D0% B2
    • % 0A
  • % D1% 81% D0% BE% D0% B7% D0% B4% D0% B0% D0% B2% D0% B0% D1% 82% D1% 8C% 20% D0% B8% 20% D0% BF% D1 % 80% D0% BE% D0% B2% D0% B5% D1% 80% D1% 8F% D1% 82% D1% 8C% 20capa% 20diagramas% 20% D0% B4% D0% BB% D1% 8F% 20C % 20% D0% B8% 20C ++% 20% D0% BF% D1% 80% D0% BE% D0% B5% D0% BA% D1% 82% D0% BE% D0% B2
    • % 0A
  • % D0% BF% D0% B8% D1% 81% D0% B0% D1% 82% D1% 8C% 20% D1% 81% D0% BE% D0% B1% D1% 81% D1% 82% D0% B2 % D0% B5% D0% BD% D0% BD% D1% 8B% D0% B5% 20% D0% BF% D1% 80% D0% BE% D0% B2% D0% B5% D1% 80% D0% BA % D0% B8% 20% D0% B4% D0% BB% D1% 8F% 20capa% 20diagramas
    • % 0A

% D0% A1% D0% BA% D0% B0% D1% 87% D0% B0% D1% 82% D1% 8C% 20Visualización% 20y% 20Modelado% 20Feature% 20Pack% 20% D0% BC% D0% BE% D0 % B6% D0% BD% D0% BE% 20% D0% BF% D0% BE% 20% D1% 81% D1% 81% D1% 8B% D0% BB% D0% BA% D0% B5:% 20 http://msdn.microsoft.com/ru-ru/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Oportunidades:

  • Use el diagrama del caso
  • Diagrama de despliegue (diagramas de topología);
  • Diagrama de estado;
  • Diagrama de actividad
  • Diagrama de interacción
  • Diagrama de secuencia
  • Diagrama de colaboración
  • Diagrama de clase
  • Diagrama de componentes

Capturas de pantalla:

Programas de código abierto

StarUML

Oportunidades:

  • Soporte UML 2.0
  • MDA (Arquitectura basada en modelos)
  • Arquitectura de complementos (puede escribir en lenguajes compatibles con COM: C ++, Delphi, C #, VB, ...)

StarUML está escrito principalmente en Delphi, pero puede agregar componentes en otros lenguajes, por ejemplo, C / C ++, Java, Visual básico, Delphi, JScript, VBScript, C #, VB.NET. A continuación se muestran varias capturas de pantalla.

Diagrama de clase:

Use el diagrama del caso:

ArgoUML

Gráficos compatibles:

  • Clase
  • Expresar
  • Caso de uso
  • Actividad
  • Colaboración
  • Despliegue
  • Secuencia

Oportunidades:

  • Soporte para nueve diagramas UML 1.4
  • Independiente de la plataforma (Java 5+)
  • Metamodelo estándar UML 1.4
  • Soporte XMI
  • Exportar a GIF, PNG, PS, EPS, PGML y SVG
  • Idiomas: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
  • Soporte OCL
  • Ingeniería avanzada y reversa

Captura de pantalla:

Muestre el comportamiento de un objeto durante su vida, desde la creación del objeto hasta su destrucción. Cada diagrama de estado representa una especie de autómata.

Plan de ACCION

En la sección Descripción, explore el conjunto básico de símbolos de gráficos de estado que necesita para poder leer los diagramas.

Después de leer las otras secciones (Ejemplo, Aplicación), puede intentar dibujar diagramas de estado usted mismo.

Notas (descripción)

Este es el conjunto de caracteres básico diagramas de estado necesario para poder leer el diagrama. Después de leer las otras secciones ("Ejemplo", "Aplicación"), podrá redactar diagramas de estado¡por propia cuenta!

Término Imagen Descripción
Pseudoestado inicial Estado inicial del sistema
Transición La transición significa pasar de un estado a otro.
Expresar Indica acciones realizadas por el sistema (pueden incluir posibles opciones) conduciendo a los resultados observados por los actores.
Expresar
estado de actividad		 Un paso complejo en un caso de uso se puede representar mediante otro caso de uso.
En términos de UML, decimos que el primer caso de uso incluye el segundo.
Estado final Le permite definir los límites de sistemas o subsistemas.
Actividades internas El caso en el que los estados pueden reaccionar a los eventos sin hacer una transición, en cuyo caso el evento, la protección y la actividad se colocan dentro del rectángulo de estado.
Actividad de entrada La actividad de entrada se ejecuta cada vez que ingresa al estado
Actividad de salida Actividad de salida: se ejecuta cada vez que abandona el estado.
Superestado
A menudo sucede que varios estados tienen transiciones y actividades internas comunes. En tales casos, puede convertirlos en subestados y mover el comportamiento general a un superestado.
Estados paralelos
Los estados se pueden dividir en varios estados simultáneos que se ejecutan al mismo tiempo.

Cómo aplicar la técnica de la creatividad.

Los diagramas de estado UML son buenos para describir el comportamiento de un solo objeto en múltiples casos de uso. Pero no son muy adecuados para describir un comportamiento caracterizado por la interacción de muchos objetos. Por lo tanto, tiene sentido utilizar otras tecnologías junto con los diagramas de estado. Por ejemplo, los diagramas de interacción (Capítulo 4) describen perfectamente el comportamiento de varios objetos en un solo caso de uso y los diagramas de actividad UML bueno para mostrar el flujo básico de múltiples objetos en múltiples casos de uso.

No todo el mundo considera que los gráficos de estado sean naturales. Observe cómo los especialistas trabajan con ellos. Es posible que los miembros de su equipo no crean que los gráficos de estado son adecuados para su estilo de trabajo. Ésta no es la mayor dificultad; debes recordar compartir diferentes técnicas de trabajo.

Si está utilizando diagramas de estado, no intente dibujarlos para cada clase del sistema. Este enfoque se utiliza a menudo con el fin de completar formalmente estrictamente, pero casi siempre es un desperdicio de energía. Utilice únicamente diagramas de estado para las clases que muestren un comportamiento interesante, donde la creación de un diagrama de estado le ayuda a comprender cómo van las cosas.

Muchos expertos creen que El editor y los controles de la interfaz de usuario tienen funciones que resultan útiles cuando se muestran mediante un diagrama de estado.

Cómo aprender

Aquí hemos intentado ofrecer una forma de aprender lo más sencilla posible. Diagramas de estado UML.

Como muchos otros idiomas, utiliza un conjunto de caracteres para describirlo. El significado de estos símbolos se puede encontrar en la tabla de la sección "Comentarios (descripción)". Cada signo tiene su propio nombre (término) y ortografía. Además, cada término cuenta con una breve explicación para comprender rápidamente su esencia principal.

Además, le recomendamos que vaya a la sección "Ejemplos". diagramas de estado para intentar leer diferentes gráficos. Entonces vale la pena estudiar la sección "Aplicaciones", porque, aunque el número de tipos de diagramas en UML es pequeño, puede obtener el máximo beneficio de su uso solo si usa los diagramas correspondientes para el propósito previsto.

Ejemplo de uso

Diagramas de máquina de estado Es una tecnología conocida para describir el comportamiento de un sistema. Los diagramas de estado han existido de una forma u otra desde 1960, y en los primeros días de la programación orientada a objetos se usaban para representar el comportamiento de un sistema. En los enfoques orientados a objetos, se dibuja un diagrama de estado de una sola clase para mostrar el comportamiento de un solo objeto durante su vida útil.

Siempre que escriben sobre máquinas de estado, inevitablemente se citan como ejemplos los sistemas de control de crucero o las máquinas expendedoras.
Decidimos usar el controlador del panel de control secreto en el castillo gótico. En este castillo queremos esconder nuestros tesoros para que sean difíciles de encontrar. Para acceder a la cerradura de la caja fuerte, debemos sacar una vela estratégica del candelabro, pero la cerradura aparecerá solo si la puerta está cerrada. Después de la aparición de la cerradura, podemos insertar la llave y abrir la caja fuerte. Para mayor seguridad, nos hemos asegurado de que la caja fuerte solo se pueda abrir después de quitar la vela. Si el ladrón no presta atención a esta precaución, entonces desataremos un monstruo espantoso que se tragará al ladrón.

En la Fig. 10.1 espectáculos diagrama de estado la clase de controlador que administra mi inusual sistema de seguridad. Un diagrama de estado comienza con el estado del objeto controlador que se está creando: estados Esperar... Esto se indica en el diagrama con pseudoestado inicial que no es un estado, pero tiene una flecha que apunta al estado inicial.
El diagrama muestra que el controlador puede estar en uno de tres estados: Espere, bloquee y abra... El diagrama también muestra las reglas según las cuales el controlador pasa de un estado a otro. Estas reglas se presentan en forma de transiciones: líneas que conectan estados.

La transición significa pasar de un estado a otro. Cada transición tiene su propia etiqueta, que consta de tres partes:
actividad / firma de disparador... Todos ellos son opcionales. Por lo general, ID de disparador Es el único evento que puede provocar un cambio de estado.

La protección, si se especifica, es una condición booleana que debe cumplirse para que se lleve a cabo la transición. La actividad es algún comportamiento del sistema durante la transición. Puede ser cualquier expresión de comportamiento. La forma completa de un identificador de activación puede incluir múltiples eventos y parámetros. La transición del estado de espera (Fig. 10.1) a otro estado se puede leer como "En el estado de espera, si se quita la vela, verá el candado y pasará al estado de candado".

Las tres partes de la descripción de la transición son opcionales. Saltarse la actividad significa que no sucede nada durante la transición. Omitir guardias significa que siempre se realiza una transición si ocurre un evento desencadenante. El identificador de activación rara vez falta, pero sucede. Esto significa que la transición se produce de forma inmediata, lo que se puede observar principalmente en los estados de actividad.

Cuando un evento ocurre en un cierto estado, entonces solo se puede hacer una transición desde este estado, por ejemplo, en el estado de Bloqueo (Fig. 10.1), las protecciones deben ser mutuamente excluyentes. Si ocurre un evento, pero no hay transiciones permitidas, por ejemplo, cerrar una caja fuerte en el estado de espera o quitar una vela cuando la puerta está abierta, el evento se ignora.

Estado final ( estado final) significa que la máquina de estado ha terminado de ejecutarse, lo que hace que se elimine el objeto controlador. Entonces, para aquellos que tuvieron el descuido de caer en la trampa, informamos que, dado que el objeto controlador deja de existir, nos vemos obligados a volver a colocar al conejo en la jaula, lavar el piso y reiniciar el sistema.

Recuerde que las máquinas de estado solo pueden mostrar objetos que se observan directamente o sobre los que se actúa. Por lo tanto, si bien podría esperar que pongamos algo en la caja fuerte o saquemos algo de allí cuando la puerta esté abierta, no lo marcamos en el diagrama, ya que el controlador no tiene nada que decir al respecto.

Cuando los desarrolladores hablan de objetos, a menudo se refieren al estado de los objetos, es decir, la combinación de todos los datos contenidos en los campos del objeto. Sin embargo, el estado en un diagrama de máquina de estados es un concepto más abstracto de estado; el punto es que diferentes estados implican diferentes caminos reacciones a los eventos.

Actividades internas en el diagrama de estado

Los estados pueden reaccionar a los eventos sin cometer una transición utilizando actividades internas (actividades internas), en cuyo caso el evento, la protección y la actividad se colocan dentro del rectángulo de estado.

En la Fig. 10.2 presenta el estado con actividades internas de símbolos y eventos del sistema de ayuda, que puede observar en los campos de texto del editor Interfaz de usuario... La actividad interna es como una autotransición, una transición que vuelve al mismo estado. La sintaxis de las actividades internas se construye de acuerdo con la misma diagrama de lógica eventos, protecciones y procedimientos.

En la Fig. 10.2 también muestra actividades especiales: actividades de entrada y salida. Actividad de entrada ejecutado cada vez que ingresa a un estado; actividad de salida- siempre que salga del estado. Sin embargo, las actividades internas no inician actividades de entrada y salida; esta es la diferencia entre actividades internas yautotransiciones .

Los estados de actividad en la tabla de estados

En los estados que hemos descrito hasta ahora, el objeto está en silencio y espera el próximo evento antes de hacer nada. Sin embargo, son posibles estados en los que el objeto exhibe alguna actividad.

Expresar buscando en la Fig. 10.3 es tal estado estado de actividad: la actividad en curso se indica con el símbolo hacer /; de ahí el término hacer actividad (ser activo)... Una vez completada la búsqueda, las transiciones se realizan sin actividad, por ejemplo, mostrando nuevos equipos (Mostrar nuevo hardware)... Si un evento de cancelación ( cancelar), entonces hacer actividad solo interrumpe y volvemos al estado Actualizar ventana de hardware.

Tanto las actividades cotidianas como las actividades normales representan la manifestación de algún comportamiento. La diferencia decisiva entre los dos es que las actividades normales son "instantáneas" y no pueden ser interrumpidas por eventos normales, mientras que las actividades de ejecución pueden ejecutarse por un tiempo limitado y pueden interrumpirse, como se muestra en la Fig. 10.3. La instantaneidad se interpreta de manera diferente para diferentes sistemas; para los sistemas en tiempo real, esto puede requerir varias instrucciones de la máquina, y para el software de escritorio, puede tomar varios segundos.

V UML 1 Las actividades comunes se denotaban con el término acción(acción) y el término actividad(actividad) solo se usó para hacer actividades.

Superestados

A menudo sucede que varios estados tienen transiciones y actividades internas comunes. En tales casos, puede convertirlos en subestados y mover el comportamiento general a un superestado, como se muestra en la Fig. 10.4. Sin superestado, tendrías que dibujar una transición. cancelar(cancelar) para los tres estados dentro de un estado Ingrese los detalles de la conexión.

Estados paralelos

Los estados se pueden dividir en varios estados simultáneos que se ejecutan al mismo tiempo. En la Fig. 10.5 muestra un reloj despertador simple que puede encender un CD o una radio y mostrar la hora actual o la hora de la alarma.

Las opciones de CD / radio y la hora actual / la hora de la señal son paralelas. Si quisiera representar esto con un diagrama de estado no paralelo, sería un diagrama desordenado cuando necesite agregar estados. Dividir las dos áreas de comportamiento en dos gráficos de estado lo hace mucho más claro.

Arroz. 10.5 también incluye estado de fondo(historia pseudoestado). Esto significa que cuando se enciende el reloj, la opción de radio / CD pasa al estado en el que se encontraba el reloj cuando se apagó. La flecha que emerge de la prehistoria muestra qué estado existía inicialmente cuando no había prehistoria.

Implementando diagramas de estado

Un diagrama de estado se puede implementar de tres formas principales: con una declaración de conmutación anidada, un patrón de estado y una tabla de estado. El enfoque más sencillo para trabajar con diagramas de estado es una declaración de cambio anidada, como la que se muestra en la Figura 1. 10.6.

Aunque este método es sencillo, es muy largo incluso para esto. caso simple... Además, con este enfoque es muy fácil perder el control, por lo que no recomendamos usarlo ni siquiera en situaciones elementales.
El patrón de estado representa una jerarquía de clases de estado para manejar el comportamiento del estado. Cada estado en un diagrama de estado tiene su propia subclase de estado. El controlador tiene métodos para cada evento que simplemente reenvían a la clase de estado. El diagrama de estado que se muestra en la Fig. 10.1 podría implementarse utilizando las clases que se muestran en la Fig. 10,7.

La parte superior de la jerarquía es una clase abstracta que contiene una descripción de todos los métodos que manejan eventos, pero no la implementación.
Para cada estado específico, es suficiente reescribir el método del controlador para un evento específico que inicia la transición desde el estado.
Una tabla de estados representa un diagrama de estados como datos.

Entonces, el diagrama de la fig. 10.1 se puede presentar en forma de tabla. 10.1.
Luego, construimos un intérprete que usa la tabla de estado en tiempo de ejecución, o un generador de código que genera clases basadas en esa tabla.

Obviamente, la mayor parte del trabajo en una tabla de estado se realiza una vez, pero luego se puede usar siempre que sea necesario resolver un problema de estado. La tabla de estado de tiempo de ejecución se puede modificar sin volver a compilar, lo cual es algo conveniente. El patrón de estado es más fácil de construir y, aunque cada estado requiere una clase separada, la cantidad de código que debe escribirse es muy pequeña.

Las implementaciones dadas son prácticamente mínimas, pero dan una idea de cómo usar diagramas de estado... En cada caso, la implementación de modelos de estado conduce a un programa bastante estereotipado, por lo que generalmente es mejor recurrir a alguna forma de generación de código para esto.

Suscríbase a las noticias del sitio, puede encontrar el formulario de suscripción en la columna derecha del sitio.

Si quieres aprender a trabajar como autónomo de forma profesional, te invitamos al curso "".

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. Además, cualquiera de estos métodos tenía su propio fortalezas, pero no permitió construir un modelo suficientemente completo del PS, para mostrarlo "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 su propia representación gráfica. 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 encontrar 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 el 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;
  • destacando clases describiendo interfaz de usuario y creación de un esquema de navegación para pantallas;
  • 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 programa: restaurar ciertas proyecciones del modelo SS mediante el análisis automático de los códigos fuente de los programas, lo cual es muy importante para garantizar la coherencia del modelo y los códigos y al diseñar sistemas que heredan la funcionalidad del predecesor. sistemas.

Anotación: El tema de este curso es UML - Lenguaje de modelado unificado. En la conferencia anterior hablé sobre qué es UML, sobre su historia, propósito, formas de usar el lenguaje, la estructura de su definición, terminología y notación. Se señaló que un modelo UML es una colección de diagramas. En esta conferencia, consideraremos tales preguntas: ¿por qué necesita varios tipos de diagramas? tipos de diagramas; OOP y secuencia de diagramación

Antes de pasar a discutir el material principal de esta conferencia, hablemos sobre por qué construir cualquier tipo de diagrama. El desarrollo de un modelo de cualquier sistema (no solo software) siempre precede a su creación o actualización. Esto es necesario al menos para poder imaginar con mayor claridad el problema que se está resolviendo. Los modelos bien pensados ​​son muy importantes tanto para la interacción dentro del equipo de desarrollo como para el entendimiento mutuo con el cliente. En última instancia, esto le permite asegurarse de que su diseño sea "coherente desde el punto de vista arquitectónico" antes de implementarse en el código.

Construimos modelos de sistemas complejos, porque no podemos describirlos completamente, "echar un vistazo". Por lo tanto, destacamos solo aquellos esenciales para tarea específica propiedades del sistema y construir su modelo reflejando estas propiedades. El método de análisis orientado a objetos permite describir sistemas complejos reales de la forma más adecuada. Pero a medida que aumenta la complejidad de los sistemas, se necesita una buena tecnología de modelado. Como dijimos en la conferencia anterior, una tecnología unificada se utiliza como tecnología "estándar". lenguaje de modelado(Unified Modeling Language, UML), que es un lenguaje gráfico para la especificación, visualización, diseño y documentación de sistemas. Se puede desarrollar un modelo detallado usando UML el sistema que se está creando, reflejando no solo su concepto, sino también características específicas de implementación. Dentro del marco del modelo UML, todas las ideas sobre el sistema se fijan en forma de estructuras gráficas especiales, llamadas diagramas.

Nota... Consideraremos no todos, sino solo algunos de los tipos de diagramas. Por ejemplo, el diagrama de componentes no se trata en esta lección, que es solo breve descripción tipos de diagramas. Número de tipos de gráficos para modelo específico la aplicación no está limitada de ninguna manera. Para aplicaciones simples no es necesario construir diagramas de todo tipo sin excepción. Algunos de ellos pueden simplemente faltar, y este hecho no se considerará un error. Es importante comprender que la disponibilidad de diagramas de cierto tipo depende de las características específicas de un proyecto en particular. Se puede encontrar información sobre otros tipos de diagramas (no cubiertos aquí) en el estándar UML.

Por qué necesita varios tipos de gráficos

Primero, definamos la terminología. En la introducción a esta conferencia, hemos utilizado repetidamente los conceptos de sistema, modelo y diagrama. El autor está seguro de que cada uno de nosotros comprende intuitivamente el significado de estos conceptos, pero para que quede completamente claro, volvamos a mirar el glosario y leamos lo siguiente:

Sistema- un conjunto de subsistemas controlados interconectados, unidos por un propósito común de funcionamiento.

Sí, no muy informativo. Entonces, ¿qué es un subsistema? Para aclarar la situación, pasemos a los clásicos:

Sistema se refiere a un conjunto de subsistemas organizados para lograr un objetivo específico y descritos utilizando un conjunto de modelos, posiblemente desde diferentes puntos de vista.

Bueno, no se puede hacer nada, hay que buscar la definición del subsistema. También dice que subsistema es una colección de elementos, algunos de los cuales especifican la especificación del comportamiento de otros elementos. Ian Somerville explica este concepto de esta manera:

Subsistema es un sistema cuyo funcionamiento no depende de los servicios de otros subsistemas. Un sistema de software está estructurado como un conjunto de subsistemas relativamente independientes. También se definen las interacciones entre subsistemas.

Tampoco muy claro, pero mejor. En términos humanos, el sistema se representa como un conjunto de entidades más simples que son relativamente autosuficientes. Esto se puede comparar a cómo, en el proceso de desarrollo de un programa, construimos interfaz grafica a partir de "cubos" estándar - componentes visuales, o cómo el texto del propio programa también se divide en módulos que contienen subrutinas, unidos por características funcionales, y pueden ser reutilizados en los siguientes programas.

Descubrimos el concepto de sistema. Durante el proceso de diseño, el sistema se considera desde diferentes puntos de vista con la ayuda de modelos, cuyas diversas representaciones se presentan en forma de diagramas. Una vez más, el lector puede tener preguntas sobre el significado de los conceptos. modelo y gráficos... Creemos que una definición hermosa, pero no demasiado clara modelo como una abstracción semánticamente cerrada del sistema Es poco probable que aclare la situación, así que intentemos explicarlo con nuestras propias palabras.

Modelo es un objeto determinado (material o no) que muestra solo las características del sistema que son más significativas para una tarea determinada. Los modelos son diferentes: materiales y no materiales, artificiales y naturales, decorativos y matemáticos ...

Aquí hay unos ejemplos. Los coches de juguete de plástico que todos conocemos, a los que jugamos con tanta pasión en la infancia, no son más que material decorativo artificial modelo de un coche real. Por supuesto, en tal "auto" no hay motor, no llenamos su tanque con gasolina, la caja de cambios no funciona (además, no existe en absoluto), pero como modelo este juguete cumple plenamente sus funciones: le da al niño una idea del automóvil, ya que muestra sus rasgos característicos son la presencia de cuatro ruedas, una carrocería, puertas, ventanas, la capacidad de conducir, etc.

En la investigación médica, la experimentación con animales a menudo precede a los ensayos clínicos de medicamentos en humanos. En este caso, el animal actúa como material natural modelos humanos.

La ecuación que se muestra arriba también es un modelo, pero este es un modelo matemático y describe el movimiento de un punto material bajo la influencia de la gravedad.

Solo queda decir qué es un diagrama. Diagrama es una representación gráfica de muchos elementos. Generalmente se representa como un gráfico con vértices (entidades) y aristas (relaciones). Hay muchos ejemplos de diagramas. Este es un diagrama de bloques familiar para todos nosotros desde los años escolares, y diagramas de instalación de varios equipos, que podemos ver en los manuales de usuario, y un árbol de archivos y directorios en el disco, que podemos ver ejecutando en consolas windows el comando del árbol, y mucho, mucho más. V La vida cotidiana Los diagramas nos rodean por todos lados, porque percibimos el dibujo con más facilidad que el texto ...

Pero volvamos al diseño de software (y no solo). En esta industria con utilizando diagramas, puede visualizar el sistema desde diferentes puntos de vista... Uno de los diagramas, por ejemplo, puede describir la interacción del usuario con el sistema, el otro - el cambio en los estados del sistema durante su operación, el tercero - la interacción entre los elementos del sistema, etc. Un complejo El sistema puede y debe representarse como un conjunto de pequeños y casi independientes modelos - diagramas, y ninguno de ellos es suficiente para describir el sistema y obtener una imagen completa del mismo, ya que cada uno de ellos se enfoca en algún aspecto específico del funcionamiento del sistema. sistema y expresa un diferente nivel de abstracción... En otras palabras, cada modelo corresponde a un punto de vista específico y particular sobre el sistema proyectado.

A pesar de que en el párrafo anterior nos entendimos muy libremente con el concepto de modelo, debe entenderse que en el contexto de las definiciones anteriores ningún gráfico es un modelo... Los gráficos son solo una herramienta de visualización del modelo y deben distinguirse los dos. Solo un conjunto de diagramas constituye un modelo del sistema y lo describe de manera más completa, pero no un diagrama sacado de contexto.

Tipos de diagramas

UML 1.5 definido doce tipos de gráficos dividido en tres grupos:

  • cuatro tipos de diagramas representan la estructura estática de la aplicación;
  • cinco representan los aspectos de comportamiento del sistema;
  • tres representan los aspectos físicos del funcionamiento del sistema (diagramas de implementación).

La versión actual de UML 2.1 no ha realizado demasiados cambios. Los diagramas han cambiado ligeramente en apariencia (marcos y otras mejoras visuales), la notación se ha mejorado ligeramente, algunos diagramas han recibido nuevos nombres.

Sin embargo, el número exacto diagramas canónicos no es absolutamente importante para nosotros, ya que no los consideraremos todos, sino solo algunos, por la razón de que el número de tipos de gráficos para un modelo particular de una aplicación en particular no es estrictamente fijo. Para aplicaciones simples, no es necesario crear todos los diagramas sin excepción. Por ejemplo, para una aplicación local, no es necesario crear un diagrama de implementación. Es importante comprender que la lista de diagramas depende de los detalles del proyecto que se está desarrollando y la determina el propio desarrollador. Si el lector curioso aún desea conocer todos los diagramas UML, lo remitiremos al estándar UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Recordemos que el propósito de este curso no es describir absolutamente todas las posibilidades del UML, sino solo introducir este lenguaje, para dar una idea inicial de esta tecnología.

Por lo tanto, veremos brevemente tipos de gráficos como:

  • use el diagrama del caso;
  • diagrama de clase;
  • diagrama de objeto;
  • diagrama de secuencia;
  • diagrama de interacción;
  • diagrama de estado;
  • diagrama de actividad;
  • diagrama de despliegue.

Hablaremos de algunos de estos diagramas con más detalle en las próximas conferencias. Mientras tanto, no nos centraremos en los detalles, sino que nos fijamos el objetivo de enseñar al lector a distinguir al menos visualmente entre los tipos de diagramas, para dar una idea inicial del propósito de los principales tipos de diagramas. Vamos a empezar.

Use el diagrama del caso

Todos los sistemas (incluido el software) se diseñan teniendo en cuenta el hecho de que en el curso de su trabajo serán utilizados por personas y / o interactuarán con otros sistemas. Las entidades con las que interactúa el sistema en el curso de su trabajo se denominan ectores, y cada actor espera que el sistema se comporte de una manera estrictamente definida y predecible. Intentemos dar una definición más rigurosa de un ector. Para hacer esto, usaremos un maravilloso vocabulario visual para UML. Mentor de Zicom:

Ector (actor) es un conjunto de roles relacionados lógicamente que se realizan al interactuar con casos de uso o entidades (sistema, subsistema o clase). Un ector puede ser una persona u otro sistema, subsistema o clase que representa algo fuera de la esencia.

Gráficamente, el ector se representa como " hombrecito ", temas similares que dibujamos en la infancia, representando a miembros de nuestra familia, o símbolo de clase con estereotipo coincidente, como se muestra en la imagen. Ambas formas de presentación tienen el mismo significado y se pueden utilizar en diagramas. La forma "estereotipada" se utiliza a menudo para representar a los actores del sistema o en los casos en que el actor tiene propiedades y necesita ser mostrado (Fig. 2.1).

Un lector atento puede hacer inmediatamente la pregunta: por qué es un actor y no un actor? Estamos de acuerdo en que la palabra "ector" corta un poco la oreja de un ruso. La razón por la que hablamos de esta manera es simple: el ector se forma a partir de la palabra acción, que en traducción significa acción... La traducción literal de la palabra "ector" es actor- demasiado largo e incómodo de usar. Por tanto, seguiremos hablando de esta forma.


Arroz. 2.1.

El mismo lector atento podría haber notado la palabra "precedente" que apareció en la definición del ector. ¿Qué es? Esta pregunta nos interesará aún más si recordamos que ahora estamos hablando de use el diagrama del caso... Entonces,

Caso de uso- una descripción de un aspecto particular del comportamiento del sistema desde el punto de vista del usuario (Booch).

La definición es bastante clara y exhaustiva, pero se puede aclarar un poco más utilizando el mismo Mentor de Zicom"ohm:

Caso de uso- una descripción del conjunto de eventos secuenciales (incluidas las opciones) realizados por el sistema que conducen al resultado observado por el actor. Un caso de uso representa el comportamiento de una entidad, describiendo la interacción entre los actores y el sistema. El precedente no muestra "cómo" se logra un determinado resultado, sino sólo "qué" se realiza.

Los casos de uso se indican de una manera muy simple, en forma de elipse, dentro de la cual se indica su nombre. Los casos de uso y los actores están conectados con líneas... A menudo, en un extremo de la línea, se representa el arroz. 2,3

  • formación requerimientos generales al comportamiento del sistema diseñado;
  • desarrollo de un modelo conceptual del sistema para su posterior detalle;
  • elaboración de documentación para la interacción con clientes y usuarios del sistema.
    • UML es un lenguaje de modelado gráfico de propósito general para especificar, visualizar, diseñar y documentar todos los artefactos creados en el desarrollo de sistemas de software.

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

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

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

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

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

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

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

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

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

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

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

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

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

    Diagramas para representar la estructura del sistema.:

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

    Diagramas para representar el comportamiento del sistema:

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

    Los diagramas se destacan:

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

    Diagrama de uso

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

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

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

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

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

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

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

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

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

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

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

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

    Diagrama de clase

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

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

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

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

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

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

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

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

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

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

    Diagrama de autómata

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

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

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

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

    Final (final) un estado es un caso especial de un estado que tampoco contiene acciones internas (pseudo-estados). El objeto predeterminado estará en este estado después de que el autómata haya terminado de ejecutarse en punto final hora.

    Diagrama de actividad

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

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

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

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

    Diagrama de secuencia

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

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

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

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

    Diagrama de comunicación

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

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

    Diagrama de componentes

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

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

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

    Diagrama de ubicación

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

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

    Diagrama de objetos

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

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

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

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

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

    Diagrama de sincronizacion

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

    Diagrama del paquete

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

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

    Modelo entidad-relación (modelo ER)

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

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

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

    Conceptos básicos:

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

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

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

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

    Hay tres tipos de enlaces binarios:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      Lectura adicional

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