Displaying items by tag: model validation


Modelling enterprises and their architectures is important for most organisations. For example for defining business processes, organisational structures, data and information modelling. But also for modelling the goals and drivers of the organisation, the alignment of business and IT need to be modelled due to the complexity of organisations in modern societies. In medium and large scale organisations the role of enterprise- or information architect is introduced to create these models of the enterprise.

What do we need for modelling enterprise architectures? An important aspect is to introduce a coherent modelling language that enables the enterprise architect to model all the relevant aspects of the organisation. This can be done by using a combination of modelling languages like UML, BPMN and DMN. Another approach is to create your own modelling language based on the MDG module in Enterprise Architect. Fortunately there is a specific enterprise architecture modelling language ArchiMate that you can use.

In this whitepaper we will introduce ArchiMate as modelling language for enterprises, its advantages and disadvantages and the possibility to apply the language in the context of a specific organisation. ArchiMate is in basic available as MDG within Enterprise Architect. But when you want to apply the language effectively, especially within large organisations, you need to modify and extend the configuration in Enterprise Architect. This is done by effectively configuring a number of default functionalities and by introducing Add-ons with specific functionalities relevant for ArchiMate. Last but not least it is important to define working processes for architects and procedures within teams to successfully apply ArchiMate as an enterprise modelling language.


We start with the description of ArchiMate as stated in Wikipedia:

ArchiMate (originally from Architecture-Animate) is an open and independent enterprise architecture modelling language to support the description, analysis and visualization of architecture within and across business domains in an unambiguous way.

ArchiMate is a technical standard from The Open Group and is based on the concepts of the IEEE 1471 standard. It is supported by various tool vendors and consulting firms. ArchiMate is also a registered trademark of The Open Group. The Open Group has a certification program for ArchiMate users, software tools and courses.

ArchiMate distinguishes itself from other languages such as Unified Modelling Language (UML) and Business Process Modelling and Notation (BPMN) by its enterprise modelling scope.

Source Wikipedia

ArchiMate is available as an open standard and is maintained by The Open Group. Since it is open all the information about the language is available from the The Open Group website via https://pubs.opengroup.org/architecture/archimate31-doc/chap03.html#_Toc489945967. Therefore we will limit the description of the language here by a short description of the most important aspects.


ArchiMate is based on a framework with layers and aspects. This framework is a matrix of the layers and aspects. There is a core framework for modelling the basic aspects of an enterprise from business layer via application layer to technology layer. The full framework is adding some extra dimension like strategy, motivation and project dimensions. In the figure below the full framework.


Source: The Open Group

The framework reduces the complexity of modelling since certain characteristics are modelled with a cell (a combination of a layer and an aspect). Within each cell a limited set of concepts and relationships is available for the modeller.


As you see in the figure there are a 5+1 layers in the framework. Each layer can be used to create a model with a limited scope. Interesting is that the layers can be seen as tiers. Between these tiers there are a limited number of defined connections possible. The layers are modelled in a horizontal manner.


The aspects are the vertical structuring of the enterprise. There are 3+1 aspects. The main aspects are active structure (who), behaviour (what) and passive structure or informational (about).  Also between the aspects a limited number of relationships are available to create connections between these aspects. Furthermore as within the layers the aspects can be seen as tiers where you preferably only connect an aspect only with the elements in the aspects direct aside it.


Within the cells of the framework specific elements are introduced. Elements are drawn with qualified stereotypes. Each element has a symbol in the right top corner of the element. Elements can be seen as metamodel elements with a definition described in detail in the language. This is used as a classification for the relevant enterprise dimensions. Creating these elements introduces classified libraries of elements all with the same definition.


Relationships are used to connect the different elements within a layer, aspect or cell. Relationships are drawn with stereotyped lines and connect two elements. More important it creates connections between elements that are positions in different cells, layers and aspects. Also the relationships have a well described definition in the language. Due to this a relationship can be used only in a limited set of combinations of elements.

In the image below the most important elements and relationships of the core framework are displayed.



One of the drawbacks of ArchiMate is that the language can be extensive and complex. Since we want to be able to model all the characteristics of an enterprise we have numerous layers, aspects and especially elements and relationships. Since we want to use the models to inform our stakeholders with  specific views on the organisation in ArchiMate viewpoints are introduced. Viewpoints are creating a template for a view or diagram that is based on a subset of the available elements and relationships. This makes it possible to create relative easy to understand views that are used to “tell” a specific part or goal of the organisation.

In ArchiMate there is a set of generic viewpoints defined that can be used as templates for your own diagrams. Also these viewpoints are well described in the language specification. However the language can be extended with viewpoints. This means that you can create your own viewpoints for specific organisational situations or stakeholders. This is an approach applied by many organisations. Please be aware that when doing so an organisation should describe the applied viewpoints in a structured manner.

In the image below an example from the Enterprise Architect Model Wizard is given. This is one of the defined viewpoints in the ArchiMate language.


ArchiMate challenges

Although ArchiMate is probably the best solution for enterprise architecture modelling there are numerous challenges when introducing the language in a (large) architecture team. Finding solutions to prevent for failures when introducing a modelling approach is essential. Below you find a short list of possible solutions to prevent for pitfalls:

  • Introduce relevant viewpoints for the context of your organisation. Every organisation is operating in a specific context. This means that not all elements and relationships are relevant for the organisations. Therefore a selection of the relevant elements and relationships is made. This selection is implemented in various viewpoints. Sometimes you can use the standard viewpoints available in the language. More often an organisation will create its own viewpoints to support modelling the specific organisational context.
  • Create modelling conventions. Not only viewpoints are relevant, it has to be combined with modelling conventions. Things like naming conventions, colour usage, status of elements, diagrams and relationships. Furthermore conventions on baseline and target architectures are relevant in modelling conventions
  • Prevent the emergence of ArchiMate dialects. When you have a large team of architects that are working on different locations in your organisation the risk of ArchiMate dialects is present. This means that every architect creates his or her own modelling approach, creates own viewpoints or even uses elements and relationship not relevant for the context of your organization.
  • Usage of patterns and building blocks, reusable models or parts of models is a great way to introduce standardisation of models. Furthermore creating architectural models will speed up enormously by introducing patterns and building blocks. As with viewpoints patterns and building blocks are available from suppliers or sectoral organisations, but creating specific patterns is also often applied.
  • Develop a modelling community, when you involve your architecture team in the development of your (ArchiMate) modelling language in your organisation. Creating ArchiMate models is difficult so discussing the best approach in stead on make decisions on your own will in the end improve the quality of the models in your team. Create modelling meetings with your team where you discuss problems and solutions. Another option is to introduce “pair modelling”.
  • Train your architects, in many organisations the architecture team is a combination of internal and hired (external) architects. Although most hired architects have experience in using ArchiMate they are not familiar with the specific modelling conventions and viewpoints in your organisation. Take the effort in the training of these architects when they start working in your team. This can be done by face to face training but also instruction videos are very effective (and less time consuming in the end)
  • Introduce a validation process. When an architect delivers his or her ArchiMate models a check for the correctness of these models is necessary. Not only a check on the ArchiMate rules in general but especially on the specific rules within your own organisation architecture.

The above described solutions are mainly focused on organizing the modelling process. However the supporting modelling tool is also important. It has to support the modelling process in an effective and efficient manner and reduce the workload of the modelling architects. Enterprise Architect out of the box (without configuration and Add-ons) is a tool less supportive for your architectural team. Therefore take time to configure the modelling tool. It has sufficient possibilities to do so.   In the next chapters we will describe the available functionalities in Enterprise Architect and two Add-ons.


Functionalities in EA

Enterprise Architect (EA) offers extensive functionalities for creating ArchiMate models. In every new version of the tool we see new functionalities, extra validations in the ArchiMate MDG. Creating a configuration effective for architectural teams using ArchiMate is relatively easy. This chapter describes a number of available techniques for effectively configuring Enterprise Architect.

Model wizard

Enterprise Architect supports a large number of modelling languages, ranging from generic like UML to very specific like Autosar. For creating enterprise architecture in most situations the ArchiMate modelling language is sufficient (or even oversized). Since version 15 perspectives are available. This makes it possible to limit the available languages to a certain field of interest. For modelling enterprise architectures there are four languages available in the perspectives in EA. ArchiMate is the most detailed one and the one with the most functionalities.

When selecting the ArchiMate perspective the Model Wizard  gets activated. This offers you a list with a description and examples of ArchiMate models based on the standard viewpoints in the language. I think this is a great starting point for novices in ArchiMate but also as starting point for ArchiMate modelling teams when they want to evaluate viewpoints or develop organisation  specific viewpoints.

In the image below you see an example of the model wizard with an ArchiMate viewpoint


ArchiMate Diagrams

Experienced ArchiMate modellers will need a more direct approach in creating diagrams than the Model Wizard and the generation of example models. They create diagrams directly from the browser or the wizard.

Apart from the default diagram types for the layers and the most important extensions In de diagram dialog there is an interesting (rather hidden) feature present. Actually the list of diagram types is a tree view and when expanding this tree you can see the generic ArchiMate viewpoints.

Unfortunately the toolbox for the diagram is not modified on the selected viewpoint. Another nice feature would be to create your own model wizard pages for the organisation specific viewpoints or modifying the Diagram tree and configure your organisation specific set of viewpoints. Maybe in a future version of EA


Perspective Sets

An interesting new feature in EA is the possibility to create Personal or Model Based perspective sets. This feature let you limit the modelling languages available for the user or the model. From the perspective of organisation specific viewpoints and modelling conventions an even more interesting feature is the possibility to restrict the available elements and relationships in a modelling language.

In the figure below you can see how easy it is to restrict ArchiMate elements and relationships. This will restrict the various ArchiMate toolboxes for the diagrams. Particularly relevant when your organisation uses a subset of ArchiMate concepts to prevent the evolution of ArchiMate dialects.

When you develop perspective sets you can combine this with the authorisation module in EA. You can assign a perspective set to  an authorisation group to limit the modelling possibilities in languages and when defined in the ArchiMate language. Users in the authorisation group can now only use the defined subset.

ArchiMate Add-ons

On top of the default functionalities of EA there are two Add-ons offering extra functionalities for ArchiMate based architecture teams. In the chapters below we will briefly discuss the functionalities in these Add-ons.

Model Expert

Model Expert is an EA Add-on developed by Ability Engineering in the United Kingdom. Model Expert offers multiple functionalities mainly focussed on model validation and model quality. In this chapter we describe the most relevant functionalities for the ArchiMate perspective modelling team.

Package dashboard

A nice feature in Model Expert is the option to create a package dashboard. This dashboard calculates the complexity of the diagrams and elements within that packages and gives the modellers an idea about the quality of the package content.

Below you see an example of the dashboard


Reference model

The basis of Model Expert is that you create a reference model or meta model of (parts of) your model. This means that you can define a package in your repository in which you place a number of sample diagrams that are modelled based on correct usage of your modelling conventions.

For ArchiMate the approach with viewpoints makes creating a Model Expert reference model is relatively easy. When you have created example diagrams of your viewpoints, and often this is already present, these can be the source for the metamodel created by Model Expert

This metamodel can later be used to validate new diagrams, models and package content. So when a modeller has created diagrams that do not apply to the metamodel of the viewpoints he or she is able to validate the models and gets information about which rules are not or wrong applied in the diagram.

In Model Expert you can create a metamodel on full package content but also on diagram level. From ArchiMate perspective this is relevant. When you create a organisation specific model with a subset of elements and relationships from ArchiMate the package level metamodel will be used. However when you have multiple viewpoints with a subset of ArchiMate concepts a metamodel of the specific diagrams is the correct approach. Luckily you can combine the both approaches in your repository and validate on both metamodels.

When you have generated an ArchiMate Metamodel in Model Expert you have the possibility to finetune your convention rules by adding extra rules or modify the generated rules.

In the figure below you see an example of the reference model maintenance screen


Diagram validation

When you have created a meta - or reference model in Model Expert you can check your diagrams and validate them against the reference model. Nice feature is that a new diagram will be generated in which the validated  diagram is combined with the relevant warnings and errors.

This approach makes it possible to validate the ArchiMate diagrams by the individual architect to do a check on his or her diagrams before the approval is done. When there is a validation process in place with the architectural team a model manager can do this validation before the model is approved.

In the figure below you see an example of a diagram with validation messages. You can see that the diagram is a combination of the original elements, the warning and error messages and an overview and score of the severity of the errors.


Managed packages and diagram

Checking the validity of a diagram is an relevant feature when the diagram is already created. Would it not be interesting to prevent a modeller from making mistakes when creating the ArchiMate model in a diagram. This approach is especially relevant when you have an architecture team working on different locations or when you have architects that are only temporarily part of your modelling team.

With managed packages and diagrams the options of diagram types but also on elements and relationships is validated during the creation of the diagram content.

In the figure below you see the Model Expert dialog when a modeller selects an element that is not in the reference model of the managed diagram or package. In the example an element is added to the diagram that is not present in the reference model. The modeller gets a warning and the option to select one of the stereotypes available in the reference model.


MDG generator

The most advanced feature is combining the model validation with a MDG based on the metamodel of the viewpoints. This means that you can create diagrams based on the generated MDG. This diagram has a toolbox with only the elements and relationships relevant in the viewpoint. This means that the modeller knows what elements are present and is unable to select an element from the toolbox that is unavailable in the viewpoint.

When he or she accidentally drags an element from the repository to the diagram not relevant in this viewpoint he or she will get a warning. See the figure below with a viewpoint based limited toolbox and a warning when selecting a irrelevant element


IDEA is an Open Source Add-on developed by EAxpertise. It is mainly focussed on supporting data modelling teams but since conceptual data modelling is often done with ArchiMate there are also relevant functionalities for ArchiMate modellers


In EA there is a clear separation of reusing existing elements in the repository and creating new elements. For existing elements a modeller uses the browser or the search windows and then drags the elements to the diagram he or she is creating. For creating elements the usage of the toolbox is the general approach.

Disadvantage of this separation of functionalities is, especially in large teams or large models the change of introducing duplicates is large. It will be more easy to introduce duplicates when the modelling and naming conventions are not fully in place in a modelling team.

In this situation the ArchiMAID screen can be helpful. It is actually a combination of search window and creating new elements in one wizard. The first step is to select one or more ArchiMate stereotypes and search for a keyword within the repository filtered on the selected stereotypes. When found you can add the elements to the diagram as a link. When not found you can go to an entry screen and then add the element to the repository and the active diagram.

In the figure below you see the three pages in the ArchiMAID wizard



In large modelling teams, and not only ArchiMate based teams, it is unavoidable that duplicate elements will exist in a repository. Therefore in the IDEA Add-on various deduplicate routines are available. The first one is a warning when a modeller creates a new element in the repository with the same name, stereotype and version.

The second one is a deduplicator screen that searches for duplicates in a repository from the scope of a package. This means that for all the elements in a package and its sub packages a check is done for duplicates in the repository. These duplicates are displayed in a grid view. When the modeller wants to deduplicate he or she can set various parameters for this functionality and merges the duplicate elements and connectors.

Below you see an image of the two screens within the package deduplicator


The deduplicator will merge all the elements to the elements present in the selected package. You can save the deduplicated elements in a duplicates package as a backup of these elements


In this whitepaper we introduced an approach to use ArchiMate for Enterprise Architecture modelling in large teams. The usage of viewpoints makes it possible to reduce complexity in modelling. Generic functions in EA and specific more advanced functionalities in Add-ons makes it possible to support an architecture modelling team in creating validated and quality models of the enterprise.

Configuring enterprise architect and the Add-ons for organisation specific viewpoints can be complex and requires knowledge on both the ArchiMate modelling techniques and configuring the functionalities and add-ons.

EAxpertise has created multiple example repositories for specific ArchiMate viewpoints. In these repositories the functionalities and add-ons are configured in an extensive manner. When you want to introduce this approach in your organisation please contact us. We can help you making a jump start with the introduction of ArchiMate viewpoints and a repository configured in an effective manner to support your ArchiMate modelling team.







Published in White Papers
Thursday, 24 September 2015 09:56

Validating ArchiMate models


When to consider the use of ArchiMate?

The Open Group recently released the ArchiMate 2.1 specification; I think that there are five principle reasons to consider using the notation to describe the architecture of your enterprise. By design, ArchiMate is focused toward:

  • Providing a high-level of abstraction
  • Facilitating the construction of a layered enterprise architecture
  • Illustrating how business concepts are supported by IT systems, comprising both hardware and software
  • Tracing stakeholder concerns through to their realization by the enterprise architecture
  • Showing the possible, and actual, evolution of an enterprise architecture through a number of recognizable intermediate states.

How does ArchiMate handle these things?

Approaching abstraction

In a similar way to modeling notations such as the UML and SysML, ArchiMate relies on a simple but powerful approach to creating a useful abstraction of a complex domain:

  • Identify the specific types of things that are pertinent
  • Identify the relationships between the types of things
  • Provide a graphical notation to illustrate the above

Types of concept

ArchiMate divides the specific types of things to be modeled into three core layers:

  • Business concepts (including actor, role, function, process, service and interface)

ArchiMate: Business Layer

Figure 1: A subset of the business layer concepts

  • Application concepts (including component, function, service and interface)

ArchiMate: Application Layer

Figure 2: A subset of application layer concepts

  • Technology concepts (including device, system software, function and interface)

ArchiMate: Technology Layer

Figure 3: A subset of the technology layer concepts

ArchiMate supplements the core types of things with two extensions for:

  • Motivation (including driver, goal, requirement, principle and constraint)
  • Implementation and migration (work package, deliverable, plateau and gap)

Relationships between concepts

ArchiMate specifies ten types of relationship that may be used between elements:

  • Composition
  • Aggregation
  • Assignment
  • Specialization
  • Realization
  • Used by
  • Access
  • Association
  • Triggering
  • Flow

Direct relationships

ArchiMate specifies the set of valid relationships that may exist between concepts. Relationships are restricted for both concepts belonging within a single core layer or extension, and also across layers. The detailed specification of all valid relationships between types is tabulated in Appendix B: Relationship Tables of the ArchiMate 2.1 specification (ISBN 978-94-018-0003-7).

ArchiMate - Direct Relationships

Figure 4: A syntactically (but not necessarily semantically) correct example showing all the available ArchiMate relationships


Derived relationships

ArchiMate also specifies rules for abstracting over a chain of relationships between three or more concepts:

Transitively applying this property allows us to replace a “chain” of structural relationships (with intermediate model elements) by the weakest structural relationship in the chain. – p. 94, ArchiMate 2.1 specification

ArchiMate - Derived Relationships

Figure 5: A chain of relationships, along with the derived relationship

How using an ArchiMate modeling tool can help

In theory, it is not necessary to use a dedicated modeling tool in order to draw ArchiMate diagrams. You could create a custom stencil with Microsoft Visio (for example) containing all the basic shapes of the elements and relationships. However, a good modeling tool can be used to positively enhance both:

  • Productivity in creating models
  • The correctness of the models

Both enhancements depend on automated model validation, at either the syntactic or semantic level.

Checking for errors in direct relationships [enhance correctness]

Ideally, your modeling tool should not allow you to draw an invalid relationship between two concepts in the first place. This can be prevented a priori whilst creating the initial drawing, by greying out or eliding the options to create invalid relationships. Alternatively (or additionally), the modeling tool can validate the relationships between elements within each diagram, highlighting where invalid relationships have been made, and suggesting valid alternatives.

Automatically deriving relationships between elements [enhance productivity]

Due to ArchiMate’s rules for abstracting over a chain of relationships, your modeling tool should be able to insert a correctly derived relationship between any two elements in a diagram, or at least inform you that no relationship can be derived at all.

Automating ArchiMate viewpoints

ArchiMate specifies twenty-six viewpoints that may be constructed using different combinations of element types and relationships. Ideally, your tool should be able to:

  • Validate any viewpoint(s) that you have already created. [enhance correctness]
  • Provide automated assistance with creating new diagrams through re-using existing model elements and their relationships. [enhance productivity]

How to do it? Let us help you!

The existing functionality of Sparx Enterprise Architect provides a good basis for fully automating the validation of ArchiMate models. Please contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. if you would like to discuss how you can gain access to our solution.

Published in Tutorials

Following on from my previous post on creating and simulating state machines in Enterprise Architect (EA), I will walk through the process of adding a UI to prototype and further interactivity to your model.

If you recall the previous article, I walked through the process of setting up ‘Triggers’ to run scenarios through your state machine and set simulation variables at state or sub-state level to better represent your application. All of this information was available using the EA ‘variables’ or recording to the Console. We can go a step further and prototype a quick UI to represent our application and/or provide a ‘dashboard’ view of states and variables.


Setting up the state machine

the state machine from the previous post

Using the state machine I used last time, we need to create a place-holder ‘state machine’ element so we can reference it as a simulation start point.

Add a ‘User  Interface’ diagram to the appropriate place in the package browser.


add a user interface to the diagram


This will be our place-holder to put the state machine and User Interface elements.

On the diagram create a new state machine element.

create a new state machine element

Then right-click the newly created element and select your existing state machine diagram we created in the previous example.

select a composite state diagram

Locate the state machine diagram in the package browser.

Locate the state machine in the package browser

Now we can create a new User Interface diagram and add that as a frame on to the current diagram (keeps it neater and modular).

add another UI element on drag into onto the master canvas

And drag that on to the Model Default (or whatever you named the original) diagram canvas.

To complete the process of linking a UI to a simulation, we want to open the Execution Analyser and create a script. If you don’t have the window open, select ‘Analyzer’ - ‘Execution Analyzer’ to bring it back up

Show the Execution Analyzer


From the Execution Analyzer window, select to add a new script

Add a new simulation script to the Execution Analyzer

And they key step for us is the last tab, ‘Simulation’ and defining the ‘Entry Point’ and Input behaviour.

Select the ‘..’ icon to locate your state machine element for the Entry Point.

Define a state machine to be the simulation entry point

That sets the entry diagram we want to use for the simulation.

To connect the User Interface to the simulation, we need to define a behaviour (in JavaScript notation) to display the correct UI element.

The format of this command is as follows:

dialog.CreateOrder.Show = True;

where ‘CreateOrder’ is the name of User Interface we created earlier (‘CreateOrder’ in my example above).

As you may have guessed from the above JavaScript, the model simulation script will start the simulation on the ‘Validate Example’ state machine and as it’s first point of business, it will display the ‘CreateOrder’ User Interface we created.

Note: Another method of displaying the UI is to assign the same command (above) to the first transition of the state diagram (e.g. Initial –> Created in my example). Whichever method works for you!


Creating the UI and assigning actions to things!

So now we have a model simulation that will give us an actual rendered screen we should probably put something on it!

Open up the CreateOrder User Interface  we created earlier and lets start adding elements.

Using the Toolbox you can add standard UI elements or use the Win32 elements to add things onto your prototype. Here is a horridly rushed example of some text and a button (note the list of Win32 UI control types in the toolbox)

building a basic user interface

So now I’ve added a UI to the model and hooked it up using a simulation script, what happens if I run it? Well let see.

Going to back to the ‘Execution Analyzer’, right click the script and select ‘Start Simulation’

start the model simulation from the execution analyzer

What do we get?

example rendered UI element during a simulation

A ‘nicely’ rendered (I use the term nicely loosely of course!) dialog box that we mocked up but the button doesn’t do anything – lets fix that!


Adding Signal behaviours to Button and making our UI interactive

Head back to our CreateModel user interface and view the properties of the ‘No More Items’ button. On the ‘tagged values’ tab we want to add a new tagged value.

creating an OnClick action for the button

The naming of this tagged value is very specific and must always be named ‘OnClick’ with the following value ‘BroadcastSignal(“ “)

defining the trigger to use for the button

When the simulation is interpreted, EA will parse the above tagged value as a JavaScript function and attempt to fire the trigger “Signal Name”. So what we were doing before manually using the ‘Simulation events’ and ‘Waiting Triggers’ window in EA, we can no build into our interactive prototype to reasonable something more alike our application!

It is important to note that the trigger type must be ‘Signal’ for this to work. To check this, return to our state machine and find an appropriate transition. In my example we are using a button called ‘No more items’ which corresponds to following transition on my state machine.

locating the appropriate trigger

Bringing up the properties of this transition will allow me to view the Triggers associated with it.

checking the trigger type of the transition

Notice the type is ‘Signal’. Had this been one of the other trigger types our simulation would not register the event.

So when we run the simulation again, we can actually use the button on the UI to progress the simulation.

simulation before clicking the rendered button


Selecting the button progresses us further into the state machine as if we had used the ‘waiting triggers’ window in the bottom right of my example.

simulation progressed after selecting the rendered button

So you've now added some interesting tricks to your model but at this point you still might be thinking – “that's all very well, but that isn't all that useful to me”. Well the initial driver for me to head down this path wasn't to create a prototype application based on my state machine but was in fact to provide a better view of the variables and states I was assigning throughout my model.

Introducing the Model Simulation Dashboard!

So go along with my very basic prototype I built an even simpler dashboard view which sits along side the prototype and displays the variable states (as recorded in the EA ‘Locals’ window) and any additional info I want to record in my simulation.

To this all I do is create a second UI diagram, and call this at the first transition (from Initial –> Created in my example)

linking a second UI for a 'dashboard' type view


In the above example, Screen1 (horribly named I know!) is my dashboard view and CreateOrder is the first UI screen from our example above.

What does that look like?

example of dashboard view alongside the running prototype

I have my dashboard running alongside my UI screens to give an alternative view of things I need to track at any given time.

Protip: You can change the stereotype of a Screen element to be a Win32Dialog and get additional properties, such as setting the window to be in the centre – very useful when using multiple Screens.

Protip: adding a centre position property to the screen element

All done!

Well thats the basics covered of adding a prototype UI to your model simulations and if there is further interest I can share some tips on making a more dynamic prototype in EA, hiding elements until required – but I shall save that for another day.

Hope that was useful to someone!

Published in Tutorials