- 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, RepositoryComponent, ResourceInterfaceRequiringEntity
- All Known Implementing Classes:
SubSystemImpl
public interface SubSystem
extends ComposedProvidingRequiringEntity, RepositoryComponent
A representation of the model object 'Sub System'.
A SubSystem is structually comparable to a CompositeComponent. The major difference is the white-blox property it preserves for System Deployers. While Component Developer have a white-box view for their CompositeComponents, a System Deployer perceives a CompositeComponent like any other component as a black-box entity, which thus cannot be allocated onto different nodes in the resource environment (a CompositeComponent cannot be split up at allocation time).
Opposed to that, SubSystems are white-box entities for System Deployers, meaning that they can be allocated to different nodes of the resource environment, if required. They are pure logical groupings of components, which can be reused by Component Developers and System Architects like usual components.
Remark 1: If a SubSystem is part of a CompositeComponent (inner component) is looses its white-box property, as there is a outer black-box component hiding the its and consequently the SubSytem's internals.
Remark 2: Structurally, SubSytem can be converted into CompositeComponents and vice versa.
Example: To model a layered architecture, of which each layer is potentially split up to run on multiple machines (in the resource environment), each layer can be represented by a subsystem, allowing to allocated each layer's components individually.
- See Also:
SubsystemPackage.getSubSystem()- Generated class or method.
- EMF model class or method.