This year’s London EA User Group took place at the Skills Matters Code Node venue. It has been enjoyable and useful to discuss and share experiences with users via this unique dedicated SparxSystems Enterprise Architect event.

This article shares some feedback on the following presentations:

• Keynote on Enterprise Architect 14 by Peter Lieber.
• Model Driven Enterprise Knowledge with Gemalto GMOD platform by David Faus.
• My presentation on scripting with Enterprise Architect.

Keynote: Sparx Enterprise Architect 14

The keynote was an opportunity to discover some of the new features available in Enterprise Architect 14. Having started evaluating version 14 since its beta release, this presentation saved me time as I received an overview of the relevant enhancements.

A new checklist artifact is available from the common toolbox.

Once created, items can be added alongside their Boolean status (checked: true or false).

Result:

Other rendering options are available:

EA 14 has introduced the EAPX file extension, as an alternative to local EAP files, matching a Jet4 engine database. Jet4 EA projects can be created in previous EA versions within an EAP file. EAPX are useful since it is explicitly tied with Jet4 engine (this format provides enhancements on the database capacities). Note that EAPX files can be opened with earlier EA versions.

A new Cloud tab is available in the CONFIGURE > Options menu (note: the following options are available in EA 13.5).

The above Data Cache option can be enabled to create images of each diagram in the EA project database when saved in EA. These images can be used and rendered in external solutions via SparxSystems Pro Cloud Server. A create batch feature is available to generate all diagrams images.

Perspectives in EA 14 can be used to enable only the notations or languages that are relevant to the current use and context. The built-in Systems Engineering\SysML perspective can be enabled for instance so users only work with SysML 1.5 elements and diagrams, and will never come across other SysML versions, or UML, BPMN, ArchiMate and so son. Custom perspectives can be defined to select a range of technologies e.g. UML and BPMN. Note: I find perspectives very useful to scale down EA features to the ones that are needed by users through a built-in feature (instead of custom XML or registry updates by the company IT services). The Model Wizard has been redesigned in EA14; in EA 13.5 and earlier versions, it was mainly used to generate Model Patterns.

EA 14 Model Wizard runs in a view (not a popup) with redesigned model patterns. First of all, the available patterns are displayed for the selected perspective, e.g. UML, Business with BPMN, Systems Engineering with SysML, Enterprise Architecture with ArchiMate, etc.

Where the previous patterns generated a full structure with samples in each model e.g. class, use case, and so on, the logic here is to individually select and add model patterns to the local project. Patterns may include several packages, elements and diagrams.
For each pattern, a nicely illustrated explanation on the purpose is available, enhancing the usability and value delivered by Model Patterns.

EA 14 Model Patterns also include a new Process Guidance tab as an addition to EA Help. It creates a step by step process via an activity diagram e.g. to create a central database EA repository in MySQL as illustrated below.

The element properties have been integrated within views to replace the pop-up properties window. For elements, additional views provide access to the attributes, operations, etc.

Also available as a view, the diagram properties now display the Diagram GUID which can be useful:

The Compartments tab provides access to the elements visibility properties. Note: I would expect in the future to have all diagram properties in this view e.g. Features, Connectors properties.

The Diagram properties include new MetaModel options, linked with MetaModel Views, both introduced in EA 14. This Views system is aimed at restricting the available elements and connections from the diagram toolbox. MetaModel Views are either built-in or user defined (note: user defined views can be useful to combine stereotyped elements and built-in elements such as a UML class, use case and actor).

When creating a diagram, a list of built-in views is available under the diagram type, for instance a UML Class diagram illustrated below:

The resulting toolbox is different from the default UML class diagram.

This selection sets the “Applied to Metamodel” diagram option.

In addition to the toolbox content, the Filter to Metamodel diagram property is now available: when set, this option will grey out all elements that are not in the current Metamodel as illustrated below.

Another new option is the Display Lock Element Status: when enabled, locked elements will be visible accordingly on the diagram.

A smart placement feature is now available to dynamically visualize the selected element’s alignment.

Model Driven Enterprise Knowledge

Note: the following summary has been written by its author and speaker, David Faus (Gemalto).

Our goal was to build enterprise knowledge repositories based on models in several business units in Gemalto. The following diagram shows our strategy coming from the well-known Nonanaka and Takeuchi knowledge management theory:

We successfully used SPARX to build our model based KM platform called GMOD (Gemalto MODeling).

To deploy our “GMOD” adaptation of the Nonaka and Takeuchi approach, we used:

• The EA MDG to implement the “UC” method which I have been building during the last 25 years. This method is quite innovative because it is based on several domains (graphical user interface specification methods, functional analysis and also Object Oriented Programming), and is customer oriented: that means everyone is able, in few minutes of explanation, to understand a UC model.
• The EA client server architecture to allow all team members to produce UC models in parallel, what is finally relevant when building a huge model oriented knowledge base. The first big success we had was the delivery of the GBPR (Gemalto Business Process Repository): All Gemalto corporate business processes are now published and maintained thru GMOD.
• The EA java API to implement the Gemalto “SPARX Companion Tool”. This tool is complementing SPARX EA functionalities by adding reporting features, UC model integrity check, one click deployment web service…
• The Gemalto FAST & Easy knowledge management platform. This platform is based on the concept of patrimonial archiving. It is used to index any important UC diagrams produced thru GMOD. This is possible because the “SPARX Companion Tool” generates static URLs for diagrams.

As a conclusion, we are now able to retrieve model oriented knowledge by simply using a Google like search engine. Our next goal is to focus on the support functions and provide some knowledge base composed by hundreds of comprehensible use cases helpful at any level and anywhere in the company. 

Extending EA with custom scripts to cater for specific needs and user requests

It was my pleasure to be selected for the third time this year as a speaker. I offered to share my experience on defining scripts in EA over the past years to extend the tool’s features e.g. via custom Excel import/exports, save users' time in avoiding repetitive or time consuming tasks, etc.

The full presentation content is available from SlideShare.

Below is a summary with selected slides to illustrate the topics:

• Enterprise Architect can be greatly customized to cater for a client or project, and it includes creating features using the API from scripts, add-ins, Excel macros, etc.
• Where EA already provides numerous features, there is still a need to create additional ones as illustrated below.

• The choice of using Scripting was supported by the need to frequently update and deploy new versions to a large group of users.

•  Having introduced the different types of scripts (project browser, diagram, normal), I discussed the need to apply naming conventions so users can clearly find the appropriate script to run.

• The usual way to use EA API is to call methods from the Object Model, e.g. get an element’s parent package element with the following VBScript method call: set parentPkg = Repository.GetPackageByID(curElement.PackageID).

• Alternatively SQL queries can be used …
  • To run complex queries.
  • To select specific elements, preventing time consuming loops.
  • To address performance issues related. Replacing a method call with SQL update reduced the execution time for ~1000 attributes from 120 minutes down to 4 minutes.
•  SQL queries can be used on the Repository object methods:
  • Repository.GetElementSet(query,2) : returns a collection of EA elements according to the SQL query
  • Repository.SQLQuery(query) : returns an XML formatted string value (SELECT queries only)
  • Repository.Execute(query) : runs a query (UPDATE/DELETE/INSERT)
• Care should be taken when running UPDATE/DELETE/INSERT queries as it can delete or break the model.
• Moving on Scripts helpers, I shared ways to address issues both from the developer and user perspective.
• Below is the publication process that has been defined (illustrated via the first demo on EA).

• With some scripts requiring to select a source or target folder to process or generate files, a common script feature made it possible to suggest the previously selected folder. Other users’ script helpers are illustrated below and were demonstrated in EA.

• Geert Bellekens’ free EA-Matic add-in has been used to automatically trigger scripts based on configured events e.g. before creating a connector.

• Having shared a few hints, I completed the presentation with a demonstration of custom scripts defined for a number of clients.

Note: this article is available in French here.

Requirements Checklist

by Phil Chudley, Principal Consultant

There is a hidden gem in Enterprise Architect (I am using version 13), but this gem is available in previous versions (I believe version 11 and version 12).

This is an element called a Requirements Checklist, although it could be used as a checklist for other elements.

A Requirements Checklist allows the modeller to create a list of check-boxes, which can be used against an element (or elements), to manage at least the following:

• Element completeness.
• Element quality.

This article introduces the Requirements Checklist and illustrates how such an element can be used and customised.

Default Use

A Requirements Checklist element can be added to a model diagram (the element can be found on the Requirements Diagram Toolbox) or added directly to a package within the project browser.

When added to a diagram, the Requirements Checklist has the following appearance:

Double-clicking opens the following dialog:

Clicking on a checkbox will check the checkbox as shown below:

Then upon clicking Close, the Requirements Checklist element will display on a diagram as shown below:

Using the dialog invoked via double-clicking, the appearance of the check box can be modified as shown below:

Checked Item Style <none>	Checked Item Style Strikeout	Checked Item Style Greyed

Relating to an Element (or Elements)

Elements can be related to Requirement Checklist using any of the usual techniques in Enterprise Architect, namely:

• Quicklink on a diagram.
• Toolbox relationship on a diagram.
• Relationship Matrix.

Which Relationship to Use and which direction?

Using the diagram Quicklink, the modeller is presented with the following choices:

• Dependency.
• Trace.
• Information Flow.

Which relationship to choose to up to the individual modeller, but ideally, the modeller will choose a relationship that “makes sense” to all stakeholders in the project.

My own personal choice is Dependency drawn from an Element to the Requirements Checklist.

The most important issue is:

No matter what relationship is used and no matter which direction is used, the same type of relationship and the same direction must be used consistently throughout the entire model by all modellers.

The main reason for this statement is for the production of documentation and reporting (covered in a future newsletter).

Configuring the Requirements Checklist Element

Although not immediately obvious, is the ability to customise the list and text of the check boxes.

A modeller can define their own list of checkboxes by using the following steps:

1. Double-click the Requirements Checklist to show Dialog.
   
2. Right-click on a check box entry and select Edit (to modify), Delete (to remove) this checkbox item. An example of such a modification is shown below:
   
3. Click Close to apply the changes.
   

Re-using Requirements Checklist

Different elements may require different checklist elements, therefore I recommend the following modelling strategy:

1. Create a Package in which to create / store all the different configurations of the Requirements Checklist element. (A list of “master checklists)
2. When wishing to use one of these checklist elements:
   • Right-click a checklist element (or checklist elements) and select Copy to clipboard > Full structure for duplication.
   • Select another package in the project browser, right-click and select Paste Element(s) from clipboard.

Summary

In this article I have presented an overview of an often overlooked element in Enterprise Architect, namely the Requirements Checklist. I have also described how such elements can be customised and re-used from a library of “master checklists”.

In a future article I will describe some techniques for producing documents which detail elements and their related checklists.

Phil Chudley
Principal Consultant
Dunstan Thomas Consulting
@SparxEAGuru

You’ll find lots of useful Enterprise Architect videos on our YouTube Channel.