paper - UniversitÃ¤t Rostock

More documents

Recommendations

Info

4 Task Models as Mediator between Scenarios and Formal System Specifications 4.1 Scenario Elements are Instances of Model Elements An action model describes a set of sequences of basic actions which all lead to task completion. Each sequence is a kind of instance of the action model. An object O 1 is an instance of an object O 2 in the business object model (denoted by O 1 ::O 2 ) if for all attributes a i :v i of O 2 there is an attribute a i :v’ i in O 1 and v’ i is an instance of v i . Further, instance relations between actors are assumed. Let T be a task model with the action model A, the business object model O and the user model R. A complete scenario is a sequence a 1 (r 1 ,{o 1 1,…,o 1 n1}),…,a m (r m ,{o m 1,…,o m nm}¡ where a i are basic actions in A and a 1 (R 1 ,{O 1 1,…,O 1 n1}),…,a m (R m ,{O m 1,…,O m nm}¡ is a possible sequence in A with action model: A actor: R,S ↓:H, ↑:G A1 actor:R ↓:E, ↑:G business object model: e1 :: A2 actor:R ↓:F, ↑:G E :: e2 A3 actor:S ↓↑:G F :: f1 :: f2 temporal relations between subactions: A = (A1 [] A2) >> A3 g1 :: g2 G :: :: g3 user model: r1 :: R r2 :: R s1 :: S valid scenarios: ¢ A1(r1,{e1,g1}),A3(s1,{g1,g1}£ , Figure 2: Complete scenarios derived from a task model ¢ A1(r2,{e2,g1}),A3(s1,{g1,g1}£ ,…,¢ A2(r1,{f2,g3}),A3(s1,{g3,g3}£ actors R i from R and objects O j i from O assigned to a i (for brevity pre-and post conditions, artefacts and means are not distinguished). Further, r i resp. o j i have to be instances of R i resp. O j i (i=1,..,m, j=1,2,…). The notion P(O) (e.g. P(SL) in Fig.1) describes a set of instances of O. A task model describes a (mostly infinite) set of complete scenarios. Fig.2 visualizes this idea by a small abstract example. The used temporal operators are [] for alternative and >> for sequential sub-actions. Comparing the scenario at the beginning of Sect.2 with the task model in Fig.1 it should be clear now that Prof. Thiel is an instance of Prof., Peter Meyer and Anne Holz are instances of Assistant, Prof. Thiel is evaluating the results of an instance of Total list and so on. 4.2 Scenarios as Stories vs. Scenarios as Test Cases This <strong>paper</strong> proposes a distinction between two kinds of scenarios. Scenarios as stories have an incomplete character in that sense that they are constructed from different parts of the appropriate task model. This kind reflects rather the approach taken by Rosson and Carroll. Scenarios can involve different actors and actions, and can even refer to goals or pieces of action models to describe mental activities of actors. Scenarios as stories are mainly used to improve and illustrate (initial) task models. For example, the scenario in Sect.2 was
constructed on the basis of the task model in Fig.1 and revealed the sub-action rechecking the total list which was added afterwards to the task model (indicated with dotted lines in the figure). “In SBD new activities are always grounded in current activities” [RC02]. Scenarios as stories support the transition from current to envisioned models. Taken the scenario in Sect.2, for example, one can easily imagine that in the envisioned practice the compiling of the total list out of the single lists for each of the 5 exercises can be done automatically by the software system under development. It is also of advantage that the system can label the “borderline cases” (the entries of the students who miss 1 or 2 points to pass the examination). An envisioned task model has to reflect the application of the software system by the actors. problem scenarios ... task model of the current practice specification of the software system design scenarios ... task model of the envisioned practice test case scenarios ... Figure 3: A combination of MBD and SBD Scenarios as test cases are complete scenarios in the sense of Sect. 4.1. They can be generated from sub-trees of the action hierarchy as should be underlined by Fig.2. They are useful for validating a system specification with respect to a task model and vice versa because they describe the interaction between a user and the system precisely. Scenarios of this kind are rather comparable with scenarios as paths through use cases. Fig.3 illustrates possible applications of scenarios to supplement a model-based design process. 5 Summary A combination of SBD and MBD to improve the software design process was shown. Task models play a mediating role. They supply a general description which is useful for constructing scenarios on the one side but also for deriving formal system specifications on the other side. A distinction between scenarios as stories and scenarios as test cases was proposed and their different fields of application were explored. There are a lot of open questions. The problem of choosing a representative set of test case scenarios out of a possibly infinite set is only one of them. The interested reader is referred to [FD03] where tool support is described. References [Car02] J.M.Carroll: Scenarios and Design Cognition, Proc. of the Int. Conf. On Requirements Engineering RE2002, Essen, Germany. [RC02] M.B.Rosson, J.M.Carroll: Usability Engineering – Scenario-Based Development of Human-Computer Interaction, Morgan Kaufmann Publishers, 2002. [FD03] P.Forbrig, A.Dittmar: Interfacing Business Object and User Models with Action Models in this Proceedings of HCI 2003. [Dit02] A.Dittmar: Ein formales Metamodell für den aufgabenbasierten Entwurf interaktiver Systeme, PhD-Thesis, Universität <strong>Rostock</strong>, 2002.
Page 1 and 2: Abstract Bridging the Gap between S
Page 3: action model organizing examination

paper - UniversitÃ¤t Rostock

Create successful ePaper yourself

Delete template?

Save as template?