Click on the image below to view it full size in an image viewer !

Tutorial: the UML2 Component as a logical and graphical «wrapper» (MagicDraw-centric)

If you want to become a true Unified Modeling Language™ (UML™) power modeller like Dr Darren, study the examples here. Don't leave home without this powerful "trick" !

The happy1 misappropriation of UML2 Components as "parasitic" logical and graphical «wrapper» of otherwise physically packaged Classes, Interfaces, and Comments (and some other UML elements) is a very useful diagramming and modelling technique popularised by Dr Darren over many years.

The use of «wrapper» Components is also a crucial part of the powerful UML™ Parsing Analysis recipe for binding technical text to UML model elements, so this section should be studied before: Tutorial: the UML Parsing Analysis recipe(s).
  • 1. It never ceases to amaze me how unhappy certain UML purests become when they see me demonstrating, promoting, and even teaching this obviously useful - yet semantically "incorrect" - trick. Ignore them; this really works, at least in some UML tools. Eventually, I would like UML2+ to support an official Wrapper element.

Diagramming with arbitrary logical «wrapper» Components

If your Unified Modeling Language™ (UML™) tool supports "parasitic" «wrapper» Components (as MagicDraw™ UML does), you can use them to provide a logical context for anything you desire, a technique employed heavily by Dr Darren in the UML™ Parsing Analysis recipe.

A «wrapper» Component can be an effective alternative to the somewhat cumbersome mechanism of PackageImports required to create logical views using a Model.

In MagicDraw™ UML, «wrapper» Components can be used whenever possible to logically and graphically group many UML model element types. If you want your UML diagrams to converge within this lifetime try experimenting with these recommendations. The principle is of course directly related to the concept of holons1 (of which UML2 Components with Ports are an example) and the Parable of the Watchmakers:

"There once were two watchmakers, named Hora and Tempus, who made very fine watches. The phones in their workshops rang frequently; new customers were constantly calling them. However, Hora prospered while Tempus became poorer and poorer. In the end, Tempus lost his shop. What was the reason behind this?

The watches consisted of about 1000 parts each. The watches that Tempus made were designed such that, when he had to put down a partly assembled watch (for instance, to answer the phone), it immediately fell into pieces and had to be reassembled from the basic elements. Hora had designed his watches so that he could put together subassemblies of about ten components each. Ten of these subassemblies could be put together to make a larger sub- assembly. Finally, ten of the larger subassemblies constituted the whole watch. Each subassembly could be put down without falling apart."
(Herbert Simon)

Are your UML diagrams falling apart ? Try logical and graphical grouping with «wrapper» Components !

  • 1. The UML2 StructuredClassifier, EncapsulatedClassifier with Ports, Composite Structure Diagram, and the SysML Internal Block Diagram with deep nesting are also all expressions of the "holon" principle.

Figure 13: Model: wrapped block class diagram (software engineering view) for the entire monochromation beam ("logical") stage.

Figure 13: Model: wrapped block class diagram (software engineering view) for the entire monochromation beam ("logical") stage.

Includes deeply nested motorised motion stages of the monochromator's goniometer. Only block «wrapper» Components throughout (no «part wrapper» Components are used), since all blocks are designed for this monochromation context only, no reuse in other assemblies is intended, except for the reused motion stage blocks, which are not yet separately wrapped here. To include content specific to each motion stage part they would need to be wrapped in individual «part wrapper» Component.