Chapter 4. ArgoUML Design, The Big Picture
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 into 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 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 dependency 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).
This shall be in the first part of the section i.e. not in a subsection.
It should also document the design of the subsystem.
This is in subsections.
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
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
SubsystemName
PluginPluginTypeModelPluginDiagram,
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
SubsystemNamePluginTypeInterfaceModelDiagramInterface,
ModelTypeInterface.
