Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

currently I'm designing an add-in for the modelling tool Enterprise Architect. The general architecture is shown in the picture below.

General add-in architecture

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?

share|improve this question
    
Why were the monolithic static classes a problem for maintainability in previous projects? Was it because the Utility classes were not properly organized into functional areas? –  Robert Harvey Jun 14 '13 at 15:19
    
@RobertHarvey not only that, but there were long sequences of method calls across those Utility classes to achieve the tasks. Those sequences are hard to understand because of the sheer number. This approach would better fit in an object structure in my opinion. More than that, a utility class is in my opinion self-containing and does not need other classes to deliver its service. –  McMannus Jun 14 '13 at 15:39
add comment

1 Answer

up vote 0 down vote accepted

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:

Addin Structure

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.