UML Component Diagrams and Package Diagrams

Component Diagrams

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.

Package Diagrams

A package diagram in the Unified Modeling Language depicts the dependencies between the packages that make up a model.

Overview

In addition to the standard UML Dependency relationship, there are two special types of dependencies defined between packages:

• package import
• package merge

A package import is “a relationship between an importing namespace and a package, indicating that the importing namespace adds the names of the members of the package to its own namespace.” By default, an unlabeled dependency between two packages is interpreted as a package import relationship. In this relationship, elements within the target package will be imported into the source package.

A package merge is “a directed relationship between two packages, that indicates that the contents of the two packages are to be combined. It is very similar to Generalisation in the sense that the source element conceptually adds the characteristics of the target element to its own characteristics resulting in an element that combines the characteristics of both” In this relationship, if an element exists within both the source package and the target package, then the source element’s definition will be expanded to include the target element’s definition.

Elements

1. Package: a general purpose mechanism for organising model elements & diagrams into groups. It provides an encapsulated namespace within which all the names must be unique. It is used to group semantically related elements. It is a namespace as well as an element that can be contained in other packages’ namespaces.
2. Class: a representation of an object that reflects its structure and behavior within the system. It is a template from which running instances are created. Classes usually describe the logical structure of the system.
3. Interface: a specification of behavior. An implementation class must be written to support the behavior of an interface class.
4. Object: an instance of a class. It is often used in analysis to represent an artifact or other item.
5. Table: a stereotyped class.

Usage

Package diagrams can use packages containing use cases to illustrate the functionality of a software system.

Package diagrams can use packages that represent the different layers of a software system to illustrate the layered architecture of a software system. The dependencies between these packages can be adorned with labels / stereotypes to indicate the communication mechanism between the layers.

When to use

1. It is used in large scale systems to picture dependencies between major elements in the system
2. Package diagrams represent a compile time grouping mechanism.