Software Factory: Adopting DSM for High Evolvement Systems
How you wish you could write a software and say – "Write it, Shut it, Forget it"? If only businesses were so simple and straightforward, and everybody in the world understood everybody else every time of the year. Sigh! There is no dearth of dreams.
Coming back to reality, fuzzy or frequently changing requirements are one of the biggest problems dealing with software systems. Today's requirements are tomorrow's legacy (whether you like it or not), and so on. And keeping your software systems on its toes has, historically, been a pain. The idea of Software Factories draws its nucleus from Domain Specific Modeling, and tries to address this to a very significant extent.
Modeling, at its very core, defines a way for the business users to define what his business is all about, and the mechanisms working together with it – Code Generation, Transformations et.al. – make sure the model is parsed and emitted out as appropriate source code and other artifacts that fuel the software system being developed. In a traditional world, a change in requirement would have to be understood through non-intelligent models, and then understood by a bunch of smart people from IT, and establish processes around this so that they flow down as precisely as possible to the developers.
And History and experience tells us, that even in its most precise form the change in business requirements is never conveyed as-is to the developers, thanks to the eternal troubles of human mind and the limitation of verbal and inter-personal communication. With DSM, this trouble is partially taken over by the mechanism itself.
So the business user makes changes to the model; and because the models are tightly coupled with the domain specific Transformation Mechanisms, they immediately churn out code and artifacts that adhere to the new model to hitherto impossible levels of precision. The developer can take over from here and add customizations and other business logic to the generated artifacts to fine tune them to best suit the software's needs.
The mechanism just described addresses the needs of fuzzy and changing requirements to a great extent, because the generated source code is a direct representation of the changed model, and the transformation logic used to churn out the code is also specific to the domain. And thereby ensuring much lesser pain and loads of reduction in time spent on understanding, translating, coding and validating the requirements.
In the next few posts, I'll discuss the theories, concepts and practices of Domain Specific Modeling.