blob: 8841df6908e6779245d6795e1f4e274f4d13ee20 [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.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="-zfl87vJBFdinDB02ArLXOQ" name="new_concept,_HZGFsKrPEdu6T6WyNqBzqQ" guid="-zfl87vJBFdinDB02ArLXOQ" changeDate="2008-02-14T05:48:12.000-0800" version="7.2.0">
<mainDescription>&lt;h3 align=&quot;left&quot;>&#xD;
Modeling Components&#xD;
&lt;/h3>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
The UML component is a modeling construct that provides the following capabilities:&#xD;
&lt;/p>&#xD;
&lt;div align=&quot;left&quot;>&#xD;
&lt;ul>&#xD;
&lt;li>&#xD;
Group classes to define a larger granularity part of a system&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
Separate the visible interfaces from internal implementation&#xD;
&lt;/li>&#xD;
&lt;li>&#xD;
Execute instances run-time&#xD;
&lt;/li>&#xD;
&lt;/ul>&#xD;
&lt;/div>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
A component includes &lt;strong>provided&lt;/strong> and &lt;strong>required&lt;/strong> interfaces that form the basis for wiring&#xD;
components together. A &lt;strong>provided interface&lt;/strong> is one that is either implemented directly by the component&#xD;
or one of its realizing classes or subcomponents, or it is the type of a provided port of the component. A&#xD;
&lt;strong>required interface&lt;/strong> is designated by a usage dependency of the component or one of its realizing&#xD;
classes or subcomponents, or it is the type of a required port.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
A component has an external view (or &lt;em>black box&lt;/em> view) through its publicly visible properties and operations&#xD;
.Optionally, a behavior such as a protocol state machine may be attached to an interface, a port, and the component&#xD;
itself to define the external view more precisely by making dynamic constraints in the sequence of operation calls&#xD;
explicit. The wiring between components in a system or other context can be structurally defined by using dependencies&#xD;
between component interfaces (typically on component diagrams).&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
Optionally, you can make a more detailed specification of the structural collaboration by using parts and connectors in&#xD;
composite structures to specify the role or instance-level collaboration between components. That is the component's&#xD;
internal view (or &lt;em>white-box&lt;/em> view) through its private properties and realizing classes or subcomponents. This&#xD;
view shows how the external behavior is realized internally. The mapping between external and internal views is by&#xD;
dependencies on components diagrams or delegation connectors to internal parts on composite structure diagrams.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
A number of UML standard stereotypes exist that apply to components, including &amp;lt;&amp;lt;subsystem&amp;gt;&amp;gt; to model&#xD;
large-scale components, and &amp;lt;&amp;lt;specification&amp;gt;&amp;gt; and &amp;lt;&amp;lt;realization&amp;gt;&amp;gt; to model components with&#xD;
distinct specification and realization definitions, where one specification may have multiple realizations.&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
The recommendation is to&amp;nbsp;use components as the representation for design subsystems.&#xD;
&lt;/p>&#xD;
&lt;h3 align=&quot;left&quot;>&#xD;
UML Definitions -- A History&#xD;
&lt;/h3>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
The definition of &lt;em>component&lt;/em> with the UML has changed over time with the release of different versions. The&#xD;
version of UML you use may be constrained by the capabilities of the modeling tools you use. That is why the&#xD;
definitions from 1.3 to 2.0 are provided here.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
UML 2.0 defined &lt;em>component&lt;/em> as the following:&#xD;
&lt;/p>&#xD;
&lt;blockquote dir=&quot;ltr&quot; style=&quot;MARGIN-RIGHT: 0px&quot;>&#xD;
&lt;blockquote>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
...a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its&#xD;
environment.&#xD;
&lt;/p>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
A component defines its behavior in terms of provided and required interfaces. As such, a component serves as a&#xD;
type whose conformance is defined by these provided and required interfaces (encompassing both their static as&#xD;
well as dynamic semantics).&#xD;
&lt;/p>&#xD;
&lt;/blockquote>&#xD;
&lt;/blockquote>&#xD;
&lt;p align=&quot;left&quot;>&#xD;
UML 1.5 defined &lt;em>component&lt;/em> as the following:&#xD;
&lt;/p>&#xD;
&lt;blockquote>&#xD;
&lt;blockquote>&#xD;
&lt;div align=&quot;left&quot;>&#xD;
A modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of&#xD;
interfaces. A component is typically specified by one or more classes or subcomponents that reside on it and&#xD;
may be implemented by one or more artifacts (e.g., binary, executable, or script files).&#xD;
&lt;/div>&#xD;
&lt;div align=&quot;left&quot;>&#xD;
&lt;p>&#xD;
In UML 1.3 and earlier versions of the UML, the component notation was used to represent files in the&#xD;
implementation. Files are no longer considered components by the latest UML definitions. However, many&#xD;
tools and UML profiles still use the component notation to represent files.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
&lt;br />&#xD;
&lt;br />&#xD;
&amp;nbsp;&#xD;
&lt;/p>&#xD;
&lt;/div>&#xD;
&lt;/blockquote>&#xD;
&lt;/blockquote></mainDescription>
</org.eclipse.epf.uma:ContentDescription>