<?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" xmi:id="-zfl87vJBFdinDB02ArLXOQ" name="new_concept,_HZGFsKrPEdu6T6WyNqBzqQ" guid="-zfl87vJBFdinDB02ArLXOQ" changeDate="2007-01-23T15:18:34.453+0330">
  <mainDescription>&lt;p align=&quot;left&quot;>&#xD;
    The Unified Modeling Language [&lt;a class=&quot;elementLinkWithUserText&quot; href=&quot;./../../../openup/guidances/supportingmaterials/references_6CCF393.html&quot; 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). (See &lt;strong>UML representation&lt;/strong> at the&#xD;
            end of this section for definitions from earlier versions of UML.)&#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;
    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.&#xD;
&lt;/p>&#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. See the section on Component Replaceability.&#xD;
&lt;/p>&#xD;
&lt;h4 align=&quot;left&quot;>&#xD;
    Modeling of components&#xD;
&lt;/h4>&#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;
    The recommendation is to&amp;nbsp;use components as the representation for design subsystems.&#xD;
&lt;/p>&#xD;
&lt;h4 align=&quot;left&quot;>&#xD;
    UML representation&#xD;
&lt;/h4>&#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;/div>&#xD;
    &lt;/blockquote>&#xD;
&lt;/blockquote></mainDescription>
</org.eclipse.epf.uma:ContentDescription>
