Spreadsheets are among the most widely used tools in systems engineering, especially for documenting system requirements and tests, and for supporting tasks like impact analysis, traceability management and project planning. We argue for the treatment of spreadsheets as models, in order to support the systems engineering lifecycle, and to provide a suitable migration path for organisations to follow in maturing their use of modelling techniques.
There have been a number of contributions made related to
integrating spreadsheets into an engineering process. Much
of this work focuses on using software engineering practices
to improve the quality of spreadsheets. This includes work
on bad smell detection and visualisation in spreadsheets
[
Early stages of engineering. MDE operates most e ciently on well-de ned languages (that do not change frequently, or at least, not in signi cant ways) and models with limited uncertainty. In the early stages of requirements engineering, the concepts of interest in our models may change frequently; they may be imprecisely de ned; and the languages that we use to express these concepts may need to evolve. MDE techniques may not be the most useful or appropriate in early stages. Natural language with some restrictions is widely used for early requirements engineering, as are tables of natural language requirements. These can easily be expressed using spreadsheets, which also enable traceability and (in later stages) requirements coverage analysis. Being able to treat spreadsheets as models thus enables de ning bridges between early stages of systems engineering, and later stages, where more precise languages are needed.
Support for legacy models. Industry uses spreadsheets, and many large organisations have legacy spreadsheets that can play critical roles, such as in project conguration and monitoring/measurement, requirements capture for product lines, etc. Being able to use such legacy spreadsheets as-is with new engineering processes, practices and tools makes it easier to change processes and practices while reducing risk of bad effects on the bottom line.
Tabular problems need tabular solutions. Some modelling problems are inherently tabular in nature, and bene t from being able to specify data (models) in columns and rows (with constraints amongst them) without requiring relational solutions. Speci cation of control laws, or parameters used to con gure product lines, simple requirements capture, and test suite speci cation are all problems that lend themselves to tabular speci cations, where spreadsheets can conceivably provide support. Providing MDE support for such idioms allows engineers who need to use such concepts to bene t from automated processing support.
Supporting existing skillsets. Not every organisation has, or can quickly acquire, expertise in MDE and model management. Most organisations do have expertise and skills with spreadsheets. Providing means for organisations to transition gradually to use of MDE and model management, and allowing those organisations to maximise the use of their current skillset, could reduce the risks associated with adopting MDE. Catching repeated errors. Substantial research has been carried out in MDE in terms of automated support for identifying and repairing repeated errors in modelling and model management. For example, updating models or evolving models after changes in a modelling language are problems for which good automated or semi-automated solutions exist. These are problems with spreadsheets as well (e.g., bad smell detection). By interfacing spreadsheets with MDE, it may be that spreadsheet users can exploit MDE solutions.
There are several plausible ways to interface spreadsheets and MDE.
Build injectors which generate models (with
metamodels) from spreadsheets, thus allowing MDE languages
and tools to be applied to spreadsheets indirectly.
Additionally, extractors from models to spreadsheets may
also be needed in order to return results to a form
amenable to processing by spreadsheet tools. In both
the injection and extraction, speci cation blow-up may
be an issue (i.e., encoding or decoding spreadsheets as
or from models may lead to less than optimal
spreadsheet or model sizes or structures).
formations, validation/constraint checking,
transformations, text generation. These would need to be
encoded using any scripting languages provided by a
spreadsheet tool. For example, for Google
Spreadsheets, these operations might be encoded using the
Spreadsheet Service3. However, such encodings would
need to be reimplemented for each spreadsheet tool.
Provide spreadsheet drivers for model management
tools, so that these tools can directly manipulate
spreadsheets like any other form of models. This is the
approach we have taken in Epsilon [
Spreadsheets are models: a less constrained and less expressive form of model than those permitted by full-blown MDE languages and tools. By treating spreadsheets as models, we can provide ways to bootstrap the MDE process, to enable automated and powerful tool support for legacy models, and a way to maximise use of current skillsets while personnel are educated in using MDE and model management techniques. Arguably, MDE and model management tools should support more model/data representation formats and techniques like spreadsheets, which allow more exible and less constrained styles of speci cation and design.
Provide equivalents of MDE and model management operations on spreadsheets, e.g., update-in-place trans3https://developers.google.com/apps-script/ reference/spreadsheet/