that no inonsistenies an our and the tool hain is as small as possible. While must rely on traing metadata to relate the ode to formal models. Considering The objetive of this ontribution is to monitor exeuted software with respet these problems, we introdue in this setion our general approah of oupling resulting information is generi, fouses on tehnial details of program ode, or models the software is based on. The reason, as mentioned in the introdution, is well-established, few approahes realize veriation with respet to formal model speiations and program ode. logi only and not its abstrat semantis. When it is monitored or veried, the to high-level speiations, but without using additional meta information, so monitoring as a way of verifying the exeution of software systems at run time that onstitutes programs at run time: The ode usually desribes exeution is that the related speiations are not naturally available in the program ode a tool for monitoring state mahines is introdued in setion 4. Afterwards we the related program ode fragments at run time in setion 3. Based on these, give an overview of related work in setion 5 and draw onlusions in setion 6. tern. They are of interest in our ontext sine expressiveness of the monitoring A monitoring as desribed above means that the program ode must ontain the a sequene of ations mathing the related model semantis. Considering the like Java, we an observe a trend to inrease the expressiveness of program ode speiation information. Considering objet-oriented programming languages fragments. For example, embedded DSLs [5℄ are domain-spei languages that of the underlying programming language and its expressiveness regarding single are embedded into other languages, so that semantis of DSLs are used inside Embedded models build upon these onepts to relate program ode to abframework that aesses and invokes the language elements and thus reates language and their relations are onsidered building bloks onstituting the patstrat speiations systematially. Eah embedded model provides a program ode pattern representing the abstrat syntax of a formal model so that a bijeThe pattern ode is interpreted by means of strutural reetion at run time able to arry type-safe metadata, e.g., Java Annotations. This enables attributeto exeute the model speiations. Eah embedded model provides an exeution enabled programming [6℄ making program ode interpretable even at run time. monitoring, it is essential that the program ode pattern elements and their a general-purpose language. In addition, some general-purpose languages are expressiveness regarding relations to the abstrat speiations are by this means aessible at run time. depends on their aessibility by appropriate mehanisms at run time. tive projetion between both exists. The pattern elements rely on the semantis fragments and their interonnetions. The statial elements of the programming public class AfterMeasurementState implements IState State Definition { Target State Pointer @Transition(target = UpUpState.class , contract = BeginUpUpContract.class ) public void beginUpUp(MeasurementModule actor) throws MeasurementAbortedException {
actor.doMeasure (); } // ... } and passes the lass denition of the initial state as well as the variables and get methods for eah variable. The name and return type of eah method are ompare the urrent values with the values from the point in time before the of the state mahine to determine if a transition is able to re, the updates variables onstituting the state spae of the state mahine. This type ontains The surrounding program ode aesses for this purpose the exeution framework ator faade types as parameters. The state mahine is then exeuted as follows: and return a single boolean value. The guards use the urrent variable values transition red to determine the hanges to the state spae. For this purpose both methods aess a variables type whih is a faade type representing the The exeution framework interprets and invokes these fragments at run time. interpreted as name and data type of the orresponding variable. arate notations, so that no inonsistenies between model and implementation this information. Seond, embedded models are tightly integrated with arbitrary monitor programs with respet to models, sine the model views an be extrated the framework, so that inferenes an be made on orretness of the model from the program ode patterns serve as entry points for interpreting and monitoring but instead used by the exeution framework, exeuted systems with embedded gram ode patterns whose elements are related to model speiations. The run time: Sine the related ode fragments are not supplementary or optional, from the ode during exeution. For this purpose the well-dened elements of the program ode. This enables a validation of programs with two purposes: program ode. This allows for high exibility during implementation, but auses As an be seen in the state mahine example, embedded models introdue proThis availability of models at run time is important for our objetive to an our. Consisteny is not only maintained at development time, but also at First, the model view itself is of interest for monitoring the model exeution by models are thus views on the program ode and need not to be stored in sepmodels arry omplete information about related speiations naturally. We will now introdue appropriate monitoring tehniques and afterwards a tool that implements the approah. the model with appliation data an be observed. framework: Sine it ontrols the exeution, it is an entry point for ations to be monitored. Inside the exeution framework for state mahines, the following Monitoring of embedded models thus onsiders program ode pattern inthe need to validate orretness of the surrounding ode with respet to the model. This is supported with appropriate monitoring sine the behaviour of stanes, for example of state mahines, as well as program ode of the exeution steps an be onsidered: proahes for this purpose here. While all of them have already been used by other respet to models at run time, but without artiial traing information. Thus not fous on the general tehnologies, but on their adequay for monitoring the approahes for monitoring, our ontribution here is the appliation to program referenes to model speiations at run time, in whih we enounter important dierenes.
Our objetive is to use this approah for monitoring program exeution with it is important to onsider the aessibility of the program ode patterns and their elements during exeution. We will introdue the basi tehnologial apode patterns arrying the abstrat syntax of formal models. We will therefore mahine variable values. To interpret the guards and updates thoroughly, The exeution framework iterates on the state mahine ow until a nal transition methods. The transition under examination is also denoted by a variable that must therefore be observed. iteration pointing to the state lass denition. Changes to this variable must For eah transition the exeution framework invokes the guard and update One a state is ativated, the exeution framework iterates the ontained be monitored in order to determine state ativation. are all operations inside this methods, espeially those that omprise state the omposition of the overall result of these methods from single operation state is reahed. The urrent ative state is denoted by a variable inside this methods and passes the variables faade instane as a parameter. Of interest results is also important to monitor.
Sine all information about the running system and the embedded state mahine interest for monitoring. The exeution framework is based on strutural reetion semantis is available inside the state mahine exeution framework, the easiest way for monitoring is to extend this framework in order to emit information of When this event is red, program ontrol has been taken over by the state Initialization and start of a state mahine. This inludes information about seletion in this state will happen subsequently.
Seletion of transitions. This indiates that program ontrol will be handed Ativation of states. This indiates that guard evaluation and transition mahine exeution framework again. for omparisons. Additional information is supplied if the validation failed. in this event. Additionally, the ahed variable values are supplied to allow all states, transitions and variables as extrated from the Java ode via reetion. States are uniquely identied by their fully qualied lass names.
Validation of updates after a transition. The variable values are updated over to the business logi in this transition. own exeution inside the state mahine. This is possible without onurreny The advantage of listeners is their easy integration into tools based on the While the approah is working at this level, the degree of detail is limited: boxes. For this reason operations inside guards and updates are not visible, but problems sine the framework passes ontrol of the program ow to the listeners of appliations is possible. Thus an appliation an gain information about its only their results after the related method was invoked by the framework.
Method ontents in Java are not aessible by means of reetion and thus blak Java platform, espeially in module-based environments. Sine the listeners are aessible from inside the same Java Virtual Mahine (provided appropriate during notiations, so that all ations are handled sequentially. programming interfaes or module lookup servies exist), even self-monitoring In the ase of state mahines, listeners an be notied about events for every exeution framework and omponents reeiving information about the exeution. based platforms (like OSGi [7℄ in the ontext of Java) allow for a loose oupling of and aesses and interprets a onsiderable part of the program ode strutures operation performed on the embedded model: onstituting the pattern. Besides setting listeners programmatially, moduleAOP usage: Emission of monitoring information is formulated as aspets that related state lass and transition method name. monitor is notied about the ontrat lass and the urrent result. The seond pointut is invoked before a transition method is exeuted, i.e., any method in from business logi. Monitoring and traing are often-mentioned examples for guard and update methods, invoke them and read the result. Afterwards the strutures of interest are aessed by pointuts. Appropriate advie written in Aspet-oriented programming (AOP) aims to separate ross-utting onerns a lass implementing the IState interfae. It noties the monitor about the AspetJ [8℄ are shown in listing 1.1. The rst and the third pointut wrap around are woven into program ode. To monitor state mahine exeution, the ode program ode pattern are learly identiable Listing 1.1. The AspetJ monitoring aspet. lasses and method names, so that pointuts an 3.3 Debugging Approah } result); && args(vars) { result); } } before() : exeution(* *.*(..)) && target(IState) { // Notify about forthoming transition method invoation monitor.notifyTransition(thisJoinPointStatiPart.getSignature().getDelaringType(), thisJoinPointStatiPart.getSignature().getName()); The main advantage of AOP in this ontext is that monitoring an be applied depending on the ontext. This is enabled by the fat that the pattern elements of embedded models are well-known and obligatory: Aspets an identify them so that advie and pointuts an address program ode elements related to model whih guard belongs to the transition being exeuted; this information has to be this problem, the exeution framework ould be hanged to make pointers to the without the need to modify the exeution framework. With load-time weaving, elements. Similar as with listeners, this also allows for self-monitoring. are exeuted (keyword thisJoinPointStatiPart ). But, they do not gain aode has been ompiled. This allows for exible mehanisms that an be applied objets of interest available as elds. number of guards is evaluated. Afterwards, one transition method is invoked. sion of suh software, it prevents full aess to information of interest: Pointuts While pointuts are informed about the single ations, they annot determine guessed or supplemented by interpreting the program ode afterwards. To solve an handle information regarding the loation of program ode in whih they ess to information in terms of sequenes of pointuts: In eah state, a ertain monitoring apabilities an even be supplemented in systems after the program However, while this exterior view on the pattern allows for dynami exten(JPDA) [9℄ provides well-dened programming interfaes to aess related events to the exeuting platform. The related Java Platform Debugger Arhiteture so that those of interest for our monitoring approah an be ltered from the The debugging approah delegates low-level observation of the program state // Wrap update method invoation and notify about the result exeution(* IContrat.validate(..)) && args(before, after) { boolean result = proeed(vars); boolean around(Objet before, Objet after) : monitor.notifyUpdate(thisJoinPointStatiPart.getSignature().getDelaringType(), return result; be dened unambiguously.
All points of interest in the by simple rules regarding their boolean result = proeed(vars); return result; boolean around(Objet vars) : exeution(* IContrat.hekCondition(..)) monitor.notifyGuard(thisJoinPointStatiPart.getSignature().getDelaringType(), // Wrap guard method invoation and notify about the result The graphial view allows to wath ativated state lasses and transition methods. Current and ahed variable values are shown to exhibit the urrent These approahes enable monitoring of program ode based on embedded models dened ode strutures only. We will now introdue a tool that is based on suh approahes and monitors the related information. Its user interfae shown in without using traing information or other metadata, but by onsidering wellgure 2 reets our requirements for the pratial use of the monitoring. state spae and to enable monitoring of hanges during transitions. Updates that invoation results is possible without additional eort when they are aessed whih would be exeuted at times not expeted by the developer. model implementations as well as all loal variables in the exeution framework. gether with information about loal variable values we an monitor evaluation of that a self-monitoring of appliations is not possible. In addition, debuggers in and updates, MethodExitEvents are of interest that are triggered after all ode abstrat models is more meaningful than debugging at the soure ode level only. evaluation of guards and updates an be reorded and presented to the develguards and updates with suh events, too: Sine only expressions are used inside approah an be used as debuggers are used in general when the appliations systems is urrently not desirable with this tehnology. We thus expet that this aess return values of variable interfae methods when they are invoked. Toare validated during development or maintenane. In this ase the relation to by the appliation itself. For the state mahine model this is suient sine the these methods, the evaluation is fully omprehensible afterwards by inspetion tion seletion are monitored by observing elds ontaining the related referenes stanes: The appliation being debugged and the debugger itself that ontrols would also allow to invoke methods at any time. This ould be of interest for and update method ontents. Sine all details of expressions are available, the the program ow, sine variable methods may ontain arbitrary business logi, A debugger an hene aess all elements of the program ode pattern in exeution. All information that an be gained is aessible only by the latter, so result of the evaluation is also available in this event.
Dierent to the listener and AOP approahes, this allows for monitoring guard The main inuene of debuggers, however, is the need for two running ingeneral have a strong impat on performane, so that a monitoring of prodution of the values of loal variables. The return value of the method and thus the variable methods to determine their urrent value. This is, however, intrusive to oper for eah step. The debugging approah is therefore the only one able to event queue. In the ase of embedded state mahines, state ativation and transiof a method has been exeuted, but before the method is left. We use them to variables are of interest only when they are evaluated in guards. A debugger in the exeution framework with ModifiationWathpointEvent s. For guards aess all elements of the program ode pattern. Aess to variables and method tuting the state spae. with the ative state and transition highlighted, right hand the variable values onstiFig. 2. A state mahine model being monitored. Left hand we see the state mahine Following our objetive to monitor the exeution of program ode that is related to model speiations, we must onsider related work with respet to two deteted by the exeution framework. The resulting arhiteture as skethed in operation performed on the embedded state mahine. state mahine. The third button visible on top of the sreenshot noties the have impat on the program ow, this information allows developers to look for Elipse-based development tools. It uses listeners that are loosely oupled over invoked during transitions, and exeution ontrol will afterwards return to the like our tool are hene OSGi bundles being deployed alongside, but independent The tool is realized on the Elipse platform, making it easy to be integrated in from business logi. The listener is registered as a named OSGi servie that is transition; the button to the right allows then for stepwise exeution. an be paused and resumed by the user. This is possible sine business logi is ould not be validated suessfully are listed separately; sine updates do not gure 3 allows to use almost arbitrary tools to be notied about events for every exeution framework that the state mahine ow should pause after the urrent the auses of suh inonsistenies later on. The state mahine ow altogether the OSGi servie registry that is provided by the Elipse platform: Listeners 6 Conlusion [22, 23℄, whih rely on metadata in soure ode omments. Instead, we an infer tion of unknown strutures and models, but fous on well-known models that an thus be examined more thoroughly and with respet to a formally-founded tem models like the Java Modeling Language (JML) [18℄ or the approah are onneted to program ode and thus monitor the related data exhange. on heuristis and not appropriate for a preise monitoring. Exeutable models pliations ompletely expressed as models, while we onsider ases where models ments [21℄ or the approahes to monitor OCL onstraints with aspet orientation based on design patterns [13℄. However, this requires manual eort or is based referenes to speiations as is neessary for PathFinder’s veriation statetargets the development time instead of the run time and annot be fully automated [11℄. Informal speiations an be inferred from program ode by deteting patterns [12℄, and similar, speiations an be extrated from program ode topis: First, general approahes that relate program ode to high-level speireason it an also learly be distinguished from general debugging approahes. bakground. We also do not require hanges in the program ode to introdue [14℄ are aessible at run time, too. However, they are only appropriate for apmonitoring with embedded models is related to abstrat speiations. For this tern ontrats [16℄ is based on low-level semantis of detailed patterns. Similarly, ontrast to stati analysis tools like DisoTet [20℄ we do not target deteto use Smalltalk with its introspetion apabilities as a meta language [19℄. In of monitoring in spei tehnologial environments. ming language and thus onsider whole appliations as models [17℄. In ontrast, We do not aim to present a notation for the speiation of all possible sysRound-trip engineering [10℄ relates generated program ode to models but all model speiations diretly from the program ode pattern. ations whih are in theory appropriate for monitoring; seond, the appliation model hekers for program ode work with low-level semantis of the programMonitoring for ompliane with so-alled design models [15℄ or design patFig. 3. Component arhiteture with the monitoring listener. Appliations are omlistener omponent is optional and hene only oupled via the servie registry. posed of omponents using the exeution framework based on the OSGi platform. The in objet-oriented program ode. We were ating on the assumption that the reWe presented our approah to monitor model speiations that are embedded Java. In: PPPJ ’08: Proeedings of the 6th International Symposium on Priniples development. IBM Systems Journal 45(3) (2006) 463480 6. Shwarz, D.: Peeking Inside the Box: Attribute-Oriented Programming with Java 1. Brown, A.W., Iyengar, S., Johnston, S.: A Rational approah to model-driven and Pratie of Programming in Java, New York, NY, USA, ACM (2008) 189197 5. Kabanov, J., Raudjrv, R.: Embedded Typesafe Domain Spei Languages for 1.5. ONJava.om (June 2004) http://www.onjava.om/pub/a/onjava/2004/06/ 4. Balz, M., Striewe, M., Goedike, M.: Embedding State Mahine Models in Objet(November 2003) 128138 tion Levels in Program Code. In: Proeedings of the 2nd International Workshop on 30/insidebox1.html. 3. Balz, M., Striewe, M., Goedike, M.: Continuous Maintenane of Multiple Abstraat MODELS 2008. (2008) 615 Luxembourg. Volume 2952 of Leture Notes in Computer Siene., Springer-Verlag Oriented Soure Code. In: Proeedings of the 3rd Workshop on Modelsrun.time Workshop on sientiFi engIneering of Distributed Java applIations (FIDJI) 2003, tures. In Gue, N., Artesiano, E., Reggio, G., eds.: Proeedings of the International 2. Tihy, M., Giese, H.: Seamless UML Support for Servie-based Software ArhiteFuture Trends of Model-Driven Development - FTMDD 2010, Funhal, Portugal. (2010) 6879 aspets an even be attahed dynamially to the programs sine they an work on the pattern speiations after ompilation. lude the development of an appropriate monitoring tool. Due to the maturity of to the program ode. All are non-intrusive regarding the soure ode of the monbitrary Java appliations, thus making model validation at run time an integral terfae of development environments. With this integration, the monitoring of the JPDA and related user interfaes in integrated development environments, information retrieval have been evaluated as possible alternatives. Our onluvironment is available, the debugging approah is more thorough and allows to itored system and two of them are even non-intrusive to the soure ode of the approahes allow to monitor guards and updates in detail. On the other hand, listeners and AOP require less overhead at run time. With AOP, monitoring For the urrent implementation of a monitoring tool, the listener approah sion is that all are appropriate to monitor the state mahine semantis, although was hosen sine it allows to aess the most important information with little exeution framework. However, the degree of detail varies sine only debugging abstrat model speiations an be seamlessly integrated with debugging of arin dierent degree of detail and with dierent impat on the neessary hanges monitor every detail of the state mahine exeution. Future work will thus ineort and provides the ability for self-monitoring. However, if the required enwe will then be able to integrate the monitoring with the debugging user inlated program ode pattern strutures are preise enough to allow for inferene part of the development proess. to model speiations even at run time. To show this, dierent approahes for 9. Sun Mirosystems, In.: Debugging Arhiteture API http:// JavaTMPlatform tem With Its High-Level Design Models. In: ICSE ’96: Proeedings of the 18th 10. Sendall, S., Kster, J.: Taming Model Round-Trip Engineering. In: Proeedings Leture Notes in Computer Siene., Springer (2005) 186200 Software Engineering 15(3-4) (2008) 283297 of Component-Based Systems. (2004) 8793 on Formal Engineering Methods (ICFEM’04). Volume 3308 of LNCS., Springerof the 26th International Conferene on Software Engineering, Washington, DC, straints. In: Proeedings of Workshop Aspet-Oriented Software Development with USA, IEEE Computer Soiety (2004) 470479 IOS Press, In. (2005) gineering Languages and Systems, 8th International Conferene, MoDELS 2005, Languages and Systems, 9th International Conferene, MoDELS 2006, Genova, 2005) 5570 20. Yan, H., Garlan, D., Shmerl, B., Aldrih, J., Kazman, R.: DisoTet: A System Italy, Otober 1-6, 2006, Proeedings. Volume 4199 of Leture Notes in Computer and Systems, Kluwer (1999) 175188 22. Rihters, M., Gogolla, M.: Aspet-Oriented Monitoring of UML and OCL Conoping Domain Spei Exeutable Models. In: Proeedings of the 8th OOPSLA Montego Bay, Jamaia, Otober 2-7, 2005, Proeedings. Volume 3713 of LNCS., Verlag (2004) 357373 UML. (2003) text Motorola Case Study. In Briand, L., Williams, C., eds.: Model Driven EnSpringer (2005) 476491 23. Chen, F., D’Amorim, M., Ro‡u, G.: A formal monitoring-based framework for softKilov, H., Rumpe, B., Simmonds, I., eds.: Behavioral Speiations of Businesses 21. Visser, W., Havelund, K., Brat, G., Park, S., Lerda, F.: Model Cheking Programs. 19. Duasse, S., Grba, T.: Using Smalltalk as a Reetive Exeutable Meta-language. 18. Leavens, G.T., Baker, A.L., Ruby, C.: JML: A Notation for Detailed Design. In for Disovering Arhitetures from Running Systems. In: ICSE ’04: Proeedings In: Proeedings of the the 3rd FSE Workshop on the Speiation and Veriation 12. Philippow, I., Streitferdt, D., Riebish, M., Naumann, S.: An approah for reverse 16. Soundarajan, N., Hallstrom, J.O., Tyler, B.: Monitoring Design Pattern Contrats. 13. Mili, H., El-Boussaidi, G.: Representing and Applying Design Patterns: What International Conferene on Software Engineering, Washington, DC, USA, IEEE 7. OSGi Alliane: OSGi Servie Platform, Core Speiation, 11. Baker, P., Loh, S., Weil, F.: Model-Driven Engineering in a Large Industrial Conware development and analysis. In: Proeedings of the 6th International Conferene Workshop on Domain-Spei Modeling. (2008) of Workshop on Best Praties for Model-Driven Software Development. (2004) 14. Hen-Tov, A., Lorenz, D.H., Shahter, L.: ModelTalk: A Framework for Devel15. Seka, M., Sane, A., Campbell, R.H.: Monitoring Compliane of a Software SysComputer Soiety (1996) 387396 Is the Problem? In Briand, L.C., Williams, C., eds.: MoDELS. Volume 3713 of java.sun.om/javase/tehnologies/ore/toolsapis/jpda/ . 17. Holzmann, G.J., Joshi, R., Groe, A.: Model driven ode heking.
In Nierstrasz, O., Whittle, J., Harel, D., Reggio, G., eds.: Model Driven Engineering engineering of design patterns. Software and Systems Modeling 4(1) (February Automated Software Engineering Journal 10(2) (2003) 8. Colyer, A., Clement, A., Harley, G.: Elipse AspetJ. Addison-Wesley (2004) Siene., Springer (2006) 604618