In the most recent release of MDG Office Integrations (v1.4.40), an exciting enhancement known as the "BPMN Visualizer" has been introduced, offering an excellent utility for BPMN users. This feature facilitates the seamless transfer of BPMN Components between Microsoft Excel documents and Sparx Enterprise Architect Models.

The key feature of 'BPMN Visualizer' in MDG Office Integration

• Simplified Approach that eliminates the necessity for Profile Creation during import and export for mapping items. This drastically minimizes user time and the possibility of manual errors.
• Through a single click of "Excel to EA" menu, users can quickly synchronize BPMN Components, seamlessly updating and aligning data between Excel and the Enterprise Architect model.
• The visual representation of diagrams from the Enterprise Architect model, as well as the related preconfigured mapping table, can be displayed within Excel.
• The capability to incorporate multiple diagrams is supported when a package is selected. This involves displaying all diagrams in the selected packages along with their corresponding predefined mapping tables on separate sheets.

BPMN Components on Microsoft Excel

MDG Integration for Microsoft Office provides seamless integration within Microsoft Excel (Version 2007 and above). A newly introduced feature named ‘BPMN Visualizer’ now resides in the ‘Feature’ dropdown of the Enterprise Architect ribbon in Excel. This feature facilitates the seamless transfer of ‘BPMN Components' between an Excel document and Enterprise Architect, allowing for bi-directional data exchange.

To import BPMN Components into Enterprise Architect from Excel

	The Feature dropdown offers the following selection options: ‘Export to EA’: Export the elements to Enterprise Architect using Profiles ‘SysML Requirement Manager’: Import SysML requirements from Enterprise Architect and Export SysML requirements and their connectors to Enterprise Architect. ‘BPMN Visualizer’:  Import BPMN Components from Enterprise Architect and export BPMN Components to Enterprise Architect.
	Allows one to select a *.eap or *.eapx or *.feap or *.qea or *.qeax or *.eadb through local project, server connection, or cloud connection. Local Project: To connect the Local Enterprise Architect model. Server Connection: To connect to an Enterprise Architect repository through a database Cloud Connection: To connect to an Enterprise Architect repository through the Pro Cloud Server
	Allows users to select a Package or BPMN Diagram to Load from the Enterprise Architect Model to Excel with the respective diagram image.

Select a package

• This window will be displayed when the Package Icon is clicked.
• It displays all the models and packages from the selected Enterprise Architect model, with BPMN Components being imported specifically.

Select a BPMN Diagram

• This window will be displayed when the Diagram button is clicked.
• It provides a hierarchical overview of all diagrams within the packages of the model. Users have the ability to choose a specific BPMN diagram from this view.

Note: The ‘Ok’ button will only enable when the selection type is BPMN Diagram

Utilizing Excel for BPMN Components

• The selected diagram is imported to an Excel sheet along with its predefined mapping table.
• The Excel sheets are named in the format of Diagram Name with Diagram ID.

Excel column definition

Creation of element from Excel to Enterprise Architect model

• To create a new element, enter a name in the ‘Action Name’ column (mandatory).
• By default, the ‘Action Type’ is ‘Activity’. Users can change the type using the drop-down list.
• Mapping the parent element for the newly created element is also achievable using the ‘Parent’ column.

Note: Supported Element types are Activity, Gateway, StartEvent, IntermediateEvent, EndEvent, DataStore, DataObject, BusinessProcess, BPELProcess, GlobalTask, Pool, and Lane.

Establishing connectors for the newly created element in Excel

‘Next Action ID’ creates a connector between two BPMN elements. Choose the appropriate ‘Action ID’ in the checklist box of ‘Next Action ID’ to connect. By default, the connector type is ‘Sequence Flow’

Note: Supported connector types are SequenceFlow, MessageFlow, Conversation Link, DataAssociation, and Association.

To update the changes from the mapping table in Excel to the Enterprise Architect model utilize the ‘Excel to EA’ Icon available in the Excel Ribbon; The preview form is presented to the user to ensure that the intended changes are ready for export. Once you click the ‘Export’ button, synchronization is initiated between the Enterprise Architect Model and Excel, causing the changes to be updated in Excel as well.

As depicted in the image below, you can observe that the recently generated ‘Process goods’ element has been incorporated into the Excel diagram. This element establishes a connection with the ‘Gateway5’ element, as indicated in the mapping table. Likewise, this synchronization is also reflected in the Enterprise Architect model.

The ‘EA to Excel’ icon enables users to revert the produced items back to their original state as Enterprise Architect Models, providing an opportunity to undo changes made in Excel. Additionally, it facilitates the synchronization of changes made from Enterprise Architect to Excel.

BPMN Components from Enterprise Architect to Microsoft Excel

Through the ‘BPMN to Excel’ menu, users can export data pertaining to BPMN Components, which have been accumulated within Enterprise Architect, into the Predefined mapping tables along with diagrams in separate sheets within Excel.

After selecting the package or BPMN Diagram, the Enterprise Architect will begin exporting data to an Excel sheet and proceed with Refer "Utilizing Excel for BPMN Components"

Check out the BPMN on Excel and Enterprise Architect video here

To know more or to request a demo, please reach out to This email address is being protected from spambots. You need JavaScript enabled to view it.

"SysML Requirements on Excel" is a new MDG Office Integration feature that allows users to author SysML requirements using Excel. Users can seamlessly integrate SysML requirements between MS Excel and Enterprise Architect.

Key features

• Import and export SysML requirements data from Excel into Enterprise Architect.
• Ability to create SysML Compliant requirements with inter-dependencies

SysML Requirements in Enterprise Architect

Using the “SysML Requirements on Excel” menu, users can connect an Enterprise Architect Model with an Excel spreadsheet.

This will create an Excel Document with required templates to let users create SysML requirements. This will also copy any existing Enterprise Architect requirements and the derived relationships to the Excel spreadsheet, to let users update or modify these contents.

Working with Excel to author Requirements

The Excel template for SysML requirements authoring will have two spreadsheets,

1. Requirements – The requirements sheet is used to create and update SysML compliant requirements, including Id and text, the sheet also displays any derived requirements (interconnected requirement)

The Requirement Sheet has two parts: "SysML Requirements" and "Derived SysML Requirements".

SysML Requirements – It contains Name, Notes, Status, Version and Id, Text (Mandatory tags for SysML)

Derived SysML Requirements – It also contains Name, Notes, Status, Version of Derived Requirement for each SysML requirement. This part is completely non-editable.

2. Requirement Matrix – This worksheet will present all requirements in a matrix format to let users easily create derivation inter-dependencies between them.

• This sheet will be automatically updated when new requirements are added in the ‘Requirements’ worksheet
• New relationships created in this spreadsheet will also be automatically updated in the ‘Requirements’ worksheet

Insert Elements and Connectors

Insert the element in the Name Column of the Requirement Sheet (with Notes, Status, Version, ID, and text, but the Name column is mandatory). And create a connector between the newly created element and the existing element in the ‘Requirement Matrix’ sheet.

Newly created connector details are updated in the ‘Requirement’ sheet.

To sync or update the modifications to the Enterprise Architect Model, use the Excel to EA icon. The changes reflected in the Enterprise Architect Model will be shown in the preview form. To update into an Enterprise Architect Model, select Export.

New elements are created under the chosen package.

The EA to Excel icon is used to restore the produced items to their original state as in the Enterprise Architect Model.

Prior to ‘EA to Excel’

Post ‘EA to Excel’

SysML Requirements on Excel (from Excel)

MDG Integration for Microsoft Office offers integration within Microsoft Excel (Office 2007 and above), and a new feature called SysML Requirement Manager is added to the feature dropdown of the Enterprise Architect ribbon. Using this, users can easily push the contents of SysML requirements from an Excel document to an Enterprise Architect or vice versa.

To import SysML requirement data into Enterprise Architect from Excel

	Dropdown list to choose the Export to Enterprise Architect Model or the SysML Requirement Manager for the document. ‘Export to EA’: Export the elements to Enterprise Architect using Profiles ‘SysML Requirement Manager’: Import SysML Requirements from Enterprise Architect and Export SysML Requirements and their connections to Enterprise Architect.
	Allows one to select a *.eap or *.eapx or *.feap or *.qea or *.qeax or *.eadb through Local project, server Connection, or cloud connection. Local Project - To Connect Local Enterprise Architect model. Server Connection - To Connect to an Enterprise Architect repository through a database Cloud Connection - To Connect to an Enterprise Architect repository through Pro Cloud Server

Select a package

• This screen will be displayed when the Package button is clicked.
• It displays all the models and packages from the selected Enterprise Architect model, with SysML Requirement items being imported specifically.

After selecting the package and clicking ‘OK, ‘Enterprise Architect will begin exporting information to an Excel sheet and proceed with Refer "Working with Excel to author Requirements"

Check out the SysML Requirements in the Enterprise Architect video here

To know more or to request a demo, please reach out to This email address is being protected from spambots. You need JavaScript enabled to view it.

To Shape Script, or not to Shape Script?

Almost a year ago, as we embarked on what was to be the first of a series of lockdowns in the UK, I decided to learn some new skills that I could put into practice with Enterprise Architect (EA). I decided that I would like to learn how to create an MDG to assist not only my own modelling activities, but also those of the clients to which Dunstan Thomas provide consultancy services. Besides, with access to one of the best in the business (Phil “Chudders” Chudley) I had no excuse not to drink from an unending well of knowledge.

What is an MDG and what is a Meta Model?

An MDG, or Model Driven Generator Technology, to give it its official title, is the method in which Sparx Systems Enterprise Architect implements a Meta Model.

A Meta Model is the definition of symbols and relationships within a modelling notation. It also defines the rules to which those relationships must adhere.

Getting to it!

I set aside some time with Phil and followed him down the MDG rabbit hole, like my very own White Rabbit.

Over the course of a couple of days, I spent a lot of time with Phil absorbing his words of wisdom. It was then time to get practical as I, like many others, learn best by doing. Therefore, I set out to create what would become my first MDG. I wanted it to be something that would use again rather than it just be a learning aid, so I looked at my role within DT to see where I could make use of a tool not traditionally used to capture information via modelling. This led me looking into risk capture.

In addition to my role as Consultant, I also lend my hand to various other activities about the office (who remembers offices? I ‘member) and one such activity is performing the fire risk assessment for the office. This had me thinking, can I use EA with a custom MDG to model my risk assessments? The answer is of course yes…else, I would not be writing this article.

Unfortunately, COVID-19 threw a spanner in the works as we were very soon under lockdown conditions. This meant that with the office closed, I could not perform a test using the fire assessment documents, but as luck would have it, DT had to perform COVID-19 risk assessments for the office in the event that staff required access. I was able to use this data to test my ability to model a risk assessment.

This led to the creation of my first MDG, RiskResolve. It is a very simple MDG with a set purpose. Define a goal (e.g. use of the office during pandemic conditions), then identify the different activities that are required to achieve that goal and further narrow that down to the individual tasks that would make up such activities. From there, I could then identify the risks associated with any of these items. This formed the top level of my model as the Risk Identification Diagram (RID) and using abstraction, I could then drill-down into the identified risk elements to the next view, the Risk Resolution Diagram (RRD). In this view, our identified risk is comprised of elements called instigators and then we have our resolution elements, which detail how an instigator is addressed to alleviate risk. These are connected via association.

Here are the example patterns I have built into the MDG:

RID Pattern

RRD Pattern

With the MDG working and me able to generate a document from it to form a risk assessment, I was very happy, but soon I got to thinking about using Shape Scripts to enhance the visuals of the model.

What is a Shape Script?

Sparx Systems talk about Shape Scripts as follows:

“As Shape Scripts are associated with stereotypes, you define them through the ‘Stereotypes’ tab of the ‘UML Types’ dialog; each stereotype can have one Shape Script.”

In plain terms, you can define how EA renders your elements by writing a Shape Script for each of them.

Not content with making things easy on myself for a first attempt at writing a Shape Script, I decided that I would like have my Associated Risk elements on the RID diagram rendered as triangles. This would overwrite the default visuals that the element is inheriting for the stereotype on which it is based.

Here is the Shape Script:

The Shape Script draws the shape by way of you plotting out how EA will draw the element within a given rectangular shape:

Here are the results:

As you can see, this is a less than ideal shape for what I need. The element name in this example simply cannot fit within this shape unless I were to attempt to position the name at the bottom of the shape, but even then I would still need space to render other information such as the associated tagged value to tell me who is at risk and display the composite link icon.

I also performed a similar experiment on the RRD, here are the results:

This is what it should look like: 

Whilst you can create a Shape Script that displays the relevant compartments (see below), it is very difficult to create the required subshapes for anything beyond a rectangle.

This is especially true given that we can just use the inherited appearance of the metaclass to which we have assigned our stereotypes. From there we can achieve the same by adding attributes such as ShowNotes=1; and ShowTags=1; our diagram profile to achieve the same:

In my example, I need only to publish particular compartments. However, should I need to display the attributes of an element, I cannot do this with a Shape Script and we are back to using the inherited appearance of the metaclass.

Conclusion

I guess through a combination of my experimentation and the visual examples above we can draw the following conclusions:

1. EA provides us with an extremely useful and powerful functionality allowing us to create our own metamodels
2. These meta models can be further customised through the use of Shape Scripts
3. A Shape Script can be set to react to certain conditions e.g. Tagged Values and Properties (like Rectangle Notation and Composite)
4. Creating these Shape Scripts can be time consuming and there are limitations to what they can do

From all of this I guess my advice would be to use a Shape Script if you are desperate to change the shape of your element stereotype, just beware of the time required to create some of the more wacky shapes and have them display your required data on the model.

The Problem

A project chartered to deliver an IT-based solution typically begins with establishing high-level functional requirements (HLRs) which are eventually followed up with detailed functional requirements (DTRs). The problem is that there have never been clear guidelines for what constitutes ‘high-level’. And when it comes to DTRs, there are no guidelines for how much detail there should be in a given requirement statement, making it difficult to check for overall completeness and/or redundancy.

The Solution

The solution to the HLR problem is to recognize that there are five fundamental capability types for adding domain-specific functionality on top of a data management capability. A given high-level functional capability should be viewed as one of the following:

• A Report
• A User Interface
• A Data Import
• A Data Export
• An Automated Function (e.g. ‘batch job’)

A given HLR should only identify who it is that needs a specific one of those types. A properly high-level HLR should contain no ‘field-level’ details.

The solution to the DTR problem is to recognize that for each of the above five types, the necessary detail can be captured in a ‘structured’ format rather than in textual requirement statements. A single DTR, containing no more detail than its corresponding HLR, should be sufficient as an aggregation point for the capability’s structured details.

The RIC MDG Technology provides that structure. It extends the Enterprise Architecture concept of Requirement, and adds additional stereotypes to capture the detail.

The Trips-R-You Web-Based Flight Reservation System case study shows examples of HLRs, DTRs, and spreadsheet-based templates structuring the example details for each of the five capability types. The RIC extensions are described in the article Tool Support for Requirements [In Context]. Documenting functional requirements for an information system-based solution using Requirements In Context format is described in detail in the Requirements In Context Series of Articles.

NOTE: Any questions or problems with the RIC MDG Technology please contact the author.

We have developed a MDG for the (Batch) process industry based on ANSI/ISA S88 standard and extended with the capability to create Piping and Instrumentation diagrams (P&ID) and Functional Block diagrams (FBD).

The Physical model

Physical model toolbox support in the ISA88 Physical layers like Area, Process cell, Unit, equipment module and control module. For example a Physical elements like a Unit can be part of or shared within a Process cell. The toolbox support in different process flows like liquid, gas and steam.

The Physical model and Procedures

The Procedure Toolbox support in the development of Procedure models with elements like Operations, Phases and Actions. Flow between  elements in these Procedure models can be created as control flows or conditional control flows. The flow can also be extended with Material flows.

Procedures en recipes

The Recipe Toolbox support in creating Recipe models. Within the Recipe models, Recipes can be extend with additional information and parameters. Recipes can be related to other Recipes by reference or copy.

Physical model and P&ID’s

Physical models are transformed to a Piping & Instrumentation model (P&ID) by using the PID toolbox. An P&ID diagram is realized as a composite diagram of a Unit, Equipment module or Control module.

The toolbox contains P&ID objects like valves, vessels, instrumentation and pumps.

P&ID’s and process automation

Objects like motors, valves, vessels and instrumentation need to be monitored and controlled. The IEC61131 describes Functional Block diagrams (FBD). The FUP Toolbox support the creation of FBD’s. An FBD is implemented as a composite diagram of P&ID element. But can also be related to Actions defined In Procedure diagram.

 Jan de Liefde

This email address is being protected from spambots. You need JavaScript enabled to view it.

Using Stereotyped Relationships to Define Quicklink rules

by Phillip Chudley, Principal Consultant at Dunstan Thomas Consulting

Background

One of my favourite features of Enterprise Architect (EA) is the ability to define your own meta-models using MDG technology, and over the many years I have used Enterprise Architect, I have developed many such MDGs and have shared my experiences in their development at numerous EA User Group meetings.

However there has always been a “sting in the tail” with developing an MDG in the respect of defining Quicklink rules. These were (and can still be) defined using a spreadsheet where each row defined a connector between two elements for a specific diagram. Not only was this tedious, but also prone to error and not that intuitive.

With the arrival of EA version 14 and in particularEnterprise Architect version 14.1 a new method of defining Quicklink rules was introduced. This new method uses Meta-relationship, Stereotyped relationship and metaconstraint.

In this article I will explain through a simple example MDG how to use Stereotyped relationships to define Quicklink rules.

Example Meta-model

For this example a simple three element meta-model will be used and this is illustrated below together with the relationships that are defined between these three elements:

Plan of Attack

To experiment with the new features of MDGs, the following steps were used:

1. Create a locally hosted model repository for the MDG model.
2. Using the MDG Builder structure, model the profile, (including any Tagged Values and Shapescripts), model the custom toolbox(es) and model custom diagram(s) connecting them with the appropriate toolboxes.
3. Generate the MDG.
4. Test the MDG.
5. Using a separate diagram model the view specifications.
6. Regenerate the MDG.
7. Test the view specifications.
8. Using a separate diagram model Quicklink definitions using Meta-relationships / Stereotyped relationships.
9. Regenerate the MDG.
10. Test the Quicklink definitions.

Steps 1) through 4) are pretty much standard for the development of an MDG and hence will not be described in detail, however some important inclusions and “gotchas” will be described.

The complete EA Model and the MDG XML file are available for download.

The MDG Profile Model

The diagram below illustrates the profile model for the elements and relationships defined in the meta-model shown previously:

Notes

The following should be noted:

1. The attribute named _HideUmlLinks of type Boolean and default value of True is necessary so as to prevent all the UML Quicklinks from the metaclass (in this case Class) being listed with your defined Quicklink definitions. This will have no effect until such Quicklink definitions have been included in the profile model. This attribute is added manually to the metaclass.
2. The attributes named _MeaningForwards and _MeaningBackwoods for the metaclasses Association, Generalization and Composition are used to provide names for the Quicklink definitions. That is the names that will appear in the Quicklink menu. _MeaningForwards is the Quicklink name for Source to Target, whereas _MeaningBackwards is the Quicklink name for Target to Source. These values, along with the attributes named _linestyle and _direction can be defined using the Profile Helpers.
3. Tagged Values named DateIndentified (type Date) and CauseDetails (type Memo) have been defined and added to the stereotypes Problem and Cause.
4. All three elements have a basic Shapescript (shown in the table below in case you would like to create the MDG from scratch), and have Toolbox / Project Browser icons defined. These icons are optional, but are included in the MDG XML file available for download, however if you use the EA model, then you will have to exclude the icons in the stereotyped elements and toolbox prior to generating the MDG.
   
   
5. EA version 14.0 moved many of the familiar right-click menu options to the Ribbons, and generating profiles for packages and diagrams is no exception. To generate a profile from a package or diagram:
   • For a Profile Package:
     • Select the Package containing the profile in the Project Browser.
     • Select Publish → Publish Package as UML Profile from the Technologies section of the SPECIALIZE ribbon.
   • For a Diagram that models a custom diagram, or custom toolbox:
     • Open the diagram containing the model of the custom diagram or custom toolbox.
     • Select Publish → Publish Diagram as UML Profile from the Technologies section of the SPECIALIZE ribbon.
     • When the dialog opens, there is no value in the Version text field. Due to an issue in EA 14.1, this must have a value (I usually set this to the same value as the version used when generating the MDG). Failure to enter a value for the version, will result in the XML files for the diagram profiles to be missing from the MDG generation dialogs.

The following diagrams illustrate the models for a single custom toolbox and a custom diagram provided for reference for the MDG example used in this article.

Example; Custom Toolbox

Example; Custom Diagram

The attributes in the Diagam_Custom metaclass are:

• Show Qualifiers & Visibility Indicators – False
• Show Tagged Values Compartment – True
• Hide Attributes Compartment – True
• Hide Operations Compartment – True
• Hide Connector Stereotype Labels – True

NOTE: Due to the simple Shapescript used for the elements within the profile, the attributes for the compartment visibility will have no effect.

Using Stereotyped relationships to Define Quicklink Rules

In Enterprise Architect version 14, two new items were added to the development of MDGs, these are:

• Meta-relationship – used to define a Quicklink rule between stereotyped elements defined in an MDG using UML Connectors.
• Stereotyped relationship - used to define a Quicklink rule between stereotyped elements defined in an MDG using Stereotyped Connectors defined in the MDG

In my experiments with these new items, I discovered that Meta-relationships worked when used to defined Quicklink rules between different MDG stereotypes, but did not appear to work when used to define Quicklink rules between the same MDG stereotype (that is a self-relationship). Hence the reason why in this example I have defined MDG stereotypes for Composition and Generalization and used Stereotyped relationships exclusively to defined Quicklink rules.

Defining the Quicklink Rules

Using a new Profile diagram with the same package as where the MDG Profile is defined, simply:

• • Re-use the MDG Stereotype element (or elements) for which a relationships is required.
  • Using the Metamodel section of the Profile Toolbox create a relationship for each valid connection between these MDG Stereotyped elements, including any self-relationships.
  • Set a tagged value named stereotype to the name of the MDG stereotyped relationship that is valid in this context.

The diagram for the Meta-model used in this diagram is as shown below:

The profile package is then saved as a UML Profile and the MDG re-generated. Upon testing, and using the Quicklink the result is as shown in the example below:

If, when using the Quicklink an attempt is made to create a connection between any two elements that do not have a Stereotyped-relationship defined (as between Cause and Solution), no connector will be allowed.

NOTE: The rules defined using Stereotyped-relationships only apply when using the Quicklinker, these rules can be broken by using any relationships visible in the toolbox.

Therefore, to fully enforce relationship rules, define all relationships using Stereotyped-relationships and do not provide any relationships in the diagram toolbox.

Conclusion

Does using Stereotyped-relationships ease the pain of Quicklink defintions? In my opinion, most definitely yes!

Accompanying this tutorial, is a zip file containing:

• The model used to define the example used in this tutorial. This is an .eapx file.
• The MDG XML file as generated from the model.

I hope this example is useful to all those of you who develop MDGs for Enterprise Architect and I welcome your feedback.

My next article will explore the other new features for MDGs, namely:

• View Specifications
• Metaconstraints

Follow me on Twitter @SparxEAGuru

Sparx Services North America launches new offerings to support the BIZBOK® Guide for Business Architecture

Sparx Services North America is pleased to announce a new set of training, consulting and technology offerings aligned to the BIZBOK Guide to support the Business Architecture discipline.  Business Architecture is an essential part of companies’ digital transformation and operational excellence strategies - weaving together people, processes, information and technology in support of strategic vision and operational objectives. A Guide to the Business Architecture Body of Knowledge® (BIZBOK Guide) from the Business Architecture Guild® represents the generally accepted standards of practice for the Business Architecture discipline.

BIZBOK Training Offerings

Whether you are a new or aspiring Business Architect seeking to learn the fundamentals of the role; a seasoned Enterprise, Business, Information or Systems Architect looking to add the BIZBOK methodology to your toolbox; or a company that uses Sparx Enterprise Architect today and are looking to bring best-practices into your architecture function – the BIZBOK training offerings from Sparx Services North America, a Guild Accredited Training Provider®, can help provide the skills you need to succeed.

BIZBOK Foundation: A 3-day course covering the core framework content of the BIZBOK to help students prepare for the Certified Business Architect® exam from the Business Architecture Guild.

Sparx Enterprise Architect BIZBOK: A 2-day course to help students understand how to use Sparx Enterprise Architect (the industry leading EA tool) to support Business Architecture activities as outlined in the BIZBOK.

BIZBOK Essentials: A 5-day course that combines the framework and essential concepts from the BIZBOK Foundation course with the practical application and tooling guidance from the implementation course into an intensive overview to give students the knowledge and skills to apply the BIZBOK in their daily work. 

Business Architecture Alignment and Integration: A 2-day course focused on leveraging the BIZBOK concepts to integrate Business Architecture with existing EA, Business Analysis and Solution Delivery functions.

BIZBOK Consulting Offerings

As active contributors to the Business Architecture Guild, the architects from Sparx Services North America understand how to apply the BIZBOK framework and methods within the context of a company’s EA/BA practice along with best-practices for configuring and using Sparx Enterprise Architect to support the BIZBOK methods.

Coming Soon! BIZBOK Extension for Sparx Enterprise Architect

Sparx Services North America will soon be releasing a new BIZBOK Extension (MDG Technology) for the Sparx Enterprise Architect platform - providing pre-configured objects, data models and templates to enable Business Architects to quickly perform techniques direct from the BIZBOK using the industry leading EA tool, Sparx Enterprise Architect.

To learn more about the BIZBOK offerings from Sparx Services North America, visit www.sparxsystems.us/bizbok or contact one of our BIZBOK experts at  This email address is being protected from spambots. You need JavaScript enabled to view it.

Business Architecture Guild, BIZBOK, A Guide to the Business Architecture Body of Knowledge, Certified Business Architect, CBA, Guild Accredited Training Program, and GATP are trademarks or registered trademarks of the Business Architecture Guild. Sparx Systems, Enterprise Architect, MDG Integration, and MDG Technology are trademarks or registered trademarks of Sparx Systems Pty Ltd

During his time as an Enterprise Architect consultant, Jan van Oort trained numerous SparxSystems Central Europe customers eager to improve their modeling skills and methodologies. When he co-founded the startup KIVU in 2016, he naturally introduced Enterprise Architect there as well, which quickly became a key development tool. KIVU Technologies is a provider of scalable software for network analysis which is currently in demand, not only in the security sector.

In times of increasing monitoring and collection of mass data, KIVU is an exceptional example. Using well-designed software, KIVU enables the analysis of networks (not just social networks) from known nodes. The software is designed to assist analysts in narrowing down their data and connections to relevant, manageable networks, enabling them to focus on pertinent content and behaviour at greater speed.  Jan van Oort, Chief Engineer of KIVU: "As a former Enterprise Architect Trainer, I recognized the potential of model-based development right from the start of our project. Enterprise Architect supports me mainly in three key areas: Requirements definition, communicating with investors and customers, and presenting our project at events.”

As a result, KIVU recently completed a seed financing round of EUR 1.8 million and is thus able to push ahead with its development. Hans Bartmann, Managing Director at SparxSystems Software Central Europe: "We congratulate KIVU on a successful financing round. At the same time, we are pleased that one of our former trainers is now leveraging the potentials of model-based development to create a data-protection-friendly network analysis platform. This approach combines many positive aspects and has the best prerequisites for an international victory from Austria."

Requirements are easily defined in the model

“The KIVU platform consists of two parts: a graphical user interface (GUI) and a database (backend server) called TARIM. Right at the start of the development of TARIM, I realized that the requirements defined here had to be clearly understandable for every developer. A model is ideal for this purpose, because it allows requirements to be defined graphically, regardless of how the programming based on it is handled," explains van Oort. Based on this requirement shown in the model, a programmer creates source code, which is then stored in a version control system (Github). In this way, van Oort can always keep track of whether a requirement has been successfully completed or whether subsequent improvements are necessary.

While the Chief Engineer deliberately does not oblige the programmers to work with the model-based approach, they still see the benefits. “As our GUI has continued to grow over the past year, the developers recently asked me if they could work with Enterprise Architect, not least due to the fact that over 40,000 lines of code can very practically be handled in a single model.” The first model (database) has therefore now been merged with the second model (GUI). The GUI is created in JavaScript, has to run in every current browser and allows the display of different views. It has a connection to the database at any time in order to be able to display changes immediately.

Since the platform is designed for the throughput of large amounts of data (social networks, telephone, time or bank data, etc.), all analyses are carried out in the database. This relieves the GUI and ensures that the displays are always current. By using special filters, only highly relevant data is analyzed. “Our data processing and filtering must be very transparent in order to be able to disclose it at any time should we be requested to do so by the authorities. On the one hand, we must guarantee the required level of data protection, while providing a powerful network analysis tool on the other,” explains van Oort.

Due diligence mastered with modeling

These days, a ‘technical due diligence’ examination is usually required on the way to start-up financing. An external expert assesses whether the start-up can really perform the service as claimed. KIVU also had to take this step, but did not want to disclose its own source code. “I can only recommend to any software start-up to use a model for this purpose. Since our Bulgarian auditor works with Enterprise Architect himself, we were able to use shared model views to successfully and quickly complete the audit via the Internet,” van Oort emphasizes. Last but not least, the KIVU team uses the views from the model in lectures, most recently at the first VÖSI (Austrian Software Industry Association) Software Day in Vienna. “We usually show our approach at security conferences in front of developers who of course want to see something concrete and understand the interrelationships. With the help of model views, this is no problem.” The views can be varied according to the target group, which significantly increases the comprehensibility and effectiveness of the presentations.

Image 1: The KIVU team (from right to left): in front, Christian Weichselbaum, Daniela Klimpfinger, Julia Franciotti; in back, Robert Wesley, Jan van Oort (in a white t-shirt) and Frazer Kirkman in back.

Image 2: The TARIM database developed by KIVU

(All images ©KIVU Technologies)

Image 3: This image represents the top layer of  the KIVU API  in the form of UML / Java interfaces, as well as the "tip of the iceberg" with regard to the API's actual implementation.  Concrete classes will often appear in one or more sequence diagrams. These diagrams (the associated code) are what developers at KIVU get to work with. The interfaces are round-trip engineered against the source code: a modification by the Chief Engineer on one side (code or model) results into an update at the other side, and forces the developers to implement it. All the while, the Chief Engineer doesn't need to look at implementation details, although at any time he can reverse-engineer the implementation source code into the model. Similar diagrams exist of protocol layers, specific parsing utilities etc. etc.  

About KIVU Technologies

KIVU Technologies is a provider of scalable software for the analysis of networks in the security sector and beyond. The company was founded in 2016 in Vienna by Robert Wesley, Jan van Oort and Christian Weichselbaum, and recently received seed financing of EUR 1.8 million. Austrian aws Gründerfonds and btov Partners led the financing round with the participation of APEX Ventures. In addition, Ewald Hesse and Louis Curran are supporting the start-up as angel investors. The KIVU team consists of engineers, developers, data scientists, analysts and security experts.

http://kivu.tech/

About Sparx Systems

Sparx Systems was founded in Australia in 1996 and is the producer of Enterprise Architect, the world’s premiere UML modeling platform. Enterprise Architect is used to design and produce software systems, business process modeling, and modeling of any process or system. Enterprise Architect has been implemented by over 650,000 users due to its high performance at an unbeatable price. Enterprise Architect is an easy-to-understand, team-based modeling environment that helps organizations analyze, design and create well-documented systems precisely and comprehensibly. It also allows companies to collect and present the often distributed knowledge of teams and departments.

In order to support customers in their own language and time zone, SparxSystems Software Central Europe was created in 2004 to provide for the entire German-speaking region with software licenses, training and consulting.

You can find more information at www.sparxsystems.eu

This article shares an MDG Technology that integrates Sparx Enterprise Architect UML models with JHipster.

VISEO EA UML to JHipster Generator MDG produces JDL (JHipster Domain Language) content from UML models maintained in Enterprise Architect. This output can be used in JHipster to create the application's entities, including properties and relations.

Not being able to find a suitable tool that generates JHipster entities from UML models, I started such integration for a software application that has been implemented with JHipster 2.

Note: the current version of the MDG is compatible with JHipster 2, latest available version when the project started. JHipster 3 new features could be integrated in a future version.

Context

A modelling project has been launched with Enterprise Architect to gather and maintain all the information and knowledge related with the project for the development team and stakeholders.

The initial models included business classes to identify the concepts, shared through a visual representation with UML. This approach has been useful when integrating these concepts in the technical environment JHipster.

JHipster, or “Java Hipster”, is a handy Open Source application generator that aims to create a complete and modern Web app:

• A high-performance and robust Java stack back-end (Spring Boot, Spring Security, Spring Data, Spring MVC, etc.)
• A sleek, modern, mobile-first front-end (Angular.js and Bootstrap)
• A suite of pre-configured development tools like Yeoman, Maven, Gradle, Grunt, Gulp.js and Bower

UML to JHipster JDL generator

Overview

Defining class models on both business and technical layers enabled a proper integration of the business definitions in the software application. Design workshops were carried in an efficient manner through the use of a common language and tool (Sparx Enterprise Architect and UML).

Looking for existing integration solutions between UML tools and JHipster yielded XMI exports/imports. However XMI implementations in UML tools don't provide most of the time a proper and full exchange of UML models i.e. without loss or modification of definitions. JDL Studio looked interesting; this online tool renders an entity diagram matching the JDL content. The downloaded file can be used to generate entities in JHipster (command line example: "yo jhipster:import-jdl export-jdl-uml.jh").
Without a suitable link between Enterprise Architect and JHipster, I wrote a script that generates such content directly from Enterprise Architect models. It requires the following JHipster 2 customizations carried in Enterprise Architect:

• Data types: JHipster types are available for the entities' attributes.
• UML profile: stereotypes on UML classes and attributes to provide JHipster properties via tagged values, listed below.
  • Classes
    • jhipsterDto : use mapstruct for the DTO-entity mapping
    • jhipsterPaginate : pagination choice for lists (infinite-scroll, pager, pagination)
    • jhipsterService : apply serviceClass to the entity
  • Attributes
    • jhipsterisRequired : the attribut is required
    • jhipsterMin: provides the minimum value (declared as minlength for String attributes, or min for Integer, Long, Float, Double, or BigDecimal attributes)
    • jhipsterMax: provides the maximum value (declared as maxlength for String attributes, or max for Integer, Long, Float, Double, or BigDecimal attributes)
    • jhipsterPattern: provide the pattern value for a String attribute
  • Script: generates the JDL content

The following UML class diagram illustrates the meta-model applied for the UML to JHipster 2 JDL integration:

The script and UML profile have been improved through users' feedback and reviews from JHipster experts at VISEO.

Installation

The EA UML to JHipster MDG is published via an XML file. Once installed, it is listed in the MDG Technologies screen:

Note: this MDG is available on request (e-mail: jhipster[at]umlchannel.com).

JHipster diagram and toolbox

EA/JHipster MDG Technology supports a diagram with its toolbox to create stereotyped classes and attributes:

UML profile and JHipster stereotypes

EA/JHipster MDG Technology includes a UML profile with stereotypes on classes and attributes to provide relevant Tagged Values.

When starting a JHipster design class diagram, JHipster entities contain tagged values available from the JHipster tab: DTO, paginate, service. The "none" value is set by default so all tagged values are optional.

The JHipster entity "Language" field is set to JHipster so its attributes are associated with the JHipster data types list.

The diagram toolbox can be used to add a stereotyped attribute to a JHipster Entity class. Such attributes also contains properties from the Tagged Values tab:

UML to JHipster generation script

The following UML class diagram has been defined with Sparx Enterprise Architect based on the JDL Studio example. This model provides a mean to check that the generated JDL content from either solution matches.

Compared with the JDL studio diagram, UML class diagrams have the advantage of being based on the OMG standard. Furthermore using a tool like Sparx Enterprise Architect provides a way to maintain the entity design model within a complete modelling repository e.g. including requirements, business, analysis and architecture models.

The following JDL content has been generated using this script:

=== EA UML to JHipster Entity Export ===
== More information is available from www.umlchannel.com/jhipster ==
INSTRUCTIONS: copy and paste the following content in a text file, and rename it e.g. as dpl.jh =
entity Department {
departmentId Long,
departmentName String required
}
entity JobHistory {
startDate ZonedDateTime,
endDate ZonedDateTime,
language Language
}
entity Job {
jobId Long,
jobTitle String,
minSalary Long,
maxSalary Long
}
/**
* The Employee entity.
*/
entity Employee {
employeeId Long,
/**
* The firstname attribute.
*/
firstName String,
lastName String,
email String,
phoneNumber String,
hireDate ZonedDateTime,
salary Long,
commissionPct Long
}
entity Location {
locationId Long,
streetAddress String,
postalCode String,
city String,
stateProvince String
}
entity Task {
taskId Long,
title String,
description String
}
entity Country {
countryId Long,
countryName String
}
entity Region {
regionId Long,
regionName String
}
enum Language {
FRENCH, ENGLISH, SPANISH
}
relationship OneToOne {
Department{location} to Location
}
relationship OneToMany {

/**
* A relationship
*/
Department{employee} to
/**
* Another side of the same relationship
*/
Employee
}
relationship OneToOne {
JobHistory{department} to Department
}
relationship OneToOne {
JobHistory{employee} to Employee
}
relationship OneToOne {
JobHistory{job} to Job
}
relationship ManyToMany {
Job{task(title)} to Task{job}
}
relationship ManyToOne {
Employee{manager} to Employee
}
relationship OneToMany {
Employee{job} to Job
}
relationship OneToOne {
Location{country} to Country
}
relationship OneToOne {
Country{region} to Region
}
paginate JobHistory, Employee with infinite-scroll
paginate Job with pagination
dto Job, Employee with mapstruct
service Employee with serviceClass

The final step involves copying this content to a JH file, and use it in JHipster to generate entities.

Scope

This approach was used as a mean to easily generate new versions of the design entity model within JHipster. Updates were carried in Enterprise Architect to remain consistent with the business model, whilst being generated, tested and approved directly in the application.

Once entities are updated in JHipster with custom code, it prevents any synchronization with the UML model. Where a full synchronization between the JHipster and UML projects is not the final purpose of this MDG, it allows having a design model that matches exactly the entities definition in the development environment during the first iterations of the project. This level of information in the design layer is very useful, even if mismatches with the code are bound to occur. The design team may chose to manually update the UML design model when needed.

Future versions

This MDG has been implemented and used with JHipster 2. A future version could be released to support JHipster 3 that has introduced new properties such as:

• new serviceImpl service
• new syntax e.g. "dto (ou service ) * with … except …"
• skipClient and skipServer declaration on entities
• angularSuffix
• Microservices (e.g. microservice with <jhipster app name>)
• elasticsearch search on entities (e.g. search * with elasticsearch except …)
• New types (AnyBlob, ImageBlob)
• Generate minbytes and maxbypes for blob attributes( Blob, AnyBlob, ImageBlob)