upgrade, vol. ix, issue no. 6, december 2008 - cepis.org · 2 presentation. network management and...

2 Presentation. Network Management and Quality of Service— Ramon Puigjaner-Trepat and Raouf Boutaba

5 Application Oriented Network Management — MiquelBordoy-Marcó, Jaume Prohens-Vadell,and Antonio Sola-Venteo

12 E2E Service Delivery through User Mobile SessionManagement — Noëmie Simoni, Chunyang Yin,and KenChen

22 Secure Management of SCADA Networks — CristinaAlcaraz-Tello, Gerardo Fernández-Navarrete, RodrigoRoman-Castro, Ángel Balastegui-Velasco,and Javier López-Muñoz

29 Converting Computer Network Malicious Activity intoDigital Footprints Based on a Notional Representation —Grigorios Fragkos

36 An Autonomic Architecture for Network Management andControl — Guy Pujolle

41 Autonomic Systems in Network and Service Management —Joan Serrat-Fernández, Antonio Astorga-Rivera,and JavierRubio-Loyola

49 Users and Network Management for Secure Interworkingand Roaming in WiMAX, 3G and Wi-Fi Networks Using RIIArchitecture — Vamsi-Krishna Gondi and Nazim Agoulmine

59 A Life Devoted to Innovation in IT — Press Conference withRadia Perlman

* This monograph will be also published in Spanish (full version printed; summary, abstracts, and somearticles online) by Novática, journal of the Spanish CEPIS society ATI (Asociación de Técnicos deInformática) at <http://www.ati.es/novatica/>.

Vol. IX, issue No. 6, December 2008

UPGRADE is the European Journal for theInformatics Professional, published bimonthlyat <http://www.upgrade-cepis.org/>

PublisherUPGRADE is published on behalf of CEPIS (Council of European Pro-fessional Informatics Societies, <http://www.cepis.org/>) by Novática<http://www.ati.es/novatica/>, journal of the Spanish CEPIS society ATI(Asociación de Técnicos de Informática, <http://www.ati.es/>)

UPGRADE monographs are also published in Spanish (full versionprinted; summary, abstracts and some articles online) by Novática

UPGRADE was created in October 2000 by CEPIS and was firstpublished by Novática and INFORMATIK/INFORMATIQUE, bi-monthly journal of SVI/FSI (Swiss Federation of ProfessionalInformatics Societies, <http://www.svifsi.ch/>)

UPGRADE is the anchor point for UPENET (UPGRADE EuropeanNETwork), the network of CEPIS member societies’ publications, thatcurrently includes the following ones:• Informatica, journal from the Slovenian CEPIS society SDI• Informatik-Spektrum, journal published by Springer Verlag on behalf

of the CEPIS societies GI, Germany, and SI, Switzerland• ITNOW, magazine published by Oxford University Press on behalf of

the British CEPIS society BCS• Mondo Digitale, digital journal from the Italian CEPIS society AICA• Novática, journal from the Spanish CEPIS society ATI• OCG Journal, journal from the Austrian CEPIS society OCG• Pliroforiki, journal from the Cyprus CEPIS society CCS• Pro Dialog, journal from the Polish CEPIS society PTI-PIPS• Tölvumál, journal from the Icelandic CEPIS society ISIP

Editorial TeamEditorial TeamChief Editor: Llorenç Pagés-CasasDeputy Chief Editor: Francisco-Javier Cantais-SánchezAssociate Editors: Fiona Fanning

Rafael Fernández Calvo

Editorial BoardProf. Wolffried Stucky, CEPIS Former PresidentProf. Nello Scarabottolo, CEPIS Vice PresidentFernando Piera Gómez and Llorenç Pagés-Casas, ATI (Spain)François Louis Nicolet, SI (Switzerland)Roberto Carniel, ALSI – Tecnoteca (Italy)

UPENET Advisory BoardMatjaz Gams (Informatica, Slovenia)Hermann Engesser (Informatik-Spektrum, Germany and Switzerland)Brian Runciman (ITNOW, United Kingdom)Franco Filippazzi (Mondo Digitale, Italy)Llorenç Pagés-Casas (Novática, Spain)Veith Risak (OCG Journal, Austria)Panicos Masouras (Pliroforiki, Cyprus)Andrzej Marciniak (Pro Dialog, Poland)Thorvardur Kári Ólafsson (Tölvumál, Iceland)Rafael Fernández Calvo (Coordination)

English Language Editors: Mike Andersson, David Cash, ArthurCook, Tracey Darch, Laura Davies, Nick Dunn, Rodney Fennemore,Hilary Green, Roger Harris, Jim Holder, Pat Moody, Brian Robson

Cover page designed by Concha Arias-Pérez"The Dome of Gods" / © CEPIS 2008Layout Design: François Louis NicoletComposition: Jorge Llácer-Gil de Ramales

Editorial correspondence: Llorenç Pagés-Casas <[email protected]>Advertising correspondence: <[email protected]>

UPGRADE Newslist available at<http://www.upgrade-cepis.org/pages/editinfo.html#newslist>

Copyright© Novática 2008 (for the monograph)© CEPIS 2008 (for the sections UPENET and CEPIS News)All rights reserved under otherwise stated. Abstracting is permittedwith credit to the source. For copying, reprint, or republication per-mission, contact the Editorial Team

The opinions expressed by the authors are their exclusive responsibility

ISSN 1684-5285

Monograph of next issue (February 2009)

"Universal, Ubiquitous and IntelligentWeb"

(The full schedule of UPGRADE is available at our website)

Monograph: New Trends in Network Management(published jointly with Novática*)Guest Editors: Ramon Puigjaner-Trepat, Raouf Boutaba

CEPIS NEWS

77 Selected CEPIS News — Fiona Fanning

UPENET (UPGRADE European NETwork)

65 From Informatik Spektrum (GI, Germany, and SI,Switzerland)Software EngineeringModel-Driven Development - Piecing together the MDA JigsawPuzzle — Oscar Pastor, Sergio España, José Ignacio Panach,and Nathalie Aquino

UPGRADE Vol. IX, No. 6, December 2008 65© CEPIS

UPENET

Software Engineering

Model-Driven Development - Piecingtogether the MDA Jigsaw Puzzle

Oscar Pastor, Sergio España, José Ignacio Panach, and Nathalie Aquino

© 2008 Informatik SpektrumThis paper was first published, in English, by Informatik-Spektrum (Volume 31, issue 5, October 2008, pp. 394-407).

Informatik-Spektrum (<http://www.springerlink.com/content/1432-122X/>), a UPENET partner, is a journal published,in German or English, by Springer Verlag on behalf of the German CEPIS society GI (Gesellschaft für Informatik, <http://www.gi-ev.de/>) and the Swiss CEPIS society SI (Schweizer Informatiker Gesellschaft - Société Suisse des Informaticiens,<http://www.s-i.ch/>)

The model-driven architecture (MDA) paradigm is well-known and widely used in the field of model-based softwaredevelopment. However, there are still some issues that are problematic and that need to be dealt with carefully. In this paperwe present a metaphor that explains how MDA grows in complexity as problems faced become more difficult or “wicked”,and how a method designed to be powerful, flexible and MDA-compliant can eventually become, in effect, a “jigsaw puzzle”.This jigsaw puzzle is not merely the result of having a collection of methodological “pieces” with routes across them, but alsoarises as a result of the criteria underlying the MDA abstraction layers. We compare MDA to other research fields such ashuman-computer interaction, model management and method engineering, and we use as an example the OO-Method, asoftware development method based on MDA-compliant model transformations. We focus on a methodological piece that isconceived to allow the specification of interaction requirements by means of interface sketches. These sketches are supportedby a task model that serves as a sound basis for formalisation and allows the application of model transformation in order toobtain subsequent models. A case study illustrates the requirements capture method together with the software developmentprocess defined by the OO-Method. The whole process presented in the case study represents one of the possible routes thatcan be followed when developing a software system with the OO-Method.

Keywords: MDA Jigsaw Puzzle,Model-Based Software Development,Model-Driven Architecture, OO-Method, Software Engineering.

Authors

Oscar Pastor is Professor and Director ofthe Centro de Investigación en Métodos deProducción de Software (ProS, ResearchCentre on Software Methods Production) ,<http://www.pros.upv.es/>, of the Universi-dad Politécnica de Valencia, Spain. He gothis PhD in 1992. Formerly he was aresearcher in HP Labs, Bristol, UK. He is(co-) author of more than 100 research papersin conference proceedings, journals andbooks, and he has received numerousresearch grants from public institutions andprivate industry. He was keynote speaker at

many conferences and workshops. Researchactivities focus on web engineer-ing, object-oriented conceptual modelling, requirementsengineering, informa-tion systems andmodel-based software production.<[email protected]>Sergio España received his MSc inComputer Science and is a member of theCentro de Investigación en Métodos de Pro-ducción de Software (ProS), <http://www.pros.upv.es/>, of the UniversidadPolitécnica de Valencia, Spain. He currentlyholds a grant by the Spanish Ministry ofScience and Innovation. His researchinterests revolve around informationsystems, requirements engineering, concep-tual modelling and interface design.<[email protected]>José Ignacio Panach is a member of theCentro de Investigación en Métodos de Pro-

ducción de Software (ProS), <http://www.pros.upv.es/>, of the UniversidadPolitécnica de Valencia, Spain. Currently heis working on how to model usability at thefirst stages of the software developmentprocess. This work is being developed in hisPhD thesis. Moreover, he has participated inworks for capturing interaction requirementsand how to evaluate automatically the systemusability from conceptual models.<[email protected]>Nathalie Aquino is a member of the Centrode Investigación en Métodos de Producciónde Software (ProS), <http://www.pros.upv.es/>, of the Universidad Politécnica de Valen-cia, Spain. She is also a PhD student of theUPV. Research activities focus on model-based user interface development and userinterface engineering.<[email protected]>

66 UPGRADE Vol. IX, No. 6, December 2008 © CEPIS

UPENET

IntroductionThe MDA paradigm [21] is

extensively used by the softwareengineering (SE) community. There area large number of methods, such asUSIXML [33] or OOWS [14], that arebased on the MDA paradigm and thatapply model transformations during thedevelopment process.

The MDA paradigm proposesseveral models to represent the system.Each model describes the system froma different abstraction level. Accordingto MDA, the first model to be builtduring the software developmentprocess is the computation-independent model (CIM). The CIM isa viewpoint focused on theenvironment and system requirements;it disregards the computerisation of thesystem being modelled. The next levelof abstraction is called the platform-independent model (PIM). This modeltakes into account which parts of thesystem will be computerised, but it stilldoes not determine the technologicalplatform that will support theimplementation. After these modelshave been built, a platform-specificviewpoint is needed. This layer iscalled the platform specific model(PSM) and it describes the systemattending to the specific characteristicsof the platform that will support it.Finally, the code model is derived fromthe PSM. Transformations among allthese MDA models are(semi)automatic, depending on theMDA environment that supports them.Moreover, some MDA environmentsimplement MDA models with acombination of several models. Theroute from the CIM to the final codecan be quite tortuous, because theanalyst has to construct a large numberof models.

Furthermore, depending on anumber of contingencies, the sequencein which the analyst fills out the modelsmay change. For example, a CIM canbe composed of several requirementsmodels. The order in which they arebuilt may be determined by the type ofuser that is formulating therequirements. Certain requirementmodels may be more appropriate forinitiating capturing requirements with

an expert computer user than others.One contribution of this paper is to

show that there are various ways ofautomatically generating the final codein an MDA environment called the OO-Method [27]. The OO-Method is asoftware development method thatmodels the system at differentabstraction levels, distinguishingbetween problem space (the highestabstract level) and solution space (thelowest abstract level). The softwaregeneration process of the OO-Methodis shown in Figure 1. This figure alsoshows the correspondence betweeneach OO-Method model and the MDAmodels. It is important to note here thatsome models belonging to the samestage in the OO-Method softwaredevelopment process correspond todifferent MDA models. This issue willbe discussed in Section 3. Each OO-Method model can be seen as a pieceof a jigsaw puzzle that has to fittogether with the rest, depending on anumber of factors. All pieces togetherrepresent the system being built.

From all the pieces that composethe OO-Method jigsaw, this workfocuses on the pieces (models) thatcapture interaction requirements,which are very important non-functional requirements whenproducing high-quality software. Asystem with an inadequate interactionis likely to be rejected by the user, eventhough the system is functionallycorrect. Many MDA-based approachesdisregard interaction requirements; indoing that, we argue, they disregard akey factor for success.

Our proposal to capture interactionrequirements is based on a formalnotation proposed by Paternò calledConcurTaskTree (CTT) [28]. A taskdefines how the user can reach a goalin a specific application domain. Themain reason for using this notation isthe fact that it is a formal language thatprovides a formal semantic, makes themodel verifiable, and avoids ambiguityin the specification.

However, creating task trees duringrequirements modelling is an arduousendeavour. This notation is not friendlywith regard to medium-sized systems.For this reason, this paper proposes tosuperimpose a more manageable modelover the task trees (although it adds anew piece to the jigsaw puzzle). Theproposed model is based on sketches,i.e. drawings that represent the finalsystem interface. Each part of a sketchcorresponds to a part of a CTT tree. Inorder to guarantee the correspondencebetween sketches and CTTs, syntacticrules have been defined. These ruleslimit the degree of freedom whenproducing the sketches, but they allowderivation of the CTTs from thesketches. CTTs are synchronouslycreated while the analyst is creating thesketches.

To accomplish these goals thispaper is structured as follows. Section2 shows a set of related works basedon method engineering and interactionrequirements capture. Section 3reflects on the complexity of usingMDA methods with their multiplemodels and multiple routes formodelling, and the MDA jigsaw

Figure 1: Comparison between MDA and the OO-Method.


UPENET

metaphor is introduced. Section 4focuses on interaction requirementscapture. Section 5 shows a case studyusing the pieces of the OO-Methodjigsaw puzzle that support user-systeminteraction modelling. Finally, Section6 provides our conclusions and outlinespossible future work.

Related WorksThis work is related to the

application of situational methodengineering to requirements elicitation,alternative routes for following theOO-Method, and capturing interactionrequirements by means of sketches. Inthis section a brief review of theserelated works is presented.

Method engineering represents astructured framework in whichmethods for software developmentactivities can be designed, constructed,and adapted. Methods are assembledfrom multiple individually identifiableparts, often referred to as “methodfragments” or “method chunks”.Situational method engineering istherefore the configuration of theseresultant methods specifically forindividual projects [5]. This topic isespecially relevant and useful in areassuch as requirements engineeringwhere various situation-specificfactors, e.g. project objective,application domain, features of theproduct to be developed, stakeholdersinvolved, and technological conditionsand constraints, exert a significantinfluence [2].

Ågerfalk and Ralyté [2] haveidentified an initial and traditionalassembly-based approach in methodengineering. In their work theprocedure was used to describemethods and processes in meta-modelsto be used as a basis for computersupported instantiation of situationalmethods, typically through theassembly of a number of methodfragments from different methodsstored in a method base [6, 20].Recently, however, method engineeringresearch and practice have extendedbeyond the traditional assembly-basedapproach to address a variety of issuesincluding method requirementsspecification [15], method configuration

[17] and roadmap-driven approaches[22]. Recent works [1, 18] also pay moreattention to method rationale (i.e. thereasons behind and arguments for themethod) and the tension betweenmethod-in-concept (as described inmethod handbooks) and method-in-action (as enacted in actual engineeringpractice).

Taking into consideration the ideasbehind situational method engineeringand requirements engineering, thispaper is a first step to analyze differentroutes or directions taken whenfollowing the OO-Method. This iswhere a useful connection can be madebetween MDA and situational methodengineering. Different starting pointsin the requirements phase, as well asdifferent routes for continuing thesoftware development process, couldrepresent an improvement, dependingon the characteristics of the specificproject to be developed. In this work,the analysis is limited to possiblealternatives, but always within thesame software development method:the OO-Method.

Regarding interaction requirements,it can be said that no widely acceptedmethod for capturing them currentlyexists, and that the drawing of userinterface sketches is becoming moreimportant in this field. A significantvariety of tools now exist for drawinginterface sketches which are then usedto automatically (or semi-automatically) generate the finalinterface.

DEMAIS [3] and DENIM [25] aretools for designing a particular kind ofapplication. DEMAIS was speciallydesigned for multimedia applicationsdesign. This tool allows the designerto shape interaction and temporalityideas and to see the result obtained.DENIM helps website designers in thepreparation of sketches at differentlevels: site map, storyboard andindividual pages. The levels are unifiedthrough views.

On the other hand, more generaltools exist for designing any type ofapplication. One of these tools is SILK[19], which provides four primitives:rectangle, free line, straight line, andellipse. Interface prototypes are formed

combining primitives. The designercan choose the interface componentsstyle once the tool has recognized eachcomponent (i.e. button type).Storyboards are used to illustratenavigation between interfaces.JavaSketchIt [7] uses a combination ofsimple figures for representing eachpossible widget (interface component).FreeForm [30] is another tool forcreating sketches. Storyboards are usedto navigate between sketches. The toolhas an execution mode in which theuser can test navigations, and offers afacility to align and determine astandard size for the created controls.

On one hand, all the previouslypresented tools generate code for aspecific programming language whichvaries according to the tools. On theother hand, SketchiXML [9] generatesuser interface specifications inUsiXML [33], a platform-independentlanguage for user interface description.This tool is able to advise the user aboutpotential usability problems in thesketches that are produced. Besides, thefigure representations can beconfigured by the user.

All the previously described toolsshare a common limitation: they onlygenerate the software system interface,and in some cases, support navigationbetween interfaces. The approachproposed in this work was designed tobe incorporated into a completelyfunctional automatic code generationprocess, which uses a model compilerto generate not only the software userinterface, but all the informationsystem functionality too. Otherrelevant characteristics of the approachare the independence of the codelanguage, which is generated to supportdifferent platforms.

The MDA Jigsaw Puzzle andthe OO-Method

Software development methodsusually offer several modellingtechniques. The aim is that modelscomplement each other and offervarious perspectives on reality. In somecases, the complementary nature of theperspectives is horizontal. For example,aspect-oriented methods seek tosegregate cross-cutting concerns that are


UPENET

observable at a certain abstraction level.In other cases, the complementarynature of the perspectives is vertical.The aim is to segregate the differentabstraction levels of the descriptions.For example, data flow diagrams allowthe level of detail of system descriptionsto be increased by means of stepwiserefinement. The four views of the OO-Method conceptual model (object,dynamic, functional and presentationmodels) also specify complementaryperspectives on reality. For example, thefunctional model offers a horizontalcomplementary perspective with respectto the other three models. The functionalmodel deals with aspects related toinformation system (IS) reaction whilethe other models specify IS memory andIS interface. However, the object modelalready has a dynamic part thatstructures IS reaction in terms of classmethods. The functional model refinesclass methods by decomposition so, inthis sense, it also offers a verticalcomplement to the object model.Further argumentation on the use ofcomplementary perspectives can befound in [26].

The MDA paradigm proposescriteria to structure system descriptionsin different layers. Having reached thispoint, a question arises: whether thecomplementary nature of the MDAlayers is horizontal or vertical. MDAmodel definitions do not clarify thisissue. Another question is whether theMDA criteria are pragmatic in realprojects. As Figure 2 depicts and welater argue, the MDA frontier betweenCIM and PIM layers cuts across the OO-Method requirements model diagonally.Figure 2 zooms in on the first two MDAlayers shown in Figure 1.

The MDA paradigm would beextremely easy and powerful if it werepossible to follow a cascade software-development lifecycle. For this towork, one person would start buildingthe models of the highest abstractionlevel. The subsequent models wouldthen be manually or automaticallyderived, each time adding the detailsrelated to the new abstraction level.However, since reality is often verycomplex, the iterative and incrementaldevelopment paradigm is more

practical and popular. MDA adaptswell to this way of working. One canstart by modelling one part of thesystem and feeling one’s way down theabstraction ladder. When this part ofthe system is more or less consolidatedand perhaps even implemented anddeployed, a new iteration starts.Another part of the system is modelledtop-down. In an MDA-based iterativesoftware development, either it ispossible to partition the system withsurgical precision, seeking a highcohesion and minimal couplingbetween the parts, or automatictransformations arise as a strong need.

Furthermore, in the area of ISs weoften have to deal with so-calledwicked problems. Wicked problemsare often not fully understood until asolution has been found, since everywicked problem is essentially unique.Solutions to these problems are notright or wrong, simply “better”,“worse”, “good enough”, or “not goodenough” [31]. Indeed, it is the socialcomplexity of these problems, not theirtechnical complexity, whichoverwhelms most current problem-solving approaches. To appropriatelydeal with wicked problems, it iscommon to carry out opportunity-driven problem solving. At any giventime the developers are seeking the bestopportunity to progress toward a

solution, regardless of whether they aregoing up or down in the abstractionladder. Rittel [31] identified a type ofproblematic situation that can only besolved if representatives of all thestakeholders participate in a jointeffort. Models are specifications of theshared knowledge about the problemand they serve as an agreement.Therefore, it is important that somespecific models are understandable forthe users.

The consequence of this tangle ofcognitive, social and abstraction-levelissues is that no single ingenuoussolution is adequate. Methodologistsneed to offer software-developmentstrategies that facilitate opportunity-driven problem solving. An evidentcorollary is that it is important to dealwith contingency in softwaredevelopment. Methods must beflexible in the sense that the techniquesto be applied in each moment aredetermined by various factors: thecharacteristics of the system to becomputerised (i.e. automatic tellermachines are not dealt with the sameway as ISs), the nature of a specificproblem presented at a given moment(e.g. to design a user interface, tospecify business objects, to designstrategic-level reports), the expertise ofthe development team (whichtechniques they know best), the

Figure 2: The MDA Layers and the OO-Method: Pragmatics going beyond Frontiers.


UPENET

maturity of the organisational system,the users’ organisational andtechnological knowledge, thepredisposition of the stakeholders to beinvolved in development, and so on.

With regards to the MDA paradigm,the number and variety of these issuesgive it a complexity akin to a jigsawpuzzle. Methodological confusionamong practitioners appears, worsenedby the fuzziness with which mostmethods and techniques are defined.Because of the lack of sound criteria,gurus proliferate, and practitioners tryto make up for a lack of adequatemethodological guides by generalisingfrom examples and case studies. Thesolution to all of this, i.e. piecingtogether a well-founded methodrequires a number of issues to consider:

1. A theoretical soundness shouldbe assured. This requires the basing ofargumentations on unambiguous andwell-defined concepts.

2. The usage of techniques shouldbe specified. Modelling techniques areoften offered by their authors as apanacea for all problems. Also, manymodelling primitives can be used todescribe things at different abstractionlevels; techniques should be located inthe methodological jigsaw puzzle,reducing the degrees of freedom withwhich they are marketed.

3. Method design that aims tofacilitate opportunity-driven problemsolving.

4. Provision is made forcontingencies. This may be achievedby offering several alternative routesaimed at completing themethodological jigsaw puzzle. Theroutes should be appropriate forovercoming problems during complexprojects.

5. To empirically assess all thealternative methodological routes. It isconvenient to carry out a series ofempirical tests to evaluate theirviability, pros and cons.

We will now clarify the issuescommented above with an exampleusing some of the methodologicalpieces of the OO-Method (see Figure3). Firstly (issue 1), one way of gainingdeeper knowledge about a method isto conceptually align it with an

ontology, a set of well-defined relatedconcepts. This ontology must beappropriate for the type of problem thatwill be solved using the method. Forexample, in [26] the OO-Methodconceptual model is aligned withregard to a conceptual frameworkconcerning information systems.

Each method must locate and placethe pieces of its puzzle depending onthe semantics associated with themodelling techniques being proposed(issue 2). For example, there is noconsensus with regard to the criteriaunderlying use cases. As things stand,the rational unified process (RUP)proposes to distinguish betweenbusiness use cases and (computerisedsystem) use cases. In the case of theOO-Method functional requirementsmodel, use cases are located at the CIMlevel (as the RUP business use cases),as Figure 2 shows. This implies thatno computerisation aspects should beconsidered at this level. Use casetemplates are also designed to becomputation-independent. However,sequence diagrams decompose the ISin terms of objects that react to externaland internal messages and many ofthem presuppose a computerisation ofthe system; for this reason, sequencediagrams in the OO-Method are notlocated at the CIM level, but rather atthe PIM level. Particularly interestingis the case of the interactionrequirements model. While task treescan be argued to focus on theinteraction between the user and thesystem, it is still arguable whether thesystem refers to an information systemor a computerised information system.In our proposal, the CTT notation isused as a computation-independentdescription of the interaction. Bydetermining the semantics of eachmodelling primitive in acomputationally independent way, wecan fix the task model at the CIM.However, the sketch of the interface isevidently oriented towards acomputerisation. Our sketchingprimitives are still independent of theparticular programming and runtimeenvironment, so the user interfacesketches are claimed as part of the PIM.Figure 2 shows how the functional and

the interaction requirements model arecrossed diagonally by an MDA frontier.

In the OO-Method we confront thechallenge in order to facilitateopportunity-driven problem solving(issue 3). We offer the chance to go upand down in the abstraction layersdepending on the specific problemsthat the developers come across duringa software project. Automatictransformations and the compilation ofthe conceptual model allow for anincremental development. Also, thesetransformations permit the testing andvalidation of partial solutions at a lowcost. For a real opportunity-drivenapproach to be possible, the problemof inter-model incoherence must bedealt with. Sometimes a model B hasbeen derived from a model A that is ofa higher abstraction layer. Later, B ismodified and details are added to it.Then it may occur that models A andB are no longer consistent. Thisproblem is solved by round-tripengineering, that is, by offering supportfor the bottom-up propagation ofchanges in the models. In the case ofthe OO-Method conceptual model andthe code model, the stress is put in theextreme non-programming paradigm[24], that is, no changes should bemade to the code. However, currenttools are not so refined, and when thisis really needed, a Tweakingapplication solves the round-tripproblem. Between the conceptualmodel and the requirements models,the round-trip problem is an issue stillrequiring a great deal of research,although some promising strategies arebeing tested.

When solving complex problems,contingencies must be dealt withappropriately. The development teammay need to take different routesthrough the method (issue 4). All thesemethodological routes must betheoretically and practically achievable.Within the MDA paradigm, the routesusually involve manual derivations and(semi)automatic transformations amongthe models. In the OO-Method, we offerseveral routes (see Figure 2). In the caseof the OO-Method functionalrequirements model, the analyst canchose between describing use cases via


UPENET

specification templates or via sequencediagrams. The interaction requirementsmodel is optional; it will not benecessary whenever the system beingdeveloped does not have demandinguser interface requirements. However,it is recommended to specify theinteraction requirements of those usecases that are not CRUD-like.1Furthermore, on some occasions, it iseven convenient to start with theinteraction requirements model forthose parts of the system where the usersalready predispose some user interfacesketches. This model then serves toestablish a degree of shared knowledgebetween the users and the developers.

See Figure 3 for a graph where thevertices represent the proposed models(methodological pieces) and the arcsrepresent transformations and mappingsamong the models. The core of the OO-Method is the conceptual model. Aboveit, at the functional requirements level,there are several proposals. In this paperwe only present those proposals relatedto use cases. A different approach isdescribed in [10], where the authorspresent an adaptation of BPMN to fit theOO-Method. The analyst will choose themost appropriate technique depending onthe problem being solved (i.e. the systembeing developed). The OO-Method is alsobeing extended at the lower abstractionlevels. In order to give more

expressiveness to the interface modelling,a concrete interface model [29] is beingresearched to deal with issues like widgets,alignment, look and feel, etc.

We can argue that our approach istheoretically valid. The differentmethodological routes are well-founded and the correspondingderivations and transformations areoffered. However, not all of the routesnecessarily give good results in allcases. We acknowledge that it is evenpossible that some routes are notconvenient at all. This is closely relatedto empirical validation ofmethodological routes (issue 5).Evaluating situational methods (whatwe have called routes across the jigsawpuzzle) is one of the topics of interestof method engineering [13, 32].

For the sake of brevity, thefollowing section focuses only on oneof the OO-Method methodologicalpieces. Interaction modelling is chosenbecause it is still a pending issue insoftware engineering. To understand itscontext for use, in Section 5 we offeran overview of a methodological routewithin the technique makes sense. Theroute starts with the functionalrequirements model (see Figure 3). Theuse case templates branch is taken.Then the interaction requirementsmodel is created; the interface sketchesare manually mapped to the use case

template. The derivation of the objectmodel from use case templates isdescribed in [11]. The strategy forderiving the presentation model fromthe interaction requirements model isdescribed in [12]. Then a manualmapping could be carried out relatingthe presentation model and the objectmodel. However, we are consideringapplying model managementtechniques and tools [4] toautomatically obtain this mapping.Once the rest of the views of theconceptual model are created, the finalapplication is automatically generatedby a model compiler [8].

A Method for CapturingInteraction Requirements:Sketches

From all the pieces which composethe OO-Method jigsaw puzzle, thispaper focuses on those pieces thatspecify the system interactionabstractly. This section proposes amethod for capturing interactionrequirements in an MDA environment.We have selected, as a starting point,the pieces of the OO-Method jigsawpuzzle devoted to interaction modellingdue to the importance of modellinginteraction to build usable systems.Following ISO 9126-1[16], usability isa software characteristic that stronglyinfluences software quality. Usabilityis related to modelling andimplementing interaction according touser requests. Therefore, a requirementsmodel to formally capture userinteraction requests is appropriate.

The technique that the OO-Methodproposes for capturing interactionrequirements is based on Paternò’sConcurTaskTrees (CTT) [28]. The originalgrammar is extended to suit the OO-Method. This has the following layers:

Lexical. This is provided by CTTnotation (interaction tasks, systemtasks, and abstract tasks).

Syntactic. This is made up ofstructural task patterns that arestructures of tasks related to each otherby means of temporal operators.

1 Create, read, update and delete are typicalactions in information systems.

Figure 3: The MDA Jigsaw Puzzle in the OO-Method: Aiming to Support Contingency.


UPENET

Semantic. This is provided by thecorrespondence between task patternsand model presentation patterns of theOO-Method.

Structural task patterns have beendefined generically. Therefore, theyoffer arguments that are instantiatedwhen patterns are used to model aspecific interface. In the followingfigures, these arguments are shown incursive format, indicating that theirnames and values should be instantiated.Arguments with variable cardinality arerepresented with ellipses (i.e. 1...N).

However, manual construction ofthese structural task patterns is verydifficult, even though there is a tool tosupport the drawing thereof. Moreover,for small applications, the structural taskpatterns become illegible due to the hugenumber of CTTs that are created. Thispaper proposes a different abstractionlevel to represent the interface by meansof sketches. The analyst, with the helpof the user, draws sketches that representthe final interfaces. As the sketches aredrawn, the structural task patterns arebuilt automatically.

Sketches are an early model torepresent the user interface. In order todefine a new model, the first step is toestablish a set of basic builders. In otherwords, the primitives for building up asketch to represent the interface shouldbe defined. The CTTs are built at thesame time that the sketches are drawn.The second step is then to define abiunivocal relationship between sketchprimitives and structural task patterns.For each structural task pattern, a sketchprimitive is defined.

Therefore there are two models torepresent system interaction, in otherwords, two pieces of the jigsaw puzzleto represent the interaction. On the onehand, CTTs have the advantage ofbeing a formal language. A formallanguage provides a formal semantic,makes the model verifiable, and avoidsambiguity in specification. On theother hand, sketches are very simple.Therefore they are easy to create andcan be understood by the final user.

For the sake of brevity, this work isbased on the structural task patterns relatedto a list of instances (Population IU andthe Elemental Patterns [23] related to it):

Filter

Filter primitives for sketches specifya filter criterion for the listed instancesin the population. The analyst must placea symbol above the columns that the userwants to use in the filter (the letter F inFigure 4). These marked columnsinstantiate the arguments of thecorresponding structural task pattern.

Order criteria

The order criteria is defined in amanner similar to the filter primitive.Some symbols are placed above thecolumns (the letter O in Figure 5) toorder the listed instances. Thesesymbols provide values for thearguments of the pattern.

Actions

The actions, shown in Figure 6,represent operations that can be madewith the selected instance in thepopulation list. Some actions are verycommon (i.e. create a new instance,modify it, or delete it); others arespecific to the system that is beingsketched. Actions instantiate the

arguments of the structural task pattern.The analyst draws the navigation

to system interfaces that implementqueries or editions of objects relatedto the object source (Figure 7). Forexample, starting from an invoice linelist, the user can navigate to the client

Figure 4: Graphical Primitive and Structural Task Pattern for Filter.

Figure 5: Graphical Primitive and Structural Task Pattern for the Order Criteria.

Figure 6: Graphical Primitive and Structural Task Pattern for Actions.


UPENET

data. The set of possible destinationsbuilds the arguments of this pattern.Once the arguments are built, thesystem task is in charge of carrying outthe navigation.

Navigations

Display set

The display set primitive (Figure 8)specifies the columns of the populationinstances that will be showngraphically. This primitive is a set ofcolumns that the analyst can assign aname to. The names of the columnsinserted in the sketch provide the valuesof the structural task pattern arguments.

PopulationOnce the correspondences between

the structural task patterns and the thirdlevel of the presentation model patterns[23] are defined, the next step is to dothe same with the second level of thepresentation model patterns.

The population primitive presentsto the user a list of instances from a

business object class (i.e. a list ofcustomers). As Figure 9 shows, it mayinclude all the primitives that representelements of the third level in the OO-Method presentation model throughstructural task patterns. Figure 10presents the corresponding structuraltask pattern. The numbers in circlesshow the common parts.

As Figure 10 shows, the CTT thatrepresents the population pattern

includes interaction tasks that are incharge of filtering (filter) and arranging(order) the instances. The bracketsrepresent grammatical-compositionrules. In other words, they are pointsat which to hook the leaves to otherstructural task patterns. A system taskis then used to show the instances ofthe objects (display), which are filteredand ordered by the selected criteria onthe screen. Finally, the user can carryout action and navigation operationswith these instances, which arerepresented in the diagram by meansof abstract tasks. All of these structuraltask patterns can be composed to modelthe interaction with a list of instances.

Case StudyThis section shows the development

process of a real system with the OO-Method methodology. This system iscalled AguasDeBullent, a water supplymanagement system. In this case study,one of the possible routes across the MDAjigsaw puzzle is followed, using many ofthe models proposed by the OO-Method.The case study starts with the stage ofrequirements capture. First, the analystcreates the use case model. To keep theexample simple, this paper focuses on oneuse case, list meters. This use caserepresents the functionality of showing alist with all the information about thewater meters stored in the system.

Figure 11 shows the use case modelwith a template that specifies the stepsrequired to accomplish the goal of thisuse case. Again, for the sake of simplicity,the template does not fully comply withthe notation described in [11] but it doesspecify the use case in detail.

Once the functional requirementshave been captured, the last step inrequirements capture is to modelinteraction requirements usingsketches (see Figure 12).

The CTT that represents the sketchis automatically built (see Figure 13).

Some of the views that compose theconceptual model (object, functionaland dynamic models) can be derivedfrom functional requirements applyingthe transformation rules detailed in[11]. The presentation model can bederived from the CTTs by applyingtransformation rules explained in [12].

Figure 7: Graphical Primitive and Structural Task Pattern for Navigation.

Figure 8: Graphical Primitive and Structural Task Pattern for Display Set.

Figure 9: Graphical Primitive for Population.


UPENET

This case study focuses on theobject model (Figure 14a) andpresentation model (Figure 14b).

Finally, the model compilerautomatically generates the sourcecode of the fully functional application.The generated window for the use caselist meters is shown in Figure 15.

Conclusions and Future WorkThe MDA paradigm is modelled in

four layers: CIM, PIM, PSM and codemodel. This paradigm is used in severalsoftware production methods thatdistinguish between the variousabstraction levels with varying degreesof automation. In many cases, each

MDA model is supported by a set ofdifferent models. Moreover, the specificmodels of each method can be built in avariable order, depending on a numberof factors. These factors include:analyst’s preferences, user’s knowledgeof computer systems, system size, andclarity of requirements. This fact,together with the large number ofmodels proposed by the methods, resultsin a huge number of possiblecombinations for abstract modelling ofthe system. Independently of the chosenorder, all the models must be coherentwith the user’s requirement and mustrepresent a full system. This problemcould be described as a jigsaw puzzleconstruction, with each model of themethod representing a piece of thejigsaw that must be joined to other piecesfor the whole to succeed.

This issue is discussed in this paperusing the example of the OO-Method

approach, a software production methodbased on the MDA paradigm. From amongall the pieces of the OO-Method jigsawpuzzle, this paper focuses on those piecesdesigned to capture interactionrequirements. The main reason forselecting these pieces is the fact thatinteraction modelling is often disregardedby the software engineering community.However, the human-computer interactioncommunity has offered many successfultechniques for capturing interactionrequirements, a prime example aresketches. Sketches have been chosen tocapture the interaction requirements in the

Figure 10: Population with CTT Notation.

Figure 11: Use Case Model.

Figure 12: Sketch.


UPENET

OO-Method due to their simplicity.However, sketches cannot be used inan automatic transformation processunless we formalise their underlyinglanguage. We have chosen theConcurTaskTree (CTT) notation toformally represent the sketches. CTTsallow the sketches to representinteraction unambiguously; they can bevalidated and then transformed into the

OO-Method presentation model. Theimplementation of the tool to drawsketches and to synchronously generateCTTs is planned as future work. Thisfunctionality, together with thetransformation of the task model intothe presentation model, will offerefficient technological support forautomatically generating applicationinterfaces and will allow early

feedback from the user. This providesan interesting and specific example ofhow to put together the various piecesneeded to create a complete, MDA-compliant software production process,the so-called MDA jigsaw puzzle.

We also plan to assess theefficiency of the proposed interactionrequirements technique, as well as thevarious alternatives for building the

Figure 14: a) Object Model. b) Presentation Model.

Figure 13: CTT Model.


UPENET

(1999) Metamodelling basedassembly techniques for situationalmethod engineering. Inf Syst24(3):209–228. doi: 10.1016/S0306-4379(99)00016-2.

[7] Caetano A, Goulart N, Fonseca M,Jorge J (2002) JavaSketchIt: Issues inSketching the Look of User Interfaces.AAAI Spring Symposium. Sketchunderstanding. AAAI Press, MenloPark, CA, pp 9–14.

[8] Care Technologies (2007) http://www.care-t.com. Accessed July 2007.

[9] Coyette A, Vanderdonckt J (2005) ASketching Tool for Designing Anyuser,Anyplatform, Anywhere UserInterfaces. INTERACT 2005, LNCS3585. Springer, Berlin HeidelbergNew York, pp 550–564.

[10] DeLaVara JL, Sánchez J (2007)Business process-driven requirementsengineering: a goal-based approach.In: 8th Workshop on Business ProcessModeling, Development, and Support(BPMDS’07), CAiSE’07, Trondheim,Norway (in press).

[11] Díaz I, Losavio F, Matteo A, Pastor O(2003) A Specification Pattern for UseCases. Inf Manage J (Elsevier ScienceB.V.) 41:961–975,

[12] España S, Pederiva I, Panach JI (2007)Integrating Model-Based and Task-Based Approaches to User InterfaceGeneration. In: Calvary, C. Pribeanu,G. Santucci, J. Vanderdonckt (eds)Computer-Aided Design of UserInterfaces VI. Kluwer, Dordrecht, pp255–263,

[13] Fitzgerald G (1991) Validating newinformation systems techniques: aretrospective analysis. In: Nissen HE,Klein HK, Hirschheim R (eds)Information Systems Research:Contemporary Approaches andEmergent Traditions. Elsevier Science,Oxford, pp 657–672.

[14] Fons J, Valderas P, Albert M, Pastor O(2003) Development of WebApplications from Web EnhancedConceptual Schemas. ER 2003,LNCS. Springer, Berlin HeidelbergNew York, pp 232–245.

[15] Gupta D, Prakash N (2001)Engineering methods from methodrequirements specifications.Requirements Engineering 6(3):135–160. doi: 10.1007/s007660170001.

[16] ISO/IEC 9126-1 (2001) Softwareengineering. Product quality 1: Qualitymodel.

[17] Karlsson F, Ågerfalk PJ (2004)Method configuration: Adapting tosituational characteristics whilecreating reusable assets. Inf SoftwTechnol 46(9):619–633. doi:10.1016/j.infsof.2003.12.004.

[18] Karlsson F, Wistrand K (2006)Combining method engineering withactivity theory: Theoretical groundingof the method component concept. EurJ Inf Syst 15(1):82–90. doi: 10.1057/palgrave.ejis.3000596.

[19] Landay J, Myers BA (2001) SketchingInterfaces: Toward More HumanInterface Design. IEEE Comput34:56–64

[20] Lyytinen K, Welke R (1999) Guesteditorial: Special issue on meta-modelling and methodologyengineering. Inf Syst 24(2):67–69. doi:10.1016/S0306- 4379(99)00005–8.

[21] MDA (2007) http://www.omg.org/mda. Accessed July/June 20072008.

[22] Mirbel I, Ralyté J (2006) Situationalmethod engineering: Combiningassembly-based and roadmap-drivenapproaches. Requirements Eng11(1):58–78. doi: 10.1007/s00766-005-0019-0.

[23] Molina P (2003) User interfacespecification: from requirements toautomatic generation. PhD Thesis,DSIC, Universidad Politécnica deValencia (in Spanish).

[24] Morgan T (2002) Business Rules and

References[1] Ågerfalk PJ, Fitzgerald B (2006)

Exploring the concept of methodrationale: A conceptual tool for methodtailoring. In: Siau K (ed) AdvancedTopics in Database Research, vol 5.Idea Group, Hershey, PA.

[2] Ågerfalk PJ, Ralyté J (2006)Situational requirements engineeringprocesses: reflecting on methodengineering and requirements practice.Software process: improvement andpractice. Wiley, New York.

[3] Bailey BP, Konstan JA (2003) AreInformal Tools Better? ComparingDEMAIS, Pencil and Paper, andAuthorware for Early MultimediaDesign. Human Factors in ComputingSystems CHI’2003. ACM, New York.

[4] Bernstein PA (2003) Applying ModelManagement to Classical Meta DataProblems. In: Proceedings ofConference on Innovative DataSystems Research (CIDR) 2003.

[5] Brinkkemper S (1996) Methodengineering: engineering ofinformation systems developmentmethods and tools. Inf Softw Technol38:275–280.

[6] Brinkkemper S, Saeki M, Harmsen F

rest of the models. This will be doneby means of empirical evaluation.Moreover, a case-base with the variousmethodological routes should bedefined together with the factors thatlead the analyst to choose one specificroute.

Figure 15: Final System.


UPENET

Information Systems: Aligning IT withBusiness Goals. Addison-Wesley,Boston

[25] Newman MW, Lin J, Hong JI, LandayJA (2003) DENIM: An Informal WebSite Design Tool Inspired byObservations of Practice. HumanComput Inter 18:259–324.

[26] Pastor O, González A, España S (2007)Conceptual alignment of softwareproduction methods. In: Krogstie J,Opdahl A, Brinkkemper S (eds)Conceptual modelling in informationsystems engineering. Springer, BerlinHeidelberg New York, pp 209–228.

[27] Pastor Ó, Insfrán E, et al. (1997) OO-Method: An OO Software ProductionEnvironment CombiningConventional and Formal Methods.Lecture Notes in Computer Science.9th Conference on AdvancedInformation Systems Engineering(CAiSE’97), Barcelona, Spain.Springer, Berlin Heidelberg New York.

[28] Paternò F, Mancini C, et al. (1997)ConcurTaskTrees: A DiagrammaticNotation for Specifying Task Models.In: Proceedings of the IFIP TC13International Conference on Human-Computer Interaction. Chapman andHall, London, pp 362–369.

[29] Pederiva I, Vanderdonckt J, España S,Panach JI, Pastor O (2007) TheBeautification of AutomaticallyGenerated User Interfaces. In:Proceedings of XI IFIP TC13International Conference on Human-Computer Interaction (INTERACT2007), LNCS 4662. Springer, BerlinHeidelberg New York, pp 209–422.

[30] Plimmer BE, Apperley M (2003)Software for Students to SketchInterface Designs. In: Proceedings ofConference on Human-ComputerInteraction (INTERACT 2003). IOS,Amsterdam, pp 73–80.

[31] Rittel H, Webber M (1973) Dilemmasin a general theory of planning. PolicySci 4:155–169.

[32] Schipper M, Joosten S (1996) Avalidation procedure for informationsystems modelling techniques. In:Workshop on Evaluation of ModelingMethods in Systems Analysis andDesign, 8th Conference on AdvancedInformation Systems Engineering(CAISE’96). Springer, Berlin

Heidelberg New York.[33] Vanderdonckt J, Limbourg Q, et al.

(2004) USIXML: a User InterfaceDescription Language for SpecifyingMultimodal User Interfaces. In:Proceedings of W3C Workshop onMultimodal Interaction (WMI’2004),Sophia Antipolis, Greece.

upgrade, vol. ix, issue no. 6, december 2008 - cepis.org · 2 presentation. network management and...

Documents