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