domain: sdv shs

text:
Pierre Chass
email: pierre.chasse@agroparistech.fr

Blatrix

Nathalie Frascaria-Lacoste

What is wrong between ecological science and policy 1 ?

Keywords: Conservation policy instruments, ecological knowledge, evidence-based policy, implementation, interdisciplinary research, policy process

Ecological research is highlighting different kinds of issues concerning biodiversity conservation policies. Based on a historical study on protected areas, we suggest that these issues are not caused by a lack of knowledge or technical tools but rather by a misuse of ecological knowledge during the implementation of policy instruments in part driven by a lack of understanding of the mechanisms underlying the policymaking process. We believe that determining the conditions under which ecological science can enlighten policy decisions is now necessary to address current biodiversity conservation issues. This can only be achieved through the promotion of interdisciplinary research.

Ecology Letters (2020) Numerous policy instruments 1 have been elaborated and implemented over the years to halt the decline of biodiversity loss. The most widely used policies (i.e. protected areas [PAs], protected species lists, and environmental impact assessments) aim to, among other things, prevent damage to species and ecosystems, decrease the drivers of biodiversity loss, ensure adequate genetic diversity, and maintain connectedness in related species populations. However, the ever-increasing rate of species extinction and ecosystem loss (D ıaz et al., 2019) calls into question the efficiency of such policy tools. In this context, a growing body of ecological literature seeks to assess the scientific relevance of biodiversity conservation instruments. For instance, numerous studies highlight the inefficiency of PAs to cover the full range of biodiversity [START_REF] Rodrigues | Effectiveness of the global protected area network in representing species diversity[END_REF][START_REF] Wiersma | Efficiency and effectiveness in representative reserve design in Canada: The contribution of existing protected areas[END_REF][START_REF] Jenkins | US protected lands mismatch biodiversity priorities[END_REF]. Others show the frequent absence of imperiled species [START_REF] Harris | Conserving imperiled species: a comparison of the IUCN Red List and U.S. Endangered Species Act: ESA's coverage of IUCN-listed species[END_REF] and the bias in taxa representation [START_REF] Cardoso | Habitats Directive species lists: urgent need of revision: Habitats Directive species lists[END_REF][START_REF] Dorey | Limitations of threatened species lists in Canada: A federal and provincial perspective[END_REF] in protected species lists. Moreover ecologists stress the inability to correctly assess the biodiversity impact of development projects (e.g. cumulative impacts, impacts on common or low detectable species) in environmental impact assessments [START_REF] Garrard | Incorporating detectability of threatened species into environmental impact assessment: Species Detectability in Environmental Impact Assessment[END_REF][START_REF] Bigard | The inclusion of biodiversity in environmental impact assessment: policy-related progress limited by gaps and semantic confusion[END_REF].

To address such issues, part of the ecological scientific community has produced conservation-oriented knowledge by, for example, elaborating technical tools to improve the design of PAs, refining knowledge about the state of species and populations needing protection, or searching for new methods to better evaluate the potential damage of development projects. Without denying the benefits of such approaches, this research suggests that the current lack of knowledge and/or technical tools is primarily responsible for our inability to solve conservation issues. However, in our view, this assumption is based on a misconception or misunderstanding about the nature of the policymaking processes responsible for the elaboration and implementation of policy instruments. Improving conservation-oriented knowledge without understanding how it is currently used by policymakers can undermine the efforts of the scientific community. Yet the study of policy processes and the way in which scientific results are integrated into decision-making processes represent a blind spot in ecological research as well as the journals in which such research is published.

Policy outcomes result from multiple policy decisions involving diverse actors, data, and rationales combined in a complex process that policy scientists label the policymaking process. This process includes the elaboration and selection of the policy instrument chosen to solve a particular issue as well as the implementation and evaluation of the selected solution. The outcome of a policy instrument is not only related to its relevance (i.e. the right allocation of means (e.g. PAs) to attain a specific goal (e.g. save particular ecosystems or species)), but also to the way in which this approach is concretely implemented (e.g. decisions concerning the location and management of PAs). Since a significant body of ecological scientific research is focused on improving policy tool implementation, we focus on this particular step. As in each phase of the policy process, scientific knowledge is only one of many factors (e.g. technical feasibility, tolerable cost, value acceptability, stakeholder interests and power) on which policymakers base their decisions. Policy studies demonstrate that the interaction of these factors often leads to highly contingent and irrational decisions on which relevant scientific and policy-oriented knowledge has little influence [START_REF] Cohen | A Garbage can model of organizational choice[END_REF][START_REF] Kingdon | Agendas, alternatives, and public policies[END_REF]. Careful deliberation and technical assessment of the best options are not the most common aspects influencing the implementation process. This suggests that producing knowledge and making it available are only one dimension among others in the process of solving a policy 1 In policy studies, public instruments are defined as 'the myriad techniques at the disposal of governments to implement their public policy objectives' [START_REF] Howlett | Policy instruments, policy styles, and policy implementation. National approaches to theories of instrument choice[END_REF]. issue. Considering these facts, we are convinced that a better understanding of the mechanisms driving the implementation of decisions is crucial in order to improve instrument efficiency in conservation policies. However, by mostly focusing on technical solutions, the scientific community often overlooks the key objective of biodiversity conservation issues.

This statement can be illustrated by briefly highlighting some preliminary results of our recent historical study conducted in France on the implementation decisions surrounding the creation of a specific kind of PA known as a National Nature Reserve (NNR). Our findings highlight that scientific interest (e.g. presence of a particular species or ecosystem, richness of a site), which was evaluated for each NNR project by a specific expert body, was necessary but far from sufficient to create a NNR. After acknowledging the scientific relevance of the project, the creation of NNRs was mostly influenced by various factors (e.g. the financial feasibility of the project, the strength of opposition; Figure 1). These results raise important concerns regarding the link between scientific knowledge and implementation decisions in the case of PAs.

Our study suggests that improving knowledge about the theoretical best location of PAs would not have changed the result of the decision-making process. In the end, the creation of PAs would still have depended on non-ecological factors, thus undermining any scientific efforts to build a scientifically based network. Moreover it is probable that this situation, most likely responsible for the observed bias in PA locations (Pressey, 1994;[START_REF] Gaston | The ecological performance of protected areas[END_REF][START_REF] Joppa | High and far: biases in the location of protected areas[END_REF], is generalisable to other biodiversity conservation instruments. The decisions relating to the integration of imperiled species in the protected species lists are likely to follow similar mechanisms, making scientific knowledge about population status of little value. Similarly, the biodiversity impact assessment is only one step in the process of land-use planning. Considering that in France, environmental impact assessment often occurs once the decision has been taken, its influence should not be overestimated compared to other factors. Increasing the accuracy of the methods does not necessarily imply a change in the way in which final policy decisions are implemented. If we only discussed these points for policy implementation, it is likely that such mechanisms also occur during the phases of elaboration and selection of the policy instruments. In such cases, our ability to solve the problem is less related to knowledge production and availability than to the identification of the obstacles responsible for the shallow use of scientific knowledge observed in policy decisions.

Without denying the importance of theoretical and disciplinary research, we believe that addressing the biodiversity crisis requires a change in the way scientific community produces ecological knowledge and interacts with stakeholders. For instance, we must not only ask if specific species, populations or ecosystems are at risk but rather how this knowledge can be made available to practitioners (e.g. protected area managers, policymakers) in a form and at a time when scientific data could compete with other socio-economic factors in the final decisions concerning the creation of PAs or the elaboration of protected species lists. We should not only try to improve models to assess biodiversity damage for land development, but also understand how the outputs of such tools concretely inform the stakeholders and influence their behaviour and decisions during the environmental impact assessments procedure. Integrating the relationship between knowledge and actors in ecological research is currently of primary importance. The particular relationship between science and policy that we discuss in this article has long been studied by the social sciences and policy studies (e.g. [START_REF] Nutley | Ad hoc reservations: Forward or backward steps in developing representative reserve systems?[END_REF][START_REF] Jordan | Embedding the concept of ecosystem services? The utilisation of ecological knowledge in different policy venues[END_REF], and we are convinced that increasing communication between these two communities is now crucial. Although some general mechanisms (e.g. presence of skilled intermediaries between science and policy to enhance the use of scientific knowledge in policy decisions) and approaches (e.g. legitimising, avoiding decisions, persuasion, justification) have been identified to describe the link between knowledge and policy decisions, this remains highly dependent on the policy domain, the level of Figure 1 Factors influencing policy decisions illustrated by the case of the creation of protected areas in France. We illustrated each type of factors by an example found in our historical study. Scientific factors are required but do not significantly influence the final policy decision. One of the questions raised in this article is how to improve the influence of the scientific factors and integrate it with other factors in policy decisions to improve the implementation of policy instruments.

© 2020 John Wiley & Sons Ltd. governance, and the policy instrument. What we have learned from our study is that the presence of opinions from scientists in expert bodies for PA implementation is not sufficient to build a scientifically based network. The ecological scientific community cannot be satisfied by the multiplication of scientific committees that play a minor role; other research must be conducted in order to better understand and improve the way in which the scientific community, stakeholders, and policymakers interact with each other. Determining the conditions under which science can realistically enlighten policy decisions must be specifically studied to address current biodiversity conservation issues. This inevitably begs the question as to the openness of ecological journals to the social sciences. Our goal here has been to illustrate the benefits from such cooperation, as we strongly believe that conservation issues will not be overcome without an interdisciplinary approach.

Graphical Abstract

The contents of this page will be used as part of the graphical abstract of html only. It will not be published as part of main.

Ecological research is highlighting different kinds of issues concerning biodiversity conservation policies. Based on a historical study on protected areas, we suggest that these issues are not caused by a lack of knowledge or technical tools but rather by a misuse of ecological knowledge during the implementation of policy instruments in part driven by a lack of understanding of the mechanisms underlying the policymaking process.

.

PEER REVIEW

The peer review history for this article is available at https:// publons.com/publon/10.1111/ele.13613.


Francis Jambon
email: jambon@ensma.fr

Patrick Girard
email: girard@ensma.fr

Yohann Boisdron

Dialogue Validation from Task Analysis

Keywords: Dialogue Validation, Task Analysis, ARCH Architecture Model, H 4 Architecture Model, Dialogue Component

HAL is

Introduction

As it is stated in [Fields, Merriam, & Dearden 1997], in recent past years, formal methods have mainly been used to allow designers to verify that software conforms to its specification. By the use of a single notation, many authors intended to demonstrate that some properties of the specification -more precisely, that would have to be in the specification-can be enforced by formal study, by the way of model checking or theorem proving.

Today, the field seems to be mature enough to reach a second step that deals with validation. It consists in analysing whether the design actually fulfils the original requirements for the system. In the article above mentioned - [Fields, Merriam, & Dearden 1997]-the authors suggest combining different formalisms which are right for some classes of properties. From descriptive and prescriptive viewpoints, the authors propose using formal methods as communication artefacts in the design process. At the end of their analyses, they conclude with a necessary focus shift from a semantic level to a methodological level.

Nevertheless, the focus of these approaches is always the design process. Even when requirements are explicitly involved, as for example when task analysis is emphasised, the goal is to provide more formal descriptions of these requirements, and to help analysis and design. This approach might be interesting in domains were tasks are well-defined. Unfortunately, that is not always the case. In the Computer-Aided Design area, systems cannot be described as a global task analysis. The reasons are twice. On the one hand, these systems must support a huge number of possible tasks -for example, some systems contain thousands of primitive functions, whose assembly generates up to a hundred of thousand tasks. On the other hand, "designers" are people whose creativity is a major characteristic. So doing, they cannot be restricted to a finite number of diagrams embedded in constrained tasks.

By the way, validation may be required for systems that cannot be exhaustively described by classical task analysis. Let us give two examples of such validation needs: (1) Choosing an existing system requires the purchaser to evaluate the possibilities of the system against his needs, when basic evaluation of every function of the system is not possible, the definition of scenarios to test on the system may be a solution. An "ad hoc" validation would be a good solution. (2) When a new release is distributed, it is important to know whether the system, despite of its new capabilities, is always capable to do what the users made with the previous release. So, an automated validation would be very interesting.

Our aim in this paper is to describe a method, which includes a task definition grammar and automated tools, in order to provide the designer of a CAD system for a practical validation of use cases. This paper is organised as follows: in Section 2, we explore some related approaches. In Section 3, we describe the context of Computer-Aided Design. In Section 4, we detail what kind of validation we want to achieve. At last, Section 5 focus on our case study.

Related Work

Many works in HCI use formal methods to check models of the actual systems. Model checking methods are a good illustration of this point. They are based on the evaluation of logical properties on the state transition system obtained from the evolving variables. Among these techniques, we can find temporal logics, Petri nets and so on. In the area of interactive systems, these methods are assumed to have first been used in formal verification of interactive systems [START_REF] Campos | [END_REF]. For example, [Abowd, Wang, & Monk 1995] verify user interfaces with SMV (Symbolic Model Verifier) using CTL (Computational Tree Logic), while [START_REF] Paternó | On the LOTOS use to describe graphical interaction[END_REF]] uses LOTOS to write interactors specifications, and analyse translated finite state machines using ACTL (Action-based Temporal Logic). [Brun 1997] develops a new temporal logic based on formalism, named XTL (eXtended Temporal Logic), to address interruptions in interactive systems' specification. Model checking is also used by Palanque et al. who model user and system by the way of objectoriented Petri nets -ICO- [Palanque, Bastide, & Sengès 1995]. The weakness of these approaches is that the running system has to be proved to conform to the model. More recently, [D' Ausbourg 1998] used the Lustre language for the automatic validation of user interface systems. In this case, the formal model is deducted from the UIL 2 description of the interface. Assuming the translator is proved, we can consider that we are really working on the actual system. Nevertheless, in most cases, formal models are only "modelling" the system, with no proof of the equivalence between the model and the system.

Using proof systems have quite similar drawbacks. They are systems where the model is described by variables, operations and invariants. The operations must preserve these invariants and a set of other properties (preconditions and/or post conditions). To ensure the correctness of these specifications, a set of proof obligations are generated and they must be proved. The proof system can achieve some of the proofs automatically. Among these techniques, we can mention Z, based on set theory [Spivey 1988], VDM, based on preconditions and post-conditions calculus [START_REF] Andrews | [END_REF], and B, based on the weakest precondition calculus [Abrial 1996 ;Dijkstra 1976]. In the Human-Computer Interaction field VDM and Z have been used to define atomic structures like interactors [START_REF] Duke | [END_REF], and Z and Object-Z are now used more extensively [START_REF] Hussey | [END_REF]. HOL (a Higher Order Logic Theorem Prover) has been used in the verification of User Interface specifications [Bumbulis, et al. 1996]. In these methods, we generally have the same problem of separating specifications and models of the system -on which proofs are conducted-from the actual system -which is only supposed to conform to the models. An exception can be found in [Aït-Ameur, Girard, & Jambon 1998], which uses the refinement methodology to reach the code level: the application itself is proved. Despite this large number of studies, formal methods are not largely used in HCI. One of the reasons is the formality gap [Dix 1991], i.e., the mapping from the requirements of the users and the formalism. In fact, even if we assume that formal models used for reasoning are relevant with final applications, formal methods suffer from a lack of readability and usability for non-specialists. Reading formal models is always hard, and the transition between the informal state of requirements and the formal model is quite difficult. Whenever formal approaches address task analysis [Markopoulos, Johnson, & Rowson 1997], such as ConcurrentTaskTree [Paternò, Mancini, & Meniconi 1997] or [START_REF] Palanque | [END_REF], constructed models are very far from task analysis models such as MAD [Scapin & Pierret-Golbreich 1990] or HTA [Shepherd 1989]. Moreover, while these methods are devoted to analysis and design, no real method or tool is developed to allow system users or experts in human factors to directly validate the systems.

Obviously, a strong need exists for validation techniques, able to ensure that a system "is really able to do that". We describe hereafter a couple of method and tool that allows it in the particular domain of Computer-Aided Design.

Computer-Aided Design Context

Our work has been made in the context of Computer-Aided Design. In this area, systems have specific topics like a huge number of functions, strong relations between functional core and presentation layer, and complex dialogues. In fact, they constitute one of the worse case of applications according to the taxonomy of interactive systems [Pierra 1995]. In this taxonomy, seven criteria have been developed to classify applications' needs. They deals with task arity (1) and structuring (2), domain objects autonomy (3) and structuring (4), source of control (5), mono/multi-user (6) and mono/multi modal (7) applications. The first four criteria are specially relevant for CAD applications. In this section, the terminology conforms to the Arch model [Bass, et al. 1992].

Task arity

Applications support different kinds of tasks. They can be mono-object tasks -each user task involves only one domain object-or multi-object tasks -each task involves several domain objects. Mono-object tasks may be supported by direct manipulation techniques, whatever multi-object tasks must be represented independently from the domain objects. Some dialogue component, of which the structure is independent from the object structure, must exist. As an example, MacDraw TM only supports monoobject tasks. Examples of multi-object tasks are provided by the drafting systems that enable creating lines as tangential to two circles.

Task structuring

Applications support atomic tasks when users must specify independently each of their tasks, the result of these tasks are recorded in the state of the domain-specific component. Conversely, applications support structured tasks when users may input in pre-order their task/sub-task hierarchy [Norman 1986]. The support of structured tasks needs recording the state of the dialogue independently from the state of the domain-specific component and the interaction component. Atomic tasks may be encapsulated either in domain objects or in interaction objects.

The following example (fig. 1) shows a typical structured task in which commands are in bold and <> represents conceptual objects that are picked up by the user. -5 -

We call create_circle_centre_radius a terminal task: it corresponds to one of the goals of the application, and projection a production sub-task: its role is to produce some information token, e.g., a position computed by projecting <point_1> on <line_2>, for the higher level terminal task.

Domain objects autonomy

The domain objects are autonomous when their presentation is mainly dependent on their state. In the opposite, they are relational when their presentation depends on the state of other domain objects. If these objects are autonomous, each of them may be mapped onto one interaction object that supports its rendering function. In the other case, rendering spaces must be provided. CAD objects are relational since that they are parts of complex models whose visualisation depends on the view the user selects.

Domain objects structuring

Domain objects are structured when several levels of objects, structured by aggregation, may be accessed by the user, whenever they are simple when domain objects are not part of other domain objects. When they are highly structured, designing one domain object may only be interpreted by the domain-side components. It requires a complete traversal of the system by the user-defined events.

Designing a specific model for CAD systems

So, complex interactive graphic applications are systems that support multi-object structured tasks and of which the conceptual objects are structured and relational objects. CAD systems are good examples of such applications. In these systems, conceptual objects are very precise: line are defined by their two end points and sweeps by their sweeped face and sweeping vectors. The tasks are multi-object tasks, users know these constraints and the system must provide for the specification of these constraints [Roller 1990]; the system supports expressions and the tasks are structured.

The conceptual objects are highly structured -a solid is the part inside of a closed shell, a shell consists of faces, etc.-and relational objects -the visibility of a point depends on every entity involved in the hidden surface process. Therefore, it does not exist any one to one mapping between conceptual objects and presentation objects, and when the designer picks up some graphical position, in order to designate some conceptual object, its intent may only be interpreted by querying the functional core.

Such systems are complex software systems, and it is well known, in Software Engineering, that these systems, whether they are designed according to object oriented techniques or not, must be first split into sub-systems. The Arch [UIMS 1992] model provides for such a macro-structuring of the system. But Software Engineering principles also require the interfaces, specification and relationships between these subsystems, to be precisely defined, and require each system to map to one unique -6 -abstraction. We have developed a specialisation of the Arch model for CAD systems, called the H 4 architecture [Guittet 1995].

The macro-structure of this model (fig. 2) conforms to the Arch model. Regarding its macro-structure, each component, but the domain-adaptor, is based on a specific hierarchy of units. Their role, interface and structuring criteria, have been precisely defined.

H 1

Interation toolkit component

Domain adaptator component

Questionaries implementation H 3

Domain specific component

Conceptual objects hierarchy In our purpose, let us emphasise the dialogue component. The only role of the dialogue component is to support the structured and multi-object task-level protocol. When using a multi-agent approach to specify this component, the agents involved in this component are very different from the classical interactive agents such as interactors [START_REF] Duke | [END_REF]. They do not only differ by the abstraction they implement -dialogue component agents implement one task or one category of related tasks such as defining geometrical 3D entities, defining 2D drafting presentation, producing geometric positions from geometric expressions, and so on)-but they also differ by their interface with the remaining part of the system. The main role of these agents, that we call control interactors, is to control, i.e., to trigger the functional core procedures. The only exchange of events is not sufficient to achieve this goal.

The state of the dialogue does not depend upon the output data that are issued by the functional core as a feedback of the triggered procedures: it only depends on whether or not the procedure fails. Therefore there is no reason to justify that the output flow from the domain adaptor component to the user should go through the dialogue component. This fact was acknowledged by the Seeheim model [Pfaff 1985], and it is still required by the class of applications we discuss in this paper.

Therefore, a control interactor does not provide rendering functions. To ensure the independence between tasks and sub-tasks, a special kind of event dispatcher -called a monitor-is needed to realise the circulation of events. It must be noticed that the development of dialogue interactors is completely different from the one of I/O interactors. Intended to support application specific tasks, they cannot be found in any predefined standard toolkit. Fortunately, they may be specified either by using a language approach [Olsen 1992], using an ATN approach [Woods 1970] or Petri Nets [Palanque 1992] in a pure declarative way. Therefore, they may be automatically generated and the different models proposed for dialogue specification [Green 1986] may be used to specify, in a modular way, each dialogue interactor behaviour. Do notice that this approach is close to the "transducer" approach from [Accott, et al. 1997]. The major difference consists in the main structure and the global behaviour of our model, which involves elementary "bricks", such as transducers.

Thanks to this architecture, the composition of complex dialogues is straightforward. Organising functions in separate dialogue interactors according to global levels of functions -picking, graphical expressions, geometrical creations, structuring, etc.-allows a good modular decomposition of the application. Then, the hierarchical organisation of the dialogue interactors, under the control of a monitor, allows free compositions of task/sub-tasks provided they do not belong to the same dialogue interactor.

A strong need for validation

Unfortunately, task analysis is very difficult in CAD systems. Because of the strong hierarchy of goals and sub-goals, which leads to strong hierarchy of tasks and subtasks. Task analysis of such systems leads to extremely large and flat trees. Reaching a given goal may be made by several methods with an equivalent result. Defining every possible path is unrealistic. In practice, the definition of CAD systems is made by incremental adjunction of new functions, which are integrated into the dialogue. A design lifecycle starting from a task analysis does not apply.

So, the need for validation is different from systems with well-characterised tasks, as for example air-traffic control or database management. In our approach, we do not address any ergonomic aspect of HCI applications. In the opposite, we focus on dynamic dialogue control. The question is "Is the system able to do that", in which "that" is expressed in a user-comprehensible way. We choose a notation that is in fact a restriction of MAD [Scapin & Pierret-Golbreich 1990]. This method allows us to define abstract scenarios of dialogues to be validated on the system.

A second requirement is to automate the validation. So, our objective is to produce test sequences from the scenarios' descriptions, and then, to validate the global execution of these test sequences onto the system itself. Test sequences are not an example of system execution, because no real value is provided. The test generation only produces dialogue tokens without associated value. In fact, we are only able to validate the dialogue of the interactive system. Let us give an example. Assume we need to test if creating a circle, which centre is the projection of a point on a segment, and which radius is half the distance between a second point and the extremity of the segment, is still possible in a new release (Fig. 3).

For user convenience, we want the system to allow either entering first the centre or the radius of the circle. The task is well-defined: the main goal may be split in two sub-goals, defining the centre and defining the radius, with no sequential relation between them. Each of them must then be expressed by a projection and a distance calculus. Expressing this task in MAD is straightforward. Of course, in real world applications, a huge set of these complex tasks may have to be checked, and so, the validation cannot be hand-performed. From this description, our system must be able to automate the generation of tests sequences and their validation on the system.

At this point, we can list the major requirements for our validation system: the designer's needs, expressed in terms of a goal and sub-goals hierarchy, lead us to use a task analysis as the main data input for our validation system. In addition to this, the designer should want to be sure that the user's goals are really achieved, i.e., correct side effects are the consequences of the user's actions. So, we have to check the system's links to the functional core of the system too. On a more technical point of view, the need for a complete coverage and the huge set of possible user interactions with the target system force us to develop an automated tool to ensure a realistic validation. We will show in the next section our validation principles, and their application on our case study in section 5.

Validation Principles

This section deals with the validation principles, whereas the next one ( 5) is dedicated to the tools used to ensure the validation of our case study -a prototype of a CAD application. In this section, we first detail the HCI properties we want to validate, and then, we describe the validation methodology starting from task analysis to interaction sequence generation. -9 -

Usability Properties

As detailed in the previous section of this paper, our research focuses on CAD systems. These systems usually gather a very important set of functions. In such context, our aim is twofold: we want to make sure that all these functions are reachable for the user, and consistent with the domain objects. So, following Dix and al. [Dix, et al. 1998] in §4.3.3, we have to check both Reachability and Task completeness.

Reachability

On the one hand, our goal is to check that the system implements the full set of user's tasks given in the user interface specifications. More precisely, we want to make sure that the system accepts and recognises the sequence of user interactions -command selection, object designation, etc.-used to perform each task given in the specifications, and each of its variants. So, from the A. Dix and al. point of view, we want to ensure Reachability which "refers to the possibility of navigation through the observable system states".

Reachability is a common usability principle. This principle may be checked by the way of verification of formal specifications. As for example, P. Palanque et al. use an object-oriented Petri nets formalism and a model checking method to prove some Reachabily properties [Palanque, Bastide, & Sengès 1995]. The Y. Aït-Ameur et al. approach is quite different: they use the B method and theorem proving to ensure this principle [Aït-Ameur, Girard, & Jambon 1998].

Our approach in this paper is significantly different: we want to validate the Dialogue Controller of an existing application. We do not provide any model of the final system -in fact we use the binary code of the Dialogue Controller itself. We just need a model of the user tasks performed in an independent way by a specialist of human factors. Another difference is in the scale: we need a complete coverage validation of the system, not only partial proofs.

Task completeness

On the other hand, we want to ensure that the modifications of the domain objects are consistent with the user's tasks. In other words, we must show that the side effects of the user's tasks on the Functional Core can be linked with the user's goal, i.e. the system does exactly what the user wants it to do. So, from the A. Dix and al. point of view, we want to ensure Task completeness which "refers to the level to which the system services can be mapped onto all the user tasks".

Task completeness is a usability principle rather difficult to prove, because one has to bridge the gap between user's goals and system Functional Core. In our approach, we want to check that the Functional Core methods called by the Dialogue Controller during user interaction are consistent with the goal and sub-goals defined in the task analysis. This way, we only make the validation on the Dialogue Controller. So, to ensure full Task completeness, we make the assumption that the Functional Core methods are functionally correct. Such validation of the Functional Core can be carried out separately.

Task Model

The first step of our validation method is a task analysis, which is supposed to be performed by a specialist in human factors. This task analysis gathers all the possible interactions performed by the user to achieve his goal. And in CAD systems, these user's goals are creations of conceptual objects in the model, modifications or requests for information on these objects. Typical user's tasks of CAD systems -see §3-are structured. They can be modelled by a classical task/sub-task tree corresponding to a goal/sub-goal hierarchical analysis. In our task model, as in MAD, sub-tasks can be re-used, but cycles and recursivity are forbidden. Moreover, the set of temporal relationships between tasks is restricted to sequence, alternative, and order independence. So our task model is limited to this set of relationships.

We defined a new and simple task model for our kind of applications. This model can be considered as a simplified version of HTA [Shepherd 1989] or MAD [Scapin & Pierret-Golbreich 1990] notations underlying model. The resulting task model will enable us to generate all the possible user's interaction sequences.

User's Interaction Sequences

It is not straightforward to validate the Dialogue Controller directly from a user's tasks model. However, it is easy to check if a sequence of user's interactions is valid: one just have to do it with the system and see what happened. Our validation method follows a similar principle: we validate the user's interaction sequences one by one.

To do so, we use the task analysis to generate all the possible interaction sequences. These sequences are automatically generated by the way of a classical tree traversal -cycles and recursivity are forbidden from our task model. All the possible sequences are generated, so, we ensure a complete coverage validation of the application. These sequences are finally sent to the system to be validated.

Dialogue Component Validation

We assume that the target system has been implemented with the Arch architecture model [START_REF] Bass | A Metamodel for the Runtime Architecture of an Interactive System[END_REF]]. In fact, our case study has been implemented with the H 4 architecture model -see §3.5-which is a variant of the Arch model. Our aim is to validate the Dialogue component of the final application.

As shown on figure 4, the principle of our validation method is to generate the complete set of possible user interaction sequences from the task analysis. Then, this set is injected in the Dialogue Component of the real application via a modified Presentation Component. Then, the application is launched and the Dialogue -11 -Component calls to the Domain Specific Component -the Functional Core-via the Domain Adaptor Component are intercepted, and compared with the user's goal. If they match exactly, the sequence of interactions is assumed to be valid.

Case study

This section deals with a validation example. We apply the validation principles exposed in the previous section (4) to a case study: MiniCAD, an application of the GIPSE system. In this section, we first describe the main features of MiniCAD, and then we relate the validation process from task analysis to error trace generation.

Test Application

The GIPSE system is a prototype of a CAD application with an integrated Programming by Example Interface Generator [START_REF] Patry | [END_REF]. GIPSE is implemented with the H 4 architecture model described in §3.5. We use a part of this system, called MiniCAD, as our case study. Briefly speaking, the MiniCAD application implements basic CAD functions -objects drawings, objects selections, etc.-and enables structured dialogue modes, but does not include any programming by demonstration generator.

Although MiniCAD is a prototype with very little functions available -compared with a real world CAD system-a huge set of user interactions are possible. As a consequence, the system cannot be validated "by hand". So, we develop a tool to do so. We test this tool on the complex structured task previously described: «creating a circle, which centre is the projection of a point on a segment, and which radius is half the distance between a second point and the extremity of the segment» (see fig. 3). For user convenience, the system allows the user either entering first the centre or the radius of the circle. The circle's radius can also be given in a simpler way by typing directly its value.

Task Description Grammar

The task of creating a circle can easily be written down by a specialist in human factors thanks to a graphical formalism, like HTA or MAD. We use a simplified version of this latter formalism to express the task of creating a circle. MAD [Scapin & Pierret-Golbreich 1990] is a graphical formalism based on temporal relationships and task/sub-task decomposition. We use as temporal relationships the more relevant operators of an enhanced version of MAD, MAD* [Hammouche 1995]. Among these operators, we use:

• AND which means that the tasks must be executed both in any order ;

• OR which means that only one of the tasks must be executed ;

• SEQ which means that the tasks must be executed both, and in sequence.

The figure 5 shows the resulting specification. In this diagram, the sentences in rectangles are tasks whereas sentences in Italics are final atomic tasks directly executed by the user on the interface, as selecting an object by a mouse click or a typing of a number with the keyboard. -13 -Of course, our sequence generator cannot directly interpret the diagram on figure 5. So, we define a task grammar. Both representations -graphical and text-are equivalent. The tool to translate the graphical representation to the textual one is not yet implemented. Consequently, the task description shown on figure 6 has been translated manually from the MAD description (fig. 5). -14 -In our task grammar, the tasks and sub-tasks are numbered. Each task (resp. subtask) description begins with the keyword task (resp. sub-task) and ends with the same keyword with the word end before. Then, three types of fields must be fulfilled:

• The command field refers to the command activated by the user, for example, the menu's item he must select in order to accomplish his task ; this field is also used to check the Functional Core calls ; • The result field is the type of conceptual object the task or sub-task is supposed to produce, for example, the sub-task extremity (of a segment) command returns a position;

• The parameter field gives information about the sub-tasks of the present task:

-First, it gives the type of the expected conceptual object (position or real for example); -Second, it gives the possible sub-tasks, which can be either the number of a sub-task (<11> for example) or an atomic action (a_position or a_real for example); these sub-tasks are supposed to produce the conceptual object type expected ; -Third, a temporal operator can be used to set the relationships among the order of parameters -in fact sub-tasks-or the use of more than one sub-task as a parameter. These operators are equivalent to MAD operators: "&" is equivalent to AND, "/" is equivalent to OR, and the SEQ operator is default.

Dialogue Sequences Generator

From the task analysis, we can extract the user's interaction sequences. Our task model does not allow neither recursivity nor cycle, so, the task/sub-task analysis specify a finite number of user's interaction sequences. Consequently, we can achieve a complete coverage validation of the Dialogue component of the MiniCAD application.

We develop a tool to extract automatically all these possible interaction sequences. The task analysis (fig. 6) gives four possible interaction sequences. We reprint two of them on figure 7. The syntax of the interaction sequences in similar to the task grammar syntax, except that each sequence begins with the keyword SEQUENCE and ends with the keyword END_SEQUENCE. When commands are issued by the user (create_circle or select_point for example) the "COMMAND :" sentence is added before the command name. When the user's actions are atomic actions (a_position or a_real for example), their names are directly printed. [Fields, Merriam, & Dearden 1997] define focus shifts as new trends for works in DSV-IS papers. In the specific point of validation, our proposal addresses many of them. Shifting from prescription to description, we propose a simple way to describe examples of tasks we want the system to be able to do. Starting from that point, a validation can be done: the analysis performed can determine whether or not the system supports the task. So doing, we also address the need for shifting from verification to validation.

Conclusion

Shifting from general to specific notations allows a great operability. Our model of task description is simple, and allows the automation of the validation process. We are able to perform validation of an existing dialogue component after its design. Moreover, the capabilities of the test platform enable designers to check quickly, while developing a new software version, a huge number of sequences. Doing so, they might prove that a new version is backward compatible with the previous one.

Nevertheless, many points have to be enhanced. The link between terminal tasks and functions of the CAD system is hand-made. With the possible great number of functions (so terminal tasks), a more automated mechanism to establish this link is needed. Methods such as Programming by Demonstration [Cypher 1993] might be used to enforce the usability of our tools. In the same way, a graphical tool might be preferable to pure textual methods. At last, the adaptation of this methodology to other application fields might also be interesting. We also plan to generate interaction sequences not at the Presentation Component level but at a lower level, i.e., at the Interaction Toolkit Component level in order to reduce system code modifications.

  Figure 1: A structured task

  Jambon F., Girard P., & Boisdron Y. Dialogue Validation from Task Analysis. Eurographics Workshop on Design, Specification, and Verification of Interactive Systems (DSV-IS'99), Eds. D.J. Duke & A. Puerta. Springer-Verlag, Universidade do Minho, Braga, Portugal, 2-4 June 1999, pp. 205-224.

Figure 2 :

 2 Figure 2: The H 4 architecture model

Figure 3 :

 3 Figure 3: Creation of a circle

  Jambon F., Girard P., & Boisdron Y. Dialogue Validation from Task Analysis. Eurographics Workshop on Design, Specification, and Verification of Interactive Systems (DSV-IS'99), Eds. D.J. Duke & A. Puerta. Springer-Verlag, Universidade do Minho, Braga, Portugal, 2-4 June 1999, pp. 205-224.

Figure 4 :

 4 Figure 4: Dialogue component validation principle in the Arch model This validation principle considers the Dialogue Component as a black box. No assumptions are made about the internal architecture of this component. It must onlyto respect the Application Programming Interface of both the Presentation and the Domain Adaptor Components which is reused by the modified components. So, it is possible to use the binary code of an existing application directly, provided the programming language accept post-compilation linkage.

Figure 5 :

 5 Figure 5: Task of creating a circle in a simplified version of the MAD formalism.

Figure 6 :

 6 Figure 6: Task of creating a circle in our task grammar.

Laboratory of Applied Computer Science, National School of Engineers in Mechanics and Aerotechnics

Jambon F., Girard P., & Boisdron Y. Dialogue Validation from Task Analysis. Eurographics Workshop on Design, Specification, and Verification of Interactive Systems (DSV-IS'99), Eds. D.J. Duke & A. Puerta. Springer-Verlag, Universidade do Minho, Braga, Portugal, 2-4 June 1999, pp. 205-224.

Test Platform

Our case study is the MiniCAD application (fig. 8). MiniCAD was developed in the ADA95 language with the H 4 architecture model. Our test platform re-uses the Dialogue Component of the MiniCAD application to validate it. In order to make the mapping between the command names of the task analysis done by the human factors specialist -in English in our case study-and the names of functions implemented by the MiniCAD programmer -in French in our case study- -16 -we need an association table. This table embodies the links between terminal tasks and functions of the CAD system. This table is in fact the only formal link between the human factor domain and the Application Programming Interface (API). The filling of this table needs cooperation between the designers. This table are to be filled only once in the design process, because the task names as well as the API are usually reused for new application versions. It must be update if new tasks are added or API are changed. Figure 9 gives an excerpt of the table we use, in which task analysis command names are on the left side of the "=" symbol, whereas the API methods are on the right one. • The Presentation Component takes the simulated user's interaction sequences and the association table files as inputs, makes the mapping between the sequences and API functions -tokens in the H 4 model-and then, activates the Dialogue Component. • The Domain Adaptor Component has the same API as the MiniCAD application but does not call the Domain Specific Component. This module compares the Dialogue Component calls to the expected commands. When the command called are not the expected ones, or if no command has been called, the test system produces an error for the corresponding sequence. Every error is written in the output file. -17 -H 1

Interation toolkit component

Domain adaptator component

Questionaries implementation H 3

Domain specific component

Conceptual objects hierarchy H 2

Dialogue component

Execution Traces

We have identified three major validation errors:

• The method called by the Dialogue Component via the Domain Adaptor

Component does not exist in the Domain Specific Component API ; • The method called is not the expected one, e.g., a rectangle is created, whereas a circle is expected.

• No method is called by the Dialogue Component at the end of the sequence. These errors may be symptoms of either task analysis error or Domain Specific Component bugs. So, they can be rather difficult to interpret by the design team. However, our main goal is to check a huge number of interaction sequences to validate the system as a whole, i.e., to answer the designer "yes all is OK" or "no, there is a problem".


domain: phys chim spi

text:
Paul Robineau

Rodolphe Jaffiol

Cyrille Vézy

Micropatterning of quantum dots monolayer for FRET-based

Abstract

During adhesion and migration, cells interact with their environment through various physicochemical interactions and forces through the cytoskeleton to focal adhesion points (FAP). Such highly specific attachments between the cell and the extra-cellular matrix (ECM) are mainly controlled by integrins, in cooperation with many other proteins.

Various optical tools have been used to study cell adhesion and migration (RICM, FLIC, STED, PALM, etc.) with the target of imaging spatio-temporal dynamics of FAP on living cells with nanometric axial resolution. Secondly, geometrical and mechanical constraints provided by in situ micro-environment must be mimicked in single-cell adhesion studies if one does not want to produce artifactual results [START_REF] Théry | Micropatterning as a tool to decipher cell morphogenesis and functions[END_REF].

We thus propose a FRET-based imaging technique integrating in its core this micro structuration necessity: Non-radiative Excitation Fluorescence nanoscopy. Using a monolayer of quantum dots as donors, NEF imaging allow selective observations of membrane components and quantitative measurement of cell-substrate distances, reaching a nanometric axial resolution and without high laser irradiance nor long time acquisitions [START_REF] Riachy | Nanometer-Scale Resolution Achieved with Nonradiative Excitation[END_REF]. We recently have conducted quantum dots micropatterning to organize the monolayer spatially. This serves as a scaffold for surface structuration of the adhesion protein (fibronectin) specifically recognized by the integrins.

The resulting surface have two main interests: a) minimize background noise of illumination b) control cytoskeleton contractibility and therefore cell shape and motility We anticipate it will help for easier rigorous analysis of cell adhesion and migration; in particular when investigating the effect of cells exposition to integrins' antagonists developed in anticancer therapy.

Micropatterning of quantum dots

  SpaceInt is co-financed by the European Union. Europe is committed in Champagne-Ardennes with the ERDF Operational Program 2014/2020 European Regional Development Fund

F

  ) // 1 px = 113.23 nm Contact : paul.robineau@utt.fr paul-robineau.github.io L2n -Light, nanomaterials & nanotechnologies. EMR 7004 CNRS Team Nanobiophotonics UTT -University of technology of Troyes 12 rue Marie Curie -CS 42060 -10004 TROYES CEDEX Tél. : (33) 03 25 71 76 00 | Fax : (33) 03 25 71 76 76 This work have been funded by the Aube Departmental Council Our special thanks for our colleagues Thomas PONS and Jérémie BEAL DA : Donor emission with Acceptor presence F D : Donor emission without Acceptor presence R 0 6 : Distance of 50% transfer efficiency κ 2 : Orientation factor n : Refractive index QY D : Quantum Yield of the Donor Easy design: any digital image (1824×1140 px) can be projected onto the glass substrate ×10 Objective ≈ 0,5 µm/px S1813 min UV dose = 1,6 mJ/mm 2 Proof of concept for proteins of adhesion scaffold Block of 8 Imidazole cycles for chelation complexes with QDs (FRET Donor) Polymer core: Block of 26 sulfobetaine (water solubility + reducing non specific adhesion)