Work Product Descriptor (Artifact): Component Model
Describes the functional view of a system, including both the structure and modularity of the software components. Depicts the dynamic behavior of the components and the way in which they interact to accomplish the required functionality.
Purpose

The purpose of the component model is to help organize projects, manage the complexity of the solution, and ensure that all architecturally requirements have been addressed. It helps developers design and implement the solution and understand the big picture of the system design.

Relationships
Contained Artifacts
RolesResponsible: Modified By:
Description
Main Description

The component model describes the structure of a system in terms of its software components with their responsibilities, interfaces, relationships, and the way they collaborate to deliver the required functionality. The component model is the main artifact documenting the functional view of the architecture and serves as an abstraction of the design. Components identified may be decomposed into further component models before they complete the specification required for detailed design.

Component models help define and document:

  • The structure of the system
  • The recurring interactions and dependencies between sets of components
  • The components present within an enterprise, each of which may be made up of smaller components.

Component models are documented at 2 levels:

  • The logical level - focuses on specifying the components' responsibilities and characteristics required to deliver the requirements. These specifications are technology and product neutral.
  • The physical level -focuses on how to implement the components to meet the previously established specifications.

You may transform logical components into physical components via custom development, the purchase of products, or the reuse of assets.

It may be important to maintain a separation between logical and physical components on larger projects. However, smaller or less complex projects may evolve a single logical component model into a physical model, and end up with only a physical model.

Examples of components at the logical level are a 'Message Bus' or a 'Customer Relationship Manager' component. Components at the physical level that implement these logical components might be 'IBM WebSphere Message Broker' or 'Siebel Contact Center.'

Brief Outline

The Component Model consists of:

  • Introduction. Describes the context, purpose, scope, and intended audience of the component model.
  • Model Overview. Explains how the model has been organized, particularly if several component models were built.
  • Notation. If appropriate, describes any notation used in the document.
  • Overview of Layers and Subsystems. May describe logical components and/or physical components.
  • Component Relationship Diagrams. Shows the relationships between components.
  • Component Interaction Diagrams. Describes the collaboration between components.
  • Component Descriptions. Describes in detail each component's responsibilities and interfaces, required service levels (non-functional requirements), risk, design rationale, and implementation approach.
Notation

The different kinds of diagrams and their associated notation used in documenting the Component Model are summarized below.

Component Relationship Diagram

A Component Relationship Diagram shows the static dependency relationships between components or subsystems.
Component Diagram

                                                              Figure 1 - Component Relationship Diagram

Component Interaction Diagram

A Component Interaction Diagram shows the interactions between individual component instances and how a number of such component instances collaborate together to realize a scenario. Interaction diagrams also show the sequential flow of messages over time.

               Component Interaction Diagram

                                                                     Figure 2 - Component Interaction Diagram

Selected Representation

A UML modeling tool is the preferred method for developing the component model. UML 2.0 is the standard notation.

Properties
Optional
Planned
Illustrations
Key Considerations

Points to consider when deciding whether to use a Component Model:

  • A Component Model is useful when you must design the system for multiple target environments, with separate design architectures. The Component Model is an abstraction, or a generalization, of the system design. It omits most of the details of the design in order to provide an overview of the system's functionality.
  • The Component Model provides value when the design is complex, such that new team members need a simplified, abstracted model to understand it. A well-defined architecture can serve the same purpose.
  • Balance the extra work required to ensure that the component and design models remain consistent against the benefit of having a view of the system that represents only the most important details of how the system works. It can be very costly to maintain a high degree of fidelity between the Component Model and the system design. A less ambitious approach might be to maintain the Component Model with only the most important components and the key abstractions in the design. As the complexity of the Component Model increases, so does the cost to maintain it.
  • Once you no longer maintain the Component Model, its value decays rapidly. At some point, it no longer accurately reflects the current functional design of the system. Deciding to no longer maintain the Component Model may be appropriate, as it may have served its purpose, but the decision should be a conscious one.

Component models tend to be useful in companies where systems live for decades, or where there are many variants of the system.

To ensure the successful development of a component model on a project, your team should:

  • Create a stable and coherent structure
  • Focus on the right levels of abstraction
  • Develop relationship and interaction diagrams in parallel
  • Select architecturally significant requirements as inputs to the Component Model
  • Plan how your team will leverage the Component Model throughout the project lifecycle
Tailoring
Impact of not having

It is difficult to gain an understanding of the structure of a complex system without some kind of component model.

The absence of this artifact may result in:

  • Difficulty managing the development project 
  • The need for individual designers and developers to understand most of the inner details of the entire system 
  • Difficulty managing parallel development due to imprecise definitions of the work allocated to development groups
  • Missed opportunities for reuse of high level components 
  • An incomplete design with key design elements missing
  • Lack of information (such as the relevant service level requirements) essential to the appropriate placement of applications and data across the system infrastructure
  • Difficulty tracing requirements through implementation and validating that the architecturally significant requirements are realized in the executable architecture
Reasons for not needing

A Component Model may not be necessary when:

  • The overall system to be developed is quite small
  • The functional view of the overall system can be adequately described in some other form, as may be the case with a simple package-based organization of the architecture
Representation Options

Ideally, you should represent component models using a UML modeling tool that supports the UML 2 notation defined for this artifact. Modeling tools help ensure consistency between models and between the various diagrams they contain by allowing model elements to be shared among many models or diagrams. These tools also allow multiple views of the same model.

Alternatively, you can represent component models through a series of stand-alone diagrams developed in diagramming tools, then bound together within a word-processing document. A diagramming tool is difficult to maintain if any model element appears in multiple diagrams, as changes to the model element must be made in each diagram on which it appears. These tools may be appropriate for smaller projects in which the development and maintenance of the component model is limited in scope, resources and effort. However, this approach is impractical for a team of practitioners responsible for maintaining an up-to-date component model that interoperates with other models, such as the requirements and operational models.

Whichever option you choose, do not underestimate the importance of using a common notation and standard like UML 2. All diagrams, irrespective of representation option, should use formal notation, and UML 2 is recommended.

More Information
Checklists
Concepts
Guidelines
Estimation Considerations