Skip to content

Xtuml change monitor

Tamas Borbas edited this page Aug 3, 2015 · 5 revisions

The XtumlModelChangeMonitor is a util to collect dirty XTComponents from a scoped ResourceSet. It returns a set of XTComponents, which are changed since the last monitor initialization. The dirty component selection is based on lower level modifications. This modifications are detected by registered EMF-IncQuery patterns.

The XtumlModelChangeMonitor is placed in the ccp.transformation.monitor package under the cpp.transformation project.

Usage

Start monitoring

To start a new change monitor, create an XtumlModelChangeMonitor instance on a valid AdvancedIncQueryEngine and call startMonitoring() method.

Get dirty components

On a running change monitor call the createCheckpoint() method to store components, which are became dirty since last call or since the start of the monitoring. You can get all dirty components with getDirtyXtComponents() method.

Dispose and clear

It is possible to delete stored dirty components from the internal memory with the clear() method and dispose the monitoring with the dispose() method. Furthermore the change monitor will be automatically disposed when the related engine is disposed or wiped.

Register patterns

In the current phase there are three patterns registered in the change monitor, which help to define changes in the containment hierarchy starts form an xtcomponent. It is possible to register further patterns with the registerQuerySpecification() method. It needs two parameters:

  • the IQuerySpecification implementation of the pattern
  • the scoped element position in the pattern parameters

Existing patterns

The following modifications are noticed:

  • Modifications of XTClass in XTComponent (for example: rename class or add a relation to the class).
  • Modifications of Package in XTComponent (for example: add a new class to the package).

Missing patterns

We need to notice the following elements' modifications:

  • ActionChain, ActionCode
  • Attribute
  • Enumeration, EnumerationLiteral (?)
  • Signal
  • StateMachine
  • Operation
  • Parameter
  • Trigger
  • Type
  • Vertex
  • XTClass (which is not explicitly in an XTComponent will not be found)
  • XTComponent (?)
  • XTEvent
  • XTRelation

The principles to be followed in patterns

We need to find the removed/added/modified element but the containing component does not need to be found. Not enough to watch for EObjects beacuse it will indicate changes permanently. So for example not enough to watch for association's modification but we also need to notice the association when an end modified and its not in the association's component. Base on these principles the existing patterns are not correct and we should modify them. For example we may need to replace this:

pattern xtComponentXTClasses(
	xtComponent : XTComponent,
	xtClass : XTClass
) {
	XTComponent.entities(xtComponent, xtClass);
}

with this:

pattern baseConainerXTClasses(
	baseContainer : BaseContainer,
	xtClass : XTClass
) {
	BaseContainer.entities(baseContainer, xtClass);
}
Clone this wiki locally