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:
- "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.
- "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.
- "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.
- "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 link s(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, as illustrated below:
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.