Click here to Skip to main content
15,881,424 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
Hello,

It is a common problem that during an ongoing project requirements do change frequently. Functional changes can be handled using -for instance- the decorator pattern and so on. But a serious problem is that when the static structure of any entity changes. You have to do relentless updates on your persistent storage, reports, mappings, models, domain etc.

Does there exist any pattern or best practice to handle such changes, may be by just extending static structure.

Thanks and best regards..
Posted
Comments
Uday P.Singh 6-Dec-11 13:01pm    
good question!

The solution cannot be universal because everything depends on the nature of changing requirements. Resorting to extensions as opposed to modification cannot really help.

I can see only one way: to change approach from hard-coded structures to stored meta-data and knowledge engineering, in particular ontology engineering (please see the links below). However, the architecture of such technology goes well beyond the format of Quick Questions & Answers and could be a matter of a really big article if not a book.

In brief, the changing requirements you face with can be considered as knowledge. Due to changed business settings and quite natural lack of powerful predictive skills and often even the minimal vision of stakeholders, this knowledge can be characterized as junk knowledge. (In such cases developers say "they don't know themselves what they want", and this is just the fact of life, generally unavoidable.) So, hard-coding of such knowledge can be impractical. In certain situations, knowledge engineering can be used to develop a very abstract model of knowledge in the form of meta-data, not hard-coded but stored in some persistent media (database, XML file). For example, in the past I developed technology where the knowledge was represented in the form of some meta-data schema, and we developed meta-data engine and graphic tools used to add/modify structures in the form of UML structural diagrams. The persisting artifact of this engineering step is used to generate code. Most difficult problem here is supporting of backup-compatibility, but automated character of schema evolution helps a lot. One idea is: you can try to stick to incremental changes only. The removed elements are not physically removed from meta-data, but are marked with the special attribute "deprecated"; so the system works with those elements only with legacy data. Again, this is difficult to explain in full in a short answer. (No, this code is not available, sorry.)

This is not easy at all. You can consider some trade-off between highly technological approach and the suffering of frequent manual changes and fixes. You can try to find some practical compromise which itself is difficult. The problem is fundamentally pretty difficult.

See:
http://en.wikipedia.org/wiki/Knowledge_engineering[^],
http://en.wikipedia.org/wiki/Ontology_%28information_science%29[^],
http://en.wikipedia.org/wiki/Ontology_engineering[^],
http://en.wikipedia.org/wiki/Metadata[^],
http://en.wikipedia.org/wiki/Expert_system[^],

—SA
 
Share this answer
 
v2
Comments
Mehdi Gholam 6-Dec-11 12:38pm    
Ever the comprehensive answer , 5!
Sergey Alexandrovich Kryukov 6-Dec-11 12:49pm    
Thank you, Mehdi.
--SA
Wendelius 6-Dec-11 12:39pm    
Very good answer, 5.
Sergey Alexandrovich Kryukov 6-Dec-11 12:50pm    
Thank you, Mika.
--SA
Uday P.Singh 6-Dec-11 13:03pm    
equally good answer 5+
Unfortunately it's the nature of the beast, and you cannot avoid it using traditional programming methods.

However using document databases and storing object structures in JSON or XML etc. do lower the changes and testing needed and in much of the cases are indifferent to schema changes.
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 6-Dec-11 12:23pm    
I voted 4. I agree with the first paragraph, but I know for sure that second part itself does not solve the problem.
Also, there is a fundamentally different approach I used in different projects -- please see my answer.
--SA
Mehdi Gholam 6-Dec-11 12:39pm    
I have been a convert for the past 8 years, so I am biased towards doc databases.
Sergey Alexandrovich Kryukov 6-Dec-11 13:18pm    
I'm not arguing about database vs any other storage system. The storage system depends on the project, requirements and other factors. I just say, this is not a matter of storage system itself, this is a matter of knowledge engineering, and knowledge persistence layer could be implemented in different ways, depending on the volume of knowledge and other factors.
--SA
Mehdi Gholam 6-Dec-11 13:21pm    
Absolutly right.
kkadir 6-Dec-11 14:41pm    
Thanks Mehdi for another angle of view.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900