An IDE to Build and Check Task Flow Models

An IDE to Build and Chec k T ask Flo w Mo dels Carlos Alber to F ernandez-y- F ernandez 1 , Jose Angel Quintanar Morales 2 , and Hermenegildo F erna ndez Santos 2 1 Instituto de Computaci´ on, Universidad T ecnol´ ogica de la Mixteca, M´ exico 2 Lab. de In v. y Des. en Ing. de Soft., U niv ersidad T ecnol´ ogica de la Mixt eca, M´ exico { caff, joseang el, ps20101600 01 } @mixteco. utm.mx Abstract. This p aper p resen ts th e Eclipse plug-ins for th e T ask Flow mod el in t he Disco very Meth o d. These plug-ins provide an IDE for t he T ask A lgebra compiler and t he mo del-c hecking to ols. The T ask A lgebra is the formal representation for the T ask Mo d el and it is b ased on simple and compoun d tasks. The mo del-chec kin g techniques were developed to v alidate T ask Mod els rep resen ted in the algebra. Keyw ords: light weight formal specification; soft ware mo delling; mo del-c hecking. 1 In tro duction There ha s bee n a steady take up in the u se of formal calculi for soft ware con- struction over the last 25 years [1], but mainly in ac a demia. Although there are some accounts of their use in industr y (bas ically in cr itical sys tems), the ma jor- it y of s oft ware houses in the “ real world” hav e prefer r ed to use visual mo delling as a kind of “semi-formal” repr e sen tation of soft ware. A method is considered formal if it has well-defined mathematical basis. F or mal metho ds provide a sy n- tactic domain (i.e., the notation o r set of symbols for use in the meth o d), a semantic domain (like its universe of o b jects), and a set of precise rules defining how a n ob ject can sa tisfy a sp ecification [1 1]. In addition, a sp ecification is a s et of sentences built using the notation of t he syn tactic domain a nd it represen ts a subset o f the semantic doma in. Spivey says that formal metho ds a re bas e d on mathematical notations and “ they desc ribe what the system must do without saying how it is to b e done” [10], which applies to the non- constructive appro a c h only . Mathematical notations commonly hav e three ch ara cteristics: – conciseness - they represent complex fa c ts of a sys tem in a brie f space; – precision - they ca n sp ecify ex a ctly everything that is intended; – unam biguity - they do not admit m ultiple or conflicting interpretations. Essentially , a forma l metho d can b e applied to supp ort the development of s oft- ware and hardware. This pap er shows an IDE for mo delling and chec king task flow mo dels using a particula r pro cess a lgebra, called T ask Algebra , to charac- terise the T ask Flow mo dels in the Discovery Metho d. The adv antage is that this will allow softw a r e eng ineers to use diag ram-based design metho ds tha t have a secure formal underpinning. 1.1 The Di s co v ery Metho d The Discovery Metho d is an ob ject- o rien ted metho dology pro posed for mally in 1998 b y Simons [8,9]; it is considered b y the author to be a method focus ed mostly on the tec hnical pro cess. The D iscov ery Method is or ganised into four phases; Busines s Mo delling, O b ject Mo delling, System Mo delling, a nd So ftw are Mo delling (Simons, p ers. co mm.).The B usiness Mo delling phas e is task-o rien ted. A task is defined in the Discov ery Metho d as so mething that “has the specific sense of an activity car r ied out by stakeholders that has a business pur pose” (Si- mons, p ers. comm.). This task -based explora tion will lead even tually towards the t wo kinds of T as k Diagr ams: The T ask Structure and T a sk Flow Diag rams. The workflo w is represented in the Discov ery Metho d using the T as k Flow Diagram. It depicts the order in which the tasks a re realised in the business, expressing also the logical dep endency b etw een ta sks. While the notation used in the Dis- cov ery Metho d is la rgely base d on the Activity Diag ram of UML, it maintains consistently the lab elled e llips e notations for tasks. 1.2 The T ask Flow mo dels Even though T ask Flow mo dels could b e r epresen ted using one of the pr ocess algebras describ ed ab ov e, a particular alg ebra w as defined with the aim of having a clea r er transla tion b et ween the graphica l mo del a nd the algebra . One of the main difficulties with applying an ex isting pro cess a lg ebra was the no tion that pro cesses consis t of atomic steps, which can b e interleav ed. This is not the case in the T as k Algebra , where even simple tasks hav e a non-atomic dura tion and are therefor e treated as interv als, rather than atomic events. A simple ta sk in the Discov ery Metho d [8] is the sma llest unit of work with a business goa l. A simple task is the minimal repres en ta tion of a task in the mo del. A co mpound task can b e formed by either simple or compound tasks in co m bina tion with op erators defining the str ucture of the T ask Flow Mo del. In addition to simple tasks and co mpound tas ks, the abstrac t syntax also requires the definition of three instan taneous ev ents. These may form part of a co mpound task in the abstract syntax. 2 The T ask Flo w metamo del 2.1 The T ask Algebra for T ask Flow mo del s The bas ic elements of the abstra c t syntax a re: the simple tas k, which is defined using a unique name to distinguish it from others; ε representing the empty activity; and the success σ a nd failure ϕ symbols, repr e s en ting a finished activity . Simple and co mp ound tasks are combined using the op erators that build up the structures allow ed in the T ask Flow Mo del. The ba sic syntax structur es for the T ask Flo w Mo del a re sequential compo sition, selection, pa rallel comp osition, rep etition, a nd encapsulation. The alg ebra definition is shown in table 1. Activ ity ::= ε – empty activity | σ – succeed | ϕ – fail | T ask – a single task | Activ ity ; Activ ity – a sequence of activity | Activ ity + Activ ity – a selection of activity | Activ ity k Activ ity – p arall el activity | µx. ( Activ ity ; ε + x ) – until-loop activity | µx. ( ε + Activ ity ; x ) – while-loop activity T ask ::= S impl e – a simple task | Activ ity – encapsulated activity T able 1. abstract syntax defin ition A task can be either a simple or a compound task. Comp ound tasks are defined b et ween bra c kets ’ { ’ and ’ } ’, a nd this is also called enca psulation b ecause it introduces a different context for the execution of the str ucture inside it. Cur ly brack ets are used in the syntax context to represent diag rams and sub-diagra ms but als o hav e implications for the semantics. Also, pa ren theses c a n be use d to help co mpr ehension or to change the a sso c iativit y of the expr essions. Expressio ns asso ciate to the rig h t by default. More details of the axio ms ca n b e seen in [6]. 2.2 Mo del-c hec king A set of tra ces is the trace se man tic repres en tation for a T a sk Flow Diagra m. The verification of the diagram may b e made in diff erent wa ys. The simples t op erations could b e per formed by s et o perato rs but more o peratio ns may b e ap- plied over the traces using tempo r al logic. T emp oral lo g ic ha s b eing extensively applied with sp ecification a nd verification of softw are. The s et of traces, obtained from a task alge bra ex pression, may b e used to verify some temp oral and log ical prop erties within the sp ecification expressed b y the diagr a ms. F or this r eason, a simple implemen tation of L TL was built. This L TL implementation works ov er the trace semantics gene r ated fr o m a T a sk Alge br a expres sion. B ecause the trace semantics repr esen t every po ssible path o f the T a s k Flow diagr am ex pressed in the T ask Alg ebra, it is str aigh tforward to use L TL formulas to q ua n tify univer- sally ov er a ll those paths. In this sectio n, some examples using Linear T emp o ral Logic (L TL) are presented, to illustr ate the reasoning capabilities of the L TL mo dule. L TL is a temp oral logic, formed a dding temp oral op erators to the pred- icate ca lc ulus . These op erators that can be used to refer to future states with no quantification ov er paths. In addition, a CTL applicatio n was built to test CTL theorems a gainst ex pressions in the tas k a lgebra. In this ca se, the a pplication has to transform the traces in a tree repres en ta tion b efore apply ing the expr es- sion. While L TL fo r m ulas ex pr ess temp oral pro perties ov er all undifferentiated paths, Computational T ree Logic (CTL) also considers quantification ov er sets of paths. CTL is a br anc hing-time log ic [5] and theore ms in this log ic may als o be tested ag ainst a set of traces obtained from a task alg ebra express ion, in the same wa y that L TL theor ems were tested ab o ve. 3 A to ol for formal sp ecification of T ask Flo w mo dels 3.1 Analysis o f In tegrated Developmen t E nvironmen ts (IDE) Through a search in sur v eys and ar ticle s published in dig ital media, Eclips e is chosen as the to p tw o op en source IDE s b e st p ositioned among develop ers. How- ever, Eclips e s ho wed a b etter p erformance due to the existence of ro bust to ols for the development of plug- in, as it has with the Plug-in’s Developmen t Envi- ronment (P DE) which provides to ols to create, develop, test, debug, build and deploy Eclipse plug-ins, mo dules and features to up date the s ites and pro ducts Riched Client Platform (RCP). PDE consists of three element s: – PDE User Interface (UI) fo r designing the user interface; – PDE T o ols Application Pr ogramming Interface (API T o oling) useful pieces of co de to develop applications ; – PDE Builder (Build), ma na ger resp onsible for the administra tio n o f the plug- in. Besides all this, the GMF frameworks (Gra phic Modeling F r amew ork - F rame- work for g r aphic editing) and Ec lips e Mo deling F r amew ork (Eclipse Mo deling F ramework, EMF), which facilitate the construc tio n. W e can get a highly func- tional visua l editor using EMF to build a structured data mo del enriched by GMF editors. The main a dv a n tage is that b eing all developmen t based on build- ing a str uctured mo del, the time sp ent o n the maintenance phase will b e sub- stantially reduced. 3.2 The arc hitecture of the task mo del to ol As men tioned ab o ve, our gener al a rc hitecture is base d on the Eclips e framework. The first co mponent is able to mo del T ask Flow diag rams and translate them into a meta mo del formed b y T ask Algebra e x pressions. The resultant file containing the metamo del is use d by the T ask Algebra co mpiler in order to gener ate the trace semantics. In addition, the other comp onent in Eclipse ha s the r espons ibilit y to receive L TL and CTL quer ies. The queries are sent to the relev ant mo del-chec king to ol. T extual results are r eturned by the to ol and have to be interpreted by L TL/CTL Eclipse plugin. Figure 1 shows the genera l dependency b et ween the comp onents of our pr o ject. 4 F ormal mo delling mad e easy 4.1 Design of the structured mo del Once identified the use cas es, cla sses w e r e des igned including the in ter action betw een different ob jects o f the to ol, we then pro ceeded to des ign the structur e d Fig. 1. Architecture of th e T ask Mod el T o ol. mo del. T his mo del is presented in Fig ur e 2. All development of the str uctured mo del is based o n the us e c ase diagr am, when we should b e extra careful as it migrates from an abstr act mo del such a s use ca ses and res ults in a diagram fro m which one has the p ossibilit y of building the computer applica tio n as such, in this case, set the application logic. Note that only c over part of the user interaction. Fig. 2. Class model for the T ask mo del plu g- in ,based on GMF. 4.2 Dev e lopmen t of the graphical mo del When the structured mo del is designed prop erly [2,3], this can b e transformed to the mo del gra ph. The mo del is a set of classes that represent rea l- w orld in- formation. In our case, the comp onents which a re integrated with diagrams. F or example, the Choice comp onent, is asso ciated with a sp ecific b ehaviour, there- fore we need to store s ome additional information (i.e, this comp onent implies information for the g uards that will trigg er the flow). All this without taking int o account neither the manner in which that informa tion will b e display e d nor the mechanisms that make these data are part of the mo del; i.e., without re gard to any o ther entit y w ithin the plug - in. 4.3 The dom ain mo del The domain mo del (or the mo del itself ) is the s e t of clas ses res ulting from analysing the components needed to design a t ask flo w dia gram. Sta r t, T as k, F ork, Join, Exception, F ailur e, Choice a nd End a r e the cla sses that were defined for the domain mo del. The domain mo del is not r elated to external information, we hav e an ov erview of the comp onents of each one of its elements. 4.4 The appli cation m o del The applica tion mo del is a set of cla sses that are re la ted to the doma in mo del, are aware of the views and implement the neces sary mechanisms to notify the latter on the changes that might give the domain mo del. The EMF framework, is resp onsible for this functionality , and which interacts directly with the str uctured mo del; i.e., the mo del built on EMF. 4.5 The vie w do main The v iews are the set of class es that are resp onsible for s ho wing the user the information contained in the mo del. A view is as socia ted with a mo del. A vie w of the mo del gets only the infor mation you need to deploy and is up dated each time the domain mo del changes through notifications generated by the mo del of the application. GMF is resp onsible for receiving such no tifications and for generating visual feedback on the plug -in. 4.6 The driver The driver is an o b ject that is r espons ible for dir ecting the flow o f enfo rcemen t due to external messag e s a nd requests g e nerations of the algebr a . F rom these messages, the controller mo difies the mo del or o pen a nd clo se views . The co n- troller has acces s to the mo del and views, but the v iew and the mo del a re not aw a re of the existence of the controller. The co n tr oller itself is the r esult of the implemen tation co de from the developer , which using GMF has the a bility to int eract with information from the visual editor plug-in. This op eration is given by the I W ork benchW indow ActionDe leg ate class implementation. 4.7 In te gration Finally when the tw o mo dels have b een integrated, w e get almost all of the user int erface plug-in. It is at this p oin t when we hav e to dev e lo p the capabilities to manage graphics’ p erformance a nd integration with the co mponents of the translator (i.e., the log ic implementation, where s pecific individual co mponents). Fig. 3. View of integration and dep endency of the plug-in for developmen t of tasks diagrams. 4.8 Results A t this p oint we have o btained a comprehensive user interface, that is, the pa r t y resp onsible for mana ging the design pr ocess dia grams. It is worth noting that the co de implementation has b een ra ther small, since ev e r ything is generated from struc tur ed mo del. Up to this p oin t we hav e manag e d to cov er ab out half of the pro ject. Figure 4 s ho ws a scr een user interface o f this par t of the pro ject so far. The developmen t of application-bas ed mo dels implemen ted in the v arious to ols fo r creating plug-ins, as is the P lug-in Dev elopment Environment, has re- sulted in optimization of time. The mo st imp ortant po in t is the p ossible mo difi- cation, addition, facilitation and explor ation of the plug-in, b ecause you can just mo dify the structur e d mo del and its subsequent integration w ith GMF mo del to make accura te changes, all witho ut writing a single line o f co de, s o it is found that the design of the mo del implemented in a to ol is sup erior to developmen ts made entirely in c ode. 5 L TL and CTL model-c hec king IDE 5.1 V erification Interf ace of T ask Flow diagrams in the so ft w are sp ecification Some factor s influencing the development of q ualit y softw are are: Understand- ing of requirements, pro per mo deling o f the use cases, verification of mo dels a nd Fig. 4. P artial view of user interface for th e T ask Mo del plu g- in. developmen t ac cording to user needs. T a sk Flow dia g rams from the Discov ery Metho d are repr e s en ted by a reduced and prec ise syntax. The verification over the T a sk Flow dia g rams is p erformed us ing temp oral log ic functions. The mo st common temp oral log ics are Linear T emp oral Logic (L TL) and Computatio nal T ree Log ic (CTL )[4 ]. The temp oral logics a re applied on a n exha ustiv e set of states to s ee if a sp ecification is true or not through time, it ensures verification of dy na mic pr operties of a s y stem without intro ducing t ime explicitly[7]. The T ask Algebra pro posed b y F erna ndez [6] offers a lready the tools (text mode) allowing you to verify T as k Flow diag rams sp ecified by the Discov ery Metho d using temp oral logic. This to ol in text mo de do es not in volv e a visual represen- tation of the op eration and the log ic a l trans ition of the mo del a nd it do es not allow a full analysis of the r esults. The c o nstruction of an interface that allows to structure L TL / CTL querie s and to gr aphically display results of the mo del verification represents the solution of the problem. With the developmen t o f a n interface to verify tas k diagra ms , the user will hav e on ha nd a s tr uctured visual to ol that lets him/her crea te lo g ical expr es- sions to r efer to even ts in the algebr aic mo del of work flow a nd display query results in a more meaning ful a nd understandable way . With the crea tion of these comp onen ts the T a sk Algebra will b ecome more ac c e ssible and with the help of appropria te technologies it will represent a contribution to the sp ecification and design phase in softw ar e de velopment. 5.2 Dev e lopmen t Pro cess The flow of a ctivities in the design phase can b e mo deled by T as k Flow diagra ms, which in addition to its gr aphical repr esen tation has a fo r mal syntactic mo del. The for mal mo del o f the tas k dia grams is the basis for verification of system prop erties. The s tr ucture o f a logical query (L TL/ CTL) is c omplex, ther efore it is necessary to a ssist it in the construc tio n and co mprehension of these expre s sions, as well a s in the visualiza tion of results. Considering the ease of dev e lo pmen t, usage statistics and fea tures offered in developmen t environments, the interface of verification will b e integrated as a plug-in in the E c lipse development environment. F o r bes t results, interface, testing and monito r ing is necessa ry to take into considera tion the following def- initions for the task diagra ms verification pr ocess : – The plug - in should chec k the entry mo del that describ es the task alg ebra. – There should b e a chec k of logical express ions c r eated (L TL and CTL s yn- tax). – The test results should be displa yed in an easy and simple w ay for user understanding. – The verification interface should b e efficient and effective. Among the verification characteristics o f the input model and the e x pressions syntax is used XT ext. In o rder to verify the input mo del and the syntax of the expressions we use XT ext. With XT ext, domain-sp ecific lang ua ges (DSL) can be created in a formal and simple wa y . The framework s upports the de- velopmen t of infrastructure in languages inc luding co mpilers and interpreters and currently it has jo ined the Eclipse development environment. In interface developmen t, Eclipse’s core libra ries such as org.eclips e.ui, or g.eclipse.jface and org.eclipse .c ore ar e used. These pack ages a llow to in tegra te icons a nd complete editor manage ment, results in the interface development are shown in fig ure 5. As we can see, the task diagrams verification interface consists of the following elements: mo dule expres sions, work are a and input mo dels. 5.3 Mo d ul es Interac tivity and Res ults The input for this plug-in is a T ask Alg ebra ex pr ession repre sen ting the T ask Flow metamo del (see Figur e 6a). This metamo del is used to gener ate the tra ce semantics needed to execute the query . A query co nstruction is created and stored when the user builds L TL or CTL logical expressions (see Figure 6b). The algebr a model (tf a) and logica l expressions created (tfq) are verified in contin uous time using DSL gra mmars defined in the plugin (XT ext), which pro duces syn tactically correct expressions. Com bining the algebra model and Fig. 5. Partial view of u ser in terface for th e mod el-c hecking plug-in: DSL Grammars, graphics elements and editor management. Fig. 6. Partial view of the u ser interfa ce for th e mo del-chec k ing plug-in: (a) describing a T ask Flow diagram, (b) describing logical expressions. the correct logical ex pressions, the verification of prop erties in the mo del is executed using the text mo de to ol descr ib ed in [6]. This part of the pr o ject is also resp onsible o f the g raphical display o f the r esults. This is still a w ork in progre s s but it is considere d relev a n t in or de r to facilitate the interpretation of the quer y results. In particula r , the CTL results ar e the most difficult to understand in their present form. 6 Conclusions Being E clipse one of the most used environments for softw are development, we offer a to o l that allows mo delling and testing of softw are mo dels that are defined usually in the sp ecification phases . Our r esearch presented the Eclipse plug-ins for the T ask Flow mo del in the D iscovery Metho d. The task algebr a is based on simple a nd compo und tasks structure d using op erators such as sequence, selection, a nd par allel comp osition. Recursio n and e ncapsulation are a lso con- sidered. The task alg ebra inv olves the definitio n o f the denotationa l semantics for the ta sk algebr a, giving the semantics in terms of traces. Additiona lly , mo del- chec king techniques were developed to v alidate T as k Mo dels repres en ted in the algebra. All of these was alrea dy av ailable as conso le to ols to prove the feasibility of the pro pose but, in or der to b e us ed by r eal-w orld developer s , a n IDE was necessary . With these to ols, develop ers ar e not require d to increas e the quantit y of artifacts when developing s oft ware. If develop ers create T as k Flow diagra ms, they will have an formal s pecification for their softw are which co uld improv e communications us ing the unambiguous notation. In addition, using softw are mo del-c hecking in ea rly stages may increase the confidence that go es fr om a correct definitio n to the final desig n. The plug-ins developed facilitate the forma l sp ecification of the T a sk Flow mo dels and the verification of these mo dels in a visual a nd simple wa y . The queries are structure d visually and with it the int erpreta tion of results is even more simple. With this pro ject the developmen t time has been o ptimized and the quality of softw are has been gua rant eed. In this pr o ject every mo dule is ea sy to use and to understand fo r progra mmers due to its integration with Eclipse. Ac kno wledgmen t This work has bee n funded by the UTM. References 1. Bogdano v, K., Bow en, J.P ., Cleav eland, R., Derrick, J., Dick, J., Gheorghe, M., Harman, M., H iero ns, R.M., Kap oor, K., Krause, P ., Luettgen, G., S imons, A.J.H., Vilkomi r, S., W oo dw ard, M.R., Zedan , H .: W orking together: F ormal metho ds and testing, (2003) 2. Budinsky , F.: Eclipse Mod eling F ramewo rk: A Developer’s Guide. Addison W esley , Boston, Massac husetts, fi rts edn. (2003) 3. Burd, B.: Eclipse for dummies. Wiley Publishing, Inc., I ndiana, U .S.A (2005) 4. Chan, W illiam, R.A.P .B.S.B.D.N., Reese, J.: Model chec k ing large softw are speci- fications. IEEE T ransactions on Soft ware Engineering 24(7), 498–520 (1998) 5. Clark e, E.M., Emerson, E.A., Sistl a, A.P .: Automatic verificatio n of fin ite-state concurrent systems using temporal logic specifications. ACM T ran s. Program. Lang. Syst. 8(2), 244–263 (1986) 6. F ernandez-y F ernandez, C.A.: The Abstract Semantics of T asks and Activity in the Dis cov ery Meth o d. Ph.D. thesis, The Universit y of Sheffield, S heffield, UK (F eb ruary 2010) 7. Gurfinkel, A., C.M., Devereux, B.: T emp oral logic q uery chec king: A to ol for mo del exploration. IEEE T ransactions on Soft ware Engineering 29(10), 898–914 (2003) 8. Simons, A.J.H.: Ob ject disco very - a pro cess for d ev eloping applications. In: W ork- shop 6, British Computer So ciet y SIG OOPS Conference on Ob ject T ec hnology (OT ’98). p. 93. BCS, Oxford (1998) 9. Simons, A.J.H.: Ob ject disco very - a pro cess for developing mediu m-sized applica- tions. In: T utorial 14, 12th Europ ean Conference on Ob ject-Oriented Programming (ECOOP ’98). p. 109. AITO/ACM, Brussels (1998) 10. Spivey , J.M.: An introduction to z and formal sp ecifications. S oft ware Engineering Journal IEEE/BCS 4(1), 40–50 (1989) 11. Wing, J.M.: A sp ecifier’s in tro duction to formal metho ds. IEEE Computer 23(9), 8–24 (1990)