| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ArtifactDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="_zxB-QKYcEdmvhNXG0Oc2uA" |
| name="design,_0WuL8slgEdmt3adZL5Dmdw" guid="_zxB-QKYcEdmvhNXG0Oc2uA" changeDate="2007-03-03T04:48:41.814-0800" |
| version="1.0.0"> |
| <mainDescription><p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| It describes the elements that will make up the implemented system. It communicates abstractions of particular portions
 |
| of the implementation and can describe an&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
 |
| communicated.
 |
| </p></mainDescription> |
| <purpose><p>
 |
| Describe the&nbsp;elements of the system&nbsp;so&nbsp;they can be examined and understood in ways not&nbsp;possible by
 |
| reading the source code.
 |
| </p></purpose> |
| <impactOfNotHaving><p>
 |
| Implementation will proceed with fine-grained, inconsistent tactical decisions that lead to poor-quality software.
 |
| </p></impactOfNotHaving> |
| <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 <em>new</em>
 |
| design. In those cases, you can simply refer to some existing design.</reasonsForNotNeeding> |
| <representationOptions><p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p></representationOptions> |
| </org.eclipse.epf.uma:ArtifactDescription> |
