Solution Architects | QualiWare Center of Excellence

AcceptEventAction

In the Unified Modeling Language (UML), an AcceptEventAction waits for the occurrence of one or more Events. If an accepted Event occurrence is for a CallEvent, then a ReplyAction may be used to reply to it. If an accepted Event occurrence is for a SignalEvent, then the received Signal instance may either be unmarshalled immediately into its attribute values, or this may be done later using an UnmarshallAction.

AcceptEventAction is an Action with Triggers for one or more Events. When an AcceptEventAction is executed, it waits for an Event occurrence to be dispatched from the event pool of the context object for its execution that matches one of its Triggers. The context object for an AcceptEventAction is the context object of the Behavior execution within which the AcceptEventAction is executing (which may be the Behavior execution itself. An AcceptEventAction is a wait point, except only the AcceptEventAction waits, rather than the whole Activity (Activities can have other Actions executing while AcceptEventActions are waiting).

If a matching Event occurrence for an AcceptEventAction is dispatched from the event pool, then the AcceptEventAction is enabled to continue. However, if the containing Behavior execution has more than one waiting Trigger that matches the Event occurrence, only one of them will be selected to actually trigger. If the Trigger on the AcceptEventAction is chosen, then it completes and produces output on any result OutputPins.

An AcceptEventAction with a trigger for a SignalEvent is informally called an accept signal action. If an accept signal action has isUnmarshall=false, then it must have a single result OutputPin on which the Signal instance associated with an accepted SignalEvent occurrence is placed. If it has isUnmarshall=true, then it must have result OutputPins corresponding to each of the attributes of the Signal of the SignalEvent (in order), and the attribute values of the Signal instance associated with an accepted SignalEvent occurrence are placed on these OutputPins.

An AcceptEventAction with a trigger for a TimeEvent is informally called a wait time action. A wait time action must have a single result OutputPin. When it accepts a TimeEvent occurrence, then the time value of when the occurrence transpired is placed on the result OutputPin.

If the triggers of an AcceptEventAction are all for ChangeEvents and/or CallEvents, then the AcceptEventAction has no result OutputPins (unless the AcceptEventAction is an AcceptCallAction). If the triggers include SignalEvents and/or TimeEvents along with ChangeEvents and/or CallEvents, then the AcceptEventAction must have isUnmarshall=false and a single result OutputPin, on which a null token is placed in the case of the acceptance of an occurrence of a ChangeEvent or a CallEvent.

NOTE. While an AcceptEventAction can, in general, contain triggers for CallEvents, it cannot accept synchronous calls unless it is an AcceptCallAction.

If one of the triggers of an AcceptEventAction is an AnyReceiveEvent, and the Event occurrence is for a message that is not matched by a SignalEvent or CallEvent trigger on the same AcceptEventAction, then the Event occurrence matches the trigger for the AnyReceiveEvent.

If an AcceptEventAction is used in an Activity, there are special rules for when it is enabled. If the AcceptEventAction has no incoming edges, by the usual rules, it is enabled when its immediately containing Activity (or StructuredActivityNode) begins execution. However, in addition, an AcceptEventAction with no incoming edges remains enabled after it accepts an Event occurrence. That is, it does not terminate after accepting an Event occurrence and outputting any values, but continues to wait for another Event occurrence. Such an AcceptEventAction is terminated when its immediately containing Activity (or StructuredActivityNode) is terminated.

Workflow Diagram

Purpose: The purpose of the Workflow Diagram template is to document the Business Processes of an enterprise at the activity level.

Concerns: The Workflow Diagram template should be used to document the Activities, Roles, Business Events, Activity Paths and Workflow Conditions of a Business Process. Available in the default modeling syntax are also Business Objects, External Objects, Information Systems, Database, Inventory, Information Flow and Logistical Flow. The syntax can be easily extended to include more objects such as Requirements, Business Rules and Goals. Below you can see an example of a Workflow Diagram with multiple Roles that are modelled vertically:

Relation to other templates: The Workflow Diagram does not support BPMN, if using that notation, you should model in the Business Process Diagram template. The Workflow Diagram can link to other Workflow Diagrams and are typically linked to by Business Process Networks. In the picture below, you can see another example of a Workflow Diagram. Here the Roles are modelled horizontally and you can see the links to and from other diagrams at two Business Events (‘ECR completed’ and ‘Rework’):

Other functionalities: In QLM, you can control which buttons related to risk management are shown below activities. You can choose to hide or show Risks, Controls and Key Controls. Both Controls and Key Controls are a type of Activity. From the Risk related toolbars (available via the “Actions” tab on the right-hand side of the Canvas in QLM) choose the following button to control what button panels appear on the Activity objects:

Properties and metadata: The Workflow Diagram can for example retain the following information:

A description of the diagram
Information on cost and duration of the process
Link to the owner of the diagram
Link to the one responsible for the accuracy of the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Workflow Diagram’s properties dialogue window, where the diagram’s properties can be viewed and edited:

Use Case Diagram

Purpose: The purpose of the Use Case Diagram template is to document user interactions in a system context, as well as the context between different cases of user interactions. Below, you can see an example of a Use Case Diagram for the service at a restaurant:

Core concerns: The available objects you have to model use cases include: System Boundary, Actors, Use Cases, and connectors such as Association, Generalization, Include and Extend. Below, you can see an example of a Use Case Diagram for a booking system at a car rental service:

Relation to other diagrams: It is important to break down use cases into other diagrams such as Sequence Diagrams, Communication Diagrams, and Activity Diagrams templates for elaboration.

Properties and metadata: The Use Case Diagram can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the accuracy of the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Use Case Diagram’s properties dialogue window, where the properties can be viewed and edited:

Transformation Plan

Purpose: The purpose of the Transformation Plan template is to document strategic transitions over time in the form of transformation plans. Below is an example of a Transformation Plan consisting of a sequence of projects:

Core concerns: The Transformation Plan template should be used to document the transformation of a part of an enterprise from a current to a future state. Additionally, a past state can be documented for reference. The template allows you to model Projects, Initiatives and Business Cases, and connect them with Activity paths and generic Connections. Below is an example of a Transformation Plan that specifies Initiatives, their related Projects and Business Case:

Relation to other templates: The Transformation Plan template should not be used to document project plans for calculating a Critical Path. The Critical Path Method Diagram should be used for that purpose. The Projects can be further detailed in a Work Model that includes Milestones in its syntax.

Properties and metadata: The Transformation Plan can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the accuracy of the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Transformation Plan’s properties dialogue window, where the properties can be viewed and edited:

State Machine Diagram

Purpose: The purpose of the State Machine Diagram template is to document the dynamic behavior of a class or an object.

Core concerns: The State Machine Diagram template enables you to model States, Pseudo States, History States, Lines and Annotations. These can be connected by Transitions.

As such, the State Machine Diagram can be used to show the different states of a class or an object and how the class or object responds to various events by changing from one state to another.

Below, you can see an example of a State Machine Diagram for an ATM:

Relation to other templates: The State Machine Diagram can be a decomposition of a State and can also be derived from a Class. The State Machine Diagram template is related to, but cannot replace the State Event Diagram, which is used to document Event States and time dependent behavior of systems.

Properties and metadata: The State Machine Diagram can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the diagram
Link to a specific State of an object the diagram specializes
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the State Machine Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

State Event Diagram

Purpose: The purpose of the State Event Diagram template is to document the time dependent behavior of a system by showing the different States and State Transitions a system can go through.

Core concerns: The State Event Diagram enables you to model States and connect them with State Transitions. The State can be manipulated by opening its properties dialog and chose ‘Final State’ to illustrate the end of the state. The Start event is created by choosing ‘Start’ in the properties of the State Transition.

Below, you can see an example of a State Event Diagram for an ordering system:

Relation to other templates: The State Event Diagram template should not be used to model Machines States. The State Machine Diagram template should be used to model these types of diagrams instead. The State Event Diagram offers a view of a system which is complimentary to those presented by for example, Use Case Diagrams Communication Diagrams, Component diagrams and Sequence Diagrams.

Properties and metadata: The State Event Diagram template can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram

The above picture shows the properties dialogue window for the State Event Diagram template, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Sequence Diagram

Purpose: The purpose of the Sequence Diagram template is to document interactions between processes over time. Below you can see a Sequence Diagram for a car rental’s booking system:

Core concerns: Sequence Diagrams are typically used to document object interactions over time in a use case for an Information System. Objects are situated along vertical Lifelines. Horizontal arrows that travel between the lifelines in a set sequence are used to illustrate how message exchanges occur at a specific point in time. The objects available in this model are Lifelines, Combined Fragments, Interaction Use, Gates, Time Constraints and Duration Constraints and Messages. Below, you can see an alternate example of a Sequence Diagram for a car rental’s booking system:

Relation to other templates: Though the customer can be included in this type of diagram, you should use the Customer Journey Map to document and analyze the customers’ interactions with your organization. If you want to map a simpler view of actors’ interactions with a system without details on time constraints, you can use a Use Case Diagram.

Properties and metadata: The Sequence Diagram can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the accuracy of the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Sequence Diagram’s properties dialogue window, where the properties can be viewed and edited:

Requirement Model

Purpose: The purpose of the Requirement Model template is to document goals, objectives and other requirements for the enterprise or a specific project. Below, you can see an example of a Requirement Model showing the Policies and Business Rules of an organization:

Core concerns: With the Requirement Model template, you can for example model Requirements, Goals, Change Requests, Policies, Business Rules, Critical Success Factors and Problems. This enables you to illustrate the interrelationships of requirements, for example showing which goals influence or contribute to each other, as the example below shows:

You can also divide goals up in different areas that may for example be subject to different regulations as below:

Relation to other templates: The Requirement Model offers a more detailed view on Requirements and Goals filtering out elements such as vision and mission compared to the Strategy Model. It can be used to detail how your organization live up to requirements specified in a Regulation Diagram or Requirements indicated in a Stakeholder Model.

Properties and metadata: The Requirement Model can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the accuracy of the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Requirement Model’s properties dialogue window, where the properties can be viewed and edited:

Product Rule Table

Purpose: The purpose of the Product Rule Table template is to document the rules pertaining to a specific product.

Core concerns: The Product Rule Table is used as an auxiliary template and functions like a matrix that contains Product Rules.

Below, you can see an example of a Product Rule Table for a balcony:

Relation to other templates: The Product Rule Table is related to templates such as Manufacturing Routing Network, Product Architecture, and Product Variant Master.

Properties and metadata: The Product Rule Table can for example retain the following information:

A description of the table
Audits (auto generated information regarding its current state and access rights)
Matrix Behavior

The above picture shows the properties dialogue window for the Product Rule Table where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Product Architecture

Purpose: The purpose of the Product Architecture template is to document the building blocks of a product. Below is an example of a product architecture:

Core concerns: The Product Architecture template enables you to model a Product and connect different parts of it with three different connection types: Part of Product, Kind of Product, and Product Interface. See below for an example of a Product Architecture where each Product object is represented graphically:

Relation to other templates: Depending on whether the product is in production or in its development phase, it could be further described in a Product Viewpoint template, have a Product Variant Master, Product Rule Table or be represented in a Product Canvas. It may also be illustrated along with other products in a Product Roadmap, just as its production may be detailed in a Manufacturing Routing Network.

Properties and metadata: The Product Architecture can for example retain the following information:

A description of the diagram
Link to the owner of the diagram
Link to the one responsible for the accuracy of the diagram
Audits (auto generated information regarding its current state and access rights)
Associated documents, diagrams and other objects
Inherent Risk detailing risk considerations
Governance information detailing information about the published diagram and who has been involved in the approval of the diagram
Project status: information about budgeted and actual man-hours spent, percentage completed and the latest milestone, result and quality control of a change process.

In the picture below you can see the Product Architecture’s properties dialogue window, where the properties can be viewed and edited: