Enterprise Architect version 13

download
purchase

English Chinese (Simplified) Czech Dutch French German Italian Korean Polish Portuguese Russian Slovak Spanish Swedish

My Profile

Social Media Channels

facebook google plus twitter youtube linkedin

colin.coates

colin.coates

Colin Coates

Dunstan Thomas Holdings Limited (Senior Consultant)
 
I joined Dunstan Thomas Consulting in July 2012 to focus on delivering training and consulting for Sparx Enterprise Architect. My previous experience with UML modelling tools includes IBM Rational Rhapsody, and IBM Rational Software Architect. I also have many years of experience as a software engineer. My primary programming languages have been C++ and Ada, with occasional forays into Java, functional and scripting languages, and SQL. I contribute to the official Dunstan Thomas Consulting blog at http://dthomas-software.co.uk/blog. You can also read my personal, but professional, blog at http://mister-uml.blogspot.co.uk.

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:

 

business-process-viewpoint-purchase-items.jpg

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:

 

bpmn-purchase-items.jpg

UML for detailing the data entites

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

 

logical-data-modeling.jpg

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.!

ElementDescription
EDIF serialization of model The EDIF serialization of a COOL:Teamwork model.
COOL:Teamwork The COOL:Teamwork application.
Sparx Enterprise Architect Sparx Systems Enterprise Architect application.
UnCOOL The UnCOOL application validates the COOL:Teamwork model, then transforms and rebuilds it inside of Sparx Enterprise Architect via the automation API.

A UML/MOF metamodel of Hatley-Pirbhai System Specification

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

ElementDescription
System Architecture Model The system architecture model consists of a layered set of AFDs and AIDs and their associated AMSs and AISs. Each successive layer refines the configuration defined by the higher-level diagrams. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 24
System Requirements Model The System Requirements Model consists of:
  • A control context diagram
  • Control specifications
  • Control flow diagram(s)
  • A data context diagram
  • Data flow diagram(s)
  • Process specifications
  • A timing specification
  • A requirements dictionary
No mention is made of how the process is activated. This is an important part of the information hiding and non-redundancy principles. The PSPEC does not know how or why it is activated, only what to do when it is. Likewise, the CSPEC does not know what the PSPEC does, only how to activate it. The user (who is familiar with the method) know exactly where to look for this information. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 288
System Specification Model The complete system specification model, consisting of the requirements and architecture models, specifies both what the system is to do, and how its design will be structured... The requirements and the architecture models together forming the total system specification model... The system requirements and architecture are interrelated and must be developed in parallel. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 22 and 24

The Requirements metamodel

Figure 3: The Requirements metamodel

ElementDescription
Control Context Diagram The control context diagram establishes the control boundary between the system under study and the environment. It is used to show communication between the system and the environment and the entities in the environment with which the system communications. The control context diagram is the highest-level control flow diagram for the system. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 345
Control Flow Diagram A control flow diagram mirrors the processes and stores form the DFD, but shows control flows instead of data flows. The CFD is constructed simply to constrain the control signals to flow along the same paths as the data signals may flow. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 347
Control Specification (CSPEC) Control specifications convert input signals into output control signals or into process controls. Control specifications have two roles, one to show control processing and the other to show process control. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 350
Data Context Diagram The data context diagram establishes the data boundary between the system under study and the environment. It is used to show the communications between the system and the environment and the entities in the environment with which the system communicates. The data context diagram is the highest-level data flow diagram for that system -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 344
Data Flow Diagram A data flow diagram is a network representation of a system's functional requirements. The system could be automated, manual, or mixed. The DFD portrays the requirements in terms of their functional component parts, with all interfaces among the parts indicated." -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 346
Process Specification (PSPEC) A process specification must be written for every functional primitive process on a data flow diagram. A functional primitive process is defined as a process that is not further decomposed into a child DFD, but is described in a PSPEC. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 349
Requirements Dictionary The requirements dictionary is a ordered list of data and control flow names and data and control store names, each with a definition in terms of its components and structure. Every data flow, control flow, and store on the flow diagrams must be defined in the dictionary down to its primitive elements. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 354
System Requirements Model The System Requirements Model consists of:
  • A control context diagram
  • Control specifications
  • Control flow diagram(s)
  • A data context diagram
  • Data flow diagram(s)
  • Process specifications
  • A timing specification
  • A requirements dictionary
No mention is made of how the process is activated. This is an important part of the information hiding and non-redundancy principles. The PSPEC does not know how or why it is activated, only what to do when it is. Likewise, the CSPEC does not know what the PSPEC does, only how to activate it. The user (who is familiar with the method) know exactly where to look for this information. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 288
Timing Specfication The timing specification is a list of system input events and their resulting system output events, both expressed in terms of the system input and output signals that represent them. The timing relationships are listed for each input-to-output event pair. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 353

Control Flow Diagram metamodel

Figure 4: Control Flow Diagram metamodel

ElementDescription
Control flow A control flow is a pipeline through which control information of know composition flows. It may consist of a single element or a group of elements. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 340

Notation: A dashed arc (terminating in a filled arrow head) with a name.

Control Flow Diagram A control flow diagram mirrors the processes and stores form the DFD, but shows control flows instead of data flows. The CFD is constructed simply to constrain the control signals to flow along the same paths as the data signals may flow. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 347
CSPEC bar A CSPEC Bar is a symbol used on a CFD to indicate the interface between the CFD and its CSPEC. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 340

Notation: A short unlabeled bar.

Process "A process indicates the transformation of incoming data flow(s) into outgoing data flow(s). It is also used to map the paths along which control signals flow, but does not indicate control processing." -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341

Notation: A circle with a name and a number.

Store A data or control store is simply a data or control flow frozen in time. The data or control information it contains may be used any time after that information is stored and in any order. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341

Notation: A pair of parallel lines containing a name.

Control Specification metamodel

Figure 5: Control Specification metamodel

ElementDescription
Control Specification (CSPEC) Control specifications convert input signals into output control signals or into process controls. Control specifications have two roles, one to show control processing and the other to show process control. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 350
Process Activation Table (PAT) Process activation tables show the circumstances under which the processes on a DFD are enabled and disabled. The actions from an STD enter a PAT, which enables and disables the appropriate processes. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 17
State Transition Diagram

A diagrammatic representation of a finite state machine.

State transition diagrams show the states of the system and how they are influenced by control signals. They respond to events represented by control flows and show the corresponding action that they system must take. Events and actions are represented on STDs as Event/Action labels on each of the transitions between the states. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 17
State Transition Matrix (STM) Here, the states are listed on the left side of the matrix, and the events along the top. Each element in the matrix shows the action (if any), and the next state (if any), caused by the event above that element when the machine is in the state on the left of that element. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 83
State Transition Table (STT)

A state transition table consists of four columns.

The first column contains a list of each of the states. The second column shows, for each current state, all the events that cause transitions from it. The third shows the action (if any) associated with each transition. The fourth shows the state to which the transition goes. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 83

Data Context Diagram metamodel

Figure 6: Data Context Diagram metamodel

ElementDescription
Data Context Diagram The data context diagram establishes the data boundary between the system under study and the environment. It is used to show the communications between the system and the environment and the entities in the environment with which the system communicates. The data context diagram is the highest-level data flow diagram for that system -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 344
Process A process indicates the transformation of incoming data flow(s) into outgoing data flow(s). It is also used to map the paths along which control signals flow, but does not indicate control processing. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341

Notation: A circle with a name and a number.

Terminator A terminator represents an entity outside the context of the system that is a net transmitter or receiver of system data. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341

Notation: A rectangle containing a name.

Data Flow Diagram metamodel

Figure 7: Data Flow Diagram metamodel

ElementDescription
Data Flow A data flow is a pipeline through which data of know composition flows. It may consist of a single element or a group of elements. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 339

Notation: A solid arc (terminating in a filled arrow head) with a name.

Data Flow Diagram A data flow diagram is a network representation of a system's functional requirements. The system could be automated, manual, or mixed. The DFD portrays the requirements in terms of their functional component parts, with all interfaces among the parts indicated. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 346
Process A process indicates the transformation of incoming data flow(s) into outgoing data flow(s). It is also used to map the paths along which control signals flow, but does not indicate control processing. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341

Notation: A circle with a name and a number.

Store A data or control store is simply a data or control flow frozen in time. The data or control information it contains may be used any time after that information is stored and in any order. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341

Notation: A pair of parallel lines containing a name.

Relationships metamodel

Figure 8: Relationships metamodel

ElementDescription
Control flow A control flow is a pipeline through which control information of know composition flows. It may consist of a single element or a group of elements. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 340

Notation: A dashed arc (terminating in a filled arrow head) with a name.

Data Flow A data flow is a pipeline through which data of know composition flows. It may consist of a single element or a group of elements. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 339

Notation: A solid arc (terminating in a filled arrow head) with a name.

Information Flow Channel An information flow channel represents the physical means by which an information flow travels from architecture module to another. This channel may be constructed of any material or energy carrier, for example it may be electrical, mechanical, optical, or radio waves. There can be different symbols for different mediums of transmission. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 343
Information Flow Vector An information flow vector is a grouping of all the information that flows between any two architecture modules. These flows may contain any number of data and control flows that constitute the interface between two architecture modules. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 342

Notation: A solid or dashed line (terminating in a filled arrow head) with a name.

Relationship A relationship between two elements.

State Transition Diagram metamodel

Figure 9: State Transition Diagram metamodel

ElementDescription
Action Notation: Shown by name, adjacent to the events that cause them; the event and action are separated by either a forward slash (like event/action) or a horizontal line (like the mathematical notation for a fraction).
Event Notation: Show by name as a label on the arc of the triggered transition.
State Notation: A rectangular box containing the name of the state.
State Transition Diagram

A diagrammatic representation of a finite state machine.

State transition diagrams show the states of the system and how they are influenced by control signals. They respond to events represented by control flows and show the corresponding action that they system must take. Events and actions are represented on STDs as Event/Action labels on each of the transitions between the states. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 17
Transition Arc Notation: A solid line terminating in a filled arrow head (showing the direction of the transition).

System Architecture Model metamodel

Figure 10: System Architecture Model metamodel

ElementDescription
Architecture Dictionary The architecture dictionary is an enhancement of the requirements dictionary. It captures the allocation of all the data and control flows to architecture modules and the channels on which they flow. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 24
Architecture Flow Diagram An architecture flow diagram is a network representation of a system configuration. The AFD represents a set of DFD and CFD flows and processes grouped into one architecture module. The architecture modules are represented by the architecture module symbol, and the communications between the architecture modules are represented by information flow vectors. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 360
Architecture Interconnect Diagram An architecture interconnect diagram is a representation of the channels by which the architecture modules communicate. The channels represent the physical means by which the information travels from one architecture module to another. The physical means might be any material or energy medium such as electrical buses, mechanical linkages, or an optical link. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 361
Architecture Interconnect Specification The architecture interconnect specification establishes the characteristics of the physical media connecting the architecture modules. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 364
Architecture Module Specification An architecture module specification must be written for every architecture module in the architecture model. The purpose of the AMS is to state the information and processing allocation for that architecture module in narrative or graphical form -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 363
System Architecture Model The system architecture model consists of a layered set of AFDs and AIDs and their associated AMSs and AISs. Each successive layer refines the configuration defined by the higher-level diagrams. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 24

Architecture Context Diagram

Figure 11: Architecture Context Diagram

ElementDescription
Architecture Context Diagram The architecture context diagram establishes the information boundary between the system and the environment. It is used to show communication between the system and entities in the environment outside the system. The architecture context diagram is the highest-level architecture diagram for that system -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 358
Architecture Module An architecture module is a physical entity that either is a grouping of other physical entities or is a fundamental physical entity to which logical flows and processes have been allocated. This physical entity could be a hardware unit... Or, it could be a software module... or a group of software modules... -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 342

Notation: A rounded rectangle containing a name and number.

Information Flow Vector An information flow vector is a grouping of all the information that flows between any two architecture modules. These flows may contain any number of data and control flows that constitute the interface between two architecture modules. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 342

Notation: A solid or dashed line (terminating in a filled arrow head) with a name.

Terminator A terminator represents an entity outside the context of the system that is a net transmitter or receiver of system data. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 341

Notation: A rectangle containing a name.

Architecture Flow Diagram

Figure 12: Architecture Flow Diagram

ElementDescription
Architecture Flow Diagram An architecture flow diagram is a network representation of a system configuration. The AFD represents a set of DFD and CFD flows and processes grouped into one architecture module. The architecture modules are represented by the architecture module symbol, and the communications between the architecture modules are represented by information flow vectors. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 360
Architecture Module An architecture module is a physical entity that either is a grouping of other physical entities or is a fundamental physical entity to which logical flows and processes have been allocated. This physical entity could be a hardware unit... Or, it could be a software module... or a group of software modules... -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 342

Notation: A rounded rectangle containing a name and number.

Information Flow Vector An information flow vector is a grouping of all the information that flows between any two architecture modules. These flows may contain any number of data and control flows that constitute the interface between two architecture modules. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 342

Notation: A solid or dashed line (terminating in a filled arrow head) with a name.

Architecture Interconnect Diagram

Figure 13: Architecture Interconnect Diagram

ElementDescription
Architecture Interconnect Diagram An architecture interconnect diagram is a representation of the channels by which the architecture modules communicate. The channels represent the physical means by which the information travels from one architecture module to another. The physical means might be any material or energy medium such as electrical buses, mechanical linkages, or an optical link. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 361
Architecture Module An architecture module is a physical entity that either is a grouping of other physical entities or is a fundamental physical entity to which logical flows and processes have been allocated. This physical entity could be a hardware unit... Or, it could be a software module... or a group of software modules... -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai, p. 342

Notation: A rounded rectangle containing a name and number.

Information Flow Channel An information flow channel represents the physical means by which an information flow travels from architecture module to another. This channel may be constructed of any material or energy carrier, for example it may be electrical, mechanical, optical, or radio waves. There can be different symbols for different mediums of transmission. -- Strategies for Real-Time System Specification by Derek J. Hatley and Imtiaz A. Pirbhai , p. 343
Thursday, 24 September 2015 09:56

Validating ArchiMate models

ArchiMate_Logo

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)

ArchiMate: Business Layer

Figure 1: A subset of the business layer concepts

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

ArchiMate: Application Layer

Figure 2: A subset of application layer concepts

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

ArchiMate: Technology Layer

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).

ArchiMate - Direct Relationships

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

ArchiMate - Derived Relationships

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.