The MOP/OII project was our first experience with software design of a larger magnitude. We must say that sometimes we were to optimistic and we underestimated the time and work necessary to complete certain tasks. It was also interesting to work as a team and taking decisions together that would influence the whole game. We must add that all four of us shared the same vision, so working together was a pleasure.
When we started with the project, we chose Rational Rose as our development tool. Mainly because we thought our computers were not powerful (RAM) enough to work with Together. Later on we started to feel this choice was a mistake. We wanted to take advantage of the code generation and CVS- support Together offers, so we switched tools and started all over again. The use of Together turned out to be only a partial success. The code generation worked fine, but after a few not so good experiences with the built in CVS-support, we decided to commit, update and add manually. We used the CVS-server pooky of the computer science department, but pooky wasn't always available, this was quite awkward sometimes.
We also encountered some flaws (from our point of view, they were) in Java.
Containers in Java can only hold
means that you have to do a lot of typecasting. It is very well possible that
a program compiles but just won't run, because you made some casting mistakes.
Java simply doesn't offer any form of type safety. We often felt the need for
templates (like in C++). An other problem we noticed, is the fact that it is
not possible to inherit static functions in Java. We encountered this problem
while implementing the
KnowledgeCatalogs, which are all singletons
who inherit from one superclass. because of this, we had to duplicate a lot
of code. It is our believe that Java is not yet as generic as we would like
it to be and that there are lot's of things in Java that still need to be implemented.
An other thing we really want to add, is that the two parts of the MOP/OII project were very badly balanced. The first part was way to heavy and we needed much more time to complete this part then the deadline provided. This is however not only a flaw of the task. We wanted to make our design as generic as possible and this choice resulted in a lot of extra work. We anticipated to much on possible extensions of the design in the second part. It is true that the task for part two was a little bit of a disappointment in this way. We could have changed course on that point, but we were determinded to go ahead on the road taken and continue with our generic design.