An action can be documented in an UML activity diagram. An action represents a single atomic step within an activity, and is not further decomposed within the activity.
Template Type: Symbols
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.
Assertion
Assertions represents claims, for example by management, regarding risks, action plans and accounts. The Assertion can be linked to Accounts and Control Activities. They are linked to risks through Control Activities, which represents the risk’s remedial action plans.
The Assertion can be described using its description field.
Account
The purpose of the Account template is to enable Financial Risk Management as documented in the Account Context Diagram.
The Account can in its properties be described with:
- a text description
- an account number
- a type (“Profit and loss” or “Balance Account”)
- link to a responsible Organization Unit
- description of purpose
- dates from which the account is valid from and to
- the currency of the amounts in the account
- the opening balance of the account
- the closing balance of the account
- the amount of the movements on the account
- a assessment of the account’s significance
- a rationale behind the account’s significance assessment
- furthermore, the account can be decomposed into several other accounts
The template can without graphics be linked to other objects under the “Risk – Influences” tab in their properties:
As such, the Account template is linked to objects the same way as the Financial Statement template:
Control Deficiency
The Purpose of the Control Deficiency template is to register a shortcoming of a Control Activity.
The Control Deficiency is used for managing Risk. It can be described with:
- Date of observation
- Type of deficiency
- Design (if the control is not designed properly)
- Operating (if the control is designed properly, but not performed correctly)
- Significance (High, medium or low)
- Observation – description of the deficiency in further detail and/or link to relevant documentation.
- Link to related process
- Link to the Control Activity it concerns.
- Description of any immediate actions taken
- Link to the person who registered the Control Deficiency
- Link to other Control Deficiency if it is not the first time it occurs.
- Description of presumed cause of the deficiency
- Description of the presumed consequence of the deficiency
- Recommended actions and their estimated cost and resource requirement
The Recommended action can also be registered in the form of a Corrective Action.
Risk
The Risk template is used for Risk Management purposes and can be linked to all objects in the repository. The Risk template supports the evaluation and continuous handling of the risk.
The Risk can be scored manually on its main tab: “Risk”, where it can also be given a Short Description, Type and Cause:
If you want to score the risk according to more specific categories, you can do so in under the Scoring tab:
You link a risk to the activity it concerns under the “Concerns” tab. Once it has been inserted here, the risk will appear as a “backwards relation” to the Activity. You can also create the risk from the activity and create the backwards relation automatically by using the inherent risk tab on the Activity and click on “Create risk”:
From the Risk-Control tab of Activities, you can also link to the risk. This link indicates that the Activity acts as a mitigating control for the risk. As such, there are two ways a risk can be linked to an activity: either as the activity where the risk is prevalent, or as the control activity that mitigates the likelihood or impact of the risk occurrence:
For more information about how to document Risks in QualiWare, please read our Risk Management Guide.
Evaluation
The Evaluation template is used for evaluating the effectiveness of a Control Activity.
In it, you can document findings in the form of Non-Conformances, Control Deficiencies and Change Requests. You can link to involved parties in the form of Organization Units, Persons and Business Connections, and link to the Responsible in the form of a Person. The conclusion results in the control activity be found either effective or ineffective. Clarifying concluding comments can be added.
Free Hand Start Stop
Start or stop symbol on a FreeHandDiagram
FreeHandStartStop properties
The FreeHandStartStop tab
| Property | Metamodel name | Description |
| Short description | ShortDescription | Short description of fragment |
| Breaks down to | BreaksDownTo | Reference to break down path Links to: AnyThing. |
| Group | ||
| Start | Start | Initial value is off. |
| Stop | Stop | Initial value is on. |
The Action tab
| Property | Metamodel name | Description |
| Macro | Macro | This field is used to create a command language program that can be executed when the user double clicks on the symbol. |
| Execute on Double-click | ExecuteOnDoubleClick | Macro is always executed when double clicking on the symbol. Initial value is off. |
Free Hand Sequential File
SequentialFile symbol on a FreeHandDiagram
FreeHandSequentialFile properties
The FreeHandSequentialFile tab
| Property | Metamodel name | Description |
| Short description | ShortDescription | Short description of fragment |
| Breaks down to | BreaksDownTo | Reference to break down path Links to: AnyThing. |
The Action tab
| Property | Metamodel name | Description |
| Macro | Macro | This field is used to create a command language program that can be executed when the user double clicks on the symbol. |
| Execute on Double-click | ExecuteOnDoubleClick | Macro is always executed when double clicking on the symbol. Initial value is off. |
Free Hand Right Bracket Comment
RightBracketSymbol symbol on a FreeHandDiagram
FreeHandRightBracketComment properties
The FreeHandRightBracketComment tab
| Property | Metamodel name | Description |
| Short description | ShortDescription | Short description of fragment |
| Breaks down to | BreaksDownTo | Reference to break down path Links to: AnyThing. |
The Action tab
| Property | Metamodel name | Description |
| Macro | Macro | This field is used to create a command language program that can be executed when the user double clicks on the symbol. |
| Execute on Double-click | ExecuteOnDoubleClick | Macro is always executed when double clicking on the symbol. Initial value is off. |