In the firstarticle in this series, we introduced the notion of an executableUML, but we did not describe the elements of which it consists. Theseelements must be sufficiently primitive to be translatable intomultiple implementations, including hardware, but be powerful enough tobe useful.
The number of elements in executable UML must also be low to easethe construction of translators, to ease the burden of learning thelanguage, and to eliminate the ambiguity that accompanies the use ofmultiple constructs to represent the same concept. Determining exactlywhich elements make up an executable UML is therefore a matter ofjudgment.
In this second article, we describe the elements of Executable andTranslatable UML (xtUML, or just Executable UML)  , how actions enable descriptionof behavior at a higher level of abstraction, the dynamic behavior ofan executable UML model, and how a model of an SoC design can beverified before committing to a hardware-software partition.
The Static Elements of xtUML
xtUML is a streamlined subset of UML to support the needs of execution-and translation-based development for SoC. As you will recall from thefirst article, we propose the construction of a single applicationmodel that captures behavior but does not capture the implementationstructure (especially whether some functionality is to be executed inhardware or software).
The xtUML diagrams (e.g. class diagrams, state machines,activityspecifications) are “projections” or “views” of an underlying modelthat has defined execution semantics. Other UML diagrams that do notsupport execution, such as use case diagrams, may be used freely tohelp build the xtUML models, but as they do not have an executablesemantics, they are not a part of the xtUML language. The xtUML modelis the formal specification of the solution to be built on the chip.
The essential components of xtUML are illustrated in Figure 2, below , which shows a setof classes and objects that use state machines1 to communicate.
[UML 2 uses “state machine” tomean both the diagram (previously known as a state chart diagram) andthe executing instance that has state.To reduce ambiguity, we havechosen to use “state model” for the diagram describing the behaviors,and “state machine” for the executing instance. Where either meaningcould apply, we use “state machine” to be consistent with the UML. ]
Each state machine has a set of actions triggered by the statechanges in the state machine. The actions then cause synchronization,data access, and functional computations to be executed.
Each class may be endowed with a state model that describes thebehavior of each instance of the class. The state model uses onlystates (including initial pseudo-states and final states), transitions,events, and actions.
Each class may also be endowed with a state model that describes thebehavior of the collection of instances. Each class in a sub-typinghierarchy may have a state model defined for it as a graphicalconvenience. As each state machine progresses through its lifecycle, itexecutes a set of actions.
|Figure1: The structure of an xtUML model|
Enabling execution of UML models
The introduction of a complete set of actions, as provided by UML 1.5carried forward into UML 2.0, makes UML a computationally-completespecification language with a defined “abstract syntax” for creatingobjects, sending signals to them, accessing data about instances, andexecuting general computations.
An action language “concrete syntax” provides a notation forexpressing these computations. [MentorGraphics' EDGE UML Suite provides OAL (Object Action Language) thatcomplies with the abstract syntax standard, but there is presently noaction language (notation) standard .]
The difference between an ordinary, boring programming language anda UML action language is analogous to the difference between assemblycode and a programming language. They both specify completely the workto be done, but they do so at different levels of language abstraction.
Programming languages abstract away details of the hardware platformso you can write what needs to be done without having to worry aboute.g. the number of registers on the target machine, the structure ofthe stack or how parameters are passed to functions. The existence ofstandards also made programs portable across multiple machines.
To illustrate the issues, consider the following fragment of logic:
Until Calls = null do
Sum += Calls.timeOfLastCall;
Calls = Calls.next;
The elements in this fragment include assignments, until, null, anexpression (with equality), an increment of a variable, and a linkedlist of some sort.The semantics of While not (expr )and Until (expr ) are the same.One of them is syntactic sugar—a sweeter way of expressing the samething.
[We once saw the following code :
ConstantHell_Freezes_Over = False;
UntilHell_Freezes_Over do. . . .
Of course, which is syntactic sugar, and which the one true way ofexpressing the statement can be a matter of heated debate. One canalways add syntactic sugar to hide a poverty of primitives so long asthe new syntax can be reduced to the primitives. The choice ofprimitives is a matter of judgment; there is no bright line.
Consider now a triplet of classes, X,Y , and Z withassociations between them. We might wish to traverse from the xinstance of X to Y to Z to get the p attribute (x–>Y–>Zp ).The primitives involved here are a traversal and a data access.
However, we could choose to implement these classes by joining themtogether to remove the time-consuming traversal. In this case, thespecification (x–>Y–>Z.p )can be implemented by a simple data access xyz.p , where xyz is an instance ofthe combined classes X, Y, and Z.
In this example, the traversal is a single logical unit expressed asa set of primitives. Defining the specification language so that theseprimitives are grouped together in a specification allows thetranslated code to be more efficient.
For example, if GetTheTimesOfAllCalls is aquery defined as a single unit in the manner of (x–>Y–>Z. p ),so that all knowledge of the data structures is localized in one place,we can implement it however we choose.
We can go further. The logic above sums the times of some calls thathappen to be stored in a list. We can recast it at a higher level ofabstraction as: GetTheTimesOfAllCalls ,then sum them. This is the formulation used by the UML action model.The application model can be translated into a linked list as in thecode above, a table, distributed across processors, or a simple array.
This last point is the reason for the word 'translatable.' Anexecutable translatable UML has to be defined so that the primitivescan be translated into any implementation.
This means isolating all data access logic from the computationsthat act on the data. Similarly, the computations must be separatedfrom the control structures (in the logic above, the loop) so that thespecification is independent of today's implementation—includingwhether to implement in hardware or software.
The Dynamic Behavior of an xtUMLModel
Figure 1 above showed thestatic structure of xtUML, but a language is meaningful only with adefinition of its dynamic behavior.
To execute and translate, the language has to have well-definedexecution semantics that define how it executes at run time. xtUML hasspecific unambiguous rules regarding dynamic behavior, stated in termsof a set of communicating state machines, the only active elements inan xtUML program.
Each object and class can have a state model that captures itsbehavior over time. Every state machine is in exactly one state at atime, and all state machines execute concurrently with respect to oneanother.
Each state machine synchronizes its behavior with another by sendinga signal that is interpreted by the receiver's state machine as anevent. On receipt of a signal, a state machine fires a transition andexecutes an activity, the set of actions that must run to completionbefore that state machine processes the next event.
Each activity comprises a set of actions that execute concurrentlyunless otherwise constrained by data or control flow, and these actionsmay access data of other objects. It is the proper task of the modelerto specify the correct sequencing and to ensure object dataconsistency.
The essential elements, then, are a set of classes and objects withconcurrently executing state machines. State machines communicate onlyby signals. On receipt of a signal, a state machine executes a set ofactions that runs to completion before the next signal is processed. (Other state machines can continue merrilyalong their way. Only this state machine's activities mustrun-to-completion .)
Signal order is preserved between sender and receiver object pairs,so that the actions in the destination state of the receiver executeafter the action that sent the signal. This captures desired cause andeffect.
It is a wholly separate problem to guarantee that signals do not getout of order, links fail, etc., just as it is separate problem toensure sequential execution of instructions in a parallel machine.
Those are the rules of the language, but what is really going on isthat xtUML is a concurrent specification language. Rules aboutsynchronization and object data consistency are simply rules for thatlanguage, just as in C we execute one statement after another and datais accessed one statement at a time. We specify in such a concurrentlanguage so that we may translate it onto concurrent, distributedplatforms; hardware definition languages; as well as fully synchronous,single tasking environments.
Application Model Verification
An executable application model can be executed independent ofimplementation. No design details or code need be added, so formal testcases can be executed against the application model to verify thatrequirements have been properly met. Critically, xtUML is structured toallow developers to model the underlying semantics of a problem withouthaving to worry about whether it is to be implemented in hardware ofsoftware.
Verification of application models is exactly that: It verifies thebehavior of the application models and nothing else. It does not checkthat the system will be fast enough or small enough; it checks onlythat the application does what you (your client and your experts) want.Verification is carried out by model execution.
When we construct an application model, such as that shown in Figure1, we declare the types of entities, but models execute on instances.To test the behavior of the example in Figure 1, therefore, we needfirst to create instances. We can do this with action language or withan instance editor.
We then define operations to create the object instances on whichthe test will execute. Then, we send a signal to one of the createdobjects to cause it to begin going though its lifecycle. Of course,actions in that object may be signal-sends that cause behavior in otherobjects. Eventually the cascade of signals will cease and the systemwill once again be in a steady state, ready for another test.
Each test can be run interpretively. Should the test fail, theapplication model can be changed immediately and the test rerun. Careshould be exercised to ensure the correct initial conditions stillapply. It is useful to be able to 'run' the whole test at once; to'jog' through each state change, and to 'step' through each action.
When each test run is complete, we need to establish whether itpassed. This can be achieved either by interactively inspectingattribute values and the state of the application models or by usingaction language that checks expected values against actuals. A reportcan be produced in regression-test mode that states whether each testpassed or failed.
Capturing xtUML Models
When we build an application model such as that in Figure 1 , its semantic content mustbe captured somehow. This is accomplished by building a model of themodeling language itself.
The classes Oven and CookingStep , for example, are bothinstances of the class Class in the model of the modeling language. (The formal name for a model whoseinstances are types in another model is a metamodel. Informally, it isthe “dotted line” of the firstarticle. )
Similarly, the states Ready and Executing for the class CookingStep are captured asinstances of the class State, and attributes powerOutput and pulseTimerof the class Magnetron are captured as instances of the classAttribute. This is also true for the actions. The action languagestatement generate powerOn tomagnetron; is an instance of the metamodel class GenerateSignalAction .
Naturally, a tool will also capture information about the graphicallayout of the boxes on the diagrams entered by the developer, but thisis not necessary for the translation process. Only the semantics of theapplication model is necessary for that, and that's exactly what iscaptured in a metamodel.
At system construction time, the elements captured in the metamodelare mapped to implementation. The desired sequencing specified in theapplication models must be maintained. Objects may be distributed,sequentialized, even duplicated redundantly, so long as the definedbehavior is preserved.
We take up how to do this in the third article in theseries.
To read Part 1 in this series, go to “Thecentral problem of SoC design and a proposed xtUML solution.”
This series isreprinted in four parts from Chapter 2 of UMLfor SoC Designwith permission of Springer .
StephenJ. Mellor , Chief Scientist of the Embedded SoftwareDivision at Mentor Graphics, is an internationally recognized pioneerin creating effective, engineering approaches to software development.In 1985, he published the widely read Ward-Mellor trilogy StructuredDevelopment for Real-Time Systems, and in 1988, the first booksdefining object-oriented analysis. His latest book MDA Distilled:Principles of Model-Driven Architecture was published in 2004.
John R. Wolfe , Director of Operations and Engineeringfor theBridgePoint UML suite at Mentor Graphics, was President and CEO ofProject Technology, Inc., since acquired by Mentor Graphics acquiredthe company, which was focused on tools to execute and translate UMLmodels in the context of Agile MDA.
Campbell D.McCausland is a PrincipalEngineer, Mentor GraphicsCorp, where he is the chief designer of the BridgePoint UML Suite. Heis the creator of (to his knowledge) the very first model compiler thattranslates xtUML models to behavioral VHDL.
John Wolfe will be at the upcomingEmbedded SystemsConference Boston, September 25-28 at the Mentor Graphics booth#1201. In addition, CortlandStarret t will be conducting a series ofseminars. Go to www.embedded.com/esc/boston/ to check on the speaker's scheduledetails. Starrett is Engineering Manager leading development oftranslationtechnology at Mentor Graphics, responsible for the production of toolsandmethods for translating xtUML models into source code such as C, C++,Java andVHDL.
 UML Profile for System on a Chip.http://www.omg.org/cgi-bin/doc?formal/06-06-01
 Executable UML: A Foundation for Model-Driven Architecture, Mellorand Balcer, Addison-Wesley, 2002.
Otherresources on Embedded.com on UML and xUML :
1) Executable and Translatable UML
2)Need for modeling tools rises with design complexity
3) In Focus: Unified Modeling Language
4) Introduction to UML statecharts
5) UML evolves total system perspective
6) Introduction to UML Class Diagrams
7) State machine shortcuts