UML: TIP: use naming convention Thing/Thing_ for Interface and default implementor Class pair

UML: TIP: use naming convention Thing/Thing_  for Interface and default implementor Class pair

This Thing/Thing_ convention can be seen often both in Dr Darren's domain analysis and Java™ work. It is more concise than the EMF generated code convention Thing/ThingImpl, and this reads far better on Ports and in analysis diagrams (given that in some cases these map directly to generated design).

So, given that in most UML tools one can have Associations between Interfaces why bother having the extra "default implementor" Class ?

One reason is to afford a Java-like distinction (also by convention) that one can have multiple inheritance (and/or taxonomical Generalizations) on the Interfaces and only single inheritance on the Classes, which can make the mapping from analysis to (forward- or reversed) design easier when targeting Java.

Another reason is that one can't display a structure compartment on an Interface, so if one wants to conveniently explore structure using Connectors between Properties in a class diagram, one at least needs an additional "default implementor" Class for that.

So why not just use analysis Classes only throughout ? Why not just use entity-like Classes, or XML-like schema Classes ?

Apart from affording the distinction between multiple and single inheritance, there are a few reasons one might want to:

  • To promote fine-grained service encapsulation, rather than relying on the so-called IClass pattern (an Interface for every Class, sometimes considered an "antipattern") used by systems like EMF.
  • One reason, crucial to some of Dr Darren's work, is to promote strong 1st order service orientation during analysis that can then be promoted to "2nd-order" port-based models, through aggregation of default implementors as types of ports in higher order EncapsulatedClassifer components.

For analysis this naming may also be combined with:

UML: TIP: prefix analysis Classes with an indicator such as an asterix (*Thing) to distinguish them from reverse/forward engineered design classes (Thing) !

If you like you can make all default implementor Classes abstract; this can be useful if you want the type of ports to be strictly substituted (through a PortFactory or Port injection), a strategy used in Dr Darren's 2nd-order "portface" strategy for higher level contracts, where both the "portface" component and the types of all of its ports are strictly abstract, so that it acts like a contract for the combination of ports.

Used in