This plugin provides the non-UI services of the tooling kernel.
Each service is identified by a service interface, which provides the public interface to the
service (see org.fortiss.tooling.kernel.service
package).
Most of the services are related to an Eclipse extension point and allow the application (built
on top of the kernel) to extend its functionality with specific implementations.
For example, the kernel provides an interface to cope with different storage solutions, which itself
uses to provide a file based storage solution based on the Eclipse workspace.
The extension point schemas for the kernel extensions can found in the schema
folder of
the plugins.
The kernel provides the following services:
ICommandStackService
: Management of the command stack (including undo/redo).IConnectionCompositorService
: Manages IConnectionCompositor
s (connection
between model elements).IConstraintCheckerService
: Manages IConstraintChecker
s.IConstraintService
: Manages IConstraint
sIEclipseResourceStorageService
: Manages model files residing in the local Eclipse
workspace.IElementCompositorService
: Manages IElementCompositor
s (composition
of model elements).IKernelIntrospectionSystemService
:
kernel introspection system service (KISS)ILibraryService
: Manages the model element library.ILoggingService
: Manages the logging of message.IMigrationService
: Upgrades old models to the latest metamodel.IPersistencyService
: Provides transparent access to the different persistency options
(e.g., local files, database, ...)IPrototypeService
: Manages modeling IPrototypes
s (generic description
of pre-configured objects).ITransformationService
: Manages ITransformationProvider
s that
encapsulate the transformation of a given source to a given target model.ITutorialService
: Provides pre-defined models with step-wise
example procedures for implementing educational tutorials to the end-user.
Extensions to the kernel services are realized by implementing a handler interface provided by the
kernel (see org.fortiss.tooling.kernel.extension
package).
In the communication between the kernel and its extensions, additional data may be required
(see org.fortiss.tooling.kernel.extension.data
package) or exceptions may be raised
(see org.fortiss.tooling.kernel.extension.exception
package).
The kernel also provides abstract base implementations for most of the handler interfaces,
which are located in the org.fortiss.tooling.kernel.extension.base
package.
The root package of the tooling kernel metamodel consists of the following classes:
IIdLabeled
: Model elements implementing this interface have a unique identifier.INamedElement
: Model elements implementing this interface have a unique id and a name.INamedCommentedElement
: Model elements implementing this interface have a
unique id, a name and a comment.IProjectRootElement
: Super class of all root elements contained in the project.ILibraryRootElement
: Super class of all root elements contained in the libraries.ILibrary
: Super class of all libraries.ILibraryElement
: Super class of all elements contained in a library.ILibraryPackage
: Super class of all library package (that can contain library
elements and/or sub-packages)ILibraryElementReference
: Super class of all references to elements contained
in a library.IExternalDocumentReference
: Reference to an external document.ISpeciallyCopyiable
: Interface to hook code to handle special cases for copy and paste.The constraints
sub-packages contains the following meta-classes required for the
IConstraintService
-based constraint verification mechanism (see below):
IConstrained
: Element which can be constrained. Keeps track of all the constraints
which apply to it.ConstraintInstance
: Constraint "instance": link between the constrained
element(s) and the constraint. Explicitly represented in the model in order to store the status and the
checksum(s) of the constrained element(s).IConstraintInstanceStatus
: Status of verification of a constraint. Typically,
should denote "Success", "Fail", "Outdated" or "Error" with
possible specializations depending on the particular constraints.OutdatedConstraintInstanceStatus
: Status that indicates that the verification
of a constraint is outdated.FailedConstraintInstanceStatus
: Status that indicates that the verification of a
constraint has failed.ErrorConstraintInstanceStatus
: Status that indicates that an error has occurred
during the verification of a constraint.SuccessConstraintInstanceStatus
: Status that indicates that a constraint has
successfully been verified.IConstraintInstanceContainer
: Container to group multiple constraint instances.ConstraintNameToChecksum
: Map type to map constraint names to checksum values.Package providing several basic IConstraintChecker
-based constraint checkers
(supported by IConstraintCheckerService
).
IConstraint
-based constraints (supported by
IConstraintService
).
Interface definitions for extension classes of kernel extension points.
Each interface corresponds to one extendable service from the kernel.service
package
and therefore to one extension point schema definition.
A plugable extension must implement the methods of the respective interface in order to work
properly with the kernel implementation. These methods are called by the kernel at the appropriate time,
e.g., a IPrototypeProvider
is required to provide its prototype elements when the kernel
calls the getPrototypes()
method.
The communication between the kernel and extensions usually involves some kind of
data (e.g. Prototype
). These data-related classes and interfaces can be
found in the kernel.extension.data
package.
For some extensions the kernel provides abstract base implementations in the
kernel.extension.base
package.
Interfaces and classes for data transfer between the kernel and extensions.
The classes and interfaces of this package appear as parameter and result types of the
interfaces in the kernel.extension
package. Parameter objects resemble
additional context data provided to the extension, while result objects are required from the
extension.
On the kernel level the context information is usually empty, i.e., the respective interface is only a marker interface. Higher layers of the tool architecture may extend these interfaces with additional pieces of information. Here, the kernel is only the mediator between plugable parts of the tool.
Some of the result objects provide additional methods, which are used by the
kernel at a later time after requesting it from the extension (e.g. once the
ITopLevelElement
is known to the kernel, the runAsCommand
method will be called whenever some change to the model must be applied).
kernel.service
package.
Kernel services are only accessible through the singletons defined in the kernel.service
package.
The implementation in this package are not intended to be used directly.
Therefore they are not exported in the plugin.xml
.
Implementation of the IStorageProvider
interface using Eclipse file resources as storage mechanism for models.
This storage provider searches all projects in the Eclipse workspace for model files.
Only files in the project's root folder are considered.
For each such files the set of registered eclipseResourceStorageLocationProvider
extensions is
asked whether the respective file should be considered a model file. This extension mechanism is used
to allow independent tools (running in the same Eclipse instance or two RCPs running independently) to use
different file extensions for their models, e.g., tool A uses file pattern *.toolA
,
while tool B uses the file pattern *.toolB
. The file extension is usually a hint on
the meta-model class of the contained root model element.
Interface definitions of the kernel introspection system service (KISS).
Each kernel service should implement the IIntrospectiveKernelService
interface to provide
useful runtime information and a brief documentation its design and objectives.
KISS is intended to be used by the tool developers to ease the development of kernel based tools.
Item definitions for the kernel introspection system service (KISS).
Each kernel service may provide specific runtime information items, which are presented by some tool developer view or console.
Classes in this package are public, since they need to be shared by the user interface implementation.
Interface definitions of the kernel services. Each interface corresponds to a certain functionality of the kernel.
Some of the services provide extension points. Extension implementors should refer to the kernel.extension
and kernel.extension.base
packages. Kernel services are implemented by classes from the kernel.internal
package.
Classes in this packages are listener interfaces for kernel services.
Sometimes higher layers of the tool architecture must be able to know what is happening in the kernel layer. Therefore, they can implement the respective listener interface and register themselves with the respective kernel service.