Task Descriptor: Outline Component Model |
Identify key logical components and define some initial high level collaborations between these components.
Based on Method Task: Outline Component Model
Relationships
Roles | Primary: Architect | Additional: | Assisting:
Inputs | Mandatory: [Technical Specification] Architectural Decisions Architecture Overview | Optional: Component Model | External: None
Outputs | Architectural Decisions Architecture Overview Component Model
Steps
Identify candidate components
Break the system up into major Logical Components to contain successively smaller components. These components help you manage complexity, and allow developers to design and implement parts of the system in parallel. Define the major components around an Architectural Pattern such as Layering. See Guideline: Abstract Away Complexity and Guideline: Layering. Identify candidate Logical Components to fulfill the architecturally significant functional requirements. Use key abstractions, or key concepts, identified in the requirements as inputs. Analysis Class that model the system boundaries, data, and control logic also make good candidates. See Guideline: Finding Analysis Classes. Name and briefly describe your candidate Logical Components in the Component Model. Visually model any obvious relationships using Component Relationship Diagrams. The components and relationships should not be highly detailed at this early stage. See Guideline: Identifying Components and Guideline: Using Visual Modeling.
Define responsibilities
Your goal in this step is to express the system behavior in terms of collaborating components by specifying the responsibilities of each component. Review the architecturally significant functional requirements, and look for the system behavior they describe. Allocate the behavior to responsibilities of one or more of your candidate components. Document each responsibility in the Component Model with a short name and description. State what the object does to fulfill the responsibility, and describe the result that occurs. Keep a "black box" focus on each component, and only specify externally observable responsibilities. See Guideline: Identifying Components. For more complex requirements (in which a number of components must interact to carry out system behavior), show component interactions in the Component Model using one or more Component Interaction Diagrams.
Map mechanisms to components
Review your list of Analysis Mechanisms and their attributes in the Architectural Decisions. Update the Component Model by listing the Analysis Mechanisms each component requires.
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 your list of potentially reusable assets for overlap with your candidate components. In the Component Model, note any components that you plan to reuse rather than build. 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. At this point, you have outlined but not detailed the Component Model, so keep your review informal. Communicate the outline to your developers, and make sure that they understand it and can deliver it. Repeat the steps of this task as needed to incorporate their feedback into the outline. For checklists to assess the results of this task, refer to the output work products.
Properties
Multiple Occurrences |
Event Driven |
Ongoing |
Optional |
Planned |
Repeatable |