Information | QualiWare Center of Excellence

Node

A physical element that exists at run time and represents some computational resource.

Node properties

The Node tab

Property	Metamodel name	Description
Short Description	ShortDescription
Represents	Represents	Links to: ClassDiagram, Interface, ComponentDiagram, Class, Object, Component.
Property	Property	Choices are: Root Leaf Abstract

The Extensions tab

Property	Metamodel name	Description
Stereotype	Stereotype	Links to: Stereotype.
Constraints	HasConstraints	Links to: Constraint.
Tagged values	HasTaggedValues	Links to: TagDefinition.

A DataEntity represent a logical group of information – a category of information.
In the early phases of a system analysis or even a business analysis a DataEntity is used to describe physical objects like ‘Customer’, ‘Order’ or ‘Product’. Or it is used to describe important concepts in the modelled system or its surroundings.

In a later phase a DataEntity will represent a smaller normalized informationgroup.

One of the most important characteristics of a DataEntity is, that it can be uniquely identified using a relation to a Key, and that it has got non-key Attribute describing its information content.

In QualiWare Lifecycle Manager the concept of a DataEntity includes a description of the operations performed on the DataEntity during its lifecycle – i.e. from it is created for the first time in the system, until it is deleted. This is accomplished by letting the user relate a DataEntity to a series of operations – here called Methods. This object oriented approach makes it possible for the designer to separate into small reusable groups related information and functions.

When a DataEntity is created it is good practice to give it a primary key. When this is done and the OK-button on the DataEntity dialog is pressed, the key attributes is automatically transferred to the attribute link list.

Subject Area

Subject Area defines major groupings of data or information concepts.

It can be broken down to a more detailed information modelling diagram(s).

A subject area can be classified:

Relational Diagram

Purpose: The purpose of the Relational Diagram is to document the relationship between different types of information on a physical level. Below, you can see an example of a Relational Diagram showing the relationship an Order in a booking system to related data.

Core concerns: The Relational Diagram is a physical data model and consists of Tables and Physical Foreign Keys. Inside each table, information about Indexes, the related Data Entity, Columns and Physical keys.

Relation to other templates: The Relational Diagram offers a more detailed view on data and its interrelationships than for example the Conceptual Data Model and the Business Object Model. Other physical data models include the Data Mapping Diagram, the Class Diagram, the Data Model Diagram and the Data Replication Diagram.

Properties and metadata: The Relational 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 Relational Diagram’s properties dialogue window, where the properties can be viewed and edited:

Data Model Diagram

Purpose: The Purpose of the Data Model Diagram template is to model the structure of data entities of an Information System and their relationships. Documenting the structure of information is a very important part of the preliminary analysis before implementing any Information System.

Core concerns: The Data Model Diagram template enables the user to document the structure of the information, that an Information System is supposed to store. The template allows you to model using Data Entities, Subject Area, Data Entity View, Model View and inheritance. The Connection types available are: Data Relation, Inheritance Connection, Complex Relation and Generalization. Below you can see an example of a Data Model Diagram describing the information structure related to an order:

Relation to other templates: The Data Model Diagram template should not be used to document data flows. In that case the Data Flow Diagram template should be used.

Properties and metadata: The Data Model 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.

The above picture shows the properties dialogue window for the Data Model Diagram where you can view and edit the diagram’s properties.

Data Flow Diagram

Purpose: The purpose of the Data Flow Diagram is to document a system’s or part of a system’s data flows; the data input the system (or a process within the system) consumes and the data output the system produces.

Core concerns: The Data Flow Diagram enables you to model Processes, Data Stores, External Entities, Control Processes and Control Stores. These elements can then be connected by either Data Flows or Control Flows.

Graphical representation of the elements:

The Data Flow Diagram can show different levels of processes within a system that exchange data, and illustrate how those exchanges occur. As such, the model can document a system’s functional hierarchies.

Below, you can see an example of a Data Flow Diagram showing the Data Flows between several Data Stores, Processes and External Entities in a Bookshop:

The next example shows the Data Flow between process, Data Stores and External Entities for a Highway Repair Service:

The final example shows the Data Flows between Processes, Datastores and External Entities in an Outlook Mailbox:

Relation to other templates: The Processes in the Data Flow Diagram can be decomposed into more detailed Data Flow Diagrams to comprise the total functional model. The top level of a Data Flow Diagram is sometimes called a Context Diagram. However, in QLM we use the Data Flow Diagram template for the higher levels as well as the more detailed ones.

The Data Flow Diagram can be a decomposition of an Information System. It can offer a more detailed view of Data Flows than, for example, the Application Architecture Diagram.

An Information System could likewise be decomposed into a Business Process Diagram which offers a complimentary view less concerned with Data Stores and Data Flow, and more concerned with Activity Flow.

Properties and metadata: The Data Flow 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 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 Data Flow Diagram template, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Conceptual Data Model

Purpose: The Conceptual Data Model template is used to describe a high-level business oriented structure of the information concept used in a specific business area. Below yo can se an example of a Conceptual Data Model where the data is divided into data for internal and external use:

Core concerns: The conceptual data model template enables you to model a preliminary high level data model. It may be abstract in content and sparse in attributes. Its preliminary structure allows for many-to-many relationships. When using the Conceptual Data Model, you can model Information Concepts, Subject Areas, and their interrelationships. Below, you can see a car rental service’s Conceptual Data Model for a customer’s data.

Relation to other templates: The conceptual data model is a means of communicating information structures between participants in a project or documenting the overall Information Concept of a specific organization. For a more detailed model you should use a Data Model Diagram.

Properties and metadata: The Conceptual Data Model can for example retain the following metadata:

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 Conceptual Data Model’s properties dialogue window, where the information can be viewed and edited:

Concept Model

Purpose: The purpose of a Concept Model is to organize an enterprise’s vocabulary to support cPonsistent and unambiguous communication about specific problem domains across business units.

Core concerns: The Concept Model template enables you to model Concepts, Specialization Aspects and Subject Areas. They can be linked by Concept Associations, Concept Aggregations, Concept Generalizations, Type Relationships, and Relationship Constraints.

You are also able to link the diagram to its area of usage through the model’s property dialogue. This area of usage can by default be set to be either an Organization Unit, Role, Actor or External Entity.

Below you can see some examples of Concept Models from a healthcare domain:

The model above shows the concepts related to the healthcare activity ‘knee arthroplasty’. The model below shows the concepts related to a signature in the healthcare domain:

The model above shows the concepts related to the healthcare activity ‘knee arthroplasty’.

The model below shows the concepts related to a signature in the healthcare domain:

Relation to other templates: A Concept Model should enable the identification of the right terms to use in communications where high precision is needed. This is useful when creating large sets of business rules or processes that need to fit together without ambiguity and when creating complex Data Models. As such, it could be advantageous to link to a concept model from the affected Business Process Networks, Workflow Diagrams, Requirements Models and Regulation Diagrams.

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

A description of the diagram
Link to the owner of the model
Link to the one responsible for the model
Link to view of area of usage
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 Concept Model, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: to learn more about Concept Models, you can read the following article:

Ronald G. Ross , “What Is a Concept Model?” Business Rules Journal Vol. 15, No. 10, (Oct. 2014). URL: http://www.brcommunity.com/a2014/b779.html

Business Object Model

Purpose: The purpose of the Business Object Model is to present a structured view of an organization’s products and services.

Core concerns: The focus of this template is the Business Object that can be described through Decomposition, Generalization, Association and Dependency with other Business Objects. Notes can be used to group Business Objects, for example as High-Growth Revenue Products, as seen in the below model:

The modelling syntax can be extended to also include strategic elements such as: Requirements, Problems, Change Requests, Goals, Performance Indicators and policies. They can be connected to the Business Objects through Strategic Alignment.

Relation to other templates: The Business Object Model belongs to the Information domain where it offers a conceptual and logical view of an organizations products and services. As such, it is related to templates such as Product Canvas, Product Roadmap and Product Variant Master

Properties and metadata: The Business Object 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 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 Business Object Model, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

Information Structure Viewpoint : Archimate

Concerns: Structure and dependencies of the used data and information, consistency and completeness
Purpose: Designing
Scope: Multiple layer/Single aspect

The information structure viewpoint is comparable to the traditional information models created in the development of almost any information system. It shows the structure of the information used in the enterprise or in a specific business process or application, in terms of data types or (object-oriented) class structures. Furthermore, it may show how the information at the business level is represented at the application level in the form of the data structures used there, and how these are then mapped onto the underlying technology infrastructure; e.g., by means of a database schema.