Home / Creating a Snapshot of your EA Meta-Model / Analyzing your Model / Creating a Snapshot of your EA Meta-Model

Creating a Snapshot of your EA Meta-Model

What is a meta-model?

A meta-model is just an EA diagram which shows which elements types & stereotypes and connectors you use in a part of your model. It’s a useful indication of the complexity of the model, and also of it’s consistency.

If you’re about to start managing the quality of your models, then its a good idea to start by looking at the meta-models of different parts of your model.

Creating a Snapshot meta-model

A snapshot meta-model is the meta-model of a single EA package (and all its sub-packages), taken at a point in time.

Task	Description	See Also
Open MX2 Examples.EAPX
Find the package ‘Example 1’ :	This package has some EA diagrams in it. They are a mixture of UML, BPMN and Archimate model elements, but this is just an example. Have a look at the diagrams to see what kind of modeling we have done.
Right-click on the Example 1 package (the ‘Source model’) and choose Specialize / Model Expert / Create snapshot meta-model
For ‘where to put the results’ choose the ‘Scratch’ package
You will see a diagram of the meta-model, like this:	This shows: all the types and stereotypes in the ‘Source Model’ how those types are related which EA attributes have been used You can get lots of useful insight into your model just by looking at this meta-model.	Top 10 meta-model tips

Note that the meta-model diagram created by Model Expert is a snapshot, so it doesn’t automatically update when you make changes to your model.

Understanding a snapshot meta-model

A snapshot meta-model contains information about the element types, attributes and connectors in a single EA package. It shows:

Item	Description
Element Types One of these is created for each unique element type/stereotype in your package. For example:	Count – number of examples of the type+stereotype in the package Type (and stereotype, if there is one) Standard Attributes. These are the ‘properties’ of elements, provided by EA. This shows which ones are used, and the percentage usage. For example, in this package there were 3 UseCases, and all had a name, but only 33% of them (1 use case) had a non-default value of ‘phase’ Tagged Values This shows which tagged values are present in the elements, and how often they are used Sub-elements This shows how the following are used: Scenarios, Constraints, Element requirements, Element Issues, Element metrics, Element files etc The number indicates the ratio. So, for Element Requirements, there are an average 1.33 Element requirements for each Use Case.
Connectors Each pair of element type+stereotype which are linked (within the package) creates a connector in the snapshot meta-model diagram. For example (attributes not shown in this EA diagram):	This says that: Use Cases are linked to other Use Cases using a <<include>>UseCase type connectors Actors are linked to UseCases using an Association link.

Item

Description

Element Types

One of these is created for each unique element type/stereotype in your package. For example:

Count – number of examples of the type+stereotype in the package
Type (and stereotype, if there is one)
Standard Attributes.
These are the ‘properties’ of elements, provided by EA.
This shows which ones are used, and the percentage usage.
For example, in this package there were 3 UseCases, and all had a name, but only 33% of them (1 use case) had a non-default value of ‘phase’
Tagged Values
This shows which tagged values are present in the elements, and how often they are used
Sub-elements
- This shows how the following are used:
  Scenarios, Constraints, Element requirements, Element Issues, Element metrics, Element files etc
- The number indicates the ratio. So, for Element Requirements, there are an average 1.33 Element requirements for each Use Case.

Connectors

Each pair of element type+stereotype which are linked (within the package) creates a connector in the snapshot meta-model diagram. For example (attributes not shown in this EA diagram):

This says that:

Use Cases are linked to other Use Cases using a <<include>>UseCase type connectors
Actors are linked to UseCases using an Association link.

Table of contents