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.

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:

SquenceDiagram_1

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:

SquenceDiagram_2

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:

Report Layout

Purpose: The purpose of the Report Layout is to provide the layout of a report for the system developed in the Dialog Model.

Core concerns: The Report Layout template enables you to model Report Pages and Report Fields which can be related by connections.

Relation to other templates: The Report Layout is a QualiWare system template and is related to the Dialog Model, Dialog Layout, Menu Layout and Help Model.

Properties and metadata: The Report Layout 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 of the Report Layout template

The above picture shows the properties dialogue window for the Report Layout template where you can view and edit its properties in QualiWare Lifecycle Manager.

Object Diagram

Purpose: The purpose of the Object Diagram is to document an instance of a class diagram accounting for objects and attributes at a specific point in time. An object diagram may be considered a special case of a Class Diagram.

Core concerns: The Object Diagram enables you to model Packages, Classes, Interfaces, Data Types, Enumerations, Primitive Types, Instance Specifications and Annotations. These elements can then be connected by Associations, Generalizations, Dependencies, Interface Realizations and Usage.

The Object Diagram template should be used to document specific objects of interest in a predefined scenario. This makes Object Diagrams especially useful for documenting examples or test cases for Class Diagrams.

Below, you can see an example of an Object Diagram for a Car Rental Agreement, where specific requirements for the car must be met:

Relation to other templates: The Object Diagram is part of the UML templates QualiWare supports along with the Activity Diagram, Communication Diagram, Deployment Diagram, Class Diagram, Composite Structure Diagram, State Diagram, Package Diagram, Component Diagram, Sequence Diagram, Use case diagram, Timing Diagram, Composite structure Diagram

Properties and metadata: The Object 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
  • Extensions (Stereotypes, Constraints, Tagged values)
  • 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 Object Diagram template, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: about the UML, please visit the Object Management Group’s Website, where you can find the complete specification. The Object Diagram is described in version 1.4.

Integration View

Purpose: The purpose of the Integration View template is to document the routing of integrations between systems.

Core concerns: The Integration View template enables you to model Information Systems, System Components and External Entities (a source to or a receiver of information from a system), and connect them using Integration Flows.

Below is an example of an Integration View concerning the flow of test data:

Relation to other templates: The Integration View belongs to the Application layer of the architecture and is as such related to the Application Architecture Diagram, the Data Flow Diagram and the Component Diagram.

Properties and metadata: The Integration View template can for example retain the following information:

  • A description of the model
  • 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 Integration View template where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

 

Deployment Diagram

Purpose: The purpose of the Deployment Diagram is to document the configuration of run-time processing nodes and the components they contain.

Core concerns: The Deployment Diagram template is structural UML diagram that enables you to model Packages, Components, Artifacts, Instance Specifications, Properties, Nodes, Devices, Execution Environments, Deployment Specifications, Objects, Classes, Interfaces, and Annotations. They can then be connected through Association, Dependency, Generalization, Deployment or Manifestation.

The Deployment Diagram models how the different hardware component and software components are connected. Below you can see an example of a Deployment Diagram for a booking service:

DeploymentDiagram_1

In the next example, you can see how Packages and Components would be included in a Deployment Diagram:

DeploymentDiagram_2

Relation to other templates: The Deployment Diagram is, as a component model, part of the application domain on the operational level. As such, it offers a complimentary view to those of the Application Architecture Diagram, Class Diagram, Component Diagram, Data Flow Diagram, Data Mapping Diagram, Data Replication Diagram, Sequence Diagram, State Event Diagram, Structure Chart, and Use Case Diagram.

Properties and metadata: The Deployment 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
  • Links to extensions such as Stereotypes and Constraints
  • 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 Deployment Diagram 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 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.

 

 

 

 

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:

DataFlowDiagram_2

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

DataFlowDiagram_1

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

dfd

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.

Composite Structure Diagram

Purpose: The purpose of the Composite Structure Diagram template is to document the internal structure of a class, Class interactions with the environment and behavior of collaborations. The Composite Structure Diagram is part of the UML version 2.5.

Core concerns: The Composite Structure Diagram enables you to model Collaborations, Collaboration Use, Properties, Classes, Interfaces and Ports. These elements can be connected by Connectors, Dependencies, Interface Realizations and Usage.

Below, you can see an example of a Composite Structure Diagram for a car safety inspection:  

The Diagram shows internal structure of the Car-safety inspection class as well as the behavior of collaborations and the different classes’ interactions.

Relation to other templates: The Composite Structure Diagram is part of the UML templates QualiWare supports along with the Activity Diagram, Communication Diagram, Deployment Diagram, Class Diagram, State Diagram, Package Diagram, Component Diagram, Sequence Diagram, Use case diagram and Timing Diagram.

The Composite Structure Diagram can be defined as the components content along with the Component Diagrams, Class Diagrams, Classes, and Interfaces. The Component Object is a representation of a physical part from the system specification.

Properties and metadata: The Composite Structure 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
  • Extensions (Stereotypes, constraints and tagged values)
  • 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 Composite Structure Diagram where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.

For more information: about the UML, please visit the Object Management Group’s Website, where you can find the complete specification.