Site Sponsors:
Rhapsody Examples + UML Use Cases 

Off to a Shaky Start?

This first thing to be aware of when using Rhapsody is that *it matters* how you start it! If you are using Rhapsody in C, do not start a new project in Rhapsody for C++ or Java. (The rest of that truth table is also true!)

While that observation might sound moronically simple, when completing the sample exercise (yes, they do indeed work fine!) more than a few of us have been unable to get them completed for 'unknown reasons.' If you have / are having trouble completing the sample exercises in Rhapsody, check your unit type. (Right click on the main project name in Rhapsody, then select 'Edit Unit'')

Do This First

From the main Rhapsody menu, you can also select 'Help', then 'List of Books.' Notice that from User's Guides and oh-too-much information and reference materials, there are also tutorials for each and every language of choice.

After ensuring that your 'Edit Unit' language is what is appropriate for the tutorial that you intend to complete, complete one or more of them. They work great.


Did you do the exercises? Good! You now have a 'bottom's up' view of what Rhapsody can do for you.

But wait ' Before settling into your cubicle to radiate within your newfound superpower, re-visit that 'why are we doing this' -thread from the previous blog entry. Aside from documenting what we have done (in ways that even you and I will have to struggle to understand a few months from now), how has what we have just learned changed anything? While using pictures to generate code is cool, what was all that stuff about re-use, patterns, (bla, blaa ...) and managing expectations?

Codeless Diagrams

To truly appreciate what architecture can do for you, we need to start at the top. Specifically, we need to be able to create designs that even our mothers can relate to.

Impossible you say? Well, even if you mother is not exactly Grace Hopper, the Use Case Diagram (without a doubt the top-most diagram on the UML totem-pole), can help.

Use Cases

A relative late-comer to the OMG inventory of pulp-only artifacts, Use Cases allow us to begin to define our systems in a way that everyone can understand. Buy focusing on nouns and verbs, (aka Actors and Scenarios), Use Cases allow us to capture the essence of what others will want our system(s) to do.

(click above to view)

Simple, eh? (Yes 'My Mom gets it, too.)

While there can be a lot more to completely understanding use cases in all of their trivial glory (documentation formalisms, include 'v- extend relationships, actor inventories & inheritance, etc.) there are entire books dedicated to the subject. Feel free to pick one up... or not. What we have above is all we need to know for the moment.

The nice thing about Use Cases is that we can use them to discuss anything ' and at any time.

(click above to view)

When overlapping versions and other such messages, the use of colors can help a lot.

Next: Sequence Diagrams

-Stay tuned!

[ view entry ] ( 31456 views )   |  permalink
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 ] ( 2643 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 ] ( 7687 views )   |  permalink

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