This tutorial trail presents some of the basic steps for managing port-based service oriented systems in MagicDraw UML using the provided/required Interface mechanism of UML2.
I recommend that you have a class or implementation "focus" diagram for each port-based class and define/declare and document its ports and required and provided services there, BEFORE connecting it up in any particular usage context.
To create an InterfaceRealization from a typed Port to "provide" an Interface you can use:
To create a Usage from a typed Port to "require" an Interface you can similarly use:
Note that the PORT MUST BE TYPED already, otherwise it makes no sense for it to realise or use anything, because it is in fact the TYPE that realises or uses the interface.
That Type (a BehavioredClassifier) of the Port will then be seen to realise (provide) and use (require) the same interfaces (see next images).
Once ports are defined they may also be display as a lists in a compartment (rather than always showing the square-box notation which can be fiddly and leads to clutter, and is only really necessary for classifier-level "dependency wiring" in class-level diagrams or instance-level connections in structure diagrams).
In a Class simply disable the display option Suppress Ports.
In a Component you may additionally disable the display option Supress Interfaces to show the services provided and realised by the Component
Interfaces are in fact provided or required by Ports via the BehavioredClassifiers that type them (for most intents a purposes you may just think of the "Class" that types the Port). Here display related elements and/or display paths under the related elements menu has been used to show the Interfaces required and provided by the Classes used as types of the Ports of Class HasPorts in the previous example.
It is a good idea in MagicDraw UML to plan your connections "architecturally" first using Classifier-level Dependency wiring, which shows what may be validly connected, as opposed to what is connected in a particular context. This enables one to provide and require all necessary Interfaces before attempting to build a specific higher-order system. This process is supported in MagicDraw UMl; by the Display Paths and Display Related Elements features.
In the Composite Structure Diagram for a specific usage context use drag n' drop to build your system out of part Properties (which may or may not have Ports). Each part Property is a specification of one or more instances that may be created whenever an instance of the parent context is created. Use Display Provided Interfaces and Display Required Interfaces to display the interfaces required and provided by each port as "lollipop and fork" notation. This gives information (only) about the services required and provided via ports.
Optionally, the "conjugated" service provided and required via a particular Connector may indicated by dragging the provided Interface onto the Connector to make that Interface the 'conveyed' Classifier of an InformationFlow (notational only). This can help visualise what services are connected (as opposed to which services may be validly connected).
After you have created a composite structure (by using convenient drag n' drop to create part Properties) you may go back to the matching "architectural" class diagram used for planning the connections and generate composition associations (if you wish) by dragging the part Properties out of the context Class (i.e. they become "roles", Property ends of composing Associations from the context Class).
TIP: I recommend that you avoid trying to "compose" complex systems using associations; prefer the structure diagram "systems-engineering" approach wherever possible ! Note also that you can't show connections in a purely classifier-level diagram, so the associative composition diagram only shows only a subset of the structural information anyway.
Visit also: