Enterprise Architect version 14.0

download
purchase

enzh-CNcsnlfrdehiiditkoplptruskessv

My Profile

Social Media Channels

facebook google plus twitter youtube linkedin

Guillaume

Guillaume

Guillaume Finance

VISEO (Sparx EA Expert, OMG OCSMP Model User certified)
 
Modelling consultant and expert on Sparx Systems Enterprise Architect modelling tool and solution, I'm helping clients with the model-based approach using standards for a number of contexts including:
- Software analysis, design and architecture with UML.
- Systems Engineering and MBSE with SysML.
- Enterprise Architecture, IT landscape with UML or ArchiMate.
- Business processes with BPMN.
My other activities include:
- Defining and maintaining the model repository including requirements, analysis and design for software projects.
- Remote support and expertise on Sparx Enterprise Architect modelling.
- Running training sessions on UML or SysML with Sparx Systems Enterprise Architect.
- Installation and configuration of Prolaborate web solution for Sparx EA.
 
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 I participate in the European EA User Group events www.eausergroup.com
Contact details: guillaume[at]umlchannel.com

Sparx Systems Enterprise Architect is a great tool to produce and organise your models using UML, SysML, BPMN or other modelling languages or notations.

In some cases, the default rendering of elements on certain types of diagrams lacks a suitable colour scheme and font.

This article deals with two topics :

  • Highlight the strengths of Enterprise Architect as a modelling tool versus that of a drawing tool,
  • Applying visual styles to improve the look and feel of your diagrams.

A vital switch from a drawing tool to a comprehensive modelling tool

Initial context : A colleague and I discovered a set of BPMN diagrams maintained by a team using a BPM modelling tool, Bizagi BPMN Business Process Modeler. Being a freeware must have helped to quickly try and adopt this tool for the project. I have to say that the rendering of the diagrams looked rather attractive and modern. As a UML and BPMN expert, my colleague was the first one to get involved in this task. He started to model new business processes, and update existing ones as requested. He noticed a number of mistakes (e.g. broken sequence flow, missing end event) that he promptly fixed.

As things went on, we had a chat and I asked what he thought about this tool compared with Sparx Enterprise Architect. His feedback was interesting ; Bizagi was more or less a drawing tool like Ms Visio, that can be used to create a couple of UML diagrams. A project browser was  missing from Bizagi i.e. when you create a BPMN node like an activity or gateway, you have no access to this element so that it can be reused into several diagrams. Not to mention all the other powerful advantages from Enterprise Architect including traceability with other model elements from the same project, e.g. to link an activity with a requirement it fulfils, or with a use case to establish links between the business and system analysis models.

The need for a real modelling project quickly lead to a move from Bizagi modelling tool to Enterprise Architect, as agreed by the client.

Applying visual styles to improve BPMN diagrams rendering

As I started to create and maintain BPMN diagrams in Enterprise Architect, I looked at simple ways to reproduce a similar look and feel from the original tool (Bizagi).  The aim was to improve the default rendering of Elements in Enterprise Architect.  Below,  I managed to reproduce a similar visual style using the following colour schemes:

  • BPMN2 start event : light green background + dark green line

 Sparx EA diagram visual start on BPMN start event

  • BPMN2 end event : light red background + dark red line

 Sparx EA diagram visual start on BPMN end event

  • BPMN2 activities and gateways : light blue background + dark blue line

 

The procedure to create those visual styles is quite easy:

  • 1- I first defined the visual settings on a selected element using the diagram toolbar by setting the background colour, line colour and width, and the font.
  • 2- Then I clicked on Save as New Style icon from the toolbar, and entered the style name as prompted by Enterprise Architect, e.g. start event.
  • Alternatively, having an element with its visual settings already done, a new style can be created using the Get Style icon from the toolbar, followed by Save as New Style.
  • 3- Having repeated this process for each new visual style, I ended up with a list styles ready to apply onto my diagram's elements.

Note : Visual styles are stored within your Enterprise Architect project (e.g. the EAP file) but I haven't found them yet from the Reference Data to export them and share with others.

Once all visual styles have been defined, the following list can be opened from the diagram toolbar :

 

Here is an illustration of what I came up with, having applied the new styles :

 

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.

SYSML WITH EA

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.

Conclusion

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.

Abstract:

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.

Page 4 of 5