OpenUP/OpenUP_SP/library/openup_basic/guidances/concepts/component.xmi

<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="_TZiasMM1EdmSIPI87WLu3g" name="component,_0YP18MlgEdmt3adZL5Dmdw" guid="_TZiasMM1EdmSIPI87WLu3g" changeDate="2007-01-23T11:49:37.968+0000" version="1.0.0">
  <mainDescription>&lt;p align=&quot;left&quot;&gt;
    The software industry and literature use the term &lt;strong&gt;componen&lt;/strong&gt;t to refer to many different things. It is
    often used in the broad sense to mean a constituent part. It is also frequently used in a narrow sense to denote
    specific characteristics that enable replacement and assembly in larger systems.
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt;
    Here. we use &lt;em&gt;component&lt;/em&gt; to mean &lt;strong&gt;an encapsulated part of a system&lt;/strong&gt; that is, ideally, a
    nontrivial, nearly independent, and replaceable part of a system that fulfils a clear function in the context of
    well-defined architecture. This includes two types of components:
&lt;/p&gt;
&lt;ul&gt;
    &lt;li&gt;
        &lt;div align=&quot;left&quot;&gt;
            &lt;p&gt;
                &lt;strong&gt;Design component.&lt;/strong&gt; A significant encapsulated part of the design that includes design
                subsystems and, sometimes, significant design classes and design packages.
            &lt;/p&gt;
        &lt;/div&gt;
    &lt;/li&gt;
    &lt;li&gt;
        &lt;div align=&quot;left&quot;&gt;
            &lt;p&gt;
                &lt;strong&gt;Implementation component.&lt;/strong&gt; A significant encapsulated part of the implementation, generally
                code that implements a design component.
            &lt;/p&gt;
        &lt;/div&gt;
    &lt;/li&gt;
&lt;/ul&gt;
&lt;p align=&quot;left&quot;&gt;
    Ideally, the design reflects the implementation; therefore, you can simply refer to &lt;em&gt;components&lt;/em&gt;, with each
    component having a design and an implementation.
&lt;/p&gt;
&lt;h4 align=&quot;left&quot;&gt;
    Component replaceability
&lt;/h4&gt;
&lt;p align=&quot;left&quot;&gt;
    In UML terminology, components should be replaceable. However, this may mean only that the component exposes a set of
    interfaces that hide an underlying implementation.
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt;
    There are other, stronger, kinds of replaceability: .
&lt;/p&gt;
&lt;div align=&quot;left&quot;&gt;
    &lt;ul&gt;
        &lt;li&gt;
            &lt;p&gt;
                &lt;strong&gt;Source file replaceability:&lt;/strong&gt; If two classes are implemented in a single source code file,
                then those classes cannot usually be separately versioned and controlled. However, if a set of files fully
                implements a single component (and no other component), then the component source files are replaceable.
                This characteristic makes it easier to use version control, to use the file as a baseline, and to reuse the
                source file.
            &lt;/p&gt;
        &lt;/li&gt;
        &lt;li&gt;
            &lt;p&gt;
                &lt;strong&gt;Deployment replaceability:&lt;/strong&gt; If two classes are deployed in a single executable file, then
                each class is not independently replaceable in a deployed system. It is desirable for larger-granularity
                components to be replaceable during deployment, which allows new versions of the component to be deployed
                without having to rebuild the other components. This usually means that there is one file or one set of
                files that deploy the component, and no other component.
            &lt;/p&gt;
        &lt;/li&gt;
        &lt;li&gt;
            &lt;p&gt;
                &lt;strong&gt;Run-time replaceability:&lt;/strong&gt; If a component can be redeployed into a running system, then it
                is referred to as &lt;em&gt;run-time replaceable&lt;/em&gt;. This enables you to upgrade software without loss of
                availability.
            &lt;/p&gt;
        &lt;/li&gt;
        &lt;li&gt;
            &lt;p&gt;
                &lt;strong&gt;Location transparency:&lt;/strong&gt; Components with network-addressable interfaces are referred to as
                having &lt;em&gt;location transparency&lt;/em&gt;. This allows components to be relocated to other servers or to be
                replicated on multiple servers to support fault tolerance, load balancing, and so on. These kinds of
                components are often referred to as &lt;em&gt;distributed&lt;/em&gt; or &lt;em&gt;distributable&lt;/em&gt; components.
            &lt;/p&gt;
        &lt;/li&gt;
    &lt;/ul&gt;
&lt;/div&gt;
&lt;h4 align=&quot;left&quot;&gt;
    Component instantiation
&lt;/h4&gt;
&lt;p align=&quot;left&quot;&gt;
    A component may or may not be directly instantiated at run time.
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt;
    An indirectly instantiated component is implemented, or realized, by a set of classes, subcomponents, or parts. The
    component itself does not appear in the implementation; it merely serves as a design that an implementation must
    follow. The set of realizing classes, subcomponents, or parts must cover the entire set of operations specified in the
    provided interface of the component. The manner of implementing the component is the responsibility of the implementer.
&lt;/p&gt;
&lt;p align=&quot;left&quot;&gt;
    A directly instantiated component specifies its own encapsulated implementation. It is instantiated as an addressable
    object, which means that a design component has a corresponding construct in the implementation language; therefore, it
    can be referenced explicitly.
&lt;/p&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>