Composite Structure and Component Diagrams

Composite Structure & Component Diagrams

This presentation will describe two diagrams defined in the UML 2.0 specification and explain their strengths in featuring some of the important aspects of Object-Oriented design. These diagrams are not better or worse than other UML diagrams you may have worked with, but they offer specialized views of a system that may better serve to express the concepts you are attempting to model.

Composite Structure diagrams explore the internal organization of classes. It can be used to explicitly describe a class as a composition of other classes. The model can also show how the contained classes interact in the working implementation.

Component diagrams allow modelers to provide a simplified, high-order view of of a large system. Classifying groups of classes into components supports the interchangeability and reuse of code. This diagram documents how these components are composed and how they interact in a system.

Composite structure diagram

Composite structure diagram in the Unified Modeling Language (UML) is a type of static structure diagram, that shows the internal structure of a class and the collaborations that this structure makes possible.

This diagram can include internal parts, ports through which the parts interact with each other or through which instances of the class interact with the parts and with the outside world, and connectors between parts or ports. A composite structure is a set of interconnected elements that collaborate at runtime to achieve some purpose. Each element has some defined role in the collaboration.

Concepts

The key composite structure entities identified in the UML 2.0 specification are structured classifiers, parts, ports, connectors, and collaborations.

• Part : A part represents a role played at runtime by one instance of a classifier or by a collection of instances. The part may only name the role, it may name an abstract superclass, or it may name a specific concrete class. The part can include a multiplicity factor, such as the [0..*] shown for Viewer in the diagram.
• Port : A port is an interaction point that can be used to connect structured classifiers with their parts and with the environment. Ports can optionally specify the services they provide and the services they require from other parts of the system. In the diagram, each of the small squares is a port. Each port has a type and is labelled with a name, such as “var”, “indVar1”, or “view” in the diagram. Ports may contain a multiplicity factor, for example [3].

Ports can either delegate received requests to internal parts, or they can deliver these directly to the behavior of the structured classifier that the port is contained within. Public ports that are visible in the environment are shown straddling the boundary, while protected ports that are not visible in the environment are shown inside the boundary. All the ports in the diagram are public, except for the view port along the right boundary of FibonacciSystem.

• Connector : A connector binds two or more entities together, allowing them to interact at runtime. The connector is shown as a line between some combination of parts, ports and structured classifiers. The diagram shows three connectors between ports, and one connector between a structured classifier and a part.
• Collaboration : A collaboration is generally more abstract than a structured classifier. It is shown as a dotted oval containing roles that instances can play in the collaboration.
• Structured classifier : A StructuredClassifier represents a class, often an abstract class, whose behavior can be completely or partially described through interactions between parts.
• Encapsulated classifier : An EncapsulatedClassifier is a type of structured classifier that contains ports. In the diagram below, both FibonacciSystem and Variable are encapsulated classifiers because they both have ports along their boundaries.

Component diagram

In Unified Modeling Language (UML), a component diagram depicts how components are wired together to form larger components or software systems. They are used to illustrate the structure of arbitrarily complex systems.

Overview

A component diagram allows verification that a system’s required functionality is acceptable. These diagrams are also used as a communication tool between the developer and stakeholders of the system. Programmers and developers use the diagrams to formalize a roadmap for the implementation, allowing for better decision-making about task assignment or needed skill improvements. System administrators can use component diagrams to plan ahead, using the view of the logical software components and their relationships on the system.

Diagram elements

The component diagram extends the information given in a component notation element. One way of illustrating the provided and required interfaces by the specified component is in the form of a rectangular compartment attached to the component element. Another accepted way of presenting the interfaces is to use the ball-and-socket graphic convention. A provided dependency from a component to an interface is illustrated with a solid line to the component using the interface from a “lollipop”, or ball, labelled with the name of the interface. A required usage dependency from a component to an interface is illustrated by a half-circle, or socket, labelled with the name of the interface, attached by a solid line to the component that requires this interface. Inherited interfaces may be shown with a lollipop, preceding the name label with a caret symbol. To illustrate dependencies between the two, use a solid line with a plain arrowhead joining the socket to the lollipop.