Artifact: Component Design
This artifact describes the realization of one or more components, detailing their internal behavior and any other design level details important to their implementation.
Domains: Architecture
Purpose

This artifact serves as an abstraction of the implementation and technology choices and is used to:

  • Conceive and/or document the design
  • Establish traceability from the design back to the architecture as the component realizations described in this artifact conform to their corresponding specifications in the architecture
  • Assist with the partitioning of work, particularly in large systems
  • Ensure that design principles, patterns and mechanisms are applied in a consistent fashion
  • Gain agreement before implementation or to document key aspects of the design after implementation, or both


Relationships
Description
Main Description

This artifact is a specification of the internal structure and behavior of one or more major structural elements (components) of a system.  Each component realization describes the internal behaviors of a component that realize its interfaces.

Brief Outline

This artifact typically contains:

  • Overview and context information
  • Design packages
  • Component realizations
    • Overview of the design, constraints, and goals for the component
    • Key relationships between internal component elements
    • Diagrams describing how the component's internal elements realize its specified interface operations
  • Design-level collaborations focused around a particular set of requirements, for example, use case realizations
  • Implementation guidance
Notation

UML 2.0 provides the graphical notation and semantics for component design modeling. Key constructs and diagrams are briefly described below.

Component
The black-box view of a component is represented in UML 2.0 as a rectangle with the name of the component inside. It has a stereotype of <<component>> and can include a tabbed rectangle icon. It can include compartments for interfaces as well as artifacts.

                                Black Box Component               Black Box Component with Interface Compartments

                                              Figure 1: Black Box Component Representations


White-box component realizations can be represented a few ways depending on the complexity of the component or the amount of documentation required.

The simplest approach is to add a compartment stereotyped <<realizations>> to the black-box component and list the classifiers that realize it.

                                                      White Box Component - simple representation

                                       Figure 2: White Box Component – Simple Representation


Another approach shows each classifier with a dependency to the component it realizes.


                    White box Component - showing dependencies

                              Figure 3: White Box Component – Representation Showing Dependencies


When a detailed view of component internals is required, place the component’s classifiers inside of the black-box component rectangle.  Ports specify a point of interaction between the component and its environment and between the component and its internal classifiers. Connectors map a port to the internal classifier that realizes the functionality.  A connector is described by a solid line with a filled arrow from the port (a small square symbol) to the classifier.

                    White Box Component - complex representation

                                             Figure 4: White Box Component – Detailed Representation


For white-box views of very complex components you can create a separate class diagram that links to its component. Note that components can be nested inside other components.


Representing Static and Dynamic Aspects of a Component

Class Diagram

The static aspects of a component’s internal design are described by UML class diagrams. The class diagram is a structural representation of objects and their static relationships described using the following structuring constructs:

  • Classes
  •  Attributes (representing the knowledge responsibilities or data)
  • Methods (representing operational responsibilities or functions)
  • Association relationships between classes
  • Aggregation relationships between aggregate and component classes
  • Inheritance relationships between superclasses and subclasses
  • Formal or informal constraint descriptions

                                                Class Diagram

                                                                     Figure 5: Class Diagram

Interaction Diagram


The dynamic aspects of a component’s internal design are described by UML interaction diagrams (sequence or communication diagrams).  These diagrams show how the sequence of interactions between the component’s internal classifiers realizes its specified interfaces.


Sequence diagrams are better for displaying and understanding the trace of messages or communication patterns. Collaboration diagrams are better for displaying the relationships between the objects involved in the interaction. Sequence diagrams tend to be the most common form of interaction diagram, because the goal of most interaction diagrams is to describe communications rather than relationships.

                  Collaboration Diagram

                                                           Figure 6:  Collaboration Diagram



        Sequence Diagram

                                                         Figure 7: Sequence Diagram



For more notation information, see Guideline: Component Design Modeling 

Key Considerations

In circumstances where the design of a component involves applying well understood, existing strategies, it is possible that you will not need a new design. In those cases, you can simply refer to some existing design.

Decide on the following:

  • Properties to include
  • Whether or not any extensions to the Unified Modeling Language (UML) are needed; for example, your project may require additional stereotypes
  • The level of formality applied to the model
  • If the model is mapped to other models, such as an architectural models and how
  • Whether a single model or multiple models will be used
  • How the model is mapped to an implementation model (this is very much affected by the decision to use reverse-engineering, code generation, or round-trip engineering); see Concept: Mapping from Code to Design
Tailoring
Impact of not having

The absence of this artifact may result in:

  • Incomplete specification of code with design decisions left undocumented and not easily recognizable from the source code
  • Poor extensibility and maintainability of components
  • Incomplete coverage of objects, relationships, and constraints to the design
  • Incomplete and erroneous realization of the interfaces required by the components of the system
Reasons for not needing

Reasons for not needing this artifact include:

  • There is no code or minimal code in this project
  • The implementation language is not an object-oriented language
  • The project is configuring packaged products rather than developing custom components
  • The design is expressed using another form, such as CRC cards
  • The implementation is understandable without design documentation
Representation Options

This artifact can be lightweight and informal, or substantial and formal according to the level of design that should be documented for the project.

Possible representations include the following:

  • Design documented directly in the code
  • A visual model created in a tool like Rational Software Architect
More Information
Checklists
Estimation Considerations