<?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="-1vS_ELnQxGQKwfCrRYrc7w"
    name="new_guideline,__MnggPTdEduDKIuqTXQ8SA" guid="-1vS_ELnQxGQKwfCrRYrc7w" changeDate="2007-07-18T07:01:37.507-0700">
  <mainDescription>&lt;h3>&#xD;
    Identification of elements&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Identify the elements, based on the needs of the requirements. The identification of elements can stem from a static&#xD;
    perspective of walking through the requirements and identifying elements clearly called out, which is a form of domain&#xD;
    modeling. This can pull in other elements identified as being in the application domain or deemed necessary from&#xD;
    examining the requirements for the portion of the system being designed. This identification can also pull from key&#xD;
    abstractions identified while defining the architecture.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The identification of elements should also apply a dynamic perspective by walking through scenarios of use of the&#xD;
    system (or subsystem) and identifying elements needed to support the behavior. That behavior might be a scenario of use&#xD;
    from an external user perspective or, while designing a subsystem, a responsibility assigned to the subsystem that has&#xD;
    complex algorithmic behavior. Consider applying the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/guidelines/entity_control_boundary_pattern_C4047897.html&quot; guid=&quot;_uF-QYEAhEdq_UJTvM1DM2Q&quot;>Entity-Control-Boundary Pattern&lt;/a> to identify the elements necessary to support the&#xD;
    scenario, or apply other patterns identified in the architecture that specify the elements that will be used to support&#xD;
    specific aspects of the scenario.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If you are designing a real-time system, include elements to represent events and signals that allow you to describe&#xD;
    the asynchronous triggers of behavior to which the system must respond. &lt;b>Events&lt;/b> are specifications of interesting&#xD;
    occurrences in time and space that usually (if they are noteworthy) require some response from the system.&#xD;
    &lt;b>Signals&lt;/b> represent asynchronous mechanisms used to communicate certain types of events within the system.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    If there are existing elements from previous passes over the design or from selected frameworks or other reusable&#xD;
    elements, reuse them whenever possible. See &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/guidelines/software_reuse_B6B04C26.html&quot; guid=&quot;_vO2uoO0OEduUpsu85bVhiQ&quot;>Guideline: Software Reuse&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    After identifying the elements, give each one meaningful name. Each element should also have a description, so that the&#xD;
    team members who work together to refine the design and implement from the design will understand the role that each&#xD;
    element plays.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Based on this information, the identification of elements could be applied several times in designing just one part of&#xD;
    the system. Although there is no one correct strategy for multiple passes, they could be done at a coarse-grained level&#xD;
    and then a fine-grained level, or at an analysis (abstract) level and then a design level.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Behavior of elements&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    To identify the behavior of the elements, go through scenarios and assign behavior to the appropriate collaborating&#xD;
    participants. If a particular use of the system or subsystem can have multiple possible outcomes or variant sequences,&#xD;
    cover enough scenarios to ensure that the design is robust enough to support the possibilities.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    When assigning behavior to elements, consider applying the &lt;a class=&quot;elementLink&quot; href=&quot;./../../../openup/guidances/guidelines/entity_control_boundary_pattern_C4047897.html&quot; guid=&quot;_uF-QYEAhEdq_UJTvM1DM2Q&quot;>Entity-Control-Boundary Pattern&lt;/a>&amp;nbsp;or other patterns identified in the&#xD;
    architecture.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Behavior can be represented as a simple statement of responsibility, or it can be a detailed operation specification.&#xD;
    Use the appropriate level of detail to communicate important design decisions while giving the freedom to make&#xD;
    appropriate implementation decisions as those tasks ensue.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Avoid too much identification of behavior solely from the perspective of domain modeling. Include only behavior that is&#xD;
    really needed -- behavior identified by going through required scenarios of system use.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Behavior must be understood as a responsibility of an element, as well as an interaction between two elements in the&#xD;
    context of some broader behavior of the system or subsystem. The latter part of this will lead the developer to&#xD;
    identify relationships that are necessary between the elements.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Design element relationships&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    The relationships between the elements necessary for the behavior must be designed. This can simply be the&#xD;
    identification of the ability to traverse from one element to another or else a need to manage an association between&#xD;
    the elements. Relationships can be designed in more detail, as appropriate. This can include: optionality,&#xD;
    multiplicity, whether the relationship is a simple dependency or managed association, and so on. These decisions that&#xD;
    drive implementation details are best made at the design level, where it is easier to see how all of the pieces fit&#xD;
    together.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Avoid defining too many relationships based on relationships in the application domain. Include only relationships that&#xD;
    are needed based on the requirements. On the other hand, a combination of requirements knowledge and domain knowledge&#xD;
    can lead to some detailed decisions on the relationships, such as optionality and multiplicity.&#xD;
&lt;/p>&#xD;
&lt;h3>&#xD;
    Analysis classes and YAGNI&#xD;
&lt;/h3>&#xD;
&lt;p>&#xD;
    Analysis classes are used to identify initial buckets where system functionality should go. They're the first pass at&#xD;
    understanding where system behavior will be realized in the design and implementation. For example, an entity class&#xD;
    might initially represent all of the behavior for an employee, such as storing personal information and calculating the&#xD;
    value of a paycheck. Few assumptions are made about how the final design will look at this point. Analysis classes are&#xD;
    about making sure required behavior is represented somewhere in the system, rather than about creating a perfect&#xD;
    design.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Analysis classes allow you to begin designing from abstractions, so that the details of the system depend on those&#xD;
    abstractions and not the other way around. In the Employee class, the notion of an employee should start with the idea&#xD;
    of someone who works for the company, who has responsibilities and receives benefits. It’s easier to create a design&#xD;
    from this simple idea. The complexity of the design should emerge from the abstract ideas of what the design needs to&#xD;
    do. This will also help keep coupling low and cohesion high.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    YAGNI (You Aren't Going to Need It) is an approach to design where the developer creates only enough implementation and&#xD;
    design to address the required functionality. No assumptions are made about re-use or possible future uses of the&#xD;
    software. Software is improved when the system requirements demand more functionality or robustness.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The first classes created from a YAGNI perspective are much like analysis classes. You don't know how complex it may be&#xD;
    to calculate a paycheck for your employee, so you assume that functionality is highly cohesive with the rest of what&#xD;
    the Employee class must do. As you understanding of the requirement develops, the analysis class evolves into a set of&#xD;
    collaborating classes and patterns that better support the behavior of the system. For example, payroll calculations&#xD;
    could be moved into a pattern that handles all of the different types of paycheck calculations (overtime, commissions,&#xD;
    and so forth), thereby increasing the internal cohesion of the class.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Use analysis classes to define an initial place to put system behavior, and add only enough behavior to satisfy the&#xD;
    YAGNI perspective. Analysis classes will evolve into concrete design classes as more behavior is added and as the&#xD;
    design is refactored. See &lt;a class=&quot;elementLinkWithType&quot; href=&quot;./../../../openup/guidances/guidelines/evolve_the_design_3C9D6965.html&quot; guid=&quot;_C4U9QPTeEduDKIuqTXQ8SA&quot;>Guideline: Evolve the Design&lt;/a>.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>