Author:

Abstract:

Since the very beginning of software development there was an unstoppable demand for higher productivity, better quality and more complex software systems. If the problem to be solved by the software system has a high complexity, solving it will inevitably also be complex. This inherent complexity is often referred to as essential complexity. The way software is developed however also causes some complexity. Better software development processes and better software building techniques, for example (programming) languages, reduce this complexity. Lower expressiveness and less abstraction introduce unnecessary and avoidable challenges that is often referred to as accidental complexity.The goal of this work is to contribute to the reduction of accidental complexity of building software systems. Improvements on three different places in the development process are proposed:• Programming Patterns: properties and associations are typically accompanied with requirements restricting the values properties or objects an object can be associated with. Three different types of requirements are identified to facilitate the (re-)definition of requirements at different positions in the class hierarchy. Value Requirements restrict the values independent of the state of the object. State Requirements restrict allowed combinations of values of different properties and associations. Transition Requirements restrict transitions to new values in view of current values. A separation of concerns between the development of methods describing requirements and the methods describing the state changes is reached by encapsulating the description of the requirements in their own inspectors. A family of patterns describes how all methods describing the state and behavior of a property or association collaborate. Finally, a first step towards a language extension to avoid the technical code of the patterns is presented.• Behavioral Modeling: conceptual models introduce accidental complexity when they contain technical aspects in order to describe real-world facts. Such complexity is introduced by enforcing (“locking in”) decisions that should have been made in a later activity in the software development process. UML and OCL lack expressive constructs to reason about event occurrences, even more so when the historical aspect of such occurrences becomes important. This work presents a new operator, the #-operator, that allows analysts to treat events as first-class citizens. By assigning a property, that represents the execution time, to events, it becomes possible to model historical event information without the need to introduce irrelevant facts in the conceptual model. A conceptual model never describes the whole universe, but is always a description of a subset of real-world facts. The decision to model a given fact as an object or as an event depends on the selected subset of real-world facts. A guiding principle assists the analyst in his decision-making: if the lifetime of a fact is of importance then the fact should be modeled as an object. Otherwise, if the fact is instantaneous, the fact should be modeled as an event.• Transformations: generally, multiple languages are used during the development of a software system. Each language is formally defined by a metamodel. These metamodels serve as the basis to define transformations between the different models. Different metamodels mostly have common structural constructs and associated functionality: a framework offering constructs to build hierarchical composition structures is developed to avoid the need repeat this work over and over again. A distinction is made between parent/child relations to specify interdependencies and dependee/dependant relations to specify unidirectional dependencies. Next to these constructs, the framework offers a metamodel-independent transformation approach. The knowledge of how to transform concrete metamodel elements is decoupled from the managing algorithm. Developers of a transformation provide strategies to transform concrete model elements, while the framework is responsible for tasks as execution order, managing cross-model consistency, model validity,…