Artifact: Design |
This artifact describes the realization of required system functionality in terms of components and serves as an abstraction of the source code.
Domain: Development Work Product Kinds: Solution
Purpose
Describe the elements of the system so they can be examined and understood in ways not possible by reading the source code.
Relationships
Contained Artifacts | Design Component Use-Case Realization
Roles | Responsible: Developer | Modified By: Developer Architect
Tasks | Input To: Refine the Architecture Implement the Solution Design the Solution Define the Architecture Implement Developer Tests | Output From: Design the Solution Define the Architecture Refine the Architecture
Description
Main Description | This product can describe multiple, static and dynamic views of the system for examination. Though various views may strive to focus on divergent, seemingly independent issues of how the system will be put together and work, they should fit together without contradiction. It describes the elements that will make up the implemented system, but in being an abstraction of any particular implementation portions can describe an isolated subsystem, a high-level analysis view of the system, a view that only describes the system from one context, or various other perspectives that provide focus on a specific problem being solved or solution to be communicated.
Tailoring
Impact of not having | Implementation will carry on with fine-grained, inconsistent tactical decisions leading to poor quality software.
Reasons for not needing | Some representation of design will always be needed. In circumstances where a project is applying well-understood, existing strategies for architecture and design it is possible that no new design will be needed; the existing design can just be referenced in these cases.
Representation Options | It is important that the author of this work product be able to reason about and communicate key decisions of the structure of the system and the behavior of the system to other collaborators. It is also important that these decisions can be communicated at various levels of granularity. Whether these decisions are captured on a white board or using a formal tool is not enforced by this process. Certain parts of this artifact will be important to the understanding of the overall architecture. Those must be represented in some way that is long-lived. For other parts that are not architecturally-significant, this work product may be considered more of an informal result of the task of designing rather than a formal artifact.
More Information
Checklists | Design
Concepts | Visual Modeling
Guidelines | Design
This program and the accompanying materials are made available under the Eclipse Public License v1.0 which accompanies this distribution. View copyright information here: OpenUP Copyright