| <?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" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.2.0" xmi:id="-1vS_ELnQxGQKwfCrRYrc7w" |
| name="new_guideline,__MnggPTdEduDKIuqTXQ8SA" guid="-1vS_ELnQxGQKwfCrRYrc7w" changeDate="2008-02-15T07:35:47.343-0500"> |
| <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 also 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="./../../../core.tech.common.base/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.
 |
| </p>
 |
| <p>
 |
| 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="./../../../nullsoftware_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, the 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="./../../../core.tech.common.base/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>
 |
| 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>
 |
| <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>
 |
| <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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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.
 |
| </p>
 |
| <p>
 |
| 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="./../../../practice.tech.evolutionary_design.base/guidances/guidelines/evolve_the_design_3C9D6965.html"
 |
| guid="_C4U9QPTeEduDKIuqTXQ8SA">Guideline: Evolve the Design</a>.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
