<?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.5/uma.ecore"
    xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-birrHREBM5-lLipCStKeiQ"
    name="intro,_5BvBEOeOEd6qzY6d3-E2jw" guid="-birrHREBM5-lLipCStKeiQ" authors="John D. McGregor"
    changeDate="2010-01-07T07:03:13.140-0500">
  <mainDescription>&lt;br />&#xD;
&lt;br />&#xD;
&lt;center>&#xD;
    &lt;strong>&lt;font size=&quot;5&quot;>Software Architecture&lt;/font>&lt;/strong>&#xD;
&lt;/center>&#xD;
&lt;br />&#xD;
&lt;br />&#xD;
&lt;br />&#xD;
&lt;p>&#xD;
    &lt;font size=&quot;3&quot;>This is a course on defining the architecture for a software-intensive system. We will explore many&#xD;
    options but in general we will follow the architecture practice defined by the&lt;/font> &lt;a&#xD;
    href=&quot;http://www.sei.cmu.edu/architecture/&quot; target=&quot;_blank&quot;>&lt;font size=&quot;3&quot;>Software Engineering Institute's&#xD;
    architecture initiative.&lt;/font>&lt;/a> &lt;font size=&quot;3&quot;>We will examine the techniques for documenting the architecture,&#xD;
    such as&lt;/font> &lt;a href=&quot;http://standards.ieee.org/reading/ieee/std_public/description/se/1471-2000_desc.html&quot;&#xD;
    target=&quot;_blank&quot;>&lt;font size=&quot;3&quot;>IEEE 1471&lt;/font>&lt;/a>&lt;font size=&quot;3&quot;>,&amp;nbsp;after it is designed. This course is also&#xD;
    about the architects who create the architecture. We will explore efforts to&lt;/font> &lt;a class=&quot;elementLink&quot;&#xD;
    href=&quot;./../../../Architecture/guidances/supportingmaterials/architecture_competence_9B00A294.html&quot;&#xD;
    guid=&quot;_NdJ8cObLEd6qzY6d3-E2jw&quot;>Architecture Competence&lt;/a>&lt;font size=&quot;3&quot;>&amp;nbsp;of the personnel on the architecture&#xD;
    team.&lt;/font>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;br />&#xD;
    &lt;font size=&quot;3&quot;>The definition for software architecture from the SEI is:&lt;/font>&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;font size=&quot;4&quot;>The software architecture of a program or computing system is the structure or structures of the system,&#xD;
    which comprise software components, the externally visible properties of those components, and the relationships among&#xD;
    them.&lt;/font>&#xD;
&lt;/p>&#xD;
&lt;br />&#xD;
&lt;p>&#xD;
    The SEI's web site has a page where people contribute their own &lt;a&#xD;
    href=&quot;http://www.sei.cmu.edu/architecture/start/community.cfm&quot; target=&quot;_blank&quot;>definition of software architecture&lt;/a>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    A stakeholder is anyone with an interest in the system. Stakeholders will be involved&amp;nbsp;in various aspects&#xD;
    of&amp;nbsp;the design process.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The stakeholders include:&#xD;
&lt;/p>&#xD;
&lt;div style=&quot;MARGIN-LEFT: 2em&quot;>&#xD;
    &lt;p>&#xD;
        &lt;font size=&quot;3&quot;>&lt;b>developers&lt;/b>&lt;/font>&#xD;
    &lt;/p>&#xD;
    &lt;p>&#xD;
        &lt;font size=&quot;3&quot;>&lt;b>testers&lt;/b>&lt;/font>&#xD;
    &lt;/p>&#xD;
    &lt;p>&#xD;
        &lt;font size=&quot;3&quot;>&lt;b>maintainers&lt;/b>&lt;/font>&#xD;
    &lt;/p>&#xD;
    &lt;p>&#xD;
        &lt;font size=&quot;3&quot;>&lt;b>system administrator&lt;/b>&lt;/font>&#xD;
    &lt;/p>&#xD;
    &lt;p>&#xD;
        &lt;font size=&quot;3&quot;>&lt;b>customer&lt;/b>&lt;/font>&#xD;
    &lt;/p>&#xD;
    &lt;p>&#xD;
        &lt;font size=&quot;3&quot;>&lt;b>end-users&lt;/b>&lt;/font>&#xD;
    &lt;/p>&#xD;
    &lt;p>&#xD;
        &lt;b>&lt;font size=&quot;3&quot;>architect&lt;/font>&lt;/b>&#xD;
    &lt;/p>&#xD;
&lt;/div>&#xD;
&lt;p>&#xD;
    Each stakeholder provides a unique perspective on the system and hence the architecture. In order to understand the&#xD;
    architecting process we need to understand their perspectives.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The architecture is based on product requirements. Functional requirements are about those things that the product must&#xD;
    be able to do. Non-functional requirements are about how the product does what it does. The non-functional requirements&#xD;
    are the most important in terms of forming the architecture. Non-functional attributes are similar to what the SEI&#xD;
    terms a &lt;a class=&quot;elementLink&quot; href=&quot;./../../../Architecture/guidances/termdefinitions/quality_attribute_673FA54C.html&quot;&#xD;
    guid=&quot;_OiHJ8LGCEdyXjdEkMCWxuA&quot;>Quality attribute&lt;/a>.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    This is the simplest architecture possible. If we don't care about anything other than &quot;what the product can do&quot; then&#xD;
    this architetcure is acceptable. However, we usually want more than one person to work on building the system at the&#xD;
    same time. We want part of the product to run on one processor and another part on another processor. We want the data&#xD;
    manipulated by the product to be safe. That leads to much more complex architectures.&#xD;
&lt;/p>&#xD;
&lt;br />&#xD;
&lt;p>&#xD;
    &lt;img alt=&quot;&quot; src=&quot;resources/square.png&quot; width=&quot;519&quot; height=&quot;331&quot; />&lt;br />&#xD;
&lt;/p>&#xD;
&lt;br /></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
