Task Descriptor: Detail Component Model |
Detail and structure the logical components, define their interfaces, and transform them into physical components.
Based on Method Task: Detail Component Model
Relationships
Roles | Primary: Architect | Additional: | Assisting:
Inputs | Mandatory: [Technical Specification] Architectural Decisions Architecture Overview Component Model | Optional: [Technical Design] Component Specification | External: None
Outputs | Architectural Decisions Component Model Component Specification
Steps
Review the architecture
Review the Architecture Overview, Component Model, and Architectural Decisions to familiarize yourself with the current state of the architecture. Update the artifacts with any new information that you have discovered since you outlined the Component Model.
Structure components
Review the candidate components that you identified when you outlined the architecture. These concepts were purposely simplified to omit details. Now it is time to refine these simplified concepts into well-structured logical components. A comprehensive Component Model is not the goal, however. Focus on architecturally significant elements. Refactor, package, and structure the high-level candidate components into detailed logical components. See Guideline: Structuring Components. Review your list of Reusable Assets and keep an eye out for reuse of existing products or subsystems. Identify components to align with existing resources where possible. If the target implementation environment is constrained and well-specified, you may directly identify and specify physical components without bothering with logical components. Update the Component Model and document the rationale for any key decisions.
Specify component interfaces
Make the responsibilities of your logical components available for use within the system by offering Interfaces to other components. First, decide which responsibilities need to be external to each component by looking at dependencies between components. Group like responsibilities together, and name the interface for each group of responsibilities. See Guideline: Specifying Components. Capture the interfaces for each component and the associated responsibilities in the Component Model using a Component Specification Diagram. Document the rationale for any key decisions you make.
Specify operations and signatures
For each interface that you have defined for your logical components, go through each responsibility and specify an operation and its signature. In the operation's signature, assign a type to each parameter and the return value. See Guideline: Specifying Components. Capture operations and their signatures in a Component Specification Diagram of the Component Model.
Specify pre- and post-conditions
Specify pre-conditions for operations to add clarity about what the caller is responsible for checking. Specify post-conditions to add clarity about the effect the operation has on the component's data or state. See Guideline: Specifying Components. Express pre- and post-conditions in the Component Model either using the formal Object Constraint Language (OCL) or using natural language.
Refine architectural mechanisms
Scan all Logical Components that use each analysis mechanism that you defined when you outlined the architecture. Based on the characteristics that these components share, refine and add detail to each mechanism, defining an appropriate Design Mechanism. Capture this detail in the component descriptions. The detail is still at the logical level, but it will help you select specific technologies when you transform your logical components into physical components. Document the rationale for any key decisions that you make.
Transform components
The Component Model created so far is at the logical level, and is deliberately product and technology agnostic. Component Transformation involves making decisions about what technology best implements each of the logical level components. At this point, make technology decisions about each component and transform it into a Physical Component. Transform your logical components into physical components by applying appropriate transformation patterns, which match the required functionality and available technologies. Document the rationale for any key decisions you make. For any logical components that have design mechanisms noted, select an [*Implementation Mechanism*] and apply the design pattern for the mechanism. Plug in your system's components as parameters to the design pattern. See [*Guideline: Transforming Components]. Repeat the steps of this task to specify details of your physical components.
Discover reuse opportunities
Review your list of potentially reusable assets and look for existing physical components that offer similar interfaces to the physical components that you identified in the previous step. If exact matches do not exist, find approximate matches. Modify your newly identified interfaces to improve the fit with existing ones. This may involve factoring the interface by splitting it into several interfaces, some of which match an existing component and some of which are new. Replace your interfaces with existing interfaces where exact matches occur. See Guideline: Software Reuse. Replace your physical components with existing components wherever possible to satisfy the required behavior of the system. In the Component Model, note the source of any component to be reused instead of built. Document the rationale for any key decisions you make.
Validate the architecture
Review the Component Model to ensure that it is complete and consistent. Review the goals, requirements, and constraints to ensure that your architecture meets them; update them with any new information that you have discovered. If you find items that your architecture has not yet addressed, go through this task again to fill in the holes. Review the Architectural Decisions to ensure that you have captured the rationale for any significant decisions that you have made, especially those that are controversial or are based on reasoning that is not obvious. Build an Executable Architecture to validate the architecture. Perform enough development work to produce just enough working software to show that the architecture is viable. It is acceptable for the software to have an incomplete or prototypical feel, as it is primarily concerned with baselining the architecture to provide a stable foundation for the remaining development work. Communicate the architecture to developers, and make sure that they understand it and can deliver it. Repeat the steps of this task as needed to incorporate their feedback. For checklists to assess the results of this task, refer to the output work products.
Properties
Multiple Occurrences |
Event Driven |
Ongoing |
Optional |
Planned |
Repeatable |