blob: 01bbce6686a336352d7325d8d6894dea894e4aef [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" xmlns:xmi="" xmlns:org.eclipse.epf.uma="" epf:version="1.0.0" xmi:id="_zxB-QKYcEdmvhNXG0Oc2uA" name="design,_0WuL8slgEdmt3adZL5Dmdw" guid="_zxB-QKYcEdmvhNXG0Oc2uA" changeDate="2007-03-03T07:48:41.814-0500" version="1.0.0">
This product can describe multiple static and dynamic views of the system for examination. Although various views may
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. It communicates abstractions of particular portions
of the implementation and can describe an&amp;nbsp;encapsulated subsystem, a high-level analysis of the system, a view of
the system in only one context, or other perspectives that explain a solution to a specific problem that needs to be
Describe the&amp;nbsp;elements of the system&amp;nbsp;so&amp;nbsp;they can be examined and understood in ways not&amp;nbsp;possible by
reading the source code.
Implementation will proceed with fine-grained, inconsistent tactical decisions that lead to poor-quality software.
<reasonsForNotNeeding>Some representation of the design will always be necessary. In circumstances where a project involves applying
well-understood, existing strategies for architecture and design, it is possible that you will not need a &lt;em&gt;new&lt;/em&gt;
design. In those cases, you can simply refer to some existing design.</reasonsForNotNeeding>
It is important that the author of this work product be able to analyze key decisions about the structure and behavior
of the system and communicate them to other collaborators. It is also important that these decisions can be
communicated at various levels of abstraction and granularity. Some aspects of the design can be represented by source
code, possibly with some extra annotations. But more abstract representations of the design will be at a higher-level
than source code.
The more abstract representation could use various representation options. UML could be used either strictly or
informally; it is a preferred notation based on its rich semantics and broad usage in the industry. Other techniques
could be used to communicate the design. Or the design could use a mix of techniques as applicable.
Whether you record these representations on a white board or use a formal tool is not governed by this process. But any
representation, whether characterized as formal or informal, should unambiguously communicate the technical decisions
embodied by the design.