Archives: Templates

The representation of a physical part from the system specification.

The Unified Modeling Language (UML) specifies a component as a set of constructs that can be used to define software systems of arbitrary size and complexity. In particular, it specifies a Component as a modular unit with well-defined Interfaces that is replaceable within its environment. The Component concept addresses the area of component-based development and component-based system structuring, where a Component is modeled throughout the development life cycle and successively refined into deployment and run-time.

An important aspect of component-based development is the reuse of previously constructed Components. A Component can always be considered an autonomous unit within a system or subsystem. It has one or more provided and/or required Interfaces (potentially exposed via Ports), and its internals are hidden and inaccessible other than as provided by its Interfaces. Although it may be dependent on other elements in terms of Interfaces that are required, a Component is encapsulated and its Dependencies are designed such that it can be treated as independently as possible. As a result, Components and subsystems can be flexibly reused and replaced by connecting (‘wiring’) them together.

The aspects of autonomy and reuse also extend to Components at deployment time. The artifacts that implement Component are intended to be capable of being deployed and re-deployed independently, for instance to update an existing system.

The Components package supports the specification of both logical Components (e.g., business components, process components) and physical Components (e.g., EJB components, CORBA components, COM+ and .NET components, WSDL components, etc.), along with the artifacts that implement them and the nodes on which they are deployed and executed. It is anticipated that profiles based around Components will be developed for specific component technologies and associated hardware and software environments.

A Component represents a modular part of a system that encapsulates its contents and whose manifestation is replaceable within its environment.

A Component is a self-contained unit that encapsulates the state and behavior of a number of Classifiers. A Component specifies a formal contract of the services that it provides to its clients and those that it requires from other Components or services in the system in terms of its provided and required Interfaces.

A Component is a substitutable unit that can be replaced at design time or run-time by a Component that offers equivalent functionality based on compatibility of its Interfaces. As long as the environment is fully compatible with the provided and required Interfaces of a Component, it will be able to interact with this environment. Similarly, a system can be extended by adding new Component types that add new functionality. Larger pieces of a system’s functionality may be assembled by reusing Components as parts in an encompassing Component or assembly of Components, and wiring them together.

A Component is modeled throughout the development life cycle and successively refined into deployment and run-time.

A Component may be manifested by one or more Artifacts, and in turn, that Artifact may be deployed to its execution environment. A DeploymentSpecification may define values that parameterize the Component’s execution.

The required and provided Interfaces of a Component allow for the specification of StructuralFeatures such as attributes and Association ends, as well as BehavioralFeatures such as Operations and Receptions. A Component may implement a provided Interface directly, or its realizing Classifiers may do so, or they may be inherited. The required and provided Interfaces may optionally be organized through Ports; these enable the definition of named sets of provided and required Interfaces that are typically (but not always) addressed at run-time.

A Component has an external view (or ‘black-box’ view) by means of its publicly visible Properties and Operations.

Optionally, a Behavior such as a ProtocolStateMachine may be attached to an Interface, Port, and to 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 compatible simple Ports, or between Usages and matching InterfaceRealizations that are represented by sockets and lollipops on Components on Component diagrams. Creating a wiring Dependency between a Usage and a matching InterfaceRealization, or between compatible simple Ports, means that there may be some additional information, such as performance requirements, transport bindings, or other policies that determine that the Interface is realized in a way that is suitable for consumption by the depending Component. Such additional information could be captured in a profile by means of stereotypes.

A Component also has an internal view (or “white-box” view) by means of its private Properties and realizing Classifiers. This view shows how the external Behavior is realized internally. Dependencies on the external view provide a convenient overview of what may happen in the internal view; they do not prescribe what must happen. More detailed behavior specifications such as Interactions and Activities may be used to detail the mapping from external to internal behavior.

The execution time semantics for an assembly Connector in a Component are that requests (signals and operation invocations) travel along an instance of a Connector. The execution semantics for multiple Connectors directed to and from different roles, or n-ary Connectors where n> 2, indicates that the instance that will originate or handle the request will be determined at execution time.

A number of UML standard stereotypes exist that apply to Component. For example, Subsystem to model large-scale Components, and Specification and Realization to model Components with distinct specification and realization definitions, where one specification may have multiple realizations (see the Standard Profiles).

A Component may be realized (or implemented) by a number of Classifiers. In that case, a Component owns a set of ComponentRealizations to these Classifiers.

A component acts like a Package for all model elements that are involved in or related to its definition, which should be either owned or imported explicitly. Typically the Classifiers that realize a Component are owned by it.

The isDirectlyInstantiated property specifies the kind of instantiation that applies to a Component. If false, the Component is instantiated as an addressable object. If true, the Component is defined at design-time, but at run-time (or executiontime) an object specified by the Component does not exist, that is, the Component is instantiated indirectly, through the instantiation of its realizing Classifiers or parts.

A potential reason for winning over a competitor.

A set of objects with identical characteristics.

In the Unified Modeling Language (UML) a Class is a kind of EncapsulatedClassifier whose Features are Properties, Operations, Receptions, Ports and Connectors.

Attributes of a Class are Properties that are owned by the Class. Some of these attributes may represent the ends of binary Associations.

Objects of a Class must contain values for each attribute that is a member of that Class, in accordance with the characteristics of the attribute, for example its type and multiplicity.

When an object is instantiated in a Class, for every attribute of the Class that has a specified default, if an initial value of the attribute is not specified explicitly for the instantiation, then the default ValueSpecification is evaluated to set the initial value of the attribute for the object.

Operations of a Class can be invoked on an object, given a particular set of values for the parameters of the Operation, according to the semantics specified in UML

A Class cannot access private Features of another Class, or protected Features on another Class that is not its ancestor.

A Class acts as the namespace for various kinds of Classifiers defined within its scope, including Classes. Nested Classifiers are members of the namespace of the containing Class. Classifier nesting is used for reasons of information hiding.

A Class may be designated by setting isActive to true as active (i.e., each of its instances is an active object). When isActive is false the Class is passive (i.e., each of its instances executes within the context of some other object).

An active object is an object that, as a direct consequence of its creation, commences to execute its classifierBehavior, and does not cease until either the complete Behavior is executed or the object is terminated by some external object. (This is sometimes referred to as ‘the object having its own thread of control.’) The points at which an active object responds to communications from other objects is determined solely by the Behavior of the active object and not by the invoking object. If the classifierBehavior of an active object completes, the object is terminated.

A Class’s Receptions specify which Signals the instances of this Class handle.

An InstanceSpecification may be used to specify the initial value to be created for a Class.

All instances corresponding to parts and ports of a Class are destroyed recursively, when an instance of that Class is deleted.

A Class may act as a metaclass in the definition of Profiles and metamodels.

A ChangeRequest represents a request from an interested party for a change in the way the business is run, how the project is carried out, in the content of a design component in the repository etc.

It should always be clear to an organization how to handle a ChangeRequest. The process of analyzing the request, recommending an action and carrying out an action should be controlled by the project management or the resposible of the content associated to the change request.

 

As standard a Change request can be created by all users, either from the “My Desktop” or in relation the approved content as part of the standard change management governance flow.

Change Requests are also used to document findings in relation to an audit.

 

 

 

 

 

Read more about how to manage change requests here

 

 

 

A certificate is used by a Person or an OrganizationUnit and grants the rights to perform specific Activity in the company.

It may also be used to define and document the results of training, education etc.