currently I’m designing an add-in for the modelling tool Enterprise Architect. The general architecture is shown in the picture below.
Basically every action where the add-in can react to is triggered by PreDefinedEvents for which the add-in can provide callback functions. These callback functions are the starting point for building whatever application someone would like to put on top EA. One has access to the Model Database (.mdb file) through the API (which uses closed-source algorithms) or by direct access, which can cause of course inconsistencies and is not safe against DB structure changes.
The current approach from previous projects was to build monolithic classes called EA_XXX_Utilities containing a huge amount of static methods. All of these methods get as argument a reference to the model repository which is stored inside the Closed Source and work with it.
I think that this approach is not very handy related to maintainability and extendability, which will have high priority in future projects, so I’m trying to find the best way which let’s me fulfill the requirements according to these quality aspects.
Every requirement basically consists of two parts:
- modify the underlying model
- present parts of the model in a custom way
This smells for me like a kind of MVC architecture, but my major problem is that if I stored the reference the the Model Repository somewhere in my application then I would have to somehow get notified of all changes which the closed source algorithms do to the database. But not all of them are forwarded to the add-in, so at some time the model stored in the add-in will get inconsistent.
This leads to the question:
How can I design the add-in, so that it has some architecture in it at all and even better satisfy the quality aspects?
2
I took the suggestion of Robert Harvey to organize the classes to functional areas. What I came up with as an overall structure is the following: