"Un día en la vida de una ardilla" o del modelado de procesos al diseño de un sistema automatizado de contabilidad de activos materiales "Belka-1.0" (Parte 2)
Resumen de la serie anterior
В usamos un área temática de "cuento de hadas" inspirada en ejemplos de estudio de diagramas UML basados en tramas de cuentos de hadas (ver, por ejemplo, [1]). Antes del modelado, acordamos el uso de algunos elementos del diagrama de actividades y comenzamos a formar un acuerdo de modelado. Teniendo en cuenta 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 que se requiere (y es posible) la automatización.
Les recuerdo que vamos a automatizar la actividad de contabilización de valores materiales, que surge en estos procesos.
...
Una isla en el mar yace, (E1, E2)
Granizo en las gradas de la isla (E3, E1)
Con iglesias de cúpulas doradas, (E4)
con torres y jardines; (E5, E6)
Abeto crece frente al palacio, (E7, E8)
Y debajo hay una casa de cristal; (E9)
La ardilla vive ahí, mansa, (A1)
¡Sí, qué animador! (A1)
Ardilla canta canciones, (P1, A1)
Sí, roe nueces, (P2)
Y las nueces no son simples, (C1)
Todas las conchas son doradas, (C2)
granos de esmeralda pura; (C3)
Los sirvientes cuidan a la ardilla, (P3, A2)
Servirla como sirvientes de varias clases (P4)
Y se asignó un empleado (A3)
Cuenta estricta de noticias de nueces; (P5, C1)
Da su honor al ejército; (P6, A4)
Se vierte una moneda de las conchas, (P7, C2, C4)
Déjalos flotar alrededor del mundo; (P8)
Chicas tiran esmeralda (P9, A5, C3)
En despensas, pero bajo un celemín; (E10, E11)
...
(A.S. Pushkin "La historia del zar Saltan, de su glorioso y poderoso hijo, el príncipe Gvidon Saltanovich y la bella princesa cisne", )
En este ejemplo, estoy usando el entorno Enterprise Architect de una empresa australiana. [2], y en el marco de las sesiones de entrenamiento utilizo [3].
Déjame recordarte que los procesos son diferentes, puedes familiarizarte, por ejemplo, [4] y [5].
Ver [6, 7] para obtener detalles sobre los enfoques aplicados al modelado y diseño.
Para obtener la especificación UML completa, consulte [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 figuras continuará.
Etapa 3. Al paso automatizado se le debe asignar una función o funciones del sistema
El sistema automatizado (AS) que se está desarrollando está diseñado para llevar un registro estricto de nueces, ¿recuerdas? Para cada paso resaltado (ver Figura 3, Figura 4 ), que automatizaremos, escribiremos el requerimiento funcional, usando algo como esta construcción "El sistema debe ser capaz de..." y desarrollaremos un diagrama de casos de uso. Ahora estamos complementando nuestro acuerdo de modelado con nuevas reglas. Déjame explicarte qué elementos usaremos.
Entre el “Rol de Usuario” y la “Función” utilizaremos la relación “Asociación” (Figura 5), lo que significa que el usuario con este rol puede realizar esta función.
Figura 5. Uso de una relación de tipo de asociación
De "Función" a "Requisito", dibujaremos el enlace "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 más de una función puede ser necesaria para implementar el requisito.
Figura 6. Uso de una relación de implementación
Si una función requiere para su ejecución alguna otra función para ser ejecutada, y es necesario, utilizaremos la conexión “Dependencia” con el estereotipo “Incluir” - inclusión (Figura 7). Si se requiere la ejecución de una función adicional bajo ciertas condiciones, usaremos la conexión "Dependencia" con el estereotipo "Extender", una extensión. Todo es muy fácil de recordar: "Incluir" - SIEMPRE, y "Extender" - A VECES.
Figura 7. Usando el enlace tipo "Dependencia (incluir)"
Como resultado, nuestro diagrama se verá así (Figura 8).
Figura 8. Diagrama de casos de uso (modelo funcional de AS)
Además, el diagrama de casos de uso se utiliza para modelar los roles de los usuarios (Figura 9).
Figura 9. Diagrama de casos de uso (roles de los usuarios de AS)
Etapa 4. Describamos la organización interna del AS usando un diagrama de clases
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. Usaremos los elementos de modelado de “Clase” y varios tipos de relaciones entre ellos.
Para mostrar la relación “todo-parte”, utilizaremos la relación de tipo “Agregación” (Figura 10): la nuez es el todo, y las cáscaras y la pepita son las partes.
Figura 10. Relación todo-parte
Como resultado, un fragmento de nuestro diagrama se verá así (Figura 11). Las clases están marcadas con color, que hemos resaltado directamente en la descripción del texto del proceso.
Figura 11. Diagrama de clases
El diagrama de clases también se usó para modelar otros artefactos, no solo aquellos que serán relevantes para el modelo conceptual del proceso de inventario automatizado, sino también relacionados con el entorno de ejecución: el entorno (Figura 12) y los procesos "vecinos" (Figura 13) que pueden influir en el proceso automatizado, pero que aún no están en el centro de nuestra atención (suponemos que el sistema se desarrollará y esta información será útil).
Figura 12. Diagrama de clases (entorno)
La relación de herencia muestra la generalización de varios edificios, clases "secundarias", bajo la clase "principal" generalizadora "Edificio".
Figura 13. Diagrama de clases (más información sobre artefactos)
La "Reacción a la situación" depende de los "Datos de control visual". Para varias relaciones de dependencia, el estereotipo “trace” se usa para mostrar el rastreo de clases que no están explícitamente indicadas en la descripción del proceso, pero que son necesarias para su automatización, a clases cuyas instancias están precisamente indicadas en nuestra descripción.
Etapa 5. Analicemos las notas en la pista "Reglas comerciales"
Como se especificaron las reglas (ver Figura 2 ):
- la necesidad de dividir uno de los pasos en 2 partes, la segunda parte comienza a realizarse solo bajo ciertas condiciones;
- designación de un cierto funcionario para realizar la contabilidad de las nueces;
- una técnica (color blanco de los elementos), que indica que el elemento no se enumeró explícitamente en la descripción del proceso.
Cabe señalar que ya hemos utilizado todas estas reglas al desarrollar diagramas.
Observaciones finales
Entonces, pasamos por 5 etapas y construimos 3 tipos de diagramas. Añadiré un pequeño comentario sobre la organización de nuestros modelos en el entorno de modelado. Existe una gran cantidad de frameworks que ayudan a estructurar los modelos que desarrollamos, pero este no es el tema de este artículo, por lo que nos limitaremos al siguiente conjunto simple de paquetes para el mantenimiento ordenado de nuestro proyecto: Business Process, Functional Model, Artefactos, Participantes y Entorno (Figura 14).
Figura 14. La estructura de los paquetes de proyectos
Por lo tanto, hemos desarrollado modelos consistentes que describen el sistema de contabilidad de activos 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.
Lista de fuentes
- Sitio "UML2.ru". Foro de la comunidad de analistas. Sección general. Ejemplos. Ejemplos de cuentos de hadas en forma de diagramas UML. [Recurso electrónico] Modo de acceso: Internet:
- Sitio web de Sparx Systems. [Recurso electrónico] Modo de acceso: Internet:
- Web de Modelio. [Recurso electrónico] Modo de acceso: Internet:
- Gran Diccionario Enciclopédico. Proceso (interpretación). [Recurso electrónico] Modo de acceso: Internet:
- Sitio web "Organización de la gestión eficaz". Blog. Título "Gestión de procesos de negocio". Definición de proceso de negocio. [Recurso electrónico] Modo de acceso: Internet:
- Certificado N° 18249 sobre registro y depósito de un producto del resultado de la actividad intelectual. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. El manuscrito del material didáctico titulado "Modelado del área temática utilizando Enterprise Architect" // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelado de procesos de negocio. - M.: KURS, NITs INFRA-M, EBS Znanium.com. — 2017.
- Especificación del lenguaje de modelado unificado OMG (OMG UML). Versión 2.5.1. [Recurso electrónico] Modo de acceso: Internet:
Fuente: habr.com