1

I have to model a situation where I would like to use specializations to ensure classes are somewhat normalized, but:

  1. Risk multiple inheritance problems, especially in the long run
  2. Will need to derive an XML-compliant UML model from it (a.o., only one superclass allowed)

The simplified situation is as follows (see also diagram below): we have Parts, like doors, bolts, wheels, etc., and Tools, like drills, ladders, and bigger machinery. All of these may be used in generic processes, like Orders, Shipments, etc. As such, I would like to have one superclass (Powertype, maybe?) that represents them, say Item.

Both Tools and Parts have specialized classes that carry a serial number. As such, I figured that a SerializedItem class with a SerialNumber, which both SerializedPart and SerializedTool inherit, would ensure that all serialized 'things' we have carry at least the same information. However, I also need these Serialized items to carry at least the same information as their more generic parts, and hence I would introduce multiple inheritance.

I have considered making the Item classes interfaces. This would at least mitigate some (many, all?) multiple inheritance problems. This is where another however comes in: aside from an attribute SerialNumber, I would also like to enforce that all Serialized specializations have an aggregation relation with a Manufacturer. Aggregation to an interface is not allowed, so I feel like I cannot with one relation to the superclass enforce this relation.

As such, I have the following considerations/problems:

  • Have two disjoint 'branches' of Item, with little to no technical governance on content of Serialized specializations
  • Item classes as Interfaces, but then little governance w.r.t. use of Manufacturer by Serialized specializations
  • All concrete classes, but then there exist multiple inheritance issues which must be solved when trying to derive XML classes from the model

Which option would you prefer, and why? Did I miss any considerations?

One option for model

Wiebe
  • 33
  • 4
  • 1
    If you choose modeling item classes as interfaces, how would you map this to XML Schema? Also, notice that interfaces are an implementation modeling concept (e.g. for making a Java class model), but not a general OO design concept. – Gerd Wagner Nov 26 '19 at 03:22
  • What I've seen quite often when converting a class model to an XSD model, is that the class hierarchy is being flattened. The result is that there is no inheritance at all anymore, only concrete classes. Because that makes things easier for the developers working with the XSD. It also seems to me that some (or most) of your classes can be set to abstract. Why do you thing you can't make an aggregation with an interface? – Geert Bellekens Nov 26 '19 at 04:37
  • @GerdWagner I was thinking of squashing them into the classes in a conversion algorithm, resulting in a UML model based on something like the above that would represent the XSD structure. – Wiebe Nov 26 '19 at 08:24
  • @GeertBellekens The Item classes are indeed abstract, but I feel like the others seem more concrete. We have bolts, that are Parts, and more expensive items that are SerializedParts. I'll admit that we have some discussion going on on smashing those together in one class, but I like the ability to govern whether only Serialized items are allowed in a service/program. Regarding the aggregation, this is w.r.t. the possibly abstract SerializedItem class, but which should contain a concrete Manufacturer. Perhaps this can be done through a Manufacturer interface? – Wiebe Nov 26 '19 at 08:28
  • 1
    In your current diagram all of your classes are concrete. There is no "more concrete" feeling. A class is either concrete (you can have instances of that type and not a subtype) or it's abstract (there can only exist instances of one of the subtypes of this type). In many cases only the lowest level of classes are concrete, and all the other abstract. There is no reason you should use an interface for `Manufacturer` if `SerializedItem` becomes an interface. It's perfectly legal to reference concrete classes from an Interface. – Geert Bellekens Nov 26 '19 at 12:38
  • Item classes _should be_ abstract is what I meant to say, you are correct. About the aggregation relationship between a concrete class and an interface, I must admit that I was influence by Sparx EA's behaviour regarding those connections, giving part/whole options between classes, but defaulting to interfaces aggregating to classes. Those connections are reversible, but I figured there was UML rules behind it that I couldn't explicitly find. Perhaps you, as an EA expert, know something about this? – Wiebe Nov 27 '19 at 09:26

2 Answers2

2

If you want to have a (platform-independent) information design model (similar in spirit to a conceptual model), then you should use multiple-inheritance if this reflects the concepts of your problem domain.

According to such a model-based engineering approach, your model is a pretty good design model that can be used as a basis for making (platform-specific) implementation models such as, e.g., a Java class model or an XML Schema model.

For making an XML Schema model, you would have to choose a certain mapping. In particular, you need to choose a mapping for resolving the multiple inheritance pattern, see also https://stackoverflow.com/a/27102169/2795909.

Gerd Wagner
  • 5,481
  • 1
  • 22
  • 41
0

I just would not make SerializedItem a superclass. Nothing is a serialized thing which generalization would mean. Things can conform to a serialization protocol which is the same as implementing an interface (maybe called Serializable). If you happen to deal with serializable things without bothering about their content you would just deal with Serializable and only know the number.

Basically you should make your SerializedItem an interface (eventually renaming it to Serializable), remove the generalization upwards and make the two horizontal ones realizations.

This is probably not an ultima ratio. But to me this approach sounds more reasonable.

qwerty_so
  • 35,448
  • 8
  • 62
  • 86