Component Diagram

• It represents pieces of software in the implementation environment.
  • They are used to model the physical aspects of a system.
  • Physical aspects are the elements such as executables, libraries, files, documents, etc.
  • This diagram does not describe the functionality of the system but it describes the components used to make those functionalities.
• The Class and Package diagrams model the logical design of the software.
  • The Component diagram models the implementation view.
• The Component diagram uses dependencies similar to the Package diagram.

Subsystem Diagram

• A subsystem is a cooperating set of *runtime objects* that form a cohesive group.
  • Packages are compile-time things, subsystems are run-time things.
  • Packages are made up of *classes*, not *objects* and they are not the same as subsystems.
• A subsystem presents a standard set of interfaces to the outside world.
  • All access to the objects that comprise the subsystem should be through these interfaces.
• If you access the subsystem via a single object whose primary responsibility is to implement an access interface(s), that object is called a port.
• The classes that comprise the subsystem are often contained in a single package, but need not be.
• Subsystems are identified by the special symbol which can be placed in the tab or body of the box.
• In the following example, the classes that define objects in the JDBC subsystem are defined in the java.sql package.
  • The diagram at left shows both the standard and ball-and-socket-style interface notations.
  • UML also lets you put into the box a static-model diagram showing the classes that comprise the subsystem.