UML Component

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.

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.

Syndicate content
randomness