UML & Enterprise Architect: design the target process when creating an automated system

UML & Enterprise Architect: design the target process when creating an automated system

Soviet poster "Automatic production control system - national economy!", artist R. Suryaninov, 1972

"A story about the modeling of precisely complex systems"


To one of my articles on modeling a “fairy tale” subject area ( Part 1 , part 2 ) a comment was left, I quote:

"It would be great to see a story about modeling complex systems."

And I promised to pick up something from real life.

A few words about the modeling language, modeling environment, methodology and agreement on modeling

Modeling Language
For modeling, use UML - Unified Modeling Language, unified modeling language [1].

Modeling Environment
Enterprise Architect from the Australian company Sparx Systems [2] is used as a modeling tool.

Modeling Methodology and Convention
Before designing, it is necessary to establish certain rules and approaches that we will follow when developing diagrams, the same rules will be used when “reading” diagrams. Details of the main approaches are described in [3, 4].

Stage 1. We develop a process map using the Use-case diagram, put all identified target processes on it - Use-case elements, and process participants - Actor elements, try to group the processes right away by meaning (if possible, of course).

Stage 2. Describe each process in the form of an Activity diagram. For a process in which more than 10 steps are highlighted, it makes sense to apply the principle of decomposition of the steps of the process in order to increase the readability of the diagram. For the lower level Activity diagrams, we apply the structuring of the diagram field using “swim lanes” - Swim lanes. The track name will correspond to the type of chart elements that will be placed on this track. "I/O. Objects ”: Objects elements will be located on this track - objects that are used or are the result of a certain process step. "Activity": here we put the elements of the Activity - the actions of participants in the process. “Role”: the track for the elements that will represent the roles of the performers of actions in our process, for them we will use the same modeling element Object - the object, but we will add the stereotype “Actor” to it. The next track is called “Rules” and on this track we place in the text form the rules for executing the steps of the process, and we will use the modeling element Note for this. The path "Tools" will be used to collect information about the level of automation of the process.

Stage 3. Select what can be automated. We will have three types of steps: manual, automated, and fully automatic.

Step 4. The automated step needs to be associated with a function or system functions (the relationship may be many-to-many), draw a Use-case diagram. These are the functions of our system.

Step 5. We describe the internal organization of the system using the class diagram - Class. Swimming track "I/O. Objects ”in the Activity diagram is the basis for constructing an object model and an entity-relationship model.

Stage 6. Let's analyze the notes on the “Rules” track, they give various kinds of restrictions and conditions, which are gradually transformed into non-functional requirements.

Step 7. The elements on the Tools track tell us about the level of process automation.
The resulting set of diagrams gives a formalized description in a fairly strict notation, i.e. has an unequivocal reading. Now you can develop a technical task, specify the specification of requirements, etc.

Modeling elements of the Use-case diagram for the process map

Modeling Activity Chart Elements

Brief information about the automation object

The automation object is quality assurance processes for the production of medical devices.

The process of manufacturing medical devices is characterized by a large number of manual operations. Quality management is regulated in accordance with GOST ISO 13485-2011. Medical products. Quality management systems. System requirements for regulatory purposes.

To carry out quality control, it is necessary to monitor and record all operations in the manufacture of a medical product for subsequent investigation of possible incidents.

Barcode is used as the registration information carrier. For reading information using a remote barcode reader.

The developed automated system (AS) for controlling the manufacture of medical devices is designed for:

  • control and record all operations in the manufacture of a medical product;
  • monitoring the process of creating a product;
  • receiving reports on the operations done.

Process Map - Use-case diagram

Figure 1 shows a map of the AU processes for controlling the manufacture of medical devices. Processes for which the following scenarios will be shown below are highlighted in green.

Figure 1. Map of the processes of the automated control system for manufacturing medical devices

Examples of process execution scenarios - Activity diagrams

Figures 2-5 show examples of scenarios for the execution of AU processes for controlling the manufacture of medical devices.

Figure 2. Preparation for work (start of shift)

Figure 3. Manufacturing honey. products (macro steps)

Figure 4. Start of manufacturing medical products

Figure 5. Manufacturing medical products

Object Life Cycle - State Chart

In the Activity diagrams, states are indicated in square brackets before or after the object names.

The full life cycle of a medical device is shown in the State Chart (Figure 6).

Figure 6.Production Health State Diagram

System structure

The system is logically divided into subsystems according to the functional attribute:

  • Subsystem "Manufacturing of medical products";
  • “Reference books and registries (NSI)” subsystem;
  • The “Monitoring and Control” subsystem (including the “Monitoring of technological operations” and “Reporting” modules);
  • Security subsystem;
  • Administration subsystem.

Automated processes in terms of subsystems and modules are presented in the figure below (Figure 7).

Figure 7. Automating processes in terms of subsystems and modules

This is, of course, not all diagrams, but I think that it’s enough to give an idea of ​​the model.

instead of the conclusion

When we started to develop the system, the knowledge of the subject area was based only on the half-page about medical devices mentioned at the beginning of GOST ISO 13485-2011. The models were discussed with the customer, there were no particular difficulties in “reading” the models.

AU developed in 2016-2017. under SQL Server 2014 Express, on C #, ASP.NET MVC 5 platform, for front-end - Javascript and JQuery. Mercury CL600R wireless scanners were used as remote barcode readers.

List of sources

  1. OMG Unified Modeling Language (OMG UML) Specification. Version 2.5.1. [Electronic resource] Access mode: Internet: .1/PDF
  2. Sparx Systems website. [Electronic resource] Access mode: Internet:
  3. Certificate No. 18249 on registration and deposit of a work of result of intellectual activity. Alfimov R.V., Zolotukhina E.B., Krasnikova S.A. The manuscript of the educational-methodical manual called "Modeling the subject area using Enterprise Architect"//2011.
  4. Zolotukhina EB, Vishnya AS, Krasnikova S.A. Business process modeling. - M .: COURSE, SEC INFRA-M, EBS - 2017.

Source text: UML & Enterprise Architect: design the target process when creating an automated system