OpenUP/OpenUP_baseline_EN/exported_HTML_0_9/openup_basic/tasks/design_solution.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>\openup_basic\tasks\design_solution.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: design_solution.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_0fshwMlgEdmt3adZL5Dmdw CRC: 4165556380 -->Design the Solution<!-- END:presentationName,_0fshwMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_0fshwMlgEdmt3adZL5Dmdw CRC: 838213958 -->Identify the elements and devise the interactions, behavior, relations, and data necessary to realize some functionality.<!-- END:briefDescription,_0fshwMlgEdmt3adZL5Dmdw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,_NrC20qeqEdmKDbQuyzCoqQ CRC: 577162411 --><p>
     This task is about designing part of the system, not the whole system.&nbsp; It should be applied based upon some small
     subset of requirements.&nbsp; The requirements driving the design could be scenario-based functional requirements,
     non-functional requirements, or a combination.
 </p>
 <p>
     This task can be applied in some specific context such as the database access elements required for some
     scenario.&nbsp; In this case the task might be applied&nbsp;again later&nbsp;to deal with a different context on the
     same requirements.&nbsp; Keep in mind that to actually build some functionality of value&nbsp;to the users, all
     contexts will typically need to be designed and implemented. For example, to actually utilize some system capability it
     will have to have been designed and implemented all its context such as user interface, business rules, database
     access, etc.
 </p>
 <p>
     If this task is being performed on an architecturally significant element the results of this design should be
     referenced by the architecture.
 </p><!-- END:mainDescription,_NrC20qeqEdmKDbQuyzCoqQ -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: keyConsiderations<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:keyConsiderations,_NrC20qeqEdmKDbQuyzCoqQ CRC: 607647162 --><P>Each step in this task can cause all previous steps to be revisited in light of new information and decisions.&nbsp; For example, while determining how elements collaborate&nbsp;you might find a gap in the requirements that causes you to go back to the beginning after collaborating with the analyst, or when evaluating the design a reviewer could&nbsp;note that a reusable element being used doesn't work as expected and that could cause you to identify new elements to take its place.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></P>
 <P>Consider the architecture while performing this task.&nbsp; All design work must be done while regarding the architecture within which the design exists.&nbsp; Furthermore, certain design elements will be deemed architecturally significant; those elements will require updates to the architecture. </P>
 <P>This task will be applied numerous times.&nbsp; Design is best performed in small chunks.</P>
 <P>Even when starting the design for a particular project it&nbsp;is expected that there will be existing frameworks and reusable elements.&nbsp; Every step of this task must give attention to the existing design and existing implementation, utilizing existing elements when possible and emulating or improving existing elements as appropriate while designing this portion of the solution. </P>
 <P>Apply patterns throughout this task.&nbsp; Patterns represent proven designs and their usage promotes quality and consistency across the design. </P><!-- END:keyConsiderations,_NrC20qeqEdmKDbQuyzCoqQ -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: purpose<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:purpose,_NrC20qeqEdmKDbQuyzCoqQ CRC: 4034027761 --><p>
     The purpose of&nbsp;this&nbsp;task&nbsp;is to describe the&nbsp;elements of the system so that they support the
     required behavior, are of high quality, and fit within the architecture.
 </p><!-- END:purpose,_NrC20qeqEdmKDbQuyzCoqQ -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_4Z7WYKuKEdmhFZtkg1nakg CRC: 3539482445 -->Understand requirement details<!-- END:name,_4Z7WYKuKEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_4Z7WYKuKEdmhFZtkg1nakg CRC: 1012897478 --><p>
     Examine the relevant <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>(s) and <a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a>&nbsp;to understand the scope of the design task and the
     expectations on the <a class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Work with the Stakeholder and Analyst to clarify ambiguous or missing
     information.
 </p>
 <p>
     If the requirements are not represented in some sort of scenario form (for example a non-functional requirement might
     not have a scenario associated with it), a scenario will have to be identified that appropriately exercises the
     requirements under consideration.
 </p>
 <p>
     If the requirements are&nbsp;determined to be&nbsp;incomplete or incorrect, work with the analyst to get the
     requirements improved and possibly submit a change request against the requirements.
 </p><!-- END:sectionDescription,_4Z7WYKuKEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_Ci7aYFixEdusJoWkvSRO9Q CRC: 1313874932 -->Understand the architecture<!-- END:name,_Ci7aYFixEdusJoWkvSRO9Q -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_Ci7aYFixEdusJoWkvSRO9Q CRC: 3306830448 --><p>
     Understand how the architecture applies to this part of the design, and how this design work fits with the rest of the
     system. Incorporate any applicable interfaces, key abstractions, mechanisms and patterns into the design work. Discuss
     possible refinements to the architecture and new areas of potential re-use with the architect.
 </p><!-- END:sectionDescription,_Ci7aYFixEdusJoWkvSRO9Q -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_--6tYKuKEdmhFZtkg1nakg CRC: 3224594196 -->Identify design elements<!-- END:name,_--6tYKuKEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_--6tYKuKEdmhFZtkg1nakg CRC: 2341138125 --><p>
     Identify the elements that collaborate together to provide the required behavior.&nbsp; This can start with the key
     abstractions identified in the architecture, domain analysis, and classical analysis&nbsp;of the requirements (noun
     filtering) to derive the&nbsp;elements that would be required to fulfill them.
 </p>
 <p>
     Identify elements in all perspectives being considered when performing this task.&nbsp; This could include identifying
     user interface elements,&nbsp;control elements, data elements,&nbsp;and elements relating to interfacing to other
     systems or devices.
 </p>
 <p>
     Existing elements of the design should be examined to see if they should participate in the collaboration.&nbsp; It is
     a mistake to create all new elements in each&nbsp;execution of this task.
 </p>
 <p>
     This list of candidates must be expanded to include special-purpose participants that handle&nbsp;particular roles in
     providing the required behavior such as transaction processing or adherence to some security specification.&nbsp; The
     <a class="elementLink" href="./../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a>&nbsp;provides a good start for identifying elements.
 </p><!-- END:sectionDescription,_--6tYKuKEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_A_LU8KuLEdmhFZtkg1nakg CRC: 2844361739 -->Determine how elements collaborate to realize the scenario<!-- END:name,_A_LU8KuLEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_A_LU8KuLEdmhFZtkg1nakg CRC: 2669209812 -->Walk through the scenario distributing responsibilities to the participating elements. These responsibilities can be simple
 statements of behavior assigned to elements; they need not be detailed operation specifications with parameters, etc. This
 step is about ensuring that a quality model is being created that is robust enough to support the requirements.&nbsp;
 <p>
     Identify the required relationships between the&nbsp;elements based on the walkthrough of the scenario examining how
     the elements initiate each other's behavior. An element that requests behavior from another element is represented as a
     relationship between those elements. As with the responsibilities, these relationships can just be defined at this
     step.
 </p>
 <p>
     Look to the architecture and previous design work to create a consistent collaboration. Use the Architect to explain
     the details and motivations of the architecture. Look to reuse existing behavior and relations or to apply similar
     structure to simplify the design of the overall system.
 </p>
 <p>
     Additional elements might be identified as behavior is found that cannot appropriately be assigned to any of the
     existing elements.
 </p><!-- END:sectionDescription,_A_LU8KuLEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_ENwJwKuLEdmhFZtkg1nakg CRC: 352956516 -->Refine design decisions<!-- END:name,_ENwJwKuLEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_ENwJwKuLEdmhFZtkg1nakg CRC: 2451428892 --><p>
     Refine the design to an appropriate level of detail to drive implementation and to ensure that it fits into the
     architecture.&nbsp; In this step the design can take into consideration the actual implementation language and other
     technical decisions.&nbsp; Revisit the identification of the elements and the collaborations&nbsp;that realize the
     scenarios if necessary as this refinement takes into consideration details at a lower level of abstraction. Discuss
     testability issues, such as&nbsp;design elements that are difficult to test or critical performance areas,&nbsp;with
     the Tester and Architect.
 </p>
 <p>
     In particular make decisions in regard to the considerations below:
 </p>
 <ul>
     <li>
         Specific details of relationships between the elements such as multiplicity and navigability
     </li>
     <li>
         Operation detail such as parameters and return values
     </li>
     <li>
         Existence and detail of data attributes necessary
     </li>
     <li>
         Usage of inheritance and interfaces to improve the design
     </li>
 </ul>
 <p>
     Incorporate <a class="elementLink" href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html" guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s from the architecture. Apply consistent structure of the elements
     and organization of the behavior as in other areas of the design and use patterns identified in the architecture.
 </p><!-- END:sectionDescription,_ENwJwKuLEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_KNZYAKuLEdmhFZtkg1nakg CRC: 419770836 -->Design internals (for large or complex elements)<!-- END:name,_KNZYAKuLEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_KNZYAKuLEdmhFZtkg1nakg CRC: 405028966 --><p>
     Design large or complex elements or some complex internal behavior in more detail. &nbsp;
 </p>
 <p>
     This might just involve devising an algorithm that&nbsp;could be performed to produce the desired behavior. Add
     additional operations, attributes, and relationships to support the expectations of an element. Discuss testability
     issues, such as&nbsp;design elements that are difficult to test or critical performance areas,&nbsp;with the Tester and
     Architect.
 </p>
 <p>
     The state of the&nbsp;element managed over the course of its lifetime&nbsp;can be designed to ensure proper behavior in
     various usages.
 </p><!-- END:sectionDescription,_KNZYAKuLEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_9LeFME42EdudDeUNeAxPCQ CRC: 3123982209 -->Design the database schema<!-- END:name,_9LeFME42EdudDeUNeAxPCQ -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_9LeFME42EdudDeUNeAxPCQ CRC: 2352077700 --><p>
     If the system has persistent data, the design will need to address&nbsp;the database (or file) schema.&nbsp; For a
     relational database schema, identify the following:
 </p>
 <ul>
     <li>
         The structure of tables and views
     </li>
     <li>
         Relationships between&nbsp;tables
     </li>
     <li>
         Triggers which enforce referential integrity
     </li>
     <li>
         Constraints on columns
     </li>
     <li>
         Default values for columns
     </li>
     <li>
         Stored procedures and functions
     </li>
 </ul><!-- END:sectionDescription,_9LeFME42EdudDeUNeAxPCQ -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_mUVt8BfnEduD353bkQ4frw CRC: 1605738521 -->Evaluate the design<!-- END:name,_mUVt8BfnEduD353bkQ4frw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_mUVt8BfnEduD353bkQ4frw CRC: 1610019147 --><p>
     Evaluate the object design for coupling, cohesion, and other quality design measurements.
 </p>
 <p>
     Evaluate the database/file design for performance, referential integrity, and normalization.
 </p>
 <p>
     Consider the design from various angles to ensure that it is a high-quality, communicable design.&nbsp; Work with other
     technical team members; an independent party can provide a fresh perspective.&nbsp;Use the Tester and Architect to
     provide perspectives on&nbsp;design quality and adherence to the architecture.&nbsp;However, when identifying potential
     reviewers keep in mind that if someone can add value by reviewing the design, then perhaps they could have added even
     more value by actively participating in the design effort itself.
 </p>
 <p>
     If design flaws are identified, improve the design.
 </p><!-- END:sectionDescription,_mUVt8BfnEduD353bkQ4frw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: name<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:name,_OGYbwKuLEdmhFZtkg1nakg CRC: 1999328299 -->Communicate the design<!-- END:name,_OGYbwKuLEdmhFZtkg1nakg -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: sectionDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:sectionDescription,_OGYbwKuLEdmhFZtkg1nakg CRC: 3988272218 --><p>
     Communicate&nbsp;the design to&nbsp;those who need to understand it. Though this is described here toward the end of
     the task, communication should be going on throughout the steps. Working collaboratively is always better than
     reviewing the work after it is complete.
 </p>
 <p>
     Here are some ways to communicate&nbsp;the design:
 </p>
 <ul>
     <li>
         Formal models&nbsp;specified in UML .
     </li>
     <li>
         Informal diagrams that render static structure and capture&nbsp;dynamic behavior.
     </li>
     <li>
         Annotated code that communicates information about the static structure supplemented with textual descriptions of
         dynamic behavior across code modules&nbsp;.
     </li>
     <li>
         Physical data models to describe the database schema.
     </li>
 </ul>
 <p>
     Here are some examples of individuals&nbsp;who will need to understand the design:
 </p>
 <ul>
     <li>
         Developers&nbsp;who will implement a solution based on the design.
     </li>
     <li>
         An&nbsp;architect who can review the design to ensure that it conforms to the architecture or who might examine the
         design for opportunities to improve the architecture.
     </li>
     <li>
         Other designers who can examine the design for applicability to other parts of the system.
     </li>
     <li>
         Developers or other designers who will be working on other parts of the system that will&nbsp;depend on the
         elements designed in this task.
     </li>
     <li>
         Other reviewers&nbsp;who will review the design for quality and adherence to standards.
     </li>
 </ul><!-- END:sectionDescription,_OGYbwKuLEdmhFZtkg1nakg -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>\openup_basic\tasks\design_solution.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: design_solution.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_0fshwMlgEdmt3adZL5Dmdw CRC: 4165556380 -->Design the Solution<!-- END:presentationName,_0fshwMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_0fshwMlgEdmt3adZL5Dmdw CRC: 838213958 -->Identify the elements and devise the interactions, behavior, relations, and data necessary to realize some functionality.<!-- END:briefDescription,_0fshwMlgEdmt3adZL5Dmdw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,_NrC20qeqEdmKDbQuyzCoqQ CRC: 577162411 --><p>
	This task is about designing part of the system, not the whole system.  It should be applied based upon some small
	subset of requirements.  The requirements driving the design could be scenario-based functional requirements,
	non-functional requirements, or a combination.
	</p>
	<p>
	This task can be applied in some specific context such as the database access elements required for some
	scenario.  In this case the task might be applied again later to deal with a different context on the
	same requirements.  Keep in mind that to actually build some functionality of value to the users, all
	contexts will typically need to be designed and implemented. For example, to actually utilize some system capability it
	will have to have been designed and implemented all its context such as user interface, business rules, database
	access, etc.
	</p>
	<p>
	If this task is being performed on an architecturally significant element the results of this design should be
	referenced by the architecture.
	</p><!-- END:mainDescription,_NrC20qeqEdmKDbQuyzCoqQ -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: keyConsiderations<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:keyConsiderations,_NrC20qeqEdmKDbQuyzCoqQ CRC: 607647162 --><P>Each step in this task can cause all previous steps to be revisited in light of new information and decisions.  For example, while determining how elements collaborate you might find a gap in the requirements that causes you to go back to the beginning after collaborating with the analyst, or when evaluating the design a reviewer could note that a reusable element being used doesn't work as expected and that could cause you to identify new elements to take its place.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p></o:p></P>
	<P>Consider the architecture while performing this task.  All design work must be done while regarding the architecture within which the design exists.  Furthermore, certain design elements will be deemed architecturally significant; those elements will require updates to the architecture. </P>
	<P>This task will be applied numerous times.  Design is best performed in small chunks.</P>
	<P>Even when starting the design for a particular project it is expected that there will be existing frameworks and reusable elements.  Every step of this task must give attention to the existing design and existing implementation, utilizing existing elements when possible and emulating or improving existing elements as appropriate while designing this portion of the solution. </P>
	<P>Apply patterns throughout this task.  Patterns represent proven designs and their usage promotes quality and consistency across the design. </P><!-- END:keyConsiderations,_NrC20qeqEdmKDbQuyzCoqQ -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: purpose<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:purpose,_NrC20qeqEdmKDbQuyzCoqQ CRC: 4034027761 --><p>
	The purpose of this task is to describe the elements of the system so that they support the
	required behavior, are of high quality, and fit within the architecture.
	</p><!-- END:purpose,_NrC20qeqEdmKDbQuyzCoqQ -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_4Z7WYKuKEdmhFZtkg1nakg CRC: 3539482445 -->Understand requirement details<!-- END:name,_4Z7WYKuKEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_4Z7WYKuKEdmhFZtkg1nakg CRC: 1012897478 --><p>
	Examine the relevant <a class="elementLink" href="./../../openup_basic/workproducts/use_case,_0VGbUMlgEdmt3adZL5Dmdw.html" guid="_0VGbUMlgEdmt3adZL5Dmdw">Use Case</a>(s) and <a class="elementLink" href="./../../openup_basic/workproducts/supporting_requirements,_BVh9cL-CEdqb7N6KIeDL8Q.html" guid="_BVh9cL-CEdqb7N6KIeDL8Q">Supporting Requirements</a> to understand the scope of the design task and the
	expectations on the <a class="elementLink" href="./../../openup_basic/workproducts/design,_0WuL8slgEdmt3adZL5Dmdw.html" guid="_0WuL8slgEdmt3adZL5Dmdw">Design</a>. Work with the Stakeholder and Analyst to clarify ambiguous or missing
	information.
	</p>
	<p>
	If the requirements are not represented in some sort of scenario form (for example a non-functional requirement might
	not have a scenario associated with it), a scenario will have to be identified that appropriately exercises the
	requirements under consideration.
	</p>
	<p>
	If the requirements are determined to be incomplete or incorrect, work with the analyst to get the
	requirements improved and possibly submit a change request against the requirements.
	</p><!-- END:sectionDescription,_4Z7WYKuKEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_Ci7aYFixEdusJoWkvSRO9Q CRC: 1313874932 -->Understand the architecture<!-- END:name,_Ci7aYFixEdusJoWkvSRO9Q -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_Ci7aYFixEdusJoWkvSRO9Q CRC: 3306830448 --><p>
	Understand how the architecture applies to this part of the design, and how this design work fits with the rest of the
	system. Incorporate any applicable interfaces, key abstractions, mechanisms and patterns into the design work. Discuss
	possible refinements to the architecture and new areas of potential re-use with the architect.
	</p><!-- END:sectionDescription,_Ci7aYFixEdusJoWkvSRO9Q -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_--6tYKuKEdmhFZtkg1nakg CRC: 3224594196 -->Identify design elements<!-- END:name,_--6tYKuKEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_--6tYKuKEdmhFZtkg1nakg CRC: 2341138125 --><p>
	Identify the elements that collaborate together to provide the required behavior.  This can start with the key
	abstractions identified in the architecture, domain analysis, and classical analysis of the requirements (noun
	filtering) to derive the elements that would be required to fulfill them.
	</p>
	<p>
	Identify elements in all perspectives being considered when performing this task.  This could include identifying
	user interface elements, control elements, data elements, and elements relating to interfacing to other
	systems or devices.
	</p>
	<p>
	Existing elements of the design should be examined to see if they should participate in the collaboration.  It is
	a mistake to create all new elements in each execution of this task.
	</p>
	<p>
	This list of candidates must be expanded to include special-purpose participants that handle particular roles in
	providing the required behavior such as transaction processing or adherence to some security specification.  The
	<a class="elementLink" href="./../../openup_basic/guidances/concepts/entity_control_boundary_pattern,_uF-QYEAhEdq_UJTvM1DM2Q.html" guid="_uF-QYEAhEdq_UJTvM1DM2Q">Entity-Control-Boundary Pattern</a> provides a good start for identifying elements.
	</p><!-- END:sectionDescription,_--6tYKuKEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_A_LU8KuLEdmhFZtkg1nakg CRC: 2844361739 -->Determine how elements collaborate to realize the scenario<!-- END:name,_A_LU8KuLEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_A_LU8KuLEdmhFZtkg1nakg CRC: 2669209812 -->Walk through the scenario distributing responsibilities to the participating elements. These responsibilities can be simple
	statements of behavior assigned to elements; they need not be detailed operation specifications with parameters, etc. This
	step is about ensuring that a quality model is being created that is robust enough to support the requirements.
	<p>
	Identify the required relationships between the elements based on the walkthrough of the scenario examining how
	the elements initiate each other's behavior. An element that requests behavior from another element is represented as a
	relationship between those elements. As with the responsibilities, these relationships can just be defined at this
	step.
	</p>
	<p>
	Look to the architecture and previous design work to create a consistent collaboration. Use the Architect to explain
	the details and motivations of the architecture. Look to reuse existing behavior and relations or to apply similar
	structure to simplify the design of the overall system.
	</p>
	<p>
	Additional elements might be identified as behavior is found that cannot appropriately be assigned to any of the
	existing elements.
	</p><!-- END:sectionDescription,_A_LU8KuLEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_ENwJwKuLEdmhFZtkg1nakg CRC: 352956516 -->Refine design decisions<!-- END:name,_ENwJwKuLEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_ENwJwKuLEdmhFZtkg1nakg CRC: 2451428892 --><p>
	Refine the design to an appropriate level of detail to drive implementation and to ensure that it fits into the
	architecture.  In this step the design can take into consideration the actual implementation language and other
	technical decisions.  Revisit the identification of the elements and the collaborations that realize the
	scenarios if necessary as this refinement takes into consideration details at a lower level of abstraction. Discuss
	testability issues, such as design elements that are difficult to test or critical performance areas, with
	the Tester and Architect.
	</p>
	<p>
	In particular make decisions in regard to the considerations below:
	</p>
	<ul>
	<li>
	Specific details of relationships between the elements such as multiplicity and navigability
	</li>
	<li>
	Operation detail such as parameters and return values
	</li>
	<li>
	Existence and detail of data attributes necessary
	</li>
	<li>
	Usage of inheritance and interfaces to improve the design
	</li>
	</ul>
	<p>
	Incorporate <a class="elementLink" href="./../../openup_basic/guidances/concepts/design_mechanism,_w2ACwA4LEduibvKwrGxWxA.html" guid="_w2ACwA4LEduibvKwrGxWxA">Design Mechanism</a>s from the architecture. Apply consistent structure of the elements
	and organization of the behavior as in other areas of the design and use patterns identified in the architecture.
	</p><!-- END:sectionDescription,_ENwJwKuLEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_KNZYAKuLEdmhFZtkg1nakg CRC: 419770836 -->Design internals (for large or complex elements)<!-- END:name,_KNZYAKuLEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_KNZYAKuLEdmhFZtkg1nakg CRC: 405028966 --><p>
	Design large or complex elements or some complex internal behavior in more detail.
	</p>
	<p>
	This might just involve devising an algorithm that could be performed to produce the desired behavior. Add
	additional operations, attributes, and relationships to support the expectations of an element. Discuss testability
	issues, such as design elements that are difficult to test or critical performance areas, with the Tester and
	Architect.
	</p>
	<p>
	The state of the element managed over the course of its lifetime can be designed to ensure proper behavior in
	various usages.
	</p><!-- END:sectionDescription,_KNZYAKuLEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_9LeFME42EdudDeUNeAxPCQ CRC: 3123982209 -->Design the database schema<!-- END:name,_9LeFME42EdudDeUNeAxPCQ -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_9LeFME42EdudDeUNeAxPCQ CRC: 2352077700 --><p>
	If the system has persistent data, the design will need to address the database (or file) schema.  For a
	relational database schema, identify the following:
	</p>
	<ul>
	<li>
	The structure of tables and views
	</li>
	<li>
	Relationships between tables
	</li>
	<li>
	Triggers which enforce referential integrity
	</li>
	<li>
	Constraints on columns
	</li>
	<li>
	Default values for columns
	</li>
	<li>
	Stored procedures and functions
	</li>
	</ul><!-- END:sectionDescription,_9LeFME42EdudDeUNeAxPCQ -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_mUVt8BfnEduD353bkQ4frw CRC: 1605738521 -->Evaluate the design<!-- END:name,_mUVt8BfnEduD353bkQ4frw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_mUVt8BfnEduD353bkQ4frw CRC: 1610019147 --><p>
	Evaluate the object design for coupling, cohesion, and other quality design measurements.
	</p>
	<p>
	Evaluate the database/file design for performance, referential integrity, and normalization.
	</p>
	<p>
	Consider the design from various angles to ensure that it is a high-quality, communicable design.  Work with other
	technical team members; an independent party can provide a fresh perspective. Use the Tester and Architect to
	provide perspectives on design quality and adherence to the architecture. However, when identifying potential
	reviewers keep in mind that if someone can add value by reviewing the design, then perhaps they could have added even
	more value by actively participating in the design effort itself.
	</p>
	<p>
	If design flaws are identified, improve the design.
	</p><!-- END:sectionDescription,_mUVt8BfnEduD353bkQ4frw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: name<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:name,_OGYbwKuLEdmhFZtkg1nakg CRC: 1999328299 -->Communicate the design<!-- END:name,_OGYbwKuLEdmhFZtkg1nakg -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: sectionDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:sectionDescription,_OGYbwKuLEdmhFZtkg1nakg CRC: 3988272218 --><p>
	Communicate the design to those who need to understand it. Though this is described here toward the end of
	the task, communication should be going on throughout the steps. Working collaboratively is always better than
	reviewing the work after it is complete.
	</p>
	<p>
	Here are some ways to communicate the design:
	</p>
	<ul>
	<li>
	Formal models specified in UML .
	</li>
	<li>
	Informal diagrams that render static structure and capture dynamic behavior.
	</li>
	<li>
	Annotated code that communicates information about the static structure supplemented with textual descriptions of
	dynamic behavior across code modules .
	</li>
	<li>
	Physical data models to describe the database schema.
	</li>
	</ul>
	<p>
	Here are some examples of individuals who will need to understand the design:
	</p>
	<ul>
	<li>
	Developers who will implement a solution based on the design.
	</li>
	<li>
	An architect who can review the design to ensure that it conforms to the architecture or who might examine the
	design for opportunities to improve the architecture.
	</li>
	<li>
	Other designers who can examine the design for applicability to other parts of the system.
	</li>
	<li>
	Developers or other designers who will be working on other parts of the system that will depend on the
	elements designed in this task.
	</li>
	<li>
	Other reviewers who will review the design for quality and adherence to standards.
	</li>
	</ul><!-- END:sectionDescription,_OGYbwKuLEdmhFZtkg1nakg -->
	</body>
	</html>