Archives: Templates

Templates and model types in the QualiWare platform.

Action

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.

Acknowledge List

The Acknowledge list function enables you to keep track of and document which of your employees have read which relevant documentation.

An acknowledge list is used to select a group of people who must digitally acknowledge that they have read or studied specific sets of documentation. This can for example be a diagram, a document, or a set of regulations. An acknowledge list can be a one to one or a many to many relationships between objects and people. This means that you can have several people, InterestGroups, OrganizationalUnits or several objects listed in the same acknowledge list.

Once a user is assigned to acknowledge an object, the user will get a govenance task, and an “Acknowledge” action-button is shown in relation to e.g. the Diagram:

The Acknowledge history can be seen on the “Acknowledge History” tab:

 

A user can access their ackowledge task(s) via their “My task” action button in the top right

And from their “To Do list” from the desktop.

Access ArchiMate

Access ArchiMate is one out of three ‘Dependency Relationships’ from the ArchiMate metamodel. IT represents a data dependency and is denoted by a dashed line.

Dependency relationships describe how elements support or are used by other elements. Three types of dependency relationship are distinguished:

  • The servingrelationship represents a control dependency, denoted by a solid line.
  • The accessrelationship represents a data dependency, denoted by a dashed line.
  • The influencerelationship is the weakest type of dependency, used to model how motivation elements are influenced by other elements.

Note that, although the notation of these relationships resembles the notation of the dependency relationship in UML, these relationships have distinct meanings in ArchiMate notation and (usually) point in the opposite direction. One advantage of this is that it yields models with directionality, where most of the arrows that represent such supporting, influencing, serving, or realizing dependencies point ‘upwards’ towards the client/user/business. Another reason for this direction, in particular for the serving relationship, is that it abstracts from the ‘caller’ or ‘initiator’, since a service may be delivered proactively or reactively. The direction of delivery is always the same, but the starting point for the interaction can be on either end. UML’s dependency is often used to denote the latter, showing that the caller depends on some operation that is called. However, for modelling this type of initiative, the ArchiMate language provides the triggering relationship, which can be interpreted as a dynamic (i.e., temporal) dependency. Similarly, the flow relationship is used to model how something (usually information) is transferred from one element to another, which is also a dynamic kind of dependency.

If you want to learn more about the ArchiMate language, you can find the specification here

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.

Abstraction

The Unified Modeling Language (UML) defines an Abstraction as a Relationship that relates two Elements or sets of Elements that represent the same concept at different levels of abstraction or from different viewpoints.

Semantically, an Abstraction is a Dependency that relates two NamedElements or sets of NamedElements that represent the same concept at different levels of abstraction or from different viewpoints. The relationship may be defined as a mapping between the suppliers and the clients. Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional. Abstraction has predefined stereotypes (such as Derive, Refine, and Trace) that are defined in UML’s Standard Profile. If an Abstraction has more than one client, the supplier maps into the set of clients as a group. For example, an analysis-level Class might be split into several design-level Classes. The situation is similar if there is more than one supplier.

 

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.