Enterprise Architect version 14.0

download
purchase

enzh-CNcsnlfrdehiiditkoplptruskessv

My Profile

Social Media Channels

facebook  twitter  youtube   linkedin

Tuesday, 20 September 2016 10:30

Fresh Modeling Versioning with LemonTree

LieberLieber is proud to present a brand new Enterprise Architect tool named LemonTree (c). The most important function of this ground-breaking product is the diffing and merging of model versions.

Now, you do not have to lock your packages. Just check-in your eap files in your version control system!

Standard approaches use line- and text-based applications that do not suffice for graphic models. Only the finely-grained 3-way diffing algorithm that considers the model’s graph structure enables an exact comparison between two models.

 LemonTree highlights:

  • Diff & Merge: Diffing and merging of Enterprise Architect models
  • Model Versioning: Parallel editing of models with optimistic model versioning
  • Integration: Seamless integration with Subversion (Tortoise) included
  • Automation Interface: Automate LemonTree and integrate it in your versioning tool such as Git, PTC, or SVN
  • Model Branches: Branches of models (longer-term, parallel development of versions and variants)
  • Merge Preview: Diagram merge and merge preview
  • Review: Changes are visualized clearly and understandably for review (including preview)

Stefan Mueller, HIMA Paul Hildebrandt, Safety-Related Automation Solutions: “In general, standards such as IEC 61508 demand the application of configuration management. This applies to all artifacts, including UML models. LemonTree from LieberLieber is our key to revealing the changes that have been made to a revision.”

 

Test LemonTree now and give us your feedback!

 

For more information: http://lemontree.lieberlieber.com/

 

Published in News

CIOReview cover 100916In a candid interview with Arun Kant from CIOReview, Sparx Systems' CEO Geoffrey Sparks highlights how Enterprise Architecture has become an imperative for survival in the ever-changing and globalized corporate landscape.

 

CIOReview has also included Sparx Systems in their '20 Most Promising Enterprise Architecture Technology Providers 2016' list, resulting from a robust selection process actioned by a highly qualified panel of domain experts. The in-depth interview with Geoffrey Sparks is the featured article in this month's edition of CIOReview, where Geoffrey discusses the Sparx Systems tradition of continual development of the Enterprise Architect platform, while maintaining the highly competitive price-point that enables affordable outfitting for all project stakeholders.

 

Geoffrey Sparx, Founder and CEO, Sparx Systems

 

To read the full featured article, simply download the PDF attachment at the top of this article.

 

cioreview ea tool vendors top 20 logo 2016

Published in News
Tuesday, 16 August 2016 21:34

Automated FMU Generation from UML Models

Automated FMU Generation from UML Models

 
Original created by: Manuel Geier and Bernhard Sadransky
(www.sysml4industry.org)


Introduction

The simulation of cyber-physical systems plays an increasingly important role in the development process of such systems. It enables the engineers to get a better understanding of the system in the early phases of the development. These complex systems are composed of different subsystems, each subsystem model is designed with its own specialized tool sets. Because of this heterogeneity the coordination and integration of these subsystem models becomes a challenge.

The Functional Mockup Interface (FMI) specification was developed by an industry consortium as a tool independent interface standard for integration and simulation of dynamic systems models. The models that conform to this standard are called Functional Mockup Units (FMU).

In this work we provide a method for automated FMU generation from UML models, making it possible to use model driven engineering techniques in the design and simulation of complex cyber-physical systems.

Functional Mockup Interface

The Functional Mockup Interface (FMI) specification is a standardized interface to be used in computer simulations for the creation of complex cyber-physical systems. The idea behind it being that if a real product is composed of many interconnected parts, it should be possible to create a virtual product which is itself assembled by combining a set of models. For example a car can be seen as a combination of many different subsystems, like engine, gearbox or thermal system. These subsystems can be modeled as Functional Mockup Units (FMU) which conform to the FMI standard.

The Functional Mockup Unit (FMU) represents a (runnable) model of a (sub)system and can be seen as the implementation of an Functional Mockup Interface (FMI). It is distributed as one ZIP file archive, with a ".fmu" file extension, containing:
  • FMI model description file in XML format. It contains static information about the FMU instance. Most importantly the FMU variables and their attributes such as name, unit, default initial value etc. are stored in this file. A simulation tool importing the FMU will parse the model description file and initialize its environment accordingly.
  • FMI application programming interface provided as a set of standardized C functions. C is used because of its portability and because it can be utilized in all embedded control systems. The C API can be provided either in source code and/or in binary form for one or several target machines, for example Windows dynamic link libraries (".dll") or Linux shared libraries (".so").
  • Additional FMU data (tables, maps) in FMU specific file formats

The inclusion of the FMI model description file and the FMI API is mandatory according to the FMI standard.

Tools

Enterprise Architect is a visual modeling and design tool supporting various industry standards including UML. It is extensible via plugins written in C# or Visual Basic. The UML models from which we generate our FMU are defined with Enterprise Architect.

Embedded Engineer is a plugin for Enterprise Architect that features automated C/C++ code generation from UML models.

We further used the FMU SDK from QTronic for creating the FMI API. It also comes with a simple solver which we used to test our solution.

Running Example

Our basic example to test our solution is called Inc. It is a simple FMU with an internal counter which is initialized at the beginning and it increments this counter by a specified step value, each time it gets triggered, until a final to value is reached or exceeded.

State Machine

The state machine contains just an initial pseudo state which initializes the state machine and a state called Step. The Step state has two transitions, one transition to itself, in case the counter is still lower then the to value, if this is the case, the inc() operation will be called and we are again in the Step state. If the value is equal or greater to the to value, it reaches the final state and no further process will be done.


Class diagram

The class diagram consists of two parts. The left part with the Inc class is project specific. It holds three attributes: counterstep and to. All attributes are of type int. The initial value for the counter is 0, for the step it's 5 and for the to value it's 50. The FSM classes on the right are the mandatory classes for the Embedded Engineer to be able to generate the state machine code.
Some specific implementation code also exists in various places. In the state machine you can see, that we have some guards on the transitions. These guards are actually code that will be used to generate the code for the state machine:

me->counter < me->to

and

me->counter >= me->to

The property me represents a pointer to an instance of the Inc class.

And finally the implementation of the inc() operation is also provided:

me->counter = me->counter + me->step;



 

Manual Code Generation

First we manually created our reference Inc FMU, the following steps where taken:
  1. UML models were defined in Enterprise Architect (class diagram and state machine diagram)
  2. C code was generated from the previously created models (with the Embedded Engineer plugin)
  3. The FMI model description xml file and the FMI API were created by hand
  4. The (compiled) FMI API was packaged together with the model description file into a FMU file. This was done with a batch script.
 
 

Automatic Code Generation

Now we want to automate the creation of the FMI model description file and the FMI API. For this purpose we wrote our own Enterprise Architect plugin. To be able to generate semantically correct FMI model description and FMI API artifacts, we attached additional information to the UML models. This was achived through the definition of various UML stereotypes for UML class attributes and methods. Since the FMI defines its own data types we also had to map the data types used in the UML models to the corresponding FMI data types. With these challenges addressed we were able to implement our FMU generation plugin.

 

Future Work

Our work comprises a fundamental prototype that is only a start and could be improved in various ways. The following list describes some issues that could be tackled.
  • One limitation of the current implementation is that we are not able to provide initial values for the FMU. Consequently, to test different configurations of our FMU, we always have to set the default values in the UML models and regenerate the FMU for the simulator again. Hence, future work includes creating new stereo types for initialization of FMU settings/variables and testing these bindings.
  • We used the FMU SDK simulator for this project. Other (more powerful) simulators should be tested too. Furthermore, co-simulation with other FMUs needs to be tested.
  • In our project we restricted ourselves to just look at discrete functions by using the event system of the FMU. To continue the journey we also have to consider continuous functions.
  • More complex examples should be considered to test the capabilities of the automatically generated code. By creating more complex examples the practical limitations of modeling a FMU with a class diagram and a finite state machine need to be discovered. Questions like "What can be implemented?" and "What can not be implemented?" need to be answered.
  • The automated code generation process could be reduced to a one-click functionality to directly generate the ".fmu" file without any additional compilation and packaging step necessary.
 

Acknowledgement

This work has been supported by LieberLieber in the context of the CDL-Flex project: http://www.sysml4industry.org/.

Screencast

Screencast FMU with UML

Published in White Papers

Managing Connectors

In this latest instalment in the series Phil Chudley will be looking at managing your connectors in Enterprise Architect.

https://www.youtube.com/watch?v=UhTsvUDrgDU

As always all of our videos are available right now via our YouTube channel ... and don't forget to subscribe!

Published in Tutorials

Creating a Diagram

In this latest instalment in the series Phil Chudley will be looking at the basics involved in creating a diagram using Enterprise Architect.

 

 

https://www.youtube.com/watch?v=hs98ZjLqCMQ

As always all of our videos are available right now via our YouTube channel ... and don't forget to subscribe!

Published in Tutorials

planet nine in outer space artistic depictionOn 20 January 2016, researchers Konstantin Batygin and Michael E. Brown at Caltech announced a calculation-based evidence of a massive ninth planet in the Solar System.

Planet Nine would be 10 times the mass of Earth (approximately 5,000 times the mass of Pluto), and have an orbit that is so far away that it could take it 15,000 Earth years to orbit the Sun. It would most likely be an ice giant with a thick atmosphere of hydrogen and helium.

 

lsst graphic

However, as Zeljko Ivezic (Large Synoptic Survey Telescope Project Scientist) suggests “if it exists, might be too small to be discovered with ongoing sky surveys, but large enough to be discovered even with only the first year of LSST data! That would be a great way to start the survey!”

Sparx Systems Enterprise Architect is providing a scalable, shared model to integrate the work of the geographically dispersed LSST team. Enterprise Architect has delivered complete requirements traceability, round-trip code engineering and detailed SysML support.

 

Additional Resources:

  • Case Study: Designing the Large Synoptic Survey Telescope with Enterprise Architect - PDF Document
  • Download E-Book: 20 Terabytes a Night: Designing the Large Synoptic Survey Telescope's Image Processing Pipelines - PDF Document
  • Official website: Large Synoptic Survey Telescope - Visit Site

 

Creative Commons Attribution: Planet Nine in Outer Space artistic depiction image by Prokaryotes

Published in Sparx Insights
Monday, 01 February 2016 01:04

ISO 19160-1 Addressing Standard Released

arcgis screenshotOn 15 December 2015, ISO 19160-1 was released.  This standard was developed by ISO/TC 211- a standard technical committee within the International Standards Organisation (ISO), to cover the areas of digital geographic information and geomatics.

The ISO 19160-1 standard defines a conceptual model for address information, together with the terms and definitions that describe the concepts in the model. The model was developed in Enterprise Architect and is presented in the Unified Modeling Language (UML).

For almost a decade Sparx Systems has supported the global geospatial community through provision of Enterprise Architect licences for standards development and inclusion of
Esri ArcGIS and GML profiles within Enterprise Architect.  

Additional Information:

Published in News

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.

Published in Tutorials

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
Page 2 of 4