Chapter 4. ArgoUML Design, The Big Picture

Table of Contents

4.1. Definition of subsystem
4.2. Relationship of the subsystems
4.3. Low-level subsystems
4.4. Model subsystems
4.5. View and Control subsystems
4.6. Loadable subsystems

Currently this is more of a base for discussion and ambition but hopefully this will mature and prove useful.

The code within ArgoUML is separated in subsystems that each have a few responsibilities.

In Issuezilla each subsystem has its issues sorted in a subcomponent with the same name as the subsystem. Furthermore the Diagrams subsystem has a set of subcomponents for issues connected to the specific diagrams.

This chapter gives an overall picture with a list of subsystems, their dependencies, and their main responsibility. Chapter 5, Inside the subsystems explains each subsystem in detail.

The subsystems are organized in layers. The purpose of the layers is to make it easy to see in what direction the dependencies are and thus allow us to know what dependencies are to be removed in the cases where we have circular dependencies. This will also allow us to know which other subsystems that are involved when testing a subsystem.

4.1. Definition of subsystem

All ArgoUML code is organized in subsystems.

Each subsystem has:

  • A name

  • A single directory/Java package where it resides

    Subparts of the subsystem can reside in subdirectories of this directory. Auxiliary parts, implemented in other products, of the subsystems can reside somewhere else. Notice that each other product used by ArgoUML is, in the design, located within one of the existing subsystems. This means that a change of version or indeed a change of choice of such a sub-product is an internal matter for the subsystem and should ideally not affect any other subsystem.

    All public and protected methods of all public and protected classes in this directory constitute the API of that subsystem.

  • A section in the chapter Chapter 5, Inside the subsystems.

    The section shall for each subsystem contain the responsibilities, the package name, the API, the Facade (if any), all the plug-in interfaces (if any), and documents the insides of the subsystem.

Each subsystem can have:

  • a Facade class

    The facade can be used by all other subsystems when using the subsystem.

    The Facade class is called SubsystemNameFacade and is located in the subsystem package. How it is used is primarily documented in the class file itself (as javadoc) but the more complex picture is documented in the Cookbook (in Chapter 5, Inside the subsystems).

  • Plug-in interfaces.

    These are Facade objects where modules or plug-ins can connect themselves to modify or augment the behavior of that subsystem.

  • The plug-in interfaces are also all located in the subsystem package and called SubsystemNamePluginPluginType. Example: ModelPluginDiagram, ModelPluginType.

  • If the subsystem uses a callback-technique the callback is always made to an interface defined by the subsystem. The interface is also in the subsystem package and it is called SubsystemNamePluginTypeInterface. Example: ModelDiagramInterface, ModelTypeInterface.