Table of Contents
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.
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
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).
SubsystemName
Facade
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
.
Example:
SubsystemName
PluginPluginType
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
.
Example:
SubsystemName
PluginType
InterfaceModelDiagramInterface
,
ModelTypeInterface
.