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

[book] Submitted by webel on Tue, 13/01/2009 - 21:54

7.3.14 Element (from Kernel)

[book] Submitted by webel on Tue, 13/01/2009 - 15:59

This example contains additional elements for comparison of Comments (with handles) and Components (with Dependencies) as containers for source text snippets "related" to analysis model elements.

7.3.45 Realization (from Dependencies)

[book] Submitted by webel on Tue, 13/01/2009 - 16:02

undefined

7.3.45 Realization (from Dependencies)

'A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that corresponds to the realized element.'

'Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client).'

[INCUBATING] 'A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the specification.'

'Figure 7.73 illustrates an example in which the Business class is realized by a combination of Owner and Employee classes.'

8.3.4 ComponentRealization (from BasicComponents)

[book] Submitted by webel on Tue, 13/01/2009 - 16:23

Includes discussion about inconsistency in the stated sense of direction.

8.3.4 ComponentRealization (from BasicComponents)

'The ComponentRealization concept is specialized in the Components package to (optionally) define the Classifiers that realize ..'

'abstraction : Component [0..1] The Component that own this Realization and which is implemented by its realizing classifiers.'

'realizingClassifier : Classifier [1] A classifier that is involved in the implementation of the Component that owns this Realization.'

'Semantics: A component’s behavior may typically be realized (or implemented) by a number of Classifiers ..'

ERROR: 'Notation: A component realization is notated in the same way as the realization dependency (i.e., as a general dashed line with an open arrow-head).'

The 'open arrow-head' is the same, however the direction is clearly in the reverse sense.

The above examples (as links to images) are amongst the most useful examples of advanced UMLTM 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.

Notes

Please select an image name link to open the image(s) in an image viewer "lightbox".

UML: MagicDraw UML: note use of logical and graphical grouping by «wrapper» Components.

UML: MagicDraw UML: the "parasitic" «wrapper» Component strategy (whereby a "logical" Component does not "steal" ownership of a graphically contained element) is known to work in at least MagicDraw UML; it may not work in all UML2 tools.

UML2.1.2: contains content quoted from the OMG UML specification documents for educational purposes.

Visit also

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