|
MDA Distilled. Principles of Model-Driven Architecture Authors: Mellor S. J., Scott K., Uhl A. Published year: 2003 Pages: 106-107/134 |
Working with Models-as-AssetsModels-as-assets change how we work as software developers. Just as thirty years ago, developers learned to relax, forget about register allocation, and love programming language compilers that conferred hardware-platform independence, so too will we learn to relax, forget about distribution, and love model compilers that confer independence from the software platform. We can therefore look forward to the day when software developers search the Web for reusable models that have the required functionality, and then combine those models with model compilers that deliver the appropriate performance for the event rates and data access patterns—which can, in turn , be combined with common infrastructure for the enterprise. Subset the models, add a little functionality perhaps, and away we go. The incremental cost will reside primarily in selecting the appropriate models and linking them together. The models themselves will need to be constructed , of course, but once they're complete, they will have greater longevity than code because they will evolve independently of other models. We developers will not hack out code, or even models. Rather, we will do the following:
When it comes time to change the application, we will make the changes in the application model, marks, or mapping functions, as appropriate, and leave the models of the implementation technologies alone. When we need to retarget an application to a different implementation environment, we will select the models for the new environment and regenerate. There will be no need to modify the application models. Costs will be lower; productivity will be higher, based on increased reuse of models; maintenance will be cheaper—and each new UML model that's built will become an asset that can be subsequently reused. Note that this vision is already a reality in the hardware world. Hardware designers already have online libraries where vendors offer designs for sale. These designs constitute valuable (and, controversially, protectable) intellectual property. |
Beyond UMLIn the best of all possible worlds , no one writes software any more. Instead, users, not developers, describe desired behavior formally using a language specific to their subject matter. Control engineers , for example, would use control diagrams, while manufacturing plant operators would describe the desired sequence of operations to be carried out in a visual language of their own devising. Accountants would think accounting; lawyers would think about, well, their fees. This vision does require users to have some abstraction capability. Just as today, such skills will likely be in short supply, but the level of the domain-specific language would be high enough that the semantic gap between domain concepts and the language would be low. This is not as farfetched as it sounds: Spreadsheets do just that. Such a future would make UML an unnecessary evil. Instead, subject-matter experts would work with domain-specific visual languages—tied in with the MDA infrastructure, of course— in which they themselves "program," relying on MDA infrastructure to deliver an implementation. Note that this moves away from MDA's focus on infrastructure. Once that infrastructure is constructed , the variability in subject matter will be much greater, and much more interesting, than variability in platforms (just as there are more frameworks and models than compilers today). In addition to the economy of scale that comes from the network effect, we also get an economy of scope due to the enormous number of model combination possibilities—plus the fact that a small model delta can be additively combined with all the other existing models, so that a relatively small input creates a great variety. This eventually enables mass customization. This is where system families play an important role in shifting the focus from thinking about platform independence to breaking up and scoping subject matters from application domains to achieve these economies of scope. Understandably, MDA currently focuses on getting the basic implementation technology standards done. However, systematic ways to scope and select domains, and to develop and manage domain-specific languages, will eventually be much more important. MDA inevitably enables a move in that direction. |
|
MDA Distilled. Principles of Model-Driven Architecture Authors: Mellor S. J., Scott K., Uhl A. Published year: 2003 Pages: 106-107/134 |