From process modeling to automated system design (Part 2)

"One day in the life of a squirrel" or from modeling processes to designing an automated system for accounting for material assets "Belka-1.0" (Part 2)

From process modeling to automated system design (Part 2)
Used illustration for "The Tale of Tsar Saltan" by A.S. Pushkin, ed. "Children's Literature", Moscow, 1949, Leningrad, drawings by K. Kuznetsov

Summary of the previous series

В 1st part we used a "fairytale" subject area inspired by examples of studying UML diagrams based on fairy tale plots (see, for example, here [1]). Prior to modeling, we agreed on the use of some elements of the Activity diagram and began to form a modeling agreement. Taking into account these agreements, at the 1st stage we described the process in the form of Activity diagrams, and at the 2nd stage we identified the process steps for which automation is required (and possible).

Let me remind you that we are going to automate the activity of accounting for material values, which arises in these processes.

...
An island in the sea lies, (E1, E2)
Hail on the island stands (E3, E1)
With golden-domed churches, (E4)
With towers and gardens; (E5, E6)
Spruce grows in front of the palace, (E7, E8)
And under it is a crystal house; (E9)
The squirrel lives there, tame, (A1)
Yes, what an entertainer! (A1)
Squirrel sings songs, (P1, A1)
Yes, he gnaws all the nuts, (P2)
And nuts are not simple, (C1)
All shells are golden, (C2)
Kernels pure emerald; (C3)
Servants guard the squirrel, (P3, A2)
Serve her as servants of various kinds (P4)
And a clerk was assigned (A3)
Strict account of nuts news; (P5, C1)
Gives her army honor; (P6, A4)
A coin is poured from the shells, (P7, C2, C4)
Let them float around the world; (P8)
Girls throw emerald (P9, A5, C3)
In pantries, but under a bushel; (E10, E11)
...
(A.S. Pushkin "The Tale of Tsar Saltan, of his glorious and mighty son Prince Gvidon Saltanovich and the beautiful Swan Princess", as it is believed, a free adaptation of the folk tale "Knee-deep in gold, elbow-deep in silver", which was written down by Pushkin in various versions)

In this example, I am using the Enterprise Architect environment from an Australian company. Sparx Systems [2], and in the framework of training sessions I use Modelio [3].
Let me remind you that processes are different, you can get acquainted, for example, here [4] and here [5].
See [6, 7] for details on the applied approaches to modeling and design.
For the complete UML specification, see here [8].

We are now ready to move on to the next steps and begin designing the functions of the system and its internal organization. Figure numbering will continue.

Stage 3. The automated step must be assigned a function or functions of the system

The automated system (AS) being developed is designed to keep a strict record of nuts, remember? For each highlighted step (see Figure 3, Figure 4 in part 1), which we will automate, write down the functional requirement, using something like this construction “The system must be able to ...” and develop a Use-case diagram. Now we are actually supplementing our modeling agreement with new rules. Let me explain what elements we will use.
From process modeling to automated system design (Part 2)

Between the “User Role” and the “Function” we will use the “Association” relationship (Figure 5), which means that the user with this role can perform this function.

From process modeling to automated system design (Part 2)
Figure 5. Using an association type relationship

From “Function” to “Requirement”, we will draw the “Implementation” link (Figure 6) to show that this requirement will be implemented by these functions, the relationship can be “many-to-many”, i.e. one function may be involved in the implementation of several requirements, and more than one function may be needed to implement the requirement.

From process modeling to automated system design (Part 2)
Figure 6. Using an Implementation relationship

If one function requires for its execution some other function to be executed, and it is necessary, we will use the “Dependence” connection with the “Include” stereotype - inclusion (Figure 7). If the execution of an additional function is required under certain conditions, then we will use the "Dependence" connection with the "Extend" stereotype - an extension. Everything is very easy to remember: "Include" - ALWAYS, and "Extend" - SOMETIMES.

From process modeling to automated system design (Part 2)
Figure 7. Using the link type "Dependency (include)"

As a result, our diagram will look something like this (Figure 8).

From process modeling to automated system design (Part 2)
Figure 8. Use-case diagram (functional model of AS)

In addition, the Use-case diagram is used to model user roles (Figure 9).

From process modeling to automated system design (Part 2)
Figure 9. Use-case diagram (roles of AS users)

Stage 4. Let's describe the internal organization of the AS using a class diagram

Using information about the input and output artifacts of our process (see Activity diagrams - Figure 2, Figure 3, Figure 4), we will develop a class diagram. We will use the “Class” modeling elements and various types of relationships between them.

From process modeling to automated system design (Part 2)

To show the “whole-part” relationship, we will use the “Aggregation” type relationship (Figure 10): the nut is the whole, and the shells and the kernel are the parts.

From process modeling to automated system design (Part 2)
Figure 10. Whole-Part Relationship

As a result, a fragment of our diagram will look something like this (Figure 11). Classes are marked with color, which we have highlighted directly in the text description of the process.

From process modeling to automated system design (Part 2)
Figure 11. Class diagram

The class diagram was also used to model other artifacts - not only those that will be relevant to the conceptual model of the automated inventory process, but related to the execution environment - the environment (Figure 12) and "neighbor" processes (Figure 13) that can influence the automated process, but are not yet in the focus of our attention (we assume that the system will develop and this information will be useful).

From process modeling to automated system design (Part 2)
Figure 12. Class diagram (environment)

The inheritance relationship shows the generalization of various buildings, "child" classes, under the generalizing "parent" class "Building".

From process modeling to automated system design (Part 2)
Figure 13. Class diagram (more information about artifacts)

The "Reaction to the situation" depends on the "Visual control data". For several dependency relationships, the “trace” stereotype is used to show the tracing of classes that are not explicitly indicated in the process description, but which are necessary for its automation, to classes whose instances are precisely indicated in our description.

Stage 5. Let's analyze the notes on the "Business Rules" track

As rules were specified (see Figure 2 in part 1):

  1. the need to split one of the steps into 2 parts, the second part starts to be performed only under certain conditions;
  2. appointment of a certain official to perform accounting of nuts;
  3. a technique (white color of the elements), which indicates that the element was not explicitly listed in the process description.

It should be noted that we have already used all these rules when developing diagrams.

Final remarks

So, we went through 5 stages and built 3 types of diagrams. I will add one more comment about the organization of our models in the modeling environment. There are a large number of frameworks that help structure the models we develop, but this is not the subject of this article, so we will limit ourselves to the following simple set of packages for orderly maintenance of our project: Business Process, Functional Model, Artifacts, Participants and Environment (Figure 14).

From process modeling to automated system design (Part 2)
Figure 14. The structure of the project packages

Thus, we have developed consistent models that describe the system of accounting for material assets from various angles: a model of an automated business process, a functional model, and a model of the internal organization of the system at a conceptual level.

From process modeling to automated system design (Part 1)

List of sources

  1. Site "UML2.ru". Analyst Community Forum. General section. Examples. Examples of fairy tales in the form of UML diagrams. [Electronic resource] Access mode: Internet: http://www.uml2.ru/forum/index.php?topic=486.0
  2. Sparx Systems website. [Electronic resource] Access mode: Internet: https://sparxsystems.com
  3. Modelio website. [Electronic resource] Access mode: Internet: https://www.modelio.org
  4. Big Encyclopedic Dictionary. Process (interpretation). [Electronic resource] Access mode: Internet: https://dic.academic.ru/dic.nsf/enc3p/246322
  5. Website "Organization of effective management". Blog. Heading "Business process management". Definition of business process. [Electronic resource] Access mode: Internet: https://rzbpm.ru/knowledge/pochemu-processy-stali-s-pristavkoj-biznes.html
  6. Certificate No. 18249 on registration and deposit of a product of the result of intellectual activity. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. The manuscript of the teaching aid entitled "Modeling the subject area using Enterprise Architect" // 2011.
  7. Zolotukhina E.B., Vishnya A.S., Krasnikova S.A. Modeling of business processes. - M .: KURS, NITs INFRA-M, EBS Znanium.com. — 2017.
  8. OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Electronic resource] Access mode: Internet: https://www.omg.org/spec/UML/2.5.1/PDF

Source: habr.com

Add a comment