Purpose: The purpose the Purpose Board is to establish a shared sense of what we are there for, and why we exist, to connect people’s activities and individual contributions to the greater purpose to be pursued.
Core concerns: An enterprise’s purpose expresses what its people believe in, consider valuable, and are striving for, usually expressed as outcomes/goals the enterprise aspires to achieve.
The Purpose Board is a part of the EDGY language created by the Intersection Group.
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 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:
In the picture below you can see the Relational Diagram’s properties dialogue window, where the properties can be viewed and edited:
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.
Add the default values by right clicking and select “Use from Default”
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.
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:
It is possible to forward engineer from the RelationalDiagram to the physical database. This can be executed from the Tools menu in QLM.
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.
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.
The DataSourceConnection can together with the DataModellingStructure be used to reverse engineering of databases, getting the database structure represented in a RelationalDiagram.