ER Publications
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];
INTRODUCTION
A
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 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.
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.
1 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 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] |Kinnosa Workflow [6] |
|TIBCO BPM [7] |Synergy [8] | |
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] |Metastorm BPM [10] |Spagic [11] |
|Interstage BPMS [12] |Living Systems Process Suite [13] |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.
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 Business Process Definition Metamodel is a semantic description of the logical relationships |[pic] |
|among the various elements of any possible business process description. |Figure 1. MDA Development Sequence |
| | |
|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). | |
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
• 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.
|Another problem still left unresolved the CIM to PIM Mapping and it is not mentioned|[pic] |
|in the MDA guide. |- Figure 2. The Abstraction Gap - |
|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. | |
|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:
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):
- 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.
2 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 details- and this is done by using a selected set of architectural concepts and structuring rules, to concentrate on particular parts in the system.
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?
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:
|A business process modeling tool. |MDA framework. |
|A tool that support the modeling of business process. |Allow the definition of data models, automation of generation as well as |
| |easy integration, maintenance, testing and simulation of the software |
| |system. |
|A work flow management engine. |[pic] |
|Describes business processes in a common dialect that lets |- Figure. 3: XBPF Architecture - |
|business people and developers speak the same language. | |
|A reverse engineering module. | |
|Extracting information from existing systems to be used in | |
|modeling the integration with other systems. | |
|An Enterprise Service Bus (ESB). | |
|Integrating applications, coordinating resources and manipulating | |
|information. | |
|An ESB UML meta model | |
|Description that defines the structure of the ESB UML integration | |
|models. | |
|A transformation engine | |
|Manipulate the business (Requirement) model. | |
|An interface tool that integrates this components | |
|A wizard tool for integrating the previous components. |
1 Proposed Solution:
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.
2 Work Done:
• 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 |[pic] |
|Module) |- 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 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 and
▪ 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: ()
• 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:
A. Separation between the business model and the MDA model.
B. 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.
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 6. BPM & MDA in the Same model - |
|- Figure 5: Separate BPM & MDA 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.
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:
|Analyzing target technology (PSM: Design Model). |[pic] |
|Model, generate and write metafacades. |Figure 7. Adding Requirement Profile to MDA metamodels |
|Identify, design and generate PSM metaclasse. | |
|Model, generate and write metafacades. | |
|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. | |
|Design cartridge test model using the profile | |
|Test cartridge. | |
| |
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:
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”, , 2003.
2] ANDROMDA -
3] Frankel, “MDA COL”, , .
1] Chordiant Enterprise Platform:
2] Progress Software Corporation (NASDAQ: PRGS), ”Savvion BusinessManager”, , 2012.
4] Kinnosa Workflow :
5] TIBCO BPM :
6] Synergy :
7] “Automate BPM”,
8] “Metastorm BPM”,
9] “Spagic”,
10] Interstage BPMS :
11] Living Systems Process Suite :
12] BPM and MDA: The Rise of Model-Driven Enterprise Systems :
13]
14] BPMI -
15] [16] BPML-2002.pdf
16] [17] BPMN -
17] [18] BPEL4WS -
18] [19, 25] A new MDA approach based on BPM and SOA to improve software development process :
19]
20] [20] “The OMG's Model Driven Architecture and BPM:”,
21] MDA Guide Version 1.0.1.pdf -
22] BPMS Essentials with Open Source.pdf -
23] JBOSS jBPM.pdf -
24]
25] “A new MDA approach based on BPM and SOA to improve software development process:”,
26]
27] ArgoUML :
28] [29]
29] [30] SCM -
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
- smart grid simulation requirements specification
- distribution automation working group
- appendix a cimi glossary map mayo clinic
- political marketing vs commercial marketing something in
- smart grid simulation platform architecture requirements
- objetivo organization of american states
- informe seguimiento pia 2010 oas
- er publications
Related searches
- west creek er richmond va
- orlando health er in kissimmee
- orlando health er kissimmee
- west florida hospital er pensacola fl
- osceola er orlando health
- orlando health er osceola parkway
- how much does an er surgeon make
- west florida er wait time
- florida hospital er central pasco
- advent health er brandon
- west florida perdido er phone number
- orlando health er locations