Software Factory: Adopting DSM for High Complexity Systems
If a picture is worth a thousand words, a model is worth a thousand lines of code. No, seriously. Despite the insistence on loosely couple architectures et. al., the complexity of the system and hence its underlying code has, historically, been the least receptive to changes.
With Domain Specific Modeling, this pain can be addresses to a large extent. DSM raises the level of abstraction using concepts related to a given business or application domain. The domain experts create a vocabulary consisting of the key concepts of the problem space, business activities, processes etc. Just like any spoken language the vocabulary defines the rules and semantics that govern that particular business. In addition to the business concepts, the vocabulary is typically extended to cover the related technology pieces that would eventually realize the goals of the problem space.
In the DSM parlance, this vocabulary is called a Meta-Model. Once a meta-model has been defined for the given problem space, the Business worker uses it to create actual models. Sophisticated code generation mechanisms which operate on the meta-model can be built to convert the models defined by the business worker into their corresponding code artifacts. DSM, thus, acts as an intermediate, bridging the gap between modeling and coding.
In typical cases, a number of models based on one or more meta-models reference each other to generate semantically valid code. In a non-DSM world, any significant change in the business process or the problem space would have an enormous impact on the written code. The first point of pain would be to make your developer understand the new changes and sit back and pray to your favorite Gods that he has actually understood them the right way. If he really did understand, the impact ranges from regression analysis, design changes, rewriting of test scripts to validating the changed application to its new requirements. If he didn’t, well, go back and pray again.
This complexity that underlies conventional mechanisms are overcome in the DSM scheme of things. In this case, a change in the problem space or requirements, would require the business user to modify the models and the references between them to reflect the new requirements. As the code generation mechanism understands the semantics of the model, it can automatically generate new code or update the existing code to reflect the new changes.
Thereby the time and effort you spend on impact analysis, coding and re-coding, and testing the changes are reduced to a considerable extent. The coupling and cohesion metrics of your code are controlled, standardized (and possibly benchmarked) as the code is generated based on known semantics of the meta-model. The meta-model itself can be refined to keep the complexity under control.
As the application evolves, and more models are added and more code is generated, similar mechanisms are adopted to ensure the overall complexity of the code is kept under a constant check. The idea of Software Factories can also be extended for enhancement of existing complex systems, which in turn results in maintaining the overall complexity of the system in a manageable state.
In the next post, I’ll discuss the role of DSM in managing a High Evolvement system.
