LAYERED PROCESS MODELS
Analysis and Implementation (using MDA Principles)
Samia Oussena
Thames Valley University, London, U.K.
Balbir S. Barn
Middlesex University, London, U.K.
Keywords: Model-Driven Architecture, Service-Oriented architecture SOA, Business Process modelling notation
BPMN.
Abstract: One of the key challenges of Service-oriented architecture (SOA) is to build applications, services and
processes that truly meet business requirements. Model-Driven Architecture (MDA) promotes the creation
of models and code through model transformation. We argue in this paper that the same principle can be
used to drive the development of SOA applications, using a Business Process Modelling (BPM) approach,
supported by Business Process Modelling Notation (BPMN). We present an approach that allows the SOA
application to be aligned with the business requirements, by offering guidelines for a systematic
transformation of a business process model from requirements analysis into a working implementation.
1 INTRODUCTION
The challenges of developing distributed enterprise
systems such as large development teams, complex
technology and changing business requirements
have the potential of being addressed by the
convergence of three key areas of technical
developments: Service oriented architecture; Model
driven architecture and Business process
management. Soley and Watson (2008) raise the
same point at a key note address at the 19th
conference on Australian Conference on Software
Engineering where they articulated the role of MDA
as a bridge between SOA and BPM.
Service oriented architecture (SOA) has gained
much attention as a unifying technical architecture
and has been concretely realised with web service
technologies (Erl, 2005). SOA promotes the
building, deploying and integrating of services
independently of any specific application and the
computing platform on which they run. Such
services generally observe characteristics such as
being individually useful or can composed to
provide higher level services thus promoting re-
usability. Services also communicate with each other
or clients via the exchange of messages and may be
part of a workflow application within the
organization. As well as a technological imperative,
SOA demands a wider organizational re-think to
understand what impact such an architectural
approach requires on solutions and their design,
what it means to assemble them from composable
services and how applications are deployed and
managed.
Modelling in general is viewed as a capstone of
many software engineering approaches where it is
used to as an approach to user requirements
definition and as a basis for developing information
systems to meet those requirements (Moody 2005).
Models provide a vehicle for explaining and sharing
understanding of complex problems and provide
capabilities for different views of the underlying
problem at different levels of abstraction. Model
driven architecture takes this premise further by
providing an overarching conceptual structure for
using and applying transformations to models in a
structured and controlled manner in all stages of the
software engineering development process. The
Object Management Group (OMG) provides a set of
standards to express models and model-model
transformation and has been leading industry
168
Oussena S. and S. Barn B. (2009).
LAYERED PROCESS MODELS - Analysis and Implementation (using MDA Principles).
In Proceedings of the 11th International Conference on Enterprise Information Systems - Information Systems Analysis and Specification, pages
168-175
DOI: 10.5220/0001995601680175
Copyright
c
SciTePress
initiatives in the promotion of technologies, methods
and standards under the banner of model driven
architecture (MDA). There are three key guiding
principles for MDA which are relevant to this paper:
Models expressed in a well defined language
(notation and semantics) are critical for
understanding system requirements and solutions.
Systems can be organised and built around a
coordinated set of models and transformations
between models. Models and their modelling
languages can be formally described using
metamodels to enable model interchange, integration
and automation by tools.
Separately but connected to the developments in
SOA and MDA, business process modelling is
experiencing a resurgence of activity. A new wave
of business process modelling initiatives (Smith and
Fingar, 2003) involves the return to business process
modelling where organizations will rapidly adapt a
business process to address a new need, measure the
performance of the new business process and then
make further changes to the business process to
optimize the performance of the process – Business
Process Management (BPM). In order to make this
happen, important technologies needed to be in
place. These technologies enable processes to be
designed, implemented executed and evaluated
(from a performance perspective) and then changed
in real time on business management servers. A key
aspect is thus the notion of a model (discussed
above), that is, the process definition (and thereby its
documentation) and its execution specification.
BPM technical infrastructure includes: standards for
notations for business process modelling, standards
for translation of models into executable languages
and the building of systems from multiple process
definitions (Delphi 2003).
The last two years have seen the OMG – authors
of the Unified Modelling Language (UML) –
publish the Business Process Modelling Notation
BPMN standard (BPMN, 2006) which includes
mappings to the execution language Business
Process Execution Language for Web Services.
BPEL4WS. At the same time, there has been the
emergence of a new form of toolset – BPM tools
that are model based and allow a process to be taken
from analysis through to execution in a single
environment. Therefore, BPMN with a supporting
toolset provides a bridge between business-oriented
process modelling notation and an IT-oriented
execution language. It allows the modelling to
encompass both system and human activities. It
provides the notation for the modelling of the
business flow and web service interaction.
2 RELATED WORK
A comprehensive literature review is outside the
scope of this paper instead our primary focus on the
work that links the three areas of SOA, MDA and
BPM in some way.
Zhang and Jiang have taken an MDA approach
to workflow based applications (Zhang and Jiang,
2008). Like the approach described in this paper
they distinguish between models for analysis
requirements and those models for implementation.
Their target implementation models are based on the
use of BPEL while their analysis models utilise a
specially developed UML 2.0 profile for business
modelling. They provide transformation mappings
from their business models to BPEL. A key
difference between our two approaches is that while
we share a conceptual framework based on MDA
principles we place greater importance on the role of
a standard such as BPMN and transformations
pertaining to that standard. Murzek at al (2006)
present a categorisation of different model
transformation scenarios which include model
integration, model translation and model
synchronization. In contrast to the algorithmic
approach adopted in this paper, workflow patterns at
the domain level are used to support the
transformation types. Brown et al describe a
software development approach to application
design using service oriented architecture principles
coupled with MDA tool support (Brown et al 2006).
They emphasise the importance of utilising such
technologies in the context of business architecture
(process driven) as response to more recent criticism
that MDA has failed to deliver. Huang and Fan
propose an approach to enterprise integration where
MDA is the philosophy of system development and
SOA is the infrastructure of system implementation
(Huang and Fan, 2007). This approach shares some
similarity with the approach described here but a
missing component is the role of BPM as a bridging
mechanism between SOA and MDA. Thomas and
Leyking present a rationalisation of the importance
of business process management and how process
models can be used to design and implement service
oriented architectures (Thomas and Leyking 2008).
Their approach provides a discussion of event
process chains, BPMN and BPEL. Their approach
however is not contextualised in a MDA framework.
Other relevant work is Zdun et al’s discussion on
modelling process driven service oriented
architectures (Zadun et al, 2007). As part of their
problem statement they comment:
“Process-driven SOA models are hard to understand and be
LAYERED PROCESS MODELS - Analysis and Implementation (using MDA Principles)
169
kept consistent because many different kinds of models are
relevant for a SOA and only loosely interconnected.
Model-driven development of process-driven SOAs is not yet
well supported because there are no precise modelling
approaches and model-driven development tools that are focusing
on the domain of process-driven SOA in general.” (page 4: Zdun
et al 2007)
This echoes the challenges identified and
partially addressed in this paper. The BPMN area
raises issues specific to that domain. Research has
largely focused on the notation and its efficacy. In
particular the expressiveness of BPMN was subject
to an examination by Recker et al (2006).The
notation set was reviewed from perspectives of
construct deficits (lack of notation support for
modelling requirement, construct excesses (notations
which may not be needed) and construct overloads
(notation for which there are multiple meanings).
While the research indicated that not all theoretical
problems were seen as critical, some issues
identified by the research were a lack of business
rules, a lack of a structuring capability, and
ambiguity around the definitions of Lane and Pool
constructs.
In summary, the convergence of SOA, MDA and
BPM presents an opportunity for organizations to
develop an IT strategy that will allow them to
respond to changing business requirements in a
structured and coherent manner. However, the
literature would indicate that there a number of key
challenges that must be addressed.
2.1 Motivation, Research Question and
Contribution of this Paper
Historically, business process models have been
developed by less IT-oriented, more business-
focussed people, and have been technically
separated from the processes representations
required by the implementation and the execution of
these processes. There has therefore been the need to
manually translate the original business process
model to the execution model. Such translations are
subject to errors due to a lack of continuity in the
development process and the lack of a framework
for managing model transformation in an organised
and systematic fashion. The lack of an end-to-end
approach also makes it difficult to understand the
evolution of the original process model and
traceability of model transformations.
The question that we are trying to address in this
paper is thus: Is it possible to articulate a
transformation of the business process model that
follows an MDA approach? Deconstructing
further: can we provide a systematic transformation
of an analysis process model to an implementation
process model?
This paper discusses an approach to providing
transformations from the initial analysis process
(business-oriented model) to the execution process
(implementation-oriented model). We present a
method that provides the transition between the tasks
of the business processes definition and the
operational systems that implement the capability, in
turn aligning the development of web services with
the business needs. The remainder of this paper is
structured as follows: The next section (3)
introduces key concepts underpinning the paper.
Section 4 presents the research approach and the
details of the case study supporting the development
work. Section 5 describes the model transformation
algorithm that supports the transformation of an
analysis process model to an implementation process
model. The algorithm is illustrated by examples of
transformations from the process models
development for case study. Section 6 concludes the
paper and outlines further intended work.
3 BACKGROUND CONCEPTS
Here we briefly introduce the main modelling
concepts to enable sufficient understanding the
remainder of this paper. BPMN is a standard for
modelling business process flows and web service
interaction. It comprises one diagram a
corresponding notation set. The diagram and its
modelling language include four core modelling
elements: activities, events, gateways and
connectors:
An activity is an action that is performed within
a business process. Activities can be either an
atomic or non-atomic part of a process model.
These are depicted in a BPMN diagram as either
sub-processes or tasks. Activities may be
performed once only, or can have internally
defined loops. A task is an atomic activity that
is included within a process, whereas a sub-
process enables hierarchical process
development. At the implementation level, it is
used more in the context of having different
scope – access rights – to the process variables.
Sub-processes represent compound activities
within the process.
An Event is something that “happens” during
the course of a business process. These Events
affect the flow of the Process and usually have a
trigger or a result. They can start, interrupt, or
ICEIS 2009 - International Conference on Enterprise Information Systems
170
end the flow. There are multiple types of events
for starting, interrupting and end events.
The flow of control between each activity is
depicted by sequence flow. Business decisions
and branching of flows are modelled using
gateways. Gateways are the modelling elements
that are used to control how sequence flows
interact as they converge and diverge within a
process.
Connectors are of three kinds:
A Sequence Flow is used to show the order
that activities will be performed in a
Process
A Message Flow is used to show the flow
of messages between two entities that are
prepared to send and receive them
An Association is used to associate data,
information and artefacts with flow objects
This notation is simple enough to be used by
business analysts in dialogue with users and rich
enough to support programming level semantics.
The challenge is to provide a mechanism for a
controlled transformation from one use to another.
3.1 Model Views
Before looking at the transformation, let’s look at
each of the views. The objective of the business
view (analysis process model) is to understand the
“as is” or “to be” process at a high level. Thus we
are concerned with: the ordering of tasks (flow), the
roles responsible for the tasks and the objects
affected by the tasks. At this stage, we are concerned
with producing models that are manageable and
readable by primarily business analysts. How a
process may be translated into an executable model
is not of concern. Such a model is tagged in MDA as
a Computation Independent Model (CIM) and a
Platform Independent Model. (PIM)
The implementation business process model extends
the business analysis model with additional focus on
the detail of the use of services and user interactions
for the process. The model may represent a process
that is composed of a set of external services (web
services, user tasks, or other processes) and specify
the exact order of activities and input and output
messages and their data formats. Issues of
parallelism, call-backs are also addressed. The main
interests at this level are: Describing the logic of
business processes through composition of services;
the services could be: web service, user task or other
processes; Invoking web service operations; Waiting
for the client (the service) to invoke the process
through sending messages (receiving a request);
Manipulating data variables; Combining basic
activities by using structures such as (sequence,
branches and loops); Structuring processes into
several scopes or sub processes; Handling message-
related and time related event and creating
compensation activities in case of failure.
4 APPROACH TAKEN
The work described in this paper refers to and
follows from earlier work on process modelling,
service oriented architecture and associated
methodologies. Thus the research approach follows
a conjunction of a number of research methods.
Firstly the approach draws upon principles of action
research, in that we are attempting to integrate
theory and practice by a process of experimentation,
reflection and iteration (Lau, 1997). The second
research method adopted is that of case study
research as there are several examples in IS research
providing evidence that case study based
methodologies are well suited for exploring business
processes in an organizational setting (Huang et al,
2005). We also felt it was important to provide
experimental data that was derived from the
implementation of the case study business process
using a BPMN toolset. We chose to implement our
case study process using the Intalio Designer
Community Edition (Intalio, 2008). This version
provides full expressive model based capability to
produce BPMN diagrams which can be executed
provided enough model based information is
entered. The toolset includes a server for executing
workflows of a specified process. A full description
of the toolset is outside the scope of this paper.
The work described in this paper is derived from
the Cova project [http://cova.tvu.ac.uk/] which aims
at evaluating the use of BPMN in a Higher
Education (HE) context. This project built on
research from a previous project: COVARM
[http://covarm.tvu.ac.uk/].
The objective of COVARM was to develop a
reference model for course validation in HE (Barn et
al, 2006) – that is the design of a new course where
the primary output of the process is a course
specification – a description of a new course.
The COVARM project took a business process
based approach to analysing the problem space and
developed four case studies of the course validation
processes in different institutions. These processes
were synthesized into a single canonical reference
LAYERED PROCESS MODELS - Analysis and Implementation (using MDA Principles)
171
process which was then used in subsequent
development. This process required both computer
and human interaction. COVARM went on to
develop two technical scenarios for the canonical
process:
1. The preparation of a proposal for a new
programme and;
2. The organising of a validation event.
The scenarios were implemented as WSDL
services and choreographed using the Business
Process Execution Language (BPEL). In the COVA
project, we modelled and implemented these two
scenarios in BPMN using a BPM toolset. We used
existing services developed for COVARM, and
developed new services when required.
Process design in higher education has relevance
to the wider community. The course design process
is a core business process and as such it has parallels
to product design processes in industry. Further
because of the complexity and longevity of the
process multiple functional areas (roles) are
involved in activities within the process. Issues of
transactional completeness, appropriate management
of delays are thus similar to that found in industry.
5 RESULTS AND EVALUATION
This section describes the transformation algorithm
that maps the analysis process model into a platform
specific implementation model. Two examples are
used to illustrate aspects of the algorithm.
5.1 The Transformation Approach
The transformation algorithm is applied to the
analysis process model. Currently the algorithm is
implemented manually. As shown in Fig 1. Each
task (BPMN activity) is treated to the “Map_task”
algorithm.
Taking the tasks identified in the business view,
we apply an iterative process to each task. In
overview, the map task function uses the
input/output data (based on the modelled data flows)
to determine the data type schemas. An attempt to
stereotype (classified) each task is carried on. If a
task can be stereotyped it can then be mapped into
an implementation model task element. Otherwise, it
is decomposed into sub tasks or sub processes,
depending on the data.
Figure 1: Transformation Algorithm.
5.1.1 Identifying Task Data
The identification of the data input(s) and output(s)
for a task can be determined by its relation to other
tasks within the process. Data flow should already
be modelled at an abstract level within the business
view. Further analysis of the input(s) and output(s)
for the task will inform data type schemas, and the
next stage of the process: stereotyping the task. In
this activity the analyst will define each input and
output either in terms of primitive or complex types.
The complex type is then compared to a service
message schema or checked if it is at the level that
can be presented to a user. If this is not the case, it
will then require further decomposition.
5.1.2 Stereotyping Tasks
In UML, a stereotype is used to refine the meaning
of a model element or used to describe a model
element that can differ in meaning or usage from
another element (UML, 2007). Similarly, we use
stereotype to categorise a task in a business process
model of being of a certain type. We stereotype
tasks in a business process as being either:
User Tasks (tasks requiring human interaction,
most usually implemented with forms in a
workflow application)
Service Tasks (tasks that require the invocation
of a method on an external service, such as a
web service)
Data Manipulation Tasks (tasks where data is
manipulated internally within the process)
ICEIS 2009 - International Conference on Enterprise Information Systems
172
Data Manipulation tasks can be treated in the same
way as Service Tasks, the difference being that calls
to methods internal to the process are used instead of
calls to external service methods.
If a task can take the defined input(s) and return
the defined output(s) while employing only one
instance of one of these stereotypes, the task is at the
correct level of granularity for implementation.
It may be the case that a task requires a number
of instances of one stereotyped task, or a mixture of
stereotypes, in which case the task must be
decomposed.
5.1.3 Decomposing Tasks
A task can be decomposed into stereotyped tasks by
inspection of data flow requirements. It should be
the case that a sub-task (task-within-the-task) is
required when data is manipulated, altered or
introduced, and when a stereotype is identified.
Once these sub-tasks have been identified, the
recursive process starts again with each sub-task.
Decomposing a task can results in either:
sequence/parallel set of sub tasks; sub tasks included
in a sub process or sub tasks included in a loop sub
process.
It is desirable that tasks are decomposed into a
set of parallel tasks unless there are constraints such
as the input from one subtask need to be used by
another subtask; in which case the decomposition
results in a sequence of subtasks. Sub processes are
used when data is required to be isolated or a
subtask requires compensation. In case the data is an
array of values, the decomposition will be a loop sub
process.
5.2 Examples of Implementing a
Layered Process Model
In this section we describe two examples of refining
the business view of a process model into an
implementation view.
The first example is a fragment describing the
scheduling of an event once the course
documentation and panel members for the validation
event have been selected. These additional
constraints make this more complex than a usual
event scheduling process.
Once a course specification document has been
prepared, a request for setting up a validation event
is issued. Upon receiving the request, the academic
office, will check the completeness of the
documentation and decide on whether to proceed
with the organisation of the validation event. The
fragment of the analysis model and its corresponding
implementation model are shown in Fig 2.
Figure 2: Example 1.
This example illustrates the decomposition of
tasks in a sequence of subtasks. The
‘GetDocumentSet’ task takes a request of retrieving
a document set and returns the actual document set.
This can directly be mapped into a web service. The
“decide on completeness of documentation” task
takes a document set as an input and the output is
Boolean. Here to arrive to the decision we need to
present the document set to the user with the
intention of making a decision on the completeness
of the document. It is therefore mapped into getting
an automatic review of the completeness (service), a
viewing of the document and a completeness report
and capturing the user decision on completeness. It
was also mapped into a task of saving any changes
made to the document set, which lead to the
invocation of a web service for storing the updated
document.
The second example illustrates two other types
of decomposition. We first look at the
decomposition into parallel subtasks and then into
loop sub processes. Here, the academic office tries
to coordinate a panel for the review of the course
specifications.
LAYERED PROCESS MODELS - Analysis and Implementation (using MDA Principles)
173
Table 1: Examples of transformation.
Analysis
Model
Transform
ation
Implementation
Model
Example 1
Get
Documentatio
n Set
Direct mapping <<Service Tasks>> GetDocSet
<<Process Tasks>> GetDocSet
Decide on the
Completeness
of the
Documentatio
n
Mapping into
tasks sequence
<<Service Tasks>>
CheckCompletness
UpdateDocSet
<<Process Tasks>>
InvokeCheckCompletness
ReviewDocSetCompletness
GetDecisionOnCompleteness
CopyFlag&UpdateDocSet
<<User Tasks>>
Completeness-Create
Completeness-Complete
Example 2
Get
Potential
Panel
Member
List
Mapping into
parallel tasks
<<Service Tasks>>
CreateEvent GetExternal
GetInternal
<<Process Tasks>>
CreateEvent GetExternal
GetInternal
Validate
Suitability
of Panel
Mapping into
sequence
tasks
<<Process Tasks>>
SelectPanelMember
RetrieveSelection
<<User Tasks>>
ViewPotentialMembers
SelectPotentialMembers
Choose
Panel
Members
Decomposed
into
Sequence of
tasks & 2
parallel
subprocesses.
Each
subprocess
decomposed
into parallel
loop task and
a subprocess
(illustrated in
Figure 4)
<<Process Tasks>>
GetpossibleDates
SuprocessInviteExternal
(loop task: inviteExternal &
subprocessProcessResp:
(GetInvitationResponse,
ProcessResponse))
SubprocessInviteInternal
(same as the external)
<<User Tasks>>
PanelInvite-create
PanelInvite-complete
<<Service Tasks>>
ProcessMemberResponse
Figure 3: Example 2.
A panel is usually composed of external subject
specialists, internal (institutional) staff and a
chairperson. The academic office reviews a list of
potential panel members, chooses an appropriate
number for each role (chair, external, internal), and
arranges a date for the meeting.
A portion of the analysis model is shown in fig
3. An examination of the data for the “Get Potential
Panel Member List” task revealed that the
identification of two types of panel members
(external and internal) was required. This lead to the
task being mapped into two tasks: “getExternals”
and “getInternals”. Both tasks could be stereotyped
into web service tasks. We noticed that the order of
completion of the tasks are not important –getting
internal panel members and getting external panel
members were not dependent on each other. A new
task was also created requesting the event web
service to create a new event that will hold the data
related to the event.
The “Choose Panel Members” task needs to be
mapped into two sub-processes: an “invite external”
sub process and an “invite internal” sub process. As
illustrated in Fig 4, within each sub process, panel
members are to be notified of their invitation to the
event. Each individual member is required to
receive the invitation at the same time; hence, the
task that invites each panel member needs to be in a
parallel loop. This process was completed by
putting a timer on the response sub process to allow
for eventualities such as a non-responding panel
member.
Figure 4: Sub Process Invite External.
6 CONCLUSIONS
In this paper we outlined the case for the application
of MDA principles in business process analysis and
implementation. We have provided examples that
illustrated an algorithm for model transformation
from analysis to implementation. These examples
have been based on the use of Intalio Designer. We
recognise that other toolsets may be used to
implement such transformations, but we feel that our
approach is toolset-independent. The transformation
stages, while straightforward, are sufficient to
achieve the consistent level of granularity required
to successfully bridge the gap between process
analysis and process implementation.
ICEIS 2009 - International Conference on Enterprise Information Systems
174
The transformation from a high-level analysis to
a lower-level implementation model can involve
some degree of complexity, even for seemingly
straightforward processes. Key to achieving a
successful transformation is the decomposition of
these high-level tasks into tasks at an appropriate
level of granularity for the implementation of the
process. The transformation approach proposed has
the potential to be a useful technique for
methodologies that need to be developed for BPM.
The algorithm presented is implementation neutral
and with further experimentation may be sufficiently
generalisable and transferable between toolsets such
that we feel a conversion from manual
transformations to automated wizard-type
transformations is a real and achievable possibility
using this approach.
REFERENCES
Barn, B.S., Dexter, H., Oussena, S., Petch, J. 2006, An
Approach to Creating Reference Models for SOA
from Multiple Processes. In IADIS Conference on
Applied Computing.
BPMN. 2006, Business Process Modeling Notation
(BPMN) Specification [Online] BPMN. Available at:
http://www.bpmn.org/Documents/OMG%20Final%20
Adopted%20BPMN%201-0%20Spec%2006-02-
01.pdf [Accessed Nov 2008].
Brown A, Delbaere M, Eeles P, Johnston S, Weaver R.
Realizing service-oriented solutions with the IBM
Rational Software Development Platform. IBM
Systems Journal [serial online]. September
2005;44(4):727-752.
Delphi Group. 2003, BPM 2003 – Market Milestone
Report. White Paper.’
Erl, T. 2005, Service Oriented Architecture – Concepts,
Technology and Design, Prentice-Hall, USA
Huang J.C., Newell S., Poulson B., Galliers R.D. 2005,
Deriving Value from a Commodity Process: a Case
Study of the Strategic Planning and Management of a
Call Center. In Proceedings of the Thirteenth
European Conference on Information Systems
Regensburg, Germany, May 26-28, 2005.
Huang, S. and Fan, Y. 2007. Model Driven and Service
Oriented Enterprise Integration---The Method,
Framework and Platform. In Proceedings of the Sixth
international Conference on Advanced Language
Processing and Web information Technology (ALPIT
2007) - Volume 00 (August 01 - 01, 2007). ALPIT.
IEEE Computer Society, Washington, DC, 504-509.
Intalio. n.d, Product List, [Online] Intalio. Available at:
http://www.intalio.com/products, [Accessed Nov
2008].
Lau, F. 1997. A review on the use of action research in
information systems studies. In Proceedings of the
IFIP Tc8 WG 8.2 international Conference on
information Systems and Qualitative Research
(Philadelphia, Pennsylvania, United States). A. S. Lee,
J. Liebenau, and J. I. DeGross, Eds. Chapman & Hall
Ltd., London, UK, 31-68.
Moody, D. L. (2005) Theoretical and practical issues in
evaluating the quality of conceptual models: current
state and future directions. Data & Knowledge
Engineering 55, 243-276.
Murzek, M., Kramler, G., and Michlmayr, E. 2006.
Structural Patterns for the Transformation of Business
Process Models. In Proceedings of the 10th IEEE on
international Enterprise Distributed Object Computing
Conference Workshops (October 16 - 20, 2006).
EDOCW. IEEE Computer Society, Washington, DC,
18.
Recker, J., Indulska, M., Rosemann, M., Green, P.: (2006)
How Good is BPMN Really? Insights from Theory
and Practice. In: Ljungberg, J., Andersson, M. (eds.):
Proceedings of the 14
th
European Conference on
Information Systems. Association for Information
Systems, Goeteborg, Sweden (2006) 1582-1593
Smith H., Finger P., Business Process Management
(BPM) the third wave, Meghan-kiffer press
Soley, R. and Watson, A. 2008. Service Oriented
Architecture: Making the Leap, Leveraging Model
Driven Architecture and Achieving Software Agility
with BPM, SOA and MDA®. In Proceedings of the
19th Australian Conference on Software Engineering
(Aswec 2008) - Volume 00 (March 26 - 28, 2008).
ASWEC. IEEE Computer Society, Washington, DC,
32-34.
Thomas, O., Leyking, K., and Dreifus, F. 2008. Using
Process Models for the Design of Service-Oriented
Architectures: Methodology and E-Commerce Case
Study. In Proceedings of the Proceedings of the 41st
Annual Hawaii international Conference on System
Sciences (January 07 - 10, 2008). HICSS. IEEE
Computer Society, Washington, DC, 109.
UML, 2007, Unified Modeling language,
http://www.omg.org/docs/formal/07-11-04.pdf
Zdun, U., Hentrich, C., and Dustdar, S. 2007. Modeling
process-driven and service-oriented architectures using
patterns and pattern primitives. ACM Trans. Web 1, 3
(Sep. 2007), 14.
Zhang, L. and Jiang, W. 2008. Transforming Business
Requirements into BPEL: A MDA-Based Approach to
Web Application Development. In Proceedings of the
IEEE international Workshop on Semantic Computing
and Systems - Volume 00 (July 14 - 15, 2008). WSCS.
IEEE Computer Society, Washington, DC, 61-66.
LAYERED PROCESS MODELS - Analysis and Implementation (using MDA Principles)
175