Component Diagram

A component diagram in the Unified Modeling Language depicts how components are wired together to form larger components or software systems. It shows the organization dependencies between components and artifacts. The following topics of component diagram are covered in the intermediate exam:

1. Components: Interfaces for components, component instantiation, and component representation
2. Connectors: Assembly and delegation connector
3. Realization relationship

Components: A component represents a modular part of a system that encapsulates its content and whose manifestation is replaceable within its environment. It defines its behavior in terms of provided and required interfaces. It may be substituted by another if and only if their provided and required interfaces are identical. This idea is the underpinning for the plug-and-play capability of component-based systems and promote software reuse. It is a special class that represents a replaceable unit in a system.

It is composed of classifiers or is implemented by classifiers. A component is represented through a component keyword with component name as shown in the following image:

Interfaces for components: A component uses the following two types of interfaces:

1. Required Interface: It is an interface of a component that a component needs to perform its execution. It specifies which component or class is required by the component to perform its function. This interface declares the services that a component will need.
2. Provided Interface: It is an interface that a component holds or realizes. A provided interface describes the services provided by the component. All the other components and classes interact with the component through the provided interface.

The ball-socket notation is a shortcut notation to represent the provided and required interfaces. In this notation, a circle is used to represent a provided interface. A semi circle is used to represent a required interface. For example:

In the above example, Inventory Management is a component. Supplier and Customer are the provided interfaces and Owner is the required interface.

Component representation:

1. Table Notation: The table notation is the compact representation of a component. It lists the realized classifiers, interfaces, and artifacts. It uses compartments to list the components of a component. For example:

   

   In the above example, Customer realizes the Inventory Management component. The component includes a provided interface Customer and a required interface Owner. Inventory Management includes an artifact named InventoryManagement.jar.

2. White box view: The white box view describes which classes, components, and interfaces a component uses to achieve its functionality. It focuses on the contents of a component. For example:

   

   The white box view displays the interfaces, classes, and components used by a component. In the above diagram, DataReciever and Owner are the interfaces, and FeedInfo and Entry are the internal parts of the component.

3. Black box view: The black box view shows what the components of a system are and how they are interconnected. The black box view shows multiple components of a system. It displays the big picture of the component of a specific system. For example:

   

   In the above diagram, there is a system of Inventory, where Inventory Management and Invoice are its key components. They are interconnected and they work together.

Component instantiation: UML offers 2 variants for instantiating components; the variants are direct and indirect. An indirect instantiated component is represented by its realized classifiers and a direct instantiated component is represented through an instance of the component with the instances of the realized classifier. The isIndirectlyInstantiated property is used to identify which of the two variants is to be applied. If default is used, the component is indirectly instantiated.

Connectors: Connectors are notations that are used for graphical representation of relationship in Unified Modeling Language (UML) diagrams. Connector is a line that represents a relationship between shapes. It shows all or part of the semantic information about the underlying relationships, but does not contain any semantics. Each connector represents only one relationship, and each relationship is represented by one connector. However, a relationship can be represented by multiple instances of a connector or none at all, in one or more diagrams.

Each connector has properties that govern its appearance in a diagram. Any modification in these properties only changes the appearance of the connector and does not affect the underlying relationship or any other connectors that represent the relationship. The component diagram uses two types of connectors:

1. Delegation connector: A delegation connector accepts an invocation that arrives at a port and forwards it to the appropriate part of the component. If delegation connector is connected to more than one subordinate port, request will be delivered to all of them that support request. It is denoted through a solid arrow from the port to the realizing part or in the opposite direction. The keyword delegate is stated near the arrow. For example:

   

2. Assembly connector: An assembly connector is used to connect two parts where one part offers service and the other part requests service. It can be modeled between a port and a part. The service that is going to be provided is defined by interfaces of the pertaining classifiers. The assembly connector is represented through a provided and requested interface.

   The assembly connectors are drawn as lollipop and socket symbols next to each other. In this notation, a circle or a semi-circle with a stick is used to represent the supplied and required interfaces. The implementation of an interface uses a circle connected to the classifier that supplies the interface by a stick. The required interface uses a semi-circle, and the classifier requests the interface by a stick. For example:

   

Realization relationship: In UML modeling, a realization relationship is a relationship between two model elements, in which one model element (the client) realizes the behavior that the other model element (the supplier) specifies. A realization is indicated by a dashed line with an unfilled open arrowhead towards the supplier. Realizations can only be shown on class diagrams. A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element. A realization relationship between classes and interfaces, and between components and interfaces shows that the class realizes the operations offered by the interface.

• Previous Entry: What is alternate access mapping?
• Next Entry: What is virtual hosting?