Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

UML Use


Is anyone using UML?

Though I often hear that question, perhaps a better formulation is: "Is anyone other than well-funded pioneers like NASA using UML to auto-generate code?"  For the dream of model driven design is to layer a new level of abstraction between the developer and the machine. Design the model, press the "generate code" button, and smart tools build your system.

It's a heck of a dream. But what's the current reality?

Recently events have provided some useful data. This year Telelogic acquired iLogix, which sells UML tools to the embedded space, and in doing so provided a glimpse into the privately-held company's books. Last year iLogix did some $27m in sales earning an 11% pre-tax profit.

Of course, some of that $27m comes from non-tool sales like training. Those numbers aren't published, but it's hard to imagine a successful company that sells more training on their products than products themselves. So let's guess iLogix sold $20m worth of tools.

Squirrelly salesmen who won't answer a direct question without first getting your entire DNA code into their database make it hard to know what the tools sell for, but a guess of $10,000 a seat is probably not entirely unreasonable. That's some 2,000 seats in a single year.

It's believed that there are some 225,000 firmware developers in the world. Therefore something like 1% of them bought an iLogix tool last year. Though that's a tiny number, the cumulative purchases over a number of years is impressive.

iLogix is hardly the only MDA (Model-Driven Architecture) vendor around. The biggest is probably IBM, though they don't focus on the embedded space. Artisan, MathWorks, and others all offer products. A Venture Development report ("The Embedded Software Strategic Market Intelligence Program 2005") pegs MDA sales from IBM and MathWorks together at 13 times that of iLogix in this market.

I recently did a survey in which roughly 5% of the 659 respondents reported automatically generating code from their UML designs. But most interestingly, there was no correlation by industry. Developers working in automotive, aerospace, telecom and more all use these tools. UML use isn't limited to a few well-funded pioneering organizations that can afford failed projects.

Such surveys and studies are notoriously unreliable. But they paint a picture, one that suggests many of our colleagues are indeed busily using UML and other modeling languages to build embedded systems.

Are you deep into UML? Is it working well for your company? How are the tools?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at [email protected]. His website is www.ganssle.com.


I've been an UML advocate for a long time. Currently, we are using Enterprise Architect ( http://www.sparxsystems.com), which have many interesting features at a very reasonable price (

This tool has automatic code generation for classes in Java, C# of C++, but we are using C in the firmware development, therefore we don't use the generated code. It also provides Model Drive Development transformations.

The tool is very complete, although, it seems to be focused mainly in Desktop Software Development, not for Embedded System Development.

One of the main issues we have is that not all developers have knowledge of the UML notation. Therefore, the diagrams are sometimes not UML-compliant. We are solving this by having internal training sessions in UML diagrams.

It took some time for everybody to get used to the diagrams and notation (including HW development, and Management), but slowly, we are getting the message out.

Unfortunately, State Chart and Executable UML Tools are expensive for small companies, and it is difficult to convince management that a $10.000 tool will improve firmware development.

- Alex Ribero


CASE tools - one of my favourite rants. Was it Grady Booch that penned "CASE tools have allowed merely bad designers to create bad design more quickly."

My own experience has added to this dim view of CASE tools - like the model with a wiring diagram for context and 12 layers of Data Flow Diagrams, for a system with lots of control but virtually no data transformation. Aside: If the reader requires an explanation of this example then they showed enroll on a real-time methodology course.

My solution to this endemic problem? Make sure the development team can convince you they are fluent in analysis and design methods (using pencil and paper) before investing in CASE.

Rant over!

- Martin Allen


Martin's got a point - Giving a $20k tool to a $50k developer doesn't necessarily turn him into a $70k developer. A tool is an amplifier; it allows the user to do more of what he already does faster.

Before giving a CASE tool to a developer you might want to ask yourself, "Do I really want TWO of this person working here?" If the answer is yes, the tool may be worthwhile. If not, consider putting the money into training instead.

- Dave Hinerman


I have used UML based MDA (Model Driven Architecture) on 2 medical devices: an automated sample handler and a cervical cancer imager. The first used a Rational (now IBM) modeler with Pathfinder Solutions code generation technology, the second Rhapsody from Telelogic.

We did a very carefully designed and reviewed object-oriented analysis and design on both projects. Both projects delivered products to market and the tool sets are still currently in use.

The major effort in both projects involved bringing the tools on-line and learning how to use them effectively. Once that was accomplished and our design was solid, having up-to-date models has proven valuable in gaining FDA approval and in maintenance development.

- Bruce Levkoff


ok... I use UML from time-to-time. Mostly; I use UML to help generate C++ header files, and all those interfaces. However; from what I can see, This UML-to-code thing looks very much like an attempt at yet another 4GL language. There are all these promises made about better code...but the bottom line is still that it takes someone with some modicum of design skill to pull of the overall architecture... or to do a better design!

One of the glaring problems is that it seems that engineers understand block diagrams and pretty pictures, with a bit of descriptive text....much better than a full blown UML diagram complete with interaction diagrams!

- Ken Wada


After having used UML based CASE tools for the past 6 years, I must say they are great for prototyping. Other than that, I'll never use them again. Merging changes from multiple developers into one graphical model? It never worked. Code generation? Only the framework and how much time will that save you. Hardware abstractions? I can do that myself AND have the option to tweak it the way I like it. Executable models? Unless I see more fancy examples than the simple microwave with a light and door, I'm not convinced. And why are those articles describing the advantages of UML always written by CEOs, CTOs and VPs of the companies trying to sell these tools?

If we have to agree on a graphical notation for design, why not use UML. Other than that, no thanks.

- Jos Dijkstra


I am writing C code from 5 years ago for embedded automotive and aerospace systems.

the point is that I want to know why the UML-based generated code is not used widely in the embedded arena till now.

In fact, I know about UML as a tool for rapid prototyping for desktop, but I do not know it is problems in the embedded software.

Once, I used Simulink to model/analyze the stability of a mechanical system and design a conroller for it. i then used the generated code to make HITL simulations but did not used that code in the final implementation.

the point I wanna know is what is the problem with the generated code. IS it inefficient ? or it is buggy?

- Hesham Shokry <


UML certainly isn't the "only game in town" when it comes to generating code from models! For the last six months I've been in Ontario working on engine controls (FADECs), and the control laws for these systems for the new crop of very light jets (VLJs) are written in a graphical tool called SCADE from Esterel Technologies. In my opinion it would not have been possible to do these projects given the code complexity and the safety level (RTCA DO-178B Level A) without a tool like this that both understands controls and can "enforce the rules", yet the number of software engineers who have even HEARD of this technology is extremely small. (It's also possible to prototype the same controls in Simulink for development and then port them over later.) Hope this helps get the word out.

- Jeffrey Lawton


Ive been involved with UML and MDA for two projects and starting my third,

and like any tool its only as good as the craftsman that uses it. Like

any tool, if you dont know the basics and dont put the effort into trying

to improve your skills you can only get out of something what you put into it.

Like anything in this business if you dont continue to expand your skills you

may be flipping burgers in the near future.

UML is an investment, not only by the company you work for but also by you.

Currently we are running a study group with both users and non users of UML.

During each of these groups you hear "thats a good idea", or "I didnt know

that". So, if nothing else UML at least gets the juices going.

Were UML really shines is when your supporting or enhance a product. With a

well done model its easy to visualize were and what the changes should be and

better yet it makes it easy to explain them. My boss is not a UML user but I

can very quickly explain to him what the system is doing with a set of models

in front of us.

- Mark Bangert


As a engineer familiar with coming to work on projects late in their life cycles, it was interesting for me to read the letter from Mr. Levkoff. I joined the company he refers to just after he left and worked on the products he modeled using UML/MDA. First I must say that of all the criticism I heard about the product none of it was software related! There was not one complaint filed and investigated that was determined to be a software related failure. Second, proposed enhancements to the software were easy to follow, explain and implement using the UML models he left behind. Kudos for a job well done.

Sure if you give incompetent carpenter a better hammer and saw your not guaranteed a better house. However, if you give a great carpenter the same tools you may just get a house of your dreams.

- Peter Kruczynski


For smaller companies UML's a good booster stage, but it isn't going to get us into orbit. At some point it becomes extra weight and costs more to use, in time and productivity, than dropping it and continuing on unimpeded.

- Trevor Ignatosky


My company made a major commitment to using UML in the development of both embedded and enterprise software as part of a major upgrade to an Air Force system. The system will consist of a loosely-coupled, heterogeneous network of some 20 processors running about a million lines of code. The effort is not proceeding smoothly and I dont think that anyone here believes that we will ultimately use the UML models as anything more than blueprints for hand-coding. There are several reasons for this.

1. UML is not a methodology. My organization has struggled with the development of a software design methodology that utilizes UML effectively. Not only was it difficult to form a consensus among our technical leads about how best to proceed, but those with most experience in model-based development had a hard time making up their own minds about which methodology to use.

2. The tool stinks. Sorry I-Logix, but for what we paid, I expect better. My company's list of complaints is a long one indeed. Chief among them are inconsistent or just non-existent support for many UML 2.0 features, important functions that are just too difficult to use and poor support for multiple developers working on the same model. And please don't tell me that these problems can all be solved by purchasing more training!

3. The old-timers think UML is a bunch of hogwash. This is nothing new; numerous articles have appeared in these pages regarding practitioners' unwillingness to adopt the next generation of abstraction. While healthy intellectual skepticism is a good thing in any endeavor, taken too far it is detrimental to organizational cohesiveness. My project has definitely suffered from a lack of buy-in by some of our senior technical staff.

My experience with UML leads me to conclude that model-based design will ultimately become the norm but that the technology still has a long way to go. I would not advise that anyone bet the farm on it for large-scale projects yet.

- Hugh Shane


I've been using modeling diagrams for 10 years on embedded 8-bit projects (first Shlaer-Mellor, now UML). I've never used the generated code in a final product and I doubt I will until the tools come up with a better way to specify and debug the models at the algorithm level.

UML is an extremely powerful anaylsis tool. It facilitates the mapping of requirments into design and most importantly helps identify how the different peices of your design will work together. You can quickly identify the roles and responsibilites of your classes (or modules), and ensure that a method has all the information and access it needs to accomplish it's task. What it lacks is a graphical langauge that lets you quickly and easilly define code execution at the algorithmic level.

I think there could be an interesting connection between LabView and executable UML. They both have the same concept: draw a picture and execute it. Generally LabView works at a lower level and UML at a higher level. If UML adopts a graphical execution language like LabView, then you might truly have an executable model from top to bottom.

- Tony Gray


Two points: 1. UML / OCL is really good for the initial analysis phase. Thereafter, more formal tools (such as SPIN) would be more productive than UML tools if only engineers took the time to explore practical (and free) tools based on discrete math, rather than endless semi-formal diagrams that cannot really verify an idea before committing it to code.

2. You do not need a tool to model software. First problem for most engineers is when (and when not) to abstract. An algorithm is better modelled in C than UML. After all they are both abstractions of the final system.

- Manoj Phatak


I have used UML and Simulink on few projects.

UML CASE tools help jotting down during architecture/requirement phases helping with clarity of ideas. These phases are not directly related to programmer productivity (in a measureble way) and code generated corresponding to this design level doesn't accomplish much action. So from programmer's point of view, the tools are less used. The generated code doesn't have enough logic/action to give programmer productivity boost. However for large SLOC projects UML usage remains of value through diagrams/views as documentation tool.

Also UML usage may not prevent bugs in the software.

On other hand are more useful tools like Simulink because of the logic to code translation which it does so well that programmer productivity is boosted and bugs are caught at logic level rather than code level. Simulink actually helps in keeping bug count less by keeping down logic-to-code translation errors.

Simulink like tools are bogged down by high cost.

The actual power lies in visuals, and is common to both UML and logic programming tools.

May be the next generation of CASE tools will cross UML and Visual logic programming (like Simulink) + Concurrency in one tool and it would address architects, designers and programmers all.

- Suresh Shukla


I would say that vast majority of cases where production code is generated from models are based on other languages than UML. For instance, Mathworks that is mentioned in the article is not using UML but their own languages. Similarly is done with other tools that generate adequate production code " a code that is not needed to be modified after generation. For example, Labview that generates working embedded code is not based on UML. Review of large scale industry experiences (see www.dsmforum.org/cases.html) actually shows that producing code from design models requires that the modeling language is domain-specific " just like the generator is made for a specific purpose too.

The reason why UML can't support adequately code generation is simple: it was not even made for that purpose. Drawing a class rectangle in a class diagram or entering a variable name into an element of state machine gives very little value. All the code generator makes then is translating the programming concept expressed in a picture to text. Developers find usually then easier to write the code directly than use a picture. This is also one reason why many vendors promote reverse-engineering - and kill the possibilities for useful modeling at the same time. I would argue that design models would be more useful if the modeling languages could raise the abstraction and hide unnecessary complexity in a similar way like 3GLs did for Assembler. Unfortunately the close mapping of UML concepts to current coding concepts prevents this effectively like the past 10 years of trying generate code from UML models clearly proves.

- Juha-Pekka Tolvanen


Read your article about UML use in Embedded.com. Apparently we are part of the 5% that are using UML with code generation in the Embedded market. That puzzled my manager; Are we some sort of strange species from another planet that have seen the light?

We started using ObjecTime in 1997 or so in a single project developing a large printer. The embedded software for these printers is (to a large extent) state and event driven and that convinced the software coach to start with ObjecTime. There was a huge learning curve for the engineers who had to think in OO while still keeping the processor performance in mind. But management thought it was a good idea (better than using Cradle) so the project was able to make the transition to OO. A 2nd project followed and all the models were converted to Rational Rose RealTime. A Reuse group was assigned to the 2nd project to create reusable components (like Information and State Managers and a Generic Function). This reuse group is currently 'controlled' by a group of SW architects of all involved projects to control the common factor between all these projects. Now any new project using the proposed architecture and thus the reuse components can make a jump start. Now some projectleaders scream: How on earth is it possible that the first 'Lab-model' is running functional embedded software after only 6 weeks?

Last year we 'discovered' a new technique using passive classes only. Since that time the software on microcontrollers (like Infineon and Arm) in a distributed architecture are also running UML-generated code (state and class digrams only). I wrote a white-paper on this issue together with a former IBM-product manager and told the story in San Franciso in 2005. (ETP-401: Model-Driven development of Resource Constrained Embedded Applications) http://www-128.ibm.com/developerworks//rational/library/04/r-3151/index. html Unfortunately Miro Samek has a session at the same time (Practical Statecharts in C) so I had only 30+ attendees...

I told my manager that managers often scream that SW developers should start to write code in stead of fooling around with these expensive tools (not him!). The light switches off before they can see it! Succes stories are not told enough by the industry, only by the tool vendors. Another problem is that IBM Rational Rose RealTime is treated as a niche product by IBM. They rather sell Lotus Notes licenses. The product however is a jewel and worth every penny. It is much better than Rhapsody, although their latest version 6 has made a lot of progress.

- Ton Janssen


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.