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