| <?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="_TZiasMM1EdmSIPI87WLu3g" |
| name="component,_0YP18MlgEdmt3adZL5Dmdw" guid="_TZiasMM1EdmSIPI87WLu3g" changeDate="2008-02-16T11:28:21.109-0800" |
| version="1.0.0"> |
| <mainDescription><p align="left">
 |
| The software industry and literature use the term <strong>componen</strong>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.
 |
| </p>
 |
| <p align="left">
 |
| The Unified Modeling Language [<a class="elementLinkWithUserText" href="./../../../core.tech.common.base/guidances/supportingmaterials/references.tech_6CCF393.html" guid="_9ToeIB83Edqsvps02rpOOg">UML05</a>] defines <em>component</em> as follows:
 |
| </p>
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <blockquote>
 |
| <p>
 |
| A modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
 |
| environment. A component defines its behavior in terms of provided and required interfaces. As such, a
 |
| component serves as a type, whose conformance is defined by these provided and required interfaces
 |
| (encompassing both their static as well as dynamic semantics).
 |
| </p>
 |
| <p>
 |
| A <em>component</em> is defined as a subtype of structured class. Therefore, a component has attributes and
 |
| operations, is able to participate in associations and generalizations, and has internal structure and ports.
 |
| </p>
 |
| </blockquote>
 |
| </blockquote>
 |
| <p align="left">
 |
| Here, we use&nbsp;the term <em>component&nbsp;</em>in a&nbsp;broader way than the UML definition. Rather than defining
 |
| components as having characteristics, such as modularity, deployability, and replaceability, we instead recommend these
 |
| as desirable characteristics of components. We use <em>component</em> to mean <strong>an encapsulated part of a
 |
| system</strong> that is 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:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <div align="left">
 |
| <p>
 |
| <strong>Design component.</strong> A significant encapsulated part of the design that includes design
 |
| subsystems and, sometimes, significant design classes and design packages.
 |
| </p>
 |
| </div>
 |
| </li>
 |
| <li>
 |
| <div align="left">
 |
| <p>
 |
| <strong>Implementation component.</strong> A significant encapsulated part of the implementation, generally
 |
| code that implements a design component.
 |
| </p>
 |
| </div>
 |
| </li>
 |
| </ul>
 |
| <p align="left">
 |
| Ideally, the design reflects the implementation; therefore, you can simply refer to <em>components</em>, with each
 |
| component having a design and an implementation.
 |
| </p>
 |
| <p align="left">
 |
| Components interact through interfaces&nbsp;and&nbsp;may be composed of successively smaller components and interfaces.
 |
| </p>
 |
| <h3 align="left">
 |
| Component replaceability
 |
| </h3>
 |
| <p align="left">
 |
| 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.
 |
| </p>
 |
| <p align="left">
 |
| There are other, stronger, kinds of replaceability: .
 |
| </p>
 |
| <div align="left">
 |
| <ul>
 |
| <li>
 |
| <p>
 |
| <strong>Source file replaceability:</strong> 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.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Deployment replaceability:</strong> 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.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Run-time replaceability:</strong> If a component can be redeployed into a running system, then it
 |
| is referred to as <em>run-time replaceable</em>. This enables you to upgrade software without loss of
 |
| availability.
 |
| </p>
 |
| </li>
 |
| <li>
 |
| <p>
 |
| <strong>Location transparency:</strong> Components with network-addressable interfaces are referred to as
 |
| having <em>location transparency</em>. 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 <em>distributed</em> or <em>distributable</em> components.
 |
| </p>
 |
| </li>
 |
| </ul>
 |
| </div>
 |
| <h3 align="left">
 |
| Component instantiation
 |
| </h3>
 |
| <p align="left">
 |
| A component may or may not be directly instantiated at run time.
 |
| </p>
 |
| <p align="left">
 |
| 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.
 |
| </p>
 |
| <p align="left">
 |
| 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.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
