Zurück zu Willert.de

File & Object association : CodeGen problem

Rhapsody Model or Codegeneration topics

File & Object association : CodeGen problem

Postby Karthik » September 3rd, 2010, 3:37 pm

I am using Rhapsody 7.5 and Rhapsody in C. The generated code doesnt compile if the model has a File element and an association relationship with an Object element.

Before getting into the problem, let me put two points:

1) For any association between elements, Rhapsody generates mutuator (helper) functions Set & Get (like setIts_object1, getIts_object1 etc).
2) These helper functions are generated with 3 levels as follows
setits_object1 that calls setits__object1 that calls setits___object1 which actually sets the values properly.

I am having a File element and an Object element with association relationship. When I generate the code, the code for the File element has incomplete helper functions generated.
It generated setits_object1 & setits___object1. setits_object1 calls setits__object1 but setits__object1 is not generated and when we build it throws compiler error.

Am I missing anything? I think I am not. Any thoughts!!! Have anyone faced the same issues?
I feel it may be a problem in Rhapsody CodeGeneration.

This has been posted in IBM forum, just in case, if any one here can give his/her thoughts, I am posting it here also.

Posts: 11
Joined: October 2nd, 2008, 1:40 pm

Re: File & Object association : CodeGen problem

Postby Skywalker » September 9th, 2010, 12:41 am

What is the idea, what is the goal behind defining a bidirectional association between an object and a file?

I cannot see a sense in doing so and would probably blame the model checker, which should/could disallow the user to do so.

Let me explain some background / philosophy before answering the concrete question.

In general - from a coding / modeling style guide I'd recommend to use directed associations (or aggregations or compositions) as far as possible and I'd try to avoid unadorned bidirectional relationships of any kind if not needed. (Of course they can be very useful in some cases)

If there is a relation from one classifier to another classifier, then what does it mean?
- by default (multiplicity of 1), probably a pointer in the first classifier's struct, pointing to the second classifier's struct.
- with fixed multiplicity (e.g. 10), probably an array of pointers in the first classifier's struct, each pointing to ...
- with multiplicity many (e.g. "*"), probably a RiCCollection type or a RiCList type struct element to manage pointers to ...
- with multiplicity many and a qualifier, probably a RiCMap type struct element to manage ...
This is straight forward and a quite logical "OO"-style implementation if a class is on both ends of such a relation.

If now, such a directed relation points from a file to a class, then the generated pointer type attribute could be of similar style as above... only it would now be a variable on file level, not an attribute in a struct... but the element would still be pointing to a struct.

Finally let us now have a relation pointing to a file element... what should it point to?
Files cannot be instantiated, files do not have a struct containing all their attributes and relations, files have flat variables on top level... which of the variables should the relation now point to?

In my opinion it does not make sense to draw a relation from any model element to a file, because there is no data entity that could be referenced.

If it comes to using file model elements, I'd recommend to use dependencies with stereotype <<Usage>> instead of using relations.

Now the concrete answer:

In your case, where an object and a file shall probably reference each other, I'd either use two <<Usage>> dependencies or I'd use a directed association from the file to the object plus a <<Usage>> dependency from the object to the file.

If you really insist on using a bidirectional relation in such a case, then you may use some "relation end" related properties in order to switch off the generation of some of the useless helper operations. By default, Rhapsody would/should implicitly implement a relation from any element to a file with a <<Usage>> dependency. Looks like this specific scenario with a bidirectional relation involving a file (which does still not make sense in my opinion) is not recognized properly, so that a class-to-class relation implementation pattern was applied.

May the force be with you ...
Posts: 74
Joined: October 31st, 2007, 5:09 pm
Location: Milkyway, classic 9-planet solar system

Return to Modelling with Rhapsody

Who is online

Users browsing this forum: No registered users and 2 guests