<?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" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="_TZiasMM1EdmSIPI87WLu3g" name="component,_0YP18MlgEdmt3adZL5Dmdw" guid="_TZiasMM1EdmSIPI87WLu3g" changeDate="2008-02-16T11:28:21.000-0800" version="1.0.0">
  <mainDescription>&lt;p align=&quot;left&quot;>&#xD;
    The software industry and literature use the term &lt;strong>componen&lt;/strong>t to refer to many different things. It is&#xD;
    often used in the broad sense to mean a constituent part. It is also frequently used in a narrow sense to denote&#xD;
    specific characteristics that enable replacement and assembly in larger systems.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    The Unified Modeling Language [&lt;a class=&quot;elementLinkWithUserText&quot;&#xD;
    href=&quot;./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html&quot;&#xD;
    guid=&quot;_9ToeIB83Edqsvps02rpOOg&quot;>UML05&lt;/a>] defines &lt;em>component&lt;/em> as follows:&#xD;
&lt;/p>&#xD;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
    &lt;blockquote>&#xD;
        &lt;p>&#xD;
            A modular part of a system that encapsulates its contents and whose manifestation is replaceable within its&#xD;
            environment. A component defines its behavior in terms of provided and required interfaces. As such, a&#xD;
            component serves as a type, whose conformance is defined by these provided and required interfaces&#xD;
            (encompassing both their static as well as dynamic semantics).&#xD;
        &lt;/p>&#xD;
        &lt;p>&#xD;
            A &lt;em>component&lt;/em> is defined as a subtype of structured class. Therefore, a component has attributes and&#xD;
            operations, is able to participate in associations and generalizations, and has internal structure and ports.&#xD;
        &lt;/p>&#xD;
    &lt;/blockquote>&#xD;
&lt;/blockquote>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    Here, we use&amp;nbsp;the term &lt;em>component&amp;nbsp;&lt;/em>in a&amp;nbsp;broader way than the UML definition. Rather than defining&#xD;
    components as having characteristics, such as modularity, deployability, and replaceability, we instead recommend these&#xD;
    as desirable characteristics of components. We use &lt;em>component&lt;/em> to mean &lt;strong>an encapsulated part of a&#xD;
    system&lt;/strong> that is nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function&#xD;
    in the context of well-defined architecture. This includes two types of components:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;div align=&quot;left&quot;>&#xD;
            &lt;p>&#xD;
                &lt;strong>Design component.&lt;/strong> A significant encapsulated part of the design that includes design&#xD;
                subsystems and, sometimes, significant design classes and design packages.&#xD;
            &lt;/p>&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;div align=&quot;left&quot;>&#xD;
            &lt;p>&#xD;
                &lt;strong>Implementation component.&lt;/strong> A significant encapsulated part of the implementation, generally&#xD;
                code that implements a design component.&#xD;
            &lt;/p>&#xD;
        &lt;/div>&#xD;
    &lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    Ideally, the design reflects the implementation; therefore, you can simply refer to &lt;em>components&lt;/em>, with each&#xD;
    component having a design and an implementation.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    Components interact through interfaces&amp;nbsp;and&amp;nbsp;may be composed of successively smaller components and interfaces.&#xD;
&lt;/p>&#xD;
&lt;h3 align=&quot;left&quot;>&#xD;
    Component replaceability&#xD;
&lt;/h3>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    In UML terminology, components should be replaceable. However, this may mean only that the component exposes a set of&#xD;
    interfaces that hide an underlying implementation.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    There are other, stronger, kinds of replaceability: .&#xD;
&lt;/p>&#xD;
&lt;div align=&quot;left&quot;>&#xD;
    &lt;ul>&#xD;
        &lt;li>&#xD;
            &lt;p>&#xD;
                &lt;strong>Source file replaceability:&lt;/strong> If two classes are implemented in a single source code file,&#xD;
                then those classes cannot usually be separately versioned and controlled. However, if a set of files fully&#xD;
                implements a single component (and no other component), then the component source files are replaceable.&#xD;
                This characteristic makes it easier to use version control, to use the file as a baseline, and to reuse the&#xD;
                source file.&#xD;
            &lt;/p>&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            &lt;p>&#xD;
                &lt;strong>Deployment replaceability:&lt;/strong> If two classes are deployed in a single executable file, then&#xD;
                each class is not independently replaceable in a deployed system. It is desirable for larger-granularity&#xD;
                components to be replaceable during deployment, which allows new versions of the component to be deployed&#xD;
                without having to rebuild the other components. This usually means that there is one file or one set of&#xD;
                files that deploy the component, and no other component.&#xD;
            &lt;/p>&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            &lt;p>&#xD;
                &lt;strong>Run-time replaceability:&lt;/strong> If a component can be redeployed into a running system, then it&#xD;
                is referred to as &lt;em>run-time replaceable&lt;/em>. This enables you to upgrade software without loss of&#xD;
                availability.&#xD;
            &lt;/p>&#xD;
        &lt;/li>&#xD;
        &lt;li>&#xD;
            &lt;p>&#xD;
                &lt;strong>Location transparency:&lt;/strong> Components with network-addressable interfaces are referred to as&#xD;
                having &lt;em>location transparency&lt;/em>. This allows components to be relocated to other servers or to be&#xD;
                replicated on multiple servers to support fault tolerance, load balancing, and so on. These kinds of&#xD;
                components are often referred to as &lt;em>distributed&lt;/em> or &lt;em>distributable&lt;/em> components.&#xD;
            &lt;/p>&#xD;
        &lt;/li>&#xD;
    &lt;/ul>&#xD;
&lt;/div>&#xD;
&lt;h3 align=&quot;left&quot;>&#xD;
    Component instantiation&#xD;
&lt;/h3>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    A component may or may not be directly instantiated at run time.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    An indirectly instantiated component is implemented, or realized, by a set of classes, subcomponents, or parts. The&#xD;
    component itself does not appear in the implementation; it merely serves as a design that an implementation must&#xD;
    follow. The set of realizing classes, subcomponents, or parts must cover the entire set of operations specified in the&#xD;
    provided interface of the component. The manner of implementing the component is the responsibility of the implementer.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
    A directly instantiated component specifies its own encapsulated implementation. It is instantiated as an addressable&#xD;
    object, which means that a design component has a corresponding construct in the implementation language; therefore, it&#xD;
    can be referenced explicitly.&#xD;
&lt;/p></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
