Eliciting a high quality requirements model that can be traced down to implementations is a challenge. Keeping models updated for evolving software systems is a further challenge. Formal modelling methods are one approach - but one that is too rigid and costly for many small software engineering companies [1]. We propose a light-weight alternative, using a wiki as the synchronous bridge between requirements capture and more formal modeling features of the IDE such as Eclipse

Petre, Marian

Tun, Thein Than

Yu, Yijun

English

Open Research Online

Open Research OnlineThe Open University’s repository of research publicationsand other research outputsMiki: a wiki for synchronous modeling of softwarerequirementsConference or Workshop ItemHow to cite:Yu, Yijun; Petre, Marian and Tun, Thein Than (2011). Miki: a wiki for synchronous modeling of softwarerequirements. In: 4th FlexiTools workshop @ ICSE 2011, 22 May 2011, Waikiki, Honolulu, Hawaii.For guidance on citations see FAQs.c© 2011 The AuthorsVersion: Version of RecordLink(s) to article on publisher’s website:http://www.ics.uci.edu/ nlopezgi/flexitoolsICSE2011/papers/yu flexitools icse2011.pdfCopyright and Moral Rights for the articles on this site are retained by the individual authors and/or other copyrightowners. For more information on Open Research Online’s data policy on reuse of materials please consult the policiespage.oro.open.ac.ukMiki: A Wiki for Synchronous Modelingof Software RequirementsYijun Yu Marian Petre Thein Than TunComputing DepartmentThe Open UniversityUnited KingdomABSTRACTEliciting a high quality requirements model that can betraced down to implementations is a challenge. Keepingmodels updated for evolving software systems is a furtherchallenge. Formal modelling methods are one approach –but one that is too rigid and costly for many small soft-ware engineering companies [1]. We propose a light-weightalternative, using a wiki as the synchronous bridge betweenrequirements capture and more formal modeling features ofthe IDE such as Eclipse .1. INTRODUCTIONRequirements engineers face the challenge of eliciting fromstakeholders high quality formal models for reasoning andanalysis purposes. In practice, however, requirements areoften informally stated, requiring substantial effort to digest.Requirements modeling methods usually demands a ratherheavy use of formal modeling tools, usually a big barrier forsmall software engineering companies to adopt [1].One way to alleviate this elicitation problem is to interfacea full-fledged modeling tool through its plugin with a wikisystem. Available to every Web browser, wikis have been ap-plied to software projects for documenting various artifactsranging from source code, design blueprints, bug reports,mailing lists, etc [7]. Through collective uses of the wikis,a software development team can elicit requirements as in-formal text in a rather flexible format. Linking to relateddomain knowledge through wiki names requires little effort.Integrating with change management systems such as sub-version is also possible. Trac1 is an example wiki systemused by software development teams. It can associate wikipages with snippets and revisions of the source code. Onthe other hand, a formal requirements model still needs tobe elicited manually from these informal descriptions.An additional problem is updating the links from the for-1http://trac.edgewall.org/mally stated requirements down to solutions in the sourcesof evolving software systems [3]. A loose integration such asthe EclipseTracPlugin 2 still requires users themselves toupload the models created by heavy Eclipse modeling toolsinto more flexible Trac wiki attachments.This paper demonstrates a technical solution that integratesthe modeling tools tightly within a wiki system such thatanalysts, end-users, other types of stakehoders only needa Web browser to create and maintain modeling diagrams.In addition to the Trac wiki format – which is suitable fordocumenting informal requirements – our extended macroalso accepts formal requirements modeling languages of ex-isting Eclipse-based tools as the input. From the input,stakeholders can get the formal models in both graphicaland textual syntaxes. The synchronously update feature ofMiki makes it less demanding to bridge formal requirementsmodels and the informal wiki pages.Our limited experience in the prototype Miki system is re-ported in this paper, with a position that a wiki enhancedwith formal modeling features that could produce easy tomaintain models that would help achieve the objective of flex-ible modeling and sketching of requirements.2. THE MIKI SYSTEMFigure 1 overviews the Miki system as a service that synchro-nizes textual and graphical models from a wiki users’ per-spective. The example illustrated here is that of analysingthe Sluice Gate problem using the Problem Frames method [6].Other modeling languages such as i* [10] and argumenta-tion [5] are equally supported by our web-based Open Re-quirements Engineering lab3, running as an instance of Miki.Wiki is an effective means to document requirements collab-oratively and informally among the group members. To il-lustrate the effectiveness on the other extreme of the flexiblemodeling spectrum, i.e. modeling formal requirements, wecompare Miki with (Trac + Eclipse ) in three operationaluse cases (creating, updating and deleting). In each of them,the formal requirements models are shown updated in thewiki pages, reflecting users’ modifications in a light-weightfashion, in terms of bandwidth, time and effort savings. Therequirements engineers in the SecureChange research projectuse the Miki prototype and have confirmed the usefulnessin eliciting early requirements: they could share and edit2http://trac-hacks.org/wiki/EclipseTracPlugin3http://computing-research.open.ac.uk/trac/openreFigure 1: An overview of the Miki systemthe requirements model using the bare browsers remotelyand document the background knowledge on the same wikipages; when they are meeting face-to-face in front of a desk-top, the advantages of Miki over the Eclipse alternative isthe provision and recording of secondary annotations in thefree-formed wiki format [4].The size of the model in textual form (DSL) is not a scal-ability issue for the tool support, however, visualising thewhole model in one page could contain excessive informa-tion for users due to the automatic layout of large diagrams.According to our users, this problem can be alleviated bydividing the large textual model into chunks that can betreated as individual diagrams separately, while maintainingthe traceability from the original model to these fragmenteddiagrams. Although all our modeling languages such as goalmodels and problem frames can be hierarchically used, ingeneral not all requirements languages support this type ofhierarchical views.2.1 Creating a modelWhen a user wants to create a model using a domain-specificlanguage (DSL) through Miki , she starts with entering anextended Trac macro (see Figure 2 for a screenshot):{{{#!openpf... domain specific language in $ext ...#!$ext}}}where #!openpf is the opening pragma for the macro we cre-ated in Miki ; $ext (e.g., instantiate to an extension namesuch as “problem” in Figure 2) in the closing pragma #!$extis the abbreviation of the DSL, used as the file extensionname of the corresponding model; the content of the model-ing file is filled by the text in-between the opening and theclosing pragmas. Once submitting the above macro in Miki,a modeling file $wiki.$ext will be created into an inputfolder with $wiki being the name of the wiki page embed-ding the macro. Our customised running Eclipse instancemonitors constantly any change inside the input folder todiscover and load the model file into the editor generatedby the Xtext framework for the DSL $ext [2]. On top ofstandard applications of model-driven software developmentprocess [9], we have introduced two major automations forthe purpose of synchronised modeling:The first one converts the modeling text in the generatedsyntax highlighted editor into a color-coded file $wiki.$ext.html in an output folder using the following encoding pertoken:<font color=‘‘#RRGGBB’’>[<$style>]$token[</$style>]</font>The hexdecimal RRGGBB colors the $token in the RGBscheme, and the optional $style is chosen between “B” forbold and “I” for italics, depending on the choices made bythe Xtext editor.The second automation generates an Eclipse modeling frame-work (EMF) model $wiki.$ext.xmi that could be loaded bya corresponding graphical modeling framwork (GMF) ed-itor that visualizes the same model graphically. A stan-dard GMF editor plugin normally just visualises a graph inEclipse, without saving it into a form for the use by an ex-ternal wiki. Therefore the visualisation must be extended tofulfil the second half of our goal, i.e., to embed the graph aspart of the wiki page. This is done automatically throughseveral customizations to the GMF editors.First we make use of the GUI-free API in the GMF runtimeto save the model opened in the GMF plugin into graphicalfile formats such as $wiki.$ext.png and $wiki.$ext.pdf,and put them into the output folder. The Miki system con-stantly monitors the changes inside the output folder un-til these output files are saved from both the Xtext andGMF editors, then automatically import them as attach-ments to the $wiki page: the HTML output file is auto-matically inserted into the wiki page after translating theHTML encoding as native ones in the Python Trac exten-sion, and the image output is embedded by the generatedTrac macro [[Image(attachment: $wiki.$ext.png)]] onthe same wiki page.In brief, Figure 3 presents the architecture of the Miki sys-tem, exemplified by the data flow. As a result (see Figure 4),along with the rest of the informal wiki text, users will seeboth the textual and graphical representations of the formalmodel. The whole process is automated and takes no morethan a few seconds.2.2 Updating a modelOnce the model was created and shared on the wiki, to up-date the model another user may simply edit the Miki macroand resubmit. Upon an update of the Miki page, the sys-tem checks the normalised $wiki.$ext model against thecached one for any difference. Without a difference, noth-ing will be created so that the user can see the updatedwiki with the formal model instantly; otherwise, updatedmodel diagrams will be regenerated from the updated macro,which can take only a couple of seconds longer than a nor-mal update of the wiki page. Since we make use of theorg.eclipse.xtext.gmf.glue extension to Xtext for thesynchronous editing of Xtext, EMF and GMF models, anupdate of the graphs also takes less time than a completeregeneration of the graph models. In this way, updating thenon-Miki macro parts of the page does not take extra time,making the Miki system as responsive as its Trac predeces-sor.2.3 Deleting a modelIf the Miki page is no longer needed, the model and auxil-iary files generated from the Miki system shall be removed.This is done by the synchronous monitor sits in-between therunning Eclipse and the Trac systems. Once a removal ofthe file $wiki.$ext happens, in a few milliseconds a noti-fication from the file system will be caught by the runningEclipse monitor such that all $wiki.$ext.* files will beremoved from the project resources, and the correspondingattachments in the Trac wiki page will be removed as well.2.4 Comparing Miki with (Trac + Eclipse )For all the three operational use cases, Table 1 compares thedifferences between Miki and its baseline predecessor (Trac+ Eclipse ) in the steps of basic usage scenarios, time auser spent, the network bandwidth; all based on the con-crete Sluice Gate example. Here Miki stands for a browserclient visiting the Miki wiki; Trac stands for a browser clientvisiting the Trac wiki, and Eclipse stands for an Eclipse in-stance that has the Xtext, GMF editor plugins instances forthe supported DSL (in our cases the OpenPF4 tool installed4http://sead1.open.ac.uk/openpfon the client side).Note that the time estimation of editing the wiki page isassumed to be 1 minutes just for an illustration, and othermouse click/shortcut key interactions require 1s each. Thebandwidth estimation is based on the actual size of the DSLspecification and generated diagrams.3. RELATEDWORKMozilla Ace for Cloud9 IDE 5 is one of the projects aimingto provide a syntax-highlighted text editor on the Web usingthe HTML5 canvas feature. Ideally it could be used to editnot only Javascript programs but also domain specific lan-guages of various sorts. However, comparing to the maturemodel-driven tool development frameworks such as Xtext,Ace requires substantially more effort to customise the do-main specific language for different requirements models.For requirements languages currently supported in Eclipse -based modeling environment, therefore it might require lessinvestment to support a syntax highlighting online editor.To this aim, it would be nice if the Xtext framework couldalready generate a Web-based text editor automatically us-ing the rich Ajax platform (RAP), as indicated by the fol-lowing April Fool’s day wish 6. Lacking support of deployinga full Eclipse framework to the Web, however, this featureis not within the release plan of the Xtext project.Ossher et al [8] propose to support flexible modeling usingthe BITkit tool built on top of Adobe Flex, which needsto be preinstalled. Miki could enable yet another level offlexibility, i.e. to synchronously edit the models using thewiki browsers alone. The Eclipse Sketch project7 providesyet another route to support flexible modeling, where anytype of graphical syntax could be supported through therecognision of the model from hand drawings. Since Sketchis supported by Eclipse, it is our belief that such graphrecognision tool could be combined with the Miki systemwhile such inputs could be provided by a whiteboard pluginfor the wiki.4. CONCLUSIONS AND FUTUREWORKIn this work, we have discussed the motivations of loweringthe barriers of adoption for flexible modeling tools throughthe use of wikis, which can provide a synchronous bridgebetween requirements capture and the more formal model-ing features of the IDE such as Eclipse. A proof-of-conceptimplementation has been detailed with a running exam-ple to explain how we tightly integrate any Eclipse-basedgraph modeling tool into the Trac wiki. Currently the toolsupports any Eclipse-based modeling representations thatcan be supported by Xtext, EMF and GMF. An instanceof the Miki system is exemplified at the website http://computing-research.open.ac.uk/trac/openre. Our ini-tial experience that the text-based informal representationsin Miki can be used effectively in eliciting formal require-ments models, saving bandwidth, time and effort.Without further empirical evidence of how frequent such use5http://ace.ajax.org/6http://kthoms.wordpress.com/2010/04/01/bringing-xtext-to-the-web/7http://www.eclipse.org/sketchTable 1: Comparing basic use cases between (Trac + Eclipse ) and MikiOperation Trac + Eclipse Sec. Byte Miki Sec. ByteInstalling installing Eclipse instance 600 200 M -Creating starting Eclipse instance 20 0 -editing DSL using Trac 30 346 editing DSL using Miki 30 346copying/pasting DSL from Trac to Eclipse 4 0 -saving DSL in Eclipse as EMF 6 0 -loading EMF in Eclipse as GMF diagram 3 0 -screenshot from GMF to an image 1 0 -uploading an image to Trac 10 10.6 K submitting the Miki page 10 380inserting link to attachment in Trac 10 346 -Updating starting Eclipse instance 20 0 -editing DSL using Trac 10 350 editing DSL using Miki 10 350copying/pasting DSL from Trac to Eclipse 4 0 -saving DSL in Eclipse as EMF 6 0 -loading EMF in Eclipse as GMF diagram 3 0 -screenshot from GMF to an image 1 0 -uploading an image to Trac 10 10.6 K submitting the Miki page 10 380Deleting deleting Trac page 1 380 delete Miki page 1 380deleting Trac attachments 1 0 -deleting Eclipse model files 3 0 -refreshing the Eclipse resource nativator 1 0 -cases happen in formal requirements modeling, here we onlyposition that Miki > (Trac + Eclipse ) as long as formal re-quirements need to be collaboratively edited. Further studyis required to tell whether Web-based interaction limits theability to edit the diagrams directly rather than having toedit the textual domain-specific languages.It is remained to be experienced how Miki would help usersengaging in the early stage of modeling. We plan to inves-tigate the cognitive dimensions [4] when evaluating Miki’seffectiveness in shortening the conceptual distances betweenusers. We intend to conduct an empirical studies to evalu-ate the benefits with respect to supporting flexible modelingtools through the Miki system by logging the number of in-teractions. To support a spectrum of models ranging fromas informal as a wiki page to those that are amenable toformal reasoning and execution, for example, we intend tostudy how to support the direct diagram editing in the Web-based interfaces. Also we would investigate the opportunityto integrate other flexible modeling tools with Miki .AcknowledgementThis work is in part supported by the EU FP7 SecureChangeproject (http://securechange.eu).5. REFERENCES[1] Jorge Aranda, Steve M. Easterbrook, and GregWilson. Requirements in the wild: How smallcompanies do it. In RE, pages 39–48. IEEE, 2007.[2] Moritz Eysholdt and Heiko Behrens. Xtext:implement your language faster than the quick anddirty way. In William R. Cook, Siobha´n Clarke, andMartin C. Rinard, editors, SPLASH/OOPSLACompanion, pages 307–309. ACM, 2010.[3] Orlena Gotel and Anthony Finkelstein. Extendedrequirements traceability: Results of an industrial casestudy. In 3rd IEEE International Symposium onRequirements Engineering (RE’97), January 5-8,1997, Annapolis, MD, USA, pages 169–, 1997.[4] T.R.G. Green and M. Petre. Usability Analysis ofVisual Programming Environments: A ’CognitiveDimensions’ Framework. Journal of Visual Languagesand Computing, 7(2):131–174, 1996.[5] Charles B. Haley, Robin C. Laney, Jonathan D.Moffett, and Bashar Nuseibeh. Security requirementsengineering: A framework for representation andanalysis. IEEE Trans. Software Eng., 34(1):133–153,2008.[6] Michael Jackson. Problem Frames: Analysing andStructuring Software Development Problems.Addison-Wesley, New York, December?Winter 2001.[7] Panagiotis Louridas. Using wikis in softwaredevelopment. IEEE Software, 23(2):88–91, 2006.[8] Harold Ossher, Rachel K. E. Bellamy, Ian Simmonds,David Amid, Ateret Anaby-Tavor, Matthew Callery,Michael Desmond, Jacqueline de Vries, Amit Fisher,and Sophia Krasikov. Flexible modeling tools forpre-requirements analysis: conceptual architecture andresearch challenges. In William R. Cook, Siobha´nClarke, and Martin C. Rinard, editors, OOPSLA,pages 848–864. ACM, 2010.[9] Bran Selic. The pragmatics of model-drivendevelopment. IEEE Software, 20(5):19–25, 2003.[10] Eric S. K. Yu. Towards modeling and reasoningsupport for early-phase requirements engineering. In3rd IEEE International Symposium on RequirementsEngineering (RE’97), January 5-8, 1997, Annapolis,MD, USA, pages 226–235. IEEE Computer Society,1997.Figure 2: Input to Miki through the Trac editor pageFigure 3: The architecture of the Miki systemFigure 4: An example Miki page as output

Miki: a wiki for synchronous modeling of software requirements

http://oro.open.ac.uk/28886/1/yu_flexitools_icse2011.pdf

Miki: a wiki for synchronous modeling of software requirements

Abstract

Similar works

Full text

Available Versions

Open Research Online