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