«Un día en la vida de una ardilla» o de la modelización de procesos al diseño de un sistema automatizado de contabilidad de productos materiales «Ardilla-1.0» (Parte 2)
Resumen del episodio anterior
En hemos utilizado el dominio de la «fantasía», inspirados en ejemplos de estudio de diagramas UML basados en tramas de cuentos (ver, por ejemplo, [1]). Antes de comenzar la modelización, acordamos el uso de algunos elementos del diagrama de Actividad y comenzamos a formar un acuerdo sobre la modelización. Con base en estos acuerdos, en la fase 1 describimos el proceso en forma de diagramas de Actividad, y en la fase 2 identificamos los pasos del proceso para los cuales es necesario (y posible) automatizar.
Recuerdo que lo que vamos a automatizar es la contabilidad de productos materiales, que surge en esos procesos.
…
Una isla yace en el mar, (E1, E2)
Una ciudad está en la isla (E3, E1)
Con iglesias doradas, (E4)
Con torretas y jardines; (E5, E6)
Un abeto crece frente al palacio, (E7, E8)
Y bajo él, una casa de cristal; (E9)
Allí vive una ardilla domesticada, (A1)
¡Y qué ingeniosa es! (A1)
La ardilla canta canciones, (P1, A1)
Y se come nueces, (P2)
Y las nueces no son comunes, (C1)
Todas cáscaras doradas, (C2)
Las nueces son un esmeralda pura; (C3)
Los sirvientes cuidan de la ardilla, (P3, A2)
Le sirven todo tipo de criados (P4)
Y un escribano severo está a su servicio; (A3)
Cuenta estrictamente las nueces; (P5, C1)
Le rinde honores el ejército; (P6, A4)
De las cáscaras vierten monedas, (P7, C2, C4)
Y las esparcen por el mundo; (P8)
Las chicas esparcen esmeraldas (P9, A5, C3)
En los almacenes, y bajo el polvo; (E10, E11)
…
(De A.S. Pushkin «El cuento del rey Salatán, sobre su hijo ilustre y poderoso caballero, el príncipe Guidón Salatánovich, y sobre la hermosa princesa Cisne», )
En este ejemplo utilizo el entorno Enterprise Architect de la empresa australiana [2], y en el marco de las clases aplico [3].
Recuerdo que existen diferentes tipos de procesos, puedes consultar, por ejemplo, [4] y [5].
Más detalles sobre los enfoques aplicados en la modelización y el diseño en [6, 7].
La especificación completa de UML se encuentra en [8].
Ahora estamos listos para pasar a las siguientes fases y comenzar el diseño de las funciones del sistema y su organización interna. La numeración de las ilustraciones continuará.
Etapa 3. Al paso a automatizar le debemos asignar una o varias funciones del sistema.
El sistema automatizado (SA) que estamos desarrollando está destinado a llevar un estricto control de las nueces, ¿recuerdas? Para cada paso destacado (ver Figura 3, Figura 4 ), que vamos a automatizar, registraremos un requerimiento funcional, utilizando aproximadamente esta construcción «El sistema debe tener la posibilidad de...», y desarrollaremos un diagrama de casos de uso. Ahora estamos, de hecho, complementando nuestro acuerdo sobre la modelización con nuevas reglas. Permíteme explicar qué elementos vamos a utilizar.
Entre el «Rol del usuario» y la «Función» utilizaremos la relación «Asociación» (Figura 5), lo que significa que para un usuario con este rol está disponible la realización de esta función.
Figura 5. Uso de la relación del tipo «Asociación»
De la «Función» al «Requerimiento» estableceremos la relación «Implementación» (Figura 6), para mostrar que este requerimiento será implementado por estas funciones, la relación puede ser de «muchos a muchos», es decir, una función puede participar en la implementación de varios requerimientos, y para implementar un requerimiento puede ser necesaria más de una función.
Figura 6. Uso de la relación del tipo «Implementación»
Si una función requiere para su ejecución que se realice otra función, y esto es obligatorio, utilizaremos la relación «Dependencia» con el estereotipo «Include» — inclusión (Figura 7). Si, por el contrario, la ejecución de la función adicional se requiere bajo ciertas condiciones, utilizaremos la relación «Dependencia» con el estereotipo «Extend» — extensión. Es muy fácil de recordar: «Include» — SIEMPRE, y «Extend» – A VECES.
Figura 7. Uso de la relación del tipo «Dependencia (inclusión)»
Como resultado, nuestro diagrama se verá aproximadamente así (Figura 8).
Figura 8. Diagrama de caso de uso (modelo funcional del SC)
Además, el diagrama de caso de uso se utiliza para modelar los roles de los usuarios (Figura 9).
Figura 9. Diagrama de caso de uso (roles de los usuarios del SC)
Etapa 4. Describiremos la organización interna del AS mediante un diagrama de clases.
Utilizando la información sobre los artefactos de entrada y salida de nuestro proceso (ver diagramas de Actividad — Figura 2, Figura 3, Figura 4), desarrollaremos el diagrama de clases. Utilizaremos los elementos modeladores «Clase» y varios tipos de relaciones entre ellos.
Para mostrar la relación «todo-parte» utilizaremos la relación del tipo «Agregación» (Figura 10): la nuez es el todo, y las cáscaras y el núcleo son las partes.
Figura 10. Relación «todo-parte»
Como resultado, el fragmento de nuestro diagrama se verá aproximadamente así (Figura 11). Los colores indican las clases que hemos destacado directamente en la descripción del proceso.
Figura 11. Diagrama de clases
El diagrama de clases también se utilizó para modelar otros artefactos, no solo aquellos que estarán relacionados con el modelo conceptual del proceso automatizado de contabilidad de bienes materiales, sino que también son relevantes para el entorno de ejecución - el ambiente (Figura 12) y los procesos "vecinos" (Figura 13) que pueden influir en el proceso automatizado, pero que aún no están en el foco de nuestra atención (suponemos que el sistema evolucionará y esta información será útil).
Figura 12. Diagrama de clases (entorno)
La relación de herencia muestra la generalización de diferentes construcciones, las clases "hijas" bajo la clase "madre" general "Construcción".
Figura 13. Diagrama de clases (información adicional sobre artefactos)
"La reacción a la situación" depende de "Los datos de control visual". Para varias relaciones de dependencia se utiliza el estereotipo "trace" para mostrar la trazabilidad de las clases que no están explícitamente definidas en la descripción del proceso, pero que son necesarias para su automatización, a las clases cuyos instancias están claramente indicadas en nuestra descripción.
Etapa 5. Analizaremos las notas en la pista "Reglas del negocio".
Las reglas indicadas son (ver Figura 2 ):
- la necesidad de dividir uno de los pasos en 2 partes, la segunda parte comienza a ejecutarse solo bajo ciertas condiciones;
- la asignación para que un funcionario específico realice el control de nueces;
- una técnica técnica (color blanco de los elementos), que indica que el elemento no fue claramente especificado en la descripción del proceso.
Cabe señalar que todas estas reglas ya las utilizamos al desarrollar los diagramas.
Observaciones finales
Así que hemos pasado por 5 etapas y construido 3 tipos de diagramas. Añadiré un pequeño comentario sobre la organización de nuestros modelos en el entorno de modelado. Existen una gran cantidad de marcos que ayudan a estructurar los modelos desarrollados, pero este no es el tema de este artículo, por lo que nos limitaremos al siguiente conjunto simple de paquetes para el manejo ordenado de nuestro proyecto: Proceso de negocio, Modelo funcional, Artefactos, Participantes y Entorno (Figura 14).
Figura 14. Estructura de los paquetes del proyecto
Así, hemos desarrollado modelos coherentes que describen el sistema de contabilidad de activos materiales desde diferentes perspectivas: un modelo de proceso de negocio automatizado, un modelo funcional y un modelo de 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 presentados en forma de diagramas UML. [Recurso electrónico] Acceso en línea:
- Sitio web de Sparx Systems. [Recurso electrónico] Acceso: Internet:
- Sitio Modelio. [Recurso electrónico] Acceso en línea:
- Gran Diccionario Enciclopédico. Proceso (interpretación). [Recurso electrónico] Acceso: Internet:
- Sitio web «Organización de la Gestión Eficaz». Blog. Sección «Gestión de Procesos Empresariales». Definición de proceso empresarial. [Recurso electrónico] Acceso: Internet:
- Certificado Nº 18249 de registro y depósito de obra resultado de la actividad intelectual. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. Manuscrito del manual metodológico titulado «Modelado del área temática utilizando Enterprise Architect» // 2011.
- Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modelado de procesos de negocio. — М.: KURS, NIC INFRA-M, EBS Znanium.com. — 2017.
- Especificación del Lenguaje de Modelado Unificado (OMG UML) de OMG. Versión 2.5.1. [Recurso electrónico] Acceso: Internet:
Fuente: habr.com
