Enterprise Architect version 14.0



My Profile

Social Media Channels

facebook google plus twitter youtube linkedin



Guillaume Finance

VISEO (Modelling and Sparx EA Consultant & trainer, OMG OCSMP Model User certified)
Business and Systems Analyst with a software development background, and certified training instructor on UML, SysML and Sparx Enterprise Architect.
After spending several years working at an international level in the UK, I'm working for VISEO, Sparx Systems authorised reseller, VAR and Training Partner in France (www.viseo.com). Current and past projects cover the following industries: banking & finance (e.g. mortgage application), payment card systems (ATM, POS, UK APACS, ISO8583), set-top boxes, oil and gaz, car industry, and hydraulic utility manufacturing.
I publish articles and news about modelling languages and Enterprise Architect on my blog www.umlchannel.com, maintain eaUtils free addin: www.eautils.com, and participate in the European EA User Group events www.eausergroup.com

As an Enterprise Architect user, you may have had the need to apply several times more or less the same set of elements on a given diagram, leading to numerous uses of copy and paste as new.

The "copy and paste" feature on a selection of elements, including their associations and layout works ok, but there could be a more suitable way to go about this. Given a context where we have our set of elements i.e. a pattern of modelling elements available from one or several diagrams within our model, we need to apply them several times onto a new diagram. Once the new diagram is created, the elements that need to be duplicated aren't available from this blank diagram. Hence the diagram that contains those elements has got to be opened first, followed by a selection on the elements of interest, copied to the clipboard (Ctrl+C). Then the newly created diagram needs to be displayed again so the paste as new command can be executed (Ctrl+Maj/Shift+V). We also need to ensure that any specific element or information, e.g. an activity description or a child composite diagram and its sub-elements, mustn't be re-used, hence they need to be deleted.

Enterprise Architect makes it possible to re-use a set of elements, their associations, any notes, and their layout on the diagram by creating UML patterns. Similarly to the use of design patterns (GoF), the aim is to define a set of elements that can be applied for modelling purposes.

In the following example, a test case has been represented by modelling each step to follow as a node within a UML activity diagram, e.g. : pre-conditions / initial context, expected result, test result (OK/KO).

We can abstract these elements to be represented as re-usable steps, shown here :

Once our pattern is defined in a standard diagram, such as the UML activity diagram above, we can save it into an Enterprise Architect UML pattern : open the Diagram menu > Advanced > Save UML Pattern, and save into a new XML file (e.g. C:\basic tests patterns.xml). Enable the "Merge" option if you need in some cases to merge a given activity (or another node) from your pattern with an existing activity from the target diagram (active diagram).

To import and have this pattern available from an EA project, open the Resources view (use the Project menu > Resources if this view is not displayed on your EA client), and right click onto UML patterns, choose "Import UML pattern", and browse to the UML pattern's XML file.

Your UML pattern is now available to use on your Enterprise Architect project ; it should be displayed within the list of UML Patterns. Simply drag and drop this pattern onto the current diagram to create a new test step with expected and test results, as defined in this UML pattern. This window lets you rename each element before it is created.

Of course UML patterns can be applied from any type of diagram (UML class, UML state machine, BPMN, SysML BDD, etc.) or model (analysis, design, tests, architecture, etc.).

I went to the first EAUG (Enterprise Architect User Group) on the 15th of May, where around 100 people from the EA community of users and experts gathered in London.

I summarised in this article a selection of talks I attended:

  1. "Modeling Software Intensive Systems" by Doug Rosenberg from ICONIX, hinting the concept of SwissML (SysML + UML) to reach the same amount of specifications for both software and hardware blocks of an embedded system. Doug discussed about the incompatibility of agile software development processes in a context where the delivered software is not the final product, but part of a system that encompasses software and hardware blocks, alongside safety and security risks associated with any possible bug.
  2. "SysML with EA" by Roman Bretz from Lieber Lieber GmbH who shared his experiences on clients projects where SysML modelling language and EA were used.
  3. "User Story : EA usage at EVRY" by Knut Paulsen from EVRY who explained how EA was used in his company, involving specific developments of EA Add'Ins such as a document generator and an Excel import/export tool, both tailored to comply with the adopted methodology.
  4. "User Story: How to do less work, have more fun and become (a bit) famous doing it" by Ian Mitchell from Ability Engineering, who shared his experience as a BA on large project at the European scale, leading to a number of advices and point of views to take into account!

SWISSML: not the Helvetica modelling language, but SYSML + UML to provide the same level of specifications on both software and hardware blocks

« Modeling software engineering systems » talk from de Doug Rosenberg at ICONIX deals with the critical role of specifications on embedded systems software. In a Software Engineering context, any software bug can not only lead to economic losses, but also to safety and security risks including those of life threatening nature. As regards, the realisation of the system's software blocks shouldn't be carried out separately from the specifications. However this is often the case e.g. where the software implementation is carried by a SCRUM development team.

To illustrate this, Doug used the American Airlines' reservation system, where he experienced as a passenger a bug in the issued ticket where the printed month was incorrect (e.g. March instead of Feb) despite his flight was confirmed on the right date. A simple search in Google showed that AA chose an agile development process for some its software.

Doug reminded some of the agile software development principles and methodologies:

  • TDD promotes writing tests first, refactoring and code fixing.
  • The agile manifesto « Working software over comprehensive documentation » statement leads to less detailed specifications (user stories).

According to him, those principles aren't compatible with a system engineering project, where detailed specifications are required, and simulating the model before its implementation is common practice, e.g. through the use of SysML (parametrics) or MatLab tools.

The choice of a separated agile process could increase the risks of critical bugs. In the given AA example, imagine the safety risks that could arise due to the passengers reservation system bugs if data from this software was fed into the aircraft luggage weight management system.

It would therefore be sensible to require the right level of specifications using UML models for the system's software, based on the system's SysML models. This leads to SwissML (UML + SysML).

Doug introduced the SysML pillars to model the system:

  • Requirements model
  • Domain model to define the vocabulary
  • Static models: block definition diagrams at 2 levels (sub-system & component), and internal block diagrams for a finer level of granularity
  • Behavioural models: use cases, sequence diagrams (design), activity diagrams to describe use case scenarios, and state machines.

SwissML involves producing the same level of specifications for hardware blocks (e.g. System on Chip) and software blocks. EA can be used to add to a modelling project with existing SysML models, UML models for the software. Hence the software components can comply with the existing system's requirements, and be defined through an appropriate and detailed level of specifications.

Note: choosing an agile development process to implement software wasn't the subject of this talk, instead it was discussed that those aren't compatible in a systems engineering context.


Roman Bretz from Lieber Lieber GmbH shared his experience with SysML, starting with a list of principles about modelling languages (e.g. to enable communication, requires that it is understood by all).

Based on his experience, projects where SysML and EA were used mostly include requirements and architecture models (SysML requirements, BDD, IBD diagrams), and only few included dynamic models as well (SysML activity, state machine, and use case diagrams).

Roman presented the structure of a "thermometer" EA project via the following SysML models:

  • Requirements model, enabling allocation/traceability links between requirements and elements from within other models.
  • System use case analysis
    • This is a decisive part of the model to set the functional scope of the system, and where the priority is given on use case results/post-conditions and the sequence of actions.
    • Then Roman described an interesting case: when setting up the model via the analysis process, the client didn't see the point of including a use case model, and estimated that it would be expensive to achieve. However Roman suggested carrying out the exercise to try and see. This led to the identification of more than 300 use cases, pointing out that the system functional scope wasn't clear. Carrying further on the use case analysis, around ten use cases were confirmed, which demonstrated the true benefits of working on a use case model.
  • System context to identify all entities in interaction with the studied system.
  • Domain model to associate business terms with SysML models.
  • Behavioural models
    • A system block's behaviour goes beyond the definition of its attributes and operation signatures. A block can also be associated via allocation links (e.g. traceability in a SE context) with activities, interactions (e.g. sequence diagrams), and state machines.
    • Activities and interactions match part of a block's operation implementation, whereas state machines define the block lifecycle.
    • From then, it can be useful in EA to manually represent additional compartments on a SysML block to show its state machines, activities, and interactions.

EA usage at EVRY

Knut Paulsen shared his experience on an advanced usage of EA at EVRY, company based in Norway.

UML Profile

EVRY has defined a UML profile to extend its use case models according to some principles from Alistair Cockburn book:

  • Additional properties have been added to the 'use case' element, available in the new use cases via tagged values.
  • Two stereotypes have been created on the 'use case' metaclass: summary & user goal.
  • A new stereotype has been created on the 'class' metaclass, "field list", to be used alongside use cases. "Field list" stereotyped classes are intended to define the list of fields that are involved with a use case, i.e. where this information is expected to be entered through one or several steps defined in the UC scenarios (e.g. name, address, date of birth, etc.). For instance we can define for the use case "search a client account" a list of fields with the following attributes: client reference, company name, client type. Note : I think that this concept is interesting as the list of required fields can be defined during the analysis, and be used at later stage when designing or implementing a User Interface.

EA Add’ins

Knut and his team have implemented 2 add'ins using EA API:

1- An Excel import/export to produce in an Excel file a list of requirements for each stakeholder to update directly in Excel, before importing thel back into EA. EA CSV export/import features are limited, hence the need for an add'in to easily synchronise requirements between Excel and Enterprise Architect.

2- Due to EA native document generator limitations, EVRY implemented its own Word document generator with advanced features:

  • keep a trace of all generated use case documents, alongside with the name of the person who approved, and the approval date for each version,
  • store a new version of the generated use case document (word or PDF format) into a shared folder, which location is defined in the add'in settings.

The advantages of complex and complete EA add'ins were illustrated throughout this talk, whilst showing a true investment of EVRY in extending EA capabilities to the methodology adopted by its teams.

These tools aren't publicly available, hence making this session very interesting to get a feel of what we can get against a given amount of efforts spent.

A single version of the truth

Ian Mitchell from AbilityEngineering shared his experience as a BA consultant on a large project at the European scale. Ian joined this project to deal with a large number of change requests and requirements.

Context: the first version of this product had been released, leading to numerous requests for the next revision. Those requests were submitted by product managers from each involved country, many of them being specific to local laws and regulations.

Ian started an Enterprise Architect project to capture the following:

  • Features submitted by the stakeholders (i.e. product managers),
  • a requirements model (requirements were associated with features),
  • a domain model to define business entities and the vocabulary,
  • risks, actions, changes, and issues, so e.g. a number of actions resulting from a project meeting could be captured in EA as 'action' elements, leading to new 'change' elements associated with those new 'action' elements to trace the impact of processed change requests.

EA has become an essential asset by capturing all the knowledge for "a single version of the truth", preventing having documents and information spread across wikis and file repositories. Ian provided us with an interesting advice: instead of attempting to redefine everything in EA, the Business Analyst should spend efforts in gathering and collecting existing documents, standards, or MS Visio drawings, and push them as references into EA so this project holds a relevant amount of knowledge, right from the beginning. From then, the team can for instance easily create a link in EA from a new business rule to an existing standard reference, e.g. preventing losing track afterwards of what justified this rule and its deletion for the wrong reasons.

Once the analysis was complete for the next product's version, a specifications document was generated and submitted to get the approval from each product manager. However since many items from this document were specific to a single country, many stakeholders were reluctant in giving their approval on a document which partially had no relevance from their perspective.

Ian decided to identify with each product manager what they exactly expected from the product. Traceability links were created in EA from stereotyped actors - stakeholder - and various elements within the models. This traceability made it possible to generate a specification document for each manager with a relevant set of requirements, business rules, and use cases. EA native document generator wasn't used as it was too limited, so Ian managed to achieve this using EADocX document generator.

To conclude:

  • Ian reminded us that no matter how well structured and managed an EA project is, the quality of our work is assessed through the content of the delivered documents. Hence it is paramount to generate the relevant information.
  • The EA project eventually became an essential asset for the client, leading to a new dedicated team responsible to maintain it.


This European EAUG has been a success; I gathered a number of very interesting and useful feedback from EA experts and consultants, and it let me discuss about various topics on EA with speakers and members of Enterprise Architect community.

More information is available from www.eausergroup.com.

Monday, 11 October 2010 00:00

SysML Modelling Language explained

This article introduces the OMG SysML modelling language, dedicated to complex systems combining software and hardware realisations. SysML, adopted in 2006 by the Object Management Group, provides a vocabulary suitable to Systems Engineering e.g. by modelling Blocks instead of classes. SysML uses a subset of UML2 and defines its own extensions, making it a smaller language that is easier to learn and apply.


UML, the standard modelling language used in the field of software engineering, has been tailored to define a modelling language for systems: SysML or Systems Modeling Language.

This article is intended to provide a non-exhaustive presentation of SysML including some background about Systems Engineering and SysML, and a review of each SysML diagram and modelling techniques.

The article "SysML Modelling Language explained" is available from the following PDF document (size: 747 KB).

You may wonder why an incomplete or incorrect diagram would be useful. Shouldn't it make sense to aim at producing a good representation right from the start by modelling what needs to be built and achieved? This article deals with a simple approach: incomplete diagrams provide a visual representation of the system to be built, that once shown to stakeholders, product owners, dev teams, and project managers, will trigger feedback and discussions to move towards a shared vision.

This article deals with a recurring question in use case modelling: given a use case that’s automatically triggered by the system clock or timer, what actor should be used? In this context, it is common use to define as the primary actor the system’s clock or timer, since this actor triggers the use case. This article compares three alternatives.

Using Enterprise Architect in a Team Environment often involves a version control repository like SVN (Subversion). This article describes a way to compare the current version of a package in your model, which is controlled under an XMI file in SVN, with an older version of this package. This is achieved through the use of the EA Baseline feature.

Wednesday, 15 August 2012 17:05

Discover and use EA Diagram Filters

This article is intended to illustrate the advantages based on my current experience of using the Diagram Filters, functionality added in EA version 9. Two case studies/examples illustrate the purpose of Diagram Filters: 1- filter dependency connectors between provided and required interfaces on a UML Component diagram, 2- show differences between the specifications and two implementations through the use of UML State Chart diagram.

Wednesday, 21 November 2012 19:57

Enterprise Architect V10 beta Preview

Sparx Systems will shortly release Enterprise Architect version 10. An overview of the main features is available from the following link: http://www.sparxsystems.com/products/ea/10/index.html.

This article is intended to provide a preview of the improvements and new features that are expected in Enterprise Architect v10 following a test carried on its beta 2 (note: as a beta version, the features shown in this article may be modified when the final version is released).


Thursday, 14 June 2012 07:52

SysML 1.3 released

The OMG has published this month the official specifications of the expected new version 1.3 of SysML, two years after releasing SysML 1.2.

SysML 1.3 affects the definition of ports by introducing Full Ports and Proxy Ports, both allowing to combine operations to call, and items to flow in and out the block. SysML 1.3 updates also include nested ports, nested flows, association blocks, and port compatibility.

Further details are available from my post in April : SysML 1.3 beta preview.

Friday, 27 April 2012 11:00

SysML 1.3 beta preview

The next version of SysML, the modelling language based on UML for Systems Engineering projects, should be released in June as version 1.3 beta is currently listed on the OMG.org website.

Even though SysML 1.3 beta specifications aren’t released yet, it’s already covered in the Second Edition of “A Practical Guide to SysML” book by S.Friedenthal, A.Moore, and R.Steiner (ISBN : 0123852064).

SysML 1.3 main changes apply to ports, distinct interaction points on Blocks. In the current version (SysML 1.2), there are two types of ports: standard ports to describe service oriented peer-to-peer interaction through provided/required interfaces, and flow ports to describe items that can flow in and out the block. 

Flow ports and Port specifications are deprecated in version 1.3, but the concepts remain: SysML 1.3 replaces them with two new types, Full Ports and Proxy Ports, both allowing to combine operations to call, and items to flow in and out the block.

●     Full ports

●     A full port represents a part that has been placed onto the main block’s boundary so it can be accessed from external blocks; hence this part is no longer shown inside the main block but as a full port

●     A full port is typed by a block to define its properties i.e. operations to call and/or items that can flow in and out the block. A full port therefore combines both SysML 1.2 flow ports and standard ports, and no longer requires the ball and socket interface notation

●     Full ports can be conjugated like SysML 1.2 flow ports to reverse the direction of items ; it has the same effect on operations i.e. it will change provided features (supported by the owning block) to required features (operations that must be supported by other blocks)


sysml 1.3 full ports

●     Proxy ports:

●     A proxy port acts as a surrogate or placeholder to route all requests to the real port that provides these features (operations, items) ; this port may belong to the main block or an internal part

●     A proxy port does not implement any feature, nor is it a block internal part

●     Proxy ports are typed by Block Interfaces to specify the available features (items and/or operations)

sysml 1.3 proxy ports

●     Nested ports and nested flows have been introduced in SysML 1.3 to specify an additional level of ports within a port. As shown in the following diagram, the port p1 has two nested ports to associate external blocks directly with the AC in and Audio out.

To define nested ports, the block’s port is type by a block that owns ports


●     Association blocks have also been introduced in SysML 1.3 to specify port compatibility in order to ensure that connecting ports from different blocks doesn’t violate any constraint

○     This is modelled by creating an association block between two interface blocks, and then choosing this association block as the type for a connector between the 2 proxy ports:


sysml 1.3 association block


SysML 1.3 has revised the concept of Ports to provide a more complete approach and definition compared with version 1.2. For instance it prevents from duplicating ports when a Block both needs to provide or require operations and have items to flow in/out.

This approach could have a significant impact on how you organize and model your system since interfaces are no longer exposed by ports. Instead, it will the block used as the type for the full port, that will realize or use interfaces, or itself own operations.

Once SysML 1.3 is available, it will be interesting to see how SparxSystems will implement it in Enterprise Architect so these new features are easy to use (e.g. with the IBD, to move an internal part of the block to a full port). A feature to easily convert a project from SysML 1.2 to 1.3 whilst keeping a good control over the changes would be useful.

Page 4 of 4