Linking models and their storage artifacts

Bernhard Rumpe, Robert France
2011 Journal of Software and Systems Modeling  
Many developers working on model-based development projects experience a problem that highlights the need for better model management technologies. If someone wants to adapt an OO class that was generated from a model, the first thing is to locate the "sources" used to generate the class (i.e., the model elements used to produce the class implementation). This turned out to be a surprisingly difficult and timeconsuming task. It is worth shedding some light on why this task typically is
more » ... if only to remind us that research on software modeling needs to extend its focus to include model management issues if we are to see more widespread adoption of software-modeling approaches. The problem of locating code generation sources can be traced to inadequate support for managing stored representations (artifacts) of models. Models need to be stored in a manner that supports convenient and efficient retrieval of model elements by both humans and software. This is particularly important when a system is modeled using multiple notations or languages; the need to check consistency across the different modeling views in these systems requires efficient model element retrieval mechanisms. Current modeling tools handle different modeling views of a system by integrating them into a single, integrated artifact that is stored in a database, a file or even in CPU storage. This monolithic approach has a number of drawbacks, including: (1) Poor support for exploratory modeling in a team development environment: If modelers want to explore B. Rumpe (B) RWTH Aachen, alternative ways of modeling an aspect of a system, possibly with known inconsistencies with other parts of the model, they must integrate their models with the shared model, and thus risk jeopardizing the work of team members working on other parts of the system model. (2) Poor support for separation of parts: Modeling subprojects with clearly specified interfaces are not easily defined. Thus, parallel model development opportunities can be missed in early development phases. (3) Poor support for version control: Version control technologies are considerably hampered by the shortcomings mentioned above. (4) Poor support for incremental and thus efficient, agile code generation: Supporting code generation mechanisms tend to be implemented as a monolithic process, in which changes to a model typically requires that the code generation process be run using the entire model as an input. Simply put, existing support for monolithic integrated internal representations of models may be adequate for some single person or small team development environments, but they fall short when used in environments in which different aspects of a system are modeled in parallel by different team members. Instead of one big, integrated artifact containing every piece of information captured in different modeling views, it is better to have clear and dedicated small modeling languages, that allow modelers to create comprehensible models dedicated to specific purposes. These models should have clearly defined relationships with the storage artifacts that persist the models. Also a set of models needs clear forms of how the models consistently "fit together": i.e. how information captured by model elements is "transported" across models and used in importing models. These relationships 123
doi:10.1007/s10270-011-0208-x fatcat:kcskxsmmkbdqri72puo3bjp2yu