Introduction

Straight out of the box, Sparx Enterpise Architect provides support for multiple modeling notations. Using a synergy of notations can result in a better description of business architecture. This article considers how ArchiMate, BPMN and UML can be combined into a model that is focused at a high-level of abstraction, whilst still allowing for some critical details to be explored.

Revealing layers of abstraction

As explained in Marc Lankhorst's book Enterprise Architecture at Work (third edition, p. 117), modeling notations provide a way to represent knowledge. The process of building, sharing and transforming the model can foster a new level of understanding amongst the participants. This refined knowledge is (at least) as valuable as the resulting model artifacts (the representation). Effective communication of that knowledge requires consideration for the target audience and an appropriate level of detail.

ArchiMate is good for:

• People who have a job title like Enterprise Architect or Business Architect.
• Presenting high-level and layered abstractions of the business itself, along with the software and technology that are used to support it.
• Tracing and illustrating how the motivating strategy is realised by the business.
• Planning the evolution and transformation of a business.
• Supporting concepts that are similar to those found within TOGAF.

By design, the ArchiMate 2.1 specification does not (explicitly) provide for detailed:

• Business process modeling
• Data modeling

Meanwhile:

• BPMN (Business Process Modeling and Notation) is focused on the detailed modeling of business processes; naturally enough, BPMN is increasingly used amongst the Business Analyst community.
• UML Class diagrams may be used to detail data types, along with the relationships between data types; they are widely recognized amongst software developers, and a good alternative to using entity relationship diagrams for logical data modeling.

Coordinating multiple notations in a single model repository

UML is the native metamodel and notation of Sparx Enterprise Architect. Each additional notation (such as ArchiMate and BPMN) is provided as a MDG (Model-Driven Generator) technology within the tool. The UML specification provides for semantic extension of the UML through the mechanism of Profiles, Stereotypes and Tagged Values. Profiles are the heart of each MDG Technology, enhanced with Sparx tool specific details supporting new types of diagram notations and diagram toolboxes.

Using multiple notations within a single repository requires a disciplined approach in order maintain clarity. In brief, the best practice is to:

• Restrict the elements of each notation to a separate root node.
• Use the UML «Trace» dependency to provide an elegant way of relating elements belonging to different notations.

Add root node to your Sparx Enterprise Architect repository

You might not have realised that the File|New Project… menu option is something of a misnomer. Both EAP and FEAP files are actually self-contained model repositories, and can therefore contain multiple root nodes (just like a RDBMS hosted shared repository, whether accessed through an ODBC or Cloud connection). As a reminder, you can add a new root node into a repository by performing the following steps:

1. If necessary, click View|Project Browser to open the Project Browser window.
2. Right-click inside the blank (white) area of the Project Browser window and then click Add|Add Root Node….
3. The Create New Model (root node) window is displayed. Type MyCorporation (ArchiMate) into the Model Name field.
4. In a similar way, create root nodes for:
   • MyCorporation (BPMN)
   • MyCorporation (UML)

Create a «Trace» dependency between elements belonging to different notations

As stated in the Unified Modeling Language 2.5 specification (p246):

"Models can have Abstraction Dependencies between them: refinement (stereotyped by «Refine» from the Standard Profile) or mapping (for example stereotyped by «Trace» from the Standard Profile). These are typically represented in more detail by Dependencies between the elements contained in the Models. Relationships between elements in different Models generally have no direct impact on the contents of the Models because each Model is meant to be complete. However, they are useful for tracing refinements and for keeping track of cross-references between models."

ArchiMate for an architectural understanding

For example, an ArchiMate Business Process Viewpoint diagram for Purchase Item might look as follows:

This provides a high-level overview of a core business process, with enough detail to inform stakeholders and decision making at a whole-enterprise level of abstraction.

BPMN for detailing business processes

BPMN can be used to detail the ArchiMate Business Process concept, as follows:

UML for detailing the data entites

UML Classes can be used to detail the ArchiMate Business Object concept, as follows:

Usually, diagrams should only contain a single notation. In the examples above, multiple notations are deliberately used to visualise «Trace» dependencies between the ArchiMate, BPMN and UML elements.

How-to add «Trace» dependencies between elements model elements

Best practice for adding «Trace» dependencies using a diagram is to:

1. Temporarily add the required elements of the foreign notation to a diagram.
2. Draw the «Trace» depencies between elements.
3. Remove the foreign notation elements from the diagrams, whilst retaining the traceablity links within the model repository. (So, delete the foreign elements from the diagram, but NOT the repository).

Alternatively, you could use the Relationship Matrix functionality of Sparx Enterprise Architect (click Tools|Relationship Matrix to get started).

Summary

The UML specified «Trace» dependency (relationship) is an elegant way of tracing between different modeling notations. Sparx Enterprise Architect provides a wide coverage of modeling notations, by leveraging the UML Profiles mechanism, and enhancing it with MDG technologies. In practice, this enables a synergy of the ArchiMate, BPMN and UML notations. Models can be constructed as layered abstractions, moving from one notation to another to suit the level of detail required by the user and intended audience.

A UML/MOF METAMODEL FOR HATLEY-PIRBHAI SYSTEM SPECIFICATION

An UnCOOL situation

Figure 1: Uncool

TeamWork, was a structured engineering tool for requirements documentation and systems design of real-time and embedded software. Sterling Software acquired TeamWork from Cayenne Software way back in October 1998, and subsequently re-named it to COOL:Teamwork. The tool provided (partial) support for building software models as described in the book Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, ISBN 0-932633-11-0.

COOL:Teamwork was used at a number of (public limited) companies, to model products targeted for the aeronautical and military (and maybe other) domains. These products have very long life-cycles (typically 10 years of development, and then three decades of product service). New variants of these products may extend the lifecycle even further. The comparatively fast-moving world of software tools presents a challenge to those seeking adequate long-term support for their tooling. Unfortunately COOL:Teamwork has been unsupported software for many years, and a solution needs to be found for migrating the valuable design and specification models that it contains into modern software tooling.

Constructing a UML/MOF metamodel of Hatley-Pirbhai System Specification, as partially implemented in the COOL:Teamwork CASE tool, was the first step in our development of a robust solution to the model migration problem. If you would like to learn more then please get in contact with us via This email address is being protected from spambots. You need JavaScript enabled to view it.!

A UML/MOF metamodel of Hatley-Pirbhai System Specification

Figure 2: A UML/MOF metamodel of Hatley-Pirbhai System Specification

The Requirements metamodel

Figure 3: The Requirements metamodel

Control Flow Diagram metamodel

Figure 4: Control Flow Diagram metamodel

Control Specification metamodel

Figure 5: Control Specification metamodel

Data Context Diagram metamodel

Figure 6: Data Context Diagram metamodel

Data Flow Diagram metamodel

Figure 7: Data Flow Diagram metamodel

Relationships metamodel

Figure 8: Relationships metamodel

State Transition Diagram metamodel

Figure 9: State Transition Diagram metamodel

System Architecture Model metamodel

Figure 10: System Architecture Model metamodel

Architecture Context Diagram

Figure 11: Architecture Context Diagram

Architecture Flow Diagram

Figure 12: Architecture Flow Diagram

Architecture Interconnect Diagram

Figure 13: Architecture Interconnect Diagram

When to consider the use of ArchiMate?

The Open Group recently released the ArchiMate 2.1 specification; I think that there are five principle reasons to consider using the notation to describe the architecture of your enterprise. By design, ArchiMate is focused toward:

• Providing a high-level of abstraction
• Facilitating the construction of a layered enterprise architecture
• Illustrating how business concepts are supported by IT systems, comprising both hardware and software
• Tracing stakeholder concerns through to their realization by the enterprise architecture
• Showing the possible, and actual, evolution of an enterprise architecture through a number of recognizable intermediate states.

How does ArchiMate handle these things?

Approaching abstraction

In a similar way to modeling notations such as the UML and SysML, ArchiMate relies on a simple but powerful approach to creating a useful abstraction of a complex domain:

• Identify the specific types of things that are pertinent
• Identify the relationships between the types of things
• Provide a graphical notation to illustrate the above

Types of concept

ArchiMate divides the specific types of things to be modeled into three core layers:

• Business concepts (including actor, role, function, process, service and interface)

Figure 1: A subset of the business layer concepts

• Application concepts (including component, function, service and interface)

Figure 2: A subset of application layer concepts

• Technology concepts (including device, system software, function and interface)

Figure 3: A subset of the technology layer concepts

ArchiMate supplements the core types of things with two extensions for:

• Motivation (including driver, goal, requirement, principle and constraint)
• Implementation and migration (work package, deliverable, plateau and gap)

Relationships between concepts

ArchiMate specifies ten types of relationship that may be used between elements:

• Composition
• Aggregation
• Assignment
• Specialization
• Realization
• Used by
• Access
• Association
• Triggering
• Flow

Direct relationships

ArchiMate specifies the set of valid relationships that may exist between concepts. Relationships are restricted for both concepts belonging within a single core layer or extension, and also across layers. The detailed specification of all valid relationships between types is tabulated in Appendix B: Relationship Tables of the ArchiMate 2.1 specification (ISBN 978-94-018-0003-7).

Figure 4: A syntactically (but not necessarily semantically) correct example showing all the available ArchiMate relationships

Derived relationships

ArchiMate also specifies rules for abstracting over a chain of relationships between three or more concepts:

Transitively applying this property allows us to replace a “chain” of structural relationships (with intermediate model elements) by the weakest structural relationship in the chain. – p. 94, ArchiMate 2.1 specification

Figure 5: A chain of relationships, along with the derived relationship

How using an ArchiMate modeling tool can help

In theory, it is not necessary to use a dedicated modeling tool in order to draw ArchiMate diagrams. You could create a custom stencil with Microsoft Visio (for example) containing all the basic shapes of the elements and relationships. However, a good modeling tool can be used to positively enhance both:

• Productivity in creating models
• The correctness of the models

Both enhancements depend on automated model validation, at either the syntactic or semantic level.

Checking for errors in direct relationships [enhance correctness]

Ideally, your modeling tool should not allow you to draw an invalid relationship between two concepts in the first place. This can be prevented a priori whilst creating the initial drawing, by greying out or eliding the options to create invalid relationships. Alternatively (or additionally), the modeling tool can validate the relationships between elements within each diagram, highlighting where invalid relationships have been made, and suggesting valid alternatives.

Automatically deriving relationships between elements [enhance productivity]

Due to ArchiMate’s rules for abstracting over a chain of relationships, your modeling tool should be able to insert a correctly derived relationship between any two elements in a diagram, or at least inform you that no relationship can be derived at all.

Automating ArchiMate viewpoints

ArchiMate specifies twenty-six viewpoints that may be constructed using different combinations of element types and relationships. Ideally, your tool should be able to:

• Validate any viewpoint(s) that you have already created. [enhance correctness]
• Provide automated assistance with creating new diagrams through re-using existing model elements and their relationships. [enhance productivity]

How to do it? Let us help you!

The existing functionality of Sparx Enterprise Architect provides a good basis for fully automating the validation of ArchiMate models. Please contact us at This email address is being protected from spambots. You need JavaScript enabled to view it. if you would like to discuss how you can gain access to our solution.

Introduction

Version 11 of Sparx Enterprise Architect included significantly enhanced reporting facilities. This was worthy of some celebration, and so I contributed an article to the Sparx Community that illustrated the improvements through a couple of UML diagrams. This was quite well received, and resulted in me being featured in a Community Author Spotlight on sparxsystems.com (thanks, Scott)!

Subsequently, Sparx ran a fresh Webinar on the basics of reporting, with more advanced topics to follow.

Emboldened by all this action around reporting on models using the functionality that's already built into Sparx Enterprise Architect, I decided to apply immersive language learning techniques in both the refresh of our classroom based training materials, along with a brand new e-learning course (email us for details via This email address is being protected from spambots. You need JavaScript enabled to view it.). 

So the idea is to enable learning how to use Sparx Enterprise Architect through (UML) pictures. So what does that look like? Here is a taster, based around the "Publish as HTML" functionality of Sparx Enterprise Architect.

Overview of reporting

Sparx Enterprise Architect provides two built-in reporting mechanisms:

• Generate Documentation
• HTML Report 

About Generate Documentation

Generate Documentation is used to publish complete and fully formatted documents that are also suitable for printing in hard-copy. The use of report templates enables a fine degree of control over presentation of contents. Report contents can be selected, searched for and filtered. Sub-templates can be used to include contents based on advanced selections, SQL queries and/or scripted functions.

About Generate HTML Report

HTML Reports are used to publish models as a collection of HTML pages and images, automatically structured into a hierarchy of directories. HTML reports can be shared on a Web server, or conveniently zipped into an archive for distribution via email. HTML reports offer relatively limited support for customizing the report content and presentation when compared with the functionality for Generate Documentation.

Publish as  HTML process

1. You can right-click a package in the project browser, or right-click a Master Document element on a Documentation diagram, to begin publishing a HTML report. 
2. Click Documentation | HTML report. 
3. The Publish as HTML window is displayed. 

About the Publish as HTML dialog

The Publish as HTML window is relatively simple to navigate, assuming a top-to-bottom and left-to-right workflow. Let's get started with a scenario for publishing a basic HTML report.

Generate a HTML report

1. The Publish as HTML window is displayed.
2. Use the keyboard to type something like C:\Users\ccoates\Documents\MyReport into the Output to edit field.
3. Click Generate.
4. Click View.

Example HTML report

Your first report features the content of your model, formatted according to the default HTML template selections. This includes the Sparx Enterprise Architect logo branding. You can now continue to create a custom HTML template that will replace the default logo with customized company branding.

 Customize the header image

The task of adding a custom image logo into your HTML is covered in the following sections:

• Select your header image and re-publish 
• Problem: mismatched image and frame heights 
• Create HTML template 
• Modify the (cascading) style sheet 
• Re-publish and check image 
• The finished HTML report

Select your header image and re-publish

1. Use your keyboard to type something like C:\Users\ccoates\Pictures\example.jpg into the Header Image edit field (alternatively, you could click the ellipsis button and browse for an image file).
2. Click Generate.

Problem: mismatched image and frame heights

You will see that the Dunstan Thomas logo is too large to fit within the available frame. You could just re-size the logo image, but that might contravene the rules set by your companies marketing and branding departments. As a better alternative, you will now re-size the frame to fit around the selected logo image.

Create HTML template

1. Click to expand the Document Generation | Web Style Templates node.
2. Right-click Web Style Templates; a menu is displayed.
3. Click Create HTML Template.
4. Use the keyboard to type MyReport into the Enter Value edit field.
5. Click OK.

Modify the CSS (Cascading Style Sheet)

Change height of .IndexBody

1. The HTML and CSS Style Editor window is displayed. 
2. Click the CSS - Main item in the list of Templates. 
3. Press Control-F on your keyboard to start a text search, and then type ".IndexBody" and the enter key; refer to the section below about Find and replace, if you need more help. 
4. Use the keyboard to replace top: 61px with something like top: 91px (the actual pixel height will be custom_image_height + 1). 

Change height of .IndexHeader

1. Click inside the Current Modified Template edit field. 
2. Press the Control-F on your keyboard, and then search for the text .indexHeader; refer to the section below about Find and replace, if you need more help. 
3. Change height: 60px to match the height of your selected image, like in the example sequence diagram below. 
4. Click Save. 
5. Click Close. 

Find and replace

1. The Find and Replace window is displayed.
2. Use the keyboard to type .indexHeader into the Find what edit box.
3. Click (to set) the Match whole word check-box.
4. Click the Find Next button.

Re-publish and check image

1. Use right-click to open the Publish as HTML window.
2. Click Generate. 
3. Click View. 

The finished HTML report

The framing of the HTML page has been resized to fit the company logo. This concludes the basic introduction to how to create custom HTML report templates.

Sparx Systems Enterprise Architect version 11 is very close to being released (I am currently using Release Candidate 2), and promises a host of new and improved functionality. It’s a good time to revisit the built-in reporting, and reflect on how the stepwise improvements during the Enterprise Architect 10 release series have been rolled-up into a streamlined user experience…

Improving the dialogue

You can right-click on a model root in the Project Browser and view the improved Generate Documentation dialog window. In particular, you will see that the Generate tab contains some additional fields to enable the easy selection of:         

• Table of Contents
• Stylesheet
•  Cover Page
• Diagram Theme

Figure 1: Generate documentation dialog

Previous versions of Sparx Enterprise Architect already provided a skilled operator with the ability to create all of these things. However, the dialogue changes (along with some other enhancements in the report template editor) are aimed at making things easier and more obvious for operators with beginning and intermediate levels of skill.

Generate documentation, not just RTF

If you click Generate Documentation | Generate | Output Format then you will see that you have options to generate Microsoft Document Format (DOCX), alongside the previously available Portable Document Format (PDF) and Rich Text Format (RTF).

Figure 2: Selecting an output format

You might not be aware that Microsoft has discontinued making enhancements its proprietary RTF specification, and that some new features in Word 2010 and later versions will not save properly into the RTF format. The new format will enable Sparx Systems Enterprise Architect to continue inter-operating with the Microsoft proprietary world.

Your model’s structure can be orthogonal to your project documents

Did you know that your model’s structure need not be dictated by the project reports that you want to generate? You can use Documentation Diagrams, containing Master Document elements, to coordinate Document Model elements and/or Template Fragments into producing production ready project documentation.

Figure 3: Overview of documentation elements

Model Documents can act as drag-and-drop targets for packages from the Project Browser, or get populated by user defined element searches, to create individually formatted sections for your documents. Fine grained control over document subsections can achieved through using Fragments, which can use custom templates, scripts (either JavaScript, JScript or VBScript), or SQL queries. Each Model Document can be formatted using a custom template, if required.

Exploring the rich report generation functionality of Sparx Enterprise Architect version 11 can take some time, and creating advanced custom templates can be quite a specialized task. However, it is important to remember that only a few people in your organization might need to develop the skills to create custom templates, whilst everyone else just needs to click through the Generate Documentation dialog, or a pre-prepared Documentation Diagram.

Ideally, you will be able to create a Documentation Diagram containing a Master Document for each of the project documents you need to create. Each document can then be right-clicked and produced on demand.

Figure 4: Example project documentation

Of course, power users of Sparx Enterprise Architect can create a script to produce documentation for the entire project, on demand, with a single mouse click!

Using an external source code editor

Sparx Enterprise Architect can be configured to open source files in an external editor. This is good news for developers who already have a strong preference (and keyboard skills) for using a particular editor, such as Vim or EMACS. Working inside Sparx Enterprise Architect:

1. Click Tools | Options...  
2. The Options window is displayed. Click Source Code Engineering | Code Editors.  
3. Clear the check-box alongside Use inbuilt editor if no external editor set, and then click Close.  
4. Right-click an UML class element (in the Project Browser or on a diagram), and select View Source Code...  
5. The source code will displayed in an external editor window, based on the file association that you have configured for your PC's operating system.

Deep integration with an external IDE

Sparx Systems offers plug-in integrations to support heavyweight commercial IDE's:

• Eclipse MDG Link, priced at $145 to $120 (depending on quantity, current pricing for 13th March 2013).  
• Visual Studio MDG Integration, priced at $199 to $145(depending on quantity, current pricing for 13th March 2013).  

The plug-in integrations are intended for developers who have already made a big intellectual investment in learning a complex IDE, and want to bridge that knowledge into using Sparx Enterprise Architect (for model-driven architecture, development and documentation).

Morgan Kauffmann has published the second edition of “A Practical Guide to SysML” by Sanford Friedenthal, Alan Moore and Rick Steiner (ISBN 978-0-12-385206-9). The authors have made a very complete selection of supporting materials available for download from http://www.elsevierdirect.com/v2/companion.jsp?ISBN=9780123852069. These companion resources include the “Air Compressor”, “Automobile”, “Distiller”, and “Security System” example models, as described in the book. Unfortunately, the model files are only available in MagicDraw tool format (although the authors have also provided HTML reports for use by anyone who do not have access to MagicDraw). I decided to try importing the files into Sparx Enterprise Architect version 10, to support my work at Dunstan Thomas.

After you use a tool like 7-zip (http://www.7-zip.org) to extract the archive, you will see that the files have a “.mdxml” extension. Opening one of them in your favourite text editor will confirm that they are in XML format, based on the XMI 2.1 specification (http://schema.omg.org/spec/XMI/2.1), and also including some proprietary extensions to support the SysML profile (such as http://www.magicdraw.com/schemas/SysML_Profile_Extensions.xmi).

Here is a step-by-step breakdown of how I imported the “Air Compressor” example model into Sparx Enterprise Architect version 10:

1. Despite the proprietary extensions, the model files are basically XMI, and so I simply changed/renamed the file extension from “.mdxml” to “.xml” (changing to “.xmi” also works).
2. Either open a new project in Sparx Enterprise Architect, or at least add a new model into your working repository [right-click in the Project Browser and then select Add Model (root node)…].
3. Rename the model to AirCompressor.
4. Right-click AirCompressor (in the Project Browser), and then click Import Model from XMI…
5. The Import Package from XMI window is displayed.  Click the ellipsis button alongside the Filename field and browse to the “Air Compressor-OMG Style_ReadOnly (from Alan).xml” model file. Did you remember to change/rename the “.mdxml” to “.xml” file extension first?
6. Select Import Diagrams, Write Log file and Import using single transaction, and then click Import.
7. Once the import has been completed, you can close the Import Package from XMI window.

You now have the model imported into Sparx Enterprise Architect, but you need to reorganize the model, and convert the diagrams and model elements to the SysML 1.3 profile. The outline steps for how to do this are:

1. Looking inside the Project Browser, you can see a <<numberOwner>> Data view has been created beneath the AirCompressor model. This view contains two packages, <<model>> Air Compressor Model and MBSE Method, that are useful. There are also several spurious Package or <<profile>> Package elements that can be deleted.
2. Continuing to work in the project browser, right-click AirCompressor and then select Add | Add View…
3. Create each of Behaviour (Dynamic View), Parametrics (Class View), Requirements (Simple View) and Structure (Class View) in turn. Also create a “MBSE Method” (Dynamic View), if wanted.
4. Work your way down through the <<model>> Air Compressor Model package hierarchy, changing each diagram to the relevant SysML 1.3 type. For example:
   1. Open the Figure Map, and then click Diagram | Advanced | Change Type…
   2. The Change Diagram Type window is displayed. Click SysML 1.3, Package, and then OK.
5. Even after converting all of the diagrams to SysML 1.3 types, it is still necessary to synchronize the model elements. To do this work your way through the various SysML 1.3 tool palettes and:
   1. Right-click each element in the SysML tool palette, and then select Synchronize Stereotype if available. The Synch Profiled Elements window is displayed. Click OK.
   2. The Actions list will display a list of the elements that have had new tags or constraints added as a result of applying synchronizing the stereotype.
6. Finally, move the converted elements underneath appropriate Behaviour, Parametrics, Requirements or Structure view. You can then delete any remaining superfluous packages that were created during the import.

Although this importing method is faster than manually recreating the example models from scratch, some manual editing is still necessary to:

1. Fine-tune the layout and look of the example diagrams.
2. Further change some of the SysML 1.3 diagram types to better represent the example models. For example, you can replace an instance of a Constraint Block with a Constraint Property.

In addition, some information does not make it intact through the import process. For example, it is necessary to manually add content into the ID and Text tagged values of the requirement elements. Some of the diagrams do not contain any elements, and this also has to be manually repaired.  Problems of this kind are largely related to each tool vendor’s interpretation of the OMG XMI specification itself, and are typically encountered whenever an attempt is made to move XMI between different implementations.