UML2 Tutorial Overview [under construction]

Welcome ! The emphasis of these tutorial trails is on how to use selected aspects of UML2 in the MagicDraw UML tool, especially:

Visit also:

Even regular UML2 users will find a lot of good advice and examples on this eSchool taken from SysML applications This is not a complete tutorial on UML2 and/or the UML2 metamodel ! Nor does it replace careful examination of the OMG's UML2 specification !

Tutorial: principles of port-based software and systems engineering

The robust principles of port-based engineering known to disciplines such as electrical engineering, mechatronics, and systems engineering are now finding practical expression in graphical software engineering through aspects of UML2 including:

UML2 Classes and Components are thus Holons. From http://en.wikipedia.org/wiki/Holon_(philosophy):


'A holon is a system (or phenomenon) that is a whole in itself as well as a part of a larger system. It can be conceived as systems nested within each other. Every system can be considered a holon, from a subatomic particle to the universe as a whole. On a non-physical level, words, ideas, sounds, emotions—everything that can be identified—is simultaneously part of something, and can be viewed as having parts of its own, similar to sign in regard of semiotics.

Since a holon is embedded in larger wholes, it is influenced by and influences these larger wholes. And since a holon also contains subsystems, or parts, it is similarly influenced by and influences these parts. Information flows bidirectionally between smaller and larger systems as well as rhizomatic contagion. When this bidirectionality of information flow and understanding of role is compromised, for whatever reason, the system begins to break down: wholes no longer recognize their dependence on their subsidiary parts, and parts no longer recognize the organizing authority of the wholes. Cancer may be understood as such a breakdown in the biological realm.

A hierarchy of holons is called a holarchy. The holarchic model can be seen as an attempt to modify and modernise perceptions of natural hierarchy.'.

Through progressive encapsulation of functionality as EncapsulatedClassifiers with declaration of provided and required services as Interfaces, UML2 Classes and Components promise to enable greatly improved development and testing of increasingly complex, reusable software components.

Visit also:

 

Using a Class with ports in a higher level system

You can use a Class with Ports as a part Property in a higher level system.

If the context using the Class only every interacts with the "instance" of the Class via its Ports (with the provided/required Interfaces as declarations), then the Class is replaceable within the context, promoting true design-by-contract and service orientation. The part Property can thus play a replaceable "role" within the higher context.


TIP: In MagicDraw UML one can also use a Class with Ports as the type of a Port to create nested ports, a powerful systems engineering feature !

UML2 Classes and Components are StructuredClassifiers: they can be decomposed into nested parts

The example shows how the composite structure compartment of a Class can be used to show deeply nested part Properties.

UML class diagram using composition Associations: SimplifiedVehicle: as an associative Class holarchy

This associative graphical composition view (well known to software engineers through UML Class Diagrams) is equivalent to the composite structure diagram view (familiar to systems, electrical, and mechatronics engineers through various engineering diagrams):

  • in the Class Diagram, named part Properties with multiplicity indicators appear as the end of Associations of AggregationKind 'composite'.
  • in the Composite Structure Diagram, part Properties appear as instance-like rectangles with multiplicities  in [brackets] and :Classifier type indicator.

Recomended naming conventions for port-based engineering in MagicDraw UML and Java

I have found the following notation conventions to be a good compromise between readability and Java-friendliness for port-based systems engineering in MagicDraw UML. (Note also that the MD SysML plugin with SysML FlowPort and ItemFlow support makes representation of signal processing systems easier.)

Consider a system with Audio. I recommend:

  • Use additional stereotypes to aid your port-based engineering.
  • Use Audio for the Interface (if needed, in some cases an Interface is overkill).
    • Do NOT use the IAudio "Eclipse" style, it is too easily confused with "input".
  • <<port>>: Use Audio_ (with a trailing underscore) for the "default implementor <<port>> Class" that provides the Interface Audio.
  • <<conjugate>>: Use Audio$ (which a trailing doller) for the conjugate that requires the Interface Audio.
    • Do NOT use the ~Audio conjugate convention, it is not Java-friendly, and it is too easily confused with the signal convention Audio~ (below)
  • <<signal>>: Use Audio~ (with a trailing tilde) to type InformationFlows.
    • The '~' looks a bit like wave.
    • This is NOT Java Friendly.

The relationship between the Interface name and the implementor/conjugate pair breaks down (as it should) for complex ports.

The example below is from the "signal processing" domain, however the principles scale well to UMl-driven port-based Java software engineering. 

Why port-based engineering is so powerful: "poor portless Arthur" vs. "smarter Martha with ports"

Imagine two school students, "Arthur" and "Martha". Both of them are going to provide services to their school, and community, and both will require some things as well (from their families). They are going to be both "used" by various Actors, who see them as Interfaces from different points of view:

  • Since both are at school they will have to be able to be educated by a Teacher (we hope), who will make them study(), swat(), research(), and sitExams(), activities which are supposed to help them Learn.
  • They both do sport for Exercise and have a Trainer (who will make them run(), jump(), skip() and swim()).
  • They both earn some money on the side in the kitchen of a local hotel run by a KitchenManager, who will ask them to Cook: fry(), stir(), and bake(). (Note that the KitchenManager is not very interested in how either of them can skip() or run(), let alone their ways of swat()ing for exams.)

And they are going to "use" the services of their Parents, who Support them by feed()ing them both with Food and imburse()ing them some pocket Money (presumably their sport classes cost more than they earn at with their hotel kitchen job).

We can represent the interaction of these Actors with different Interfaces as shown below, without yet specifying how those services will be encapsulated ! (We will compare the different encapsulation strategies of "poor portless Arthur" and "smarter Martha" next).

The PortlessHuman: poor mixed up Arthur (or how not to design reusable software)

Poor Arthur's way of doing things -without ports - is very cognitively mixed up. (He has been studying old-style software engineering at university and classic object-orientation, and he has been using some of those awfully bloated "GUI God Classes" with hundreds of methods of different kinds from certain well-known software houses, all the time thinking that it is "supposed" to be done that way.)

He tried to implement all the operations of all provided Interfaces with methods in a single Class !

He mixed up all the signatures for all provided Operations for all Interfaces as methods in one Class, and presumably he mixed up his data, too. He has his swim()ming near his swat()ing, and he can't add in any new Operations to one service Interface without changing and even recompiling his whole portless body to include a new implementing method ! If he wants to add in a new Operation in Exercise like squat() he will have to recompile methods that already work and are unchanged and have nothing to do with Exercise like stir() and research();

But isn't this the way most "object-oriented" software systems are implemented ?

Isn't this service orientation and design-by-contract, and aren't we meant to be using it ?

Isn't this what is shown in nearly all Java examples, where a single Class can implement many Interfaces, yet can only extend once ?

In fact - although still widely taught and used - it is a merely a very highly coupled and inflexible form of both service orientation and design-by-contract. There is a good reason why your home HiFi, your TV, planes that fly, and robots that work, are not built like this ! Let's see a smarter way of achieving service orientation by using some port-based systems engineering techniques that are centuries old.

But first, let us try to use poor portless Arthur and see how inflexible and hard to reuse he is !

Portless service orientation: strong coupling to implementation

Just some of the issues when attempting to use our portless Arthur class include:

  1. If you want to replace your implementation of portless Arthur you would have to replace the whole of Arthur !
  2. There is no easy way of injecting different port implementations of the provided Interfaces.
    One thus has to sacrifice dependency injection of fine-grained service implementations !
    (One can't have an injected PortFactory for creating port implementors which provide the fine-grained service interfaces.)
  3. In Java: if you want to just access a particular Interface like Cook, you have to subassign (implicit cast):
    Cook c = arthur;
    There is no easy way of prompting on your PortlessHuman to discover what it does or does not provide.
  4. It is very difficult to represent details of the interactions between portless Arthur and his environment.
  5. MagicDraw UML does not (yet) support display of required/provided Interfaces from part Properties.

 

Port-based service orientation: "Martha" the SmarterHuman

Student "Martha" is much smarter than portless Arthur. (This is probably because "Martha" has studied and applied real-world engineering instead of just software engineering for harmless web applications, and she wants to build things that actually work and do what they are meant to.) Smarter Martha realises that:

  1. Classes with hundreds, or even thousands, of methods are very hard to maintain.
  2. It does not make cognitive sense to try to implement different sorts of things all in the same place.
  3. It makes cognitive sense to keep your mind on things OF THE SAME NATURE within one implementor (don't have swim()ming near cook()ing).
  4. If you distribute your intelligence over well-defined Ports you become more autonomous.
  5. If you use Ports you can implement Interfaces piecewise and test them progressively.
  6. If you use Ports you can fetch the implementations of the Interfaces easily from an injected Factory as implementing ports.
  7. If you use Ports you can more easily handle Operation extensions to the service Interfaces or even the addition of completely new Interfaces without recompiling things that have nothing to do with the new Operation or Interface.
  8. If you use Ports you can also use service accessor operations to get at the Interfaces provided via ports.
  9. You can prompt on the service accessor operations in your IDE to get at and discover which service Interfaces are provided !

Best of all, if a service is never required, YOU NEVER HAVE TO CREATE AN IMPLEMENTOR AND WASTE ANY RESOURCES FOR IT ! (Poor portless softy engineer Arthur has to create resources to Exercise and Learn even when he only needs to Cook in a hotel kitchen as a holiday job.)

To make this magic happen, we need a new kind of top-level contract, one that says what interfaces the ports must provide and require, which is what the «meta»-Interface is all about. First however, let us see (next page) how one might use "Martha the SmarterHuman with Ports" as a part Property in a higher context.

Using Martha and the SmarterHuman Class as a part Property in a higher context

One can now connect clientinstances (and the ever-serving :Parent) to the Ports of a part Property martha:SmarterHuman_ in a higher context.

(The smarter humans amongst you will note that in this example I have used the port-based Class SmarterHuman_ - NOT used the Meta-Interface SmarterHuman - to type the part Property, because in UML2 an Interface most unfortunately can't support port notation ! We'll return to this significant problem later.)

In pure port-based engineering the Port always acts "on behalf" of its parent.

Walk up to your TV or home HiFi and turn the volume up or down:

  • If it is an old device you might have a a single volume knob as a control.
  • If it is a newer device it might have a group with volume up (+), volume down (-), and maybe also a "loudness mode" toggle if it is a HiFi.

Either way you are interacting with the device via a Port. However you are apparently changing the volume of the entire device (TV or HiFi):

The services provided via true ports always appear to act "on behalf" of the parent device.

Similarly, when you plug your headphones into the headphone socket of a device you are apparently hearing the whole device, not just the headphone Port.

(By comparison, consider now taping a small MP3 player onto the side of your TV set. There is a headphone socket, and there is a volume control group, however there is no sense in which these ports are now acting on behalf of the TV set ! Because there is no delegation from the ports of the MP3 player to the internal parts or Ports of parts of the TV.)

In Java, this effect of "ports acting on behalf of a parent" is quite easily acheived using inner classes to implement Ports, or by passing a parent reference on construction to an existing Port Class implementation that is "mixed in" to act on behalf of the parent. (We will see later exactly how this can be done in Java in the Instrument ModelServer system tutorials.)

 

Port-based software engineering is a way of promoting reuse through aggregation over inheritance

As your systems become increasingly port-based you are effectively moving from "vertical" inheritance-based reuse to "horizontal" aggregation-based reuse.

This can be represented as shown below. The Port (which acts on behalf of its parent), is more tightly bound to its parent than a regular Property. Recall that a Port is a specialisation of Property.

By design the special Port classes can act on behalf of their parent. In Java, this can easily be achieved by:

  1. EITHER implicitly as an inner Class acting on behalf of the outer Class.
  2. OR by expliclity acting via a reference to the parent that was passed on construction of the Port class

This means you can completely avoid the tedious "mixin and delegation" coding needed to evoke the impression that a reusing Class provides an Interface that a reused Class provides. Wow !

The «meta»-Interface and The Golden Rules of truly port-based systems engineering

I use the term «meta»-Interface to describe an Interface that serves only to declare the service Interfaces that form the purely port-based contract. The only operations of a «meta»-Interface are called Service Accessors. It is related to what I call The Golden Service Rule of port-based software engineering:

A truly port-based Class should only ever offer services via Ports as Operations of Interfaces, it should NEVER offer services directly.
(There is a loophole, namely that «friend»  Classes may need direct access to public methods not in the public «meta»-Interface.)

Implementations of the «meta»-Interface can choose to create "port implementors" of the promised Interfaces by:

  1. creating them on construction (not very efficient or flexible, however sometimes necessary to prevent latency on later access)
  2. lazy instantiation: create them on-the-fly as and when needed (and never before being accessed, thus saving resources)
  3. lazy instantiation combined with Factory-based Dependency Injection: very flexible and efficient.

There is a corresponding Golden Client Rule of port-based software engineering:

Clients should only ever access services of truly port-based Classes via the Service Accessor Operations of a Meta-Interface.

In Java, including some dependency injection using a factory, it looks like this: 

HumanPortFactory f = new  SimulatedHumanPortFactory_(); // could of course be specified outside the application as XML
Human h = new SmartHuman_(f); // The Port implementors will be obtained from an injected factory.
h.cook().stir(); // will trigger creation of a Port that provides the grouped Cook service

You can now pass exactly the interfaces as needed to the relevant clients, like this: 

   Teacher t = new Teacher_(h.learn());

The teacher client does not know - and need never know - what Port implementation was used to provide Learn, or even who provided the service. Nor does the teacher client ever have to deal with Interfaces like Cook that have nothing to do with the required Learn service.

The «meta»-Interface is great in Java code, but not in UML2, because an Interface can't show Ports.

The «meta»-Interface concept is simply wonderful for port-based engineering in Java:

  • It encourages clients to access services via service accessor Operations that provide service Interfaces via Ports.
  • The service Interfaces group related Operations together nicely, and make for very efficient, robust, and easy programming.
  • One can prompt on the service accessor Operations in IDE to discover the Interfaces effectively provided by a port-based Class.
  • One can use the service accessor Operations to trigger creation methods for Ports:
    • these creation methods can exploit flexible techniques like:
      • on-the-fly (lazy) instantiation of Port implementors
      • fetching Port implementations from an injected PortFactory for maximum flexibility.

Sounds simply wonderful. Just one big problem:

The «meta»-Interface approach fails notationally in UML2 because
a UML2 Interface is not an EncapsulatedClassifier, so it can't show Ports !

In other words, if you type a part Property by a «meta»-Interface you completely lose nearly all the advantages of holons and port-based engineering NOTATIONALLY (only), in UML2. Again: there is no problem with the elegant «meta»-Interface concept for port-based engineering in Java, it is only a notational problem for UML2 -compliant tools. And yet the Interface does support attributes typed by Property, and a Port is a specialization of Property, so the «meta»-Interface strategy is tantalizingly close to working in UML2.

There is another possibility; use an abstract Class to declare the Port contract. However it turns out to be a problem for single-inheritance Java .. 

 

The abstract UPMS <<serviceProvider>> Class is not good in Java !

So if the Java-friendly «meta»-Interface idea does not work well notationally in UML2 (because an Interface can't show Ports) why not just use an abstract UML2 Class with abstract Ports providing/requiring interfaces to specify the port-based contract (instead of a UML2 Interface) ?

In fact, this works quite well - notationally - in UML2, and that is the approach adopted for the «serviceProvider» proposed by the OMG's UPMS working group:

UML Profile and Metamodel for Services RFP UPMS “Services Metamodel”

However, that approach makes it very hard to get direct correspondence with Java, which only admits single inheritance of implementations:

The BIG PROBLEM for port-based engineering in Java: Once you use a Class for merely specifying the "contract",
you have used up your precious one shot at inheriting an existing implementation of the set of promised ports.

It truly is a headache for Java users (fans of multiple-inheritance languages are ROTF laughing.).

As explained above, there is another solution that would rescue the wonderful port-based «meta»-Interface concept for single-inheritance Java:

The UML Interface could be promoted to be an EncapsulatedClassifier that can show Ports

One problem with that, however, is that it implies a Interface might be instantiable (as, for example, a Classifier of an InstanceSpecification).

Example: using a port-based contract declared by an abstract <<serviceProvider>> Class

Now that we have defined a «serviceProvider» contract for the port-based HiFi as an abstract Class we can use it in a higher context, such as a HomeEntertainmentSystem. Because the «serviceProvider» stereotype has been applied to a Class (not an Interface), and because a UML2 Class can have and can show Ports (whereas a UML2 Interface can't) we can reuse the abstract HiFi as a "port-based contract" without specifying the implementation. A particular implementation of the port-based HiFi contract -such as HiFi_ - could also be injected.

While a bit fiddly (it takes patience if hand-coded, although it is easily forward-engineered), it looks very promising notationally. However:

BIG PROBLEM for Java: this strategy fails badly in Java in all but the simplest cases because
the one precious shot at inheritance of the implemented port set has been used up already !

(I hear fans of multiple-inheritance languages ROTF laughing yet again.)

Further Reading: the UPMS <<serviceProvider>>

I highly recommend also this series of articles on Service Oriented Architecture (SOA) by Jim Amsden:

Modeling SOA: Part 1. Service identification  

Modeling SOA: Part 2. Service specification

Modeling SOA: Part 3. Service realization

Modeling SOA: Part 4: Service composition

Although the application domain business service modelling is much removed from own areas of interest (such as systems engineering of scientific instruments and signal processing systems), many of the principles discussed in these articles overlap with traditional port-based engineering design recipes.

UML2 metaclass examples

This trail already illustrates some (only) of the most common UML2 metaclasses as they appear in MagicDraw UML, with minimal examples. The emphasis is on those metaclasses required for service-oriented software engineering and port-based systems engineering, including those upon which the SysML metamodel is built. Snippets quoted from the OMG UML specifications are indicated with versioned stereotypes: like «UML2.1.2». Many of the metamodel diagrams and examples are prepared using the UML Parsing Analysis recipe to bind "wrapped" text parsed from the UML2 specification into "parsing containers" related to UML metaclasses and model elements.


NB: The «metaclass» elements are (only) part of the profiling mechanism of MagicDraw UML, they afford a point of extension for custom stereotypes. They are NOT a complete representation of the UML2 metamodel. Nevertheless, you can learn a lot about UML from them, and you are encouraged to explore them using Display Related Elements from any «metaclass» of interest, as shown.

7.3.1 Abstraction (from Dependencies) [STUB]

From UML2.1.2:

'Description
An abstraction is a relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints. ..'

7.3.12 Dependency (from Dependencies) [INCUBATING: analysis incomplete]

Quoted here nearly in full as a point of reference for discussions about direction an terminlogy in other directed relationships including:


From UML2.1.2: 7.3.12 Dependency (from Dependencies):

'Description

A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. ..

Associations

• client: NamedElement [1..*]
The element(s) dependent on the supplier element(s). .. Subsets DirectedRelationship::source.


• supplier: NamedElement [1..*]
The element(s) independent of the client element(s), in the same respect and the same dependency relationship. .. Subsets DirectedRelationship::target.

Semantics
A dependency signifies a supplier/client relationship between model elements where the modification of the supplier may impact the client model elements..

Notation
A dependency is shown as a dashed arrow between two model elements. ..

A dependency is a relationship that signifies that a single or a set of model elements requires other model elements ..[STUB]

From UML2.1.2: 7.3.12 Dependency (from Dependencies):

'Description

A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).'

client: NamedElement [1..*]

From UML2.1.2: 7.3.12 Dependency (from Dependencies):

'• client: NamedElement [1..*]
The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation. Subsets DirectedRelationship::source.'

Notation: A dependency is shown as a dashed arrow between two model elements..[STUB]

From UML2.1.2:

'Notation
A dependency is shown as a dashed arrow between two model elements. The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier). The arrow may be labeled with an optional stereotype and an optional name. It is possible to have a set of elements for the client or supplier. In this case, one or more arrows with their tails on the clients are connected to the tails of one or more arrows with their heads on the suppliers. A small dot can be placed on the junction if desired. A note on the dependency should be attached at the junction point.'

Semantics: A dependency signifies a supplier/client relationship between model elements .. [STUB]

From UML2.1.2:

'Semantics

A dependency signifies a supplier/client relationship between model elements where the modification of the supplier may impact the client model elements. A dependency implies the semantics of the client is not complete without the supplier. The presence of dependency relationships in a model does not have any runtime semantics implications, it is all given in terms of the model-elements that participate in the relationship, not in terms of their instances.'

supplier: NamedElement [1..*]

From UML2.1.2:

'• supplier: NamedElement [1..*]
The element(s) independent of the client element(s), in the same respect and the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common
convention in the domain of class-based OO software is to put the more abstract element in this role. Despite this convention, users of UML may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific. Subsets DirectedRelationship::target.'

7.3.14 Element (from Kernel)

Because the Element root metaclass is already so familiar it is used here also as as a demonstration and investigation of the UML Parsing Analysis technique (as used here for metamodel and specification analysis), including a quick comparison of some of the pros and cons of Comments (with handles) vs. Components (with Dependencies) as "parsing containers" for analysis text. 

7.3.45 Realization (from Dependencies)

From UML2.1.2:

Description


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). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

..

Semantics
A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the specification. The meaning of ‘implementation’ is not strictly defined, but rather implies a more refined or elaborate form in respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable.

Notation

A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that corresponds to the realized element. Figure 7.73 illustrates an example in which the Business class is realized by a combination of Owner and Employee classes.'

A Realization dependency is shown as a dashed line with a triangular arrowhead..

From UML2.1.2:

'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..

From UML2.1.2:

'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 ..

From UML2.1.2:

'A Realization signifies that the client set of elementsare an implementation of the supplier set, which serves as the specification'  

8.3.4 ComponentRealization (from BasicComponents): includes discussion about inconsistency in the stated sense of direction

WARNING: The UML2..1.2 Superstructure specification of the UML ComponentRealization metaclass contains some controversial notation direction conventions (as compared with Realization) and some contradictory and duplicated specification text. Therefore a relatively large portion of the UML2.1.2 specification is reproduced here, in order to support this detailed analysis.

From UML2.1.2:

'The ComponentRealization concept is specialized in the Components package to (optionally) define the Classifiers that realize the contract offered by a component in terms of its provided and required interfaces. ..

Description

In the metamodel, a ComponentRealization is a subtype of Dependencies::Realization ..

Associations:

• abstraction : Component [0..1]
The Component that own this Realization and which is implemented by its realizing classifiers.
{Subsets Element::owner, DirectedRelationship::source, Dependency::client}

• realizingClassifier : Classifier [1]
A classifier that is involved in the implementation of the Component that owns this Realization.
{Subset Dependency::supplier, DirectedRelationship::target}

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

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).'


Please note above that the 'abstraction', which is clearly to be understood as the specification 'which is implemented by its realizing classifiers' is the source (=client), which is exactly the opposite of the convention used in Realization, although it is stated that 'a component realization is notated in the same way as the realization dependency'. We will see in this trail that this is impossible; the specification text is contradictory in a number of places.

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

From UML2.1.2: 

'abstraction : Component [0..1]
The Component that own this Realization and which is implemented by its realizing classifiers.
{Subsets Element::owner, DirectedRelationship::source, Dependency::client}'

ERROR: Notation: A component realization is notated in the same way as the realization dependency ..

From UML2.1.2:

'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).'

This clearly contradicts the role of the 'abstraction' attribute as 'source, client'.

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

From UML2.1.2:

'realizingClassifier : Classifier [1]
A classifier that is involved in the implementation of the Component that owns this Realization.
{Subset Dependency::supplier, DirectedRelationship::target}'

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

From UML2.1.2 (includes [duplicated] and {contradictory} text as marked):

'Semantics
A component’s behavior may typically be realized (or implemented) by a number of Classifiers. In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of Component Realization Dependencies to these Classifiers. [In effect, it forms an abstraction for a collection of model elements. In that case, a component owns a set of {Realization Dependencies} to these Classifiers].

It should be noted that for the purpose of applications that require multiple different sets of realizations for a single component specification, a set of standard stereotypes are defined in the UML Standard Profile. In particular, «specification» and «realization» are defined there for this purpose.'

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

From UML2.1.2:

'The ComponentRealization concept is specialized in the Components package to (optionally) define the Classifiers that realize the contract offered by a component in terms of its provided and required interfaces. The component forms an abstraction from these various Classifiers.'

Contains a proof that the sense of direction from "implementing" Classifiers to "realized" Component is wrong w.r.t. the clearly stated conventions of Realization, or at best contradicatory w.r.t. the 'ComponentRealization.abstraction' attribute !

Discussion of possible "justifications" for the direction of ComponentRealization being in the opposite sense to Realization

Some colleagues have referred to the following extracts from UML2 relationship metaclasses to defend the apparent "switch" of direction of ComponentRealization.

From UML2.1.2: 7.3.12 Dependency (from Dependencies):

'users of UML may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific'

There is however no such stipulation for ComponentRealization; in fact the words 'stipulate', 'sense' and 'direction' do not appear in its specification.

From UML2.1.2: 7.3.1 Abstraction (from Dependencies):

'In the metamodel, an Abstraction is a Dependency in which there is a mapping between the supplier and the client.'

It is sometimes emphasised that this says "between supplier and the client", however that does not explain away the specifications in Realization that ComponentRealization swaps. The following from UML2.1.2: 7.3.13 DirectedRelationship (from Kernel) also offered as a loophole

'There is no general notation for a DirectedRelationship. The specific subclasses of DirectedRelationship will define their own notation. In most cases the notation is a variation on a line drawn from the source(s) to the target(s).'

ComponentRealization does not define it's own notation: rather it "inherits" a notation and direction convention from Realization, which notation the 'source/client' and 'target/supplier' specifications contradict:

A component realization is notated in the same way as the realization dependency'

Except it isn't; ComponentRealization makes the specification 'abstraction' the client, and the implementing/realizing classifiers the supplier. While this is consistent with the notion that the
realizing classifiers (perhaps classes from a library) might already exist before a Component's specification of provided and required interfaces, it is inconsistent with the sense of direction stated for Realization, in which clients implement a supplied specification !

Visit also (then come back to follow the analysis):

Component

UML2.1.1:

8.3.1 Component (from BasicComponents, PackagingComponents)

A component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment. A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a type whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). One component may therefore be substituted by another only if the two are type conformant. Larger pieces of a system’s functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring together their required and provided interfaces.

Visit also:

 

ConnectableElement

UML2.1.1: 9.3.5 ConnectableElement (from InternalStructures):

A ConnectableElement is an abstract metaclass representing a set of instances that play roles of a classifier. Connectable elements may be joined by attached connectors and specify configurations of linked instances to be created within an instance of the containing classifier.

Connector

UML2.1.1:

9.3.6 Connector (from InternalStructures)

Specifies a link that enables communication between two or more instances. This link may be an instance of an association, or it may represent the possibility of the instances being able to communicate because their identities are known by virtue of being passed in as parameters, held in variables or slots, or because the communicating instances are the same instance. The link may be realized by something as simple as a pointer or by something as complex as a network connection. In contrast to associations, which specify links between any instance of the associated classifiers, connectors specify links between instances playing the connected parts only.


The example chosen here shows "UML2-based system engineering" (rather than assembly
of software components and delegation of software services) for comparison with SysML FlowPorts.

Visit also:

ConnectorEnd

UML2,1,1: 9.3.7 ConnectorEnd (from InternalStructures, Ports):

A connector end is an endpoint of a connector, which attaches the connector to a connectable element. Each connector end is part of one connector.

EncapsulatedClassifier

UML2.1.2:

9.3.8 EncapsulatedClassifier (from Ports)

Extends a classifier with the ability to own ports as specific and type checked interaction points.


Visit also:

InformationFlow

UML2.1.2: 17.2 InformationFlows:

'Information flows describe circulation of information in a system in a general manner. They do not specify the nature of the information (type, initial value), nor the mechanisms by which this information is conveyed (message passing, signal, common data store, parameter of operation, etc.). They also do not specify sequences or any control conditions. It is intended that, while modeling in detail, representation and realization links will be able to specify which model element implements the specified information flow, and how the information will be conveyed.'

UML2.12 17.2.1 InformationFlow (from InformationFlows)

'An InformationFlow specifies that one or more information items circulates from its sources to its targets. Information
flows require some kind of “information channel” for transmitting information items from the source to the destination.
An information channel is represented in various ways depending on the nature of its sources and targets. It may be
represented by connectors, links, associations, or even dependencies. For example, if the source and destination are parts
in some composite structure such as a collaboration, then the information channel is likely to be represented by a
connector between them. Or, if the source and target are objects (which are a kind of InstanceSpecification), they may be
represented by a link that joins the two, and so on.'


Visit also:

Channels for InformationFlows

UML2.1.2: 17.2.1 InformationFlow (from InformationFlows):

'Information flows require some kind of “information channel” for transmitting information items from the source to the destination. An information channel is represented in various ways depending on the nature of its sources and targets. It may be represented by connectors, links, associations, or even dependencies. For example, if the source and destination are parts in some composite structure such as a collaboration, then the information channel is likely to be represented by a connector between them. Or, if the source and target are objects (which are a kind of InstanceSpecification), they may be represented by a link that joins the two, and so on.'

In MagicDraw UML:

  • use a Connector, Association, or Dependency to carry an InformationFlow.
  • (A Link is not supported as an information flow channel.)

 Visit also:

InformationItem

UML2.1.1: 17.2.2 InformationItem (from InformationFlows):

'An information item is an abstraction of all kinds of information that can be exchanged between objects. It is a kind of
classifier intended for representing information at a very abstract way, one which cannot be instantiated.

..


represented : Classifier [*] Determines the classifiers that will specify the structure and nature of the information. An information item
represents all its represented classifiers. '


Visit also:

Port

UML2.1.1:

'9.3.11 Port (from Ports)
A port is a property of a classifier that specifies a distinct interaction point between that classifier and its environment or between the (behavior of the) classifier and its internal parts. Ports are connected to properties of the classifier by connectors through which requests can be made to invoke the behavioral features of a classifier. A Port may specify the services a classifier provides (offers) to its environment as well as the services that a classifier expects (requires) of its environment.'

StructuredClassifier

UML2.1.2:

9.3.13 StructuredClassifier (from InternalStructures)

A structured classifier is an abstract metaclass that represents any classifier whose behavior can be fully or partly described by the collaboration of owned or referenced instances.


Visit also: