blob: 472bfb2b84fe7cdaba2a0056a0c8cc48474d6a7b [file] [log] [blame]
<?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="_TZiasMM1EdmSIPI87WLu3g"
name="component,_0YP18MlgEdmt3adZL5Dmdw" guid="_TZiasMM1EdmSIPI87WLu3g" changeDate="2007-05-30T11:38:20.555-0700"
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;
Here. we use &lt;em>component&lt;/em> to mean &lt;strong>an encapsulated part of a system&lt;/strong> that is nontrivial, nearly&#xD;
independent, and replaceable and that fulfils a clear function in the context of well-defined architecture. This&#xD;
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;h4 align=&quot;left&quot;>&#xD;
Component replaceability&#xD;
&lt;/h4>&#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;h4 align=&quot;left&quot;>&#xD;
Component instantiation&#xD;
&lt;/h4>&#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>