Haupt-Inhalte der Seite
Model-Driven Software Development and eHF
When building any non-trivial software system, and especially when employing frameworks and external execution environments, you often end up writing a multitude of boilerplate code and configuration files, whose sole purpose is to integrate your application with other system components. This work is tedious, error-prone, and distracts you from the actual task at hand: understanding and implementing a complex health care solution.
What is MDSD
Model-driven software development (MDSD) is a paradigm that leverages the concept of abstraction to increase software development efficiency. Instead of writing large amounts of repetitive code, the developer can capture the core concepts of a software system in a more abstract form, namely that of a model. Automated transformation, generation, and sometimes interpretation of such a model creates a substantial part of the final software product, which is typically enhanced with manually coded fragments. The main idea is that you can gain time and increase quality by expressing parts of the software in a language that is better suited to the problem at hand than a general purpose programming language.
- From model to code
MDSD Concepts
The underlying concepts of model-driven software development can be explained with an analogy in the field of civil engineering: When creating a new building, an architect employs an appropriate (graphical) language to produce a blueprint (i.e. a model) of the building. He arranges the major features like walls and doors on a high level of abstraction and can ignore mundane details like bricks and mortar. He is, of course, constrained by the natural laws of physics and statics. Similarly, a software architect can express software as a model. He chooses (or even creates) an appropriate, high-level language to do this. This language can either be graphical or textual, or even both. The words and grammar of the language, together with a set of constraints define what can be created with this language, and what cannot. In software, however - and there the analogy ends -, these models can be transformed into running systems automatically. No manual labor to stack bricks and mortar is required.
Since it is typically neither feasible nor desirable to express the whole software system as an abstract model, you may have to provide additional code for various implementation details - which is equivalent to decorating your living room. The walls around you, however, are already there. The concepts that can be expressed by such a modeling language, called abstract syntax, are defined in a so-called metamodel. For civil engineering, the metamodel compriseswalls, doors, and windows, for example. The Java metamodel has concepts like classes, interfaces, and methods. Using a textual or graphical notation, called concrete syntax, you can create models, which are effectively instances of metamodels. A blueprint of the Empire State Building is a model in a graphical language. Java files on the filesystem are a a kind of textual model consisting of Java artifacts. Both abstract and concrete syntax together form a language. Languages targeted towards a specific purpose are called domain specific languages (DSLs), as opposed to general-purpose languages. In computer science, transformation, generation and interpretation techniques are usedto produce running systems out of language artifacts. The most typical transformation is the well-known compiler.
Just Another Compiler
From the explanation of the concepts above, it becomes fairly obvious that the software industry has been going along this path for several decades now. Low-level, general purpose languages are superseded by languages that provide a higher level of abstraction. While computer pioneers had to deal with computer instruction code and processor registers, today's software engineers work with logical control structures and virtual memory allocation - while at the same time giving up direct control of the hardware they are working on.
Model-driven software development takes this evolution one step further. It provides tools and frameworks that facilitate the creation and tailoring of languages that operate on the most appropriate level of abstraction for whichever problem is at hand. It also provides tools and frameworks that facilitate the creation and tailoring of editors, transformers, and generators for such languages. These integrate themselves into the regular software development lifecycle, and in many ways, working with an MDSD toolchain is not so much different from working with a "classical" toolchain. From a developer's point of view, it is just another compiler, taking source artifacts and producing output artifacts. It's just the artifacts that are different.
- MDSD is similar to a compiler
eHF uses an Architecture-centric MDSD Approach
In the eHealth Framework (eHF), a module typically revolves around a domain model. This model captures the essence of a module's business assets: its data structures, interrelations, validation rules, service exposure guidelines, and more. This model manifests itself in various forms at many different places in a module's implementation.
eHF uses an architecture-centric MDSD approach to help developers create eHF modules. Taking the domain model as input, the eHF Generator creates Java classes, Spring configuration files, and other artifacts required to fit a module into the overall eHF architecture. This approach is architecture-centric as the developer concentrates primarily on the domain model and business logic, while most architecture-related artifacts are taken care of by the generator. Apart from the obvious benefit of relieving the developer of hours of error-prone, repetitive coding tasks, this also ensures a consistent architecture throughout
all eHF modules.
The domain model itself is conceptually very close to a Java class model, and UML2 captures most of the required concepts. Actually, UML2, being a general purpose language, covers much more than the required concepts. For that reason, UML2 in combination with a custom UML2 Profile and a set of constraints is employed to create a Domain Specific Language (DSL) tailored to the eHF.