As our client request, we are proceeding to change the base of our system. We already have the following structure:

A class has many students. (simple typical one - to - many)

Now we must change it to:

A class has many groups. Each group has many students. (Intermediate Object "Group" is inserted).

That seems to be a "simple" change, but it breaks all of the management interface, from both mobile client to web views. And in database structure also.

Our system is a data-management program where we have about 50 - 60 domain objects which are parts of a hierarchy model of around 5 levels. And the intermediate object is inserted in around the 2nd-stage.

My question includes 2 aspects:

1) How to estimate the efforts needed. I'm making a new code branch, then insert the new domain object, after that break the relation of the class-student to insert the new "group" in. Then look in the error-report of Eclipse to locate the troubled code. However, it makes the whole project red, and I'm having troubles giving accurate time-estimation for the task.

2) How to avoid/prevent this situation to happen in the future. It happens once before, and at that time I have spent a week to write database conversion script, as well as making the changes. But at that time the system is still small. Now it has grown big.

  • To answer 1) we'll need to know how much you know. Is there any design documentation available? Do you have UML class diagrams and/or sequence diagrams that you can use to do a survey of the existing code? (or something else that shows how tight the binding of the code is) Is it an option to use reverse / round trip engineering tool to get that overview? (Or at least partially) To answer 2) we'd need to know how much the change is breaking the underlying ERM behind your application. Some changes just can't be made without some major restructuring. – Onno May 27 '13 at 16:20

The best way to do something like this is to do it in small steps. First, even when you add this group, the students are transitively related to single class. So while there is some kind of grouping on the inside, the outside interface might ignore this and present only Student-Class relationship.

So first step might be keeping Student-Class relationship, but add Student-Group and Group-Class relationship to the side. Yes, there will be duplication, but this should be only temporary. This will allow you to slowly refactor from old relationship into the new relationship. This transitive "state" of your model will expose both of those relationships, so clients can slowly move from the old one to the new one. And when all clients move to the new one, you can remove the old one.

  • 1
    Quite common to have this 1/2 way house approach to ensure a clean transition over. Aids in data migration thinking as well. – Martijn Verburg May 27 '13 at 10:37
  • This is a very good solution, I would also suggest just adding the 3 way relationship and keeping it. Because having a students assigned to a class is natural, and then having your students belong to a group is also natural. Then a group can also be limited to a class (and that class's students). This makes the group optional but relational. I have also done what you did and after years, I'm kicking myself not having employed the 3 way relationship I'm forced to always have a group. – Wasted_Coder Nov 20 '15 at 12:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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