The Facade class

The use of Facade class is not wide spread in ArgoUML. This is because ArgoUML is traditionally built as a whole and no subsystems were clearly defined.

A Facade class provides the most common functions other subsystems want to do when using that subsystem to reduce the need of having to use anything else but the Facade class. The Facade class should be very much more stable than the subsystem itself. Methods in the Facade should change very slowly and only be removed after several months (and one stable release) of deprecation.

The Facade class is documented in the class file itself (as javadoc) and the more complex picture (if needed) is documented in the Cookbook (in Chapter 5, Inside the subsystems).

An API with calls to public or protected methods.

Traditionally, the subsystems in ArgoUML communicate through public methods and public variables and the subsystems, as defined by the responsibilities, are spread over several packages setting aside the Java visibility rules. For this reason it is not well-known or documented what public methods form part of a subsystem's API and what public methods are internal to a subsystem. For this reason, always exercise extreme caution when changing the signature of a public method. (See Section 7.2, “When Committing to the Repository”.)

In order to improve things, make it very clear when encountering and understanding the purpose of a public method or class, if it is part of the subsystem's API or not (by improving the javadoc for that method or class).

Try to help in moving the public API methods and classes from wherever, to the subsystem's directory/package using the proper deprecation procedure.

In order not to worsen things, always add new API classes and methods in the subsystem's directory/package.

This way of communicating is still to be used when it is not convenient to use the Facade for a specific use of that subsystem.