A PartnerLink is a physical place where a process is running
Archives: Templates
Templates and model types in the QualiWare platform.
Path : ArchiMate
A path is used to model the logical communication (or distribution) relations between nodes. It is realized by one or more communication networks (or distribution networks when modeling physical elements; see Chapter 11), which represent the physical communication (or distribution) links. The properties (e.g., bandwidth, latency) of a path are usually aggregated from these underlying networks.
A path connects two or more nodes. A path is realized by one or more networks. A path can aggregate nodes.
Path properties
The Path tab
Property | Metamodel name | Description |
Short description | ShortDescription | |
Implements | Implements | Links to: All templates. |
BreaksDownTo | BreaksDownTo | Links to: All templates. |
Peripheral
A peripheral can be any type of item which exists in the infra structure which you want to add to a InfraStructureDiagram. Typically it is a hardware device which is physically defined by a HardwareComponent.
Peripheral properties
The Peripheral tab
Property | Metamodel name | Description |
Short Description | ShortDescription | A short description of the item |
Type | PeripheralType | The type of the peripheral. |
Show | ShowType | Display the type next to the symbol on diagrams. Initial value is off. |
Hardware | Hardware | The hardware or computer that implements the peripheral. Links to: Computer, HardwareComponent. |
IP Address | IPAddress | The IP address of the device if the address is fixed |
Logical name/address | LogicalAddress | The logical name or address of the item. |
Show | ShowNetworkName | Display the network name next to the symbol on diagrams. Initial value is off. |
Vendor | Vendor | The vendor of the item. The vendor might for instance be an internal organisation unit or an external supplier. Links to: BusinessConnection, ExternalEntity, OrganizationUnit. |
Support | Support | The support provider. Links to: BusinessConnection, Person, ExternalEntity, OrganizationUnit. |
The Economy tab
Property | Metamodel name | Description |
Date of purchase | DateOfPurchase | When the item was purchased |
Warranty expires | WarrantyExpires | When the warranty of the item expires |
Contracts | HasContract | All the different contracts connected to the item. Links to: Contract. |
Plateau : ArchiMate
In order to support this, the plateau element is defined.Plateau propertiesThe Plateau tab
Property | Metamodel name | Description |
Short description | ShortDescription | |
Implements | Implements | Links to: All templates. |
BreaksDownTo | BreaksDownTo | Links to: All templates. |
Policy
A policy is a symbol that represents a set of rules or guidelines that govern an organization’s behavior, decisions, or actions. Policies can be depicted in various types of diagrams, such as Requirement Model, Strategy Model, or Value Chain Model, among others.
Here are some examples of policies that could be represented as symbols in diagrams:
- Acceptable Use Policy: a policy that outlines acceptable and unacceptable behaviors when using an organization’s technology or network resources.
- Security Policy: a policy that defines how an organization’s information and technology assets should be protected from unauthorized access, use, disclosure, disruption, modification, or destruction.
- Privacy Policy: a policy that informs individuals how their personal information is collected, used, stored, and shared by an organization.
- Environmental Policy: a policy that establishes an organization’s commitment to sustainability and outlines its approach to minimizing its environmental impact.
- Human Resources Policy: a policy that governs employee conduct, benefits, leave, compensation, and other employment-related matters within an organization.
- Compliance Policy: a policy that outlines an organization’s commitment to complying with relevant laws, regulations, standards, and guidelines in its operations and activities.
These are just a few examples of policies that could be represented as symbols in diagrams. The specific content and format of policies may vary depending on the organization’s industry, size, mission, values, and other factors.
Pool
A Pool represents a Participant in the Process. A Participant can be a specific business entity (e.g, a company) or can be a more general business role (e.g., a buyer, seller, or manufacturer).
Graphically, a Pool is a container for partitioning a Process from other Pools, when modeling business-to-business situations, although a Pool need not have any internal details (i.e., it can be a “black box”). ° A Pool is a square-cornered rectangle that MUST be drawn with a solid single black line. One, and only one, Pool in a diagram MAY be presented without a boundary. If there is more than one Pool in the diagram, then the remaining Pools MUST have a boundary.
To help with the clarity of the Diagram, A Pool will extend the entire length of the Diagram, either horizontally or vertically. However, there is no specific restriction to the size and/or positioning of a Pool. Modelers and modeling tools can use Pools (and Lanes) in a flexible manner in the interest of conserving the “real estate” of a Diagram on a screen or a printed page.
A Pool acts as the container for the Sequence Flow between activities. The Sequence Flow can cross the boundaries between Lanes of a Pool, but cannot cross the boundaries of a Pool. The interaction between Pools, e.g., in a B2B context, is shown through Message Flow.
Another aspect of Pools is whether or not there is any activity detailed within the Pool. Thus, a given Pool may be shown as a “White Box,” with all details exposed, or as a “Black Box,” with all details hidden. No Sequence Flow is associated with a “Black Box” Pool, but Message Flow can attach to its boundaries.
For a “White Box” Pool, the activities within are organized by Sequence Flow. Message Flow can cross the Pool boundary to attach to the appropriate activity.
All BPDs contain at least one Pool. In most cases, a BPD that consists of a single Pool will only display the activities of the Process and not display the boundaries of the Pool. Furthermore, a BPD may show the “main” Pool without boundaries. In such cases there can be, at most, only one invisibly-bounded pool in the diagram and the name of that pool SHALL be the same as the diagram. Consequently, the activities that represent the work performed from the point of view of the modeler or the modeler’s organization are considered “internal” activities and need not be surrounded by the boundaries of a Pool, while the other Pools in the Diagram must have their boundary.
In QualiWare, the user can specify if the Pool is of a scope of Private (Internal), Abstract (Public), or Collaborative (Global).
The Participant field identifies the role associated with the Pool, or the process that is being executed within the Pool. Since there can be multiple Pools in one BusinessProcessDiagram in QualiWare, it is sometimes important to define the role that is being fulfilled within the Pool.
The Uses Parameter field in QualiWare, on the Pool tab of the Pool Object Editor, permits the user to specify if there is some specific parameter or value essential to the execution of the process that the Pool contains.
The Included in Service field allows the user to specify if there is a unique service associated with the process that is contained in the Pool.
The Target Namespace field allows the QualiWare user to define the scope of the process that is contained in the Pool.
Preventive Action
Definition of an action with the purpose of avoiding certain incidents
PreventiveAction properties
The PreventiveAction tab
Property | Metamodel name | Description |
Short description | ShortDescription | Short verbal description of the PreventiveAction |
Related Non-Conformance | RelatedNonConformance | Links to NonConformance related to this action Links to: NonConformance. |
Responsible | HasResponsible | Link to responsible for this PreventiveAction Links to: InterestGroup, OrganizationUnit, Person, Position, Resource, Role. |
Goals | HasGoal | Links to: Goal. |
Plan of action | PlanOfAction | Link to ProjectActivity or WorkModelshowing dates and resources for plans to execute this PreventiveAction Links to: ProjectActivity, WorkModel. |
Due date | DueDate | |
Estimated Cost | EstimatedCost | Estimated cost of carrying out this action |
The Action taken tab
Property | Metamodel name | Description |
Start Date | StartDate | Starting date. |
End Date | EndDate | Ending date. |
Action taken by | ActionTakenBy | Relation to person/group who executed the action. Links to: InterestGroup, OrganizationUnit, Person, Position, Role. |
Cost of Non Conformance | CostOfNonConformance | Cost caused by the non conformance |
Resources Spent | ResourcesSpent | Actual cost of corrective action |
Corrective Action Taken | CorrectiveActionTaken | A description of the corrective action taken. |
Closing date | ClosingDate | The closing date for this NonConformance |
Principle : ArchiMate
Principles are strongly related to goals and requirements. Similar to requirements, principles define intended properties of systems. However, in contrast to requirements, principles are broader in scope and more abstract than requirements. A principle defines a general property that applies to any system in a certain context. A requirement defines a property that applies to a specific system as described by an architecture.
A principle needs to be made specific for a given system by means of one or more requirements, in order to enforce that the system conforms to the principle. For example, the principle “Information management processes comply with all relevant laws, policies, and regulations” is realized by the requirements that are imposed by the actual laws, policies, and regulations that apply to the specific system under design.
A principle is motivated by some goal or driver. For example, the aforementioned principle may be motivated by the goal to maintain a good reputation and/or the goal to avoid penalties. The principle provides a means to realize its motivating goal, which is generally formulated as a guideline. This guideline constrains the design of all systems in a given context by stating the general properties that are required from any system in this context to realize the goal. Principles are intended to be more stable than requirements in the sense that they do not change as quickly as requirements may do. Organizational values, best practices, and design knowledge may be reflected and made applicable in terms of principles.
Principle properties
The Principle tab
Property | Metamodel name | Description |
Short description | ShortDescription | |
Implements | Implements | Links to: All templates. |
BreaksDownTo | BreaksDownTo | Links to: All templates. |
Printer
Use the printer symbol to specify a printer. For all other types of devices use the Peripheral template.
Printer properties
The Printer tab
Property | Metamodel name | Description |
Short Description | ShortDescription | A short description of the item |
Type | PrinterType | The type of the printer. |
Show | ShowType | Display the type next to the symbol on diagrams. Initial value is off. |
Hardware | HardwareComponent | Use this field to point to a HardwareComponent, if it is necessary to describe the hardware device that is the printer. Links to: HardwareComponent. |
Serial number | SerialNumber | The serial number of the item. This field can be used if you have an internal serial number for all printers, while the manufacturers serial number is specifed in the HardwareComponent in the Hardware field. |
IP Address | IPAddress | The IP address of the device if the address is fixed |
Logical name/address | LogicalAddress | The logical name or address of the item. |
Show | ShowNetworkName | Display the network name next to the symbol on diagrams. Initial value is off. |
Shared | isShared | Check this box if the printer is connected to a computer but has been made available for other users in the network. Initial value is on. |
Vendor | Vendor | The vendor of the item. The vendor might for instance be an internal organisation unit or an external supplier. Links to: BusinessConnection, ExternalEntity, OrganizationUnit. |
Support | Support | The support provider. Links to: BusinessConnection, Person, ExternalEntity, OrganizationUnit. |
The Economy tab
Property | Metamodel name | Description |
Date of purchase | DateOfPurchase | When the item was purchased |
Warranty expires | WarrantyExpires | When the warranty of the item expires |
Contracts | HasContract | All the different contracts connected to the item. Links to: Contract. |
Problem
A Problem represents a requirement from an interested party for a change in the way the business is running, the project is carried out, the content of a design component in the repository etc.
It is important to note that a problem should concidered a threat to the accomplishment of the business idea, the project or quality of the final product. As opposed to aChangeRequest that represents an opportunity to act.
It should always be clear to an organisation how to handle a Problem. The process of analyzing the scope of the problem, recommending an action and carrying out and action should be controlled by the project management or dedicated people.
Problem properties
The Problem tab
Property | Metamodel name | Description |
Short Description | ShortDescription | Short verbal description. |
Priority | Priority | The priority for this Problem. Choices are: |
Originated Date | OriginatedDate | CreationDate for this Problem. |
Originated By | OriginatedBy | The person who put forward this Problem. Links to: InterestGroup, OrganizationUnit, Person, Position, Role. |
Status | Status | The status of this Problem. Choices are: |
Responsible | HasResponsible | Person responsible for the problem handling Links to: InterestGroup, OrganizationUnit, Person, Position, Role. |
The Recommend tab
Property | Metamodel name | Description |
Recommended Date | RecommendedDate | CreationDate of this recommendation. |
Recommended By | RecommendedBy | The Person/Group responsible for this recommendation. Links to: InterestGroup, OrganizationUnit, Person, Position, Role. |
Estimated Resource Requirement | EstimatedResourceRequirement | Estimated cost to solve the problem. |
Recommended Solution | RecommendSolution | Description of the recommended solution |
The Actual tab
Property | Metamodel name | Description |
Start Date | StartDate | Starting date. |
Executed By | ExecutedBy | The person/group that carries out the solution Links to: InterestGroup, OrganizationUnit, Person, Position, Role. |
End Date | EndDate | Ending date. |
Resources Spent | ResourcesSpend | Resources used |
Corrective Action | CorrectiveAction | Description of the action |
The Breaks Down To tab
Property | Metamodel name | Description |
Breaks Down To | BreaksDownTo | Link to models showing a decomposed picture of this entity Links to: RequirementModel, StrategyModel. |