ADRIA: A Method for Abstract Design of Rich Internet Applications ...

ADRIA: A Method for Abstract Design ofRich Internet Applications for the Web 2.0Peter Dolog and Jan StageAalborg University, Department of Computer ScienceSelma Lagerlöfsvej 300, DK-9220 Aalborg East, Denmark{dolog,jans}@cs.aau.dkAbstract. Rich Internet Applications can contribute to realize the visions of the so-called Web2.0. Rich Internet Applications provide users with facilities in web applications that are similar todesktop applications. In this paper, we present the ADRIA method for designing rich internetapplications. The design activities of ADRIA depart from the results of an object-orientedanalysis. The method employs interaction spaces as the basic abstraction mechanism coherentlythroughout all the design activities. The notation is based on UML. The activities of the methodsare described, and its use is illustrated with a case study of the design of an interactive webapplication for furniture configuration. This application features recommendation of furnitureitems according to the interaction of a user and advanced customization features for furnitureplacement to show the main advantages. We also present the results from an evaluation of themethod in a university education setting.Keywords: Web 2.0, Rich Internet Applications, software design, interaction spaces1 IntroductionWeb 2.0 is a vision about the second generation of web information services. The aim is toenhance creativity, information sharing, and collaboration among users, while providing richpossibilities for interaction. User interaction with Web 2.0 applications will require improvedresponsiveness and increased interactivity compared to first generation web services.Rich internet applications can contribute to realize the ideas behind Web 2.0. Rich internetapplications were introduced as a response to the limitations in richness that users of firstgeneration web services have experienced in comparison to desktop applications [9], [10]. Theterm Rich Internet Applications was first launched by Macromedia to denote this class ofapplications. Rich internet applications have been enabled by recent advances in internet browserplugin technologies such as Flash from Adobe, ActiveX technologies, and AJAX [19]. Thesetechnologies provide users of web applications with possibilities similar to desktop applications.Recently, this technology has also been adopted by others, for example Google and Flickr.Rich internet applications introduce additional complexity connected with asynchronouscommunication and synchronization problems as some data are being held and processed at theclient side. This complexity influences the software engineering methods that are needed to buildsuch applications. The richness and wide range of possibilities introduce a need for strongabstraction mechanisms. This is similar to user interface design for desktop applications. This isalso apparent from recent developments in the area of web information systems engineering wherewe have witnessed several emerging methods, such as an extension of WebML [2] to reflect thecomplexity of the rich internet applications.In this paper we present ADRIA, a method for abstract design of rich internet applications. Themethod combines interaction spaces and task models [14], [14] with UML for designing adaptiveweb applications [7], [8]. This combination has three advantages. First, interaction space is anatural metaphor for designing user interface fragments that a web user will interact with. Theyreflect the richer interaction possibilities that characterize rich internet applications. Second, usecases are the basis for designing the interaction with a rich internet application. They connectinteraction design directly to the users’ work. Third, UML statechart diagrams are used to refinethe use cases. These task models provide a natural means to define user interaction events whichare connected to synchronization events between client and server and synchronization eventsbetween fragments of the user interface. The aim with ADRIA is to contribute with a newdevelopment processes for the web 2.0 with particular focus on modeling, overall design and userinterface issues.The purpose of this paper is to present the ADRIA method and illustrate how it can be used todevelop a rich internet application. The following section 2 presents the ADRIA method fordesigning rich internet applications and discusses how the resulting design can be transformed into1

2.2 Identify Interaction StructuresThe first activity in ADRIA is Identify Interaction Structures. This activity departs from theresult of an object-oriented analysis, and it produces a structural interaction space model. Itcomprises four steps as illustrated in Figure 2.50"*,1' (6-47(8"*'.4 (OOADocument)*'&/%9:(;$

temporarily maintained at the client side to enable the user to easily interact with it. It can bereinitialized as soon as a user changes a focus to another item in the room configuration. Again,the CFurnitureList object, if implemented in AJAX, will implement an AJAX function that isresponsible for synchronization with server side persistent data storage through the server sideSFurnitureListBrowser class. The SFurnitureListBrowser has to implement a getRecommendationmethod to retrieve recommended store items based on parameters passed through thecommunication between client and server. This step also involves identification of the methodsthat are need for client and server side objects.CFurnitureListBrowser1SFurnitureListBrowserFigure 9 Refinement of the FurnitureList interaction space into client and server side objectsThe second step is to define the exchange of messages. Client side and server side objects needto communicate in well structured messages. The request to the server basically means a request toupdate a state of the client side object. Therefore, the message should contain an identification of aclient side object, identification of called server side object method and parameters for themethods. Similarly, call back asynchronous message with the results should be structuredsimilarly. Figure 10 depicts an excerpt of a UML Guide that describes the system’s responses touser interactions. The model is a refinement of the task model presented in Figure 6. There are twodialog steps depicted at the figure: Room and Room&Store. They are counterparts for theinteraction spaces and activities in the task model.The third step is to define concurrency and synchronization. The Room&Store stateincorporates 3 concurrent regions representing three concurrently presented dialog steps:RoomItems, StoreItems and RecommendedStoreItems. We distinguish client side from server sidemethod calls by placing C and S letters respectively at the beginning of the object names. You canobserve that we instantiate classes we have defined above as refinements of interaction spaces.Such a notation advices which objects will be implemented at the server side and which at theclient side. The star symbol as a synch pseudostate between concurrent regions represent anunlimited upper bound for a difference between how many times the incoming and outgoingtransitions have been triggered which is consistent with UML 1.3 notation for state machines.Room/CRoomBrowser .ShowRooms (USER )SelectedRoom (RoomId ,null,null )StoreItems/sit := cnfg,CFurnitureBrowser () ;/sit .ShowTypes (chosen )Room &Store/cnfg:= new CRoomConfiguration (RoomId )SelectItem (chosen )/selected := cnfg.addItem (chosen )RoomItems/room := cnfg .CFloorPlanViewer (RoomId );SelectItem (selected ,storeid )/room .ShowItems (selected )/selected :=cnfg .addItem (chosed)/returned := SFurnitureBrowser .GetRecommendation (selected ,storeid )***RecommendedStoreItems/fl:= cnfg.CFurnitureBrowser ();/fl.ShowItems (returned )SelectItem (chosed )Figure 10 An excerpt of the UML Guide model with client and server side object invocationsWhenever a user selects an item from store items (SelectItem event on the transition fromStoreItems), the item is placed into the room by synchronization invoked cfng.addItem function.The model at the client side is reinitialized and client side functions such as room.ShowItems()rerenders the displays considering the added item as part of the scene. More interesting situationhappens whenever user selects an item in a room. An event, which triggers synchronization with aserver of furniture shop specified by shopid, occurs. The recommended items based on similarityfunctions for example or based on user preference are retrieved. Additional parameters can bespecified such as booking history and so on. Synchronization with server side class is indicated bya message SFurnitureBrowser.getRecommendation(selected, storeid).3.4 Create User InterfaceThe third activity with ADRIA is to design the appearance of the user interface. This involvesdescription of a presentation model and sketching of each user interface element. In section 49

elow, we describe experiences from the experiment, where we tried ADRIA out on the FurnitureConfigurator example. This section also provides the final user interface related to Use case 3.3.5 ImplementationFigure 11 shows an example of an AJAX java script function to get recommendations from aweb service. First, SOAP headers need to be set properly for XML message. Second, after gettingresults back from the web service, the returned XML message with the recommended items has toparsed and formatted for the client. Third, for privacy reasons, a proxy needs to be implementedwithin the application domain to call an external web store interface. The proxy is exposed throughan application web service interface specified in the UML Guide. The proxy transfers the call fromthe client to the web service call to the web store (not shown in the code fragment). It is alsopossible to provide an implementation without a proxy. A web service call outside the domain ofthe application is however possible with AJAX just when digitally signed messages are sent.function GetRecommendation(selected){xmlhttp.open("POST", "",true);xmlhttp.onreadystatechange=function() {if (xmlhttp.readyState==4) {alert(parsexml(xmlhttp.responseText))}}xmlhttp.setRequestHeader("Man", "POST http://www.rcapp.org/SFurnitureBrowserHTTP/1.1")xmlhttp.setRequestHeader("MessageType", "CALL")xmlhttp.setRequestHeader("Content-Type", "text/xml")sendstring = ""sendstring = sendstring + "\n\n"+"

We have needed just altogether five work sessions with duration of 2 hours on average. Theprocess followed was quite sequential, comparable with the figure presented in the methodologysection. First, scenario, use cases and problem domain entities have been discussed. The taskmodel has been derived from the use cases. We performed 3 iterations with respect to the problemdomain classes; we needed 2 iterations to come up with the task model which is presented in theprevious section. We also needed 2 iterations to end up with implementation classes and the UMLguidestatechart diagram. The changes which resulted in several iterations have been triggeredboth due to the users (usability), and also technology and developers feedback.RecommendedStoreItemsStoreItemsRoomItems /RoomConfigurationFigure 12 An example application based on the designs presented aboveBased on these results, the design method is promising with respect to the kind of applicationswe have been targeting. The main advantage of the proposed method was the effectiveness ofcommunication of the designs both to the customer and to the developer. The means to structurethe scenario from tasks and user interaction point of view have been understood quite well by therepresentatives of the users. On the other hand, the UML-guide state diagram together with therefinements of the problem domain classes to the implementation classes at the client and serverside served their purpose to communicate the synchronization aspects useful in the context ofAJAX technology and distribution of the code and data stores among client and servers. As theapplication scenario also points out, the design technique can also be used in integration scenarioswhere data stores on the server sides already exist and the goal is to design just a brokerageplatform which will provide improved user experience on top of integrated applications withenhanced web based user interface.Other projects. The ADRIA method was used last year in 4 student team projects. The ADRIAwas applied by a team of 6 people in developing a geographical quiz application for Facebook, bya team of 3 people in developing a brokerage portal for music mixes, by a team of 3 people indeveloping interactive plug-in and editing solution for content management systems, and by teamof 5 people in developing an online shop.Figure 13 depicts the GeoQuiz: the geographical quiz application for Facebook as an exampleof a running application available also from Facebook. The application is an interactive quiz whichinegrates geographically oriented questions on top of google maps and integrates it into thefacebook. The example depicted in Figure 13 is from geographical monuments of Europe. As youcan see, there is a score bar integrated as a separate object, google map as a autonomous object andquiz related hints as separate objects. User is supposed to find a monument by clicking a rightplace and placing a pinpoint as you can see on the Figure 13. Based on preciseness of the answerand time in which the answer was given, the application calculates the number of points. Theapplication allows for zooming in and calculating right distances based on google maps interface.Based on the above you can see, that this application has all properties of a Web2.0 Rich Internetapplication such as advanced visualization, high interactivity, and autonomous user interfaceobjects which need to interact with each other.11

Figure 13 GeoQuiz as a facebook applications [21]4.2 Experimental ResultsWe have conducted an experimental study in those projects mentioned above. Please not thatstudy system at Aalborg University is organized around group projects in each semester. Studentsare grouped to solve particular larger problem in a project. This study was conducted on the 1semester of the software engineering master program (7 th semester of total). The semester topic isweb engineering. As mentioned above, 4 different student groups applied the ADRIA method forabstract user interface design of their web applications. This setting is actually very close to thereal industrial settings of a first project with novice web engineers. Therefore, this study canconfirm the ADRIA method is easy to learn and apply by people with basic knowledge aboutobject oriented analysis and design. At the beginning of their project, the students receive atechnical report describing ADRIA method. They did not know about it before. That was the onlystudy material they had during the performance of their project. We wanted to find out thefollowing about ADRIA method: How was it to work with ADRIA and its various activities How much the ADRIA method concepts have been used How useful was it to work with various concepts of ADRIA methodOur hypotheses before the study were:H1: Overall ADRIA method can be usually easy to apply but sometimes difficult especially incomplex interactions.H2: Structural interaction space models of ADRIA are mostly easy to apply.H3: The behavioral interaction space models of ADRIA are sometimes difficult applyH4: Structural interaction space models of ADRIA are applied in more than half use cases (usuallythe more complex one requiring more reasoning)H5: Behavioral interaction space models of ADRIA are applied sometimes (usually when morecomplex interaction is needed among autonomous user interface objects with distributedcomputation)H6: Structural interaction space models of ADRIA are mostly useful in design phaseH7: Behavioral interaction space models of ADRIA are mostly useful for designing anddescribing implementation of synchronization among autonomous user interface objects.Couple of weeks before the end of the projects we handed questionnaires to the projectsparticipants. Each participant filled in the questionnaire independently. We have asked themindependently because the roles of students in the teams varied, different team membersparticipate in designing the applications with different intensity, and therefore they could formtheir own opinions on the ADRIA method. The questionnaire contains questions quantifying theabove mentioned questions on how was it to work with, intensity, and usefulness of the ADRIA12

concepts as well as open questions asking for reasons why the project participants answered in thatway. In the time of writing, 9 students have completed the questionnaire.Overall, six out of nine students reported regarding to how was it to work with the ADRIAmethod as sometimes difficult. The other three answered that it was mostly easy. This confirmsour hypothesis H1.There are two reasons for these answers. The first is the timeframe of the project and theirbackground. As the projects were relatively short (one semester) and they did not work that muchwith the ADRIA concepts. However, we need to also know what made them to answer that it issometimes difficult. The questionnaire actually contained also the detailed answers about differentconcepts of ADRIA as described above. For structural interaction space models we actually foundout that they are mostly easy to apply (2 answered easy, 5 answered mostly easy, 1 did not answerthe related questions as he did not participate and only one answered that it was sometimesdifficult). This actually confirms our hypothesis H2. The reason why there is sometimes difficultyfor some people was reported at the step where use cases are updated to reflect the tasks. Thisactivity in the ADRIA method should result in hierarchical states which are assigned tosubsequence of activities in task model. As this abstraction is slightly more complex, the novicedesigners had sometimes associated a difficulty with it. More difficulty actually resides in thebehavioral part of the ADRIA method which decomposes the task models into UML statediagrams – so called UML-Guides. There, 2 students answered that it was difficult and 5 studentsanswered that it was sometimes difficult and 2 students answered that it was mostly easy. Thisconfirms our hypothesis H3. The reason for this answer was mostly that the UML-Guide is thatthe behavioral abstractions with concurrent regions to specify parallel computation withsynchronizations among autonomous objects require a bit higher effort as well as experience.However, as we will see later, these abstractions are not necessary very often, but on the otherhand they are very useful especially in the kinds of applications where more interaction isnecessary.We have also asked students to answer questions about intensity with which they used the twodistinctive concepts of structural and behavioral interaction spaces of ADRIA. As we found out,structural models are used more often as they help to structure the object oriented application andinterface while the behavioral models are used only sometimes but in very justified cases. 5 out of9 students answered that the structural interaction space models are used in more than half of theuse cases, 2 of them answered that they are used sometimes. This confirms our hypothesis H4.Again, the reason for this answer is intuitively clear. The modeling is needed in most cases wherethe complexity is higher. This was confirmed in more than half cases. In other cases, the studentscan start programming without prior reasoning with structural interaction spaces. On the otherhand the behavioral models are used sometimes. This confirms our hypothesis H5. The reason forthis is again intuitively clear. The behavioral models adds additional overhead which can bejustified only in the cases where this models help to clarify concurrency, synchronization and morecomplex interactions among objects. This was the case when the students actually used the UML-Guides. It is also interesting to see, that for the traditional simple data centric applications such asthe one which record the metadata for music mixes on the web, the UML-Guides were not usedthat much as the required interactivity was small and navigation sequences simple to envision thatthe students could program them without a design model.We have also explicitly asked about usefulness of the various concepts in ADRIA methods indifferent stages. We have found out that the structural models of interaction spaces were moreuseful in design phase to reason about different structure for the user interfaces. 4 students out of 9reported that it was useful in more than half of the cases and 2 students reported that it wassometimes. This confirms our hypothesis H6. The UML-Guide models have been found useful inboth, design and implementation, when synchronization between autonomous user interfaceobjects was needed. However, the usefulness for later implementation was considered higher. Inthe design phase 5 students considered it useful sometimes in the cases where we reported about italready and 1 student considered it useful in more than half of the cases. For the subsequentimplementation, 3 students rated it as useful in more than half of the cases and 5 studentssometimes and this again in those cases where the synchronization was needed between objects.This confirms our hypothesis H7.Furthermore, it is also interesting to observe, that the designs and implementation ofapplications triggered additional interaction spaces which have not been initially design at thebeginning which also confirms the suitability of the method for iterative development.13

5 Related WorkA number of design methods have provided extensions dealing with different aspects of richinternet applications. WebML extension for rich internet applications has been proposed in [2].The authors have proposed new abstractions for client side and server side functionality withinhypertext schema reflected also on the pages, such as client side entity, area, web page, clientbased selectors to operate on client side data, and client side operations. The synchronizationbetween client user interface fragments and between client events and the server is implemented ina generator.RUX method [12] describes a rich internet application user interface design in three steps:abstract interface design, concrete interface design, and final interface design. The RUX providesmedia, connectors, and views elements for modeling abstract interface design. Media is an atomicelement for presenting information. Views are used to model sets and groups of information to bevisible at the same time. Connectors connect media to the other design models such as navigationand data models. Abstract interface design therefore represents a composition of presentation outof different media fragments. Concrete presentation design refines the abstract presentationdesigns with spatial, temporal and interaction aspects. Spatial presentation is defined by means ofcontrols, layouts, and navigators. Handlers, specific behavior objects, are introduced to specifychanges of a user interface based on user interaction. Handlers are synchronized as specified intemporal presentation design which describes how temporal presentation elements or groupsbehave as the time evolves; how they are synchronized when they run in parallel and whenspecific handlers are invoked.OOH4RIA [15] concentrates on RIA features in the presentation model and the orchestrationmodel. The presentation model specifically targets the Google Web Toolkit, capturing its differentwidgets. Widgets are either basic GUI elements (e.g., a button), or composite widgets (e.g., a grid).Screenshots specify the spatial arrangement of widgets that will be rendered together on thescreen. The orchestration model captures the interaction between the widgets and the rest of thesystem, the navigation between screenshots and the way widgets react to user actions. TheOOH4RIA models are modeled in UML and the language elements are defined in MOF metamodels.This allows for model transformations based on model driven architecture.The difference which ADRIA provides is the focus on interaction spaces and earlyrequirements. Therefore, it can be used with other methods which provide further refinement stepsof higher level early requirements models of ADRIA. ADRIA also provides the state machineextension which can be used as a complement to other methods.The notion of interaction spaces originate from work on model-based user interface design. Thisbroad research area includes work on the creative process of user interface design that is conductedby human designers. The aim here is to provide tools and techniques that support humans inhandling the complexities involved in the design task. This has also been denoted as designheuristics [20]. A crucial prerequisite for this approach is strong abstraction mechanisms that canhelp designers tame the complexities of the user interface design task.The literature reflects three different types of abstraction mechanisms that have been suggestedfor user interface design. The first type originates from user interface technology. In the Cameleonreference framework [4], the most abstract description of a user interface is a logical model that isbased on elements that are abstractions of existing widgets [11]. Thus this approach employs anabstraction mechanism that is derived from existing user interface technology. Widgets have beenadopted by SHDM [3] as well.The second type of abstraction mechanisms originates from the domain of the prospective usersof the system. Some focus on the tasks of the users. Tasks are a key element of the applicationdomain of a system [14]. Most task-driven design techniques exploit hierarchically organized taskstructures with temporal dependencies between sub-tasks to derive models of user interfaces [21].Others focus on the objects of the users’ work. This is a key element in the problem domain of asystem [14]. Finally, there are attempts to include both tasks and objects [12].The notion of interaction space is an interesting abstraction mechanism for model-based designof user interfaces. It is used in the Wisdom (Whitewater Interactive System Development withObject Models) method [17][18].Views have been suggested as another abstraction for user interface design. For a given task,the designer defines how many views are needed to support that task. Then the sub-tasks of thattask are distributed on the views [24]. This idea is similar to interaction spaces in the sense that anabstract concept forms the basis for design. However, a view represents a screen or part of a screenand thereby, it is less abstract than an interaction space that can represent any means forinteraction.14

Task models have been studied in the context of WSDM [5]. Similarly to our approach, thetasks are used to describe control flow between user activities and their decompositions to webapplication internal operations. We use the tasks model together with the interaction spaces. Weperform refinements to UML Guide which bridges user interaction with synchronization andcommunication specification. Our approach provides the advantage of being solution domainindependent. The mapping to the notion of web pages is performed at the UML-Guide whichallows for flexible plug in principle for different strategies to allocate behavior to the web clientand web application server.Interactive Dialog Model (IDM) [1] and SiteLang [23] focus on dialog specification and storyboarding. Story boards are based on state machines. Both approaches do not deal withcomplexities raised by client side and server side functionalities as introduced in recenttechnologies for rich internet application and different synchronization issues which are supportedby our design technique.6 ConclusionWe have proposed ADRIA, a new UML-based design method for rich internet applications.The method reflects the need to have a part of the business logic at the client side, and it providesflexibility with respect to the web page design as these decisions are made later in the design stageaccording to the UML-Guide principles. It has been illustrated through an example that the methodprovides direct means to analyze user interaction as well as asynchronous communication betweenweb client and web server. The evaluation also confirms our hypothesis on where our method isstrong in the overall development project lifecycle with novice web engineers. It also shows, thatthe modern Web2.0 applications can be build with the methods which are realized as adaptationsof existing mostly object oriented analysis and design methods.In our further work, we plan to conduct larger set of studies about features of this method. Weneed to especially look at more experienced practitioners as well as further properties of themethod to better support the designers with further guidelines.References[1] Bolchini, D., Paolini, P.: Interactive Dialogue Model: A Design Technique for MultichannelApplications. IEEE Transactions Multimedia, Vol. 8, No. 3, June 2006.[2] Bozzon, A., Comai, S., Fraternali, P., Carughi, G., T.: Conceptual Modeling and Code Generation forRich Internet Applications. ICWE2006: International Conference on Web Engineering. Palo Alto,California USA. ACM Press.[3] Calvary, G., Coutaz, J., Thevenin, D., Limbourg, Q., Bouillon, L. and Vanderdonckt, J. A UnifyingReference Framework for Multi-Target User Interfaces. Interacting with Computer, 15, 3 (2003), 289-308[4] De Moura, S., S, Schwabe, D.: Interface Development for Hypermedia Applications in the SemanticWeb. La-Web 2004 Proceedings, Oct. 2004, IEEE Press.[5] De Troyer, O., Casteleyn, S.: "Modeling Complex Processes for Web Applications using WSDM", InProceedings of the Third International Workshop on Web-Oriented Software Technologies (held inconjunction with ICWE2003), IWWOST2003[6] Dolog, P., and Stage, J.: Designing Interaction Spaces for Rich Internet Applications with UML. In PieroFraternali, Luciano Baresi, and Geert-Jan Houben(eds.), Proc. of ICWE2007: International Conferenceon Web Engineering. Como, Italy, July 2007. pages 358-363, Short Paper. LNCS 4607, Springer Verlag2007[7] Dolog, P.: Engineering Adaptive Web Applications. Doctoral dissertation. University of Hannover.March 2006.[8] Dolog, P., and Nejdl, W.: Using UML and XMI for Generating Adaptive Navigation Sequences in Web-Based Systems. In Proc. of «UML» 2003 - Sixth International Conference on the Unified ModelingLanguage: Modeling Languages and Applications, October 2003, San Francisco, USA, Springer Verlag,LNCS 2863[9] Driver, M., Valdes, R., Phifer, G.: Rich Internet Applications Are the Next Evolution of the Web.Technical report, Gartner, May 2005.[10] Duhl, J.: Rich Internet Applications. White Paper, IDC, November 2003.[11] Limbourg, Q. and Vanderdonckt, J. Adressing the Mapping Problem in User Interface Design withUsiXML. In Proceedings of TAMODIA 2004, ACM, 155-163.15

[12] Linaje, M., Preciado, J., C., Sánchez-Figueroa, F. Engineering Rich Internet Application User Interfacesover Legacy Web Models, IEEE Internet Computing, vol. 11, no. 6, pp. 53-59, November/December,2007.[13] Mahfoudi, A., Abed, M. and Abid, M. Towards a User Interface Generation Approach Based on ObjectOriented Design and Task Model. In Proceedings of TAMODIA 2005, ACM, 135-142.[14] Mathiassen, L., Munk-Madsen, A., Nielsen, P. A. and Stage, J. (2000) Object-Oriented Analysis &Design . Aalborg: Marko.[15] Melia, S., Gomez, J., Perez, S., and Diaz, O. A model-driven development for gwt-based rich internetapplications with OOH4RIA. In Daniel Schwabe, Francisco Curbera, and Paul Dantzig, editors,Proceedings of the 8th International Conference on Web Engineering (ICWE 2008), Yorktown Heights,New York, USA, pages 13-23. IEEE, July 2008.[16] Nielsen, C. M., Overgaard, M., Pedersen, M. B., Stage, J. and Stenild, S. (2006) Exploring InteractionSpace as Abstraction Mechanism for Task-Based User Interface Design. Proceedings of TAMODIA 06.Berlin: Springer-Verlag.[17] Nunes, N. J. and Cunha, J. F. Wisdom: A Software Engineering Method for Small SoftwareDevelopment Companies. IEEE Software, 2001.[18] Nunes, N. J. and Cunha, J. F. Wisdom - Whitewater Interactive System Development with ObjectModels. In M. van Harmelen (Ed.), Object Modeling and User Interface Design. Addison-Wesley, 2001.[19] Paulson, L., D.: Building Rich Web Applications with Ajax. Computer, 38(10):14–17, 2005.[20] Prinebeau, C. and Vanderdonckt, J. Exploring Design Heuristics for User Interface Derivation from Taskand Domain Models. In Proceedings of CADUI 2002, 103-110.[21] Ratnavravi, L., Christensen, A., M., Midtgaard, M., Boeg, P., H., Dao, A., T., N., Justesen, M.: InternetDevelopment: GeoQuiz – A Facebook Application. 7 th Semester Project Report on Software EngineeringStudy Program. December 2008. Aalborg University.[22] Reichart, D. Forbrig, P. and Dittmar, A. Task Models as a Basis for Requirements Engineering andSoftware Execution. In Proceedings of TAMODIA 2004, ACM, 51-58.[23] Thalheim, B., Düsterhöft, A.: SiteLang: Conceptual Model for Internet Sites. Proceedings of ER 2001,20th International Conference on Conceptual Modeling, Yokohama, Japan, November 27-30, LNCS2224, pp. 179–192, 2001, Springer[24] Wolff, A., Forbrig, P., Dittmar, A. and Reichart, D. Linking GUI Elements to Tasks – Supporting anEvolutionary Design Process. In Proceedings of TAMODIA 2005, ACM, 27-34.16