Site Sponsors:
Introduction To Modeling & Rhapsody 

Wherefore Rhapsody?

For those of you who might not know much about it, Telelogic's Rhapsody is a Model-Driven Architecture (MDA) way of bringing UML Models to life. Recently acquired by IBM, Rhapsody adds a decidedly firmware / embedded flavor to the avid C, C++, or Java developer's tool-kit.

For the new developer, tackling the list of Rhapsody-related acronyms can be a bit daunting. For example, when taken in context with task of learning a new notational convention (UML), the sheer onslaught of the most common permutations of the initial UML diagram types (Use Cases, State Charts, Activity and Sequence Diagrams) can make the chore of mastering a new RTOS on a new DSP seem trivial by comparison.

Add to that pile a list of frameworks and objected-oriented concepts (encapsulation, cohesion, coupling, design patterns, OSAL, IDF, OXF, platform adapters, and more), and many a firmware engineer will feel understandably overwhelmed. That's the bad news.

The good news is that if we tackle both UML and Rhapsody a little at a time, the entire process of both analyzing what we have to do, as well as understanding the best way to impellent our models, the overall journey can be completely logical.

Learning Curves

Having tackled the Rhapsody portion of the learning curve myself recently, I wanted to share what I have learned. The process will take a few blog posts.

Getting Started - Rhapsody

At the time of this writing, there are only two diagram types that actually generate code. While one might be tempted to focus on these types exclusively, it is massively important to realize, especially for the firmware developer, that merely using a software modeling tool does not guarantee that our designs will be any good!

While that observation might seem trite, I have been surprised at how many engineers make the mistake of viewing software models in much the same way as we might see circuit / VSAL designs. While bad circuit designs are possible, UML makes it far, far easier to shoot yourself in the foot.

Before we get started using any UML tool, we need to ask ourselves a few questions:

Question 1: Why Am I Modeling?

This first question is simple enough. What benefit does taking the time to model aNyTHinG bring to the table?

In general, using any modeling methodology allows us to:

* Analyze what we have done. (present)

* Analyze what we have to do. (future)

* Agree upon what we need to do. (triage)

* Document what we need to do. (codify)

* Discuss ways we can team-up to implement what we need to do. (maximize re-use)

Not a bad list to start. While some of those might apply to your team or project, some may not. In general, the fewer of the above activities that apply to your project, the less value we will realize from any modeling techniques (let alone UML).

Question 2: Why Am I Using Rhapsody?

In general, using Rhapsody allows us to:

* Write code in such a way so as to leverage many OO concepts.

* Use an abstract Framework to use Semaphores, Timers (etc) in a more portable way. (OXF / IDX / OSAL -v- TI / ATMEL / PIC)

* Allow our code to be moved to new platforms (via adapters), if and as required.

* Ensure that our Analysis Models are implemented properly.

* Avail ourselves of 'Rhapsody in C', a great way to generate procedural code in an object-oriented manner.

Here again, the more you can relate to the above, the more confident you should feel about this particular tool selection.

1 + 2 = ?

Here is a good bottom line: When taken together, UML and Rhapsody allow us to:

* Discover patterns that we can leverage / re-use.

* Cooperatively leverage the patterns to deploy code quicker.

* Maintain better-documented code (helps us to re-use code quicker.)

* Have a common way to manage our projects across many platforms.

* Quickly understand what others have / are doing in their code.

I plan on justifying each of those statements, as well as to show how to leverage Rhapsody to achieve each goal, over the upcoming holidays.

Stay tuned!

[ view entry ] ( 2611 views )   |  permalink
Who are they paying for, anyway? 

Bleeding U.S Dry?

If you are a subcontractor you might have asked yourself a very common question: When the place where I work each day is paying for MY skills, how oh why is someone else able to take 30 to 75% of my wage?

No, I am not talking about the Government. While the 30% the 'Fed adds on top of that skim cripples us to taking home only about .25 - .40 on the dollar, every contractor who has had to scrimp and save to work hard while others bask in our earnings knows how much it hurts. How did this happen?

Who Ruined It for Us All?

Many years ago, a bunch of sub-contractors sued their contract employer (IBM) for benefits. To the horror of all genuine consultants, these secretaries actually won the lawsuit. From that dark day to this, in order to avoid those legal entanglements, every company in the U.S of A now uses "Shell Companies."

Shell Games

You know how the shell game works - Some 3rd party company contacts you. They tell you about a great contract job. You give them your resume, you win the interview, and you report to work. When the work is done, you are out of a job. In exchange for merely getting you an interview with a decision maker, you fork over many, many, dollars an hour to the middle man. How is that fair?

According to the U.S. Government, loosing full quartile percentages of our hourly wage *would* be fair if our employment continued after the sub-contract work was ended. Since it doesn't, the shell company should be either paying us as 1099 or W2S (statutory) Employee. That is what federal tax law says.

Taxing Terms

The difference between 1099, W2-S and W2 is a matter of ensuring that you can keep things like health insurance and other business deductions working the same way from contract to contract; Avoiding loss of benefits for pre-existing conditions.

When we work W2, United States Employment and Tax regulations assume that a shell company is taking care of us - after that single contract is over - as employees. For far too many of us independent contractors however, our shells just dump us back into the job search game again. A clear violation of the intent behind that W2 "employee" status, today most shell companies do not even reimburse employees for their travel and living expenses. It's a nightmare.

To The Rescue!

While we cannot deny that having head hunters can be valuable when we are out of work, we need to change the legal system so as to encourage our real employers to use us directly. To cut out the middle man.

In order to re-kindle the entrepreneurial American spirit, we need to ask our lawmakers to let contractors enjoy the fruit of our own labors. Moreover, rather than allowing a rare breed of idiotic consultants to terrorize our would-be employers with legal nightmares, we also need to ask the government to step in to protect companies from gratuitous would-be-employee lawsuits.

Let companies choose to hire U.S. without fear; Let good subcontractors once again reap the reward for our ability to keep our *real* employers happy. Most of all, we need to liberate our long-term earnings from a host of do-nothing middlemen. After all, is the company where we show up to work each day paying for our ability to get the job done, or the ability of someone else to find our resume on or

Dumb & Dumberer-er

The mere fact that modern human resource professionals are actually forbidden by their legal departments from using Internet resources to locate their own employees underscores the foolishness of where our country has arrived today. In the spirit of competition; in anticipation of rekindling the genuine supply-and-demand mentality, if we want to keep America competitive in the world labor market, don't we need to cut out as many middlemen as possible?

[ view entry ] ( 7662 views )   |  permalink
Adding Javadoc to NetBeans 

What is "Netbeans"?

Netbeans is a free Java developers environment from Sun. IMO is is much easier to use than Eclipse.

The best part of the deal is that NetBeans is 100% free. If you are new to Java Software Development, NetBeans is a great place to start before you upgrade to a professional IDE like JBuilder.


Once NetBeans is installed, most folks also want to install the on-line help for Java.

For the perplexed, to install the Java documentation (know as JavaDoc) all we have to do is:

(a) Download the official JDK docs from

(b) Unzip the doc into the JDK directory (on MS Windows, mine was under C:\Sun\SDK\jdk)

(c) From the main NetBeans Menu, select "Tools | Java Platform Manager".

(d) Select the platform you need to Javadoc in the left side of the Platform Manager.

(e) Click the Javadoc tab. Select Add ZIP/Folder. Type in the directory location of the newly unziped Javadoc files.

(f) Close the Dialog. Your changes will be saved automatically.


The hardest part can be finding the proper version of the help files you need. If you were looking for JavaHelp on version 1.5, then try

[ view entry ] ( 2752 views )   |  permalink  |  related link

<<First <Back | 83 | 84 | 85 | 86 | 87 | 88 | 89 | 90 | 91 | 92 | Next> Last>>