From UML to Embedded System

7/28/2019 From UML to Embedded System

1/8

2005 Mentor Graphics Corporation. All rights reserved. 1

From UML to Embedded System:Is it Possible?

Stephen J. [email protected]

Mentor Graphics Corp.7400 North Oracle Rd.

Suite 365Tucson, AZ 85704

United States

www.acceleratedtechnology.com

AbstractSoftware design tools have been around for over 20 years now. Although they have

improved greatly over that time, there seems to be a problem with generated code: it isstill too inefficient and unreadable. Until now.

At one level, building efficient executable UML models is trivial: write some code and

put some boxes around it. The code will run as fast as you build it, and the boxes (for aclass, eg) can easily be turned into some appropriate code. But the value added from this

approach is low, and the mental overhead high.

An option is to generate more of the code from boxes, under the supposition that theboxes are more abstract and so more productive than writing code directly. This is

intuitively correct, but in practice it tends to break down because bit-fiddling code cannotcheaply be represented in UML. It is, in fact, more productive to write the code

directlybut then we lose the productivity advantages of abstraction.

An alternative is to make UML both executable and translatable. This approach lets thedeveloper verify that the design is solving the problems he intends to solve by executing

an executable UML model and debugging the models behavior before any code is

generated. Moreover, translation is carried out using a set of rules that builds a system ina strict and repeatable manner. The developer has full control over these rules so that themost appropriate code for a particular architecture can be generated.

Rather than bit-fiddling the generated code, a more structured and repeatable process is

now used. If there is a problem with the behavior of the application, then the model ischanged accordingly; if there is a problem with the performance of the code, then the


2/8


rules are adjusted. This separation of the application from the architecture (thetranslation rules) results in a more maintainable and efficient system.

1. The Problem

Embedded software developers have a reputation in the software world at large for being

a bit slow. Not dim, you understandeveryone knows we tackle sophisticatedproblemsbut slow to pick up on new software tools and languages.

This accusation has some truth. Today, some 77.2% of projects use some C, another

46.2% use assembly language, and 44.2% use C++.1

(The numbers add up to more than100% because a project may use more than one language.) Hardly anyone in IT would

think of writing in a language as close to the machine as C, let alone assembly code, thesedays.

We embedded developers would quickly retort that our problems have to be very

efficient, very small, and in many cases, very fast too. Moreover, we need to havecomplete control over the generated code, and that is taken away from us by

programming language compilers.

We recognize, of course, the advantages of writing code at a higher level of abstraction.After all, studies for nigh thirty years have shown that we can write the same number of

lines of code per day, irrespective of the language. Since we get more functionality for aline of C++ than for a line of assembly, it stands to reason that we can increase

productivity if we use a more abstract language.

Meanwhile, the IT folk are moving towards higher-level-still languages such as theUnified Modeling Language, mostly as a sketching language, or as a blueprint for further

software development. The UML is also an executable language, with state machines formodeling concurrent behavior and exploring synchronization issues, which would make

the language appropriate for the embedded market, but it is so far away from the machineit seems at first blush to be even more unlikely than using C++ in the embedded space.

But what if you could generate small, efficient code? And what if you could havecomplete control over it? That would give us the productivity advantages of a higher-

level language while still meeting our performance constraints. Then moving from UML

to embedded system would indeed be possible.

We begin our discussion, then, by describing a model-based approach to systems

development, based on executable models.

1 Venture Development Corporation, The Embedded Software Strategic Market Intelligence Program,

2004.


3/8


2. Model-Based Systems Development Process

Figure 1: The overall development process

Idea

The first step, shown on the left as a light bulb, represents the concept behind an

embedded project, a marriage of the desirable, as expressed by the participation ofmarketing, and the available, as expressed by the participation of hardware and software

experts. Defining the concept behind a product is often a compromise and trade-offbetween possible features desired by marketing and the capabilities that can be delivered

by a given hardware-software architecture.


4/8


At this point, the development process bifurcates into application and architecturesections. These sections may be carried out in parallel, but we describe the application

first.

Application Models

Application models are executable, and consist of three primary diagrams as shown inFigure 2. [For a complete description, see 1; for an extended example, see 2] The first

part is the declaration of the conceptual entities in a particular subject matter; these arerepresented using a Unified Modeling Language (UML) class diagram. It is critical to

recognize that our use of a class diagram says nothing about the software structure. Ina translatable model, a class diagram is only a convenient representation for a

conceptual grouping of information and behavior.

Behavior over time is represented using a subset of a UML state chart diagram (thesecond part of Figure 2). There is a state-chart diagram for each object of a class2. All the

dynamic behavior in an application model takes place as a part of a state machine.

An executable model is meaningless without rules that define execution. In executableUML, each state machine executes concurrently with all other state machines. They

communicate by sending signals that define precedence relationships between sequencesof actions. Just as with class diagrams, the state chart diagram does not imply an

implementation; signals may be implemented in any manner that preserves the desiredprecedence of actions.

2More accurately, there may be one state chart for each instance and there may be one state chart for the

behavior of the collection of instances as a whole. Moreover, instances may participate in subtyping

hierarchies. See [3] for more details.


5/8


Figure 2: An application model example

Actions are the last of the primary artifacts of executable UML. Actions are alsoimplementation independent, in that they do not assume a software structure. Consider,for example, a function that sums the total time used in the last n phone calls. Looping

through a linked list of recent calls is one way to implement this, but that definition reliesof a specific software structure: a linked list. UML actions are cast so we first get the

times for each of the calls and then sum them up. This subtle difference in expressionallows us to access stored the data in any way we choose, so as to get the best

performance.

Other diagrams, such as communication diagrams, can be derived from the primarymodels as required for presentation and comprehension purposes.

Architecture

Work on defining the architecture can take place at any time in respect to work on

defining the application. This unexpected property comes about because the architectureis not an elaboration of the application but rather a set of rules that define how to

transform an application written in executable UML into an implementation. Aconsistent set of rules that target an architecture is called a model compiler.

When we build an executable UML model, the meaning of the model is stored in a

database. The diagram shown in Figure 2 creates instances in the database as shown inFigure 3. The structure of the database is given by the elements of the executable UML

language. Hence, we have a table Class to store information about classes, and a tableState to store information about states. The structure of this database is called a

metamodel.


6/8


Figure 3:

A model compiler applies the architecture rules to the application as stored in thedatabase. The rules traverse this database in accordance with the desired target output;

they also manipulate strings to produce text acceptable to a compiler in the language ofchoice. The result is text on some output streams that may be compiled. The model

compiler is oblivious to the language; it merely manipulates text.

It is here that the rubber meets the code: the performance needs to be adequate. Shouldyou find the code is too slow or too big, you can quickly identify the cause and write a

rule to fix it. For example, we may find that turning the magnetron on and off every somany seconds is not fast enough. In that case, you should fix the rules to generate a

periodically executing task, not diddle the generated code: Write the new rule, add it to

the rule set and test it. That way your expertise can be leveraged across the organization.

Off-the-shelf rule sets are available from vendors or internal organizations that have

modified rule sets to meet the needs of a specific environment or product. The reason forsuch modification is to meet performance constraints on speed or memory and perhaps to

interface to a library or some legacy code.


7/8


Compilation

Once the model compiler has produced text, it can be compiled by a programming

language compiler. This represents the transition from the abstract world of model-

driven architectures to the familiar embedded software development environment. Anopen model compiler makes the process controllable and seamless.

The generated code may be in a selection of familiar languages:

1. Standard C. This is still the most widely used language for embedded softwaredevelopment.

2. Standard C++. Although not embraced by all developers, C++ is usedincreasingly often for embedded code.

3. C with special features. Sometimes standard C does not map directly onto aprocessors architecture and a special variant is useful. Or you need to meet

certain standards such as MISRA.4. Assembler. Although high-level languages are the now norm, assembler has its

place, particular with smaller devices.

This covers all the widely-used embedded development languages. The next step is to

simply put the generated code through the appropriate tool-chaincompile, assemble, linkwith relevant libraries (e.g. RTOS) for the chosen target.

Model Debugging

The application model has been verified; the architecture rules have been verified; themodel compiler is part of well-tested tool set. Is there anything left to do? Intellectually,

no. But we may still get it wrong. At that point, it is helpful to be able to examine thegenerated code in action and debug the resulting code using a debugger. Just like trying

to debug assembly code generated from a C compiler, this can be difficult without asymbolic debugger. A model-level debugger allows us to set breakpoints in the model,

halt the running code, and hyperlink back to the model element that caused the problem.

Prototyping

Frequently, hardware and the embedded user interface are being assembled as the

software is being written. To provide a common platform for all developers, a host-compiled simulation environment can run embedded applications on the developmenthost. This provides the ability to simulate the complete system, including hardware and

peripherals, I/O and the applications GUI, which allows you to start development beforereceiving hardware. With several powerful additions including visualization, monitoring

and tracing tools, this also provides expanded network simulation and the ability tosimulate not just the applications GUI, but also the complete Man-Machine-Interface

(MMI) of the product under development.


8/8


Debugging

Beyond the standard debug support, you need a number of advanced features that enable

in-depth analysis and debugging of complex embedded systems. Features for establishing

the state of the machine, identifying areas of code for performance gains and interactingwith the program executes are all required.

Deployment

Of course, the next step is to move on to deployment

4. From UML to Embedded System

The software development flow of Figure 1 says it all. From idea to deployment.

The key concept is that ofopen translation rules. These allow you to tune the code to

produce anything you need.

That said, we have found that better than two thirds of projects have no need to tweak therules at all from the out-of-the-box model compiler.

Yes. Not only is it possible to go from UML to embedded system, it is easy.

5. References

[1] Stephen, J. Mellor, Marc J. Balcer. Executable UML: A Foundation for Model-DrivenArchitecture

[2] Leon Starr,Executable UML, The Elevator Case Study, Model Integration, LLC.;

From UML to Embedded System

Documents

Transcript of From UML to Embedded System