Model-driven development: the good, the bad, and the ugly
IBM Systems Journal - Model-driven software development
Model-Driven engineering in a large industrial context — motorola case study
MoDELS'05 Proceedings of the 8th international conference on Model Driven Engineering Languages and Systems
| Hi-index | 0.00 |
State machines can be comprehensively specified, simulated and validated at design time to get a formally founded skeleton for a software application. A direct implementation of state machines in Java source code can realize states as classes, transitions as methods and variables as well as pre-conditions and variable updates as auxilliary methods, invoking either arbitrary application methods to retrieve the current variable values or evaluating expressions [1]. Viewed from an abstract level, implementation and state machine are two models, sharing the same semantics. To maintain the modelled software systems, it is vitally important to perserve as much of this semantics as possible in the source code to be able to track back changes and errors [2,3]. In contrast to these considerations, current techniques of model-driven development use several unidirectional steps, starting from an abstract model and resulting in platfrom specific source code.