Site Sponsors:
SOA Meltdown 
Hariharan asks: "Can SOA predict slowdown?"

Response: Most can predict a slowdown for large companies who use SOA. Indeed, using the modern definition of an XML based service, SOA itself is inheritantly fat, chatty, and slow. Using a more broad definition (i.e. octet-optimized services), when you hit that XML parsing wall you can chuck that XML SOA noob mess and architect-in something a lot more customized, efficient, and - alas, closed. In XML terms, it is defined as favoring CDATA over PCDATA.

Indeed, until some motion is detected in the realm of ESXML, the best you can hope for when your XML based SOA inevitably becomes sluggish is to either chuck more hardware at the problem, or begin to design for a more customized, secure, and - unfortunately arcane - set of packet-level efficiencies.

Still, big companies do indeed need XML based SOA to help bring some order to the stove-pipe, duct tape, bailing-wire, file and protocol integration mess that we often see today. But be aware that the trade off between pumping metadata along with each and every packet, as opposed to assuming some form of implicitly strongly-typed packets, will still be the trade off for a very, very, long time.

Caveat Architect.

[ add comment ] ( 1782 views )   |  permalink
Blinking - Part One 
I would like to thank IBM's Jeffery Cohen for helping me get this model working under Rhapsody. In as much as we both had better things to do with our time, I appreciate his willingness to go that extra mile to " eventually " give me exactly what it took to make it all work properly!

Understanding Rhapsody Events

Rhapsody comes with some very good tutorials. While it might take a little know how to get the examples working properly, those tutorials can teach us a lot of what anyone needs to know to get things kick-started.

For the experienced modeler however, going thru the tutorials can be more than a little frustrating. Not only do the examples seem far too "cookbook oriented", but unless you work them all in very short order, any single tutorial fails to communicate the appreciation that there can be a lot more ways to 'skin YOUR OWN problem domain.

Embedded Machinations

Embedded developers who are new to Model Driven Architecture (MDA) concepts, let alone the Unified Modeling Language (UML), more often than not feel like there must be only one way " one model " that works.

Nothing can be farther from the truth! In fact, by levering any geek"s preference for inheritance, aggregation, composition, and / or static member functions, (let alone a preference for either C or C++!), modern object oriented models can offer us far, far too many examples. Each of us can simply draw many different pictures to accomplish the exact same thing! ... It is the type of diagram-drawing that can drive a computer scientist crazy.

Common Ground

The idea that any trim-and-proper analysis can yield wildly different models might seem heretical. However, in the same breath we should note that such frustrations typically come about only when we geeks are left modeling in a vacuum. In real life, most of us have requirements; Challenging problems to solve. Few of us are allowed to just 'cut loose.' --That is a good thing.

Why good? Because those who have been implementing their own models for decades can tell you that the larger the legacy, the more models tend to merge together. Indeed, through the years I have been pleased to discover " given the same requirements - that practically all modelers tend to come up with very similar views of their system. In fact, the first time I saw this, a grand total of four of us realized it at the same time.

What were we trying to do? Simple: We were trying our hand at creating the "best implementation" for a cross-platform expression of a Windows INI-stype file manager. Given such a well defined legacy, all of us pretty much came us with the exact same design... and one of us did not even speak English! Indeed, our Sections, files, an line-item name implementations were ALMOST EXACTLY THE SAME.

While it may sound a bit trite to mention the obvious, in order to calm the fears I might have inadvertantly raised earlier we need to note that in general the tighter the requirements are, the more common the model will be. Knowing that our models tend to be on as good as the requirements are is why Subject Matter Experts (SMEs) are so important to experienced Modelers.

The Blinking LED " Part One

So much for the level-set.

Today"s digital signal processors (DSPs), field-programmable gate array (FPGAs), microcontrollers, and / or classical embedded processor do not typically have a better output device available. The task of getting an LED to blink can be the quickest path to a solid proof-of-concept.

In order to demonstrate the high-points of UML + MDA on Rhapsody, lets consider the creation of what is becoming the "Hello World" application for the embedded world: Getting an LED to blink.

Console Blinky

From a Modeling point of view, getting an LED to blink is certainly easy enough to understand. While your team"s nomenclature for each of my depicted classes and / or states probably will (and should!) be different, the model / controller pattern should be readily understood by all:

Here is the state chart for ActiveController:

And here is the same for the LED:

Rhapsody Events

When it comes to creating events in Rhapsody, a lit depends (pardon the pun) upon how we fill out that "Features Dialog":

In this case, by specifying evOn for one, and evOff for the other line, Rhapsody creates the events we specify, for us:


Once the events have been defined, we need to raise them. There are many ways to to that, but in keeping with our selected Controller / Model Pattern, guess where the code needs to go?

Here is the way we decided to manage that Toggling State:

Here is how we translate + report that information (aka: The Reporting State) to the LED:

The LED Member Functions

Our first task is to implement a model that can be used on the console. Afterward, we will implement the same model on a TI 28335 DSP.

While you might be tempted to run off and compile the program now, please wait until the end of the section to do so. While Rhapsody might indeed allow us to animate our models, choosing to do so before you set up it"s innards properly can leave your implementation (in this case, itsLED!) with a few NULL pointers!

Below is a plausible "console blink" implementation. We will update this with your embedded code later on:

When using the Rhapsody Editor, in order for your changes to eventually make "round trip" back into the model safe and sound, note that any and all code needs to be inserted between those Rhapsody-provided comments!

The LED State

Last, but certainly not least, is getting those Rhapsody Events to call the above implementations:

By double-clicking on either of the above LED States, it is all too easy:

The Tricky Part

If you are like I was at this point, you might be thinking that it is all done; That we are ready to rock; That you are a Rhapsody LED Master... right?

I learned better. Indeed, while this particular model might look just fine and dandy to a Rhapsody guru, until we tell Rhapsody how to instance that LED class, ActiveController itsLED could be NULL. Evil, but very easy to overcome.

The Composite Class

To properly factorize our model, we need some objects. Objects are to Classes as Pies are to Recipes. To get a factory to create our object relationships, we need a Composite Class.

Because a composite class is more about the relationships between "pies" than their "recipes" are, when we first drop ActiveController and LED on the Composite Class, they look very odd indeed:

Once we right-click on each of the red areas to select Make an Object however, all looks a little more like it should once again:

Once we add the green Link and set the display options up properly however, we can tell that our pies, and their relationships, are as they should be. All that remains is to tell Rhapsody to use our new composite Builder object, exclusively:

Now you can run this project and it works " no problem!

Applying Animation

While using animation is relatively well documented by the Tutorials, for a well-documented thrill we should wrap up this first working example by enabling animation:

Once you have updated your Instrumentation Mode setting, Generate, Make, and Run (GMR) your program. Once it is running, then you can experience the thrill on animation " the very reason why we model things to look like this in Rhapsody " by clicking the "Animation Man":

To quote Darth Vader yet again: "All too easy"."

Other Modeling Options

According to IBM, using the Composite "Builder" approach (described above) is the preferred way of getting the ball rolling in our modeled relationships, but there are others. Some are good ideas... some not so good.

Good Idea?

For example, why not just assign or create an LED instance when we detect that itsLED in ActiveController is NULL? Not only would that approach work perfectly fine, but because we do not need to create a Composite "Builder" Object, our model becomes a lot easier to understand.

Because the above is fulfilling the basic object-creation aspect - one that would otherwise require the creation of a "Composite Object" - this self-creation technique allows us to keep those nifty Rhapsody-animateable class relationships. Marvelous.

Not So Good

On the top of the list of the "not so good-ers" would be calling the LED member functions directly.

(Admit it: didn't you wonder why you could not just call those LED on() and off() functions yourself? It is a type, after all...)

Indeed, in as much as the LED.On() and LED.Off() functions have been declared as "public", you might rightly think that ActiveController might simply use:


-rather than


The problem with calling the LED logic directly is that, even though the members are public, their generated implementations are not:


The next in line on the "not so good" list is with trying to use that myLED.GEN(evOn) thingy. While any code we write to use it will indeed compile and run, the desired events never make it to the LED.

Even more interesting, even though GEN() is a macro, neither .GEN(...), nor something like (&myLED)->GEN(evOn), works as expected... Whats up with that?

The Fix

The solution that allows us to use itsLED.GEN() is akin to our former observation. Namely, by default the class-member implementation is a pointer which is set to NULL. This time however it is far more obvious that while we asked for one thing (a concrete type as a concrete member), we got something else entirely (a NULL pointer to same.)

Rumor has it that there is a property in Rhapsody that we can munge around a bit to encourage it to put object instances wherever such pointers are placed by default. I or someone else will post it here when we stumble across it.


In the next part of this saga, I will demonstrate how to use Rhapsody to take our model over to the TI DSP.

In the meantime, keep on Modeling " You look mhavel-ous!

Best Regards,

R.A. Nagy

[ add comment ] ( 2711 views )   |  permalink

<<First <Back | 103 | 104 | 105 | 106 | 107 | 108 | 109 | 110 | 111 | 112 | Next> Last>>