Login | Register
My pages Projects Community openCollabNet

argouml
Wiki: Diff for "Notation Architecture"

Edit this page | Links to this page | Page information | Attachments | Refresh page

 

Differences between revisions 8 and 9

Deletions are marked like this. Additions are marked like this.
Line 16: Line 16:
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. 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.
Line 23: Line 23:
notationTextChanged - called by the notation subsystem to tell the item to redraw with the given text. {{{notationTextChanged()}}} - called by the notation subsystem to tell the item to redraw with the given text.
Line 25: Line 25:
getMetaType - returns the metatype of this item (e.g. Operation, Attribute) {{{getMetaType()}}} - returns the metatype of this item (e.g. Operation, Attribute)
Line 27: Line 27:
getNotationType - this is normally "name" but other notations on a diagram might be "multiplicity" {{{getNotationType()}}} - this is normally "name" but other notations on a diagram might be "multiplicity"
Line 29: Line 29:
=== Notation Utility === === NotationUtility ===
Line 40: Line 40:
''UML'' in this example could be any programming language.
Line 41: Line 43:
Module startup class - registers the UML notation with NotationUtility Module startup class - registers the ''UML'' notation with {{{NotationUtility}}}
Line 44: Line 46:
Central class for controlling requests for UML notations. Central class for controlling requests for ''UML'' notations.
Line 46: Line 48:
When NotatedItems are added a listeners a new NotationText class is started in its own thread and the listener is added to that class. When {{{NotatedItems}}} are added a listeners a new {{{NotationText}}} class is started in its own thread and the listener is added to that class.
Line 53: Line 55:
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. 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 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.


CategoryFurtherDevelopment

Notation Architecture (last edited 2011-05-03 17:37:43 -0700 by linus)