Interface System

All Superinterfaces:
org.eclipse.emf.cdo.CDOObject, org.eclipse.emf.cdo.common.id.CDOWithID, ComposedProvidingRequiringEntity, ComposedStructure, Entity, EObject, de.uka.ipd.sdq.identifier.Identifier, InterfaceProvidingEntity, InterfaceProvidingRequiringEntity, InterfaceRequiringEntity, NamedElement, Notifier, PCMBaseClass, PCMClass, ResourceInterfaceRequiringEntity
All Known Implementing Classes:
SystemImpl

public interface System extends Entity, ComposedProvidingRequiringEntity
A representation of the model object 'System'. A System is the out-most entity of a PCM's assembly of components. It captures the modeling decision to which extend a system under investigation is modelled within the PCM. A System is not composable (part of another composition) because it has QoS annotations which are only allowed in the "outer" composition thing. And a UsageModel must only access ProvidedRoles of a System and not of inner components. The System is inheriting from ComposedProvidingRequiringEntity to have a unique means for expressing the inner composition of an entity (here: System). Also it allows using the same editor etc. being applied to ComposedProvidingRequiringEntity and thus also being useful for System. A system consists of an assembly and is itself referenced by an allocation (only a System can be allocated). The first specifies how the components are connected with other components, the latter specifies how the components and connectors are mapped to the resource environment (hardware and middleware). From a structural point of view, Systems can be seen as special kind of CompositeComponents. Systems are not supposed to be reused as components are. The are assumed to be coupled by using special techniques for system integration. A System has provided and required roles like a composite component. Only a system's provided role can be accessed from the usage profile. Only a system's required roles can have QOS annotations. Like SubSystems, Systems are white-box entities for the Software Architect and also for the System Deployer. Thus, a System Deployer can and must allocate inner components of a System individually.

The following features are supported:

See Also:
Generated class or method.
EMF model class or method.
annotation="http://www.eclipse.org/emf/2002/Ecore constraints='systemMustHaveAtLeastOneProvidedRole'" annotation="http://www.eclipse.org/emf/2002/Ecore/OCL/LPG systemMustHaveAtLeastOneProvidedRole='not self.providedRoles_InterfaceProvidingEntity->isEmpty()'"
  • Field Details

  • Method Details

    • getQosAnnotations_System

      EList<QoSAnnotations> getQosAnnotations_System()
      Returns the value of the 'Qos Annotations System' containment reference list. The list contents are of type QoSAnnotations. It is bidirectional and its opposite is 'System Qo SAnnotations'. QoS Annotations allow for specifing fixed (non-parameterised) QoS properties at the system boundary level for required services. For example, for a required service it can be specified that its response time is fixed "3 ms". See the QoS Annotations package for more details.
      Returns:
      the value of the 'Qos Annotations System' containment reference list.
      See Also:
      Generated class or method.
      EMF model class or method.
      opposite="system_QoSAnnotations" containment="true" ordered="false"