Analysis of UML Workflow Management System

Analysis of UML Workflow Management System

1 workflow Overview

The Research on Workflow originated in 1970s. Due to the limitations of the network, the initial workflow system mainly focused on file processing within the enterprise. By 1990s, With the development and application of Internet technology, the development of e-commerce applications has been greatly promoted, this makes it possible to process the business between the company and the company, between internal departments, and between subsidiaries, which brings great opportunities and challenges to the development of workflows.

According to predictions from international organizations, with the development of e-commerce, data processing-centric database products have entered a stable development period, and Business Process-centric workflow products will enter a period of rapid development. In China, with the standardization and scale of enterprise management, computer management of enterprises will not only stay on information resource management, but also move towards more complex business process management.

To achieve organizational goals, business activities are connected to each other in chronological or logical relationships to form a business process. During business development, documents, information, or tasks are transmitted, processed, or executed among participants according to organization specifications. In the overall business process, all or part of the automated process based on computer assistance is called a workflow. That is to say, a workflow is automatically executed in whole or in part with the help of a computer. The workflow can run in a heterogeneous and distributed operating environment for collaborative work. Workflow Server is a computer software platform that allows you to visually design, manage, and control business processes, and dynamically modify business processes during actual execution. It makes it possible to quickly develop, deploy and run enterprise business management systems and e-commerce systems. It also makes it possible for enterprises to quickly adjust their business or business processes in a complex and changing market environment to quickly adapt to market changes and save existing investment while the existing system remains unchanged. Such as procurement processing, various applications, order and quotation processing, employee performance appraisal, personnel changes, loan approval, claim processing, B2B, and e-commerce.

2 Workflow Management System Overview

A workflow management system is a system that defines, creates, and executes workflows. It is a special computer-Supported Collaborative processing (computer-Supported Collaborative processing) software system.

Workflow Management System Generation

The WfMS (workflowmanagementsystem) is a computer-supported distributed, collaborative work business flow automatic or semi-automatic as the research target software system. With the rapid development and application of computer networks, especially Internet/Intranet, the distributed and collaborative workflow systems supported by computers become more and more important in enterprises and public institutions, and have broad prospects.

A workflow management system is a system that defines, creates, and executes workflows. To develop such software systems, we need to coordinate activities on distributed and collaborative nodes and execute them according to predefined control procedures to achieve automatic execution and effective management of them. The development of such software is highly repetitive. the workflow management system abstracts the public process control part (Workflow running service, engine), management part, and other public parts of the software, to form a software development platform, users only need to describe their control processes so that the platform software can automatically execute and effectively manage their control processes, instead of repeatedly developing different applications each time.

Different workflow management systems can have different implementation methods, different underlying communication mechanisms, and a wide range of applications, however, from the perspective of the user's application layer, the general workflow management system should be able to provide the following three functions:

The first is to build a function, that is, to define and model the business processes of workflows and the activities that constitute these business processes.

The second is the operation control function. In a certain operating environment, it is responsible for creating, executing, and controlling workflow instances, and activating corresponding resources and applications, and transfer control from one activity to another. It is the core part of the entire workflow management system.

Finally, the interaction function is run. That is, when a workflow instance is running, the workflow management system interacts with the workflow participants (business work participants or controllers) and external applications.

Due to the development of information technology and increasingly fierce business competition, people are no longer satisfied with independent and scattered office automation and computer applications, but need integrated solutions. As a technology for managing and integrating conventional transactions, the emergence of WMS is inevitable. It can improve and optimize business processes, improve business efficiency, achieve better business process control, improve customer service quality, and improve business process flexibility.

3. Composition of the workflow management system

A complete workflow management system consists of the following seven parts and data.

A. process definition tool

A process definition tool is used to create a business process description that can be processed by a computer. It can be a formal process definition language or object relationship model, or a group of routing commands that simply specify information transmission between users.

B. Process Definition

Process Definition (data) contains all the necessary information that enables the business process to be executed by the workflow execution subsystem. The information includes the start and end conditions, composition activities, activity scheduling rules, the work that the participants of various businesses need to do, and the call information of related applications and data.

C. workflow execution subsystem and workflow engine

The workflow execution subsystem is also called the (business) process execution environment, which includes one or more workflow engines. The workflow engine is the core software component of WfMS. Its functions include interpreting process definitions, creating process instances, controlling their execution, scheduling various activities, adding work items to user worksheets, and using application interfaces (APIS, application program interfaces) call applications to provide supervision and management functions. The workflow execution subsystem can contain multiple workflow engines. Different workflow engines execute workflows in collaboration.

D. workflow control data

System Data managed by the workflow execution subsystem and workflow engine, such as the status information of the workflow instance and the status information of each activity.

E. Workflow-related data

Data related to the business process. WfMS uses the data to determine the status transfer of workflow instances, such as process scheduling decision data and inter-activity transmission data. Workflow-related data can be used by the workflow engine or called by applications.

F. worksheet and worksheet processing program

A worksheet lists a series of work items related to participants in a business process. A worksheet handler manages interactions between users and worksheets. The Worksheet processing program provides the following functions: You can select a work item in the worksheet, reassign a work item, and report the completion of the work item, call the corresponding application when the work item is processed.

G. Application and Application Data

Applications can be called directly by WfMS or indirectly through the application proxy. By calling an application, WfMS completes an activity partially or completely automatically, or supports the work of business participants. Unlike workflow control data and related data, application data is partial data for applications and invisible to other components of WfMS.

Glossary

4. Function Analysis of the workflow management system

As mentioned above, a complete general workflow management system should include seven parts. The reason for the limitation is only the core part of the workflow management system: analyze the workflow execution subsystem and workflow engine.

Core functions of the workflow management system

The core component of the workflow management system is the workflow execution subsystem, which provides a runtime environment for creating, initializing, and executing process instances.

A workflow execution subsystem can contain one or more workflow engines. The former is a centralized implementation method, and the latter is a distributed implementation method. Distributed implementation can be divided into two different scenarios: homogeneous and heterogeneous. Homogeneous refers to a running service system that contains multiple compatible workflow engines. Heterogeneous refers to a workflow management system that contains more than two heterogeneous workflow execution subsystems.

The workflow engine is the core software component of the workflow management system. Its main functions include interpreting process definitions, controlling process instances (creating, activating, suspending, and terminating), and calling various activities according to the defined business logic of the process, add work items for user worksheets, maintain workflow control data and workflow-related data, call applications, and provide supervision, management, and audit functions.

The workflow execution subsystem involves four types of data: workflow control data, workflow-related data, organization/role model data, and worksheets.

First, workflow control data. Internal control data maintained by the workflow execution subsystem is used to indicate the status information of process instances and activity instances.

Second, workflow-related data. Data related to business processes are generated and updated by applications or users through work item processing. The workflow engine determines the status transfer of process instances based on relevant data, for example, process scheduling decision data and data transmission between activities.

Third, organization/role model data. It is the data that describes the organizational structure and is mainly used to determine the executors of work items.

Type 4: Worksheet. Lists a series of work items related to workflow participants.

5. Modeling instances

 

5.1 create a Use Case View

The Use Case view captures system behaviors from the perspective of external users. It divides system functions into transactions that are meaningful to the user (the ideal user of the system. These function sheets are called use cases. Use Cases describe the interaction with the operator through a series of messages between the system and one or more activists. Its activists include people, other computer systems and processes.

The activist is represented by a villain. The name of the activist is marked below the villain. The use case is represented by an ellipse. The name of the use case is marked in or below the ellipse, and is connected to the operator who communicates with the real line. The Use Case view is used to model the system functions perceived by the active users. The purpose is to list the active users and use cases and display the active users in each use case.

A. workflow execution Subsystem

Figure 1 shows the use case of the workflow execution subsystem. Activity participants include wfclient, monitor, definitiondb, enactmentdb, and organizationdb), applicationdb (application database), workitemdb (work item database), and configfile (workflow system configuration file ). Here, as part of the interface for receiving user interaction, wfclient sends requests to the workflow execution subsystem for processing according to fixed rules. As part of the interface for Receiving System Administrator interaction, monitor sends system adjustments made by the system administrator to the workflow execution subsystem for processing. Other definitiondb activities are responsible for recording the operations and status of each step of the workflow execution subsystem to the database for permanent storage. Use Cases include resourcelocate, enginecontainer, processdefload, processmonitor, and util ). Enginecontainer uses resourcelocate to locate all resources used by the system. The enginecontainer Use Case uses resourcelocate and uses a solid line with arrows. Enginecontainer does not directly interact with the user. The worker participates in the workflow through the entrance of the workflow execution subsystem processmonitor. Enginecontainer loads existing workflow definitions through processdefload to run the workflow. The relationship between enginecontainer use cases and resourcelocate use cases is described as follows.

Here, only the specific function analysis of the Use Case processmonitor is provided. These function analyses are used as comments to the processmonitor use cases. They are not identified in the use case diagram and only serve as the key points of detailed system design. The analysis method for other use cases is similar.

As a part of the engine container, the Process Monitoring Server provides external monitoring of the running status of the engine container, that is, querying the current running status of the engine.

For example, when the client or management end needs to know the running status of the engine, it first sends a message request, and the message server then interprets the message after receiving the message, if the query engine is running, call the API provided by the Monitoring Service (application interface) to query the engine and return the result to the requester.

The query requests processed by the Monitoring Server mainly include the following content based on different request objects:

Engine container running status query; engine running status query; process definition Information Query; process instance information query; Activity instance information query; work item information query; synchronous command request response.

B. Workflow Engine

Figure 2 shows the use case of the workflow engine. The activites include enginemanager and logfiles ).

Enginemanager controls the status of all elements in a workflow and is the core of workflow scheduling. Logfiles records fixed formats as logs for storage. Examples include processcontrol, transitioncontrol, activitycontrol, workitemcontrol, and danamaticmodify) and createlogfile (create a log file ). According to certain conditions, enginemanager uses processcontrol, transitioncontrol, activitycontrol, workitemcontrol, and danamaticmodify to control the status of each component element of a workflow.

C. process supervision

Figure 3 shows an example of Process Monitoring. The activites include enactmentdb (Workflow running database) and enginecontainer (engine container ). Examples include enginequery, processdefquery, enginecontainerquery, and processinstancequery) activityinstancequery, workitemquery, and transitionquery ).

Here, we only perform detailed functional analysis on the processinstancequery case. The analysis method for other cases is similar.

Processinstancequery is used to query process instances in the system. It mainly includes the following content: obtaining the list of process instances: obtaining a list Of all process instances in the system; obtain information about a process instance from the process instance list. obtain detailed information about the process instance based on the specified process instance number. Disable the list of opened process instances; obtains a list of various states of the Process instance in the system, queries its status based on the given process instance number, and closes the list of opened process instances; obtains the list of various attributes of a process instance in the system.

5.2 create an interactive view

 

The interaction view describes the message exchange sequence between system behavior roles. A category role is the description of objects that act as special roles in interactions. The interactive view provides a global description of the behaviors in the system and displays the control processes between multiple roles. The interaction view is displayed by two different types of graphs with different focuses: Sequence Chart and collaborative graph.

Message refers to the one-way communication between roles, from the sender to the receiver carrying information control flow. A message may contain parameters that pass values between roles.

The sequence diagram and collaborative plot show interactions, but they emphasize different aspects. The sequence diagram shows the chronological order, but the relationship between roles is implicit. The collaboration diagram shows the relationship between roles and associates messages with the relationship. However, the time sequence is not obvious because it is expressed by a sequence number. Each chart should be used based on the main focus.

A. Sequence Diagram

A sequence chart shows a series of messages that are scheduled over time. Each category role is displayed as a lifeline, representing the role during the entire interaction period. The message is displayed as an arrow between the lifeline. A Sequence Chart can express a scenario, that is, the specific history of a transaction.

A sequence chart displays interactions in two-dimensional charts. The vertical line is the timeline, and the time is from top to bottom. A category role that represents a single object in the collaboration is displayed horizontally. Each object is represented by a box. The object name is inside the box and underlined under the name. Each category role is represented by a vertical column-lifeline. During the time when the role exists, the lifeline is displayed as a dotted line. During the role activation time, the lifeline is displayed as a double line.

The message is displayed as the arrow from one role lifeline to another. The Arrow is arranged from top to bottom in chronological order. A purpose of a sequence chart is to show the behavior sequence of a use case. When the behavior is implemented, the messages in each sequence diagram are the same as the operations on the object or the event triggers during migration in the state machine.

Figure 4 shows the order of request case processing. The five boxes in the figure represent five objects: processmonitor, enginemanager, engine, entactmentdb, and logfiles. This example is generated when processmonitor receives user operations, converts these operations into fixed requests, and sends them to the engine for execution.

After processmonitor receives the operations performed on the user interface, it converts these operations to fixed command requests and sends them to enginemanager. Enginemanager then delivers commands to different engines based on the type of the command received. The engine executes the corresponding commands. After the engine executes the command, it notifies entactmentdb to modify the corresponding data. Then, the engine notifies logfiles to record the operations for future query. Finally, the engine directly returns the result to processmonitor, which packs the result and displays it to the user.

B. Collaboration Diagram

A collaboration diagram is used to model objects and links that have meaning in interactions. Objects and links are meaningful only in the context provided. CATEGORY roles describe objects and associated roles describe links in collaboration. A collaboration chart displays the role in the interaction through the geometric layout of the image. The message is displayed as an arrow that links to the category role. The order of messages is represented by the sequence number before the Message description.

A collaboration chart is used to represent the implementation of operations. Collaboration shows the operation parameters and local variables, and more permanent associations. When the behavior is implemented, the message sequence is consistent with the nested call structure of the program and the signal transmission.

Figure 5 shows the collaboration diagram corresponding to the request case processing. This example is generated when processmonitor receives user operations, converts these operations into fixed requests, and sends them to the engine for execution. This collaboration diagram shows the relationship between the five objects involved in processing the request case.

5.3 create a state machine View

The state machine view models the possible life history of an object and describes the dynamic behavior of the object in a time series. Each object is considered an isolated entity that detects an event and responds to it to communicate with the outside world. An event represents a change that an object can detect-call between objects or display signals, a change in a value, or a passage of time. Anything that affects the object can be described as an event. What happens in the real world is modeled as signals from the external world to the system.

A State refers to a series of object values that have the same response property for an event in a specific class. In other words, all objects in the same State respond to an event in the same way, that is, all objects in the same State perform the same action when receiving the same event. Objects in different States may have different responses to the same event and execute different actions.

The state machine contains the state connected by the event. Each State is modeled for a period of time in an object's life cycle, during which the object meets certain conditions. When an event occurs, it may trigger the migration and change the object to the new State. When the migration is triggered, the actions attached to the migration can be executed. The state machine is displayed as a state chart in UML.

In the state machine View, the State is represented by a rectangle with rounded corners, the initial State is represented by a circle filled with solid, and the ending State is represented by a circle in a circle coat filled with solid.

Figure 6 shows the state machine view of the Process instance. As you can see, a workflow-defined process instance may have five different processes at run time, namely the initial status, readiness status, running status, suspension status, and end status.

 

A process instance is in the initial state (Initial State ). As needed, an instance is created (create) to become ready (ready ). Then, you can select a ready process instance to start as needed, and the status of the started process instance changes to running ). The process instance in the ready and running status can be changed to the end state by canceling the operation (abort ). A running process instance can be changed to a suspended state (holded) through the hold operation ), an instance in the pending status can also be changed to running by running. The difference between the suspended state and the ending state is that the suspended state does not release the resources occupied and can be recovered. Finally, if an instance in the running status is completed, it is changed to the terminated status by completing the operation (finish.

A state machine can be used to describe user interfaces, device control, and other interactive subsystems. They can also be used for objects that have gone through several specific stages in their life, each stage has special behavior.

5.4 create an activity View

The activity view is a special form of displaying the state machine used to execute an operation activity during a computing process. The activity status indicates the execution status of the operation: the execution of the steps or operations of the process. The activity diagram describes the sequence and concurrent activity groups. The activity view is expressed as an activity chart.

The activity diagram contains the activity status. The activity status shows the execution of statements in the process or the execution of activities in the workflow. Unlike the General wait state wait event, the activity state waits for the end of the operation. When the activity ends, the next activity in the figure is processed. When the previous activity ends, the end migration in the activity diagram is triggered. There is usually no migration of external events in the active state, but they can be canceled by events in the peripheral state.

In the activity diagram, the left and right sides are the rectangles of the arc to represent the activity, the rough horizontal line to represent the distribution of the activity, and the arrow line to represent the order of the activity processing.

Figure 7 shows the user's operation activity diagram. Before using the functions provided by the system, you must first log on to the system. That is to say, the first step is to log on (LOGIN ). After logging on, you can select one of the three operations: Choose process define, choose process instance, and choose workitem ). The execution of these three activities is not sequential and is completely selected by the user.

 

After you select a process definition, you can create an instance of the selected process definition, that is, execute the create process definition activity (create process define). After you select a process instance, depending on the instance status of the process, you can terminate (abort), start (start), hold (hold), and run (run) The process instance, the execution of these operations is not sequential. After you select a work item, you can execute this work item, that is, do workitem ).

Analyze the functional layers of the workflow management system based on the Use Case view, InterAction view, state machine view, and activity view, we should have a clearer understanding. These understandings and understandings will lay a good foundation for further design.