| <?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="-zfl87vJBFdinDB02ArLXOQ" |
| name="new_concept,_HZGFsKrPEdu6T6WyNqBzqQ" guid="-zfl87vJBFdinDB02ArLXOQ" changeDate="2007-01-23T03:48:34.453-0800"> |
| <mainDescription><p align="left">
 |
| The Unified Modeling Language [<a class="elementLinkWithUserText" href="./../../../openup/guidances/supportingmaterials/references_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). (See <strong>UML representation</strong> at the
 |
| end of this section for definitions from earlier versions of UML.)
 |
| </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">
 |
| A number of UML standard stereotypes exist that apply to components, including &lt;&lt;subsystem&gt;&gt; to model
 |
| large-scale components, and &lt;&lt;specification&gt;&gt; and &lt;&lt;realization&gt;&gt; to model components with
 |
| distinct specification and realization definitions, where one specification may have multiple realizations.
 |
| </p>
 |
| <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. See the section on Component Replaceability.
 |
| </p>
 |
| <h4 align="left">
 |
| Modeling of components
 |
| </h4>
 |
| <p align="left">
 |
| The UML component is a modeling construct that provides the following capabilities:
 |
| </p>
 |
| <div align="left">
 |
| <ul>
 |
| <li>
 |
| Group classes to define a larger granularity part of a system
 |
| </li>
 |
| <li>
 |
| Separate the visible interfaces from internal implementation
 |
| </li>
 |
| <li>
 |
| Execute instances run-time
 |
| </li>
 |
| </ul>
 |
| </div>
 |
| <p align="left">
 |
| A component includes <strong>provided</strong> and <strong>required</strong> interfaces that form the basis for wiring
 |
| components together. A <strong>provided interface</strong> 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
 |
| <strong>required interface</strong> 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.
 |
| </p>
 |
| <p align="left">
 |
| A component has an external view (or <em>black box</em> 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).
 |
| </p>
 |
| <p align="left">
 |
| 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 <em>white-box</em> 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.
 |
| </p>
 |
| <p align="left">
 |
| The recommendation is to&nbsp;use components as the representation for design subsystems.
 |
| </p>
 |
| <h4 align="left">
 |
| UML representation
 |
| </h4>
 |
| <p align="left">
 |
| The definition of <em>component</em> 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.
 |
| </p>
 |
| <p align="left">
 |
| UML 2.0 defined <em>component</em> as the following:
 |
| </p>
 |
| <blockquote dir="ltr" style="MARGIN-RIGHT: 0px">
 |
| <blockquote>
 |
| <p align="left">
 |
| ...a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its
 |
| environment.
 |
| </p>
 |
| <p align="left">
 |
| 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>
 |
| </blockquote>
 |
| </blockquote>
 |
| <p align="left">
 |
| UML 1.5 defined <em>component</em> as the following:
 |
| </p>
 |
| <blockquote>
 |
| <blockquote>
 |
| <div align="left">
 |
| 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).
 |
| </div>
 |
| <div align="left">
 |
| <p>
 |
| 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.
 |
| </p>
 |
| </div>
 |
| </blockquote>
 |
| </blockquote></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
