Purpose: The purpose the Service Blueprint is to make a blueprint of the enterprise by collecting the most relevant elements.
Core concerns: The Blueprint enables you to collect objects of the different facets in the EDGY language in one diagram.

Purpose: The purpose the Service Blueprint is to make a blueprint of the enterprise by collecting the most relevant elements.
Core concerns: The Blueprint enables you to collect objects of the different facets in the EDGY language in one diagram.

Purpose: The purpose the Story Board is illustrate identity and purpose, while verbalizing your mission statement as a story.
Core concerns: An enterprise story is a narrative with our co-creators as protagonists, the enterprise as the setting, the ecosystem as context, and the co-creators’ activities as actions.

The Story Board is a part of the EDGY language created by the Intersection Group.
Purpose: The purpose the Object Map (previously known as “Structure Board”) is to use a single and consistent vocabulary, while consistently using the same entities and relations when designing software solutions (data models, user interfaces)
Core concerns: An object is a tangible or intangible multi-part structure such as a machine, building, application or data. Objects can have behaviour, such as performing automated activities, or support people that are doing activities. Objects consist of parts: objects that combine to form an object of a higher complexity and function.

The Object Map (previously known as Structure Board) is a part of the EDGY language created by the Intersection Group.
More information about EDGY:
Purpose: The purpose the Task Board is when deciding which products to create and market, tasks clarify what these products are for. It can also gain insight and a sense of priority about what matters to customers or other important people.
Core concerns: People have numerous tasks they want to accomplish every day: getting up in the morning, working together with a colleague, visiting a friend or relaxing in the evening. Those tasks are about the outcomes people want to achieve, not the means to get there. Tasks can be seen as a stable expression of people’s needs, motivations and intent.

The Task Board is a part of the EDGY language created by the Intersection Group.
Purpose: The purpose of the Activity Board diagram is modelling what is being done or going on in our enterprise or its ecosystem.
Core concerns: Activities represent something happening that is relevant to our enterprise. This can be something people do, individually and/or collectively (work, entertainment, other ways to spend their time). It can also refer to something happening or going on, events unfolding within our enterprise or outside its boundaries within our ecosystem. They capture the behavior and dynamics of our enterprise over time and enable us to model and map what we do to go about our business and organize ourselves to do so.

The Activity Board is a part of the EDGY language created by the Intersection Group.
The Decision Requirement Diagram shows how a set of decisions depend on each other, on input data, and on business knowledge models.

The Decision Requirement Diagram is a part of the Decision Model Notation (DMN) from OMG.
“The primary goal of DMN is to provide a common notation that is readily understandable by all business users, from the business analysts needing to create initial decision requirements and then more detailed decision models, to the technical developers responsible for automating the decisions in processes”.
Purpose: The purpose of the Package Diagram is to group elements of a large system and illustrate the dependencies between them.
Core concerns: The Package Diagram can be used to organize a system’s parts and enables you to model Packages, Profiles and Annotations. These can be connected using Dependency, Profile Application, Package Merge, Package Import and Containment.
Below, you can see an example of a Package Diagram for a booking system for a car rental service:

Relation to other templates: The Package diagram offers a simplified view of for example a Class Diagram, grouping classes into packages. It should be used when a class diagram becomes too large and complex to easily read.
Properties and metadata: The Package Diagram template can for example retain the following information:

The above picture shows the properties dialogue window for the Package Diagram template, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.
Purpose: The purpose of the Production Site template is to provide a model over the content and flow of a production site.
Core Concerns: The Production Site template enables you to model Production Lines, Work Centers, Equipment, Inventory and Fixed Installations. These elements can then be connected by Logistical Flows, Wires or Transport Systems. Below, you can see an example of a ‘Job Shop’ Production Site:

The Production Site can in its property window have its production process environment classified as being either a:
Relation to other templates: The Production Site template offers an additional perspective to the Product Architecture, Product Canvas, and Product Roadmap templates. Together, these templates illustrate the different aspects of the production process.
Properties and metadata: The Production Site Diagram can for example retain the following information:

The above picture shows the properties dialogue window for the Production Site where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.
Purpose: The purpose of the Structure Chart is to show the physical design of a program. A subroutine or a module.
Core concerns: The Structure Chart template enables you to model Modules and Data Stores. These elements can then be linked by Module Parameters and Connections. The Structure Chart is built as a hierarchy of modules calling each other. The connections are Parameters that are transferred through these calls.
Below, you can see an example of a Structure Chart, where the data flows are illustrated by arrows:

Relation to other templates: The Structure Chart is part of the information domain. As such it is related to, for example, the Data Flow Diagram, Communication Diagram, Data Mapping Diagram, Data Model Diagram, and the Relational Diagram.
Properties and metadata: The Structure Chart template can for example retain the following information:

The above picture shows the properties dialogue window for the Structure Chart template, where you can view and edit the Chart’s properties in QualiWare Lifecycle Manager.
Purpose: The purpose of the Timing Diagram is to show the change in state or the condition of a lifeline over time.
Core concerns: The Timing Diagram template enables you to model Lifelines, Duration Constraints, Time Constraints, Tick Marks and Annotations. These elements can be connected by Messages or Lifeline Changes.
The most common usage of a Timing Diagram is to show the change in state of an object over time in response to accepted events or stimuli.
Below, you can see an example of a simple Timing Diagram for the user of a ATM:

Relation to other templates: The Timing 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, and Composite structure Diagram.
Properties and metadata: The Timing Diagram template can for example retain the following information:

The above picture shows the properties dialogue window for the Timing Diagram template, where you can view and edit the diagram’s properties in QualiWare Lifecycle Manager.
For more information: To learn more about the UML, please visit the Object Management Group’s Website, where you can find the complete specification.