Drawbacks to the Model Interface
The Model Interface is the interface of the <<Subsystem>>_Model.
The model interface was produced with extreme pressure to get UML1.4 implemented at the same time. As a result we have the following drawbacks in the design.
Single Instance
The repository behind the model interface is initialised at application startup. This means it is not possible to move from one project to another with different repositories for each. ArgoUML has to shut down and be restarted to changes modes.
With the need to store multiple projects at a time on the wishlist for ArgoUML we need to cater for the possibility that they require different repositories.
Everything is Object
Outside the model implementation all model element are simply tokens passed around as Objects. This is to cater for the fact that the actual repositories in any implementation have different class names for what is logically the same thing.
This breaks one of the Object Oriented principles of bringing data and functionality together in an Object.
A developer cannot discover what functionality an object has. He can only infer that from the name and find the other suitable utility class that will perform the function required on that object.
Structure based on UML1.4
The model interface is heavily based on the structure of UML1.4 and so does not fit well to UML2 or any other future structural change to the UML specification.
For example the Facade interface has many methods for identifying model elements such isAClassifier, isAInterface. There is also a MetaTypes interface with methods such as getClass(), getInterface() etc. The new elements in UML2 all need their own method adding to this interface. This gives a lack of stability to the model interface on each release.
Bloated API
The model interface is made up of several Java Interfaces. Because of the strong tie in to a particular UML definition there are many methods supplied for each type of UML object rather than providing generic methods that can handle any object.