umlgeneralization

Multiple generalisation and generalisation sets

I'm try to model stock exchange data, and in doubt how to model the situation: I have 2 types of deals on stock exchange (spot and future), and have orders and trades. So I can do 2 types of deals with isDisjoint generalisation set, and Trade Stage class with isDisjoint generalisation set, and then I can model Trade with multiple inheritance from all the above. But I intuitively dislike the result. Is it possible to model all the above in a better way? enter image description here

Updated Version of the model.

enter image description here

Solution

  • Thanks to @GerdWagner for pointing to me obvious mistake that I've made (and was since fixed).

    There are several issues with your hierarchy:

    1. Trade inherits all parents. So it is at the same time Future, Spot, Traded, and Ordered. That makes little sense.

    2. {disjoint} is applied to both hierarchies, but in your Trade you are inheriting all of them, so effectively Trade is violating isDisjoint property of the generalization set.

      (9.7.3) if isDisjoint is true, then no instance of any of the specific Classifiers may also be an instance of any other of the specific Classifiers.

    3. Trade type is a powertype; subclassing it is like making the class Dog a subclass of Species (thanks @GerdWagner)

    4. Stage of trade can (I assume) change during runtime. But you cannot swap parent classes. This would be ok if your Trade was immutable, and going from Ordered to Traded would create a new instance of Trade. Nevertheless it is more common to use association in such a case.

    This can be resolved in several ways.

    a) using enumerations

    If the only property you care about is a basic "label" that Trade is future/spot/traded/..., then you can just use enumerations.

    enter image description here

    b) using associations and powertypes

    But in many cases you actually have additional information associated with the types, such as when it was ordered, when it was traded, different prices, etc. In such case you can attach the information via associations, or by reversing the hierarchy.

    enter image description here

    Notice that the Trade hierarchy was completely reversed. Future Trade is now properly kind of a trade, rather than Trade being kind of Future Trade.

    Of course depending on the situation you can combine all approaches.