| <?xml version="1.0" encoding="UTF-8"?> |
| <xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1"> |
| <org.eclipse.epf.uma:ProcessDescription xmi:id="-VFp5B68iro5ga1pz4nbQFw" name="develop_architecture,_KaeNsdOFEdyqlogshP8l4g" guid="-VFp5B68iro5ga1pz4nbQFw" version="7.2.0"> |
| <mainDescription><p> |
| This activity refines the initial high-level architecture into working software. The objective is to produce stable |
| software that adequately addresses the technical risks in scope. |
| </p> |
| <p> |
| The architect and developers work together to: |
| </p> |
| <ul> |
| <li> |
| Refine the initial sketch of the architecture into concrete design elements |
| </li> |
| <li> |
| Ensure that the architecture decisions are adequately captured and communicated |
| </li> |
| <li> |
| Ensure that the team has enough information to enable software to be developed |
| </li> |
| <li> |
| Ensure that the requirements that were prioritized for the current iteration are adequately addressed in the |
| software |
| </li> |
| </ul> |
| <p> |
| In an iterative project, the team should not attempt to develop the architecture for the entire project in a single |
| pass. Rather, they should focus on meeting the requirements in scope for the current iteration, while making decisions |
| in the context of the wider project. |
| </p></mainDescription> |
| <howtoStaff><p> |
| These activities are best carried out as a collaborative effort by the team, with the architect acting as a focal point |
| for coordinating and facilitating the decisions. |
| </p></howtoStaff> |
| <usageNotes><p> |
| The work is best done in several sessions, perhaps performed over a few days. |
| </p></usageNotes> |
| </org.eclipse.epf.uma:ProcessDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-V51fxSq2AzJuVZF90kMOmA" name="architecture_notebook,_EjG_cNOKEdyqlogshP8l4g" guid="-V51fxSq2AzJuVZF90kMOmA"> |
| <refinedDescription><p>
 |
| This artifact&nbsp;describes the <a class="elementLink"
 |
| href="./../../core.tech.common.extend_supp/guidances/concepts/software_architecture_59A08DE0.html"
 |
| guid="__O7tAMVvEduLYZUGfgZrkQ">Software Architecture</a>.
 |
| </p>
 |
| <p>
 |
| It provides a place for maintaining the list of architectural issues, along with the associated architectural
 |
| decisions, designs, patterns, code documented (or pointed to), and so forth -- all at appropriate levels to make it
 |
| easy to understand what architectural decisions have been made and remain to be made.
 |
| </p>
 |
| <p>
 |
| It is helpful for architects to use this artifact to collaborate with other team members in developing the architecture
 |
| and to help team members understand the motivation behind architectural decisions so that those decisions can be
 |
| robustly implemented. For example, the architect may put constraints on how data is packaged and communicated between
 |
| different parts of the system. This may appear to be a burden, but the justification in the Architecture Notebook can
 |
| explain that there is a significant performance bottleneck when communicating with a legacy system. The rest of the
 |
| system must adapt to this bottleneck by following a specific data packaging scheme.
 |
| </p>
 |
| <p>
 |
| This artifact should also inform the team members how the system is partitioned or organized so that the team can adapt
 |
| to the needs of the system. It also gives a first glimpse of the system and its technical motivations to whoever must
 |
| maintain and change the architecture later.<br />
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| <org.eclipse.epf.uma:DescriptorDescription xmi:id="-j18JWuRaOWhpi32MRwfW7A" name="refine_the_arch,_6RuKMN_1EdyOsumnGvWsEg" guid="-j18JWuRaOWhpi32MRwfW7A"> |
| <keyConsiderations><p>
 |
| It is important to continue 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>
 |
| Continue the collaboration with the whole&nbsp;team on the refining of the architecture in order to promote consensus
 |
| and a common understanding of the overall solution. The architect should be working to coordinate and guide the
 |
| technical activities of the team rather than doing all the work alone.&nbsp;Place special emphasis&nbsp;on
 |
| involving&nbsp;the developer(s) throughout this task since it's the developed solution that will prove out the
 |
| architecture and may result in refinements to the architecture documentation.
 |
| </p>
 |
| <p>
 |
| Ensure that those who need to act upon the architectural work&nbsp;understand&nbsp;it and are able to work with
 |
| it.&nbsp;Make sure that the description of the architecture clearly conveys not only the solution but also the
 |
| motivation and objectives related to the&nbsp;decisions that have been made in shaping the architecture. This will make
 |
| it easier for others to understand the architecture and to adapt it over time.
 |
| </p>
 |
| <p>
 |
| You can communicate your decisions as many ways as you wish.&nbsp; For example:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Publication of&nbsp;reference source code
 |
| </li>
 |
| <li>
 |
| Publication of&nbsp;reference models
 |
| </li>
 |
| <li>
 |
| Publication of&nbsp;software architecture documentation
 |
| </li>
 |
| <li>
 |
| Formal&nbsp;presentations of the material
 |
| </li>
 |
| <li>
 |
| Informal walkthroughs of the architecture
 |
| </li>
 |
| </ul></keyConsiderations> |
| <refinedDescription><p>
 |
| This task&nbsp;builds upon the outlined architecture and makes concrete and unambiguous architectural decisions to
 |
| support development.&nbsp; It takes into&nbsp;account any design and implementation work products that have been
 |
| developed so far.&nbsp; In other words, the architecture evolves as the solution is designed and implemented, and the
 |
| architecture documentation is updated to reflect any changes made during development. This is&nbsp;a key,&nbsp;since
 |
| the actual implementation is the only real "proof" that the software architecture is viable and provides the definitive
 |
| basis for validating the suitability&nbsp;of the architecture.&nbsp; For more information, see <a
 |
| class="elementLinkWithType"
 |
| href="./../../core.tech.common.extend_supp/guidances/concepts/executable_arch_D4E68CBD.html"
 |
| guid="_O1kAANvfEduv2KOT-Teh6w">Concept: Executable Architecture</a>.
 |
| </p>
 |
| <p>
 |
| The results are captured for future reference and are communicated across the team.
 |
| </p></refinedDescription> |
| </org.eclipse.epf.uma:DescriptorDescription> |
| </xmi:XMI> |
