| <?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.3/uma.ecore" 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"> |
| <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> |