System Statute: Describe Workflow Management with UML
Author: Pavel Hruby forward, wind.deng translation
Unified Modeling Language (UML) defines a series of standard symbols for the description object-oriented system. Use UML to enhance the communication between domain experts, workflow experts, software designers, and other different backgrounds. UML can be used in universal applications, and it is intuitive for users of the workflow system. In addition to these, the UML symbol has accurate semantics, that is, the visualized workflow description can be used as a software specification. This article focuses on how to use UML to describe the workflow management system, how to track the description information of the business process to object-oriented software design, how to use UML to interactive workpiece to structure the project knowledge base. In this article, we will first discuss software designers and users of workflow products, and then introduce how to use unified modeling language (UML) to describe the general workflow concept, and finally explore How to link the object-oriented software status and workflow system. Let's first describe a usual situation when you implement a new workflow management system: consultants describe a software solutions supported by a software solution. The development team gains consultants, but they are difficult to understand business terms and find that there are too many information to be difficult to implement this system. Developers write system regulations from technical perspectives, when the system is present in front of the user, because it is too professional, so that users are difficult to understand. However, in order to carry out the next step, the two sides are forced to accept this system status. This way is easy to cause the system to achieve the user's needs. Users, consultants, and developers are usually not used in the same language, so that there is difficult to ensure that all parts of the business process are well communicated and converted to technical software stations. In addition, because the actual user of this system is difficult to fully understand technical system regulations, it makes it difficult for software systems. Its challenge is to model it in an accurate and friendly approach to business processes and business systems. Each symbol used to describe the business process is very intuitive, and there is a definite semantic, so developers can use it as a general description and even used to accurately describe the software system status. UML has rich and complex symbols to describe the software system. These symbols may be too rich so that they are not intuitive, unfriendly. However, it is appropriate to describe the workflow management system to describe the workflow management system. First, UML is a standard symbol standard for software boundaries; second, UML can also be used in general situations that do not require detail. The UML map shown in the display and the experts already used in the field are in an intuitive, in addition, their semantics have precise definitions. If necessary, a detailed implementation details can be added to the same map for the purpose of software design. The description of the business system consists of a description of the process and static structure. The most intuitive model of the process is a sequence of activities or tasks, completed in order to reach a target. Therefore, the sequence diagram and active diagram of the UML are ideal for friendly, accurate, detailing business processes, such as static structures such as organizational maps, no detail, can be described with UML static structural diagram. Graphical implementation details tend to mislead those who are not proficient in UML. For example, the navigation arrow often erroneously represents the direction, preferably a particular subset of only the UML represents the option. For example, the element is nesting each other to indicate that the assembly is better than using the solid rhizome. Use text to describe the various properties without using the UML symbol, such as "refine", is much better than the triangular dashed line.
Workflow concept map to UML concept
Here is an example of using UML to describe the workflow concept. This only provides a general guidance, how to make the workflow concept into UML, detailed details are easy to get from the semantic and symbol guide [7] of UML. Each structure of a workflow management system can be described with a suitable configuration of the UML symbol.
Figure 1 represents business objects, business processes, team roles with UML
Figure 1 shows the use of UML to describe business processes, business objects, team roles. Business objects are represented by class and objects in UML. Class Description There is no business object, such as an invoice; an object describes a characteristic business object, such as an invoice number (VM 4/55: Invoice) numbered VM4 / 55 (VM 4/55: Invoice). Business Process 1 Use Examples and Use Example Examples to describe, use cases to describe based on targets, responsibilities, preamplifiers, and post conditions; use case objects are specific event sequences. Workflow is an automated business process with constructive << Workflow >>
Use examples or examples of examples. Using class and object description team roles in UML, describe the type of team role, and object descriptions of the role (Worker). All symbols can be modified with corresponding constructs, such as
<< Business Object >>, << Business Process >> and << Team Role >>
. Each constructor can be represented by text or a particular icon. Assuming that the business process is completed between business objects, roles, and other instances in the business system. Please refer to the detailed introduction "Tracking Business Process to Software Design".
Figure 2 UML static configuration diagram description team structure
Figure 2 shows an example of a team structure. The team's role is represented by an object instance, and the number of employees is specified for each role. A customer satisfaction team has three developers, two testers, a product manager and a person's role. The role group is called a customer satisfaction team, represented by a package symbol. The role group may also be represented as an object - as an assembly of the role. If the team expresses the relationship between the object, the team, and the role is the assembly relationship, according to the UML element model concept, a specific role instance cannot belong to more than one team. If the team is expressed as a package, a specific role instance can belong to several teams.
Figure 3 UML sequence diagram describing an example of a business process
Figure 3 depicts an example of a business process. The Customer Customer has a certain order and then a worker in the sales department confirms this order. If the order is valid, this worker calls another business process "Company Ships An Item" instance. This type of diagram is not clear in the UML representation method, however, it conforms to the UML element model. The symbol on the top of the object lifetime represents the classifier role, as role in Figure 3, object role, and use case role.
Figure 4 UML use case diagram describes static relationships between business processes
Figure 4 is an example of UML, described in the statically relationship between business processes. Business Process Description Organization and Role Customer Cooperative. Note that in the UML version 1.1, the use case cannot be associated with each other and always trigger by the role signal. This brings difficulties to the modeling environment, and one use case is running during operation, and the other use case will start starting. In this case, the role is initialized by contacting the contact with another use, without having to issue any particular start signals. For example, if the customer's request is evaluated as valid, use the COMPANY Ships An Item that is triggered by the object in the organization. This use case instance is not directly triggered by the customer, I hope the next version of the UML will reduce the limitations of the associated connection.
UML use case map is not easy to express the order of the use case instance, for example, first customer request an item, then the company will transmit this item, and finally payment. A solution method is to use constraints between the use of the case {precedes} or dependencies
<< Precedes >>
. Similar relationships are also present in Open Modeling Language, see [3], Robert C. Martin recommends using keyword FOLLOWS to replace Precedes, see [6]. The reason why this alternative is dependent
<< Follows >> Points to dependence << Preceds >>, dependency, dependency << Follows >>
Point to the usual dependency direction - from the dependent element points to the independent element, as for which one is more intuitive is still an unresolved problem. However, the charts with constraints or dependencies are still static structures and does not describe a specific scene.
Figure 5 UML sequence diagram Describe the interaction between business processes and executors (ACTOR)
The role can use the system with a method of initiating the use case. Scenes like this - Example Example Sequence - A sequence diagram or collaborative diagram can be described, referring to Figures 5 and 6. The control object interacts with each other, and the scene is described as a message sequence, and the scene is described as a sequence of sequences with an example intent. This figure is only a UML diagram of a scene consisting of an instance of another scene. The message call (invoke) represents the signal of the use case constructor and mapping to the use case from the role. According to the start operation of each use case, such as invoke request, invoke sales, invoke payment, you can name these messages, except for these messages, use case interactive maps to represent roles and systems The interaction between other messages and describes all the talks and characters.
Figure 6 UML interactive diagram describes interactions and relationships between business processes and roles
The use case collaboration map also describes a scene consisting of business process instances. Unlike the use case sequence diagram, the use case collaborative diagram describes the use case relationship and message interaction between the use case instance and the role instance. The use case cooperation is shown in Figure 6.
Figure 7 UML activity diagram describing the allowable order of business processes
The use of an example interaction is merely a typical scene consisting of an example example. Therefore, it cannot express all permissible sequences of the use case instance, and the sequence allowed by the use case instance of the use case can be described in detail within the use case lifecycle. The life cycle of the case can be used in a static diagram, and the Backus-Naur paradord (BNF) (see how [4] uses BNF specified lifecycle.) Active map representation, in these states, active status or BNF declaration mapping is used in case Use case. The use case lifecycle is an accurate description of the use case behavior, however it is difficult to correctly express, especially in complex use cases. Using an example interaction map is easy to express, but it is described only a typical scene consisting of an example in the package. Figure 7 is a UML activity diagram, which describes the life cycle of the Order Management (Order Management). The activities in the active diagram correspond to the use cases in Figures 4, 5, 6. Note that the UML element model does not define any mappings from state or behavior status to the use case instance, which can be carried out in the development process, similar to Martin and Odell methods, where each state of the subsystem refers to a candidate class in the mild system. . Reference [5]. Other development processes may then define the use case lifecycle in other ways. For example, the purpose of the use case lifecycle can be specified as the order of the subsystem interface operation within the range of the case. There is also a significant difference between the use of an example interactive model and the use case life cycle - they differ in the position of the project knowledge base and different from other design workpieces. The workpiece use case interaction model is associated with the workpiece use case model, the workpiece case case lifecycle is related to the workpiece case case, the latter abstract level ratio corresponds to the use case model and the use case interaction model.
Figure 8 Relationship between workpieces in the use case view in the project knowledge base.
The symbol is expressed in UML, and the dependency is represented by Role Ends3.
Structured structured project knowledge base
In the development process, software architects, designers and developers confirm some of the software products, such as use cases, software architecture, object collaboration, and class descriptions. This information may be very abstract, such as product prospects, or very specific, such as source code. In this article, we are called this information as a software product design workpiece (DESIGN Artifacts). We must recognize the difference between designing workpieces and its expression: Designing the workpiece to determine the information of the business system, and expression decides how to expand this information. Some design workpieces are represented by UML, and some use text or table, for example, the lifecycle of the class can be expressed in a UML status diagram, an active diagram, a status transfer table, or a Backus-Naur parameter. The class library is represented by text. The specifications of the workflow management system are defined based on the precisely defined design workpiece, not on the map. This section and the next section will discuss the structure of the design workpiece, this structure can clarify the relationship between business processes, business rules, software architecture, and business system design, and it is easy to extend to other aspects of the business system, such as team structure. And project plan. The business system can be described as a multi-level abstraction and a variety of views. Multi-level abstracts such as organizational level, system level, architecture level, class; multiple views such as logical views, modes view, analysis view, test view, or document view. At each level of abstract and in each view, software products can be described in four design workpieces: the static relationship between the classifier, the dynamic interaction between the classifier, the classifier responsibility, and the classifier lifecycle. Each workpiece can be represented by a UML map or text. As shown in Figures 9 and 10. Figure 9 Structured Project Knowledge Base Design Workpiece Mode
Figure 10 In each view of each abstract level, the software product can be described with four design workpieces.
The UML classifier is: class, interface, use case, node, subsystem, and components. The classifier model (Classifier Model) specifies the static relationship between the classifier. The classifier model can be a set of static structural diagrams (if the classifier is a subsystem, class or interface), it can be a set of examples (if the classifier is the use case and the executor), it can be a set of deployment diagrams (if the classifier It is a node), and it can be a set of components (if the classifier is a component). Classifier Interactive Model Specifies the interaction between the classifier. The classifier interactive model can be used to use each other: a sequence diagram or a collaborative diagram. The UML NOTATION Guide only describes those classifiers to interact with objects, and those classifiers are interactive in the classifier, subsystems, nodes, or components. The design workpiece is called a classifier (Classifier), specifies the duties, roles, and static properties of the classifier interface (for example, the operation table of the classifier, with pre-condition and post criteria). The classifier can also be represented by a structured text, such as a CRC card. Classifier Lifecycle Specifies dynamic properties of the classifier state machine and the classifier interface (for example, the order of operations and events allowed). The classifier lifecycle can be represented by a state diagram, an active diagram, and a status transfer table. One instance of the classifier model can be connected to several instances of the classifier interactive model, and all of these instances are linked to the classifier, and the classifier's instance links to the classifier lifecycle.
Track business processes to software design
In a well-structured design document, information about business processes and software products can be easily positioned, and the related information links together, while the structure also reflects the integrity and consistency of different design workpieces, it is business expert, consultant and Software developer's basis for communication. This structure also provides a significant concern, from business people instead of developers to define all business rules. This section discusses the relationship between business processes and software design workpieces, uses it to construct the project knowledge base, give the business process and their relationship with the relationship between the software design workpiece. See [4] to understand the specific example of the structure of the library. The structure is based on business processes in business objects, roles, and workers in the business system (represented by UML). Business Process (Sample) is defined as a collaborative type, indicating system operations for collaborative responsibilities, target, preamp, back conditions, and collaboration. Business Process Instance (with example instance) is a collaborative instance, indicating the specific order of behavior and events, system status, and status transfer in collaboration. Figure 11 Design workpiece describes the software system in logic and business process views
Figure 11 shows the relationship between the design of the business process and the logic design of the software system, and the workpiece is organized according to different abstract levels: organization level, system level, architecture level and object level
Organization Level specifies the responsibility of an organization (such as company, schools and government agencies), as well as the organization's business environment. Organization (Organization) specifies the organization's responsibilities and related static properties. The workpiece organization model (Organization Model) specifies the relationship between the organization and other organizations. The workpiece organization (Organization USE Case) uses process destination, pre-condition, back conditions, and business processes to specify business processes for organizations with its related static properties. This business process is a collaboration between organizations and other organizations, which is specified in the Organization USE Model, and see the dependency collaboration in Figure 11. An example of an organizational business process is specified by an organization interactive model (Organization Interaction Model) to interact with other organizations. Organization business processes can be refined to a more specific system business process, see the dependencies in Figure 11. The workpiece organization usage life cycle specifies the allowed system business process. Organization Use Case Intertion Model Specifies a typical business process example sequence, see the instance dependencies in Figure 11. The implementation of the organization business process is specified with the interaction between software systems and its users (team roles), and the dependencies are implemented in Figures 11 and 12. System Level specifies the environment of the software system and the relationship between its roles. The workpiece system (System) uses responsibilities, front conditions, back conditions, parameters, and return values to specify the interface and operation of the system. If role responsibilities and interfaces are related, and are specified by the workpiece role (actor). System Lifecycle Specifies the allowed system operations and events. System Model Specifies the relationship between software systems and roles (other systems and users), system interactive models specify interactions between software systems and characters. These interactions are examples of system business processes, see examples of relationships in Figure 11. The workpiece system use case specifies the business processes within the system range with the target, front condition, back condition, non-functional requirements, business rules, and other related static properties. This business process is a collaboration between the system and other systems or users. Collaboration between these systems and its roles is described in the System Use Case Model, as shown in Figure 11. The dynamic properties of the business process interface are as specified in the system operations allowed within the service process range, which is specified in the system use case cycle. System Uses Interact Model Specifies the sequence of a typical business process instance. The system business process can be refined into the subsystem business process, see the dependencies in Figure 11 refine. The system business process implements interaction between architectural subsystems to see the dependencies in Figure 11 implementation. Architectual Level defines subsystems (components), subsystem responsibilities, interface, relationship, and interaction. Subsystem duties, front conditions, post conditions, parameters, and return values specify the subsystem interface and subsystem operations.
Subsystem Lifecycle Specifies the order of operation and event of the subsystem allowed. Subsystem model specifies the relationship between subsystems and other subsystems, subsystem interaction model specifies the interaction between subsystems, which is an example of subsystem business processes, see 11 Dependent relationship << Examples >>. Subsystem Use Case specifies the business process within the subsystem, which is a collaboration between the subsystem and other subsystems, systems, and users. All collaboration between the subsystem and its roles is described in the System Use Case, see the dependence in Figure 11 << Collaboration >>. The dynamic characteristics of the subsystem business process interface, such as the subsystem operation order allowed in the business process range is specified in the subsystem use case life cycle. Subsystem Use Case Intertion Model Specifies a typical sequence of business process instances. The interaction between the sub-system business process is described with the interaction between the objects. See the dependencies in Figure 11 << Implementation >>. Object Level uses business objects, business objects, relationships, and interactions describe the designs of subsystems. Business Object Model Specifies the static relationship between business objects. Business Object Interaction Model uses the interactive specified subsystem operation between business objects. The workpiece business object (Business object) Specifies the statics of the service object and the static properties of the business object interface, such as the interface operation described with the front condition and the back condition. Business object lifecycle specifies the allowed interface operation order. In Figure 12, the design workpiece describes the organization team structure. In fact, it does not differ much from the workpiece describing the software subsystem structure. The role of the team can represent a UML structure type, a workpiece role (Role) specifies the responsibility of the worker role and other related static properties. The workpiece role lifecycle specifies the dynamic properties of the role, their status, and the events they respond. The workpiece role model (Role model) specifies the static relationship between the characters. Member Level Business Process Specifies collaboration between team member roles and other team members roles, see the dependencies in Figure 12 << Collaboration >>. Examples of these business processes are specified between the interaction of the Role Interaction Model with role examples, as shown in Figure 12 << Example >>. Figure 12 In the team and business process view, the design workpiece describes the software system
The design workpiece called Team (Team) is a role package that specificallys the team's responsibilities and related static properties. The team's dynamic properties are specified in the Team Life Cycle. The workpiece team model (Team Model specifies the static relationship between the team. Team Level Business Process Specifies collaboration between teams and other teams, see the dependencies in Figure 12 << Collaboration >>. The instance of the team-level business process is specified in the Team Interaction Level, as shown in Figure 12 << Example >>. The interaction between team-level business processes is specified between the interaction between team members and interactions between team members and software systems, as the dependencies in Figure 12 << Implementation >>. The mode of designing workpieces can be applied to higher abstraction level 4 with similar methods. The structure of the design workpiece described in this section can be simplified in two ways: • Only the subset of the design workpiece; • Combine some of the closely related design workpieces to form a larger design workpiece unit. The subset of the design workpiece does not cause loss of information because the UML chart system is not orthogonal. It means that the same information can be described with two or more different UML diagrams. For example, two static structural diagrams and object collaboration diagrams describe the relationship between objects. Two state diagrams and interactive diagram describes messages between objects. Because the same information can be described from several orientations, the developer is only a specific subset of design workpieces, otherwise the workpiece must accept inspections on consistency. Due to actual reasons, designers can create a larger interactive workpiece to include several closely related workpieces. For example, classifier duties and life cycles are always related to a certain document. It is also possible to combine organizational, system, subsystems, and class examples into a large-purpose example diagram to clearly use case levels. Similarly, system, subsystems, and business object static structures and interactive diagrams in all levels can be combined into one document, or use UML semantics to combine static structural diagrams, components, nodes, and per level. . In this way, the designer can express the relationship between the use of examples, roles, subsystems, business objects, team members, and business processes in a large static structural diagram. However, "UML Expiration Guide" did not clearly mention this. Combined static structural diagram. Small knot
This article discusses the use of UML to represent the object-oriented workflow management system, gives how typical workflow concepts into UML concepts, and recommends structured design workpieces to track the definition of business processes and between object-oriented software design. information. This structure demonstrates the business process to represent cooperation with other instances in business objects, team roles, and business systems. This structure is based on four-related design workpieces. These four design workpieces are classifier relationships, interactions, responsibilities, and life. cycle. This mode can be applied to different abstractions and different views of a business system, or other aspects of business and software system design.
