| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:TaskDescription 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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="_qDRSULBKEdm7Eph_l9Cn9w" |
| name="outline_the_arch,_0f-1oMlgEdmt3adZL5Dmdw" guid="_qDRSULBKEdm7Eph_l9Cn9w" |
| changeDate="2008-08-08T11:26:46.696-0700" version="1.0.0"> |
| <mainDescription><p>
 |
| This task focuses on outlining the initial architectural decisions that will guide development and testing. It relies
 |
| on gathering experience gained in similar systems or problem domains to constrain and focus the architecture so that
 |
| effort is not wasted in re-inventing architecture.
 |
| </p>
 |
| <p>
 |
| The results are captured for future reference and are communicated across the team. It is important that the team has
 |
| enough information to understand the technical approach being taken.
 |
| </p>
 |
| <p>
 |
| The architecture evolves organically over time by outlining and refining portions of it. A few people get together in a
 |
| room and sketch out what they think the architecture will be. This envisioning effort sets the foundation for
 |
| prototyping. If the solution is similar to a previously produced solution (or is a well-known solution domain), then it
 |
| will probably be good enough to reference that example as evidence of the feasibility of the approach. In some cases,
 |
| it may be necessary to develop one or more prototypes to validate some of the decisions or clarify some of the
 |
| requirements.
 |
| </p>
 |
| <p>
 |
| The work done here does not seek to produce a detailed and comprehensive technical specification for the system.
 |
| Rather, the approach should be to decide the overall technical approach at a high level. The conclusion of this work
 |
| should produce just enough information to communicate the architecture to the team, and to demonstrate its viability to
 |
| the customer. This allows the project to move forward, enabling you to refine and baseline the architecture.
 |
| </p></mainDescription> |
| <keyConsiderations><p>
 |
| It&nbsp;is important to reduce the complexity of the&nbsp;solution by raising the levels of abstraction.&nbsp; For more
 |
| information, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/guidelines/abstract_away_complexity_DBF13AE6.html" guid="_we3F4ACpEdu8m4dIntu6jA">Guideline: Abstract Away Complexity</a>.
 |
| </p>
 |
| <p>
 |
| It is critical that this task be performed collaboratively with active involvement of other team members and project
 |
| stakeholders so that consensus and common understanding is reached. It is particularly vital to involve the
 |
| developer(s) throughout this task. The architecture effort&nbsp;is about providing leadership and coordination of the
 |
| technical work rather than putting in a solo performance.
 |
| </p></keyConsiderations> |
| <sections xmi:id="_3nMQQA3rEduibvKwrGxWxA" name="Identify architectural goals" guid="_3nMQQA3rEduibvKwrGxWxA"> |
| <sectionDescription><p>
 |
| Work with the team to describe the remaining goals for the architecture and identify which ones are appropriate to
 |
| address for this iteration.&nbsp;Look at&nbsp;the requirements and speak to the people asking for them to
 |
| make&nbsp;sure that the&nbsp;critical goals for this iteration are well understood. These goals will prioritize and
 |
| guide the approach to important technical decisions.<br />
 |
| </p>
 |
| <p>
 |
| It's important to regularly review the status of these goals throughout the project to make sure that they are still
 |
| valid and that the system is on track to deliver them.
 |
| </p>
 |
| <p>
 |
| For more information, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/concepts/arch_goals_CB41D8AE.html" guid="_HlRqANpbEdyP58ppo1Ieaw">Concept: Architectural Goals</a>.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_f0y2kM25Edym_ZFqrJcXUg" name="Identify architecturally significant requirements" |
| guid="_f0y2kM25Edym_ZFqrJcXUg"> |
| <sectionDescription><p>
 |
| Identify which of the current requirements are architecturally significant.&nbsp;Explore and refine those that must be
 |
| implemented in order to realize the architectural goals for the current iteration. See <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/concepts/arch_significant_requirements_1EE5D757.html" guid="_HrZGIA4MEduibvKwrGxWxA">Concept: Architecturally Significant Requirements</a>&nbsp;for more information.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_9o6Z4CSCEdqDjNgZyGMf5w" name="Identify constraints on the architecture" |
| guid="_9o6Z4CSCEdqDjNgZyGMf5w"> |
| <sectionDescription><p>
 |
| List any constraints on the architecture and any trade-offs between competing requirements and resources. Decide how
 |
| the architecture will meet these issues. Justify each of the decisions made and capture this information. Regularly
 |
| review the list of constraints to make sure that they are still valid and that no new ones have appeared.<br />
 |
| </p>
 |
| <p>
 |
| For more information, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/concepts/arch_constraints_AE56B662.html" guid="_jdKSsNpiEdyP58ppo1Ieaw">Concept: Architectural Constraints</a>.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_I32E4MP2EdmWKcx6ixEiwg" name="Identify key abstractions" guid="_I32E4MP2EdmWKcx6ixEiwg"> |
| <sectionDescription><p>
 |
| Identify the key concepts and abstractions that the system needs to handle. The requirements are good sources for key
 |
| abstractions.&nbsp; Don't spend too much time describing&nbsp;abstractions in detail at this initial stage, because
 |
| there is a risk that spending too much time will result in identifying classes and relationships that the solution does
 |
| not actually need.
 |
| </p>
 |
| <p>
 |
| When&nbsp;identifying&nbsp;key abstractions, it can be useful to also define any obvious relationships that exist
 |
| between them.&nbsp;These can be captured in a table or&nbsp;in diagrams (in a tool or whiteboard.&nbsp;In general, it
 |
| is not worth agonizing over defining a highly detailed set of relationships at this early stage in design. The
 |
| relationships will become more concrete and detailed later and will&nbsp;probably modify&nbsp;these
 |
| early&nbsp;assumptions.&nbsp;
 |
| </p>
 |
| <p>
 |
| For more information, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/concepts/key_abstractions_1474DBF2.html" guid="_pLEGUNqGEdy88NBoQgfGyg">Concept: Key Abstractions</a>.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_B899cMP2EdmWKcx6ixEiwg" name="Identify reuse opportunities" guid="_B899cMP2EdmWKcx6ixEiwg"> |
| <sectionDescription><p>
 |
| Survey, assess, and select available assets.&nbsp; Identify assets from other areas that may be reused in the current
 |
| architecture. For more information, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/guidelines/software_reuse_B6B04C26.html" guid="_vO2uoO0OEduUpsu85bVhiQ">Guideline: Software Reuse</a>.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_FVrlsMP2EdmWKcx6ixEiwg" name="Define approach for partitioning the system" |
| guid="_FVrlsMP2EdmWKcx6ixEiwg"> |
| <sectionDescription><p>
 |
| Decide how to partition the software, both in logical and physical terms. Partitioning your system helps you manage its
 |
| complexity by using the well-known "divide and conquer" strategy. By breaking the process into smaller and more
 |
| manageable pieces, you make development easier.
 |
| </p>
 |
| <p>
 |
| As a minimum, decide on:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| How to partition the software when managing development (the use of layering as a partitioning strategy, for
 |
| example).&nbsp; For more information, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/guidelines/layering_F169CF07.html" guid="_0gpkAMlgEdmt3adZL5Dmdw">Guideline: Layering</a>.
 |
| </li>
 |
| <li>
 |
| How the software will be composed at run time.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| For each software partition, briefly describe
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Its name and purpose.
 |
| </li>
 |
| <li>
 |
| Its relationships to other partitions.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| At this point, you do not need to identify the elements that should be placed in each of these partitions.&nbsp;
 |
| Instead, you define how many partitions you will need and how they should be related. Later, during&nbsp;design
 |
| activities, you decide which elements will populate these partitions.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_tmvWwE5cEducxZ_XZXh-vw" name="Define approach for deploying the system" |
| guid="_tmvWwE5cEducxZ_XZXh-vw"> |
| <sectionDescription><p>
 |
| Outline how the software will deploy over the nodes on the network. Work with stakeholders such as network support and
 |
| deployment teams to ensure that the proposed approach is a good fit for the wider technical environment.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_KBAsYMP2EdmWKcx6ixEiwg" name="Identify architectural mechanisms" |
| guid="_KBAsYMP2EdmWKcx6ixEiwg"> |
| <sectionDescription><p>
 |
| Make a list of the&nbsp;technical services that the system needs to provide and capture some basic information about
 |
| each item on the list. It's generally a good idea to make an initial&nbsp;list of all the mechanisms required for the
 |
| project and then prioritize the development of those that need to be&nbsp;delivered to achieve the architectural goals.
 |
| </p>
 |
| <p>
 |
| At this point, usually only the analysis mechanisms are defined.&nbsp; However, specific <a class="elementLink" href="./../../core.tech.common.extend_supp/guidances/concepts/arch_constraints_AE56B662.html" guid="_jdKSsNpiEdyP58ppo1Ieaw">Architectural Constraints</a>&nbsp;may mean that some of those mechanisms can be
 |
| described as design mechanisms (even at this early stage).
 |
| </p>
 |
| <p>
 |
| For more information on architectural mechanisms, see <a class="elementLinkWithType" href="./../../core.tech.common.extend_supp/guidances/concepts/arch_mechanism_2932DFB6.html" guid="_mzxI0A4LEduibvKwrGxWxA">Concept: Architectural Mechanisms</a>.&nbsp;
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_RKSLsNp3EdyItewP9R0w7Q" name="Identify interfaces to external systems" |
| guid="_RKSLsNp3EdyItewP9R0w7Q"> |
| <sectionDescription><p>
 |
| At this point, identify the external systems with which this system must interact.&nbsp; An external system may be
 |
| anything from software to hardware units that the current system will use, such as printers, terminals, alarm devices,
 |
| and sensors.
 |
| </p>
 |
| <p>
 |
| Describe those interfaces at a high level, concentrating on the information that must pass between the systems.
 |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_Q2PRIFHSEd2zrOgIte8oWg" name="Verify architectural consistency" |
| guid="_Q2PRIFHSEd2zrOgIte8oWg"> |
| <sectionDescription>Work with the team&nbsp;to verify that the architecture is consistent with the requirements and that the descriptions of
 |
| the architecture are complete, meaningful, and clear.</sectionDescription> |
| </sections> |
| <sections xmi:id="_Xia1QFHSEd2zrOgIte8oWg" name="Capture and communicate architectural decisions " |
| guid="_Xia1QFHSEd2zrOgIte8oWg"> |
| <sectionDescription>Capture important decisions about the architecture in the <a class="elementLink" href="./../../practice.tech.evolutionary_arch.base/workproducts/architecture_notebook_9BB92433.html" guid="_0XAf0MlgEdmt3adZL5Dmdw">Architecture Notebook</a>&nbsp;for future reference. Make sure that&nbsp;the team
 |
| understands the architecture&nbsp;and can deliver it.</sectionDescription> |
| </sections> |
| <purpose><p>
 |
| To outline a technical approach to the system that supports the project requirements, within the constraints placed on
 |
| the system and the development team.
 |
| </p>
 |
| <p>
 |
| To provide sufficient guidance and direction for the team to begin development.
 |
| </p></purpose> |
| <alternatives><p>
 |
| This task&nbsp;is most&nbsp;needed when developing new and unprecedented systems. In systems where there is already a
 |
| well-defined architecture, this task may be omitted and replaced with a&nbsp;review of the existing architecture.
 |
| </p></alternatives> |
| </org.eclipse.epf.uma:TaskDescription> |
