Divide and Conquer

Introduction

As I always tell the people who attend my UML Trainings: without using Classes and Objects to split up the work your application must do, it is impossible to handle todays complexity.

Programing used to be easy, in the early days of computers and the early days of embedded. The first boards had small controllers on them that had a few kilobytes of ROM memory and a few bytes of RAM.

Getting these to work from scratch involved a day of reading some stuff and applying power to the board, then your first blinking LED was reality. (and how cool it was..)

Later using 16-bit controllers, still with Kilobytes but now more than a few,  but using ‘C’ in stead of Assembler, this was already complex. Could take a few days to get the first stuff running. (Not to forget that you had to learn ‘C’ as well…

With UML the initial effort increases again, you have to learn UML, ‘C’ (or ‘C++’ ) and you have to install a lot more stuff. But this is also doable and after the initial effort you’ll notice that things go faster.

The complexity, however, is still increasing and the only way to master it will be to re-use existing stuff. This is only possible if we have “designed for re-use”.

 

Modeling or Programming?

That is the question. The difference is not clear to people who use Rhapsody for the first time, it is, however, crucial for the way you use your models and how you do the implementation. So just breaking up in multiple Classes and Objects is no longer sufficient, you need to be able to divide your models in “Components” that can be re-used without having to look deeply into them to understand what they do.

Rhapsody supports a couple of ways to do that in your model. You can use (parts of) other models. In the menu you have “File”, “Add to Model”.

Then a menu pops up that lets you select a Rhapsody model (Or a file in a model, i.e. a Unit like a Package or a Component) You can also select “As unit (with a “copy” tick) or as reference.

  • As Reference, links the selected model element in the open model as a read-only reference. (Same GUIDs) You cannot edit the element in your Rhapsody model, you have to open the original model for that.
  • As Unit, links the selected model element in the open model as a writable reference. (Same GUIDs) You can edit the element in your Rhapsody model and it will then change the original model as well.
  • As Unit (with copy) copies the selected model element in the open model. (New GUIDs) You can change the element in your Rhapsody model but the original element will be left untouched.

GUIDs are the generated 128-bit ID’s that Rhapsody assigns to every Model element. Rhapsody uses the GUID to recognize model elements (It does NOT use the name for that!) So copying renews the GUIDs so there will be no name clashes with existing model elements.

Now try to model as independent as possible by using only unidirectional relations, eventually ports and interfaces. Use private attributes and operations when possible, at least describe the public interface as good as possible so re-use is easier while the re-user does not have to study the inside of your model.

 

Attention points.

  • Paths. If you use referenced model elements, be sure that they are in the right path on all computers of all project members… Otherwise check-in  and -out will be a torture. You have to manually adapt the paths in your model. It helps to use relative paths in your model

    General::Model::ReferenceUnitPath
    General::Model::PathInProjectList
    can be helpful there. You might also use an Environment variable to point to your working directory and sync that with your colleagues. (Like the OMROOT variable that Rhapsody uses to make it independent where your Rhapsody Share directory is)

  • Config Management. If you check in and out models and parts of models, it is easy to fetch a wrong version of a referenced model. Think about your CM structure!
  • Names. Don’t use default names like “default” for th package, etc. Use meaningful names that can be used in their projects without causing collisions.
  • Documentation. Is even more important when your model is re-used inside other models.

Tips and Tricks

  • As long as you make changes in your model _and_ in the referenced model, load both models in a project (Using “File”, “Insert Project”. You have to switch the active project to make changes but it will reduce time. Rhapsody saves the Workspace separately! (You can even edit it if you make changes to your paths)
  • Using Ports and Interfaces greatly improve the way you can use models in models.
  • There are more ways to create Interfaces, see my Techletter about using Interfaces.

 

Dividing up your models.

If you have made a model that represents the hardware you use in multiple projects, you can easily use that model in all projects that use the same hardware. The nice thing is that if you have your version system right (perhaps even with a check in the model..) and really defined your interfaces, then you can use different versions of the hardware without really worrying about you model.
Another advatage is that referenced model load faster.

 

That’s it! Happy modeling with Rhapsody!

Walter van der Heiden (wvdheiden@willert.de)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s