Hello there Dermot O'Bryan here from Sparx Systems. In this webinar we'll explore how to transform
Behavioral Models into Executable Source Code using Enterprise Architect's Behavioral Model
Code Generation features using the Behavioral Models such as State Machines, Sequence diagrams
and Activity diagrams. Enterprise Architect can generate usable code in the more popular
code languages like C++ C# and Java as well as hardware description languages like VHDL, Verilog
and SystemC. There is also the option to find your own code structure using Enterprise Architect's
Code Template Framework. Even create Templates for generating code for another code language.
These features can be used in a variety of environments ranging from high-end applications
through to embedded code for automated machines. From simple devices through to components in
complex units used in the automotive, maritime and aerospace industries. Note that these features
do require the Unified or Ultimate Edition of Enterprise Architect. We'll start with an overview
of a Class with underlying Behavioral Models. Then Generate Code from this in a number of different
code languages. What we'll cover is a look at an example and the code generated. A look at the
Structure from the Class down. Generate out the code from the Model. See the correspondence from
Elements to Actual Code for Activity diagrams, State Machine diagrams including Transitions
Entry/Exit, Do Actions and Sequence diagrams. We will then view the options available for different
languages. Finally we will look at customizing the generation using the Code Template Language.
The example diagrams that we'll be using to generate the code are available in the
EA Example Model, which is supplied with Enterprise Architect. The particular diagrams we'll be
looking at cover some fundamental functions used in the Input/Output of a Portable Audio Player.
The higher end design is shown in the Design Package under the Requirements Package.
We are focusing on the software language aspect, which is used for the implementation of
this Portable Audio Player. In this case it is a generation to C++ of the USB Interface
as outlined in the Design Model. Note that there are also hardware language examples above.
This to start off with. Let's take an example of a Set of Classes under one language.
In terms of the general structure, what is required is, the Behavioral Models are set
under a Class to basically emulate an Operation. These Behavioral Models can
be called in the same way an Operation can be called. They can also Call Operations or
other Behavioral Models. For example a State in a State Machine calling an Activity diagram
or a Composite diagram. An Action calling an Activity using a Call Operation. In this case
we explore a simple two-Class Model. We can see, this has one standard UML Operation set.
Number of bytes received as well as a much more complex Behavioral Model
including several Activity diagrams. Here is one, we'll look at doReadSerialPort.
State Machine diagrams, a key one that we'll look at is the Search Internal Media
and Sequence diagrams. This is a more complex one. We will run over a simple example later.
Let's generate this Class out to code to get an overall view of what is created. We select
the Class IO, open the Develop Ribbon and in the Source Code section we use the “Generate” option.
Now with the Code generated we access this via the Class
by selecting the Class and pressing F12 or Control+E. We see the Code in the Code Editor
and its Operation structure on the left pane. The actual generator code on the right pane.
The standard Class Operation set, Number of bytes received has some simple script
defined in the Code Properties, which we see, is generated out with the code.
On looking at the Behavioral Models under the Class we see the correspondence to the
Code generated as Operations from the Behavioral Models. In this case we have the Activity diagram
doReadSerialPort and the Code generated out from this diagram.
Then we have doReadUSB and the Code generated out from this Sequence diagram.
Let's have a look at each of the three Behavioral Models and get an overview of what each is capable
of generating. For a View of the general Sequence of Calls, let's have a quick look at
a State Machine, an Activity diagram and a Sequence diagram as an Interactive Model.
Each used to generate code. We start with a State Machine SearchExternalMedia on looking
at the "do" Operation. On opening the code we see, it is calling doReadSerialPort. I'm finding that
Action under the Class as the pseudo-Operation of the Class. We open it and see its general layout.
On coming back to the State Machine we look at the next statement
and see that it is a "do" Operation. It is calling an interaction doReadUSB
with a Sequence diagram laying out the process.
Now we see how the Call sequencing in this case is laid out in the State Machine;
SearchExternalMedia. To run over the characteristics of each Behavioral Model Type.
We will start with an example on an Activity diagram. Then look at the State Machine
and a Sequence diagram. For an example in which we look at the correspondence of code generated
from the source Activity diagrams. Let's go back to the Serial Interface diagram; doReadSerialPort.
This code generated from the Activity is clearer and simpler than the State Machine.
We can open the diagram - place the Code Editor as a split diagram so we can see both.
This Activity diagram covers a number of features that are used for generating code.
Let's start with the Create Object Action. This is set to create an
Instance of the ErrorHandler Class. So let's search for that in the code.
This is covered in the first line of the function doReadSerialPort.
It's deriving its argument pHandler from the Result Property.
Looking back at the code we see the line that was generated from this.
Then we have the Call SetLastError Action, which when we look at the Behavior.
It is calling the Operation in the ErrorHandler Class called SetLastError. This is referenced
using the Browse button. We can see that the Operation is referencing the ErrorHandler Class.
We can also find that the Operation is under the ErrorHandler Class in the Browser.
The first Activity Pin is referenced in the Properties under Call Operation Action
as the Target: phHandler. The second is referenced as the Argument arg_iErrNo.
We see how each of these are referenced from their respective Browse buttons.
In the case of arg_iErrNo Activity Pin Properties. We see that it is set with a Parameter Value of 0.
Looking back at the code we see, what has generated from this on line 103.
In the CallCreatePort we have in its Behavior a reference to the Operation under the Class IO
which we find it under the IO Class.
The Action Pin provides the Parameters that is the value LPT1. All this produces a single
line of code. Now we look at the Loop Sequence. The entry to the loop is based on the condition
bValid == True in the ControlFlow's Constraints. The “while” condition is defined in the
ControlFlow’s Guard as bDataReader == false. There are two Activities in the loop, which are
generated inside the “do while” statement. Each of the Activities in this part of the Model covers
similar Behavioral Definitions as we covered above. Hence giving simple lines of code calling
Operations with Parameters. This is completed with an Action “Destroy” that takes the Argument
pHandler from the Action Pin and does a check on the handler and deletes it. There is a lot more,
but hopefully this gives you an overview of some key places to study. As to where there are
definitions and where to find the resulting code statements that have been generated.
Of course the Code Generation can be different depending upon the languages being used,
but we will cover the Code Generation Templates later.
Now let's go back to the State Machine that called the Activity diagram and have a closer look at the
code generated for the loop between these States. Let's get the Boolean Condition Statement in that
Guard. That is the Transitions Constraints and we will do a search for that in the generated code.
We see, it is in the IF Statement in the Operation. This is deciding whether to take
the transition to the ReadSerialPorts or take the Transition to Final.
We now look at the doReadUSB Sequence diagram that we saw was being called
earlier for the State Machine that we first looked at. In this case it is
a simple Sequence diagram with an Interaction Occurrence reference to
another Sequence diagram. It includes two Messages inside an Interaction Fragment.
We then look at the Code generated from this. It is a set of "Clear" statements generated from each.
The first Message is the interaction of current,
which is a Call to the more complex setupUSB Interaction Diagram.
On double clicking this, we see the Reference Model.
The Call to the SetUSB has a Parameter bValid device, which is defined under the Arguments tab.
We see in the Code generated that is a Call to SetupUSB with the Parameter bValid. It then has
the "alt" combined Fragment with a Condition bValid.
With that condition being met it has a message to read the port, otherwise it sets the bData
variable to "False". Again in looking at the code we see the nice clean and simple if/else Statements
with these two statements generated Enterprise Architect's Code Generation supports a variety
of languages ranging from the popular C#, Java, C++ through to specific embedded code languages
like SystemC, VHDL and the like. When starting to create a new model ensure that you set the
language for the code to be generated out. This is defined in the Settings Ribbon
under the Default Language for Code Generation. We can see
a variety of languages supported. Let's set this in this case to C#.
Now let's look at creating a simple Model to show, how we can generate out a quick piece of code.
For this we will start by creating a Package and placing a Class diagram under this Package.
On opening the diagram we can use the Spacebar to add a Class.
On viewing the Class Properties we see that it is set to C# in line with what we said as
the default language. Now under the Class we can create a simple Activity diagram.
In this diagram we create an Initial Action
and a ControlFlow to an Action. Then an Activity Final via another ControlFlow. In selecting the
Action then its Properties under Effects, we set a simple C# line of code for a write statement.
On selecting the Class and go to the Ribbon; Develop | Source Code | Generate
On selecting the Class and pressing F12 we see the simple code that was generated.
Including the "write" statement in the Activity Operation. Just to cover a
more realistic example we have a simple Action Loop, which we can now generate out to code.
On opening the code we can clearly see,
how the Action Loop was generated as a “do while" statement in the C# Class.
The code generated is customizable in that Enterprise Architect provides user
definable Templates for the setting of your own code generation structures. The use of these
can vary and can range from simple adjustments to conform to one of many industry standards,
such as ISO-178c or the iISO 26262 through to creating your own templates for another language.
Okay so let's have a look at a standard template. We open the Code Template Framework
and choose a specific language. As you can see there is a wide range of languages supported
including the likes of C++, C# and the languages for embedded code like SystemC,
Verilog and VHDL. Note that there is also the templates option, which allows you to set up
a new set of templates for a new language. Let's look at a nice simple language that is JavaScript.
Although it's not object oriented and not available for Behavioral Code Generation.
It is used elsewhere and gives us a nice simple starter for the concepts behind these Templates.
If we have a look at the Class Template. We see, it is calling Class Declaration on opening.
We see the simple String Function that would be a direct text generation. Next to it a Call for the
Class Name Variable. This give a simple Function and the Function Name Output going back to C#.
Let's look at the Behavioral Model Code Generation Template for an Action. We see a
simple set of Calls based on the Action Types such as “Create” and “Destroy” that we covered earlier.
In the case of “Create” we have the initial lines that are Setting Values to the Strings
to work with. Then there are a series of checks and warnings on the missing Parameters etc.
Finally on line 31 we have the Statement to be generated out using the Values of
the Variables set at the start. Now to give a broader picture on this you see.
The key individual model groups are covered in the Templates here. We have Actions.
We just covered one, but there are many more. Now we have a look at States and Transitions
and finally Interactions as these basically cover the same process as an Action.
They use the same Code Generation as the Action Templates. On looking at the Help Topic covering this.
We see a Message invoking an Operation uses the Code Template of an Action Call.
A Message with a Life Cycle Delete invokes the Action “Destroy” and so on.
In this webinar we only covered several key options for setting up Behavioral Models for Code
Generation. Each of the Behavioral Code Models have distinctive features that are generated out
to Code, which if covered in specific detail would mean a very long and boring webinar.
So what is recommended when searching for details on implementing a specific Element Type. What is best is
to scan through these example models in the Example Repository. Then look at the Properties
in the resulting code and then use these as a starting point to define your own Model.
There is also a set of Java examples of Behavioral Code Generation
under Software Engineering Java Models with Behaviors.
To give a summary of the topics covered in this webinar. We firstly looked at the structure
from the Class down. Then we looked at the correspondence from Elements to actual Code
for Activities including core Behaviors. State Machines including Transitions and Entry, Exit, Do
and Sequence diagrams. We then looked at a range of languages supported and the option for defining
modeling for specific languages. Finally we looked at customizing the generated code using the Code
Template Framework. In this webinar we covered the standard Behavioral Model Code Generation.
There are numerous other Enterprise Architect features in common with this. In particular the
Executable State Machine Code Generation feature, which covers a similar usable code generation, but
uses the Intel Simulation features of Enterprise Architect for Testing, Simulating and Debugging
the processes. There is also the Code Generation and Simulation for Decision Model Notation or DMN.
So when looking at the Model Based Code Generation, it's worthwhile firstly
considering these other options and discerning, which is most appropriate for your scenario.
In conclusion hopefully this gives you a good overview of the scope of Enterprise Architect's
Behavioral Model Code Generation. How to define the Element Properties as
well as a guide to using this in the Code Template Framework. For more information
see the Help Topics under Modelling Domains | Software Engineering | Behavioral Models