The following suggests an architecture for an alternative notation subsystem within arguml
The advantages over the current implementation are
- Modular/Pluggable
- No reflection
- Separation of responsibilities for interpreting and generating notation text
- Multi-threaded generation of notation text
- Less events sent to GUI
Diagram classes
FigNotation
This is the only diagram class that needs to implement the NotatedItem interface. It shows text for an element such as an attribute in the diagram. It is not thought that any subclasses will be required for this as all code that handles differences in presentation or input through the Fig are managed by the notations.
Core Notation Classes
NotatedItem
implemented by any visual class that wants to display a notation
notationTextChanged() - called by the notation subsystem to tell the item to redraw with the given text.
getMetaType() - returns the metatype of this item (e.g. Operation, Attribute)
getNotationType() - this is normally "name" but other notations on a diagram might be "multiplicity"
NotationUtility
The core point of registration for any new notations or items listening for notation changes
NotationLanguage
The interface that any notation languages should implement (e.g. UML, Java etc).
NotationText
The interface that any classes generating notation text must implement.
Notation Implementation Classes
UML in this example could be any programming language.
UmlNotationModule
Module startup class - registers the UML notation with NotationUtility
UmlNotationLanguage
Central class for controlling requests for UML notations.
When NotatedItems are added a listeners a new NotationText class is started in its own thread and the listener is added to that class.
Any requests to interpret a text string of a notation provided by some external class is delegated to some Interpreter class
NotationText implementations (pink)
These are coded to listen to the specific model elements required for this language and notation item. e.g. for a UML operation it will be listening to the operation and all the parameters of that operation.
When it receives an event that any of these have changed in a relevant way it regenerates the text for the notation and queues an event to fire that text back to the NotatedItem that is listening to it.
The firing of the queued text is delayed by a fraction of a second to allow the possibility that any further change affecting the notation is about to follow soon after from the model subsystem. If another change is detected the first event is removed from the queue.
Interpreter class (yellow)
These interpret a string of text in the format of the language for a specific item and updates all model elements required.