Figure 2 - uploaded by Rémi Bastide
Content may be subject to copyright.
Contexts in source publication
Context 1
... propose a design life cycle supporting the use of formal notations both for task and system modelling. This life cycle (Figure 2) instanciates the life-cycle described in Figure 1 as a sub-cycle to support both task and system formal modelling and extends it to include task/system cross verification. The life cycle proposed in Figure 2 may start either by some rough model of the system (which may originate from the existing situation, e.g. ...
Context 2
... life cycle (Figure 2) instanciates the life-cycle described in Figure 1 as a sub-cycle to support both task and system formal modelling and extends it to include task/system cross verification. The life cycle proposed in Figure 2 may start either by some rough model of the system (which may originate from the existing situation, e.g. analysis of the paper documents in an information system analysis) or with an initial task model. ...
Context 3
... first start from an initial model of the system and then show two successive modifications of the system and task models. This corresponds to performing two iterations in the design life-cycle presented in Figure 2. The internal loop for the building of each model as well as the quantitative analysis box of Figure 2 are discussed in the section " Formal Verification of Models ". ...
Context 4
... first start from an initial model of the system and then show two successive modifications of the system and task models. This corresponds to performing two iterations in the design life-cycle presented in Figure 2. The internal loop for the building of each model as well as the quantitative analysis box of Figure 2 are discussed in the section " Formal Verification of Models ". ...
Context 5
... section aims at describing the content of the box entitled Maintain Task and System Model Consistency shown in Figure 2, and at showing how it is applied to the case study. When both task and system models have been built their consistency must be ensured at the lexical, syntactic and semantic levels. ...
Context 6
... example, using Petri net theory it can be automatically proved that the reconstructed net allows the place Countdown to be emptied and that there will be no token in place LightOff before the place CountDown is actually empty, stating that the light will be kept on. Figure 2 there are two boxes related to verification of models in the design life-cycle: the formal analysis one and the quantitative analysis one. In this section we describe the principles of the verification process. ...
Context 7
... propose a design life cycle supporting the use of formal notations both for task and system modelling. This life cycle (Figure 2) instanciates the life-cycle described in Figure 1 as a sub-cycle to support both task and system formal modelling and extends it to include task/system cross verification. The life cycle proposed in Figure 2 may start either by some rough model of the system (which may originate from the existing situation, e.g. ...
Context 8
... life cycle (Figure 2) instanciates the life-cycle described in Figure 1 as a sub-cycle to support both task and system formal modelling and extends it to include task/system cross verification. The life cycle proposed in Figure 2 may start either by some rough model of the system (which may originate from the existing situation, e.g. analysis of the paper documents in an information system analysis) or with an initial task model. ...
Context 9
... first start from an initial model of the system and then show two successive modifications of the system and task models. This corresponds to performing two iterations in the design life-cycle presented in Figure 2. The internal loop for the building of each model as well as the quantitative analysis box of Figure 2 are discussed in the section " Formal Verification of Models ". ...
Context 10
... first start from an initial model of the system and then show two successive modifications of the system and task models. This corresponds to performing two iterations in the design life-cycle presented in Figure 2. The internal loop for the building of each model as well as the quantitative analysis box of Figure 2 are discussed in the section " Formal Verification of Models ". ...
Context 11
... section aims at describing the content of the box entitled Maintain Task and System Model Consistency shown in Figure 2, and at showing how it is applied to the case study. When both task and system models have been built their consistency must be ensured at the lexical, syntactic and semantic levels. ...
Context 12
... example, using Petri net theory it can be automatically proved that the reconstructed net allows the place Countdown to be emptied and that there will be no token in place LightOff before the place CountDown is actually empty, stating that the light will be kept on. Figure 2 there are two boxes related to verification of models in the design life-cycle: the formal analysis one and the quantitative analysis one. In this section we describe the principles of the verification process. ...
Similar publications
Citations
... The two models are merged into a single representation, which is analysed to determine whether the system conforms to the task. The 'semantic consistency' of task and interface model is verified in the MICO method [146] by a deadlock analysis of the combined task and interface representations. This corresponds to deadlock analysis on the expression TM R || IM G , which verifies the feasibility of completing the task rather than that task sequencing is supported by the interface model. ...
... Few attempts have been made to explicitly define this relationship. A rare example, is the MICO method [146,147], mentioned above, which seeks to establish deadlock freedom for the combined task and interface behaviours. ...
This thesis investigates abstractions for modelling user interface software, discussing their content and their formal representation. Specifically, it focuses on a class of models, called formal interactor models, that incorporate some of the structure of the user interface software. One such abstract model is put forward. This model is called the Abstraction-Display-Controller (ADC) interactor model; its definition draws from research into user interface architectures and from earlier approaches to the formal specification of user interfaces. The ADC formal interactor model is specified using a specification language called LOTOS. Several small scale examples and a sizeable specification case study demonstrate its use. A more rigorous discussion of the ADC model documents its properties as a representation scheme. The ADC interactor is compositional, meaning that as a concept and as a representation scheme it applies both to the user interface as a whole and also to its components. This property is preserved when interactors are combined to describe more complex entities or, conversely, when an interactor is decomposed into smaller scale interactors. The compositionality property is formulated in terms of some theorems which are proven. A discussion on the uses of the ADC model shows that it provides a framework for integrating existing research results in the verification of formally specified user interface software. Finally, the thesis proposes a conceptual and formal framework for relating interface models to models of users task knowledge capturing some intuitions underlying task based design approaches. 2 Acknowledgements I wish to acknowledge the help of all my colleagues in the Department of Computer Science at Queen Mary and Westfield College, who provid...
This paper presents and discusses a generic navigation model built with Coloured Petri net (CPN) to support the analysis of
the navigation component in human interface design. The modelling and analysis is developed in the context of supervisory
control systems for industrial plants. The paper discusses the results of using this navigation model in an industrial application
case study.
The design of safety critical systems calls for advanced software engineering models, methods and tools in order to guarantee safety requirements that can put human life at stake. When the safety critical system encompasses a substantial interactive component, the same level of confidence is required towards the humancomputer interface. Conventional empirical or semi-formal techniques, although very fruitful, do not provide sufficient insight on the reliability of the human system cooperation, and offer no easy way, for example, to quantitatively compare two design options. The aim of this paper is to present a method with related tools and techniques for engineering the design and development of usable user interfaces for safety-critical applications. The specific application area which we will consider is air traffic control but most of the results will be valid for any application areas with similar requirements. KEYWORDS Formal specification, Interaction Techniques, Task Models, P...
