Information Architects | QualiWare Center of Excellence

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:

Reverse and forward Engineering

The RelationalDiagram can be used to Reverse engineer a database.

Right click on the white canvas to open the dialog for the Diagram.

On the main tab you can add a link to a Data Source (linking a DataSourceConnection).

Once you can have addded a DataSource you can select Catalogue and Schema from the drop-down menu. If the drop-down list is empty, then the DataSourceConnection isn’t working, and you have to test it, see more.

NOTE there need to be a parent SubjectArea for the diagram for this to work, if not you will get this message.

You can link a SubjectArea to a RelationalDiagram from the SubjectArea, see more here.

Physical Detail

Add the default values by right clicking and select “Use from Default”

Reverse Engineer

It is now possible to reverse engineer the Relational Diagram using the Setting from above (DataSourceConnection, Catalog, Schema, and Setting on Physical Detail).

Select Reverse Engineer from the Tools menu i QLM, and select the tables to be included in the Diagram.

After a little while the Diagram is created (reverse engineered)

You can re-arrange the symbols to get a good representation.

The Green dots represent that the Model correspond to the real Database.

You can open the properties of the tables on the diagram.

If you change the properties of the table so that it no longer corresponds to the databasestructure, the dot turns from green to yellow on the diagram.

Table – Physical Detail

On the Physical Detail tab, it is possible to change the target value and options for the details.

Hint: All fields are read-only by default. Move the horizontal cursor to the left and select the Option will enable 4 options:

0 => Read only
1 => Editable as string
2=> By choice e.g. True or False
3=> Object selection filtered by template

Forward Engineering

It is possible to forward engineer from the RelationalDiagram to the physical database. This can be executed from the Tools menu in QLM.

Create DDL

From the RelationalDiagram it is possible to create DDL code that can be used to create or update a database.

DDL conversion parameters are set on the DDL Settings tab. You can right click the box to Use default.

On the Physical Details tab you can similary add the Default settings, and choose the DDL pending action (Update/Create).

When the Create DDL is activated, an ExternalDocument will be created based upon the settings and added to the list of DDL Conversions on the RelationalDiagram.

Conversion

It is possible to convert between the different models.

It is possible to convert a RelationalDiagram from the physical level to a logical DataModelDiagram from the tools menu in QLM.

Video

The DataSourceConnection can together with the DataModellingStructure be used to reverse engineering of databases, getting the database structure represented in a RelationalDiagram.

Reverse engineering of SQL Server database

Workflow Diagram

Purpose: The purpose of the Workflow Diagram template is to document the Business Processes of an enterprise at the activity level.

Concerns: The Workflow Diagram template should be used to document the Activities, Roles, Business Events, Activity Paths and Workflow Conditions of a Business Process. Available in the default modeling syntax are also Business Objects, External Objects, Information Systems, Database, Inventory, Information Flow and Logistical Flow. The syntax can be easily extended to include more objects such as Requirements, Business Rules and Goals. Below you can see an example of a Workflow Diagram with multiple Roles that are modelled vertically:

Relation to other templates: The Workflow Diagram does not support BPMN, if using that notation, you should model in the Business Process Diagram template. The Workflow Diagram can link to other Workflow Diagrams and are typically linked to by Business Process Networks. In the picture below, you can see another example of a Workflow Diagram. Here the Roles are modelled horizontally and you can see the links to and from other diagrams at two Business Events (‘ECR completed’ and ‘Rework’):

Other functionalities: In QLM, you can control which buttons related to risk management are shown below activities. You can choose to hide or show Risks, Controls and Key Controls. Both Controls and Key Controls are a type of Activity. From the Risk related toolbars (available via the “Actions” tab on the right-hand side of the Canvas in QLM) choose the following button to control what button panels appear on the Activity objects:

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

A description of the diagram
Information on cost and duration of the process
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 Workflow Diagram’s properties dialogue window, where the diagram’s properties can be viewed and edited:

Use Case Diagram

Purpose: The purpose of the Use Case Diagram template is to document user interactions in a system context, as well as the context between different cases of user interactions. Below, you can see an example of a Use Case Diagram for the service at a restaurant:

Core concerns: The available objects you have to model use cases include: System Boundary, Actors, Use Cases, and connectors such as Association, Generalization, Include and Extend. Below, you can see an example of a Use Case Diagram for a booking system at a car rental service:

Relation to other diagrams: It is important to break down use cases into other diagrams such as Sequence Diagrams, Communication Diagrams, and Activity Diagrams templates for elaboration.

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

State Machine Diagram

Purpose: The purpose of the State Machine Diagram template is to document the dynamic behavior of a class or an object.

Core concerns: The State Machine Diagram template enables you to model States, Pseudo States, History States, Lines and Annotations. These can be connected by Transitions.

As such, the State Machine Diagram can be used to show the different states of a class or an object and how the class or object responds to various events by changing from one state to another.

Below, you can see an example of a State Machine Diagram for an ATM:

Relation to other templates: The State Machine Diagram can be a decomposition of a State and can also be derived from a Class. The State Machine Diagram template is related to, but cannot replace the State Event Diagram, which is used to document Event States and time dependent behavior of systems.

Properties and metadata: The State Machine 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
Link to a specific State of an object the diagram specializes
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 Machine Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

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:

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.

Sequence Diagram

Purpose: The purpose of the Sequence Diagram template is to document interactions between processes over time. Below you can see a Sequence Diagram for a car rental’s booking system:

Core concerns: Sequence Diagrams are typically used to document object interactions over time in a use case for an Information System. Objects are situated along vertical Lifelines. Horizontal arrows that travel between the lifelines in a set sequence are used to illustrate how message exchanges occur at a specific point in time. The objects available in this model are Lifelines, Combined Fragments, Interaction Use, Gates, Time Constraints and Duration Constraints and Messages. Below, you can see an alternate example of a Sequence Diagram for a car rental’s booking system:

Relation to other templates: Though the customer can be included in this type of diagram, you should use the Customer Journey Map to document and analyze the customers’ interactions with your organization. If you want to map a simpler view of actors’ interactions with a system without details on time constraints, you can use a Use Case Diagram.

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

Requirement Model

Purpose: The purpose of the Requirement Model template is to document goals, objectives and other requirements for the enterprise or a specific project. Below, you can see an example of a Requirement Model showing the Policies and Business Rules of an organization:

Core concerns: With the Requirement Model template, you can for example model Requirements, Goals, Change Requests, Policies, Business Rules, Critical Success Factors and Problems. This enables you to illustrate the interrelationships of requirements, for example showing which goals influence or contribute to each other, as the example below shows:

You can also divide goals up in different areas that may for example be subject to different regulations as below:

Relation to other templates: The Requirement Model offers a more detailed view on Requirements and Goals filtering out elements such as vision and mission compared to the Strategy Model. It can be used to detail how your organization live up to requirements specified in a Regulation Diagram or Requirements indicated in a Stakeholder Model.

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

Decision Model

Purpose: The purpose of the Decision Model template is to document complex decisions by modelling decision trees that illustrates decision gates. Below you can see an example of a Decision Model:

Core concerns: Complex decisions can be documented as decision trees. The model illustrates the Business Decision and its underlying Rule Families. The Rule Families can contain Rule Family Tables, that precisely describe the outcome of a given set of variables. Below you can see an example of a Rule Family Table:

Relation to other templates: Where the Decision Model template illustrates the decision gates, the end to end process is described in either a Work Flow Diagram or a Business Process Diagram.

Properties and metadata: The Decision 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 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 Decision Model’s properties dialogue window, where the information 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:

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.

Conversions

It is possible to convert between the different models.

It is possible to convert a DataModelDiagram from the logical model to a conceptual (ConceptualDataModel) and physical level (RelationalDiagram) from the tools menu in QLM.

From the same menu the model can also be converted to an OntologyDiagram, and the model can be created from an OntologyDiagram read more here:

Integrating Data Consistency in OpenAPI | QualiWare Center of Excellence

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’:

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

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.