[note] MagicDraw UML: does not permit drawing a Dependency (or Usage) from a Property name symbol or line end of an Association, makes it hard to indicate a chosen implementation Class. Workaround: draw from Property symbol in composite structure compartment.

Type:

Problems applies at least to MagicDraw UML 17.1.

Case: one has a Property variable typed by an Interface in a managing Class and one wishes to indicate (when a factory is not used) which implementation Class is assigned to the variable (say on lazy instantiation).

IMPORTANT: this matter is only of concern when a managing class has knowledge of concrete implementation Classes assigned to its Interface variables (such as for a demonstration class choosing demonstration items), it does not apply when factories are used !

Consider the code below. The property $blockViewCurrentPosts is correctly documented with type @var IBlockView , because it does not "know" that it will be (at least in the implementation of this class) be lazily assigned a new CurrentPostsBlockView in the lazy creator blockViewCurrentPosts(). From OoeBridge:

  /**
   *
   * @var \Drupal\ooe\Block\IBlockView 
   */
  private $blockViewCurrentPosts;
 
  /**
   *
   * @return \Drupal\ooe\Block\IBlockView 
   *   Lazily creates a block view for the current posts.
   */
  protected function blockViewCurrentPosts() {
    if (empty($this->blockViewCurrentPosts)) {
      $this->blockViewCurrentPosts = new CurrentPostsBlockView(
              $this->block_current_posts(),
              $this->getModuleDisplayName() . ': Current posts'
      );
    }
    return $this->blockViewCurrentPosts;
  }

Now we could instead document $blockViewCurrentPosts with @var CurrentPostsBlockView, which PEAR PHP UML correctly picks up, and can be used to generate an Association to a CurrentPostsBlockView. But this has some problems: (1) it breaks the rule of design-by-contract (although in fact only the creator method blockViewCurrentPosts() of type IBlockView is ever used directly); (2) What if an extending class overrides the creator method blockViewCurrentPosts() and returns a different implementation (or even uses a factory and does not know what the implementation will be) ?

But if $blockViewCurrentPosts is correctly documented with type @var IBlockView and the lazy creator blockViewCurrentPosts() is correctly documented with type @return IBlockView (but uses a new CurrentPostsBlockView) the PEAR UML PHP will not catch the class CurrentPostsBlockView anywhere, not even from the PHP use header !

So how do we indicate in (MagicDraw) UML what implementation type is (at least by default in this OoeBridge class) assigned to $blockViewCurrentPosts ?

One should be able to use a stereotyped Dependency (such as a Usage) because the Associations for Dependency (in UML2.3) are:

- client: NamedElement [1..*]

- supplier: NamedElement [1..*]

And since a Property is a NamedElement is may be the client of a Dependency.

However MagicDraw UML does not seem to support drawing a Dependency from either the name symbol of a Property at an Association end or from the end of the Association line symbol.

ooe-mduml-usage-from-Property-not-permit

One can draw a Dependency or Usage from the middle of the Association line to a Class symbol, but that is not consistent, as it is not really the whole Association we wish to specify an implementation type for, only one Property end:

ooe-mduml-usage-from-Association-inconsi

MagicDraw UML does however support drawing a Dependency (or Usage) from Property part symbol in the composite structure compartment (when displayed, not "suppressed") to a Class. In Ooe one can stereotype such a relation with «!default», indicating that this is not necessarily the only implementation type the Property could carry. Further, one can stereotype the Property with «!chosen», to indicate that (at least in the default context) an implementation type is chosen for the Property. This strategy is not ideal, however it does communicate well graphically the creation setup:

ooe-mduml-usage-from-Property-part-symbo

A «!chosen» Property is as opposed to a «!product» Property for which the implementation type is obtained from a factory (and the managing class does not need to know even what kind of factory implementation is used, let alone what product implementation is finally assigned to the Property, as long as the Interface contract is met):

ooe-mduml-usage-from-Factory-products.pn


So what's wrong with drawing a Usage from the lazy creator method ? After all it's the part that knows best what implementation class is assigned (in the context of the managing class)

In terms of the UML model (as opposed to diagram) there's nothing wrong with doing this, in fact one can do it as well. It is also local to the (client) method within the context of the managing Class, so if a subclass overrides the creator method and chooses a different implementation Class one can create a different Usage for it to show the implementation class it instantiates.

But graphically there are some problems:

- Usages from operations/methods lead to clutter in the diagrams, because the order of the operations/methods may not match well (be near to) the implementation Class symbol.

- It is very difficult to tell when method the Usage is drawn from, since it is indicated by a small circle connection point on the right-hand-side of the method/operation text.

- If you close the operations compartment of a Class/Component symbol the Usage relationship no longer appears ! It is still in the model, but it does not work well for graphically associative modelling.

OoeBridge.method_usages.imp.crop.jpg


Why not just draw a Usage from the managing Class ? After all, then the Usage would be local to that class, so if a subclass overrides the creator method one can draw a new Usage to a new chosen implementation Class.

The problem with this is that it is not clear what the chosen implementation Class is used for ! This is of concern when one has many properties (like in OoeBridge) of the same Interface type.


Note applies to ...
Visit also