2

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

Andrey Minakov
  • 545
  • 2
  • 5
  • 19
  • And thanks all of you guys, your help is very appreciated! – Andrey Minakov Feb 07 '18 at 19:38
  • As far as I understand, the most important point is that a trade can really change it's stage from Order to Traded (p. 4), so Trade defenitely cannot be in any way a subclass of Stage of Trade. But in the real life only one of the subclasses of Trade may be assosiated with only one of the sublclasses of Stage of Trade (actually instances of the sublasses, of course). And thus an abstract superclass Trade cannot be assosiated with abstract superclass of Stage of trade. Is it possible to express this in a meaningful way via UML? And I attached the updated image of my current model. – Andrey Minakov Feb 07 '18 at 19:39

1 Answers1

4

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.

Peter Uhnak
  • 9,617
  • 5
  • 38
  • 51
  • @ThomasKilian Filled triangles? You mean open arrowheads? This is association, not extension. – Peter Uhnak Feb 07 '18 at 08:01
  • @Peter Uhnak: Your use of UML generalization/inheritance is also flawed. According to your model, an instance of `Future` (a future contract) is a `Trade type`, which is not the case. `Future` is not a subclass, but rather an instance, of `Trade type`. Better simplify your model by turning `Trade type` (and, similarily, `Stage of trade`) into an enumeration datatype with the enum literals `future`and `spot`. – Gerd Wagner Feb 07 '18 at 09:25
  • @GerdWagner I'm not a domain expert, so I was copying OP. However I don't see any point in turning them into enums at this point as you are robbing yourself of polymorphism -- especially in the case of stage of trade which is effectively a state pattern. – Peter Uhnak Feb 07 '18 at 09:48
  • @Peter Uhnak: You don't need to be a domain expert in stock trading to see the flaw in your model. It's a general anti-pattern, like making the class `Dog` a subclass of `Species`, despite the fact that a dog is not a species. Classes like `Trade type` (or `Species`) are called ***power types*** in UML. Their instances are classes. – Gerd Wagner Feb 07 '18 at 10:11
  • @GerdWagner ah, of course. Now I see the glaring issue... I'll update the post. Thanks! – Peter Uhnak Feb 07 '18 at 10:35