<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:ContentDescription 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="-c5Uh71vXTPN-VmrGYVRV7w"
    name=",_bFjlAPTYEduDKIuqTXQ8SA" guid="-c5Uh71vXTPN-VmrGYVRV7w" changeDate="2007-04-27T09:52:05.024-0700">
  <mainDescription>&lt;p>&#xD;
    Designing a system is about creating the internal structure and behavior of a system that's robust, extensible, and&#xD;
    high-quality. Good design improves quality and makes a system easier to maintain and extend, while a poor design can&#xD;
    significantly raise the cost of producing and maintaining the software.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Design is an abstraction of the code that presents the system from a perspective that makes it easier to address the&#xD;
    structure and behavior of the software. This can be done through viewing the code, but it's more difficult and less&#xD;
    effective to address structural and behavioral issues this way. Design can be visual models, simple sketches, text&#xD;
    descriptions, etc. The critical element of design is that it describes how different elements of the system interact to&#xD;
    fulfill the requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The amount of design that's formally documented and maintained will vary depending on the criticality of the design and&#xD;
    how much of the design needs to be communicated to future team members. At a minimum, all architecturally significant&#xD;
    design elements should be documented and kept up-to-date with the implementation. These are critical aspects of the&#xD;
    system that are necessary for the understanding and maintenance of the software. Other important or complex structure&#xD;
    and behavior may be maintained as well. And some contracts may require that the entire design is throughly documented.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    On many projects there will probably be aspects of the design that are only documented for the purpose of creating a&#xD;
    solution or walking through how certain behavior will be realized. It may not be worth the overhead of maintaining this&#xD;
    information as the design is transformed through refactoring and other influences. However, it may be useful to archive&#xD;
    the initial decisions, whiteboard images, or files so they can be referenced in the future if necessary. These can be&#xD;
    viewed as &quot;old meeting minutes&quot; that are stored for potential future reference. They may not reflect the current&#xD;
    design, but they may still provide useful insight.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Multiple Passes&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The design will be revisited many times throughout an iterative lifecycle and even within an iteration. Each time some&#xD;
    design activity is being performed, it will be performed in the context of a specific goal. The goal might be to&#xD;
    identify a notional set of participants in a collaboration that can be exercised to realize the behavior required (an&#xD;
    analysis pass). The goal might be in the identification of some coarse-grained elements that are required to act out&#xD;
    some scenario (an architectural pass). Then a pass might be done within one of those components to identify the&#xD;
    elements within that will collaborate together to perform the behavior required (a more detailed design pass).&lt;br />&#xD;
    &lt;br />&#xD;
     Design might be performed in a particular context such as database context, user-interface context, or perhaps the&#xD;
    context of how some existing library will be applied. In these cases the design steps will be performed just to make&#xD;
    and communicate decisions regarding that context&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Avoid analysis paralysis. Avoid refining, extending, and improving the design beyond a minimal version that suffices to&#xD;
    cover the needs of the requirements within the architecture. Design should be done in small chunks, proven via&#xD;
    implementation, improved via refactoring, and integrated into the baseline to provide value to the stakeholders.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Design versus Architecture&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Design is a real thing, the construction of the system’s structure and behavior. Architecture [link to concept on&#xD;
    Software Architecture] defines principles, contexts, and constraints on the system’s construction. Architecture is&#xD;
    described in architecture artifacts, but it’s realized as design (visual or otherwise) and implementation.&lt;br />&#xD;
    &lt;br />&#xD;
     One way to look at architecture is that it helps to make the entire design more cohesive with itself by balancing the&#xD;
    needs of the entire system. Design tends to focus on one area at a time. Architecture helps assure the design is&#xD;
    consistent and appropriate to the goals of the system. For instance, there may be constraints placed on most of the&#xD;
    design to support the performance of one part of the system, such as improving access to a legacy system. Failure to&#xD;
    conform to those constraints in the design may cause the system to fail to meet the performance requirements of the&#xD;
    legacy system access. Conforming to the architecture assures that all the goals of the system are met by balancing&#xD;
    competing technical issues.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Quality of Design&#xD;
&lt;/h3>&#xD;
&lt;h4>&#xD;
    You Arn't Going to Need It&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The YAGNI principle is a good general approach to design. While designs should be robust enough to modify, re-use, and&#xD;
    maintain, it should also be as simple as possible. One of the ways to keep it simple is to make few assumptions about&#xD;
    what the design's going to need in the future. Don't assume you'll need something until you know you need it, then do a&#xD;
    good job of adding it. Add what's needed for the current requirement or iteration. Refactor the design as necessary&#xD;
    when more functionality needs to be added or the design must be made more complex to deal with new circumstances.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Coupling and Cohesion&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Two of the most fundamental principles of design are coupling and cohesion. A good design contains elements that have&#xD;
    high cohesion and low coupling. High cohesion means that a single element, such as a class or subsystem, is composed of&#xD;
    parts that are closely related or work closely together to fulfill some purpose. Low coupling means that the elements&#xD;
    of a system have a minimum of dependencies on each other. A single element such as a subsystem should be easily&#xD;
    replaceable by another subsystem that provides similar behavior.&lt;br />&#xD;
    &lt;br />&#xD;
     For example, in a payroll system an Employee class would have high cohesion if it contained elements and functions&#xD;
    such as Name, Tax ID Number, and Monthly Salary. At first, it may seem as if the Calculate Paycheck functional would&#xD;
    also be cohesive. But when you consider that hourly employees must be paid overtime, sales people must have commission&#xD;
    calculated for them, etc, the function is less related to Employee and should probably be its own class or&#xD;
    subsystem.&lt;br />&#xD;
    &lt;br />&#xD;
     An example of low coupling would be if the Calculate Paycheck subsystem can be easily replaced by third party that may&#xD;
    be more robust and offer more features.&lt;br />&#xD;
    &lt;br />&#xD;
     Coupling and cohesion are so important to be aware of because they arise in so many design principles and design&#xD;
    strategies such as patterns.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Open-Closed Principle&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Elements in the design should be “open” for extension but “closed” for modification. The goal of this principle is to&#xD;
    create software than can be extended without changing code &lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html#MEY97&quot; guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[MEY97]&lt;/a>. This is because every change to software runs the risk of introducing bugs&#xD;
    into code that’s already correct. It also allows functionality to be re-used without having to know the details of the&#xD;
    implementation, reducing the time it takes to create something new. Keeping this principle in mind helps make a design&#xD;
    more maintainable.&lt;br />&#xD;
&lt;/p>&amp;nbsp;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>