Templates | QualiWare Center of Excellence

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.

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.

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.

Communication Diagram

Purpose: The purpose of the Communication Diagram template is to document interactions between objects or parts, focusing on sequenced messages.

Core concerns: The Communication Diagram template is a simplified UML 2.0 alternative to the UML Collaboration Diagram. It enables you to model Lifelines and Annotation, which can be connected by messages.

Below you can see a simple example of a Communication Diagram:

Relation to other templates: Usually, Communication Diagrams would be modeled using information from Class Diagram, Sequence Diagram, and Use case diagram. It is related to the other UML interaction diagrams: Sequence Diagram, Interaction overview diagram and Timing Diagram.

While the Communication Diagram show much of the same information a Sequence Diagram does, the Communication Diagram conveys which elements each one interacts with better, while sequence diagrams show the order in which the interactions take place more clearly.

Other UML diagrams that QualiWare support include: Activity Diagram, Communication Diagram, Deployment Diagram, , Composite Structure Diagram, State Diagram, Package Diagram, Component Diagram, Composite structure Diagram, and Object Diagram.

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

A description of the diagrams
Link to related sequence diagram
Extensions (Stereotype, 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 Communication 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.

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:

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:

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:

Business Process Network

Purpose: The purpose of the Business Process Network is to at document a mid- to high-level view of Business Processes and their interrelationships.

Core concerns: The Business Process Network template enables the documentation of top to mid-level processes. The core objects available to model with are Business Processes, Business Events, Business Objects, Business Scope, Information Systems, and different types of connections. Below you can see two examples of a Business Process Network modelled in different styles.

High level process view without business events or connections between processes:

High-level process view where business events and connections indicate a flow between processes, stakeholders and customers:

Relation to other templates: The top-level processes would typically be broken down to one or more levels of mid-level processes. The last level of Business Process Networks can then be broken down to several Workflow Diagrams or Business Process Diagrams detailing the activities contained within the business process

Properties and metadata: The Business Process Network can for example retain the following information:

Description of the diagram
Link to the owner of the diagram
Link to the one responsible for executing the processes in 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

In the picture below you can see the Business Process Network’s properties dialogue window, where the diagrams properties can be viewed and edited:

Business Process Diagram

Purpose: The purpose of the Business Process Diagram template is to enable workflow modelling using the industry standard BPMN (Business Process Modeling Notation).

Core concerns: The Business Process Diagram template supply you with the BPMN icons that enable you to draw a workflow diagram. These icons include different types of events, activities, gateways, connectors, as well as pools, lanes and artifacts such as data objects and messages. The Business Process Diagram is typically used to illustrate business processes and software processes used in requirement documentation. Below is an example of a classic BPMN diagram with swimlanes:

To ensure the right BPMN syntax, the Business Process Diagram template will continuously perform Graphic Syntax Checks while you model. When a graphic syntax error occurs, you will be met with an error message like the one shown below:

Other functionalities: The Business Process Diagram can enable the execution and automation of a process when the diagram is converted into XML type files.

If you don’t wish to have a visible pool in your diagram, you can choose to have a ‘default pool’ that doesn’t have to be graphically represented. You can see an example of a diagram without pool and lanes below:

Relation to other templates: The Business Process Diagram template is exclusively aimed at modeling using the BPMN standard. If the BPMN is not chosen as a mandatory standard, the WorkFlow Diagram template, which has fewer syntax limitations, can be used instead.

The Business Process Diagram is typically linked as a decomposition of a Business Process contained in a Business Process Network template.

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

Description of the diagram
Expression and query language
Link to the owner of the process
Link to the one responsible for executing the process
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

In the picture above you can see the Business Process Diagram’s properties dialogue window, where the diagram’s properties can be viewed and edited:

For more information: about the BPMN standard please visit OMG’s dedicated website.

Business Process Cooperation Viewpoint : Archimate

Purpose: Designing, deciding

Concerns: Dependencies between business processes, consistency and completeness, responsibilities

Scope: Multiple layer/Multiple aspect

The business process cooperation viewpoint is used to show the relationships of one or more business processes with each other and/or with their environment. It can be used both to create a high-level design of business processes within their context and to provide an operational manager responsible for one or more such processes with insight into their dependencies. Important aspects of business process cooperation are:

Causal relationships between the main business processes of the enterprise
Mapping of business processes onto business functions
Realization of services by business processes
Use of shared data

Each of these can be regarded as a “sub-viewpoint” of the business process cooperation viewpoint.

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.

Business Excellence Diagram

Purpose: The purpose of the Business Excellence Diagram template is to describe a measuring tool based on The European Foundation for Quality Management Excellence Model (EFQM).

Core concerns: The Business Excellence Diagram enables you to model Business Scopes, Criterion and Sub Criterion. These aspects can then be connected by Criterion Influencers.

Below, you can see an example of a Business Excellence Diagram for the Leadership of an organization. The diagram is structured according to the EFQM and shows the overall scores for the leaderships performance:

Other areas covered in the EFQM are Policy & Strategy, People, Partnerships & Resources, Processes, Customer Results, People Results, Society Results and Key Performance Indicators.

Relation to other templates: The Business Excellence Diagram is a strategic template that is complimentary to the Business Capability Model, Stakeholder Model, Business Canvas, and Strategy Model

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

For more information: To learn more about the EFQM, please visit their website, where you can also find an overview of the EFQM Excellence Model.

Business Ecosystem

Purpose: The purpose of the Business Ecosystem template is to enable an organization to understand itself from an outside-out perspective by modelling the environment in which the organization is embedded.

Core concerns: The Business Ecosystem supplies five elements to model with: Business, People, Things, Business Interaction and Business Moment. The Business Ecosystem template should primarily be used for modeling entities outside the enterprise to identify new business opportunities in the form of Business Moments.

Above you can see a model of a Business Ecosystem. The blue areas are Business Moments, where the interactions between People, Businesses and Things create business opportunities for your enterprise.

Relation to other templates: The Business Ecosystem model is based on the Enterprise Design theories and is as such in the same family as the Customer journey map.

The Business Ecosystem is a strategic model and can be used to document a strategic possibility or track along with for example Business Capability Models, Strategy Models, and Work Models.

Properties and metadata: The Business Ecosystem can for example retain the following information:

A description of the diagram
Link to the owner of the application architecture
Link to the one responsible for the application architecture
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.

For more information: If you want to learn more about Enterprise Design, we have a four-part webinar by Milan Guenther available for viewing. You can also visit Milan’s website, where you can learn more about the Enterprise Design framework.