Models of the System Standard Form alism s chapter 17 software engineering notations used to specify the required behaviour of specific interactive system s Interaction Models models of the system special purpose m athem atical m odels of interactive system s used to describe usability properties at a generic level Continuous Behaviour activity between the events, objects with continuous m otion, m odels of tim e types of system model Relationship with dialogue • Dialogue m odelling is linked to sem antics • dialogue – main modes specific system • System sem antics affects the dialogue • full state definition structure generic • But the bias is different • abstract interaction model issues • Rather than dictate what actions are legal, these formalisms tell what each action does to the system . Irony • Computers are inherently mathematical machines standard formalisms • Humans are not • Formal techniques are well accepted for cognitive models of the user and the dialogue general computing notations (what the user should do ) to specify a particular system • Formal techniques are not yet well accepted for dictating what the system should do for the user ! 1
standard formalisms Uses of SE formal notations Standard software engineering form alism s can be used • For com m unication to specify an interactive system . – com m on language – rem ove am biguity (possibly) Referred to as form al m ethods – succinct and precise • Model based – describe system states and operations • For analysis – Z, VDM – internal consistency • Algebraic – describe effects of sequences of actions – external consistency – OBJ, Larch, ACT-ONE • with eventual program • Extended logics – describe when things happen and who • with respect to requirements (safety, security, HCI) is responsible – specific versus generic – temporal and deontic logics model-based methods model-based methods • describe state using variables • use general mathematics: • types of variables: – numbers, sets, functions – basic type: x: Nat – non-negative integer { 0,1,2,...} or in the Z font: • use them to define – individual item from set: – state shape_type: { line, ellipse, rectangle} – subset of bigger set: – operations on state selection: set Nat – set of integers or in the Z font: – function (often finite): objects: Nat � Shape_Type Mathematics and programs running example … Mathem atical counterparts to com m on program m ing constructs Program m ing Mathem atics t ypes sets basic types basic sets constructed types constructed sets records unordered t uples lists sequences functions functions a simple graphics drawing package procedures relations supports several types of shape 2
define your own types … yet another type definition an x,y location is defined by two numbers A collection of graphic objects can be identified by a ‘lookup dictionary’ Point = = Nat � Nat [ Id] a graphic object is defined by its shape, size, and centre Shape_Dict = = I d � Shape Shape = = • Id is an introduced set shape: { line, ellipse, rectangle} – som e sort of unique identifier for each object • Shap_Dict is a function x, y: Point – position of centre – for any Id within its dom ain (the valid shapes) it wid: Nat gives you a corresponding shapthis m eans for any ht: Nat – size of shape use them to define state invariants and initial state invariants – conditions that are always be true – m ust be preserved by every operation selection � dom shapes – selection must consist of valid objects initial state – how the system starts! shapes: Shape_Dict dom shapes = { } – no objects selection: set Id – selected objects selection = { } – selection is empty Defining operations … another operation State change is represented as two copies of the state delete: before – State after – State’ dom shapes' = dom shapes – selection – remove selected objects The Unselect operation deselects any selected objects � id � dom shapes' shapes' (id) = shapes(id) unselect: – remaining objects unchanged selection' = { } – new selection is empty selection' = { } – new selection is empty shapes' = shapes – but nothing else changes � note again use of prim ed variables for ‘new’ state 3
display/presentation Interface issues • Fram ing problem • details usually very complex (pixels etc.) – everything else stays the same … but can define w hat is visible – can be complicated with state invariants • I nternal consistency Visible_Shape_Type = Shape_Type – do operations define any legal transition? highlight: Bool • External consistency display: – must be formulated as theorems to prove – clear for refinement, not so for requirements vis_objects: set Visible_Shape_Type • Separation – distinction between system functionality and presentation vis_objects = is not explicit { ( objects(id), sel( id) ) | id � dom objects } where sel(id ) = id � selection Algebraic notations Return to graphics example • Model based notations types – emphasise constructing an explicit representations of the State, Pt system state. operations init : � State • Algebraic notations make ellipse : Pt � State � State – provide only implicit information about the system state. move : Pt � State � State unselect : State � State • Model based operations delete : State � State – defined in terms of their effect on system components. axiom s for all st � State, p � Pt • • Algebraic operations 1. delete(make ellipse(st)) = unselect(st) – defined in terms of their relationship with the other 2. unselect(unselect(st)) = unselect(st) operations. 3. move(p; unselect(st) ) = unselect(st) Issues for algebraic notations Extended logics • Ease of use • Model based and algebraic notations m ake extended use of propositional and predicate logic. – a different way of thinking than traditional programming • Propositions • I nternal consistency – expressions made up of – are there any axioms which contradict others? atomic terms: p, q, r, … • External consistency – composed with logical operations: � � ¬ � … – with respect to executable system less clear • Predicates • External consistency – propositions with variables, e.g., p(x) – with respect to requirements is made explicit and – and quantified expressions: � � automation possible • Not convenient for expressing tim e, responsibility and • Com pleteness freedom , notions som etim es needed for HCI – is every operation completely defined? requirem ents. 4
Temporal logics Explicit time • These tem poral logics do not explicitly Time considered as succession of events mention time, so some requirements cannot be expressed Basic operators: – always ( G funnier than A) • Active research area, but not so m uch with – eventually (G understands A) HCI ¬ ¬ – never (rains in So. Cal.) • Gradual degradation more important than tim e-criticality Other bounded operators: p until q – weaker than • Myth of the infinitely fast m achine … p before q – stronger than Deontic logics Issues for extended logics For expressing responsibility, obligation between agents • Safety properties – stipulating that bad things do not happen (e.g., the human, the organisation, the computer) • Liveness properties perm ission per – stipulating that good things do happen obligation obl • Executability versus expressiveness For example: – easy to specify impossible situations owns ( Jane’ file ` fred' ) ) � – difficult to express executable requirements – settle for eventual executable per ( Jane, request ( ‘print fred’ )) performs ( Jane, request ( ‘print fred’ )) ) � • Group issues and deontics obl ( lp3, print ( file ‘fred’)) – obligations for single-user systems have personal impact – for groupware … consider implications for other users. Interaction models General computational models were not designed with the user in mind interaction models We need models that sit between the software engineering formalism and our understanding of HCI • formal – the PIE model for expressing general interactive properties to support usability PIE model • informal defining properties – interactive architectures (MVC, PAC, ALV) to motivate separation and modularisation of functionality and presentation (chap 8) undo • semi-formal – status-event analysis for viewing a slice of an interactive system that spans several layers (chap 18) 5
Recommend
More recommend
