Purpose - To handle generating, updating and editing in different languages of a textual representation which represents one or more UML modelelements. Such a notation element gets e.g. attached to a diagram figure or an explorer entry.

The notation subsystem is located in org.argouml.notation and its sub-folders.

Figure 5.2. Notation subsystem part 1.

In the scope of issue 3140, the notation architecture has been discussed. Later, a change has been performed to resolve dependency cycles.

We decide that we support other languages than UML to show in diagrams, but this shall be a user-choice with project scope - and we will never refine the scope to something more detailed. Hence we need not store the notation language per Fig. So, this means that you can set the notation language in the project properties, and in the application-wide defaults.

The interface NotationProvider is at the center of the subsystem. There is an object implementing the NotationProvider interface per string (i.e. textual model representation) that is shown on the diagram: e.g. TransitionNotation, StateBodyNotation, ModelElementNameNotation. A state will show the latter 2.

This notation object would keep track of which UML objects it represents, generate and parse and provide a help text.

The Fig refreshes the text by calling the toString() method of the Notationprovider, at initialisation time and whenever the model changes. This latter works as follows: The notation object defines the set of model change events that the Fig listens at. Putting this task into this Notation class (instead of the Fig) has the advantage that the knowledge to which uml objects to listen is centralised where it is needed, and not in the Fig. The Fig then receives a PropertyChangeEvent when the model changes. This causes the Notationprovider to update the set of listeners, and the Fig refreshes the rendering of its string.

Figure 5.3. Notation subsystem part 2.

The NotationProvider objects TransitionNotation, StateBodyNotation, etc. are abstract, since they are specialised in classes that implement them for a certain language, i.e. one per language. So, we will have: TransitionNotationUML, TransitionNotationJava, ... etc.

The NotationProviderFactory2 is a singleton, since it is the accesspoint for all Figs to create the textual representation of modelobjects, and since plugin modules can add extra languages. Once/if ArgoUML would support multiple projects, then we would need one NotationProviderFactory2 per project, since its language may differ per project.

The NotationProviderFactory2 creates a notation object on request for any Fig, based on the current notation language selected by the user for the current project. Hence, when the user changes the language (in the menu), then it is the Fig's responsibility to listen to the NotationEvent (hence the Fig shall implement ArgoNotationEventListener), and ask the NotationProviderFactory2 to create a new NotationProvider child.

Figure 5.4. Notation subsystem part 3.