After a while, clusters of classes that strongly interact and form a unit will start to peel out from the architecture. To express this, the corresponding clusters can be represented as components. If taken far enough, this can lead to a highly reusable component architecture. But such an architecture is hard to design from scratch and usually evolves over time.
Component diagrams are often used to model high-level software components and how they interact. The interfaces between these components become clearer as the model grows, which provides a much clearer delineation of duties of each component.
When working extensively with Component diagrams, it is a good idea to turn off automatic edge rendering from Edit -> Settings -> Diagram display -> Add dependent edges automatically. This will prevent potentially confusing edges to appear when working with multiple representations of the same element within a single diagram.
The update from UML 1.x to 2.0 where the actual meaning of the term 'component' was altered necessitated some changes to the Component Diagram. Previously, a component referred to an item to be implemented, such as an executable. As of UML 2.0, components are treated as encapsulated entities that serve as a black box to hide behavior and provide interfaces to the component. This transforms them into more logical elements that can be easily replaced as required by the design.
Required and Provided Interfaces
Components hide the inner workings of a component; each component is a general logical unit. Truly essential to Component diagrams are the provided and required interfaces that determine how the components are wired together and how they interact with one another.
Interfaces can be represented with 'ball and socket' notation: sockets indicate required interfaces and balls (or lollipops) indicate provided interfaces. They can be shown together as a single interface:
Or they may be shown shown separately. The 'Split Assembly Connector' rapid button will disconnect them and display the same interface in two places.
Interfaces may also be shown within the components themselves, regardless of whether the ball and socket notation is being used simultaneously. To do this, select the 'Provided Interfaces' and 'Required Interfaces' checkboxes from the Visibility dropdown menu in the Details Pane toolbar.
Add an Interface to a Component
To simply add an interface to a component, you can create a new component in a Component diagram, then create the new interface with either the required interface or the provided interface rapid buttons. See Section 3, “Interfaces” for more information on working with interfaces in Poseidon.
The method mentioned above will certainly create the interfaces, but they are lacking the semantic information that makes UML so useful. If we take a look at the class diagram below, we can see behind the scenes. We have an interface called Interface_1 that is implemented by Class_1 (Class_1 has Interface_1 as a Provided Interface), and that is used by Class_2 (Class_2 has Interface_1 as a Required Interface).
It is in these classes and interfaces that the true behaviors of the component are defined.
When seen from the Component diagram, we see that Component 1 is realized by Class_2. Logically, Component_1 has the same interfaces as Class_2, which we see here in three ways.
First, we see the use relationship between Class_2 and Interface_1 along with the realization between Class_2 and Component_1. Next, we see the list of required interfaces within Component_1. And finally, we see Interface_1 in socket notation. Any one of these methods is sufficent, we have simply chosen to use all three for this demonstration.
To display the representation of an interface that already is listed by a component, select an interface from the Properties tab, then click the 'Add Representation' button from the toolbar above the interfaces list.
|Try it Yourself - Add a Provided Interface to a Component|
|Try it Yourself - Add a Required Interface to a Component through a Class Realization.|
Along with interfaces, ports may be added to components. For full details about how to work with ports, please see Section 3.3, “Ports”.
Objects from UML 1.4 have been redefined in UML 2.0 as instances using Instance Specifications.
Assembly and Delegation Connectors
An assembly connector is a connector between two components that defines that one component provides the services that another component requires. An assembly connector is a connector that is defined from a required interface or port to a provided interface or port. - OMG UML 2.0 Superstructure Specification p. 150
In Poseidon, an assembly connector between two components with compatible interfaces will automatically add these interfaces to the component. Their display can be controlled from the Properties panel.
A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the component's parts. It represents the forwarding of signals (operation requests and events): a signal that arrives at a port that has a delegation connector to a part or to another port will be passed on to that target for handling. - OMG UML 2.0 Superstructure Specification p. 150
Nodes - Nodes represent the hardware elements of the deployment system.
Components - Components stand for logical elements that are deployed within the system.
Links - Links are used to connect instances of nodes or objects.
Dependencies - Dependencies exist between components and can be specified by utilizing predefined or user-defined stereotypes.
Associations - Associations are used to display communication relations between nodes. They can be specified by utilizing predefined or user-defined stereotypes.
Instance Specifications, Classes, Interfaces - Components and nodes can include objects, classes or interfaces.
|Add or remove space between elements|
|Link between two Instance Specifications|
|Interface As Circle|
|Connect Comment to Element|