Rational Modeling: Components Diagram

Component diagrams

In UML, component diagrams show the structure of the software system, which describes the software components, their interfaces, and their dependencies. You can use component diagrams to model software systems at a high level or to show components at a lower, package level.

This type of diagram supports component-based development in which a software system is divided into components and interfaces that are reusable and replaceable.

Component diagrams are useful for the following reasons:

• Defining the executable and reusable aspects of a software system
• Revealing software configuration issues through dependency relationships
• Showing an accurate depiction of a software application before you make changes or enhancements

You can also use component diagrams to depict the following physical parts of a software system:

• Source code files that you develop in an integrated development environment
• Executable files that are necessary to deliver a running system
• Physical databases that store information in the tables of a relational database or in the pages of an object-oriented database
• Adaptable systems that have components that migrate for load balancing and failure recovery

Note: Component diagrams are distinct from deployment diagrams. A component diagram defines the composition of components and artifacts in the system. A deployment diagram shows components and artifacts in relation to where they are used in the deployed system.

The following topics describe model elements in component diagrams:

• Components
  In UML modeling, components are model elements that represent independent, interchangeable parts of a system. They conform to and realize one or more provided and required interfaces, which determine the behavior of components.
• Component instances
  In UML modeling, component instances are model elements that represent actual entities in a system.
• Packages
  Packages group related model elements of all types, including other packages.
• Artifacts
  In UML models, artifacts are model elements that represent the physical entities in a software system. Artifacts represent physical implementation units, such as executable files, libraries, software components, documents, and databases.
• Interfaces
  In UML modeling, interfaces are model elements that define sets of operations that other model elements, such as classes, or components must implement. An implementing model element realizes an interface by overriding each of the operations that the interface declares.
• Relationships in component diagrams
  In UML, a relationship is a connection between model elements. A UML relationship is a type of model element that adds semantics to a model by defining the structure and behavior between model elements.