bug fix: an index is not selected in the outline view if the line that
connects the index figure with the record is selected in the diagram
can add an index to a record; order is LAST, cannot be changed at this
time (this is the case for all sets)
fine-tune create index command and create delete index command (not
hooked yet)
add the component edit policy allowing for the deletion of indexes (not
hooked yet)
Bug fix: when undoing the creation of an index, a NPE would occur

It appears that we will run into trouble in our (graphical) edit parts when
handling upon each individual property change event; in doing so, we will
be exposed to temporary inconsistencies in the schema model (like an area
specification that is not yet or no longer associated with an area).

The outline related (tree) edit parts follow command stack changes but
this is too coarse.

It would be better to respect the fact that a command corresponds to a
unit of work and only act when a unit of work is executed, undone or
redone...
rework the procedure class specifications in the model
Add model change annotations (model change notification redesign).

Model changes are to be controlled in a better way; components
interested in model changes (edit parts, property sections, ...) should
be informed about model changes in a controlled way, i.e. the model 
should always be in a consistent state when informing a component of a 
model change; this is difficult, if not impossible to achieve with EMF
model change events.

Each command executed on the command stack and for which model changes
are to be dispatched to interested components, is assigned a 'model 
change category' and depending on the model change category, 1 or more
fields of the command instance have to be annotated as well (TODO: 
document all annotations so that it is clear which annotation is 
applicable for which model change category).
Rework commands (model change notification redesign).

Model changes are to be controlled in a better way; components
interested in model changes (edit parts, property sections, ...) should
be informed about model changes in a controlled way, i.e. the model 
should always be in a consistent state when informing a component of a 
model change; this is difficult, if not impossible to achieve with EMF
model change events.

Each command executed on the command stack and for which model changes
are to be dispatched to interested components, is assigned a 'model 
change category' and depending on the model change category, 1 or more
fields of the command instance have to be annotated as well (TODO: 
document all annotations so that it is clear which annotation is 
applicable for which model change category).
Add model change infrastructure (model change notification redesign).

Model changes are to be controlled in a better way; components
interested in model changes (edit parts, property sections, ...) should
be informed about model changes in a controlled way, i.e. the model 
should always be in a consistent state when informing a component of a 
model change; this is difficult, if not impossible to achieve with EMF
model change events.

Command stack events are tracked by a model change dispatcher, that
invokes model change category specific methods on model change
listeners.  Model change listeners don't longer have to use instanceof
constructs to detect whether they should update their visuals.
Add command tests (model change notification redesign).
Add test suite (model change notification redesign).