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
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. 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. Figure 2: White Box Component – Simple Representation Another approach shows each classifier with a dependency to the component it realizes. 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. 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 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. Figure 6: Collaboration Diagram Figure 7: Sequence Diagram For more notation information, see Guideline: Component Design Modeling
Selected Representation | Rational Software Architect
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 | Component Design UML Modeling
Guidelines | Component Design Modeling
Estimation Considerations | Component Design
© Copyright IBM Corp. 1987, 2009. All Rights Reserved. © Copyright ABC Corp. 2009. All Rights Reserved. Includes materials licensed from IBM and Eclipse. See IBM copyright and Eclipse copyright .