Towards Developing eXecutable Business Process Framework (XBPF
Architecture)
Ali Abdel-Aziz, Amr Kamel, Ibrahim Farag, (Ali Abdel-Aziz)
Computer Science department,
Faculty of Computers & Information, Cairo University,
Cairo, Egypt
Email: ali.abdel.aziz.ali@gmail.com
Abstract: nowadays software has become an essential part of many life issues. You can find it easily around you in
the everyday life in modern societies. As software plays vital role in any field including huge and large systems so
this lead to raising the complexity of the required software, so it became evident that modeling data and application
is a must. Before modeling it was difficult to maintain or modify an existing system. At the earliest stages, UML
modeling was of little benefit except that this model provide high level view for the application; more work have
been done in this area.
This paper will address how to automate software life cycle by transforming from Requirement model to Detailed
UML design model that can be used to generate the application source code, with its deployment tasks that can be
invoked to deploy the system.
This means expressing the system in requirement model pressing magic button that will generate the system and
deploy it.
CIM:stands for Computation Independent Model; PIM:stands for Platform Independent Model; PSM:stands for
Platform Specific Model; SRS:Software Requirement Specification which is a complete description of the
behavior of the system to be developed. It includes a set of use cases that describe all the interactions the users
will have with the software; Element: A generic term referring to a singular object in a model. Some of the
common elements include requirements, actors and systems; Model: A representation of a particular system,
such as a business process or a database; Diagram: A common way of representing the way in which models and
elements interact; Attributes: Data fields containing information within another modeling elements; Dot:
Hierarchical or layered drawings of directed graphs. The layout algorithm aims edges in the same direction (top
to bottom, or left to right) and then attempts to avoid edge crossings and reduce edge length. [12]; ERP:
Enterprise Resource Planning main purpose is to facilitate the flow of information inside the organization and
manage the connections to outside stakeholders; SCM: Supply Chain Management mange all movement and
storage of raw materials, work-in-Process inventory and finished goods from point of origin to point of
consumption [30];
I.
A
INTRODUCTION
S
the complexity of the required software grows; it became evident that modeling data and application is a
must. Before modeling it was difficult to maintain or modify an existing system. At the earliest stages, UML
modeling was of little benefit except that this model provides high level view for the application. After UML became
This work was supported in part by the Computer Science Department, Faculty of Computers & Information, Cairo University. Under the
supervision of Dr. Amr Kamel and Prof. Dr. Ibrahim Farag.
Ali Abdel-Aziz is with the Computer Science department, Faculty of Computers & Information, Cairo University. (Phone: 00971-55-5519130; email: ali.abdel.aziz.ali@gmail.com; website: http://www.aliabdelaziz.org).
the industry De-facto standard, supporting tools start providing features like generating simple prototype from the
model “generating class template with functions prototype”.
However, synchronization problems between the model and generated code. Developers have to manually ensure
that changes in the code are reflected in the model and vice versa. Further research work in this field allowed current
UML tools to generate prototypes as well as auto synchronizing between the code and the model. They typically have
proprietary code generation systems with a fixed meta model. Furthermore, the Object Management Group (OMG)
devised the Model Driven Architecture (MDA) concepts [1] to allow the definition of data models, automation of
generation as well as easy integration, maintenance, testing and simulation of the software system.
Tools and frameworks supporting MDA, such as ANDROMDA [2], employs some parts of MDA that allow the
code generation and maintenance from data model. Unfortunately, these frameworks need high technical skills to
benefit from.
To overcome this problem, practitioners have developed models for specific application domain; eXecutable
Business Process (XBP) is a prominent goal for such an effort. The ultimate objective of the XBP is to develop tools
to support business analysts in the same way CAD/CAM tools are used to support engineers [3].
For serving any application domains and not being tied to the already developed application domains models
theoretical solutions has been proposed to make use of BPM and MDA in away to provide a powerful support for
business users/analysts the same way it’s going to support architectures/designers and developers; but this solutions
didn’t provide a methodologies to solve the abstraction gap “to be discussed later” and didn’t provide away to
automate the mapping from CIM to PIM.
Our solution automates the full process and make it easy at the initiation of the project as this thesis tries to make
the abstraction gap closer; the gap that exists between the PIM models that can be used to generate the software and
the CIM models that can be used to express/model the business requirement of software in terms of BPM models.
And this will be done by implementing a higher level above the PIM;
This is a Bottom up approach so we can realize the outcome sooner as illustrated later in this thesis.
II.
BACKGROUND
This chapter would focus on the treatment & the research that has already been done on the topic in addition it
address the modules needed to be combined with current ones to formulate the whole picture of the introduced
approach. It would contain a review of related literature, which includes past research and writings and their impact
on the study.
A.
Work done in this area:

Business process modeling tool:
In 7, November, 2002 the Business Process Management Initiative (BPMI) [15] published the Business
Process Modeling Language (BPML) specification document. The Business Process Modeling Language
2
specification provides an abstract model for expressing business processes and supporting entities. “BPML
defines a formal model for expressing abstract and executable processes that address all aspects of enterprise
business processes” [16]; adding to this activities, transactions, data management, concurrency, exception
handling and operational semantics. BPML grammar form is XML Schema that enable the persistence and
interchange of definitions across heterogeneous systems and modeling tools. Business Process Management
Notation (BPMN) 0.9 [17] , is a sister specification to BPML 1.0. BPMN aims to be able to generate
execution definitions (BPML4WS) [18] that will be used to implement the business processes. BPEL4WS
recognizes the need for an independent representation of the interactions between parties.
Business Activity Monitoring (BAM) tools can provide real time views of executing business processes.
Most of the existing BPM tools are specialized or much stronger if used for a specific industry.
BPM tools have a predefined functional set that it can be employed in; such as (Business rules and controls,
Compliance with government regulatory standards, Events, Form formatting, form Tables, Monitoring and
management, Process analytics, Process collaboration, Process modeling, Report design and generation,
Security management, Task allocation, Versioning control and management, Visualization tools and
presentation, Workflow and business process management, Workflow design, Workflow portal, Workflow
reporting, Document management, Form management).
The following BPM tools can satisfy Business rules and controls, process modeling, and workflow design
requirement:
 Chordiant Enterprise Platform [4]
 Savvion BusinessManager [5]
 TIBCO BPM [7]
 Synergy [8]
 Kinnosa Workflow [6]
There are also some powerful BPM tools that fail in satisfying one or more of the Business rules and controls,
process modeling, and workflow design functional requirement and this list contains:
 Automate BPM [9]
 Interstage BPMS [12]
 Metastorm BPM [10]
 Living Systems Process Suite [13]
 Spagic [11]
 ProVision
Business process modeling is usually not done with an IT focus as stakeholders are business people, not IT
folks this guarantees that the business models are independent of any particular technology.
Business process models are used to drive BPM engines and can be used for documentation purposes, and as
Strategic planning.
The main purpose of BPM is to enable computer-assisted management of business processes. BPM models
describe business processes, and the main purpose of MDA, on the other hand, is to enable computer-assisted
generation of applications, components, and integration solutions.
3
Business Process models and MDA models are not exactly the same thing; But BPM models can be seen as
the CIM models and hence it is part of the MDA stack as seen by (Miguel A. Sánchez Vidales 12, Ana Mª
Fermoso García 1, Luís Joyanes Aguilar) [19], and (Paul Harmon) [20]
The OMG worked on defining Process Definition Metamodel; to overcome the problem of different BPM
tools that prevent exchanging the BPM models from one tool to another, also this problem prevents the
The Business Process Definition Metamodel is a semantic description of the
logical relationships among the various elements of any possible business process
description.
Once the BPM tools vendors maps its specific metamodel to the OMG’s
metamodel, at this point XMI can be used to transport information about
developed models in that tool to any other tool that is also mapped to the OMG
metamodel.
This mapping will enable the movement from CIM models created in this
proprietary business process tools to the Business Process Definition Metamodel
then this can be used to complete the MDA development sequence as illustrated
in Figure 1.
Transformation from BPM models (CIM) to any other UML metamodels (PIM).
Figure 1. MDA Development
Sequence

MDA framework:
In 2001 OMG adopted MDA framework, the Model Driven Architecture or MDA is an approach to using
models in software development. “The Model-Driven Architecture starts with the well-known and long
established idea of separating the specification of the operation of a system from the details of the way that
system uses the capabilities of its platform”.[21]
There exist good MDA frameworks one of them is ANDROMDA. ANDROMDA will be our MDA
framework. AndroMDA is an open source MDA framework - it takes any number of models (usually UML
models stored in XMI produced from case-tools) combined with any number of AndroMDA plug-ins
(cartridge and translation-libraries) and produces any number of custom components. You can generate
components for any language you want, Java, .Net, HTML, PHP, anything, just write (or customize an
existing) plug-ins to support it.
The following are some names of other MDA frameworks:

ArcStyler, OptimalJ, OpenArchitectureWare, KennedyCarter, Xcoder, Iqgen, and Home brewn.
4
Another problem still left unresolved the CIM to PIM
Mapping and it is not mentioned in the MDA guide.
Existing MDA Frameworks has already implemented the
MDA specs starting from the PIM models passing thru the
transition to PSM Models and then generating the Database
scripts and software code; So the software architecture can
start modeling the PIM models for the software under
development then generate the source code, database scripts
and build it and package it into a package that is ready for
deployment.
- Figure 2. The Abstraction Gap -
So supposing that Business Process Definition Metamodel has been finished and matured, and all/most BPM
vendors maps its proprietary metamodels to the OMG’s Process Definition Metamodel;
Or in other words the coordination between BPM and MDA;
MDA’s move up the abstraction ladder carries the development paradigm inexorably away from the
computing platform and toward business processes.
A key issue is how to treat the remaining gap which some have called the abstraction gap between the
business process specification language and the software specification language. (See Figure 2.) [14]

Work flow management engine:
In 1990 Business Process Management (BPM) was an interesting topic. In 2001 BPM came back. “The
principle of BPM is to provide business and technical users with a common framework to model, implement,
deploy, execute, measure and improve business processes”.[22]
There exist many work flow and BPM products in the market but all are expensive; JBOSS delivered a
professional open source work flow/BPM engine called JBPM [23].
JBoss JBPM provides a high level view of applications and accomplishes several things:
-
It facilitates more agile implementation of the processes required by business people.
-
It describes business processes in a common dialect that lets business people and developers speak
the same language.
-
It organizes embedded logic of applications into separate and easily changed “state machines” to
allow a new level of processes within businesses.

A reverse engineering module:
5
The main functionality of this module is to extract information from existing system to be used in modeling
the integration with other systems as well as how this system well interact with other systems and how this
system functionalities will be used. there are existing some Reverse engineering modules found in
AndroMDA that is called Schema2XMI which takes as input Database Schema and it generates XMI
representing this system.
a proof of concept for this module has been done and more work done to build over it; I have used
Scheam2XMI to generate XMI UML from an existing database schema and the generated XMI contains all
the objects but with no class diagrams being created for expressing those objects so I have used another open
source API to visualize the generated XMI.
This module has been addressed in more details later in thesis.

Enterprise Service Bus (ESB):
“ESB is not a new software product — it's a new way of looking at how to integrate applications, coordinate
resources and manipulate information” [24]. Unlike other approaches for connecting distributed applications,
for example Remote Procedure Call (RPC), the ESB pattern enables the connection of software running in
parallel on different platforms, written in different programming languages and using different programming
models. ESB solves one of the current biggest challenges which is application integration.
The following are some of the existing ESB:
-
Project Open ESB, Mule, Apache ServiceMix, Celtix, PetALS (JBI), IBM WebSphere Message
Broker, IBM WebSphere ESB.
-
ESB UML meta model:
ESB UML meta model is a description that defines the structure of the ESB UML models as well as
how the systems that are involved in the integration will talk to each other and to the ESB.

Transformation engine:
This engine will be responsible for:
-
Generating Skeletal MDA models from the requirement Models.
-
Keeping the requirement Models and the MDA Models in synchronization.
-
May generate the ESB xml configuration file depending on the way this engine will be implemented
by.

This engine will be covered in more details in the following chapter.
MOF (Meta Object Facility):
6
-
The OMG has defined mappings of MOF to XML and to CORBA. The Java Community Process
has defined a mapping of MOF to Java. A model compiler based on these mappings reads the MOF
model of a language and produces XML schemas for the language, which support encoding models
expressed in that language.
-
The MOF-XML mapping is named XML Metadata Interchange (XMI®) and the MOF-Java
mapping is named Java Metadata Interface (JMI).
A manual approach has been presented on 2008 to make use of BPM fundamentals to create CIM models,
and to create the PIM models manually then it uses SOA to facilitate the use of software services connected
to business tasks [25].
This thesis tries to make the abstraction gap closer; the gap that exists between the PIM models that can be
used to generate the software and the CIM models that can be used to express/model the business requirement
of software in terms of BPM models.
B.
MDA Big Picture:
In 2001 Object Management Group (OMG) introduced the Model Driven Architecture (MDA) framework
which defines standards for how software systems can be developed and work together.
MDA define standards for separating out the famous questions "what" from the "how".
To separate what we want to do in the system from how we will do it;
MDA provides a methodology for:
-
Specifying a system independently of the platform that supports it,
-
Specifying platforms,
-
Choosing a particular platform for the system,
-
Transforming the system specification into one for a particular platform.
The three primary goals of MDA are portability, interoperability and reusability through architectural
separation of concerns.
-
MDA presents its concepts in terms of existing or planned system.
-
Model Driven Architecture name comes from the features MDA provide which are driving the
design, construction, operation and maintenance from the architecture models.
-
MDA use viewpoints for abstraction –establishing simplified model by suppressing selected detailsand this is done by using a selected set of architectural concepts and structuring rules, to concentrate
on particular parts in the system.
7
MDA has three view points:
-
Computation Independent Viewpoint
That focuses on system environment, and on system requirements; leaving the structure details and
system processing undetermined.
-
Platform Independent Viewpoint
That focuses on the system operation whereas hiding particular platform necessary details.
A platform independent view point represents the specification that does not change from one
platform to another.
-
Platform Specific Viewpoint
Which combines the platform independent viewpoint with an additional focus on the details that
specify how the system uses a particular type of platform?
III.
PROPOSED SOLUTION “XBPF”
Our general goal is to realize the layout for the eXecutable Business Process Framework (XBPF), identify
the requirements; integration required and specifies the required steps for making/creating this framework to
realize this objective. We propose an architecture consisting of 8 different components to realize this system,
(As shown in figure 3).
The proposed system consists of:
1. A business process modeling tool.
A tool that support the modeling of business
process.
2. MDA framework.
Allow the definition of data models, automation of
generation as well as easy integration, maintenance,
testing and simulation of the software system.
3. A work flow management engine.
Describes business processes in a common
dialect that lets business people and developers
speak the same language.
4. A reverse engineering module.
Extracting information from existing systems
to be used in modeling the integration with
other systems.
5. An Enterprise Service Bus (ESB).
Integrating applications, coordinating
resources and manipulating information.
6. An ESB UML meta model
Description that defines the structure of the
ESB UML integration models.
7. A transformation engine
Manipulate the business (Requirement) model.
8. An interface tool that integrates this
components
A wizard tool for integrating the previous components.
8
- Figure. 3: XBPF Architecture -
Proposed Solution:
A.
As indicated above XBPF needs frameworks, tools, modules, engines and integration between them. This study
will not cover all of these areas but will concentrate on a specific area. This research will present the work done as
proof of concept for Reverse Engineering module as will it will extend the existing MDA framework to involve the
business (requirement) model in its cycle. This will be achieved by taking the business (Requirement) model and
entering it to the transformation engine and MDA framework which will in turn generate the targeted system.
Work Done:
B.

Reverse Engineering Module:
This part will present the work done to reverse engineer an existing system which uses postgres data base. “any
other database will be the same with small modifications in the configuration and properties files”.
The reverse engineering module will work as follows: (see Figure 4.
Reverse Engineering Module)
- Reverse engineer an existing database to XMI file.
- The XMI file will contain the Class Diagram representing the
database schemas as entities classes.
- Writing an XSLT file that is responsible for parsing the generated
XMI file and producing DOT file containing the Entities Class
Diagrams.
- Feeding the XMI and XSLT files to the XSLT processor and this
- Figure 4 Reverse Engineering
Module -
will produce the DOOT file.
- Feeding the DOT file to the Graphviz engine which will generate the
required output format which might be PNG, SVG, or any other
supported format.
As
stated
before
there
is
a
reverse
engineering
AndroMDA
(andromda:schema2xmi) Plugin which will be used to to achieve this task.
For achieving this task there are a set of Prerequisites which are (Java, Maven, and a working andromda
environment).
The following are the required steps to generate the xmi file from our postgres database:
 Generating an AndroMDA project using Maven.
 Adding the PostgreSQL Mappings file.
 Add dependency to Postgres jdbc drivers.
 Run schema2xmi.
For more details visit http://www.aliabdelaziz.org/Reverse_Engineering_DataBase_Part_1 and
http://www.aliabdelaziz.org/Reverse_Engineering_DataBase_Part_2
9
 Discussion:
The previous methodology proved its correctness and efficiency and it worked greatly with me in several
projects, and it has been recommended and mentioned as the technical inspiration for one of the argouml
[27] module: (http://argouml-graphviz.tigris.org)

Transformation from requirements to detailed PIM model:
As presented early in the Introduction this is our main objective; the optimum solution is taking BPM model
which will form our CIM model and generate a full system from it.
There are three main directions to achieve this:
a.
OMG is trying to standardize the BPM models by defining Process Definition Metamodel; to overcome
the problem of different BPM tools that prevent exchanging the BPM models from one tool to another,
also this problem prevents the transformation from BPM models (CIM) to any other UML metamodels
(PIM), and this can be a step forward but OMG by this solution is working Top down and we will not be
able to link between this and between the existing implemented work in the MDA field until we can find
a way to transform from the CIM model to the PIM model automatically.
b.
A manual approach has been presented on 2008 to make use of BPM fundamentals to create CIM
models, and to create the PIM models manually then it uses SOA to facilitate the use of software services
connected to business tasks [25].
This off course will not be of a big help at the initiation phase of the software process, but it will be of a
big help at the support phase or at any other phase that will need business changes or Business on
demand as it is mentioned in this approach.
c.
Our solution that will be presented here which will try to automate the full process and make it easy at
the initiation of the project as we are trying to make the abstraction gap closer; the gap that exists
between the PIM models that can be used to generate the software and the CIM models that can be used
to
express/model
the
business
requirement
of
software
in
terms
of
BPM
models.
And this will be done by implementing a higher level just above the PIM and off course under the BPM;
This is a Bottom up solution so we can see the outcome immediately as illustrated later in this thesis.
Extending the existing MDA framework (AndroMDA):
This is the core of this thesis; for extending the existing MDA framework to involve the business (requirement)
model in its cycle. This will be achieved by taking the business (Requirement) model and entering it to the
transformation engine and MDA framework which will in turn generate the targeted system.
This goal will be achieved by one of the following Ways:
C. Separation between the business model and the MDA model.
D.The same model will be used for both the business and MDA.
1.
Separation between the business model and the MDA model:
In this way there will be two types of models Business Model and MDA Models.
10
The transformation engine will generate MDA Models from the given Business Model which will be
processed by the MDA framework to produce the targeted system. (As in Figure 5)
Following this way the transformation engine will not generate the ESB xml configuration file; it will be
generated by a custom andromda cartridge.
2.
The same model will be used for both the business and MDA:
In this way the business model and the MDA model will be in the same model and there will be
transformation (Requirement) cartridge in the MDA framework which will handle the transformation and the
generation from the business part of this model. (As in Figure 6)
In this approach the transformation engine (Business / Requirement Cartridge) will generate the ESB xml
configuration file.
- Figure 5: Separate BPM & MDA Model-
- Figure 6. BPM & MDA in the Same model -
Following the first way there is expected problem, because at some point, Business Process models and
MDA models
3.
Selected Solution:
I choosed the first idea to implement – A new model will be generated from the business (Requirement)
Model - Also as mentioned above AndroMDA will be our MDA framework.
To overcome the problem of keeping business models and MDA models in sync; some diagrams of the new
generated detailed system model will be marked as don't touch as it will be overridden whenever a change in
the business (Requirement) model is done and a trigger for detailed system model generation is done.
Examples for these models are Entity Diagrams and Value Objects Diagrams … etc.
As Entity Diagrams and Value Objects Diagrams should not be changed as it is one to one mapping to
business entities to be presented in the requirement system model.
Some Other Models will be marked as free for modifications as it will be just generated once; these models
will be any model not supported for detailed and complete generation and also models that needs interfering
by software design engineer. Examples for these models are Sequence Diagrams, and Activity Diagrams,
and Services Class Diagrams.
11
As for example Service Class diagram will be generated once with its dependencies to the entities that it
might need to interact with and the most commonly used functions for every business entity will be
presented inside these services however some other business methods might be needed to be added by the
Design Engineer, and this will trigger change in the Service Class Diagram, and the invocations in the
sequence diagrams and a change also in the activity diagrams might be needed; so it would be save to not
override all of this work.
The work to be done is writing a requirement cartridge which consists of the following steps like any other
custom AndroMDA cartridge.
The basic process for Requirement / Business cartridge implementation includes the following steps:
1. Analyzing target technology (PSM: Design
Model).
2. Model, generate and write metafacades.
3. Identify, design and generate PSM metaclasse.
4. Model, generate and write metafacades.
5. Create UML profile as a modeling guide for
Business Cartridge users:
As all MDA models are related because all of
them are based on a very abstract metamodel;
The (MOF) Meta Object Facility.
6. Design cartridge test model using the profile
7. Test cartridge.
IV.
Figure 7. Adding Requirement Profile to MDA
metamodels
CONCLUSION
Problem Solution Results:
This research first goal was to reverse engineer any existing system to get platform independent model
representing it so that it can be used in integration with any other system and this is already done successfully based
on the Database of the legacy system.
The second goal which is a major goal was to present away to represent the Requirement (Business) models in a
way that a detailed UML model can be generated from it which in turn will be eligible to code generation and
packaging via AndroMDA; and a proof of concept for this have be done.
Assumption about the way the requirement model will be presented using it have been taken to use UML as a way
of presenting requirements and business models and a requirement cartridge profile model have been modeled to be
used while modeling the requirement models such that when a stereotypes of the following types (CRUD, CREATE,
RETRIEVE, UPDATE, or DELETE) have been used in making any requirement entity a corresponding Class Entities
and Objects are being generated with tagged values and stereotypes applied to it and those Classes will contains the
operations that is related to each of the mentioned stereotypes.
FUTURE WORK:
12
Talking about future work will take us in two directions, either going horizontally and try to build over what it
have been presented in this thesis to try to close the gap between the BPM models and our presented requirement
model; alternatively is to work vertically to complete this requirement to detailed PIM transformation tool.
REFERENCES
[1] Mariano Belaunde (France Telecom R&D), Carol Burt (2AB), Cory Casanave (Data Access Technologies),
Fred Cummins (EDS), “MDA Guide Version 1.0.1”, http://www.omg.org, 2003.
[2] ANDROMDA - http://www.andromda.org
[3] Frankel, “MDA COL”, http://www.codegeneration.org, .
[1] Chordiant Enterprise Platform: http://www.chordiant.com/solutions/enterpriseplatform.html
[2] Progress Software Corporation (NASDAQ: PRGS), ”Savvion BusinessManager”,
http://www.savvion.com/business_manager, 2012.
[4] Kinnosa Workflow : http://www.firsttrace.com/product-kinnosa-workflow.jsp
[5] TIBCO BPM : www.tibco.com
[6] Synergy : http://www.exactamerica.com
[7] “Automate BPM”, http://www.vendor-showcase.com/frame_profiledb.asp?optionid=16385
[8] “Metastorm BPM”, http://www.metastorm.com/products/overview_index.asp
[9] “Spagic”, http://www.spagoworld.org/xwiki/bin/view/Spagic
[10] Interstage BPMS : http://www.fujitsu.com/global/services/software/interstage
[11] Living Systems Process Suite : http://www.whitestein.com/goal-oriented-bpm-suite
[12] BPM and MDA: The Rise of Model-Driven Enterprise Systems :
[13] http://www.bptrends.com/publicationfiles/0603%20wp%20bpm%20and%20mda%20whitepaper%20frankel11.
pdf
[14] BPMI - http://www.BPMI.org
[15] [16] BPML-2002.pdf http://www.BPMI.org
[16] [17] BPMN - http://www.ebpml.org/bpmn.htm
[17] [18] BPEL4WS - http://www.ebpml.org/bpel4ws.htm
[18] [19, 25] A new MDA approach based on BPM and SOA to improve software development process :
[19] http://www.scielo.oces.mctes.pt/pdf/tek/n9/n9a04.pdf
13
[20] [20] “The OMG's Model Driven Architecture and BPM:”, http://www.bptrends.com/publicationfiles/0504%20NL%20MDA%20and%20BPM.pdf
[21] MDA Guide Version 1.0.1.pdf - http://www.omg.org
[22] BPMS Essentials with Open Source.pdf - http://www.glintech.com
[23] JBOSS jBPM.pdf - http://www.riseforth.com
[24] http://www.ibm.com
[25] “A new MDA approach based on BPM and SOA to improve software development process:”,
http://www.scielo.oces.mctes.pt/pdf/tek/n9/n9a04.pdf
[26] http://www.andromda.org/docs/andromda-cartridges/andromda-hibernate-cartridge
[27] ArgoUML : http://argouml.tigris.org/
[28] [29] http://forum.andromda.org/viewtopic.php?t=3253
[29]
[30] SCM -http://en.wikipedia.org/wiki/Supply_chain_management
14