Process Driven Architecture: A Model Driven
Development Approach for Process Support Software
Sascha Müller
, Stefan Jablonski
and Matthias Faerber
Ansbach University of Applied Sciences, Residenzstr. 8, 91522 Ansbach, Germany
Chair of Applied Computer Science IV, University of Bayreuth
Universitätsstrasse 30, 95447 Bayreuth, Germany
Abstract. In this paper we propose a new model based development method
specialized on the efficient production of process support software, called the
Process Driven Architecture (PDA). It is based on our experiences in the do-
main of clinical process support and a comprehensive review of related model
driven software approaches, such as the OMG’s Model Driven Architecture
(MDA) or the Software Factories approach. The exemplary implementation of
a clinical process illustrates the feasibility of our PDA approach.
1 Supporting Clinical Research Processes
The clinical application domain has been a great challenge for information technol-
ogy solutions for decades [2][5][15][3] and is sometimes even considered as the “kil-
ler application” in the field of process support [5]. This estimation is based on the
high complexity of the medical domain [2][15], which results from multiple factors.
According to [2][4][14], these factors can be divided into two groups: technical and
socio organizational. One of the most challenging technical factors is flexibility with
respect to process modeling and execution [5]: process management must not restrict
physicians or nurses in their decisions about the next treatments to undertake, but
must silently assist and support decisions of the medical staff. A second major techni-
cal factor is fast adaptation to new requirements. Typical reasons for this are new
medical research findings and organizational or juridical amendments [16].
We have discussed in several publications that the above mentioned requirements
can be met using domain-specific process models [10] [12]. Due to their inherent
flexibility domain-specific process models require sophisticated tool support. This
starts with the modeling and ends with the execution of tailored domain-specific
processes. In order to cope with this challenging technological need we propose to
implement domain-specific process models according to the MDSD (Model Driven
Software Development) methodology [20]. This facilitates rapid provision of tools for
process modeling and execution that are tailored to specific application domains.
After a short introduction into MDSD (Section 2) we present our approach that is
called Process Driven Architecture (PDA, Section 3). Section 4 then exposes an ex-
ample from a clinical application implemented according to the PDA approach.
Müller S., Jablonski S. and Faerber M. (2007).
Process Driven Architecture: A Model Driven Development Approach for Process Support Software.
In Proceedings of the 3rd International Workshop on Model-Driven Enterprise Information Systems, pages 73-82
DOI: 10.5220/0002432000730082
2 Model Driven Software Development
The notion of MDSD comprises several software development approaches sharing
the same core idea: Efficiently develop software based on models using a domain-
specific modeling language (DSL). Our PDA approach is especially influenced by
two MDSD approaches: The Model Driven Architecture (MDA) and Software Facto-
ries (SF) [8].
The Object Management Group’s (OMG) MDA [19] is an industry standard for
the model driven development of software based on the MOF standard [18]. In con-
trast to the fuzzy definition of MDSD, the MDA standard is more concrete and pre-
scriptive. The main difference between the MDSD and the MDA can be summarized
by three observations:
Predefined development process: The MDA proposes a model driven software
development process with four layers of abstraction.
MOF compliant DSL: MDA requires the conformity of the DSL to the MOF.
Specification languages for transformation: The transformations between the
language layers must be described by standard languages (e.g. QVT).
One of the cornerstones of the MDA development process is that specifications on
the abstraction layers are completely based on models. However, these models not
just serve presentation purposes but represent code. In [KlWB03] the roles of these
models are characterized as “different abstraction levels in the system specification”.
With their concept of SF, Greenfield and Short [8] pick up the basic idea of McIl-
roy’s “component factory” [17], but move the emphasis away from the mass produc-
tion of software, which is not suitable for software development [1], to build-to-order
software development, i.e. the efficient development of a software product line (SPL).
The SF approach is divided into three stages [8]: First, the development of a SPL, i.e.
the tools, languages, patterns and frameworks needed for software development,
called the Software Factory Schema (SFS). Second, the configuration of the SPL, i.e.
the domain-specific adoption of the SFS, called the Software Factory Template
(SFT). Finally, during the Product Development, the application is developed using
the SFT.
Contrary to the MDA approach, the SF approach considers both the development
of a software development infrastructure and the domain-specific configuration of
this software development infrastructure.
3 The Process Driven Architecture
The Process Driven Architecture (PDA) is a comprehensive approach for the model
based development of process support software. It covers not only the application
development stage, but as well the method and tool development stage and the do-
main-specific customization stage. Yet, the PDA’s application development stage is
built upon the core concepts of the MDA. Section 3.1 exhibits the similarities and
differences of both methods. Section 3.2 then broadens the view of the development
of process support software. The last two sub-sections expand on the models of the
PDA (Section 3.3) and the transformation support offered by the PDA (Section 3.4).
3.1 The PDA as Adaptation of the MDA
The basic concepts of the MDA and the PDA are very similar: Starting with a rela-
tively coarse application / process model a detailed model of the application is de-
rived by stepwise refinement. The structural similarities become very obvious when
comparing the application development steps (Fig. 1). In the following paragraphs we
discuss common characteristics and differences of both approaches.
Fig. 1. The structural similarities of the MDA and the PDA Application Development.
Shift of Focus
The central idea of the MDA is to describe an arbitrary application by its data, func-
tions and necessary communication, i.e. by interacting objects. By contrast, the PDA
shifts the modeling focus to the processes as the fundamental elements of a (process-
oriented) application. Thus, the PDA is a sort of result of the logical merger of Busi-
ness Process Reengineering [9] and MDA.
Clear and Explicit Structures
An important advantage of the MDA is the definition of a clearly structured process
for application development. This is of utmost importance, as it allows for the devel-
opment of tools that may be applied for many kinds of MDA-based software devel-
opment projects. The PDA builds upon this experience by defining specific models
and transformations while keeping the same clear development process (Fig. 1).
Domain-specific Customizability
The MDA focuses on model based generation of object-oriented software. It is ge-
neric and adoptable to different application domains only to a restricted degree using
UML profiles or stereotypes. In contrary, the PDA inherently picks up the domain’s
requirements, as the domain-specific customization of the process modeling method,
tools and development environment is a prerequisite for the PDA’s application devel-
opment stage (Section 3.2). In contrary to the resulting lack of transformation support
between the application domain and the Computation Independent Model (CIM) and
the CIM and the Platform Independent Model (PIM) respectively, the PDA’s spe-
cialization allows for significantly improved transformation support (Section 3.4).
Domain-specific Language
The PDA offers a high degree of adaptability to an application domain, by using a
process modeling method that can be customized to make use of domain-specific
concepts. The combination of the domain-specific language and the paradigms of
process orientation enable the PDA to involve users much tighter in the application
development process. Compared to the MDA, the PDA’s domain-specific process
model is for the users much more intuitive and understandable than an object-oriented
representation of the process support system.
To summarize, the MDA is used for the development of arbitrary software sys-
tems whereas the PDA is used specifically for the development of process based
applications. In other words, the PDA application development stage might be re-
garded as a specialization of the MDA for process based software. The next section
deals with the prerequisites to allow for a domain-specific application development in
the PDA.
3.2 The PDA Development Approach
The PDA promotes a comprehensive development approach which covers not only
the application development, but also the prior development of adequate tools, meth-
odologies and necessary customizations. Accordingly, the overall PDA development
process is divided into three stages (cf. Fig. 2): Tool & Method Development, Cus-
tomizing and Application Development.
During the first stage the basic process modeling methodology, e.g. the perspective
oriented process modeling method [11], and associated tools are developed. This is
done in three steps: First, a method developer, typically embodied by an industrial
consortium (e.g. the OMG) or a research group, designs a process modeling method
(cf. Fig. 2, n). Second, software developers create specialized tools to be able to
efficiently perform modeling tasks using the new process modeling method (cf. Fig.
2, o). Finally, an execution environment is developed that can implement processes
modeled using the newly designed method (cf. Fig. 2, p). The Tool & Method De-
velopment stage is generic by nature, as it is independent from any application do-
main and the results.
The second stage of the PDA approach adopts the results of the first stage to a
certain application domain, e.g. the clinical field of application. Yet, it is still inde-
pendent of a concrete application process and thus belongs to the infrastructure de-
velopment. The Customization stage is split into three steps, as well: In the first step,
the process modeling method is customized to the application domain (cf. Fig. 2, q).
Typically this involves the cooperative design of modeling artifacts that adhere to the
terminology of the application domain. Actually, a new idiom of the modeling lan-
guage, called the domain-specific language (DSL)
[21], is created that serves as a
communication basis between the domain experts and the application developers.
This step is critical to many model driven software development approaches [20] and
thus has to be performed in close cooperation between experienced domain experts
and application developers. The newly introduced modeling artifacts and all other
modifications of the modeling methodology subsequently have to be reflected in the
modeling tools (cf. Fig. 2, r). The application developer is responsible to configure
the tools accordingly. It is important to note that this step also comprises the provi-
sion and preparation of other required tools like wrappers, mediators or middleware.
The process execution environment has to be customized to fit into the application
domain, as well (cf. Fig. 2, s). The necessary actions at this step range from the
installation of basic infrastructure such as a web server or a database system to the
provision of network access to required information systems, such as a hospital in-
formation system. At the end of the Customization stage all tools and the modeling
methodology are fitted to the intended application domain, i.e. the development infra-
structure is ready to be used for the “production” of process-oriented applications.
Fig. 2. The multi layered PDA approach.
For every process that is to be supported, only the application development stage
has to be passed. Three steps constitute the PDA application development: At first, a
domain-specific model of the process to support is drafted cooperatively by the do-
main experts, e.g. the medical personnel, and the application developers (cf. Fig. 2,
t). This step is of utmost importance for the quality of the resulting process support
application and has to be done very carefully. Exactly at this point, a model based
approach like the PDA offers significant advantages regarding the development effi-
ciency, as it allows for rapid application development and immediate user feedback.
This ability to semi-automatically generate an application directly results from the
comprehensive efforts during the Customization stage. Right after the domain-
Often a graphical DSL is also referred to as domain-specific modeling language (DSML)
specific process modeling is finished, the application developer takes care of system
specific adoptions and enrichments of the process model by simply wiring the previ-
ously configured and prepared tools with the elements in the process model (cf. Fig.
2, u). All actions that have to be taken after this step may be automated and do not
need any further human interaction if prepared well during the Customization stage.
The last application development step comprises the generation, compilation and
deployment of the application (cf. Fig. 2, v). What steps are exactly necessary de-
pends on what kind of process execution environment was selected, i.e. the genera-
tion of software is treated differently than the deployment of a workflow in a Work-
flow Management System. Respectively, the degree of manual intervention strongly
depends on the specific situation, especially if a well organized test and release cycle
is followed. The Application Development stage results in an executable process-
oriented application.
3.3 Models of the PDA
During the execution of the Application Development stage three types of models are
used: the domain-specific process model, the system-specific process model and the
platform-specific model. Two more representations are relevant for application de-
velopment: the description of the application domain and the resulting application.
Application Domain Description
The starting point of the PDA is a detailed description of the application domain. The
PDA Application Development stage requires a process-oriented description, i.e. the
process that is to be supported must be documented in any way and the users should
be accustomed to it. In our clinical application domain medical guidelines or clinical
pathways are common.
Domain-Specific Process Model
The domain-specific process model is created according to a comprehensive process
analysis of the application domain. The transformation between the application do-
main description and the domain-specific process model hast to be done manually by
the application developer and the domain expert. It is the first step towards a machine
readable representation of the process and serves as communication basis between the
application developer, the domain experts and the users. The domain-specific model-
ing artifacts (the DSL) created during the Customization stage are used to record the
process model, this allows for a tight integration of the users.
At this level the model is not detailed enough to be executed, but it contains all re-
levant information of the application domain to correctly and comprehensively de-
scribe the process.
System Specific Process Model
The system specific model contains all details necessary to automatically generate the
platform-specific model. The application developer is responsible to enrich the do-
main-specific model with the necessary technical details, e.g. where the used data is
stored. Typically this is done by specifying missing attribute values or adding special
modeling artifacts.
The professional content of the process model must not be changed at this level;
only system-specific changes may be performed. After the system-specific model is
complete, all following transformations are performed automatically.
Fig. 3. The models of the PDA Application Development Stage.
Platform-Specific Model
The platform-specific model is tightly connected to the used process execution plat-
form and thus cannot be used for a different execution platform. It is no longer human
readable, and it is stored in a format that is perfectly suited for the following code
generation steps. As the lack of the term “process” in the name of this model implies,
the process is no longer “visible” in this representation, i.e. an object-oriented model
might be used to describe the process support software to be generated.
The software that transforms the system-specific process model in the platform-
specific model typically inserts modeling artifacts in the model, that are very specific
for the execution platform, such as artifacts needed to generate the user interface or
code to access subsystems like a database. The platform-specific model is subse-
quently transformed into a representation that is suitable to support the user during
process execution, e.g. the application is compiled and then deployed.
The application is the result of the PDA Application Development stage and supports
the process, exactly as previously modeled in the domain-specific process model.
How this is done, depends of the chosen process execution platform, e.g. it might be
deployed as a web based application.
To convert one model to the next, model transformations have to be applied. The
overall quality of the generated process support application directly depends on the
quality of these transformations (Section 3.4).
3.4 Supporting Transformations: The PDA Toolkits
In order to offer optimal support for the mission critical model transformations the
PDA introduces the concept of so called “toolkits”. Three toolkits are used in the
PDA Application Development Stage (Fig. 1): the Method-specific, the System-
specific and the Platform-specific toolkit. The toolkits are the result of the Customiza-
tion stage and offer the application developer and the domain expert a specific collec-
tion of methods, procedures, modeling artifacts, tools to perform the transformation
effectively and efficiently. A toolkit does not contain a fixed set of methods or tools;
rather it might be regarded as (formal or informal) domain-specific knowledge that is
to be applied during the transformation. Thus, the existence of a toolkit does not nec-
essarily imply the possibility to automate a transformation. Yet, the availability of the
Method-specific and the System-specific toolkit are a significant advantage of the
The concrete content of the PDA’s toolkits cannot be specified in advance, as the
contents heavily depend on the project context and are developed during the Cus-
tomization stage. Nevertheless, the following exemplary lists of typical contents,
derived from our experience, give a brief impression of the PDA’s toolkits:
Domain-specific toolkit
o Domain-specific modeling artifacts (e.g. the artifact to represent a clinical
checklist or an evidence based medical decision)
o Domain-specific modeling conventions (e.g. "medical decisions are always
modeled using the artifact for an evidence based medical decision")
o Modeling handbook (e.g. an introduction on how to apply the used process
modeling method in the project, modeling conventions)
System-specific toolkit
o System-specific modeling artifacts (e.g. a representation of the used medical
examination tools)
o Configurations of used software tools (e.g. configuration files, parameters,
o System-specific modeling conventions (e.g. "every process can only have one
entering data flow")
o Rule sets to allow for automated model checking (e.g. "the definition of data
containers must not be recursive")
Platform-specific Toolkit
o Mediators and wrappers (e.g. to connect to external applications, medical ex-
amination tools, data source, etc.)
o Installed and configured process execution environment (e.g. an installed and
usable workflow management system)
o Code generation templates and deployment descriptors (e.g. templates for web
pages to be generated)
As soon as the toolkits are defined the PDA Application Development stage can be
initiated. For the clinical projects (cf. Section 1), a model based software generation
and process execution environment has been developed, called i>ProcessExecution
(i>PE). The next section highlights its usage for a glaucoma screening process.
4 Example: The A4 Glaucoma Screening Process
After having designed the system specific process model, the manual work steps are
completed and an executable application can be generated in three steps: First, the
process model is exported as an XML document. This export is then used as input for
the i>PE compiler and is transformed into a deployable module. During the compiler
run, the system specific process model is split up again into the domain-specific part,
which is responsible for the core business logic and the system specific part, which is
responsible for connections to other systems. In a final step the executable module,
here a web application, can be deployed in an application server and made available
to the medical staff.
Fig. 4. Transformation of a Process Model into an executable application.
As a short example, we will discuss an application that is used at the ophthalmic de-
partment of the University of Erlangen for a glaucoma screening examination. This
screening process is described in detail in [13], hence we will omit details here.
In Fig. 4 a small part of this screening process is shown. This process describes
the work steps that have to be performed after all medical data has been collected and
the patient’s data has to be reviewed by a physician. All data that is relevant to assess
the patient’s eye (e.g. patient’s medical history or images taken in previous work
steps) have to be presented to the physician.
Each process step (n) in the process model is mapped to a separate web page
(e.g. "Review Patient Data"). The process’s input data is transformed into elements of
the web page (o). In the example above, the patient’s medical history together with
the image from one the medical device are displayed. For all output data (i.e. data that
is generated in the process step), empty fields are generated (p).
5 Conclusion
The PDA is a process model driven software development approach that describes
how to efficiently and effectively create process-oriented software. It combines the
advantages of the structured application development process of the MDA with the
holistic understanding of software development as promoted by other model driven
approaches (e.g. SF) and enriches it with the specific concepts of process modeling.
1. Aaen, I.; Bøttcher, P.; Mathiassen, L.: The Software Factory: Contributions and Illusions.
In: Proceedings of the Twentieth Information Systems Research Seminar in Scandinavia,
Oslo, (1997).
2. Anderson, J. G.: Clearing the way for physicians’ use of clinical information systems. In:
Communications of the ACM, 40(8) (1997) 83-90.
3. Berg, M, & Toussaint, P.: The mantra of modeling and the forgotten powers of paper: a
sociotechnical view on the development of process-oriented ICT in health care. In: Interna-
tional Journal of Medical Informatics 69, Elsevier (2003).
4. Berg, M.: Patient care information systems and health care work: a sociotechnical ap-
proach. In: Int J Med Inf 1999 (55), Elsevier, (1999) 87-101.
5. Dadam, P., Reichert, M., & Kuhn, K.: Clinical Workflows - The Killer Application for
Processoriented Information Systems? In: Abramowicz, W.; Orlowska, M.E. (Eds.): BIS -
Proc. of the 4
Int'l Conference on Business Information Systems, Poznan, Poland,
Springer, (2000) 36-59.
6. Eisenecker, U. W.; Czarnecki, K.: Generative Programmierung, Addison-Wesley,
München, (2000)
7. Fowler, M.: Language Workbenches: The Killer-App for Domain Specific Languages?.
Online Article., retrieved 3/5/07.
8. Greenfield, J.; Short, K.: Software Factories: Assembling Applications with Patterns, Mod-
els Frameworks and Tools. Wiley, Indianapolis, (2004).
9. Hammer, M.; Champy, J.: Reengineering the Corporation: A Manifesto for Business Revo-
lution. Harper Collins Publishers Inc., New York, (2005).
10. Jablonski, S.: Process Based Data Logistics: Data Integration for Healthcare Applications.
In: Proceedings of the European Conference on eHealth (ECEH06), Fribourg, Switzerland,
11. Jablonski, S.; Bußler, C.: Workflow management - modeling concepts, architecture and
implementation. London. International Thomson Computer Press, (1996).
12. Jablonski, S.; Lay, R.; Meiler, C.; Müller, S.; Hümmer, W.: Data Logistics as a Means of
Integration in Healthcare Applications. Proc. of the 2005 ACM Symposium on Applied
Computing (SAC) - Special Track on Computer Applications in Health Care, Santa Fe,
New Mexico, (2005).
13. Jablonski, S.; Lay, R.; Müller, S.; Meiler, C.; Faerber, M.; Derhartunian, V.; Michelson,
G.: Building a Generic Platform for Medical Screening Applications based on Domain
Specific Modeling and Process Orientation. Proceedings Second International Workshop
on Data Integration in the Life Sciences (DILS 2005), LNBI 3615, 2005, San Diego,
(2005), 257-265
14. Kuhn, K.A., Giuse, D.A., Bakker, A.R., Ball, M.J., Gell, G.: Challenges in Deploying
Health Information Systems. In: Patel, V.L.; Rogers, R.; Haux, R. (eds): Medinfo 2001,
Proceedings 10th World Congress on Medical Informatics, (2001).
15. Lenz, R., Elstner, T., Siegele, H., Kuhn, K. A.: A Practical Approach to Process Support in
Health Information Systems. In: J Am Med Inform Assoc., 9(6), (2002) 571-585.
16. Lenz, R.; Kuhn, K. A.: Towards a continuous evolution and adaption of information sys-
tems in healthcare. In: I J Med Inf 73, Elsevier, (2004) 75-89.
17. McIlroy, M. D.: Mass-Produced Software Components. In: Buxton, J. M.; Naur, P.; Ran-
dell, B. (Eds.): Proc. of Software Engineering Concepts and Techniques, 1968 Nato Conf.
on Software Eng., (1969) 138–155.,
retrieved 3/5/07.
18. Object Management Group (OMG): Meta Object Facility (MOF), (2006)., retrieved 3/5/07.
19. Object Management Group (OMG): Model Driven Architecture (MDA), (2006)., retrieved 3/5/07.
20. Stahl, T.; Völter, M.: Modellgetriebene Softwareentwicklung. Techniken, Engineering,
Management. 1. Auflage 2005, dpunkt.verlag, Heidelberg, (2005).
21. van Deursen, A.; Klingt, P.; Visser, J.: Domain-Specific Languages: An Annotated Bibli-
ography. In: ACM SIGPLAN Notices, Vol. 35, Issue 6, (2000) 26–36.