Figure 06: Example: wrapped class diagram (software engineering view) of a fictitious neutron beam conditioning bunker

Figure 06: Example: wrapped class diagram (software engineering view) of a fictitious neutron beam conditioning bunker

Shows a top-level block «wrapper» Component for a conditioning bunker and its contained «part wrapper» Components, which graphically and logically organise the diagram and design comments within their respective block or part contexts (corresponding to part Properties).

Figure 04: ExampleBlock convention for block wrapper components and organisation of engineering elements

Figure 04: ExampleBlock convention for block wrapper components and organisation of engineering elements

Logical/graphical block «wrapper» Component and the BlockModel/BlockPackage<code> system.

Figure 01: Convention and notation for Class/Interface pairs and associated wrapper Component.

Figure 01: Convention and notation for Class/Interface pairs and associated wrapper Component.

Figure 1 Convention and notation for Class/Interface pairs and associated «wrapper» Component. The convention is employed throughout the Bragg Instrument ModelServer software architecture, and can likewise be applied to systems engineering blocks.

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.

UML: TIP: MagicDraw UML: DO NOT use reverse-engineered Components (like Class.java) as «wrapper» Components

It is hard to read, difficult to manage in the model browser, and not very robust (since the model and diagrams can change on reverse).

CASE Study: a UML Parsing Analysis of UML2 Specification metaclasses, using «wrapper» Components as relatable parsing containers

The above examples (as links to images) are amongst the most useful examples of advanced UML™ Parsing Analysis. Here we begin to appreciate the advantage of using stereotyped elements over mere notes as containers for source text snippets, and why it is so important to have a relatable parsing container (such as «wrapper» Components), rather than just a Comment. Please take time to examine these detailed examples carefully.

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.

"2nd Order" UML Parsing Analysis: use a «wrapper» Component as a container for the source text, and relate it to model elements using a Relationship

The full UML™ Parsing Analysis recipe can only be exploited when the relationship between source text and model elements can be traced. A relatable parsing container for snippets of source text is needed, from which one can draw a Relationship such as a Dependency, Association, or ComponentRealization, depending on the container and purpose.

To this end, a Classifier (such as a Component or Artifact) can be used, where the NamedElement.name is typically used to carry one sentence of source text
(usually combined with suitable styling of the element so that the name reads like regular text).

The Class is not well suited, because it is not a good graphical container for logical grouping, and if source text is to be related to Class elements it can be confusing to use a Class for the model and the source text.

The Artifact (being generally associated with external software artifacts) offers itself, however it is not able to sufficiently graphically and logically group a wide range of elements, and does not nest well.

Best by far is the UML Component, which can be happily misappropriated for this purpose in some UML tools.

I call UML Components used this way parsing «wrapper» Components, because they graphically "wrap" other model elements. When they are also only used to logically group other model elements (without "stealing" physical ownership of the graphically grouped elements), I call them logical «wrapper» Components:

IMPORTANT: UML Components misappropriated in this fashion for UML™ Parsing Analysis SHOULD be clearly stereotyped by a «wrapper» stereotype, or an extending sub-stereotype, such as «source» as an indicator of the source of the "parsed" text snippet that names the Component used as a relatable parsing container.

Thus, a «source» Component is a special kind of «wrapper» Component, one that provides a logical context for relating other UML model elements to the text that names the Component, and which also can provide a graphical grouping of those elements within the boundary of the Component.

In many UML tools, some types of elements that are graphically contained/placed inside a Component will be related to that Component automatically by a ComponentRealization, so that 1 analysis model element can be easily traced to zero or more parsing «source» Components.

This is the fundamental idea behind "2nd Order" UML™ Parsing Analysis. And it is very useful and powerful !

Syndicate content