Formal Analysis of Multi-Dimensional Model Dependencies

Models are an indispensable tool for software development. They help developers curb system complexity; they also help the many stakeholders convey their concerns to other stakeholders in a manner that is understandable to both and that will ensure the proper treatment of those concerns. However, today, modeling focuses mostly on the contents of models - their insides - and not their connectedness (dependencies) to other models, requirements, and code. The latter is of vital important for understanding the collective meaning of models (analysis, impact of a change, validation and verification). Model dependencies are sometimes implicit in a modeling language but are often expressed explicitly via traceability links. These links are simple and herein lays the single biggest misperception in software modeling: dependencies among semantically rich models cannot actually be described via simple, independent links. Because of this misperception, the gaps between requirements, models, and code are bigger than ever and the most significant obstacle to model-driven development. The goal of this work is to understand the dependencies among models. Model dependencies may be semantically poor (compared to models and their contents) but such dependencies cannot be set arbitrarily - or else they risk violating the meaning and content of the models involved. The proposed work will build a well-defined, theoretic foundation for reasoning about model dependencies, by: 1) analyzing how the semantics (meaning) of models affect model dependencies 2) analyzing how dependencies among models affect dependencies among other models As there are n2 model dependencies among n models, we speak of n2 dimensions to be considered. Almost all current state of the art investigates these dimensions of model dependencies separately, which is weak. Herein lays the power of multi-dimensions reasoning on model dependencies: every dimension of model dependencies (among models, requirements, or code) describes another angle of the overarching traceability problem with implications onto model dependencies everywhere (a crosscutting problem). By integrating these model dependencies, this work will improve trace capture and maintenance. The direct practical implications of this proposed work are improved automation during trace capture and maintenance, higher quality of trace links, and less human intervention (n instead of n2 ). The indirect, more significant benefit of this proposed work is its fundamental role in integrating models and thus its vital support to model-driven software development. Not only software engineering benefits from this work but also other domains and disciplines where model-driven engineering is practiced.

There is more to software development than requirements and code. Developers routinely capture use cases and scenarios to describe workflows. Structural models (architectures, class diagrams) help developers break down complex tasks/systems in smaller, more manageable parts. State machines in turn describe the essential system behaviour. Today, developers use many models to help describe a software system and curb its complexity. The use of such models, however, also has a severe downside. Their very benefit, the separation of concerns, is also the foundation to their very problem. At the end, the separate models should make up a coherent software system. This is where traceability comes in. Traceabiliy describes how artifacts in different models are connected. Such traces are essential for software understanding, change management, error detection, and any forms of analysis. The lack thereof is recognized as a problem. This project developed a novel approach for capturing and validating traceability that addressed several shortcomings in current state of the art. First, traces are known to be error prone and this work was able to 1) recommend corrections to incorrect trace input or, when this was not possible, to 2) isolate incorrect trace input from the reasoning process. Second, traces are often not understood completely and this work was able to recommend missing traceability. Third, traceability is often ambiguous because developers often capture traceability at a later time. By then key people may have moved on or their recollection of facts may be blurred or inconsistent. Here, our work was able to provide a language for capturing traceability that allows for uncertainty and incompleteness in traceability while still able to reason correctly about their logical consequences. As an added bonus, this project also performed a study that investigated the usefulness of traceability. It should be noted that despite the growing popularity of traces and there apparent benefits, there exists no published evaluation about the usefulness of requirements traceability. Do the benefits of traceability justify their cost? After all, trace capture and maintenance is not free. Our study focused on real maintenance tasks across two projects and 71 developers. The result showed that subjects with traceability performed on average 24% faster on a given task and created on average 50% more correct solutions -- suggesting that traceability not only saves effort but can profoundly improve software maintenance quality.