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:

StateEventDiagram_1

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.

Data Replication Diagram

Purpose: The purpose of the Data Replication Diagram template is to map a high-level view of the movement and replication of information between data sources.

Core concerns: The Data Replication Diagram template enables you to map Data Sources, Data Files, Data Transformations and Data Warehouses. These elements can then be connected by either a Data Extract or a Data Apply.

Graphical representation of the elements:

Below, is an example of a Data Replication Diagram for a commercial Data Warehouse:

DataReplicationDiagram_1

The model shows that the data is extracted from different data sources, transformed and applied to the Data Warehouse from which it is extracted, aggregated and either applied to sales, production or improvement.

Relation to other templates: The Data Replication Diagram offers a high-level data mapping. The Data Transformations contained in the Data Replication Diagram can be further decomposed into more detailed Data Mapping Diagrams.

Properties and metadata: The Data Replication Diagram template ­­­­can for example retain the following information:

  • A description 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 it

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

 

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:

DataModelDiagram_1

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 Mapping Diagram

Purpose: The purpose of the Data Mapping Diagram is to map data’s sources.

Core concerns: The Data Mapping Diagram template enables you to model Data Entities, Classes, Tables, Records and Mapping Algorithms. These are connected by Data Mappings. The Data Mapping Diagram is sometimes called Entity Mapping Diagram.

Below, you can see an example of a Data Mapping Diagram where data is moved from one table to another transforming from ‘customer data’ into ‘client data’:

DataMappingDiagram_1

The following very simple diagram illustrates the relations between Records and their elements:

DataMappingDiagram_2

Relation to other templates: The Data Mapping Diagram is, through the object Data Transformation, related to the Data Replication Diagram. Data Transformation is contained in the Data Replication Diagram and has a mapping which is described in the Data Mapping Diagram.

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

  • A description 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

The above picture shows the properties dialogue window for the Data Mapping Diagram 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:

ConceptualDataModel_2

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.

ConceptualDataModel_1

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:

ConceptModel_1

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:

ConceptModel_2

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

Component Diagram

Purpose: The purpose of the Component Diagram is to specify the structure of and dependencies among the different components that make up a system.

Core concerns: The Component Diagram template enables you to model a system’s Components, Classes, Interfaces, Packages, Artifacts and Ports. They can be connected by Dependency, Interface Realization, Component Realization, Usage, Generalization or a generic Connector. Below, you can see an example of a simple Component Diagram consisting of Components connected by Dependencies.

ComponentDiagram

Using the properties dialogue, you can identify extensions such as Stereotype, Constraints and Tagged values:

Relation to other templates: The Component Diagram is part of the Application domain and shows how a system is structured. To model how users interact with a system you should use a Use Case Diagram, to model how interactions with the system through processes you should use the Sequence Diagram template. To model the structure of an application landscape you should use the Application Architecture Diagram.

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

Class Diagram

Purpose: The primary objective of the Class Diagram template is to visually represent and document the structural components of a system utilizing the Unified Modeling Language (UML). Displayed below is an example of a straightforward Class Diagram:

ClassDiagram_2

Core concerns: The Class Diagram effectively captures the various classes within a system, their attributes, operations, and the relationships between classes and other objects, such as packages. This comprehensive representation enables a clear understanding of the system’s structure, promoting efficient communication among stakeholders and facilitating system design and maintenance.

Example: In the Class Diagram below, the relationships between the classes “Customer” and “Internet User” and the packages “WEB-API”, “Reservation Control”, “GUI” (Graphical User Interface), and “Database” are illustrated. This example highlights the connections among different components and provides a visual overview of how they interact within the system:

ClassDiagram_1

Relation to other templates: The Class Diagram presents a detailed structural view of information. It can for example be a decomposition of an Information System which typically is presented in an Application Architecture Diagram. If a Class Diagram becomes too complex or large, a Package Diagram, where the classes are grouped into Packages, could be modelled instead.

Properties and metadata: The Class 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
  • Audits (auto generated information regarding its current state and access rights)
  • Extensions regarding constraints and tagged values
  • 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

In the picture below you can see the Class Diagrams properties dialogue window, where the information can be viewed and edited: