Components
Terminology
Internally, a well designed system is a network of interacting components.
A component is a cohesive, opaque, replaceable, functional module of a larger system.
The larger system can be a hardware, software, or business system, thus a component can be a hardware component, such as a device, microchip, or circuit; a software component such as a user interface, database, or message passing subsystem; or a component can be a business unit such as payroll, provider, or shipping. (See the Wikipedia article on Systems Theory for a good overview of the full scope of the system/component concept.)
A component's functionality is specified by a set of provided interfaces.
A component provides its services to other components. In turn, a component may require the services of other components. These requirements are specified by a set of required interfaces.
An interface is a set of related operations, properties, events fired, and conventions.
In the following UML Component diagram aComponent implements interfaces 1 and 2 and depends on otherComponent to implement interface 3:
A component can have instances just like use cases and classes.
An instance of a component is manifested as an artifact, which is usually a file:
Example
Component Containers
A component instance is usually deployed in a component container.
A component container manages a collection of third-party components. Managing components may include providing communication, lifecycle, discovery, and transaction services. The container may also specify a standard interface definition language (for example: WSDL, IDL, DCOM).
Examples of component containers include: J2SE, J2EE, .NET, MySQL.
Examples
Collaborations
Internally, a composite component is a network of sub-components.
Internally, a simple component is a collaboration.
A collaboration is a collection of classes that work together to achieve some common purpose (such as implementing several interfaces.)
Example
A virtual shopping cart implements the Checkout Interface and is realized by the CartImpl collaboration:
The CartImpl collaboration consists of four classes:
Interactions
An instance of the Cart component might contain instances of these four classes. but how do these objects collaborate? How do they interact with each other to implement the Checkout interface? To answer this question we use an interaction diagram. There are two types: collaboration diagrams and sequence diagrams.
Here's a sequence diagram:
Common Component Stereotypes
<<process>> Components
A process component provides some sort of functionality to other components.
A process component is usually transaction based.
A process component is usually stateful. A service component is a like a process component except that it is stateless.
Examples:
Message Passing System
Event Handling System
<<service>> Components
Components in a service oriented architecture (SOA).
Examples:
Web serivces
<<subsystem>> Components
A component can have subcomponents. We call these subsystem components.
Examples:
user interface
database system
business logic
Other Links
Component-Container Architecture