Best Practice Contradicting group in logical model

[Rouven]

Hi everyone,

and again a question regarding your UML expierence. I'm working on a domain model which primarily targets the business for the time being. Since we are combining several systems into one I have users with different perspectives meeting in the target system for the first time.

One of our goals for the domain model is to define the logical terms used within the project and thus used in use cases etc. in the model.

What used to work rather well so far was to use abstract classes not only as a means of identifying common aspects, but also to introduce wording for the groups. For example if the business needs a term "Vehicle" to cover entities "Cars" and "Trucks", I'd introduce an abstract class Vehicle and make Cars and Trucks specializations.

This takes me to the problem of conflicting perspectives, let me give a simplified example:
Consider 3 business entities A, B, C.
User group A thinks in terms travel vs. duty. A and B represent travel, C represents duty.
User group B thinks in terms of ground vs. air. B and C happen in the air, A is on the ground.

Now I'm wondering how I might get these groupings introduced into the model. One alternative would be multiple inheritance in terms of multiple generalizations/specializations.
A+B specialize Travel, C specializes Duty
A specializes Ground, B+C specialize Air

Have you come across a similar problem? What was your solution?

Thanks for you input!
Regards,
Rouven

[qwerty]

I remember that Paolo has recently started a similar thread. Sorry for not remembering the title...

Just a thought: these are different perspectives of the same whole. They have the same right to exist and should be modeled accordingly. I always get a bad feeling when it comes to multiple inheritance. Is a swim car a boat or a car? I'd say its a swim car. You might define abstract classes above car and boat from which all can inherit parts. Finding these can be a PITA. And often you're lead in a cul-de-sac. An abstract motor for boat and car is probably nonsense since you have so special demands for both that a common class reduces it to the plain metal.

q.

[edit:] http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1323414994

[Rouven]

Hi there,

thanks for the link to the other thread which is an interesting read but unfortunately can't provide "THE answer" (which I assume does not exist in any case).

Just taking up your example of the "plain metal", this is not the case for me. I have classes in the model that are structurally different and also semantically different, which has led me to separate them into different classes.
Now for the specifications I want to make things easier and fix the terms that everyone appears to know but really doesn't because the interpretation varies.
If I prohibit the use of non-domain model terms I can force my users to specify "find the name 'x' in all objects of type A and B", thus pulling the different classes A and B into each spec. On the other hand it would be great if I could just find a way of representing the term "Travel" as meaning objects A and B so that I can re-phrase "find the name 'x' in all travel". Or in your example: "find the motor which has 8 cylinders" instead of "find the boat or car which has 8 cylinders".

Rouven

[qwerty]

I guess I see what you mean and I have a phenomenal proof for that. But unfortunately the margin is too small to write it down ;-) (Freely adapted from Fermat)

q.

[Robert Sheridan]

Informally you could use aliases or use tags (create a stereotype or add them adhoc) with a lookup to a set of elements that represent those broader terms.  I have used the latter to associate changes with components that represent different parts of the system so that I can show which components a change will effect, you could have a element for each of your broader terms and link it in the same way to your classes.  The tag approach has the advantage of being structured and allowing you to make multiple links of terms.