System conventions: Describing workflow management with UML

Unified Modeling Language (UML) defines a series of standard symbols for describing object-oriented systems. Use UML to enhance communication between domain experts, workflow experts, software designers, and other experts from different backgrounds. UML can be used in common situations and is intuitive to the users of the workflow system. In addition to these, UML symbols have exact semantics, meaning that visual workflow descriptions can be used as software specifications. This paper discusses how to use UML to describe workflow management system, how to track the description information from business process to object-oriented software design, and how to use UML interactive workpiece to construct project Knowledge Base.

In this article, we first discuss the needs of software designers and users of workflow products for a common language, then we'll talk about how to use the Unified Modeling Language (UML) to describe the general workflow concept, and finally we want to discuss how to relate the Object-oriented software specification to the description of the workflow system.

Let's begin by describing the usual scenario for an enterprise when implementing a new workflow management system:

The consultant, together with the user, describes an enterprise business process supported by a software solution. The development team gets a description of the consultants, but it is difficult for them to understand the business terminology and find that it describes too much information to be used to implement the system. The developer writes the system specification from the technical point of view, when presenting the system specification in front of the user, because it is too professional, so that the user is difficult to understand. For the next step, however, both sides were forced to accept the system's statute.

This approach can easily lead to a system that does not meet the needs of the user. Users, consultants, and developers are often not in the same language, and such communication issues make it difficult to ensure that all parts of the business process are well communicated and converted into technical software specifications. In addition, because it is difficult for actual users of this system to fully understand the technical system specification, making software systems difficult to use.

The challenge is to model business processes and business systems in a way that is both accurate and user-friendly. Each symbol used to describe the business process is intuitive to the user and has certain semantics, so developers can use it as a general description or even to describe the software system specification accurately.

UML has rich and complex symbols to describe software systems. These symbols may be too rich to be intuitive or unfriendly. However, there are two great benefits to using UML to describe workflow management systems. First, UML is a recognized symbol standard in the software industry, and secondly, UML can be used in general situations where no details are needed. The UML diagrams shown are visually similar to those already used by domain experts, and their semantics are precisely defined. If necessary, you can add detailed implementation details to the same diagram for software design purposes.

The description of the business system consists of a description of the process and the static structure. The most intuitive model of a process is a sequence of activities or tasks, complete in order to reach a target. Therefore, UML sequence diagram and activity diagram are very suitable for friendly, accurate and detailed description of business processes, such as organization diagrams, such as static structure, no implementation details, can be described in UML static structure diagram. Graphical implementation details tend to mislead people who are not proficient in UML. For example, a navigation arrow often incorrectly represents a direction, preferably a specific subset of the options in UML only. For example, it is better to have elements nested together to represent an assembly than a solid diamond representation association. Using text to describe a variety of properties without UML notation, such as "refine", is much more comprehensible than a dotted line with triangles.

Workflow Concepts map to UML concepts

Here is an example of using UML to describe workflow concepts. This only provides a general guide on how to image the workflow concept as UML, and detailed details can easily be obtained from the UML Semantics and Symbolic Guide [7]. Each structure of a workflow management system can be described with a suitable stereotype of UML notation.

Figure 1 representing business objects, business processes, and team roles in UML

Figure 1 illustrates the use of UML to describe business processes, business objects, and team roles. Business objects are represented in UML with classes and objects. A class describes a business object that has no attributes (identity), such as invoices (invoice), and an object that describes an attribute business object, such as an invoice numbered VM4/55 (VM 4/55:invoice). Business Process 1 is described using use cases and use case instances, which are described by objectives, responsibilities, preconditions, and post conditions; a use case object is a specific sequence of events. Workflows are automated business processes that are described using use cases or use case instances with stereotypes <<workflow>>. In UML, class and object are used to describe the team role, with the class describing the type of team role, and the object describes the specific worker (worker) who holds the role. Roles All symbols can be decorated with the appropriate stereotypes, such as <<business object>>, <<business process>>, and <<team role>>. Each structure can be expressed in words or a specific icon.

Suppose that a business process is done in collaboration between business objects, roles, and other instances in the business system. See "Tracking business processes to software design" in detail.

Figure 2 UML Static structure diagram describes the team structure