Data Model Driven Architecture (DMDA)Chen Chen, Xueguang Chen, and Hong Liu

Abstract—Based on the current development of Model Driven Architecture (MDA) in Enterprise Information System (EIS), the paper proposes a DMDA, a new development architecture to improve EIS development speed and quality. The basic idea of the DMDA is to take advantage of formal description, decomposition and re-use on EIS development process to let computer understand development demands of developers and then consequently generate some business models having nothing to do with specific technical realization, combine with specific technical basic platform to finally generate the EIS meeting actual demands based on data model. The practice proves the architecture is capable of simplifying EIS development difficulty, expediting application and development speed, improve development quality and achieve the rapid development purpose. 1

I. INTRODUCTION

HE MDA [1] is a general software development architecture, and it is needed to work out the different standard and specifications for different

software. For EIS, there are many development technologies (.NET, JAVA and etc.) and multiple middleware platform realization techniques (CORBA, EJB and etc.) [2]. Moreover, these standards and techniques are under unceasing development; so it is hard to describe all EIS development standard and technology by using a general standard or specification. In addition, the modeling method for MDA currently is mainly based on uniform modeling language (UML) [3];however as a general modeling language, the UML does not specify specific guiding approaches to EIS field; but the developers are required to have skilled modeling language [4]. However actually, most of developers have not such capacities; moreover a high cost will be involved when learning the modeling knowledge. In view of the factors aforesaid, it is urgent to be available the new development system structure and approaches easy to be adopted by developers in EIS development enterprise to guide development of EIS [5].

To be done by encircling data is the core of EIS, and a complete EIS needs the data-storing and data-processing capacity, therefore it is needed to establish a model that can clearly describe data storage and process mode firstly if aiming to use MDA ideas in EIS development field. For developers, it is a must to have the competency

Manuscript received October 28, 2011. This work was supported by

the National Natural Science Foundation of China, Grant No.60903174, the Fundamental Research Funds for the Central Universities, HUST: 2010QN016, 2010MS017, the fund of Key Lab for Image Processing and Intelligent control (20093).

Chen Chen and Xueguang Chen are with the Institute of Systems Engineering, Huazhong University of Science and Technology, Wuhan 430074, PR China. (Email:datocc37@126.com, xgchen9@mail.hust.edu.cn )

Liu Hong is with the Key Lab for Image Processing and Intelligent control, Huazhong University of Science and Technology, Wuhan 430074, PR China . Email: hongliu1978@mail.hust.edu.cn ; Tel: +86-(0)13986080703

to establish a data model that can describe data storage structure. To let data model become a basic element to drive EIS development and improve development speed and efficiency, but not a document to establish data storage structure, will be easy to form a general EIS development standard. However the existing data model cannot describe data processing logic; therefore it is needed to expand and adjust the existing data model so as to describe the business logic involved in data processing; in this paper, the improved model is called the business model.

However it is not undesirable to establish such business model by developer directly; the main reason is the data processing logic, which requires to abide by some strict grammar and rules for establishment of business model; if so it will be inevitable to require developers to have professional business modeling knowledge; such requirements are rightly opposite to the object to reduce learning cost (mentioned previously); therefore the most appropriate mode, for developers, is to establish data model, and then let computer complete the transformation from data model to business model [6].

Based on the aforesaid thinking, the paper proposes the concept of DMDA; the basic idea of the DMDA is to take advantage of formal description, decomposition and re-use on EIS development process to let computer understand development demands of developers and then consequently generate some business models having nothing to do with specific technical realization, combine with specific technical basic platform to finally generate the EIS meeting demands based on data model.

II. SYSTEM STRUCTURE

The DMDA adopts the idea of model driven to guide EIS development, but it does not follow up the MDA specifications; since the DMDA adopts mainly the model driven, it is a MDA application defined broadly. The Fig. 1 shows the system structure of viewpoint-separated DMDA.

Data modelMiddle model

Business model

Model Tier

Pattern Tier

Development pattern

Conversion

Template Tier

Template file

Database

EIS development

process

Code of repeated structure

EIS Code

Developer

Designer

Code Generat

e

Development activity

Fig. 1 System Structure of Viewpoint-separated DMDA

From the Fig. 1 above, it can be seen the system structure adopts the viewpoint-separated hierarchical

T

269

Fourth International Workshop on Advanced Computational Intelligence Wuhan, Hubei, China; October 19-21, 2011

978-1-61284-375-9/11/$26.00 @2011 IEEE

design approach, and the system stricture is divided three tiers from top to bottom, i.e.: Model tier, Pattern tier and Template tier.

Model tier is the base of the DMDA; which offers the semantic description of model--data model and middle model and business model involved in the integral structure. In accordance with the descriptions, developers can quickly establish data model and complete the transformation between data model and middle model, as well as middle model and business model according to the given rules.

Pattern tier is the core of DMDA; which is mainly responsible for extracting development pattern and decomposing development process. The development pattern is derived from the formal description, decomposition and re-use on EIS development process. By extracting such patterns, EIS developer can continuously use the existing solution and development mode, avoid repetitive development labor, and then realize the development mode oriented by EIS development process and achieve the rapid development objective.

Template tier offers the realization mode of business model under different technical basic platforms; its purpose is to realize separation between business development and specific realization technique. The template tier is applied to convert business model into the EIS code document satisfying with the target technical basic platform based on template document.

The hierarchical approach above shows the viewpoint separation of two types of users. One is the designer; which is mainly responsible for extracting various development modes and writing realization template for different technologies and platforms, and then offering sound rapid development environment for developer; the other is the developer, which is needed to establish data model according to business demands on one hand and complete transformation from data model to business model and from business model to final code according to independent development idea on the other hand; therefore designer is needed to care about the pattern tier and the template tier, but developer is needed to care about the model tier. The function, composition element and operating mechanism of model tier and pattern tier are described hereinafter specially.

III. MODEL TIER Model tier consists of data model, business model and

middle model and etc. the specific composition elementis defined formally as follows:

Definition 1: Data item DataItem=(ItemName,DataType,DataLength,IsKey,Is

ForeignKey) Definition 2 Data table DataTable =(TableName,{DataItem},Constraint) Definition 3 Data model DataModel =(ModelName,{DataTable},Constraint) Definition 4 Extended attribute ExtendedAttribute=(AttributeName,ExtendedObject ,{

Constraint},Value) Definition 5 Business attribute BizAttribute =(AttributeName, DataTable ,DataItem,

ExtendAttribute) Definition 6 Business entity BizEntity =(EntityName,{BizAttribute},Constraint) Definition 7 Business model BizModel=(ModelName,{BizEntity},Constraint,{Temp

lateCondition}) Definition 8 Middle model InterBizModel=(ModelName,{BizEntity},Constraint,{

TemplateCondtion},{TaskCondition},State) After the definition for the composition elements of

the model tier is available, the model transformation between them will be introduced hereinafter. The Fig. 2 shows the general model transformation process of the model tier.

Data modelInitial-status

middle model

Middle-statusmiddle model

Final-status middle model

Bussiness model

Abnormal-statusmiddle model

Fig. 2 General Model Transformation Process of Model Tier

From the Fig. 2 above, it can be seen the primary transformation of the model tier is to convert data model into the initial-status middle model. In this process, the data model is not extended, but the State status is changed and the TaskCondition for the next development task is added; therefore the BizEntity and Constraint of the middle model and the DataTable and Constraint of the data model at the moment are corresponded each other; for their formal description, see the following:

DataModel(ModelName,{DataTable},Constraint)→InterBizModel(ModelName,{DataTable},Constraint,Ø,{TaskCondition},”Initial-status”)

However, the middle model in the initial status will be converted into the middle-status middle model. In this process, the BizEntity, Constraint, TaskCondition and State status of the middle model will change; moreover the TemplateCondition for template is added; in addition, if the TaskCondition in the initial-status middle model fails to match with the next development task, the transformation process will interrupt, and then finally an abnormal-status middle model will be converted. Its relevant formal description is made as follows:

InterBizModel(ModelName,{DataTable},Constraint, Ø,{TaskCondition},”Initial-status”) →InterBizModel(ModelName,{BizEntity},Constraint’,{TemplateCondition},{TaskCondition}’,”Middle-status”)\InterBizModel(ModelName,{DataTable},Constraint,Ø, Ø,”Abnormal-status”)

Following the middle model in the middle status is continued to be converted. On one hand it can be converted into a new middle-status middle model; on the other hand, it can be converted into a final-status middle model. Similarly, if the TaskCondition in the middle model fails to match with the next development task, it can then be converted into the abnormal-status middle model; its formal description is made as follows:

InterBizModel(ModelName,{BizEntity},Constraint’,{TemplateCondition},{TaskCondition}’,”Middle-status”) →InterBizModel(ModelName,{BizEntity}’,Constraint’’,{TemplateCondtion}’,{TaskCondition}’’,”Middle-status”)|InterBizModel(ModelName,{BizEntity}’,Constraint’’,{TemplateCondition}’,

270

Ø,”Final-status”)| InterBizModel(ModelName,{BizEntity},Constraint’,{TemplateCondition}, Ø,”Abnormal-status”)

Finally the middle model in the final status is eliminated the TaskCondition and State by the system and then be converted into the business model; its formal description is made as follows:

InterBizModel(ModelName,{BizEntity}’,Constraint’’,{TemplateCondition}’,Ø,”Final-status”) →BizModel(ModelName,{BizEntity}’,Constraint’’,{TemplateCondition}’)

When the system shows the abnormal-status middle model, the system will require developer to make choice, i.e.: end the model transformation or designate the next development task to continue model transformation.

IV. PATTERN TIER

Pattern tier comprises of development task, development pattern, development work and development activity and etc. The specific composition element has a formal definition as follows, i.e.:

Definition 9 Atomic development task AtomicDevTask=(TaskName,{PreCondition},Empowe

rConstraint ,{TransferRuleTemplate},{PostEffect}) Definition 10 Composite Development Task CompositeDevTask=(TaskName,TaskGoal,Decompos

eConditon) Definition 11 Initial Development Process

InitialDevProcess=(ProcessName,{CompositeDevTask},Sequence)

Definition 12 Development Process DevProcess=(ProcessName,StartTask,EndTask,{Atom

icDevTask}) Definition 13 Start task StartTask=(TaskName, {PostEffect}) Definition 14 End task EndTask=(TaskName,{PreCondition},{PostEffect}) Definition 15 Task decompose method DecomposeMethod=(MethodName,PreCondition,{Ato

micDevTask| CompositeDevTask}) Definition 16 Development pattern DevPattern=(PatternName,{DecomposeMethod}) Definition 17 Development work item DevWorkItem=(Actor,{TransferRule},{PostEffect},Sta

te) Definition 18 Development activity DevActivity=({TransferAction}) Based on the research above, the operating mechanism

of the pattern tier will be further analyzed hereinafter. The essence of the pattern tier is to provide support for model transformation of model tier, and its purpose is to convert the development demands of developer into a series of model transformation operations. The Fig. 3 shows the operating mechanism of the pattern tier.

Model

Data modelMiddle model

Development processStart task

End task

Decompose

Development work

Development work item

Participant

DeveloperComputer

CompleteDevelopment activity

Model transformation sequence

Atomic development task network

Initial development process

Development task sequence

Development pattern

Task decomposition method assembly

Execute

Fig. 3 Operating Mechanism of Pattern Tier

From the Fig. 3 above, it can be seen the operation of the pattern tier needs to define the initial development process by developer as per development demand; afterwards seek the matchable task decomposition method in the pre-defined development pattern; its formal description is made as follows:

find DMS={DecomposeMethod} in DevPattern where DevPattern.DecomposeMethod.PreCondition=InitialDevProcess.CompositeDevTask.DecomposeCondition

Following, the development process will be obtained by decomposing the initial development process according to such methods. The task is a complete development task network, and its formal description is made as follows:

Decompose(InitialDevProcess,DMS)→DevProcess(ProcessName,StartTask,EndTask,{AtomicDevTask})

Following, put the data model into the system, and then adopt the StartTask of development process to convert data model into initial-status middle model; its formal description is made as follows:

Execute(DataModel,DevProcess.StartTask)→InterBiz

Model(ModelName,{DataTable},Constraint, Ø,DevProcess.StartTask,{PostEffect},”Initial-status”)

The task-matching condition of the middle model can satisfy with the preconditions of subsequent tasks of StartTask; in such way, when the StartTask finishes, the subsequent development task can then be implemented continuously; such subsequent development task will work with the middle model to generate a task case, i.e.: the development work item in the activated status; its formal description is made as follows:

Execute(InterBizModel,DevProcess.AtomicDevTask) →DevWorkItem(Actor,{TransferRule},{PostEffect}},”Activated-status”)

The model transformation rule of development work item is derived from the mutual effect of model transformation template of middle template and atomic development task; its formal description is made as follows:

Generate(InterBizModel,DevProcess.AtomicDevTask.{TransferRuleTemplate})→DevWorkItem.{TransferRule}

When participant finishes the development work item,

271

the status of the development work item will be changed into the completion status, and its post-effect will be changed according to operation of participant; afterwards, modify the task-matching condition and status of middle model to generate a development activity that implements the model transformation operation; its formal description is made as follows:

Finish(DevWorkItem,DevWorkItem.Actor)→DevActivity({TransferAction})

The model operation sequence of the development activity is derived from the mutual effect of model transformation rule of participant and development work item; its formal description is made as follows:

Generate(DevWorkItem.Actor,DevTask.{TransferRule})→DevActivity.{TransferAction}}

After the model tier transfers the development activity, a transformation to the middle model will be completed, and thence a new middle model will be produced. At this moment the system will match the subsequent development task from the actual development process in accordance with the current task-matching condition of middle model, and new development activities will be generated to continue model transformation process till the business model appears.

Based on the previous introduction, the initial development process is a task sequence composed by atomic development task or composite development task to be implemented in a given sequence; its decomposition process is the key step of pattern hierarchy, and its basic idea is to decompose recursively the composite development task of initial development process into smaller and smaller development subtask till the atomic development task that can be implemented directly appears; finally an atomic development task network with the given sequence can be formed.

In order to complete the aforesaid decomposition process rapidly, the paper proposes a forward-searching recursive decomposition algorithm to realize the process; and its specific steps are defined as follows:

Step 1: acquire the development task sequence of initial development process, i.e. :

1 2{ , ,..., }n

T T T T� , and then acquire TaskGoal, the development goal of all tasks of the sequence to compose an initial goal assembly, i.e.:

1 2{ . , . ,..., . }n

TG T TaskGoal T TaskGoal T TaskGoal� ; where an initial development task network will be generated, i.e.: { , }DT StartTask EndTask� ; following turn to the Step 2 as follows:

Step 2: Select the composite development task (1 )iT i n� � in accordance with the sequence of

development task sequence; afterwards turn to the Step 3 as follow; end the calculation by adopting 1i i� � and i n� .

Step 3: Select the matchable decomposition method from the task decomposition method assembly of development pattern according to the decomposition conditions of current composite development task, and then decompose the composite development task by

adopting the method, finally the task network of 1 2{ , ,..., }i kN t t t� will be obtained, and then it will be

turned to the Step 4; if no corresponding decomposition method is found, it means the composite development task iT can not be implemented and will be deleted from T ; at this moment it will be turned to Step 2.

Step 4: Check if the current task network is empty; if not, select the task (1 )jt j k� � and turn to Step 5; otherwise obtain the upper task network of the current task network; if yes, implement the Step 4; otherwise turn to Step 2.

Step 5: Judge if the current development task is the atomic development task; if yes, turn to Step 6; if not, turn to step 3.

Step 6: Check if the post-effect of current atomic development task, i.e.: { }PostEffect , belongs to the assembly TG; if yes, it means the task does not need to be implemented and the task will be deleted from the current task network; afterwards it will be turned to Step 4; if not, turn to Step 7.

Step 7: Check if the precondition of the current atomic development task belongs to the assembly TG; if yes, it means the task needs to be implemented; afterwards it will be turned to Step 8; if not, the task will be deleted from the current task network and it will be turned to Step 4.

Step 8: Delete the precondition of current atomic development task of the assembly TG, and then add the { }PostEffect of the atomic development task; after the operation is done successfully, add the task into the task network DT and delete the task from the current task network; afterwards turn to Step 4.

Since some decomposition methods for some complicated development activities are stored in the development pattern, i.e.: the process knowledge, so it is allowable to avoid from searching the status space there is not available the feasible solutions so as to expedite the solving speed by describing the field knowledge of development process efficiently; therefore the algorithm can be used to lessen calculation complicacy and expedite decomposition speed.

V. EFFECTIVENESS ANALYSIS When developing under the DMDA and making same

application development with conventional methods, a comparison analysis was made on code amount, development time and other aspects to prove the rationality and effectiveness of the architecture. The specific practices are defined as follows, i.e.: on one hand we collected the code of samples from an EIS under the DMDA; on the other hand we re-developed the code of samples according to the conventional development modes. The Table 1 shows the comparison on the source code amount of two different development modes.

272

Table 1 Comparison Analysis on Source Code Amount of Two Different Development Modes

From Table 1 above, it can be seen under the same development task, the source code amount developed under the DMDA is reduced by 16% comparing with the one developed by adopting the conventional mode This value is not high, but it comprises the code amountgenerated by models; whereas the typical figure is the code amount wrote manually, and the former is reduced by 88% comparing with the latter; which means developer, under the DMDA, is only needed to write the code amount one tenth of the one obtained by adopting

the conventional development mode; which certifies the rapidity of tool development.

Except the issue to write code, EIS development comprises the creation and transformation process of model, which may cost some time too. Therefore the analysis on code amount does not represent the development time. Hereinafter a comparison on the time arising from tool development and conventional development mode, from the angle of system development and maintenance, is made as follows:

Table 2 Comparison and Analysis for Development Time of Two Different Development Modes Development time / day/person Conventional

development mode Development model based

on DMDASaved by

System development

Modeling time 1 3 -66%

Time to write code manually

30 8 73%

Test time 5 2 60%

System maintenance

Time to modify model 1 2 -50%

Time to modify code manually

10 3 70%

Test time 2 1 50%

Total 49 19 61%

From Table 2 above, it can be seen the cost is worthy, although the development mode under the DMDA costs more time for modeling and model modification comparing with that of conventional development mode; this is just because the development mode under the MDA lessens the time spent in code write, modification and test too much, and saves the integral development time by 61%; therefore it can be proved the DMDA is capable of improving EIS development productivity hugely.

VI. CONCLUSION The chapter discusses the concept, system structure

and operating mechanism of DMDA; its main research achievement includes the concept, basic idea and general system structure of DMDA proposed facing to development process and reuse for realizing development process by aiming to the shortcomings of MDA in EIS development field; the relevant model, for instance data model, middle model and business model, that has close relation with EIS development fields proposed after the conventional EIS development process is analyzed. Besides, the paper defines these models, studies and discusses the transformation process among them, makes formal description for the conventional EIS development process, decomposes the conventional EIS development process into multiple composition elements, for instance development task, development mode, development work and development activity, and then makes definition for mutual collaborative mechanism among all composition

elements and finally offers a forward-searching recursive decomposition algorithm to decompose the initial development process defined by developer. The practice proves the achievements offer a new and rapid development mode for EIS development enterprises.

REFERENCES

[1] Anneke G. Kleppe, Jos Warmer and Wim Bast, MDA Explained: The Model Driven Architecture: Practice and Promise. Boston, MA, USA. Addison-Wesley Longman Publishing Co., Inc. , 2003, pp. 2-3.

[2] Jing Zhang, Fang Kong, Jiwen Yang, “A component based fromodel driven ERP software development framework design,”

Microelectronics & Computer, vol. 24, no. 7, pp, 40-43,2007.[3] Object Management Group, UML2.0 Superstructure Specification.

OMG 2002. [4] Yulin Zhang, Weijun Zhong and Shue Mei, “ A Study in EIS

Development,” Application Research of Computers, vol. 8 pp.19-22, 2002.

[5] McConnel, Steve. Rapid Development . USA : Microsoft Press,1996, pp. 12-13.

[6] Coulson G., Blair G.S., Clarke M., Parlavantzas N. , “ The design of a highly configurable and reconfigurable middleware platform, ” Journal of ACM Distributed Computing, vol. 15, no.2, pp.109-126, 2002.

Source code quantity /kb Conventional development mode

Development model based on DMDA

Saved by

Source code introduction & realization

1400 1100 21%

Code wrote manually 22000 2500 88% Code generated by models 0 16000

Total 23400 19600 16%

273