Enterprise Architect version 15.2

download
purchase

enzh-CNcsnlfrdehiiditkoplptruskessv

My Profile

Social Media Channels

facebook  twitter  youtube   linkedin

Displaying items by tag: uml

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
Published in White Papers

Improved C code generation
Efficient C++ code generation
Debugging on the model level (UML)
User code synchronization
Requirements Tracing

LieberLieber Embedded Engineer for Enterprise Architect Version 2.0 offers improved code generation from ANSI-C code from UML structures, state machines and activity models, as well as – brand new – the generation of C++ source code. This improves productivity by using more complex structures from UML modeling and state machines, the code for which, up to now, had to be implemented by hand in C or C++.

  • The automated code generation creates detailed documentation at the same time.
  • Existing solutions must not be converted, since a clean integration of model-based and classic development exists.
  • Compliance with norms is simplified, since only the Code Generator must be adapted.
  • Since the source code is delivered at the same time, necessary adjustments are easily possible and no dependency on solutions providers is generated.

You can download your 90-day trial here.

Published in News

Dunstan Thomas ConsultingNew courses released onto the DT schedule & virtual learning environment!

With no small amount of effort we have managed to bring forward the release of the phase 2 online training courses available via the Dunstan Thomas virtual learning environment.

The list of options now available is; 

You can find all these sessions in the training directory on our website; 

Dunstan Thomas Consulting - Online Training

 

Visit our online training page & use the subscription calculator to get a quote for your online training needs.

New to our classroom offering... 

Modelling Applications for Mobile Devices using Enterprise Architect 

This two day training course for Sparx Systems UML modelling tool, Enterprise Architect. It is designed to provide Business Analysts and Solution Architects with the necessary practical skills to create, using Enterprise Architect, design solution models for applications that will be running on mobile devices. 

For any information on these or any of our other courses or services please do not hesitate to contact us

Published in News

Supported by Sparx SystemsEA User Group Conference; London - The agenda takes shape...

We have received an amazing level of response to the call for speakers for the London conference and can now provide a preview of how the agenda is shaping up for London; 

EA User Group - London Conference 2015

We're still in the draft stages and so timings and presentations are still subject to change.

The call for speakers doesn't close until the end of the month so if you have a story to share and would feel like sharing it with the community then This email address is being protected from spambots. You need JavaScript enabled to view it.

The conference will be taking place at the Park Plaza County Hall, 1 Addington Street, London, SE1 7RY, United Kingdom.

Tickets for this event are already on sale via the EA User Group website.

We look forward to seeing you all in London.

Published in News
Wednesday, 18 February 2015 09:43

Dunstan Thomas launch online training service.

Online training with Dunstan Thomas

Online training with Dunstan Thomas

DT Consulting now offer a virtual learning environment to compliment our existing classroom offering.

This new browser delivered self-study training environment will bring to you DT Consulting’s most popular training courses covering areas such as;

  • Sparx Systems Enterprise Architect
  • The Systems Modelling Language (SysML)
  • The Business Process Modelling Notation (BPMN)
  • The Open Group Architecture Framework (TOGAF)
  • The Unified Modelling Language (UML)
  • ArchiMate

 

Available Courses

 

Coming Soon…

Please visit our website for information on subscription pricing.

Published in News
QUAD-ML – Rapid Modeling Mastery Course with Enterprise Architect (EA) v11

May 28-29 starts 7:00 AM Pacific – Register Here
June 5-6 starts 7:00 AM Pacific – Register Here

Take advantage of our new mixed-language course, QUAD-ML, a one-time only offer at a deeply discounted rate.

What is the QUAD-ML mixed-language?
It is a unique proprietary approach to integrating the four key modeling languages UML, SysML, BPMN and SoaML, into one compact and simplified hands-on course using EA, designed specifically for enterprise modelers, business & systems analysts, software developers and technical managers.

Why QUAD-ML? Why Now?
This course was designed based on inquiries and questions from our customers regarding best practices in mixed-language environments. We also learned that competent hands-on knowledge of these four key languages is becoming a standard in many corporate environments.

QUAD-ML was carefully designed to provide you with a quick and affordable way to gain practical knowledge rapidly with these four languages. It is the best way we know of (so far) to help you come up to speed and compete effectively in the current fast-paced business and high technology environment.

What you will learn:
  • The 10 most important modeling practices you should be applying today
  • The 7 best practices successful organizations use in mixed-language environments
  • How all four languages "integrate" in the same model-based environment
  • How to effectively use the Sparx EA modeling tool
  • Key fundamentals of UML and SysML enterprise modeling
  • The BPMN and SoaML languages
  • How and when to use BPMN and SoaML in mixed-language environments
 
What to expect?
  • Learn first-hand from experts in the industry with over 20 years experience
  • Full course delivery in only 2 days using EA (agenda details upon registration)
  • Experience a real world project in a mixed-language environment
  • A free early copy of the eBook "Rapid Enterprise Modeling" that will soon be selling on Amazon.
  • Register by May 23rd and get 50% off the regular course price
  • Cancel any time up to 24 hours before the class begins
  • 100% money back guarantee
May 28-29  – Register Here
June 5-6 – Register Here

With appreciation,
Ernest Stambouly
949-378-1138
 
Published in News
Thursday, 30 January 2014 23:14

Mobility - Global Change Agent

According to the International Telecommunications Union (ITU) in 2013, there are almost as many mobile-cellular subscriptions as people in the world and in 2014 the number of mobile phones in use will exceed the number of people on the planet.

 

The mobile revolution is providing equity of access to education, health, government, banking, environment and business for many sectors of the global community while challenging enterprise business models in every sector. It is a platform that is here to stay and a disruptive influence on business that cannot be ignored.

 

Mobile devices form the platform that will deliver work models that are very different from the past and facilitate social networking. This force will inform the enterprise architecture that will deliver strategic support for mobile devices owned by employees and provide open, secure environments to allow these devices to connect to enterprise systems including the cloud.

 

By defining an envisioned future state that can be shared and discussed, enterprise architecture will assist organizations to navigate change in an agile manner while enabling milestones to be achieved within agreed time-frames. A key standard for enterprise architecture is the use of UML for creating design models: http://www.sparxsystems.com.au/platforms/soa.html

 

Enterprise architecture is about ensuring that an organization has the right integration/alignment between IT and the business (including people, processes, investments, information and technology) in order to better support the business's capabilities and to enable the business to evolve toward a future state, according to Gartner - “It is not just about technology. Enterprise Architecture is the key to driving digital strategy": http://www.gartner.com/newsroom/id/2586115

Published in White Papers

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

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

This article deals with two topics :

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

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

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

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

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

Applying visual styles to improve BPMN diagrams rendering

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

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

 Sparx EA diagram visual start on BPMN start event

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

 Sparx EA diagram visual start on BPMN end event

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

 

The procedure to create those visual styles is quite easy:

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

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

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

 

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

 

Published in Tutorials
Tuesday, 30 July 2013 12:54

The Well Dressed Model

Seven ways to organise your EA models so that other people can understand them

Ian Mitchell, ian@eaDocX.com

  • If you have spent many hours creating a great EA Model, hopefully you want the rest of your organisation to use it as well. But how can you make it readable?
  • Or maybe have you just picked-up a model which you created a few years back, only to be baffled by your own work. What exactly was this model all about, and where has all that great stuff gone ?
  • Or perhaps you’ve inherited a model from someone else who isn’t available to tell you what’s in it. How are you supposed to sort out what’s complete and useful, from the ‘other stuff’?

Over the years, we’ve come across all of these several times, and have developed a few tricks to avoid them.

If you have more techniques for helping other people to understand your models, please email Ian at eaDocX dot com.

1         A Package is not a Bucket

The most important ‘thing’ in Enterprise Architect is definitely the Package. It’s also the simplest. Just a folder with stuff in it, right?

Wrong.

The Package or rather the family of Packages which you create, say more about your model than anything else. If you just use them as a bucket to put things, then you’re missing-out on a critical way to communicate the intent of your model.

Some rules for Packages:

  • Sensible names. It may seem amusing to call a package ‘new stuff’, but nobody else will ever look there to find anything. If it’s ‘new stuff which was invented in the meeting..’ then call it that. 
  • Descriptions. A Package without a description isn’t just half-dressed, it’s practically naked. There is always something you can say about what’s in the package, where it came from, whether it’s finished or not.
    I suggest that anyone who creates a package in a shared model and doesn’t add a description should buy the coffees for all of next week.
  • Authors. Enterprise Architect will make the Author of the Package the person who created it. But go further, and make the Author the Owner of the information in it. So, even if someone is totally confused at what’s in the package, they can always email the author…

2       Notes, notes, notes

I’ve been teaching UML and other modelling techniques for more than 15 years, so apologies to all former students for repeating this. If you’re in that select group, can you remember the most important UML (or BPMN, or SysML..) modelling construct ?

The Note.

The humble note.

They don’t cost anything, they never run out, and they can communicate more about whyyour diagrams look the way they do than anything else.

Add them to elements, to links, to anywhere you can think of. But make sure to keep them up-to-date: a diagram with misleading notes is worse than one with no notes at all.

3       Single-purpose Packages

If you’re going to follow the rules above, and describe what’s inside each package, then having one, or a small number, of different types of ‘thing’ in a folder is sensible: it’s easier to find things, and easier to write a quick description.

This also becomes important if you are going to document your model using a document generator – either RTF or eaDocX.

A Package with one type of thing in it can be documented as a simple table, with the Package name becoming a title for the table.

4       Different things get different stereotypes

The idea of the Stereotype is one of the key ideas of UML, which EA has extended to cover all the other model types it supports. So whether you’re creating SysML diagrams, BPMN business processes or Use Cases, you can use stereotypes.

So use them.

A stereotype is just a ‘special kind of’ thing. So if you have use cases which are sometimes complete (all scenarios filled-in) then make them <<fully dressed>>Use Cases, or if not <<partially dressed>> . So a reader finding one of these will know whether it will be completed or not: they know what to expect.

The same can be true of any other element. Using a stereotype can tell your readers what they are looking at.

Stereotyping also makes it easier for documentation tools like eaDocX to change how they format their outputs. For example, a <<fully dressed>> Use Case should print its scenarios, and highlight where they are missing – that’s an error. But <<partially dressed>>Use Cases don’t need to.

5        Status is everything, or Somewhere to Play

When you read a model, probably the most common problem is that you don’t know what the status of something is: a diagram, an element, or a whole package of the model.

Is this completed, signed-off and implemented, or just some ideas I had over coffee one day?

So using the EA ‘Status’ fields (with some sensible values) is really, really useful to readers.

But you can do more to help separate the ‘finished’ content from the ‘just thinking’ stuff.

Why not have an area of the model which is just a sandpit? Somewhere where modellers can try things out, and to which no standards apply. Readers are not encouraged to look in these packages. Everything is work-in-progress or incomplete.

Equally, the areas which are for ‘real’ content DO obey all the local rules: packages must have descriptions, only the approved stereotypes are used etc.

6       Public and Private diagrams

The great power of EA is that it allows us to create links between all kinds of elements, depending on what kind of problem we’re trying to solve.

There are several ways to create these links: the Relationship Matrix is a quick way, but diagrams are also very common. And this creates a problem for the reader.

Are they looking a ‘proper’ diagram, which they are supposed to understand, or is this a diagram which you just created to establish some relationships, and isn’t really for public use?

So get used to naming diagrams so that this is obvious, and to prevent accidental printing of these diagrams in documents.

Pick a naming convention for ‘do not print’ documents: we add ‘hidden’ in front of the document name. We’d like to use a diagram stereotype, but that doesn’t appear in the Project Browser. So ‘My untidy diagram’ becomes: ‘Hidden – my untidy diagram’. We also tick the box in the diagram properties to “Exclude image from RTF Documents”. Both the EA RTF generator and eaDocX will take this to mean ‘don’t print in any document’.

So now you’re free to create as many untidy diagrams as you like, and readers will know to ignore them.

7        Pick a meta-model, write it down, and stick to it

This final piece of advice is really a summary of all the others.

Each idea we’ve discussed above contributes to your meta-model.

If that sounds like a scary, super-technical idea, it isn’t.

All of your EA models already have a meta-model, whether you know it or not. The meta-model just says what kinds of ‘stuff’ is in your model.

  • What kinds of elements have you used? e.g Requirements and Use Cases, but not internal requirements,
  • How have you linked them together?  
  • What stereotypes have you used, and what does each one mean?
  • How have you used things like Element Tests, the Glossary, or Project Tasks?

..so not really complicated. The meta-model is just your local modelling standards.

If you want to find out what your meta-model is, use the eaDocX Model Expert. It will draw a diagram of all the element types, stereotypes and links in your model. Be prepared for a surprise! Big models can be complicated!

This is a good reason to make your meta-model clear and simple. Pick a small number of elements, stereotypes and links, and use them consistently.

Communicating the meta-model is critical: one which only you understand is no use. It MUST be written down, preferably in the model itself, and taught to all of your team.

AND kept up-to-date, as your modelling style evolves, as it will certainly do.

Published in White Papers

CRaG Systems has scheduled a number of public courses in Johannesburg, South Africa teaching model-driven development with UML, BPMN and Enterprise Architect. The courses take place over the five days of one full working week on a regular basis at the CRaG Systems Training Centre in the heart of the central business district of Sandton in the north of Johannesburg.

Over the 5 days students will learn the use of Enterprise Architect for business analysis, requirements definition and system analysis using the most appropriate syntax for the job in hand. Students can choose which of the three sections they would like to attend enrolling for one, two or all three sections in any one week.

Industry best practice is taught for business process modelling, system use case modelling and system analysis at every appropriate level of abstraction based on the Business Process Modelling Notation v2.0 for business process modelling and on the Unified Modelling Language v2.4 for systems modelling. The techniques are taught within the context of a business process management (BPM), improvement or re-engineering strategy and a model-driven development process in a way that satisfies the needs of both technical and non-technical stakeholders.

Enterprise Architect is used for the exercises throughout the course and the relevant details of the use of Enterprise Architect for modelling, reporting, traceability and change management are taught.

CRaG Systems' Johannesburg Training Centre

Currently scheduled dates:

  • August 19th - 23rd 2013
  • October 7th - 11th 2013
  • November 18th - 22nd 2013
  • January 27th - 31st 2014
  • March 10th - 14th 2014
  • May 5th - 9th 2014

 

For more information see the CRaG Systems BPMN and UML using Enterprise Architect Training Courses in Johannesburg page.

 

CRaG Systems' Johannesburg Training Centre

Published in News
Page 3 of 4