Subsections

Design goals

The design of Jupe is following a number of goals. Of course, some of them are controversial so that we had to find compromises. We also found some design goals that are less important for us, so that they are neglected in case of conflicts. E.g. efficiency in CPU and memory usage aren't in our focus.

Extensibility

Extensibility is our most important design goal. The duration of the project with the initial team was fixed to 10 months. It is evident that not all possible features could be implemented in this period. In order to allow a successful continuation of our work we had to focus on some of them and build up an architecture that allows to add other features later. We mainly thought about two types of extension: Firstly, there is support for other programming languages than Java. As Eclipse offers its functionalities for C++ using CDT, an extension of Jupe to C++, but also every other object oriented programming language might be imaginable. Further, we want to permit the extension of Jupe to create other diagram types than class diagrams. E.g. sequence diagrams, use case diagrams and component diagrams are very important parts of the UML standard, but could not be treated during the first 10 months.

Reuse and reusability

Other important goals for us are reuse and reusability. The reasons for reuse of existing software are obvious. It allows to save time, leads to more stable software and permits us to focus on parts of the program not already existent. On the contrary, it demands the understanding of the API of the reused framework or library which can be time-consuming.

The reusability of our own work is substantial to achieve the extensibility design goal. We tried to design Jupe to be as extensible as possible for the above mentioned extensions. Though we didn't focus on reusability of our source code by others.

Orthogonality

The aim of an orthogonal design is to guarantee that operations within one of its components neither create nor propagate side-effects to other components. Orthogonality reduces the test and development time, because it is easier to verify designs that neither cause side effects nor depend on them. Moreover, it allows to replace particular components of a software without effecting the rest of the system. Developing orthogonal software costs additional investments at first, but pays off when the system grows.

Correctness

The correctness of our plugin is another significant issue. We aim to use the Unified Modeling Language (UML) in version 2 which is officially defined as standard by the Object Management Group (OMG) [8]. Though we don't aspire to support the complete standard or the complete standard for class diagrams. We want to concentrate on the important features of UML and provide a correct implementation of them.

Usability

Usability is the extent in which a product can be used to achieve specified goals with effectiveness, efficiency and satisfaction. In our context, it describes a user-friendly interface and particularly an appropriate integration into the Eclipse platform. We try to reuse as much as possible of Eclipse' interface in order to disturb the user as less as possible in his workflow. Furthermore, we aim to offer an easy to learn plugin that allows to achieve common tasks in a short time.

Simplicity

The last but not least design goal is simplicity. It is evidently opposed to other goals as reusability and orthogonality so that trade-offs have to be made. Simple systems are easier to maintain, have less bugs and can be developed faster. In consideration of the limited time that we had to present our first results, simplicity had to be a design goal, too.

http://jupe.binaervarianz.de