Subodh Paudel

Mohamed Elmtiri

Wil L Kling

Olivier Le Corre
email: olivier.lecorre@mines-nantes.fr

Bruno Lacarrière

Pseudo Dynamic Transitional Modeling of Building Heating Energy Demand Using Artificial 1 Neural Network 2

Keywords: Building Energy Prediction, Short term building energy forecasting, Operational Heating 24 Characteristics, Occupancy Profile, Artificial Neural Network, Orthogonal Arrays 25 26 27 28

This paper presents the building heating demand prediction model with occupancy profile and 11 operational heating power level characteristics in short time horizon (a couple of days) using artificial 12 neural network. In addition, novel pseudo dynamic transitional model is introduced, which consider 13 time dependent attributes of operational power level characteristics and its effect in the overall model 14 performance is outlined. Pseudo dynamic model is applied to a case study of French Institution 15 building and compared its results with static and other pseudo dynamic neural network models. The 16 results show the coefficients of correlation in static and pseudo dynamic neural network model of 0.82 17 and 0.89 (with energy consumption error of 0.02%) during the learning phase, and 0.61 and 0.85 18 during the prediction phase respectively. Further, orthogonal array design is applied to the pseudo 19 dynamic model to check the schedule of occupancy profile and operational heating power level 20 characteristics. The results show the new schedule and provide the robust design for pseudo dynamic 21 model. Due to prediction in short time horizon, it finds application for Energy Services Company

22

(ESCOs) to manage the heating load for dynamic control of heat production system.

Introduction 29

The global concerns of climate change and regulation in energy emissions have drawn more showed that occupancy profile has a significant contribution in determination of auto regressive terms 119 during different intervals of time and further showed a variation of it in the building heating and cooling 120 energy consumption. The proposed ARX model showed similar performance with neural network.

121

Sensitivity analysis for heating, cooling, hot water, equipment and lighting energy consumption based 122 on occupancy profile was performed by Azar et al. [31] for different sizes of office buildings. In their 123 work, they found that heating energy consumption has the highest sensitivity compared to cooling, hot 124 water, equipment and lighting energy consumption for small size buildings. Also, results showed that 125 heating energy consumption is highly influenced by occupancy profile for medium and small buildings 126 during the occupancy period. Moreover, few literatures focused on operational power level 127 characteristics (schedule of heating and cooling energy to manage energy production from plant 128 system). For example, Leung et al. [32] used climate variables and operational characteristics of 129 electrical power demand (power information of lighting, air-conditioning and office equipment which 130 implicitly depends on occupancy schedule of electrical power demand) to predict hourly and daily 131 building cooling load using neural network.

132

In conclusion, it can be reiterated that physical and semi-physical models [4][5][6][7][8][9][10][11], though give 133 precise prediction of building energy, they are highly parameterized and are computationally expensive 134 to manage the energy for control applications for ESCOs. Data-driven methods which depend on 135 measurement historical data are not effective during the early stage of building operation and 136 construction since measurement data are not available at these stages. When building energy data 137 are available, data-driven methods can be considered if measurement data are accurate and reliable 138 as this kind of models can be sensitive on the quality of measured data. Sensitivity of the accuracy of 139 data driven models, thus, depends on the measurement data. Data-driven models based on statistical 140 and regression methods [12][13][14][15]26] cannot precisely represent short time horizon (couple of days) 141 with hourly (or couple of minutes) sampling time prediction, though they perform prediction of energy 142 consumptions of buildings with limited physical parameters. They also require significant efforts and 143 time to compute the best fitting of the actual data. Static neural network models [19][20][21] are used for 144 daily prediction and [22][23][24][25] are used for hourly prediction of the buildings energy consumptions.

145

Though dynamic neural network model [27][28] gives better precision in compared to static neural 146 network, they do not consider occupancy profile and operational power level characteristics of the 147 plant system and therefore not adapted for the ESCOs to manage energy production for control variables and application of models developed in the literature reviews are summarized in Table 1.

152

None of these studies has evaluated the transition and time dependent effects of operational 153 power level characteristics of heating plant system and has predicted building heating energy demand 154 in short time horizon (a couple of days). This short term prediction is important to ESCOs for dynamic 155 control of heat plant system. This paper bridges the gap between static and dynamic neural network 156 methods with occupancy profile and operational power level characteristics of heating plant system. It 5. The wind speed and direction are not taken into consideration. This is due to the fact that 202 present weather variables data are taken from data acquisition system but future weather 203 variables values are coming from an atmospheric modeling system which mesh size can be 204 15 km (as ARPEGE, see [33]), 10 km (as ALADIN, see [34]) or 2.5 km (as AROME, see [35]).

205

In such a case, wind impact on heating demand prediction of a specific building located inside the mesh is very difficult or even impossible to consider for precise effect. Further, heating 207 energy demand is highly dependent on outside temperature and other climate variables have 208 less significant impact on heat energy [36].

211

The operational heating power level characteristics gives operational features of the plant system, 212 however, they do not give abstract information about transition attributes of operational heating power 213 level which is illustrated through an example in figure (2). The y-axis represents set up power level 214 from the production system and x-axis represents operation schedule. 227

      2 , 1 , ... 7 , 5 , 3 ....., 8 , 6 , 4 , 2 0 2 2 2 2              u v v u v u uv v u uv       (1)

228

where, 0  ,   and represents initial power level, step size of transition power level and absolute values respectively. In figure (4), delay represents time it takes from plant system to reach the building for heating 241 operation and after this, power is sufficient to provide heating demand. The  represents the 63% of 242 power transferred to the building heating system from plant system. Other dynamics to incorporate is 243 settling time ( s T ), which is the time elapsed for heating power to reach and remain within the specified

300

for normalization of input and output variable, and for this paper, normalization with zero mean and 301 unit standard deviation is done as shown in equation (4). In equation (4), x , i X and m represents 302 mean of input variable, overall vector of input variable and number of datasets respectively and thus,

303

applies similarly for output variable.

304

 

x x x x T T T T T e e e e x h           , (3) 305        i i i i x x m x x 1 1 X (4)

306

The cost function of MLP network is computed in equation ( 5):

307         2 1 2 1     m l l a l y y m J  (5)
where y , a y , l and    J represents predicted values produced from the network, actual values of 309 given datasets, individual data from m number of datasets and cost function of the neural network 310 model respectively. Further, y of the network is computed as:

311              p k i q i ki k x h y 1 0   (6)

312

In order to update the model parameters for a higher degree approximation on unknown non-313 linear function for learning process, there are different methods as -gradient descent, Newton's 314 method and so on [37]. Gradient descent is too slow for the convergence, and it takes more time to 315 compute the hessian matrix in Newton's method as well. Levenberg-Marquardt algorithm is used for 316 this paper which takes approximation of hessian matrix in the form of Newton's method and model 317 parameter update equation

1  t  is given as: 318           J L I L L T T t t 1 1      (7)

319

In equation ( 7), hessian matrix is approximated as [ L L T ] and gradient is computed as

   J L T , 320
where, L is Jacobian matrix,  

328

The maximum failures in validation or accuracy over validation datasets is defined to stop the 329 learning process if the accuracy of learning datasets increase and validation accuracy stays same or 330 decrease. 347

Model

    y w w x L L L L L * 1 * 1      (12)

348

DOF of neural network model is the difference between number of learning equations and 349 number of model parameters in the network. It should be always >>1 and depends on the optimum 350 size of hidden neurons. DOF and maximum hidden neurons are given by equation ( 13) and ( 14), the maximum hidden neurons.

353

 L L e   DOF (13)     1 1 max     y x y L L L L W   (14)

366

It is essential to know whether schedule of occupancy profile and operational characteristics 367 obtained from ESCOs is reliable for the robust design of pseudo dynamic model. Occupancy profile performance and if all these transition period are consider for finding the best robust model, it takes 370 long time to compute. Orthogonal arrays (OA) identify the main effects with minimum number of trials 371 to find the best design. These are applied in various fields: mechanical and aerospace engineering

372

[40], electromagnetic propagation [41] and signal processing [42] for the robust design model.

373

The orthogonal array allows the effect of several parameters to find best design with given

390

The data is taken from data acquisition system and consists of day/month/time, solar radiation,

398

The simplified/theoretical occupancy profile and operational heating power level characteristics 399 for working and off-days for 24 hours is shown in figure ( 6) and ( 7).

400

404

from 18 hour onwards, power demand characteristics is not accordance with occupancy profile. Thus,

405

it further shows that simplified occupancy profile is not enough to characterize the heating demand.

406

424

x L equals to 10. Transitional and pseudo dynamic characteristic with four lags during working day is

425

shown in figure ( 9). Transition level in figure ( 9) is calculated from equation ( 1) and for this case study, 5) is computed iteratively up to 1000 for each

437

of the minimum and maximum number of hidden neurons. The maximum number of hidden neurons is 438 calculated from equation ( 14), where  is chosen 8 as it gives the flexibility in the degree of model 439 parameters. Thus, three minimum hidden neurons are chosen as 3 for this case study. Hidden 440 neurons length ( w L ), thus, is varied from 3 to max W . Performance of model at each iteration (number 441 of epochs) is computed from equation ( 16) and ( 17) and model parameters are updated based on 442 equation ( 7), where initial value of  is chosen as 0.01 and its value is increased with a factor of 10 443 and decreased with a factor of 0.1. The maximum value of  is chosen as 1e10. Neural network 444 model in this study will be stopped if the number of epochs reached to 1000 and performance goal 445 reached the value given by equation ( 15).

446

Under the scope of study (see subsection 2.1), the accuracy on the number of occupants are 447 not relevant, however, it is essential to know inside the sampling time, when the staff and students

514

For the robustness of pseudo dynamic model, orthogonal arrays are applied to determine the 515 highest coefficient of correlation for learning and validation for the optimum 9 hidden neuron size of 516 model 6. Table (5) shows OA(729,10,3,5) and coefficient of correlation for learning and validation 517 phase. It is clear from table (5) that the schedule taken from the ESCOs is from experiment 1 and from 518 the orthogonal arrays, the optimal schedule that fits the best for model 6 is experiment 398. The

537

However, there is a fluctuation in the power demand in the morning for each consecutive 4 days and it 538 is difficult to learn datasets which transits rapidly in actual power demand. The prediction of heating 539 demand for model 6 during testing phase after optimum orthogonal array design is shown in figure 540 (14). It is vivid that pseudo dynamic model is able to predict heating demand, however during the third 541 day, the pseudo dynamic model is not able to meet 1.1 MW of heating demand. This is due to the fact 542 that neural network does not learn this threshold maximum heating demand in the learning phase as 543 this kind of information is not available in the database. This data, thus, needs to be improved in the

novel pseudo dynamic transitional model is introduced. A large building is considered for application The minimum energy consumption error is achieved and is 0.02% for the learning phase and is 2.39% orthogonal array design is applied to the pseudo dynamic model (the schedule of occupancy profiles and operational heating power level characteristics) application for energy operator to manage the heating load for the dynamic control of the heat production system *Highlights (for review)

  157 introduces novel pseudo dynamic model, which incorporates time dependent attributes of operational 158 power level characteristics. Their effects on neural network model performances are compared to 159 static neural network for building heating demand. Orthogonal arrays are applied to the proposed 160 pseudo dynamic model for robust design and confirmed the new schedule of occupancy profile and 161 operational heating power level characteristics obtained from ESCOs. The proposed method allows 162 short term horizon prediction (around 4 days with sampling interval of 15 minutes) to make decision 163 (e.g. management of wood power plant) for the ESCOs. The next section describes methodology 164 including scope of study, design of transitional and pseudo dynamic characteristics, neural network 165 model and orthogonal arrays. Finally, a case study is presented and results and discussion are drawn 166 to analyze the performance of different static and pseudo dynamic models along with robustness of 167 proposed pseudo dynamic model for heating demand prediction of the building.

179Figure 1 : 1 .

 11 Figure 1: Outline of the proposed methodology on heating demand prediction

192 2 .

 2 Existing building is considered and space heating demand of this building is fed up from a heat 193 network to a central substation. Domestic hot water (DHW) is out of the scope.1943. The heating demand data was recorded in data acquisition system database and thermal 195 comfort inside the building was performed in this database. Thus, the effects of ventilation and 196 air-conditioning on heating are already included in this database.

197 4 .

 4 Simple occupancy profile of building is anticipated approximately to assist the ESCOs to 198 schedule their heat production system. In such a system, individual occupant's behavior or 199 precise occupancy profile is not considered. Thus, the modeling constraints are closer to the 200 operational condition of ESCOs to estimate the heat demand.

  201

  215

Figure 2 :

 2 Figure2: Operational heating power level characteristics of the plant system (for a day)

244 280 Figure 5 :

 2805 Figure 5: Neural Network Architecture

  cost function, t  is initial model parameter,  is 321 suitable chosen scalar and I is identity matrix. Update model parameter, thus, depends on the cost 322 function and scalar value  .

  criteria for stopping the neural network model. For this paper, the stopping 325 criteria depend on number of epochs to learn the network, performance goal, maximum range of  326 and maximum failures in the validation. The performance goal (PG) is given as:

  Performance332Performances of models are characterized by mean square error (MSE) and coefficient of 333 issues of neural network model is over learning of the network. With increase of 338 hidden neurons, model performance can be increased, but, it will lead neural network to over learning.339Validation accuracy and degree of freedom (DOF) adjustments are done in this paper to avoid over 340 fitting. Number of learning equations that model could deliver are given by equation(11), where e L is 341 learning equations of the network and y L is length of vector output neurons ( y ), and in this case 342 equal to 1 since there is only heating demand load.

  model parameters for a single hidden layer MLP neural network are given by 345 the equation (12), where  L , x L and w L represents number of model parameters, vector length of 346 input neurons ( i x ) and vector length of hidden neurons ( k w ) respectively.

355

  Modified performance goal according to degree of freedom adjustment is given as: also further modified based on degree of freedom adjustment. The 358 is performed for learning and validation, 364 and based on it, optimal configuration of model is identified for the final prediction.

391

  outside air temperature and heating demand from mid of January to February 2013 with sampling 392 interval of 15 minutes. The 70% of data (outside temperature, solar radiation and heating demand as 393 shown in figure 5) are used for learning phase i.e. in mathematical equation in neural network, see 394 section 2.3, equivalent to 19 days with 15 minute sampling time, and each 15% of data (4 days with 15 395 minute sampling time) is used for validation and testing phase. Outside temperature taken for this study has minimum, average and maximum value of 1

Figure 6 :Figure 7 :

 67 Figure 6: Occupancy profiles for working and off-day

Figure 8 :

 8 Figure 8: Heating power demand and occupancy profile during working days

Figure 9 :Figure

 9 Figure 9: Transitional and pseudo dynamic characteristics during working day

448

  come and leaves the buildings. It is necessary to check occupancy and operational power level characteristics provided by ESCOs are right or not for robust design model. And, the main controlling 450 factors for robust design model are the transition schedule of occupancy and operational 451 characteristics. From figure (6), it is clear that there is no transition of occupancy during off-day, but 452 there is transition of occupancy during the interval at 8 hour, 12 hour, 13:30 hour and 17:45 hour and 453 these are represented by t1, t2, t3 and t4 factors respectively. Similarly, there is a transition of 454 operational characteristics for working and off day as shown in figure (7) and these transition factors 455 are represented by t5, t6, t7 and t8 for working day for 6 hour, 12 hour, 14 hour and 20 hour; t9 and 456 t10 for off day for 6 hour and 20 hour. Since the sampling interval taken for this case study is 15 457 minutes, three levels are used for orthogonal arrays so that the model will represent the 15 minutes 458 ahead and before from occupancy and operational characteristics schedule period. The summary of 459 control factors and their levels are shown in table (3), where OSW represents occupancy schedule at 460 work day, OCSW represents operational characteristics schedule at work day and OCSO represent 461 operational characteristics schedule at off day. 462 Table 3: Summary of control factors and their levels 463 Thus, there are 10 factors and 3 levels that govern the robustness of the model and if the full464 factorials are used to generalize the model, it takes 3 10 = 59049 experiments. The orthogonal arrays 465 reduce the number of experiments to 729 with 5 strengths. OA (729,10,3,5) is applied to the proposed 466 pseudo dynamic model in this case study.

Figure 11 :

 11 Figure 11: Coefficient of correlation performance (Model 5)

488

  operational characteristics are not enough to determine and generalize the unknown function of the 489 building heating demand. As transitional attributes of operational characteristic is introduced in model significantly from 0.82 to 0.87 for learning phase and from 491 0.81 to 0.85 for validation phase and correspondingly ified mod MSE decreases in contrast to model 1. 492 Pseudo dynamic transitional attributes in model 3 and time constant  in model 4 leads increase in 493 model performance. Further, dynamics of settling time and steady state plays an important role in 494 characterizing the neural network model. It is seen that for learning and 0.85 to 0.87 for validation in model 5 compare to model 2 although transition 496 attributes is introduce in model 2. In addition, hidden neuron size is also reduces from 19 to 13. 497 Moreover, it is distinguish that learning and validation performances remained the same in the model 6 498 compared to model 5. The optimal choice of the model, thus, lies in between settling and steady state 499 time. 500 It can be further view that model 5 and model 6 show reasonable and consistent model 501 performances. However, minimum hidden neuron size and maximum learning criteria is essential for performance ified mod 2 R remained the same (0.89) in model 6 comparing to model 5, model 6 is 504 chosen as the best configuration of the overall models. The optimal choice of the model 5 and model 6 505 can be delineated by the error in percentage of energy consumption (kWh) in actual and prediction for 506 the learning and validation phase. Heating energy consumption error in actual and prediction in 507 learning phase in Model 6 is 0.02% compare to 0.32% in Model 5. For validation phase, heating 508 energy consumption error is 2.39% in Model 6 compare to 2.57% in Model 5. From this energy 509 consumption error, it is clear that there is a small heating energy consumption error in Model 6 510 compare to Model 5 during the learning and validation phase. So, one can conclude that Model 6 can 511 be chosen as optimal configuration of the overall model. The model 6, thus, bridges the gap between 512 static and dynamic neural network model in the sense that it is better than static model and increases 513 the performance comparable to dynamic neural network model.

519

  orthogonal arrays, thus, ensures that there is transition in occupancy in 7:45 hour, 12 hour, 13:45 hour 520 and 18 hour instead of 8 hour, 12 hour, 13:30 hour and 17:45 hour period in the existing case 521 respectively. There is also a transition in 5:45 hour, 11:45 hour, 14 hour and 17:45 hour instead of 6 522 hour, 12 hour, 14 hour and 17:45 hour for working day; 5:45 hour and 20 hour instead of 6 hour and 523 20 hour in off days for operational characteristics. The coefficient of correlation after the orthogonal 524 array design is 0.90 for learning, 0.88 for validation and 0.86 for training phase. Nevertheless, other 525 issue of overall model is that it is difficult to increase the coefficient of correlation beyond 0.90 and this 526 is due to the sampling time of 15 minutes. With short sampling time, it is very difficult to learn the ified mod 2 R value of 0.90 during the learning phase is always acceptable. Coefficient of correlation of linear regression obtained from neural network model in the actual 531 and prediction of heating demand for learning, validation and testing phase of Model 6 after optimum 532 orthogonal array design are 0.95, 0.95 and 0.93 respectively. The prediction of heating demand for 533 model 6 after optimum orthogonal array design during validation phase is shown in figure (13).

534

  Prediction gives the power heating demand and the area under the curve gives the heating energy 535 demand. From figure (13), it is clear that heating demand tremendously increases approximately 990 536 kW during third and fourth day and pseudo dynamic model is able to predict and learn the behavior.

544Figure 13 :Figure 14 :Figure 1 :Figure 3 :Figure 4 :

 1314134 Figure 13: Prediction of heating demand in model 6 during validation phase (after optimum orthogonal

Figure 7 :

 7 Figure 7: Operational heating power level characteristics for working and off-day

168 Table 1 :

 1681 Summary of variables and application models in the literatureThe development and implementation of models proposed in this work are based on collection of 171 real building heating demand, operational heating power level characteristics, climate variables and steady state time and is estimated from real building data. Based on operational heating power level 178 and dynamics of building characteristics, transitional and pseudo dynamic models are designed.

	169
	170	2. Methodology

Table 4 :

 4 Optimal configuration of models 486

	487	Table (4) shows that with static neural network model 1, best	R	2	mod	ified	for learning and
		validation can be obtained up to 0.82 and 0.81. From this, it is clear that occupancy profile and

Table 1 :

 1 Summary of variables and application models in the literature

			Ambient Dry Bulb Wet Bulb
	Girardin et al. [12] (2009)	Statistical	√

Table 1 5 6 7

 16

Table 5

 5

level characteristics of the plant system are still missing, though, authors[29][30] consider occupancy

profile and author[32] considers operational characteristics of electrical power demand. The detailed

approximated occupancy profile data (see Appendix A for selection of relevant input variables). An

outline of the methodology presented in this paper is shown in figure[START_REF] Laustsen | Energy efficiency requirements in building codes, energy efficiency policies for 1*: Nominal Temperature of heating, cooling and hot water system[END_REF]. The input of this methodology

is in form of time-series climate and building heating energy data. The other inputs data are occupancy

profile and operational heating power level characteristics for working and off-days for 24 hours.

depends on the power level of operational characteristics.

The neural network consists of neurons to interconnect the inputs, model parameters and

and operational characteristics transition period, thus, plays an important role in the model

and testing for different hidden neurons sizes of model 5 and from this optimal configuration is chosen

datasets which changes in 15 minutes sample, nonetheless, for good generalization of the model,

Table 5: OA (729,10,3,5) and coefficient of correlation for learning and validation for model 6

buildings. Coefficient of correlation increases from 0.82 to 0.89 for learning, 0.81 to 0.87 for validation

(http://www.iea.org/publications/freepublications/publication/Building_Codes.pdf )

X. Li, C.P. Bowers, T. Schnier, Classification of Energy Consumption in Buildings with outlier

K.K.W Wan, D.H.W Li, D. Liu, J.C. Lam, Future trends of building heating and cooling loads

and energy consumption in different climates,Building and Environment 46 (2011) 223-234.

R. Yokoyama, T. Wakui, R. Satake, Prediction of energy demands using neural network with

neural networks in Denizli-Turkey, Advances in Engineering Software 41 (2010) 141-147.

P.A. Gonzalez, J.M. Zamarreno, Prediction of hourly energy consumption in buildings based

on feedback artificial neural network, Energy and Buildings 37 (2005) 595-601.

P. Popescu, F. Ungureanu, A. Hernàndez-Guerrero, Simulation models for the analysis of

space heat consumption of buildings, Energy 34 (2009) 1447-1453.

methods: a novel optimization technique in electromagnetics, IEEE Transactions on Antennas

and Propagation 55 (2007) 723-730.

ProababilityLetters, 65 (2003) 161-163.

C.Y. Suen, A. Dey, Construction of asymmetric orthogonal arrays through finite geometries,

Journal of StatisticalPlanning and Inference, 115 (2003) 623-635.

N.J.A. Sloane, A library of orthogonal arrays (Online).

http://www2.research.att.com/~njas/oadir/ (Access on : 28/04/2013)

Remarks:

and 0.61 to 0.85 for testing in pseudo dynamic comparing to static neural network model. Also, the 562 size of hidden neuron is further reduced, which reduces complexities and increases generalization of 563 the model. Moreover, minimum energy consumption error is achieved in pseudo dynamic model as 564 0.02% for learning and 2.57% for validation phase. Further, orthogonal array is applied to optimal

575

Further, research will be focused towards the feature extraction of data before learning phase of 576 the neural network so that abnormalities in the data can be corrected in the learning phase. Also 577 adaptive and real time learning criteria with seasonal behaviour will be studied.

Acknowledgement

579

This research has been done in collaboration with Ecole des Mines, Nantes, Technische Universiteit

689

The influence of input variables on the model output is evaluated based on the correlation analysis.

690

Correlation measures the strength and weakness of linear relationship between two variables. There

The correlation coefficients can range from -1 to +1:


Yu Sun
email: yusun@cis.uab.edu

Jeff Gray
email: gray@cs.ua.edu

Romain Delamare
email: rdelamare@cs.ua.edu

Benoit Baudry
email: benoit.baudryg@irisa.fr

Jules White
email: julesw@vt.edu

Automating the Maintenance of Non-functional System Properties using Demonstration-based Model Transformation

Domain-Specific Modeling Languages (DSMLs) are playing an increasingly significant role in software development. By raising the level of abstraction using notations that are representative of a specific domain, DSMLs allow the core essence of a problem to be separated from irrelevant accidental complexities that are typically found at the implementation level in source code. In addition to modeling the functional aspects of a system, a number of non-functional properties (e.g., quality of service constraints, timing requirements) also need to be integrated into models in order to reach a complete specification of a system. This is particularly true for domains that have distributed real-time and embedded needs. Given a base model with functional components, maintaining the non-functional properties that crosscut the base model has become an essential modeling task when using DSMLs.

The task of maintaining non-functional properties in DSMLs is traditionally supported by manual model editing or using model transformation languages. However, these approaches are challenging to use for those unfamiliar with the specific details of a modeling transformation language and the underlying metamodel of the domain, which presents a steep learning curve for many users. This paper presents a demonstration-based approach to automate the maintenance of non-functional properties in DSMLs. Instead of writing model transformation rules explicitly, users demonstrate how to apply the nonfunctional properties by directly editing the concrete model instances and simulating a single case of the maintenance process. By recording a user's operations, an inference engine analyzes the user's intention and generates generic model transformation patterns automatically, which can be refined by users and then reused to automate the same evolution and maintenance task in other models. Using this approach, users are able to automate the maintenance tasks without learning a complex model transformation language. In addition, because the demonstration is performed on model instances, users are isolated from the underlying abstract metamodel definitions. Our demonstration-based approach has been applied to several scenarios, such as auto-scaling and model layout. The specific contribution in this paper is the application of the demonstration-based approach to capture crosscutting concerns representative of aspects at the modeling level. Several examples are presented across multiple modeling languages to demonstrate the benefits of our approach.

Introduction

Domain-Specific Modeling (DSM) [START_REF] Gray | Domain-Specific Modeling[END_REF] has become an important part of Model-Driven Engineering (MDE) [START_REF] Schmidt | Special Issue on Model-Driven Engineering[END_REF] to address the complexity of software systems. A Domain-Specific Modeling Language (DSML) can be used to declaratively define a software system with specific domain concepts. Various software artifacts (e.g., source code, simulation scripts, XML deployment description files) can be generated automatically from the models. By raising the level of abstraction, DSM helps to protect key intellectual assets from technology obsolescence, resulting in less effort and fewer low-level details to specify a given system, which can lead toward improvements for supporting end-user development [START_REF] Burnett | End-user Software Engineering[END_REF].

Although much effort has been focused on using DSMLs to specify the functional properties of a system, the correct and complete specification of non-functional properties is also critical in many domains such as distributed systems, embedded systems, or large-scale applications. The non-functional properties range from performance, timing, and Quality of Service (QoS) constraints, to some behavior requirements such as logging and concurrency control. Although several modeling tools (e.g., GME [START_REF] Ledeczi | Composing Domain-specific Design Environments[END_REF], GMF [START_REF]Graphical Modeling Framework (GMF[END_REF], GEMS [START_REF]Generic Eclipse Modeling System (GEMS[END_REF]) have been developed to allow users to define various types of DSMLs and instantiate model instances, the tools to support the maintenance of non-functional properties in a DSML are not welldeveloped. In most situations, manual maintenance has to be done through the basic operations provided by the editing environment, which is tedious, error-prone, and time-consuming, particularly when the base model is large and complex. A manual process for maintaining model changes often involves repeated and complicated changes and computations [START_REF] Gray | Automating Change Evolution in Model-Driven Engineering[END_REF].

An alternative for automating the maintenance of non-functional properties with DSMLs is to use executable Model Transformation Languages (MTLs) [START_REF] Sendall | Model transformation -The Heart and Soul of Model-Driven Software Development[END_REF], which can define a set of transformation rules that specify how to add, remove, or modify the non-functional properties in a base model. Although MTLs are very powerful and expressive for handling a wide range of non-functional properties in diverse DSMLs, using a transformation language is not always the perfect solution. Firstly, even though most MTLs are high-level declarative languages, they have a steep learning curve due to the complexity of their syntax, semantics, and other special features (e.g., OCL [START_REF]Object Management Group, Object Constraint Language Specification[END_REF] specification is used in many MTLs). Moreover, model transformation rules are often defined at the metamodel level, rather than in the context of a concrete model instance, which exposes users to abstract metamodel concepts. Because many potential model users (e.g., requirements engineers, domain experts) are not necessarily software engineers or programmers, learning transformation languages and understanding the formal syntax definitions may be beyond their capability. Such challenges may prevent some users from realizing nonfunctional property maintenance tasks for which they have extensive domain experience. Consequently, this leads to an irony that a technology (i.e., DSM) meant to enable end-users to participate in the specification of functional components of a software system does not enable end-users to manage the non-functional properties easily.

To overcome the problem and provide an end-user approach to support automating the maintenance of non-functional properties in DSMLs, we have been investigating and extending the idea of Model Transformation By Demonstration (MTBD) [START_REF] Sun | Model Transformation by Demonstration[END_REF], which applies a demonstration-based approach to enable users to specify the desired maintenance process of non-functional properties and execute the process to any model instance through an execution engine. The goal of the approach is to assist general model users (e.g., domain experts and non-programmers) in realizing the automated maintenance of nonfunctional properties in DSMLs without knowing a specific model transformation language or the metamodel definitions.

This paper provides the following contributions to the study of non-functional system property maintenance in DSMLs:

• We describe how MTBD is extended and adapted to support the demonstration of non-functional system property maintenance tasks in a DSML (including a user refinement mechanism and an updated transformation engine to enable users to accurately specify where to apply the properties and how to apply them) without using MTLs or exposing metamodel definitions to end-users. • We present how MTBD can generalize and infer a transformation pattern that can be used to automate the whole maintenance process through an execution engine, as well as how users can refine the pattern. • We select two typical non-functional system property maintenance tasks (i.e., adding a logging mechanism and applying QoS strategies) in DSMLs that have already been solved using MTLs, and present the new solutions using MTBD. • We present an evaluation by comparing efforts (based on operational effort to perform the same tasks) between the two approaches to solve the exact same tasks. This evaluation identifies the key advantages of using MTBD over using MTLs in the maintenance of non-functional system property tasks.

Motivating Examples of Non-Functional Properties in Models

This section presents two examples that motivate the need for automating the maintenance of nonfunctional system properties in different DSMLs. For each of the examples in Sections 2.1 and 2.2, background information about the specific application domain and the context of the DSML will be given, followed by an illustration using a concrete model instance. Then, we present a typical non-functional system property maintenance scenario in the domain, and describe the desired model instance after the maintenance of these properties. The challenges of accomplishing each task will be summarized afterwards. We have used both of these examples in previous efforts focused on MTLs [15][16]. In this paper, we compare our new approach that is focused on end-user demonstration to the more traditional approach that uses MTLs. The solution of using MTBD to address the exact same problems will be given in Section 3, so that a better comparison can be made between the traditional MTL approach and the new MTBD approach.

Maintaining Non-Functional System Properties in ESML Models

The Embedded Systems Modeling Language (ESML) [START_REF] Karsai | Model-Driven Architecture for Embedded Software: A Synopsis and an Example[END_REF] is a DSML used to graphically model realtime mission computing embedded avionics systems. ESML is specifically designed for modeling component-based avionics application deployment and distribution middleware infrastructure, which allows users to model the system from several different aspects such as Interfaces, Events, Components, Interactions, and Configurations.

Figure 1 shows an excerpt of an ESML model specified for one usage scenario. The top of Figure 1 illustrates the interaction among components in a mission-computing avionics application. The set of components collaborate to process a video stream that provides a pilot with real-time navigational data. The bottom of Figure 1 shows the internal representation of two components (Display_Device and AirFrame_SynchProxy), revealing the data elements and other constructs used to describe the infrastructure of component deployment and the distribution middleware. An event-driven model is implemented for the infrastructure that enables different components to update and transfer data to each other through event notification and callback methods.

Maintaining Non-Functional Properties in ESML. The need to maintain non-functional properties in ESML models arises from the requirement to apply non-functional properties to each Data in the components. For instance, different logging mechanisms (e.g., LogOnRead and LogOnWrite) can be added to each data element to realize the recording policy of a black-box flight data record; specific constraints are occasionally required to attach the data element as preconditions to assert a set of valid values when a client invokes the component at runtime; in some cases, concurrency elements (e.g., Internal Locking and External Locking) specifying the synchronization strategy should be distributed across the components.

As the first example used in this paper, we choose the task of adding a logging mechanism for each data element, which is defined as follows:

Example 2.1: In each implementation Component (i.e., the name of the component ends with "impl"), if an Action exists in the Component, a LogOnRead logging element should be attached to every Data element in the Component.

The tasks of adding data constraints and synchronization policies share a similar process as Example 2.1, and therefore can be solved using the same approach. A correct process of maintaining these nonfunctional properties involves navigating the model and locating the correct places to insert the nonfunctional properties, and then adding the correct non-functional elements and specifying the corresponding attributes. Although the maintenance process can be done by manual editing, it is tedious, time-consuming, and error-prone, particularly when the base model is large and complex (e.g., the partial system model shown in Figure 1 is only a subset of a system with thousands of components). Thus, an automated process can benefit the maintenance process when evolving model properties.

Maintaining Non-Functional System Properties in QoSAML Models

The maintenance and evolution of distributed real-time and embedded systems is often challenging because of the consideration of different Quality-of-Service (QoS) constraints that might conflict with each other and must be treated as trade-offs among a series of alternative design decisions [START_REF] Gray | Concern Separation for Adaptive QoS Modeling in Distributed Real-Time Embedded Systems. Behavioral Modeling for Embedded Systems and Technologies: Applications for Design and Implementation, Idea Group[END_REF]. The QoS Adaption Modeling Language (QoSAML) [START_REF] Gray | Concern Separation for Adaptive QoS Modeling in Distributed Real-Time Embedded Systems. Behavioral Modeling for Embedded Systems and Technologies: Applications for Design and Implementation, Idea Group[END_REF] was designed to address the challenges of using an MDE approach, which uses a finite state machine representation extended with hierarchy and concurrency mechanisms to model the QoS adaptive behavior of the system.

One successful usage of QoSAML is to specify the QoS properties for an Unmanned Aerial Vehicle (UAV) [START_REF] Karr | Application of the QuO Quality-of-Service Framework to a Distributed Video Application[END_REF]. A UAV is an aircraft that is capable of surveying dangerous terrain and territories. The UAV continuously sends video streams to a central distributor, so that operators can observe the video and give further commands to the UAV. In order to reach a precise and timely response from operations, a smooth video stream must be guaranteed, which means that the video must not be stale, or be affected by jittering. However, due to the changing conditions in the surveillance environment, the fidelity of the video stream must be maintained by adjusting the QoS parameters. For example, as shown in Figure 2, in good conditions where a reliable network transmission is available, a smooth video stream can be kept using a high video Size and a high video FrameRate, while in a poor environment, both video Size and FrameRate should be reduced in order to keep the same video transmission latency. ) from the QoSAML models automatically, which can be integrated into the runtime kernel of the system [START_REF] Gray | Concern Separation for Adaptive QoS Modeling in Distributed Real-Time Embedded Systems. Behavioral Modeling for Embedded Systems and Technologies: Applications for Design and Implementation, Idea Group[END_REF].

Maintaining Non-Functional Properties in QoSAML. The model in Figure 3 is not complete, because the transitions between different states have not been specified. A transition connects a source state to a target state, representing how a control parameter can be changed and adapted. To give the transitions, there are two different strategies that can be used, as illustrated in Figure 4. The left side of the figure specifies a protocol that exhausts the effect of one independent parameter (Size) before attempting to adjust another independent parameter (FrameRate). In other words, the FrameRate parameter has a higher priority so that it is not reduced or increased until there is no further reduction or increment possible to the Size. By contrast, the strategy in the right side of the figure is more equitable, with a zigzag pattern suggesting that the reduction or the increment of one parameter is staggered with the reduction or the increment of another [START_REF] Gray | Concern Separation for Adaptive QoS Modeling in Distributed Real-Time Embedded Systems. Behavioral Modeling for Embedded Systems and Technologies: Applications for Design and Implementation, Idea Group[END_REF]. From this scenario, it can be seen that weaving the strategy protocols becomes a challenging task when more control parameters are involved, or a large number of intermediate states are included in the state. As the second example for this paper, we choose the task of weaving the priority exhaustive protocol to the QoSAML model, which is defined as follows:

Example 2.2: In a given state machine, for each pair of two states included in the state machine, if their priority data are less than 5, and if the priority data of one state is one less than the other, add a transition between the two states from the state with the lower priority (SourceState) to the one with the higher priority (TargetState). In addition, set up the attributes for the transition: the Guard of the transition should be given from the users input, and the Action of the transition should be in the format of "ControlParameterName = (SourceState.Max + TargetState.Max) / 2)."

For example, Figure 5 shows the model after applying the priority exhaustive protocol to Size State and FrameRate State. The challenges of this task result from locating all pairs of the states that consist of the qualified priority data (i.e., SourceState.Priority = TargetState.Priority -1, SourceState.Priority < 5, TargetState.Priority < 5), performing the repeated computation to obtain the average value from the two Max data, as well as enabling user input. We have extended the MTBD concept to non-functional property maintenance tasks, so that it can be used to demonstrate the specific maintenance process and generate a reusable pattern to automatically realize the process to the rest of the model, as well as other model instances.

Figure 6. High-level overview of using MTBD to address non-functional property maintenance

Figure 6 is an overview of the approach. In any non-functional property maintenance task, two fundamental specifications are required to precisely define a task. First, we need to specify the "where" (i.e., the locations in the models where the non-functional property or behavior emerges). The desired locations can be specified through constraints on its structure (i.e., the presence of required model elements and connections) and attributes (i.e., the model elements and connections with qualified attribute values). Second, we need to specify the "what" (i.e., the specific composition of the non-functional properties or behavior). As shown in the two examples, a non-functional property can contain various types of actions ranging from adding new elements or connections (removing and modifying elements and connections also happens in some tasks), conducting computations, asking for user input and initializing attributes. Using the MTBD approach, users can simply select one of the qualified locations, and then perform the necessary non-functional property maintenance tasks on the specific location. At the same time, the recording engine captures all the information about the demonstration, and later generalizes an initial pattern from the user's demonstrated behavior. Because the initial pattern may not reflect the precise specification about the locations, refinements are enabled in the extended MTBD to allow a user to provide more detailed feedback in order to restrict the pattern in terms of the structure and attributes. The pattern is finalized after the refinement, and can be executed and applied to the whole model instance to realize the complete weaving process.

In Section 3.1, we explain the approach with more implementation details about each step, along with solving the motivating Example 2.1. Section 3.2 continues to illustrate the approach by presenting the solution to motivating Example 2.2.

MTBD in Action

The main steps of the extended MTBD approach for non-functional property maintenance are shown in Figure 7. To better describe the idea, we use Example 2.1 to explain the specific processes. Step 2 -Operation Optimization. The list of recorded operations indicates how a non-functional property should be composed in the base model. However, there is no guarantee that all operations in the demonstration are meaningful. Users may perform useless or inefficient operations during the demonstration. For instance, without a careful design, it is possible that a user first adds a new element and modifies its attributes, and then deletes it in another operation later, with the result being that all the operations regarding this element contradict each other and do not take effect in the transformation process. Thus, the operations are meaningless, even though they do not lead to an incorrect demonstration. Thus, after the demonstration, the engine optimizes the recorded operations to eliminate any meaningless actions. The optimization algorithm is specified in [START_REF] Sun | Model Transformation by Demonstration[END_REF]. The operations in List 1 are all meaningful and are unchanged after this step.

Step 3 -Pattern Inference. With an optimized list of recorded operations, the transformation can be inferred by generalizing the behavior in the demonstration. Because the MTBD approach does not rely on any model transformation language, it is not necessary to generate specific transformation rules, although that is possible. Instead, we generate a transformation pattern, which summarizes the precondition of a transformation (i.e., where a non-functional property emerges) and the actions needed in a transformation (i.e., how a non-functional property should be maintained in this location). As the initial generalized pattern, the precondition in this pattern is called the minimum precondition, which means that it only ensures that all the operations can be executed correctly with the minimum required model elements and connections. As shown in Figure 9, the precondition in this pattern defines that there must be a Component available, and in this Component, a Data element must exist. Obviously, this precondition provides sufficient operands for the operation actions to be executed correctly. However, in many cases, the generalized precondition is not restrictive and precise enough due to the limited expressiveness of the user demonstration. For example, although an Action is included in the Component in the demonstration, it is not incorporated in the generalized precondition, because this element was never used in any of the user operations. Similarly, we intentionally chose the Component called "BM_DeviceComponentImpl" as the desired location of our demonstration. The constraint on the name of this component is not inferred. Therefore, to provide further constraints on the precondition, more feedback is needed from users.

Precondition Actions

Step 4 -User Refinement. The inaccuracy of the initial pattern resulting from the limitation on the expressiveness of the user demonstration is a main issue undermining the applicability of MTBD to the maintenance tasks of non-functional properties, because it is often essential to accurately specify the exact locations of applying a non-functional property based on precise constraints. In order to address this problem, we extended the original version of MTBD to permit users to refine the inferred transformation by providing more feedback for the precondition of the desired transformation scenario from two perspectives -structure and attributes. For instance, users can restrict the precondition by selecting and confirming extra model elements or connections in the model editors that must be included in the pattern.

A new type of operation -Confirm Containment-is implemented in the editor for this purpose, which allows users to right-click on any model element in the editor and confirm to the engine that it should be contained in the final precondition. In addition, the precondition related with the implicit structure is also supported, such as replacing element A only if A has no incoming or outgoing connections. The refinement on the attributes can be realized by choosing the element in the demonstration and typing the specific conditions (e.g., add new element B in C only when the attribute value of C is greater than 200).

All the user refinements are still performed at the model instance level without being aware of the metamodel definitions, after which a transformation pattern will be finalized and stored in the pattern repository for future use.

Reconsidering Figure 10 shows the final transformation pattern after user refinement (the bold rectangle outline represents the attachment of preconditions on its attributes). The generated pattern will be stored in the repository for future reuse. The execution engine applies a backtracking algorithm that works similar to graph matching, which can be found in [START_REF] Sun | Model Transformation by Demonstration[END_REF]. The selected existing model elements in a model instance serve as a candidate pool, and the precondition is matched using subsets of the pool to find the satisfied locations based on both the structural and attribute constraints.

Precondition Actions

Users can select the pattern in the execution controller dialog to execute an inferred transformation pattern from the repository. Users can select multiple patterns to execute in sequence, which is particularly useful when a model transformation task is divided by sub-tasks and specified by different demonstrations. In addition, the total times for executing the selected pattern(s) can be specified, because in some use cases (e.g., model scalability), a transformation pattern(s) needs to be executed multiple times to transform the model to a specific state and configuration.

Executing the generated pattern from Step 4 leads to the Logging element added to all the locations that qualify the conditions.

Step 6 -Correctness Checking and Debugging. Although the location matching the precondition guarantees that all transformation actions can be executed with the necessary operands, it does not ensure that executing them will not violate the syntax, semantics definitions, or external constraints. Therefore, the execution of each transformation action will be logged and model instance correctness checking on syntax and static semantics is performed after every execution. If a certain action violates the metamodel definition, all executed actions are undone and the whole transformation is cancelled. An execution control component has been developed as part of MTBD to control the number of execution times, and enable the execution of multiple patterns together in sequence. A debugger has been created (out of the scope of this current paper's context) to enable end-users to track the execution of the transformation pattern without being exposed to low-level execution information.

Solving Non-functional Property Maintenance Tasks in QoSAML

The demonstration of adding a QoS transition strategy is performed on the selected Size State, as shown in Figure 11. Inside the Size State, we locate the two States with the proper Pri values, and perform the operations in List 3. The Action attribute configuration by operation 2 is conducted through the attribute refactoring editor, which allows users to access all the model elements and connections in the current model editor and load the attribute values to specify the computation process and evaluate the concrete value. The attribute refactoring editor also provides a mechanism to let users create a temporary data pair, with a given name and a value. The creation of the temporary data is actually used to simulate the user input process, and the data can be used in any attribute configuration and computation process through the entire demonstration. The creation of the temporary data will be generalized as a user input action and will display an input box when the final pattern is executed. The initial pattern generalized from the demonstration is shown in Figure 12. Similar to Example 2.1, the precondition is not accurate enough, because the relationship between the two Pri values are not reflected in the demonstration. Moreover, although the two Max elements are included in the pattern, they share the same type as Min and Pri (their meta type are all Data), the consequence being that it is possible that the execution engine incorrectly uses Min or Pri to calculate the average value, or use Max or Min to compare the Pri relationship. Thus, it is necessary to further restrict the Data involved in the pattern with their names. The following operations in List 4 are performed in the user refinement step. Operations 5 -10 confirm the required Pri data elements and their relationship, while operations 11 -12 ensure that Max data elements exist in the two States. Figure 13 shows the final generated transformation pattern.

List 3. Operations performed for Example 2.2 in the demonstration

Sequence

Comparison Between MTBD and Traditional Model Transformation Languages

The MTBD implementation is a plug-in called MT-Scribe that is hosted within the GEMS [START_REF]Generic Eclipse Modeling System (GEMS[END_REF] modeling tool. MT-Scribe is triggered by the end user by pressing a "record" button in the model editor. Thus, any modeling language defined in GEMS that can be edited in the model editor can apply MTBD to address the maintenance of non-functional properties, which means MTBD is a general solution that can be applied across multiple DSMLs.

Using MTBD, users are only involved in editing model instances to demonstrate the non-functional property maintenance process and giving feedback after the demonstration. In other words, users only participate in Step 1 and Step 4 (Section 3.1). All of the other procedures (i.e., optimization, inference, generation, execution, and correctness checking) are fully automated. In both Step 1 and Step 4 where users are involved, all of the information exposed to users is at the model instance level, rather than the metamodel level. For instance, the demonstration is done using the basic editing operations in the GEMS model editor; the attribute configuration is accomplished using the attribute refactoring editor, which contains all the concrete attribute values from all the available elements and connections; the containment confirmation is simply realized by a one-click operation on the desired model element or connection; and the extra precondition is given using the dialog where users can access all the elements touched in the demonstration and type the constraints directly. The generated patterns are invisible to users (Figure 9, 10, 12, 13 are presented for the sake of explanation, which are not visible to users when using MTBD). Therefore, apart from the basic knowledge about the domain, users are isolated from the formal and abstract metamodel definitions and implementation details. Furthermore, no model transformation languages and tools are used in the implementation of MTBD. Thus, users are completely isolated from knowing model transformation languages or programming language concepts. To compare MTBD to traditional usage of transformation languages, we considered MTBD with the actual transformation rules used to specify the same transformation tasks for the two motivating examples [15][16]. These transformation rules were used by C-SAW (Constraint-Specification Aspect Weaver) [START_REF] Gray | Automating Change Evolution in Model-Driven Engineering[END_REF][23], as shown in Figures 14 and15. We compare the two approaches by analyzing the specific implementation differences as well as some general development summaries in Section 4.1 and 4.2. As a special type of MTLs, we discuss the differences and advantages of MTBD over graphical MTLs in Section 4.3.

Comparison on specific implementation differences between MTBD and C-SAW

Identifying the desired locations of the non-functional properties that must be maintained is very easy using MTBD (i.e., a user just selects an example of the specific location using an instance model). In the transformation rules sent to C-SAW, the location of the non-functional properties is defined by extended OCL constraints (e.g., forAll(), select()) together with APIs provided in the transformation language (e.g., models("State"), atoms()). The process becomes more complex when the different APIs are called and used together in a single statement. By contrast, the main location specification in MTBD is automatically handled in the demonstration process. It is the recording engine that detects the location of the operation happening and generalizes the location context information, so that users focus on selecting a desired location without being aware of a generalized locating process.

The specific constraints on the preconditions using MTBD are more intuitive and direct than writing transformation rules. By selecting and clicking on the desired model elements or connections, constraints on the structure can be specified. The location and selection of the attribute in MTBD is realized by clicking on the element in the precondition specification dialog and providing much simpler expressions based on the instance model. However, in C-SAW, OCL expressions and condition statements need to be applied (e.g., if …select(m | m.kindOf() == "Action")->size() >= 1). When it comes to defining the precondition on attribute values, we believe that MTBD is simpler than using conditional statements that access the modeling tool APIs. For example, the following is an expression that would be needed in a typical model transformation rule using the traditional approach:

findAtom("Priority").findAttributeNode("InitialValue").getInt(pri);

Non-functional property maintenance and composition are implemented using model manipulation APIs in C-SAW (e.g., parent().addConnection("Transition", "Transition", "Transition",endID, prevID), aConnection.addAttribute("Guard",guard)), while using MTBD, the composition process is demonstrated using the basic operations in the model editor (i.e., add, delete, update attributes).

Comparison on development efforts between MTBD and C-SAW

We have not performed a formal user study on the comparison between the two approaches. However, some general summaries related to development using the two approaches are given. Table 1 lists the concrete effort to create the deliverable transformation artifact, indicating that with the demonstration approach, only a small number of operations are needed using MTBD to accomplish the exact same tasks that were done by writing dozens of lines of transformation code. To better measure the effort, we asked two users to accomplish the two tasks using these two approaches so that we could measure the time spent using each approach. The user who used MTBD was a trained MTBD user, while the other user who wrote the transformation rules is one of the C-SAW co-authors. The result in Table 2 shows that using MTBD to solve these two examples is 10 times faster than writing C-SAW rules. This fast development cycle enables users to quickly test patterns and make modifications. For instance, in order to determine if a generated pattern is too general or not, users need to execute the pattern and test the result just as testing programs are tested. In some cases, modifications have to be made to fix errors followed by re-executing the new pattern. MTBD shortens these development iterations.

Table 3 describes the prerequisite knowledge for each approach. For MTBD, the development environment is integrated in the modeling tool itself, so users only need to know a few additional buttons to use MTBD. The demonstration is performed using the same model editing operations, so the only new things to learn are the 3 types of UIs for inputting pattern refinements. For C-SAW, the development environment is a plug-in to GME, and it requires a regular textual editor to specify the transformation rules. Learning C-SAW requires learning the new syntax and semantics of the language, including a number of new keywords, program structures and functions. Finally, we identified the possible errors that could happen in the development process using the two approaches. For MTBD, users might perform incorrect editing operations or give invalid expressions in the precondition specification and refinement.

The base pattern and minimum preconditions are automatically generated at the background, so there is no way that users can make mistakes on this part. For C-SAW or nearly any other textual or visual transformation programming language, the transformation rules could suffer from general programming issues such as the syntax errors and semantics bugs in the logical perspective.

Example

Comparison with graphical MTLs

Besides the textual C-SAW transformation comparison, MTBD also shows advantages over general graphical MTLs (e.g., GReAT [START_REF] Balasubramanian | The Graph Rewriting and Transformation Language: GreAT[END_REF]). Graphical MTLs specify the transformation rules by configuring the source model in the left side and the target model in the right side. The transformation engine matches the source model and replaces it with the target model. Compared with the textual MTLs, graphical MTLs provides a more visual and straightforward approach to specify the rules. However, in order to specify a transformation rule using graphical MTLs, users must map the concrete model elements with the concrete syntax of a certain domain to the syntax of the graphical MTL they choose. Depending on the specific domain and MTLs, the syntax and semantics gap of converting the desired model transformation scenario into a rule varies. Additionally, the rules are still defined using metamodel definitions even though they are represented graphically. Similar to graphical MTLs, the execution engine of MTBD applies a similar semantics to match a precondition and carry out the execution process, but MTBD hides the left side and right side rules (the right side rules in MTBD are in the format of an operational change list as described in Section 3) and avoids the gap by the demonstration process. Users specify the transformation on concrete model instances by directly editing, without having to convert the idea into another syntax format.

Apart from the general graphical MTLs, some innovative new graphical MTLs (e.g., MATA [START_REF] Whittle | MATA: A Unified Approach for Composing UML Aspect Models based on Graph Transformation[END_REF]) provide and improved user experience and ease of use by applying concrete syntax to specify the rules without the knowledge of metamodel definitions, as well as combining the left hand side rule and right hand side rule together into a single view. This type of graphical MTLs shows similar user experience as MTBD. However, there are still some fundamental differences between the two approaches as follows: First, MTBD is not designed as a language or programming language, but as a new user experience and interface integrated with the model editing environment to perform model transformations. Thus, programming concepts are avoided in the MTBD process. Users demonstrate transformations rather than writing programmatic rules to specify them. The underlying tool takes care of deriving the programmatic expressions to generalize the demonstrated transformation. Some of the expressions used in the precondition specification are programmatic in nature, but have no conditional logic, loops, or complex expressions, and their usage is minimized through intuitive UIs (e.g., dialog showing the related model element and connections) to assist users' specification. By comparison, graphical MTLs such as MATA are still programming languages based on a grammar or specific metamodel (e.g., UML), with its own syntax and semantics. Although it is really easy to use, users still need to have the basic knowledge about a programming language or graph transformations to correctly utilize the language. For many domains, users do not have sufficient experience with programming language or graph transformation concepts to write transformation rules. Furthermore, MTBD is designed to be at a higher level of abstraction than the graphical MTLs. This results in the fact that a lot of low-level implementation details are hidden (e.g., patterns are generated and executed based on graph theories in MTBD, but are invisible to end-users). On the other hand, the higher level of abstraction actually means that not all possible transformations can be expressed. We did not design MTBD to support all types of model transformation and all possible non-functional aspect modeling activities. A lot of tasks that can be easily specified using regular MTLs cannot be directly demonstrated using MTBD (e.g., using max/min in precondition specification, non-functional properties weaving based on multiple metamodels). However, we target the most practical and commonly used transformation scenarios in different domains and try to ensure the improved user experiences.

Finally, we would also like to highlight the fact that the target user group of MTBD is a little different from the general MTLs. We expect the main users of MTBD to be domain experts using DSMLs to build models, who do not necessarily have any programming or graph transformation background. For computer scientists or programmers, we believe that they may find it more efficient and comfortable to write specific rules using MTLs to accomplish certain tasks rather than using demonstration based approach, but for users without programming background, MTBD offers a feasible alternative for them to finish certain basic model transformation tasks in a potentially simpler way without a steep learning curve. With so many DSMLs being emerging, this group of users is becoming increasingly important in modeldriven engineering community.

Related Work

Non-functional system properties in DSMLs have been well-investigated [START_REF] Bošković | The 1st International Workshop on Non-Functional System Properties in Domain-Specific Modeling Languages[END_REF][6], ranging from the specification of non-functional properties to the measurement and analysis of the non-functional properties. Troya et al. [START_REF] Troya | On the Specification of Non-Functional Properties of Systems by Observation[END_REF] regard non-functional properties as dynamic semantics and specify the properties using domain-specific observers. Boulanger et al. [START_REF] Boulanger | Modeling Heterogeneous Points of View with ModHel[END_REF] propose a multi-view modeling approach to model both functional and non-functional viewpoints. Berardinelli et al. [START_REF] Berardinelli | An Unified Approach to Model Non-Functional Properties of Mobile Context-Aware Software[END_REF] apply a unifying conceptual framework to model context-aware aspects of mobile software systems. Yrjönen and Merilinna [START_REF] Yrjönen | Extending the NFR Framework with Measurable Non-Functional Requirements[END_REF] propose a non-functional properties framework to check the satisfaction of specified requirements. Kupfer and Hadar [START_REF] Kupfer | Understanding and Representing Deployment Requirements for Achieving Non-Functional System Properties[END_REF] present a methodology to achieve predefined non-functional properties by understanding and representing deployment requirements.

Regarding the maintenance of non-functional properties, the current main practice is to use MTLs. For example, Paige et al. [START_REF] Paige | Automated Safety Analysis for Domain-Specific Modeling Languages[END_REF] propose to use Epsilon [START_REF]Eclipse Epsilon[END_REF] to capture failure behavior. Of course, the traditional model transformation languages and tools are also applicable to support automating the maintenance of non-functional properties in DSMLs. The most direct way is to use general-purpose porgraming language (GPL) such as Java or C++ to access and manipulate the internal structure of a model instance using an API provided by a host modeling tool [START_REF] Sendall | Model transformation -The Heart and Soul of Model-Driven Software Development[END_REF], but this approach is not feasible for end-users who do not have programming experience. The power of a transformation is often restricted by the supported API within the modeling tool.

Many modeling tools support importing and exporting model instances in the form of XMI. Therefore, it is also possible to use existing XML tools (e.g., XSLT [START_REF] W3c | XSLT Transformation version 1.0[END_REF]) to manage the non-functional properties outside of a modeling tool using XMI as an intermediate representation. However, the problem of XSLT is that it is tightly coupled to XML, requiring experience to define the transformations using concepts at a lower level of abstraction than DSMLs.

Model transformation languages are the most popular approach to support non-functional property maintenance, because the process of maintaining the properties in the base model can be considered as a model transformation. Textual MTLs specify the transformation rules using high-level expressions and statements. C-SAW [START_REF] Gray | Automating Change Evolution in Model-Driven Engineering[END_REF], ATL [START_REF] Jouault | ATL: A Model Transformation Tool[END_REF], and QVT [START_REF]Revised Submission for MOF 2.0 Query/View/Transformations RFP[END_REF] are representative examples of powerful MTLs that can be used to manage the weaving of models. Moreover, graphical MTLs (e.g., GreAT, VIATRA [START_REF] Balogh | Advanced Model Transformation Language Constructs in the VIATRA2 Framework[END_REF]) also exist to convert non-functional property maintenance tasks into a graph transformation problem by utilizing graph matching and rewriting techniques. Compared with textual MTLs, it is easier to define specific model patterns using graphs, leading to a simplification of the transformation rules in many cases. However, whether a MTL has a high level of abstraction, graphical or textual, its usage always suffers from the challenges mentioned in Section 1 (i.e., the steep learning curve and need to understand the details of the metamodel).

An alternative approach to simplify the maintenance of non-functional properties is to use end-user model transformation approaches, as proposed in this paper. To address the challenges inherent from using MTLs, Model Transformation By Example (MTBE) [31][34] was developed so that instead of writing transformation rules manually, users are asked to build a prototypical set of interrelated mappings between the source and target model instances, and then the metamodel-level transformation rules are semi-automatically generated. This approach simplifies model transformation implementation to some extent, but is not appropriate for non-functional property maintenance tasks because: 1) it focuses on direct concept mapping between two different domains rather than maintaining property models within the same domain; 2) they do not support attribute transformation, preventing the automatic setup of attributes needed in many maintenance tasks.

Another work has been described by Brosch et al. [START_REF] Brosch | An Example is Worth a Thousand Words: Composite Operation Modeling By-Example[END_REF], which uses an example-based approach to address model refactoring tasks. Because it supports model transformation within the same domain, it also has potential to be applied in non-functional property maintenance scenarios. However, the user feedback step may not be at the proper level of abstraction in their approach, and complex attribute transformation is not provided.

EMF Refactor [START_REF]EMF Refactor[END_REF] is a new open source component that provides tool support for generating and applying refactoring for models based on EMF. The capabilities of EMF Refactor simplify the process of adding new refactoring functions in EMF editors and supporting model evolution activities, which can be used also to address the maintenance of non-functional properties. However, the initial definition of the maintenance rules is based on EMF Tiger [START_REF]EMF Tiger[END_REF], a graphical MTL, which is based on writing model transformation rules.

Conclusion and Future Work

In this paper, we presented an end-user approach to enable general users (e.g., domain experts or nonprogrammers) to manage the non-functional properties in different DSMLs without knowing model transformation languages or metamodel definitions. The MTBD approach is based on demonstrations made in a modeling tool by the end-user, which are then generalized. We have shown through two examples how non-functional properties can be introduced using demonstrations provided by a domain expert.

As future work, we will investigate using MTBD to support the maintenance of non-functional properties across different domains and metamodels (e.g., separation of common non-functional properties in a way that can be reused across multiple modeling languages). For instance, the base model may need to be transformed to a new domain first and then apply the non-functional properties, but the current implementation of MTBD cannot handle this type of maintenance because of the nature of supporting only endogenous model transformation in MTBD. Extending the MTBD idea to exogenous transformation will enlarge its applications in practice.

Due to the higher level of abstraction, which allows domain experts to manage non-functional properties, MTDB is less powerful and expressive than a well-defined transformation language. Some functions (e.g., getMax(), getMin()) can be simply realized using function calls or a customized part of code, which can be very challenging to demonstrate. Therefore, in order to enhance the functionality of MTBD, those commonly used functions in the maintenance of non-functional properties will be identified, and integrated in the demonstration and user refinement steps. Furthermore, there are also some features that can be done to improve the demonstration user experience. For instance, when confirming a containment of an element in the user refinement step, it would be a good feature to automatically include the basic constraints on not only the element type but also the attributes (e.g., name).

Acknowledgement

This work is supported by NSF CAREER award CCF-1052616.

Figure 1 .

 1 Figure 1. Adding non-functional properties in ESML models (adapted from [15])

Figure 2 .

 2 Figure 2. QoS Issue in the UAV Image Transmission Scenario

Figure 3 Figure 4 .

 34 Figure 3.QoSAML Model

Figure 5 .

 5 Figure 5. A QoSAML model after applying the Priority Exhaustive protocol3. Demonstration-based Non-Functional Property Maintenance using MTBDModel Transformation By Demonstration (MTBD) is our solution that enables general end-users to evolve and maintain non-functional properties of models, without knowing programming languages or metamodel definitions. MTBD is a new model transformation approach that was initially designed to handle model refactoring problems[START_REF] Sun | Model Transformation by Demonstration[END_REF]. The idea of MTBD is to offer an alternative to writing model transformation rules manually, such that users are asked to demonstrate how the model transformation should be performed by directly editing (e.g., add, delete, connect, update) the model instance to simulate the model transformation process step-by-step. The user evolves and maintains a source model to the target model during the demonstration process. A recording and inference engine captures all user operations and infers a user's intention in a model transformation task. A transformation pattern is generated from the inference, which can be reused and executed in any model instance at any time to carry out the same model transformation process.

Figure 7 .

 7 Figure 7. The implementation of MTBD (initially described in [29])Step 1 -User Demonstration and Recording. Users first give a demonstration by locating one of the correct places in the model where non-functional properties are needed, and directly editing a model instance (e.g., add a new model element or connection, modify the attribute of a model element, connect two model elements) to simulate the maintenance task. During the demonstration, users are expected to perform operations not only on model elements and connections, but also on their attributes, so that the attribute composition can be supported. An attribute refactoring editor has been developed to enable users to access all the attributes in the current model editor and specify the desired computation (e.g., string and arithmetic computation). It also provides a mechanism for users to create a temporary data pair (i.e., a variable name plus its value), and use this data to simulate user input data during the whole demonstration. At the same time, an event listener has been developed to monitor all the operations occurring in the model editor and collect the information for each operation in sequence.

Figure 8 .List 1 .

 81 Figure 8. A selected Component before (left) and after (right) the demonstration of adding a logging mechanismIn Example 2.1, the task is to add a Logging mechanism to each Data in the Component whose name ends with "impl"; there also must be an Action in the Component. Therefore, the demonstration is performed on a selected Component (BM_DeviceComponentImpl) that qualifies these conditions as shown in the left of Figure8.With a desired location, the demonstration is straightforward. Users can add a new Logging element in the Component, and set up its type attribute as "LogOnRead," after which a user makes a connection between the new Logging element to a Data element. List 1 shows all the operations performed during the demonstration, and the model after the demonstration is presented in the right of Figure8. The demonstration only needs to be done for one of the Data elements, because the execution engine can automatically match all the other locations.

  Logging in elem2 2. Set up Logging.LogType = "LogOnRead" 3. Connect Logging to elem3 elem1: ESMLRoot elem2: Component elem3: Data

Figure 9 .

 9 Figure 9. The initial generalized pattern

Figure 10 .

 10 Figure 10. The final generated pattern after user refinementStep 5 -Pattern Execution. The final generated patterns can be executed on any model instances. Users can select a specific part of the model to apply the pattern, or by default apply the pattern on the whole model. Because a pattern consists of the precondition and the transformation actions, the execution starts with matching the precondition in the new model instance and then carrying out the transformation actions on the matched locations of the model. The MTBD engine has also been updated to validate the preconditions refined by users in the previous step. The execution can be carried out in any selected locations in the model, or to the whole model by default. The execution engine applies a backtracking algorithm that works similar to graph matching, which can be found in[START_REF] Sun | Model Transformation by Demonstration[END_REF]. The selected existing model elements in a model instance serve as a candidate pool, and the precondition is matched using subsets of the pool to find the satisfied locations based on both the structural and attribute constraints.

Figure 11 . 5 .Figure 13 .

 11513 Figure 11. Demonstration of adding a transition and setting up the attributes for the new transition

  The remainder of the paper is organized as follows: two non-functional property maintenance scenarios in two different DSMLs are presented in Section 2 as motivating examples; Section 3 explains the MTBD concept through two motivating examples. In Section 4, a comparison of MTDB and the use of traditional model transformation languages is given in the context of the two motivating examples. Related works are discussed in Section 5, and Section 6 offers concluding remarks and summarizes the directions of future work.

Inside the OuterState, there are state machines that describe the adaption of identified independent control parameters, such as Size State, FrameRate State. In each of the state machines, several States are included to represent the options for the corresponding control parameter. A state specifies three Data for the option: Pri defines the priority of this option; Max defines the maximum value that can be used for this parameter; and Min defines the minimum value for the parameter. Model translators have been developed in previous efforts that generate run-time conditions (expressed in the Contract Description Language [19]

  Figure 3 is part of a QoSAML model that specifies the QoS properties for a UAV application. In this model, the latency is a dependent variable input to a hierarchical state machine called Outer State.

  Example 2.1, two more user refinement operations are needed in this step, as shown in List 2.

	List 2. Refinement operations performed for Example 2.1 in the demonstration
	Sequence	Operation Performed

4 Confirm the containment of ESMLRoot.BM_DeviceComponentImpl.Action 5 Specify precondition: ESMLRoot.BM_DeviceComponentImpl.name.endsWith("Impl")

15. The ECL code to implement Example 2.2 (from [16])

	strategy AddTransition(stateName, prevID, guard : string; prevPri : integer)
	{
		declare pri, minVal, maxVal, avgVal : integer;
		declare endID : string;
		declare aConnection : node;
		findAtom("Priority").findAttributeNode("InitialValue").getInt(pri);
		if(pri == prevPri + 1)
		then
		getID(endID);
		findAtom("Min").findAttributeNode("InitialValue").getInt(minVal);
		findAtom("Max").findAttributeNode("InitialValue").getInt(maxVal);
		avgVal := (minVal + maxVal) / 2;
		<<CComBSTR action(stateName);	// exit statement to C++
		action.Append("="+XMLParser::itos(avgVal)); >>
		aConnection :=
		parent().addConnection("Transition", "Transition", "Transition",
		endID, prevID);
		aConnection.addAttribute("Guard", guard);
		aConnection.addAttribute("Action", action);
		endif;
	}
	strategy FindConnectingState(stateName, guard : string)
	{
		declare pri : integer;
		declare startID : string;
		findAtom("Priority").findAttributeNode("InitialValue").getInt(pri);
		getID(startID);
		if(pri< 4)
		then
		parent().models("State")->
	defines Start, FindData1, AddLog; forAll(AddTransition(stateName, startID, guard, pri));
		endif;
	strategy FindData1() }
	{
	Atoms()->select(a | a.kindOf() == "Data")->AddLog(); strategy ApplyTransitions(stateName, guard : string)
	} {
		declare theModel : node;
	strategy AddLog() theModel := findModel(stateName);
	{	theModel.models("State")->forAll(FindConnectingState(stateName, guard));
	}	declare parentModel : model;
		declare dataAtom, logAtom : atom; Figure
		dataAtom := self;
		parentModel := parent();
		if (parentModel.atoms("")->select(m | m.kindOf() == "Action")->size() >= 1)
		then
		logAtom := parentModel.addAtom("Log", "LogOnWrite");
		logAtom.setAttribute("Kind", "On Write");
		parentModel.addConnection("AddLog", logAtom, dataAtom);
		endif;
	}
	strategy Start()
	{
		rootFolder().findFolder("ComponentTypes").models().select(m | m.name()
		.endWith("impl"))->FindData1();
	}
		Figure 14.The ECL code to implement Example 2.1 [23]
	defines AddTransition, FindConnectingState, ApplyTransitions;

Table 1 .

 1 The comparison of development effort to solve the two motivating examples

	MTBD	C-SAW Rules

Table 2 .

 2 The comparison of development time to solve the two motivating examples

	MTBD	C-SAW
	1. MTBD development environment	1. C-SAW syntax and semantics
	2. How to demonstrate by model editing	including 12 keywords, 5 main
	3. How to perform refinement (i.e., the	program structure, and 4 functions.
	usage of 3 types of refinement UIs)	2. C-SAW development environment

Table 3 .

 3 The comparison of prerequisite knowledge to solve the two motivating examples

	MTBD	C-SAW
	1. Demonstrate with the wrong editing	1. General programming language
	operation	syntax error.
	2. The incorrect specification on the	2. Semantics error or bugs on the
	attribute precondition expressions	transformation logic

Table 4 .

 4 The comparison of possible errors to solve the two motivating examples

Precondition elem1.elem2.elem3.elem4 elem1.elem2.elem3.elem5 elem1.elem2.elem3.elem4.elem6 elem1.elem2.elem3.elem5.elem7 elem1: QoSAMLRoot elem2: State elem3: State elem4: State elem5: State elem6: Data elem7: Data Actions 1. Add a Transition between elem4 and elem5 2. Set Transition.Action = elem3.name + "=" + (elem6.value + elem7.value) / 2 3. Create a data pair (guard = "Latency > 25 && FrameRate < 5") 4. Set Transition.Guard = guard.value Figure 12. The initial generalized pattern Precondition elem1.elem2.elem3.elem4 elem1.elem2.elem3.elem5 elem1.elem2.elem3.elem4.elem6 (elem6.name == "Max") elem1.elem2.elem3.elem5.elem7 (elem7.name == "Max") elem1.elem2.elem3.elem4.elem8 (elem8.name == "Pri") elem1.elem2.elem3.elem5.elem9 (elem9.name == "Pri") (elem8.value == elem9.value -1) (elem9.value < 5) elem1: QoSAMLRoot elem2: State elem3: State elem4: State elem5: State elem6: Data elem7: Data elem8: Data elem9: Data

Executing the pattern on any selected States will make the execution engine automatically traverse the state and locate all the pairs of included States that satisfy the Pri relationship constraint and contains the needed Max elements. This allows the Transition to be added correctly and combined with a user input Guard value.