Desde el modelado de procesos hasta el diseño de un sistema automatizado (Parte 2)

"Un día en la vida de una ardilla" o desde procesos de modelado hasta el diseño de un sistema automatizado de contabilidad para valores de materiales "Ardilla-1.0" (Parte 2)

Se utilizó la ilustración de A.S. Pushkin's Tale of Zar Saltan, publicada por Children's Literature, Moscú, 1949, Leningrado, dibujos de K. Kuznetsov

Resumen de la serie anterior.

En la primera parte, utilizamos un área temática de "cuento de hadas", inspirada en ejemplos del estudio de diagramas UML basados ​​en diagramas de cuentos de hadas (véase, por ejemplo, aquí [1]). Antes del comienzo del modelado, acordamos el uso de algunos elementos del diagrama de Actividad y comenzamos a formular un acuerdo de modelado. Con base en estos acuerdos, en la primera etapa describimos el proceso en forma de diagramas de actividad, y en la segunda etapa identificamos los pasos del proceso para los cuales se requiere automatización (y posible).

Permítame recordarle que vamos a automatizar la actividad de contabilizar los valores materiales que surgen en estos procesos.

...
La isla se encuentra en el mar, (E1, E2)
Ciudad en la isla se encuentra (E3, E1)
Con iglesias con cúpulas doradas, (E4)
Con torres y jardines; (E5, E6)
El abeto crece frente al palacio, (E7, E8)
Y debajo hay una casa de cristal; (E9)
La ardilla vive allí manual (A1)
¡Qué artista! (A1)
Ardilla canta canciones, (P1, A1)
Sí, las nueces roen todo, (P2)
Y las nueces no son simples, (C1)
Todas las conchas son doradas, (C2)
Los granos son pura esmeralda; (C3)
Los sirvientes guardan la ardilla, (P3, A2)
Le sirven un sirviente diferente (P4)
Y se ordenó al empleado (A3)
Estricta cuenta de nueces; (P5, C1)
Saluda a su ejército; (P6, A4)
De una cáscara vierta una moneda, (P7, C2, C4)
Sí flotan alrededor del mundo; (P8)
Las niñas vierten esmeralda (P9, A5, C3)
En las despensas, pero en el fondo; (E10, E11)
...
(A.S. Pushkin "El cuento del zar Saltan, de su glorioso y poderoso héroe, el príncipe Gvidon Saltanovich y de la bella princesa Swans", como se cree, un tratamiento gratuito del cuento popular "Hasta las rodillas en oro, el codo de la mano en plata" que fue grabado por Pushkin de varias maneras )

En este ejemplo, uso el entorno Enterprise Architect de la compañía australiana Sparx Systems [2], y como parte de la sesión de capacitación uso Modelio [3].
Permítame recordarle que los procesos son diferentes, puede familiarizarse, por ejemplo, aquí [4] y aquí [5].
Para obtener más información sobre los enfoques aplicados al modelado y diseño, consulte [6, 7].
Vea la especificación completa de UML aquí [8].

Ahora estamos listos para pasar a los siguientes pasos y comenzar a diseñar las funciones del sistema y su organización interna. La numeración de las cifras continuará.

Etapa 3. El paso automatizado debe coincidir con la función o funciones del sistema.

El sistema automatizado (AS) desarrollado está diseñado para mantener un estricto registro de nueces, ¿recuerdas? Para cada paso seleccionado (ver Figura 3, Figura 4 en la primera parte ), que automatizaremos, anotamos el requisito funcional, aplicando aproximadamente la siguiente construcción: "El sistema debe tener la oportunidad de implementarse ..." y desarrollar el diagrama de casos de uso. Ahora en realidad estamos complementando nuestro acuerdo de modelado con nuevas reglas. Déjame explicarte qué elementos usaremos.

Entre el "Rol del usuario" y la "Función", utilizaremos la asociación de asociación (Figura 5), ​​lo que significa que para un usuario con este rol, la ejecución de esta función está disponible.

Figura 5. Uso de la comunicación de tipo asociación

De la "Función" al "Requisito" dibujamos la relación "Implementación" (Figura 6) para mostrar que este requisito será implementado por estas funciones, la relación puede ser "muchos a muchos", es decir una función puede estar involucrada en la implementación de varios requisitos, y se puede requerir más de una función para implementar un requisito.

Figura 6. Uso de una relación de tipo "Implementación"

Si una función requiere para su ejecución que se realice otra función, y es necesario, utilizaremos la relación "Dependencia" con el estereotipo "Incluir" - inclusión (Figura 7). Si se requiere la ejecución de una función adicional bajo ciertas condiciones, entonces usaremos la relación "Dependencia" con el estereotipo "Extender" - extensión. Todo es muy fácil de recordar: "Incluir" - SIEMPRE, y "Extender" - A VECES.

Figura 7. Uso de una relación del tipo "Dependencia (inclusión)"

Como resultado, nuestro diagrama se verá más o menos así (Figura 8).

Figura 8. Diagrama de casos de uso (modelo funcional AS)

Además, el diagrama de casos de uso se utiliza para modelar roles de usuario (Figura 9).

Figura 9. Diagrama de casos de uso (roles de usuario del hablante)

Etapa 4. Describimos la organización interna del AS utilizando el diagrama de clase.

Usando información sobre los artefactos de entrada y salida de nuestro proceso (ver Diagramas de actividad - Figura 2, Figura 3, Figura 4), desarrollaremos un diagrama de clase. Utilizaremos los elementos de modelado de "Clase" y varios tipos de conexiones entre ellos.

Para mostrar la relación de “parte completa”, usaremos la relación de tipo “Agregación” (Figura 10): la tuerca es el todo, y las cáscaras y el núcleo son partes.

Figura 10. La relación "parte entera"

Como resultado, un fragmento de nuestro diagrama se verá más o menos así (Figura 11). El color indica las clases que identificamos directamente en la descripción de texto del proceso.

Figura 11. Diagrama de clases

El diagrama de clases también se usó para modelar otros artefactos, no solo aquellos que estarán relacionados con el modelo conceptual del proceso automatizado de contabilización de valores materiales, sino que están relacionados con el entorno de tiempo de ejecución: el entorno (Figura 12) y los procesos "vecinos" (Figura 13), que pueden para influir en el proceso automatizado, pero aún no están en el foco de nuestra atención (asumimos que el sistema se desarrollará y esta información será útil).

Figura 12. Diagrama de clases (entorno)

La relación de herencia muestra una generalización de varios edificios, clases "secundarias", bajo la clase general "estructura" "primaria".

Figura 13. Diagrama de clases (información adicional sobre artefactos)

La "respuesta a la situación" depende de los "datos de inspección visual". Para varias relaciones de dependencia, el estereotipo de "rastreo" se usa para mostrar el rastreo de clases que no se indican explícitamente en la descripción del proceso, pero que son necesarias para su automatización, a clases para los casos de los cuales hay una indicación exacta en nuestra descripción.

Etapa 5. Analizamos las notas en la pista "Reglas de negocios"

Se indicaron las reglas (ver Figura 2 en la primera parte ):

1. la necesidad de dividir uno de los pasos en 2 partes, la segunda parte comienza a realizarse solo bajo ciertas condiciones;
2. Nombramiento para llevar la contabilidad de las nueces de un funcionario en particular;
3. técnica técnica (color blanco de los elementos), que indica que el elemento no se indicó explícitamente en la descripción del proceso.

Cabe señalar que ya usamos todas estas reglas al desarrollar diagramas.

Observaciones finales

Entonces, pasamos por 5 etapas y construimos 3 tipos de diagramas. Agregue un pequeño comentario sobre la organización de nuestros modelos en el entorno de modelado. Hay una gran cantidad de marcos que ayudan a estructurar los modelos en desarrollo, pero este no es el tema de este artículo, por lo tanto, nos limitaremos al siguiente conjunto simple de paquetes para llevar a cabo nuestro proyecto de manera ordenada: proceso comercial, modelo funcional, artefactos, participantes y medio ambiente (Figura 14).

Figura 14. Estructura del paquete del proyecto

Por lo tanto, hemos desarrollado modelos consistentes que describen el sistema de contabilización de valores materiales desde varios ángulos: un modelo de un proceso comercial automatizado, un modelo funcional y un modelo de la organización interna del sistema a nivel conceptual.

Desde el modelado de procesos hasta el diseño de un sistema automatizado (Parte 1)