<?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-8V5osHpRNG6Z7KPy8RGW1w" name=",_C4U9QPTeEduDKIuqTXQ8SA" guid="-8V5osHpRNG6Z7KPy8RGW1w" changeDate="2008-10-15T08:19:00.000-0700" version="7.5.0">
  <mainDescription>&lt;h3>&#xD;
    Review the design&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Design is best accomplished collaboratively, because it is a problem-solving activity with a range of&amp;nbsp;parts and&#xD;
    perspectives. There should be a constant level of review to ensure that the decisions make sense within the area being&#xD;
    designed and in the design of the system overall. There also might be occasions where some area of design is reviewed&#xD;
    by a set of interested or knowledgeable parties, such as the architect who will verify that the design conforms to an&#xD;
    architectural decision or a developer who will be expected to implement the design.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The design should be examined to ensure that it follows heuristics of quality design, such as loose coupling and high&#xD;
    cohesion. Responsibilities should be appropriately distributed to elements in ways that there are no elements with too&#xD;
    much responsibility and no elements that are left without any responsibilities. The design should be able to clearly&#xD;
    communicate the design decisions, yet not delve into concerns best dealt with during implementation of code.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Ensure that the design follows any project-specific guidelines and conforms to the architecture. Modifications to the&#xD;
    design to improve it (based on issues identified in reviewing it) should apply &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/guidelines/refactoring_F3D63EBD.html&quot;&#xD;
    guid=&quot;_YNx2sJ05EdyQ3oTO93enUw&quot;>Refactoring&lt;/a>&amp;nbsp;to ensure that the design and any existing implementation of the&#xD;
    design continues to fulfill its responsibilities.&#xD;
&lt;/p>Revisit the relationships between elements to improve the coupling in the design. Remove redundant relationships, try&#xD;
to make relationships unidirectional, and so forth. See &lt;a class=&quot;elementLinkWithType&quot;&#xD;
href=&quot;./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html&quot;&#xD;
guid=&quot;__MnggPTdEduDKIuqTXQ8SA&quot;>Guideline: Analyze the Design&lt;/a> for more information. &#xD;
&lt;h3>&#xD;
    Refine the design&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    After creating an implementation that includes a set of collaborating elements, with the behavior and relationships&#xD;
    robust enough to pass developer tests, the design can be improved and transformed into a more robust and maintainable&#xD;
    system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The visibility of each operation should be selected to be as restrictive as possible. Based on walking through the&#xD;
    scenario, it should be clear which operations must be available to other elements in the design and which can be&#xD;
    considered behavior inside of the element that has the operation. Minimizing the number of public operations creates a&#xD;
    more maintainable and understandable design.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    With respect to parameters, the return value, and a description of how it perform the behavior, operations can be&#xD;
    detailed at a lower level that drives the actual implementation, or that detail might be left to be handled when&#xD;
    writing the code.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Data attributes can be identified based on information needed to support behavior or based on additional requirements,&#xD;
    such as information to be presented to the user or transmitted to another system. Avoid indiscriminate domain analysis,&#xD;
    because there might be a great deal of data in the domain that is not needed to support the requirements. Data&#xD;
    attributes can simply be identified or they can be designed in detail, with attribute types, initial values, and&#xD;
    constraints. Decide on the visibility of the data attribute; operations to access and update the data can be added or&#xD;
    deferred until implementation.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Generalization and interfaces can be applied to simplify or otherwise improve the design. Ensure that the use of these&#xD;
    techniques actually improves the design, rather than bogging it down with complexity. For example, common behavior can&#xD;
    be factored into a parent class through generalization or out to a helper class through delegation. The latter solution&#xD;
    can be more understandable and maintainable, because generalization is an inflexible relationship (see the section that&#xD;
    follows on inheritance).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The refinement of any portion of the design could include another pass through the design process. You might find that&#xD;
    what was initially identified as a single behavior of an element warrants a detailed walkthrough of the collaborating&#xD;
    elements to realize that behavior.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When updating an existing design -- especially one that has had portions already implemented -- apply refactoring to&#xD;
    ensure that the improved design continues to perform as expected.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Organize elements&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    In a design of any notable size, the elements must be organized into packages. Assign the elements to existing or new&#xD;
    packages, and ensure that the visibility relationships between the packages support the navigation required between the&#xD;
    elements. Decide whether each element should be visible to elements outside of the package.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When structuring the design into packages, consider &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html&quot;&#xD;
    guid=&quot;_0gpkAMlgEdmt3adZL5Dmdw&quot;>Layering&lt;/a> and other patterns. Although all design work must conform to existing&#xD;
    architectural decisions, the allocation of elements to packages and possible updates to package visibility are of&#xD;
    significant architectural concern. The developer should collaborate with the architect to ensure that package-level&#xD;
    decisions are in accordance with the rest of the architecture.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This guideline first talks about the identification and design of the elements and then about organizing the elements&#xD;
    into packages. However, this is not a strict order of events. There is nothing wrong with identifying a package&#xD;
    structure for the system and then populating that structure with identified elements, as long as the actual elements&#xD;
    identified are allowed to influence the resulting package structure. See the sections on identification and behavior of&#xD;
    elements in &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html&quot;&#xD;
    guid=&quot;__MnggPTdEduDKIuqTXQ8SA&quot;>Guideline: Analyze the Design&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    Identify patterns&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    Identifying &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../core.tech.common.extend_supp/guidances/concepts/pattern_10BE6D96.html&quot;&#xD;
    guid=&quot;_0YJvUMlgEdmt3adZL5Dmdw&quot;>Pattern&lt;/a>s and seeking opportunities to leverage patterns are useful techniques. The&#xD;
    value of patterns here is that they provide a shortcut to a robust design. For instance, when there's an interface&#xD;
    realized by multiple classes, it's possible that an Abstract Factory pattern will be useful, because the pattern&#xD;
    encapsulates the logic of what class should be instantiated. The more experienced a developer is, the better the&#xD;
    developer is at identifying opportunities to take advantage of, or leverage, patterns.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The longer you use patterns, the easier it will be to identify opportunities to leverage them. At first, look for&#xD;
    places where you can clearly specify the need for some behavior. Perhaps there's a place where some function or&#xD;
    algorithm must be shared between many different classes. How can this behavior be shared over and over among&#xD;
    heterogeneous classes? Or perhaps a third-party library is replacing a block of custom code. Is there a way to make&#xD;
    this transition easier by creating an interface that can use either implementation? These are opportunities for finding&#xD;
    or possibly creating a pattern.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    See also &lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
    href=&quot;./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#GAM95&quot;&#xD;
    guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[GAM95]&lt;/a>&amp;nbsp;and &lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
    href=&quot;./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#SHA05&quot;&#xD;
    guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[SHA05]&lt;/a>&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Inheriting behavior versus inheriting interfaces&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Inheritance (or generalization) is often used as a shortcut during implementation to quickly re-use behavior (code).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;b>Caution:&lt;/b>&lt;br />&#xD;
    Work hard to remove behavior inheritance in design. It will almost always cost more effort than it saves.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Inheritance is a very rigid structure with strict rules. A class that inherits from another class is establishing an&#xD;
    &lt;b>is-a&lt;/b> relationship. The inheriting class is a type of the parent class-- the child has the same relationships and&#xD;
    behaviors as the parent. In most hierarchies, it will be impossible to maintain this type of relationship. Exceptions&#xD;
    quickly creep in, and it's common to find child classes that remove or override behavior in the parent classes. This&#xD;
    increases maintenance costs and makes it difficult to understand what each class does.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It's also too tempting to instantiate parent classes, which makes the parent class both abstract and concrete. If a&#xD;
    class has children, it must be abstract enough to support the generalized behavior of the children. But if it's&#xD;
    instantiated, it must be concrete enough to provide specific behavior. It's rarely possible to fulfill both of these&#xD;
    competing imperatives at the same time, and the design suffers.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Use association and aggregation relationships instead of inheriting behavior. Patterns are a good tool to leverage in&#xD;
    breaking up inheritance hierarchies.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Inheriting interfaces is safe, because only the description and not the implementation of what needs to be done is&#xD;
    reused.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Avoiding inheriting behavior is an application of the Open-Closed Principle. See &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../practice.tech.evolutionary_design.base/guidances/concepts/design_E36137FA.html&quot;&#xD;
    guid=&quot;_bFjlAPTYEduDKIuqTXQ8SA&quot;>Concept: Design&lt;/a> for more information.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    &lt;strong>Revisit the analysis&lt;/strong>&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The &lt;a class=&quot;elementLinkWithType&quot;&#xD;
    href=&quot;./../../../practice.tech.evolutionary_design.base/guidances/guidelines/analyze_the_design_4C4750C0.html&quot;&#xD;
    guid=&quot;__MnggPTdEduDKIuqTXQ8SA&quot;>Guideline: Analyze the Design&lt;/a>&amp;nbsp;describes techniques that are also useful when&#xD;
    evolving a more robust design.&lt;br />&#xD;
&lt;/p>&#xD;
&lt;h4>&#xD;
    &lt;strong>Consider the architecture&lt;/strong>&#xD;
&lt;/h4>&#xD;
&lt;p>&#xD;
    The architecture must be considered in all design changes. The &quot;best&quot; design for a particular part of the solution may&#xD;
    not be appropriate because of architectural constraints that must support the entire system. The architecture may also&#xD;
    help to make design decisions, because it can be part of the selection criteria between two potential solutions.&#xD;
    Developers should always be up-to-date with the architecture and review it often, particularly in early iterations.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This guideline remarks on conforming to the architecture in various ways; it is written as though it is about designing&#xD;
    within a pre-existing architecture. Although projects will often have pre-existing architectures available, a&#xD;
    particular architecture is the result of design activities. Therefore, in addition to discussing conformance to some&#xD;
    existing architecture, you must also consider the creation of the architecture, as well as updates and improvements&#xD;
    based on the work of design.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Also, see&amp;nbsp;&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
    href=&quot;./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html#SHA05&quot;&#xD;
    guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>[SHA05]&lt;/a> for a&amp;nbsp;useful introduction to object-oriented techniques that should be&#xD;
    applied when evolving a good design.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
