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

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