Dynamic Generation of On-line Help Messages from Dialogue Models Berardina De Carolis, Fiorella de Rosis and Sebastiano Pizzutilo Department of Informatics, University of Bari, Italy derosis,
[email protected] [email protected]
1.
Introduction
Formal models have been proposed in human-computer interaction to design correct and usable interfaces and describe their behaviour unambiguously. Graphical methods such as Harel's State Charts (Harel, ), ADV Charts (Carneiro et al.) and Petri Nets with Objects (Palanque and Bastide,
) emphasize different aspects of
interaction modeling, thus offering different advantages. They all have, however, the limit of requiring a considerable effort, to the designer, in building the model. This is, probably, the main reason why even the methods that proved to be valid in HCI research find difficulties in being applied in interface engineering. There are, currently, two ways in which research tries to deal with this limit. The first one focuses on developing tools that simplify the modeling process; examples of these tools are .... The second one is focused on proving that efforts spent in building a formal interaction model can be got back at least in part if the model is employed to ease some of the designer tasks: for instance, early prototyping and pre-empirical evaluation of the interface correctness and usability. Achieving the first of these objectives requires integrating formal modelling methods with artificial intelligence techniques. In this case, the formal model is augmented with a knowledge base in which HCI design guidelines are represented, to generate in a semiautomatic way the interface prototype: see, for instance, MECANO (Eriksson et al, 1994), HUMANOID (Szekely et al, 1992) or GENIUS ( ). Achieving the second objective requires enhancing the modeling tool with automatic check of some interface properties and evaluation of some usability measures: for instance, task executability, respect of access rights, evaluation of visual and task complexity, interface consistency and so on. These proposals are meaningful examples of how the formal model of interaction can be used as a knowledge source: the richer is the formalism, the more are the uses for which models can be employed, besides mere interface description. User-adapted interaction is a source of specific problems in trying to achieve the above mentioned objectives (model building, interaction simulation, interface prototyping and semiautomatic evaluation of interface properties). Indeed, it requires specifying in the most compact way how the interface will behave for the different user categories and contexts for which it was designed: which tasks are enabled, how each of them can be performed and which information items will be displayed in every interaction phase. Obviously, this
description requires an accurate analysis of the user requirements and of the tasks that each user category should and can perform (Macawlan, 199...). In addition, the formalism employed has to preserve knowledge collected in these phases, and to represent it in an immediate and understandable way. In previous papers, we proposed a formalism that we called XDM (Context-Sensitive Dialogue Modeling), in which Coloured Petri Nets are extended to specify user-adapted interaction modeling (De Carolis et al, 1994); we then described a tool for building XDM models and for simulating the interface behaviour in different contexts (de Rosis et al, 1996), and we proved how this tool allows performing some pre-empirical evaluation of the interface correctness and usability (de Rosis et al, 1997). In this paper, we want to prove that the same formalism can be used as a knowledge base for automatic generation of on-line help messages and, in the future, of instruction manuals addressed to the different user categories. In this research, we were inspired by the experience of the DRAFTER Project, at the University of Brighton (Scott, 1996; Hartley and Paris, 1996). DRAFTER is an interactive tool that supports technical authors in generating software manuals in several languages,
by applying natural language generation
methods to a task model. Though DRAFTER's proposal is important and new, the generation process does not consider adaptation to the user, and messages produced cover only part of the questions that users might ask: this is due, in our opinion, to limits on the formalism employed, in that research, to model interaction. To illustrate the support that a richer formalism like XDM can provide to message generation, we will: a.
describe briefly (in Section 2) an XDM interaction model (that we will call XDM-knowledge-base);
b.
analyze (in Section 3) the main explanation categories of graphical multithread interface systems, and how information needed to generate these message is represented in the XDM-knowledge-base;
c.
describe (in Section 4) the generation methods that may be employed in interpreting the user help requests and providing appropriate explanation messages, in our generation system (that we call XDM-Gen).
We will illustrate these aspects by considering a small case study about a clinical record management system.
2.
XDM Interaction Model
The XDM formalism is described in Appendix 1. An XDM interaction model traslates the results of user requirement and task analysis into an extension of Petri Nets, for each category of users; it includes a description of the following components: a.
users and contexts:
a user category or an interaction context is represented as a ground atomic formula, in a first order language whose predicates represent user or context features. In the example case that is considered in this paper: UserJob (PHYSICIAN) UserSite (HOSPITAL) describes the category of physicians working in a hospital.
2
A list of ground atomic formulae will then describe the categories of final users that will potentially use the described interface. For example, the list: ---------------------------------------------------------------------------------(UserJob (PHYSICIAN) AND UserSite (HOSPITAL), UserJob (NURSE) AND UserSite (HOSPITAL),......) -----------------------------------------------------------------------------------
describes the categories of physicians and nurses working in a hospital. b.
dynamics of tasks execution:
Task hierarchies, with temporal relations among them, are represented as a 'cascade' of coloured PNs. The lowest level of the hierarchy (elementary tasks) corresponds to elementary (non-nested) transitions in the PNs; higher levels correspond to nested transitions and are described, in their turn, by PNs corresponding to tasks of varying complexity: the tasks hierachy and the relationships among tasks are then mirrored in the PN 'cascade'. Adaptation to user categories and to the context is represented by associating guards to transitions and conditions to places: guards and transitions are represented with the same language employed to describe users and contexts. Figure 1 shows an example of PN describing the task Retrieve a set of patient records with different nesting levels and constructs. Modeling dialogues with PNs shows how immediate it is to represent aspects which are typical of graphical intefaces, such as sequencing, visual concurrency, synchronization, selection among alternative tasks, iteration of a task or interleaving. Let's see how: -
sequence: this construct allows specifying a complex task as a concatenation of less complex tasks.
All transitions in a sequence (for instance 'Retrieve a set of Patient Records' or 'Retrieve a Single Record', in Figure 1) have an elementary preset and postset. XDM attaches to places and transitions a logical projection, that specifies the task associated to every transition and the information items associated to every place. Executing the sequence path in the PN thus represents the alternance of 'system states' (displayed information in a given phase of interaction) and 'events' (task perfomed by the user); -
visual concurrency: the simultaneous display of different information items is represented by the
simultaneous marking of different places (as in the PN 'Input personal data'). Paths starting from these places define concurrently active tasks; -
syncronization: this construct defines an action that synchronizes the execution of different,
concurrently active paths and is indicated by a transition that closes the concurrent paths; -
selection: the possibility to select one of the tasks that are simultaneously executable in a given phase
of interaction is represented by the simultaneous enablement of different transitions; paths starting from these transitions define alternative tasks (as in 'Search a patient'); -
iteration: task repetition is represented by inserting an edge that connects the end of the path which
represents that task to the preset of its initial transition (as in 'Retrieve records'): this allows enabling again this transition when the task has been completed. Obviously, iteration must be combined with a transition representing exit from the task. c.
user commands:
the 'physical projection of transitions' describes the action by which the task associated to every transition can be performed, by each user category. 3
For instance: --------------------------------------------------------------------------task: Exit from the Retrieve record task user category: (UserJob (PHYSICIAN) UserSite (HOSPITAL) interaction technique: Sb (select a button) interaction object 'EXIT' button ---------------------------------------------------------------------------
The physical projection table, together with the PN mentioned in the previous point, describes in a complete way the actions needed to perform complex tasks, with the temporal relationships among these actions and, therefore, among tasks themselfs. d.
effects of a task
An elementary user action produces a change in the interface and in the application state: this is described by the 'logical projection of places' that, as mentioned previously, associates to each place the description of the information item that will be displayed when that place will be marked. For example: --------------------------------------------------------------------------task: Exit from the Retrieve record task user category: (UserJob (PHYSICIAN) UserSite (HOSPITAL) effect: application function: close the 'Retrieve record' application information content: confirmation message ---------------------------------------------------------------------------
Obviously, the effect of an elementary action is the precondition of the following one, in the sequence of commands that describe a task. e.
interface layout in every interaction phase.
The 'physical projection of places and transitions' defines in terms of images or animations, how each information item or action is displayed, for each user category. Referring, again, to the previous example: --------------------------------------------------------------------------task: Exit from the Retrieve record task user category: (UserJob (PHYSICIAN) UserSite (HOSPITAL) information content: confirmation message layout: 'Do you really want to exit from the record retrieval session?' ---------------------------------------------------------------------------
3.
Categories of explanation messages
Our purpose is to generate on-line hypermedia explanation messages that provide, in each interaction phase and on the user request, the information which is relevant in that phase and that context. The same messages might be generated and used also when interaction is simulated, so that the designer, a technical writer or a sample of potential users can evaluate them before the interface is engineered. From the analysis of a 'standard' software instruction manual (Microsoft Visual Basic), integrated with other experiences in this field (for instance, DRAFTER), we singled out the categories of user questions to which the system should be able to answer, and the information elements that answers should include:
4
a.
information on single items.
Hartley and Paris (1996) propose the following elements as meanigful constituents of a software manual: -
goals:
the elementary tasks
-
functions:
the elementary actions (or commands, to be executed by means of events
applied to interaction objects) -
constraints:
constraints for the correct task execution;
-
results:
task effects, described as changes in the system state;
-
substeps:
sequence of elementary tasks that enable performing a more complex task.
b.
information on relations among items:
The description of a goal in terms of its 'substeps' is adequate in the case of task sequences. However, all the relations that we described in subsection 2b have to be translated, as well, into user-adapted explanations. Though this type of messages is less common in manuals, we will provide examples whenever possible. c.
type of questions to which the system should be able to answer.
-
which-tasks? which tasks is this system able to perform (globally)?
This corrsponds, for instance, to the index of the Visual Basic Instruction Manual; this index can be generated, for each user category, from the logical projection of transitions concerning complex tasks in the XDM model. Example: --------------------------------Visual Basic Help: Learning Visual Basic Creating the Interface Setting Properties ....... -------------------------------------------
-
which-now-tasks? which are the tasks that can be perfomed in this phase of interaction?
This corresponds to the list of (simpler or elementary) tasks that can be performed in the context of a more complex one. This list can be obtained, again, from the logical projection of enabled transitions, by clarifying whether enabled tasks are in alternative or are concurrently active. In the first case, the activation of one of the tasks will disenable the others; in the second case, the other tasks will remain enabled when one or more tasks will have been activated. Example: ---------------------------------------------------------There are 16 tools in the toolbox: Pointer: this is the only item, in the toolbox, that doesn't draw a control. ....... ----------------------------------------------------------
-
how-to task? how a particular task can be executed?
5
If the task is an elementary one, the physical projection of the transition associated to the task describes the action. Example: ------------------------------------------------------press the "Down Arrow" to Select the next tool down (in the Toolbox keys) ----------------------------------------------------------
if it is a complex and corresponds to a sequence of elementary tasks, the task associated to every transition in the sequence has to be described. Example: --------------------------------------------------------How to "Create an Application". To create an application in Visual Basic, follow thesuggested sequence: 1. Create a new project 2. Create a form for each window in the application 3. ..... ..... and so on ---------------------------------------------------------
If the task is complex and includes a combination of the constructs mentioned in Section 2c, construct-specific generation functions have to be employed. -
when task?
when, in which conditions can a task be executed?
The guard attachted to the transition to which the task is associated defines its condition of execution; the preset of this transition describes the state of the system before the task is performed. Example: ---------------------------------------------------------To create an executable file, 1. from the File Menu, choose Make Exe File. If there are no syntax or other compile errors in your code, ..... ----------------------------------------------------------
(this example message is, in fact, a combination of answers to 'how-to task' and 'when task' questions). -
what-if interaction-object: what happens if an interaction object is activated?
which is the task associated, in a particular context, to this action? Example: ------------------------------------------------------"New Project" option in the "File Menu" creates a new Project. "Help Menu" provides access to Help topics, .... -------------------------------------------------------
which information will be displayed after executing this task? Example: --------------------------------------------------------------------------To create an executable file, 6
1.
from the File Menu, choose Make Exe File. If there are no syntax or other compile errors in your code, Visual Basic displays a default .EXE filename in the FileName text box. ---------------------------------------------------------------------------
This example is also a combination of answers to 'how-to task' and what-if interaction-object' questions. -
why-not interaction-object: why is an interaction object inactive?
Example: -----------------------------------------------------------------Edit Menu. "If Paste is not enabled, this means that nothing has been copied or cut" ------------------------------------------------------------------
4.
XDM-Gen: the generation module (?)
An explanation message is generated by XDM-Gen as a function of the following elements: -
type of question,
-
item(s) of the PN to which the question refers,
-
relation among items involved in the answer.
Different sections of XDM knowledge base are employed to generate answers to different types of questions; the NLG method is based on schemas. A schema is a classical knowledge representation formalism, which is widely used in natural language and multimedia generation (ILEX e Cawsey , inserire). We will distinguish between: -
elementary schemas, describing a PN's constituents;
-
schemas for answering to questions about tasks or interaction objects, described in the previous Section.
We will describe how these answers are generated in correspondence with the elementary constructs that define relationships among items in a PN. We will refer, in this description, to the PN relations and functions and to the elementary message generation functions that are described in Appendix 2. 4.1. a.
Description of single items place description --------------------------------------------(def-schema describe_place(pi) :preconditions = :decomposition = ((text (pi.informationcontent/currentcontext)) (img (pi.layout/currentcontext))) end-def) ----------------------------------------------
b. b.1.
task description elementary task --------------------------------
7
(def-schema describe_task (ti) :preconditions = not nested(ti) :decomposition = ((text (ti.task/currentcontext)) 'by' (describe_action (ti))) end-def) ---------------------------------
b.2.
nested task -------------------------------------(def-schema describe_task (ti) :preconditions = nested(ti) :decomposition = ((hypertext (ti.task/currentcontext))) end-def) -------------------------------------
c.
description of the action needed to perform an elementary task ------------------------------------------------------(def-schema describe_action(ti) :preconditions = not nested(ti) :decomposition = ((text (ti.interaction_technique/current_context ) "the " (interaction_object/current_context) ".") (img (ti-layout/currentcontext))) end-def) -------------------------------------------------------
d.
description of preconditions to execute a task
d.1.
simple preconditions -------------------------------------------------------------------(def-schema describe_precondition (ti)) :preconditions = |preset(ti)| = 1 :decomposition = ((text "This task can be performed when the" (describe_place (Pr(ti))) "is displayed")) end-def) (if exists(ti.transition-guard) "and the following condition is true:" (ti.transition-guard))) --------------------------------------------------------------------
d.1.
complex preconditions --------------------------------------------------------------(def-schema describe_precondition (ti)) :preconditions = |preset(ti)| 2 :decomposition = ((text "This task can be performed when the following information is displayed" (forall pj (is-in pj Pr(ti)) (Insert_item_list) (describe_place(pj))) (if exists(ti.transition-guard) "and the following condition is true:" (ti.transition-guard))) end-def) ----------------------------------------------------------------
e.
description of the effects of an action
e.1.
simple effects 8
----------------------------------------------------------------------------(def-schema describe_effect (ti)) :preconditions |Po(ti)| = 1 :decomposition = ((text "This will have as effect the display of the") (describe_place(postset(ti)))) end-def) ---------------------------------------------------
e.1.
complex effects ------------------------------------------------------------(def-schema describe_effect (ti)) :preconditions |Po(ti)| 2 :decomposition = ((text "This will have as effect the simultaneous display of the following objects:" ) (forall pk ((is-in pk Po(ti)) and (Cond(pk) = true))) (insert_item_list) (describe_place(pk)))) end-def) ------------------------------------------------------------
4.2.
Answers to questions about performable tasks:
a.
globally: which-tasks? --------------------------------------------------(def-schema describe_which-tasks :preconditions = (ask-which-user) and main(net) :decomposition = ((text "The following tasks can be performed") (forall ti (part-of (ti net)) (insert_item_list) (describe-task(ti)))) end-def) --------------------------------------------------
b.
in a particular interaction context: which-now-tasks ? ------------------------------------------------------------(def-schema describe_which-now-tasks :preconditions = (ask-which-now-user) and active(net) and (choice(net)) :decomposition = ((text "You have to select one of the following tasks") (forall ti (part-of (ti net)) and (enabled(ti)) (insert_item_list) (describe-task(ti)) (text "or"))) end-def) -------------------------------------------------------------------------------------------------------------(def-schema describe_which.now-task :preconditions = (ask-which-now-user) and active(net) and (concurrency(net)) :decomposition = ((text "You can do, concurrently, the following tasks") (forall ti (part-of (ti net)) and (enabled(ti)) (insert_item_list) (describe-task(ti)) (text " ,")))
9
end-def) ------------------------------------------------------------------------
4.3.
Answers to questions about a specific task
4.3.1. how-to task? a.
elementary tasks (associated to non-nested transitions): ------------------------------------------------------------------------(def_schema describe_how_simple (task) :precondition = (ask-how-user (task)) and (associated-to (task ti)) and not (nested(ti))) :decomposition = ((describe-task(ti))) end-def) -------------------------------------------------------------------------
b.
complex tasks (associated to nested transitions) -------------------------------------------------------------------(def_schema describe_how (task) :precondition = (ask-how-user (task)) and (associated-to (task ti)) and (nested (ti)) :decomposition = ((describe_how_sequence (task)) or (describe_how_choice (task)) or (describe_how_iteration (task)) or (descrbe_how_order-independence (task)) ......... ) end-def) --------------------------------------------------------------------
b.1
sequence of tasks:
A B
------------------------------------------------------------------(describe_how_sequence (net)) :precondition = sequence (net) :decomposition = ((text "To"(net.name)",you should perform, in sequence, the following tasks:") (forall tj (part-of (ti net)) (insert_item_list) (describe-task(ti))) end_def) --------------------------------------------------------------------
b.2.
Choice between tasks:
A |B
-----------------------------------------------------------------------------------------(def-schema describe_how_choice(net) :precondition = (choice(net)) :decomposition = ( (text "You can" (net) ", in one of the following ways." ((forall ti ((part-of (ti net)) and (enabled(ti))) ((insert_item_list) (describe_task(ti))) ) end-def)
10
------------------------------------------------------------
b.3.
Order independence:
A
that is:
&B
(A B | (B A)
------------------------------------------------(def-schema describe_how_order_independence (net) :precondition = (order-independence (net)) :decomposition = ((text "To" (net.name) ", you have to:") (forall ti ((part-of (ti net)) and (enabled(ti))) (insert_item_list) (describe-task(ti))) (text "in any order. You have, finally, to") (forall tj ((part-of (tj net)) and not (enabled (tj))) (describe-task (tj)))) end-def) --------------------------------------------------
b.4.
iteration:
A*
-------------------------------------------------------------------------(def-schema describe_how_iteration(net) :precondition = ((part-of (ti net)) and (= postset(ti) preset(ti))) :decomposition = ((text "To" (net.name) ", you may iterate the task") (describe_task(ti)) (text "several times .")) end-def) ----------------------------------------------------------------------------
Other constructs can be generated by similar schemas. Figure 2 shows the answer to 'how-to-task' requests of explanations, for the Petri Net that was shown in Figure 1. 4.3.2. when-task? ---------------------------------------------------------------------(def-schema describe_when (task) :precondition = ((ask-when-user (task)) and (associated-to (task ti)) and not (nested (ti))) :decomposition = ((text "You can") (describe-task (ti)) (text "when" (Cond(it)) "is true and when the") (describe_precondition(ti)) (text "are displayed in an active mode")) end-def) -------------------------------------------------------------------------
Figure 3 shows an example of answer to a 'when task' request.
11
4.4.
Answers to questions about interaction objects
a.
what-if interaction-object? ----------------------------------------------------(describe_whatif (interactionobject) :preconditions = ((associated-to (interactionobject ti)) and (nesting (ti false))) :decomposition ((text "If you") (describe-action(ti)) (text "you will") (describe-task(ti)) (text ". The effect of this action will be to") (describe-effect (ti))) end_def) ------------------------------------------------------
Figure 4 shows an example of answer to a 'what-if interaction-object' question. b.
why-not interaction-object?
This is a more difficult question to handle: the answering system should reason on why a specified transition is not enabled, in a given context. The transition guard might be false or some elements of the transition preset might be unmarked (and the reason of this should be examined, in its turn). 5.
Final remarks
The main advantage of dynamic generation of explanation messages employing the formal interaction model as a knowledge source is that messages produced follow automatically every variation in the system design; in addition, knowledge about users and context enables adapting messages to their characteristics (language, level of experience, and so on). Messages can be structured, in perspective, as an hypermedia, on-line instruction manual: the elementary generation functions employed in the schemas (text, hypertext, insert-itemlist, etc.) render the output directly in HTML; their combination, activated by the schema application, generates a hypermedia that users can browse during interaction, according to their information needs. Acknowledgements We owe the idea of this research to Cecile Paris, when she was a Visiting Professor at the University of Bari in 1997. References B De Carolis and F de Rosis: Modelling adaptive interaction of OPADE by Petri Nets. SIGCHI Bulletin, 26, 2, 1994 F de Rosis, S Pizzutilo and B De Carolis: A tool to support specification and evaluation of context-customized interfaces. SIGCHI Bulletin, 28, 3, 1996. F de Rosis, S Pizzutilo and B De Carolis: Formal description and evaluation of user-adapted interfaces. Submitted to IJHCS, 2nd revision, december 1996 12
H Eriksson, D Harel: Statecharts: a visual formalism for complex systems. Science of Computer Programming, 8, 231274, 1987 A Hartley and C Paris:Two sources of control over the generation of software instructions. University of Brighton Technical Report ITRI-96-02, 1996 C Janssen, A Weisbecker and J Ziegler. Generating user interfaces from data models and dialogue net specifications. Proceedings of INTERCHI93, 418-423, 1993. L Macawley: C Paris and K Vander Linder: DRAFTER, An interactive support tool for writing multilingual instructions. IEEE Computer, 29, 7, 1996 Palanque and Bastide
D Scott: Computer support for authoring multilingual software documentation. University of Brighton, Technical Report ITRI-96-14, 1996 Szeckely:
13
Appendix 1: Formal Description of an XDM model --------------------------------------------------------------------------------------------------------A PN can be formally defined as a tuple : , where N is the name of the Net P is a finite set of places: p1, p2...,pn, denoted with a circle; T is a finite set of transitions: t1, t2 ...,t m , denoted with a rectangle; A : is a finite set of oriented arcs between P and T (T and P); A : (PxT) (TxP) 0,1 SP is the set of start places (a subset of P); EP is the end place (an element of P) and is denoted with a grey circle. The set of places that are incident on a transition t is a preset of t (Pr(t)): p in P: (p in Pr(t)) (A(p,t) = 1). The set of places that follow t is a postset of t (Po(t)): p in P: (p in Po(t)) (A(t,p) = 1). A path in the PN is a sequence of places and transitions which begins and ends with a place. The function M : P 0,1 is called a marking function for the PN. This function maps each place p to a binary value. A place pi is marked if M(pi)=1 (a token is in that place), otherwise it is unmarked; marking is denoted with a dot within the place. Ms denotes the initial marking of the net, where all start places are marked. In the final marking Mf, the end place is marked. Markings propagate in the net according to the following rules: a transition is enabled when its preset is marked; it then can fire. After a transition has fired, its postset is marked and the markers in its preset are removed; the marking function represents how the system state evolves during execution. In a Nested Petri Net, a labelling function L is associated to transitions: this function maps each transition into the name of a PN, or NIL; if L(t) ≠ Nil, t is a nested transition and is denoted with a grey rectangle A Dialogue Model is then a tuple: DM = < PN, LP, PhP> , where: PN is a Petri Net; LP is its logical projection, defined as a couple < LPp , LPt > , where: LPp is a logical projection of places; LPt is a logical projection of transitions. Given a set G of tasks that the user wants to achieve and a set I of information items that the system will display as result of these tasks, the logical projection of places LPp is a function that associates to each place of the PN a description of information displayed: LPp = P -> I the logical projection of transitions LPt is a function that associates to each transition of the PN a description of the task performed: LPt = T -> G PhP is its physical projection, defined as a couple < PhPp , PhPt > , where: PhPp is the physical projection of places; PhPt is the physical projection of transitions. Given a set A of actions that the user can perform and a set D of screen layouts that the system can show as a result of these actions, the physical projection of places PhPp is a function that associates to each information item in LPp its screen layout D: PhPp = I -> D the physical projection of transitions PhPt is a function that associates to each task in LPt the action that the user has to perform to achieve it: PhPt = G -> A . A context-sensitive dialogue is described by a Coloured Nested Petri Net, which is a tuple: CPN = , where F is a place-conditioning function that maps each place p into a nonquantified ground formula Cond(p) in a first order language or Nil; this formula specifies a condition for the place to be marked. G is a transition guard function that maps each transition t into a nonquantified ground formula Tg(t) in or Nil; this formula specifies a condition for the transition to fire. 14
Appendix 2: Definitions ----------------------------------------------------------------------------------------------------Let be ti the name of a transition and net a PN name; let's define the following functions and properties: functions to check properties of a PN and of its elements: main(net) net is the 'main PN', it corresponds to the main task of the system active(net) net is the currently 'active' PN nested(ti) ti is nested ; enabled(ti) ti is enabled; belongs-to (Po(ti), Pr(ti) the postset of ti is included in its preset; associated-to (task ti) the task 'task' is associated to ti; (a che ti serve? E' gia' nelle proiezioni basta chiedere ti.task) is-in (ti set) : ti is included in the 'set' of transitions: for instance, is-in (ti Pr(ti)) part-of (ti net) ti is one of the transitions of net; sequence(net) net is represented by a 'sequence' construct; choice(net) net is represented by a choice construct; iteration(net) ......etc. properties of the user-system interaction: all these properties are of the type: ask-user(type of question);CONSIDERA CHE NELLO SCHEMA USI ask-when-user DOVREBBE ESSERE QUINDI ask-user(when_task) OSBAGLIO? in questions of the type 'how' and 'when' the task to which the question refers to is specified; in questions of the type 'what-if' and 'whynot' the interaction object is specified. |set|
functions to elaborate PNs: calculates the cardinality of 'set', for instance of Pr(ti).
elementary functions of message generation: (text (list)): generates a text in natural language combining the elements in (list); (hypertext (list)): generates an anchor text, from the elements in (list); (insert_item-list): insert a progressive ordinal number to identify list items.
15
Retrieve a set of patient records
t0
Retrieve records
Retrieve records
t1
t2 Retrieve a single record t4
t3
Exit from the Retrieve records task
Retrieve a single record
Confirm exit Search a patient
Search a patient Input personal data
t5 Print a record
Input personal data Input surname
t8
t9
t10
t6
t7
Input Identif. number
Input name
Confirm data
Figure 1: an example of nested PN representing the task Retrieve a set of patient records
16
------------------------------------------------------------------------------------------------------t0
Nested PN
Task
-----------------Retrieve records
-------------------
Interaction technique --------
Layout -----------
t1
Exit from the Retrieve records task
Sb
figura
t2
Confirm exit
Sb
figura
Print a record
Si
figura
t7
Input identification number
Ft(8)
figura
t8
Input surname
Ft(20)
figura
t9
Input name
Ft(20)
figura
t1 0
Confirm data
Sb
figura
t3
Retrieve a single record
t4
Search a patient
t5 t6
Transition guard ----------------
Input personal data UserSite(HOSPITAL)
----------------------------------------------------------------------------------------------------------------------Table 1: logical and physical projection of transitions, in the PN in figure 1
17
--------------------------------------------------------------------------------------------------------------How to Retrieve a set of patient records? -----------------------------------------------------------------------To Retrieve a set of patient records, you should perform, in sequence, the following tasks: 1. Retrieve records 2. Exit from the Retrieve records task, by clicking on the 'Exit' button 3. Confirm exit by clicking on the 'OK button. -----------------------------------------------------------------------How to Retrieve records? -----------------------------------------------To Retrieve records, you may iterate the task Retrieve a single record several times -----------------------------------------------How to Retrieve a single record? ----------------------------------------------------------------------To Retrieve a single record, you should perform, in sequence, the following tasks: 1. Search a patient 2. Print the record, by clicking on the Print icon in the menu bar ----------------------------------------------------------------------How to Search a patient? -----------------------------------------------You can Search a patient in one of the following ways: 1. Input personal data 2. Input identification number by filling the 'identification number' textfield -----------------------------------------------How to Input personal data? ------------------------------------------------------To Input personal data, you have to: 1. Input surname, by filling the 'surname' textfield and 2. Input name, by filling the 'name' textfield in any order. You have, finally, to Confirm data, by clicking on the 'OK' button. ------------------------------------------------------
Figure 2: examples of 'how-to' help messages, about the Petri Net in Figure 1
18
-----------------------------------------------------------------------When Print a record? -----------------------------------------------------------------------You can Print a record by clicking on the 'Print icon' on the menu bar, when the 'Patient found' condition is true and the 'Patient Identification data' are displayed. ------------------------------------------------------------------------
Figure 3: an example of 'when' help message, about the Petri Net in Figure 1
What-if Exit button? ----------------------------------------------------------------------Clicking on the Exit button enables you to exit from the 'Retrieve records' task. The system will undisplay the Patient record window and will display the menu bar. -----------------------------------------------------------------------
Figure 4: an example of 'what-if' help message, about the Petri Net in Figure 1
19
