Mathieu Magnaudet

Stéphane Conversy

Magnaudet Martin Conversy

Causette: User-Controlled Rearrangement of Causal Constructs in a Code Editor

Keywords: CCS CONCEPTS, Human-centered computing → Visualization toolkits, User interface programming, • Software and its engineering → Development Interaction programming, code visualization, causality

Figure 1: Interaction 2. Reordering FSMs: (a) The user hovers over on a declaration of a state (blue) which highlights the in and out transitions (green); (b) the user clicks on the state, and the system animates a rearrangement of the transitions; (c) the new y-ordering of the statements matches the causal relationships being analyzed (in-transitions above state above out-transitions).

INTRODUCTION

Programmers of interactive systems e.g. Graphical User Interfaces that react to input events from the keyboard, the mouse, or the touchscreen, face specific challenges due to the interrelated behavior of numerous components and uncontrolled, unpredictable flow of external events [START_REF] Letondal | Usability requirements for interaction-oriented development tools[END_REF]. A number of textual programming languages provide dedicated language constructs to tackle the complexity of writing interactive programs. Some of them propose reactive constructs that avoid the need to write code for updating outputs when the inputs of a computation change [START_REF] Wan | Functional Reactive Programming from First Principles[END_REF]. Others use traditional object-oriented constructs to describe state-based behavior [START_REF] Appert | SwingStates: Adding State Machines to the Swing Toolkit[END_REF]. Conceptual frameworks, syntaxes and tools have been proposed for user interface development [START_REF] Myers | The amulet environment: New models for effective user interface software development[END_REF], natural programming [START_REF] Myers | Natural programming languages and environments[END_REF], interaction-oriented programming [START_REF] Magnaudet | Djnn/smala: A conceptual framework and a language for interaction-oriented programming[END_REF], or web programming [START_REF] Berry | HipHop.Js: (A)Synchronous Reactive Web Programming[END_REF]. Still, most approaches rely on code split over different source files, each dedicated to the description of interactive behavior at a local level. This breakdown hinders the programmer's ability to understand interactive behavior. As a consequence, interaction code is hard to debug and maintain.

The problem: understanding causality

We believe that developers should be able to follow and understand the causal chains to assess whether the code of an interaction will behave correctly. Following the philosopher of science W. Salmon [START_REF] Salmon | Scientific Explanation and the Causal Structure of the World[END_REF], we take causality as a spatio-temporal process involving the transmission of "information, structure and causal influence". We consider that two processes A and B have a causal relationship if A always precedes B and B occurs every time A occurs. In other words, "causality" means that the execution of a piece of code follows the occurrence of an input event. Causal chains are a set of elementary causal relationships that form a chain.

General-purpose and interaction-oriented programming languages provide programmers with "causal programming constructs" i.e. syntactic expressions that establish a particular causality between two pieces of code. Some of Java Swing, Qt, SwingStates [START_REF] Appert | SwingStates: Adding state machines to the swing toolkit[END_REF] or QML APIs and syntaxes can be considered as causal constructs. With Java Swing, the registering of a listener callback is a causal construct expressed with source.addListener(listener). With Qt, the connection between a signal and a slot is expressed with ob-ject1.signal.connect(object2.slot). With SwingStates, the transition between two states is expressed with Transition t = new PressOnShape(BUTTON1, "»menuOn") while with QML a transition is expressed with DSM.SignalTransition {target-State:finalState signal:button.clicked}. In Smala [START_REF] Magnaudet | Djnn/smala: A conceptual framework and a language for interaction-oriented programming[END_REF], the binding between the activation of two processes is expressed with p1->p2, an assignment with p1=:p2, a dataflow with p1=>p2 and a transition with s1->s2(event).

Such causal constructs may have been defined by a programmer with the same source or destination, over multiple code locations. They thus implicitly form a "causal chain". The challenge we tackled here is the programmer's ability to understand such causal chains. Since interaction is by nature dependent on external events that might occur in any order, understanding an FSM requires taking into account multiple causal chains. Similarly, to understand a dataflow of connected components, developers must follow the flow of data across multiple code locations. Few tools have addressed these difficulties in past work.

Causette

Our goal is to better support programmers when they seek to understand the causal chains involved in interactive programs. Here we introduce Causette 1 , a set of interaction techniques and representations of textual code. With Causette, a programmer is notably able to bring together the causal relationships that are far away from each other in the source code, with a visual ordering consistent with the conceptual causal order (see fig. 1). Our contributions are:

(1) The elicitation of four design principles (4.2) we relied upon to design four interactions (4) that rearrange interaction code representations to support some interaction programming tasks; [START_REF] Appert | SwingStates: Adding state machines to the swing toolkit[END_REF] The demonstration of the interactions in relevant scenarios (4); [START_REF] Berry | The Foundations of Esterel[END_REF] The evaluation of the interactions with a semi-controlled experiment with 12 professional programmers (5). 1 Causette is a pun from the French given name Cosette spelled like Causality, and evoking "*-et" HCI terms such as "widget" or "applet".

RELATED WORK

We first introduce the terminology we use. As much as functional programming is about programming functions that run within a program that compute results [START_REF] Landin | The next 700 Programming Languages[END_REF], interaction programming is about programming interactions that run within an interactive program i.e. that reacts to external events such as human input or network data reception. Interaction code is the code devoted to the description of interactive programs. Similarly, as much as objectoriented programming [START_REF] Kay | The Early History of Smalltalk[END_REF] languages have been designed to suit the programming of "objects", interaction-oriented [START_REF] Letondal | Usability requirements for interaction-oriented development tools[END_REF] programming languages and frameworks [START_REF] Chatty | Programs = data + algorithms + architecture: Consequences for interactive software engineering[END_REF][START_REF] Letondal | Usability requirements for interaction-oriented development tools[END_REF][START_REF] Myers | The garnet user interface development environment[END_REF] have been designed to suit the programming of "interactions". Causette is informed by research in three areas: interaction programming and causality, augmenting textual code, and code representation and animation.

Interaction programming and causality

In the field of interaction-oriented programming, the causal challenges related to interaction code have been pointed out [START_REF] Chatty | Programs = data + algorithms + architecture: Consequences for interactive software engineering[END_REF][START_REF] Letondal | Usability requirements for interaction-oriented development tools[END_REF][START_REF] Myers | Improving program comprehension by answering questions[END_REF][START_REF] Myers | The garnet user interface development environment[END_REF], but few tools have addressed it. The WhyLine debugger [START_REF] Ko | Designing the Whyline: A debugging interface for asking questions about program behavior[END_REF][START_REF] Ko | Debugging reinvented: Asking and answering why and why not questions about program behavior[END_REF] provides developers with answers to a why?-question regarding a phenomenon they perceive on a user interface i.e. a causality question. Outside the scope of interaction programming, many papers have studied developers' needs, particularly when debugging [START_REF] Latoza | Developers ask reachability questions[END_REF][START_REF] Sillito | Questions programmers ask during software evolution tasks[END_REF][START_REF] Von | Program understanding behavior during debugging of large scale software[END_REF] and proposed new debugging methods, notably in the field of functional reactive programming [START_REF] Salvaneschi | Debugging for reactive programming[END_REF][START_REF] Salvaneschi | Debugging reactive programming with reactive inspector[END_REF]. However, few of them have been focusing on the debugging of interactionoriented programs or causal relationships. Aside the field of programming, some work in information visualization have studied the representation of causality. This includes the exploration of graphs and diagrams to visualize causality [START_REF] Elmqvist | Causality visualization using animated Growing Polygons[END_REF][START_REF] Elmqvist | Growing Squares: Animated Visualization of Causal Relations[END_REF][START_REF] Vo | Visual Causality: Investigating Graph Layouts for Understanding Causal Processes[END_REF], applied to statistics or to the modelling of distributed systems. However, typical graph layouts may not be appropriate to follow the control flow of an application, as they force the readers to visually hop from node to node in arbitrary directions. Those limits have been addressed by tools like DA4Java [START_REF] Pinzger | A tool for visual understanding of source code dependencies[END_REF] for Java source code. To make the graph more readable, a set of features allows to incrementally compose graphs and remove irrelevant nodes and edges from graphs.

Augmenting textual code in IDEs

Several issues with program understanding motivate work on textual code augmentation. One issue is related to file-based IDEs. The literature points out how IDEs lack effective support to browse complex relationships between source code elements. Developers are often forced to exploit multiple user interface components at the same time [START_REF] Ko | An exploratory study of how developers seek, relate, and collect relevant information during software maintenance tasks[END_REF], making the IDE "chaotic" [START_REF] Minelli | Taming the IDE with fine-grained interaction data[END_REF]. To prevent timeconsuming navigation between files, CodeBubbles [START_REF] Bragdon | Code bubbles: Rethinking the user interface paradigm of integrated development environments[END_REF][START_REF] Bragdon | Code bubbles: A working set-based interface for code understanding and maintenance[END_REF][START_REF] Steven | Code bubbles: A practical working-set programming environment[END_REF][START_REF] Reiss | Tool demonstration: The visualizations of code bubbles[END_REF] offers an integrated development environment for Java. With Code-Bubbles, programmers can build working sets composed of code fragments (like methods, small classes, notes, documentation, etc.), displayed in a separate bubble or lightweight window. Programmers can rearrange the layout of the bubbles to create a logical context. VSCode offers a functionality called CodeLens [START_REF]CodeLens[END_REF]: an actionable contextual information interspersed (from different files) in the edited code. It differs from Causette in terms of interaction technique (pop-up window), type of information (e.g. editing history) and targeted code (imperative code). In the same line of thought, to 2 overcome the limits of navigation in IDEs, Hunter [START_REF] Dias | Evaluating a visual approach for understanding javascript source code[END_REF] is a tool for the visualization of JavaScript applications that provides a set of coordinated views that include a node-link diagram that depicts the dependencies among the components of a system, and a treemap that helps programmers to orientate when navigating its structure. We used a different strategy to bring related chunks of code closer, by inserting "remote" code into the currently edited one. Similarly, "code portals" [START_REF] Breckel | Embedding programming context into source code[END_REF] embed various types of context information uniformly into the main source code view in proximity to the relevant source code. "Fluid source code views" [START_REF] Desmond | Fluid source code views[END_REF] consists of insertions of relevant remote lines of code in the edited file. The aim is to provide the programmer with the control and data flow directly in the edited code, and thereby minimizing navigation. But it is applied to object-oriented programming and relies on displaying hierarchies of methods. SimplyHover [START_REF] Jbara | SimplyHover: Improving comprehension of else statements[END_REF] is a plug-in for Eclipse that brings the "if" condition next to its "else" counterpart.

Theseus is an IDE extension that visualizes the run-time behavior of a program within a code editor by displaying real-time information about how the code actually behaves during execution [START_REF] Lieber | Addressing Misconceptions about Code with Always-on Programming Visualizations[END_REF]. It provides the programmer with the number of calls of a particular function and a collapsible tree of calls. Like Causette, Theseus augments the textual code being edited, by displaying the number of calls to the left of the function header. By contrast, we target another type of information: the causal activation chain. We also focused on state activations in an FSM, but used a quantitative representation of activation recency instead of a numerical representation of the number of calls. We took Theseus evaluation method as inspiration for the evaluation of Causette.

Code representation and animation

Causette builds upon previous work about graphical code representations. For example, InterState [START_REF] Oney | InterState: A language and environment for expressing interface behavior[END_REF] is a programming language and environment that supports developers in writing and reusing user interface code. InterState mixes texts and graphics to represent interactive behaviors using a combination of FSMs and constraints. It also provides programmers with a visual notation to facilitate code navigation and understanding. SwingStates [START_REF] Appert | SwingStates: Adding state machines to the swing toolkit[END_REF] makes a clever use of Java anonymous inner classes to describe FSMs. However, the specification of the interactions is done at a local level, and SwingStates does not offer support for understanding causal chains.

From a more theoretical standpoint, source code shares a lot with a text to be read [START_REF] Darrell R Raymond | Reading source code[END_REF]. There is a distinction made in the literature between textual and visual information. But it is not clear-cut and it is not obvious to favor the latter or the former. Visual programs can even be harder to read than textual programs [START_REF] Green | When Visual Programs are Harder to Read than Textual Programs[END_REF]. The cognitive dimensions of notation is a framework that helps designers analyze interactive tools, including programming environments and languages, may they be textual or graphical [START_REF] Blackwell | Chapter 5 -Notational Systems -The Cognitive Dimensions of Notations Framework[END_REF]. The Physics of Notations framework focuses on the properties of graphical notations [START_REF] Moody | The "Physics" of Notations: Toward a Scientific Basis for Constructing Visual Notations in Software Engineering[END_REF]. Unifying textual and visual languages shows that both types have much in common and that both should rely on the capability of the human visual system [START_REF] Conversy | Unifying textual and visual: A theoretical account of the visual perception of programming languages[END_REF]. More recent work on code reading is relevant to Causette. There have been studies on the way programmers read natural language text and code. Some results indicate that code reading is less linear [START_REF] Busjahn | Eye Movements in Code Reading: Relaxing the Linear Order[END_REF][START_REF] Peitek | What drives the reading order of programmers? an eye tracking study[END_REF] than prose reading because programmer focus on the program execution flow, or that code regularity (same structures repeated time after time) reduces code reading complexity [START_REF] Jbara | On the effect of code regularity on comprehension[END_REF]. The effect of ordering on comprehension has been studied [START_REF] Jbara | On the effect of code regularity on comprehension[END_REF], with a focus on the ordering of methods. It motivates design principles for Causette, in the sense that it invites to support the matching between linearity of reading order and the readability of the execution flow.

An environment and language suitable for programming should allow one to "follow the flow" and "see the state" [START_REF] Victor | Learnable Programming-Designing a programming system for understanding programs[END_REF]. The author designed several interaction techniques and representations to support those two concerns. However, they involved following an imperative flow and data states, while Causette targets the interaction flow or the interactive state. The author claims that the features of the environment are less important than the particular ways of thinking they support. This is what we strive to do for interaction programming: provide programmers with interactions and representations to better apprehend causal relationships.

To augment and represent textual code efficiently, we used animations. Text animations are useful to understand changes of information display [START_REF] Chevalier | Animations 25 Years Later: New Roles and Opportunities[END_REF]. Gliimpse [START_REF] Dragicevic | Gliimpse: Animating from markup code to rendered documents and vice versa[END_REF] or Diffamation [START_REF] Chevalier | Using text animated transitions to support navigation in document histories[END_REF] share with our work the use of animations in code: they offer animated transitions to different parts of text (latex markup code and rendered document in Gliimpse, revision history of textual documents in Diffamation). Gliimpse allows users to check and navigate through the code, without leaving the text editor. However, Gliimpse animates from code to rendering, and not from code to code. Finally, animations of word-scale graphics within texts also enable to follow the rearrangement of graphics and make them easier to compare thanks to a vertical alignment [START_REF] Goffin | Exploring the placement and design of word-scale visualizations[END_REF].

THE SMALA LANGUAGE

As mentioned in the related work, the problem of describing and understanding interaction code has been partly addressed with the design of specific, interaction-oriented textual languages. We used such a language, Smala, in the remaining of the paper, as it eliminates some interaction programming problems, like the "spaghetti of call-backs" [START_REF] Myers | Separating application code from toolkits: Eliminating the Spaghetti of call-backs[END_REF]. Our interaction techniques were designed for this language, to overcome the remaining difficulties (the techniques may be applied to other languages or toolkits such as Qt). This section briefly describes Smala to help the reader understand the code examples.

Smala is a textual, interaction-oriented programming language dedicated to the development of highly interactive software. It takes inspiration from classical reactive languages such as Lustre [START_REF] Halbwachs | The Synchronous Data Flow Programming Language LUSTRE[END_REF] or Esterel [START_REF] Berry | The Foundations of Esterel[END_REF], notably adding a specific syntax and a seamless integration of interactive graphics.

At the conceptual level, a Smala program is a declarative specification of a graph of coupled processes going from a set of event sources to a set of output processes. Such specification is akin to the way causal chains are declared in an imperative language/framework such as Java or Qt: adding listeners (Java), or connecting signals to slots (Qt) is a way to declare a causal chain during the initialization of an interactive program. The execution is triggered by the occurrence of events that are propagated by an activation vector, resulting from the sorting of the graph of processes.

At the syntactic level, Smala provides specific operators to define causal links between processes (listing 1). For example, the arrow between two processes specifies that each time the left process is activated then the connected process must be activated (binding). More complex control structures exist such as FSMs. An FSM consists in declarations of states, followed by declarations of transitions (listing 2). Each state may include other processes. The Smala syntax has been designed to facilitate the development of interactive software. Indeed, the arrow-based notation is a representation of the control flow of an interactive software. The language designers have also reversed the direction of the classical APL assignment operator (𝑠𝑟𝑐 =: 𝑑𝑠𝑡 instead of 𝑑𝑠𝑡 := 𝑠𝑟𝑐) to make it consistent with the directions of other types of flow (binding: -> and data-flow/connector: =>). Smala makes it easy to combine data-flows and FSMs: a data-flow can trigger an FSM transition and an FSM can start or stop a data-flow (as envisioned in [START_REF] Chatty | Extending a Graphical Toolkit for Two-Handed Interaction[END_REF][START_REF] Jacob | A visual language for non-WIMP user interfaces[END_REF]).

However, as with Java or C++/Python/Qt programs, the entire causal chain specification can be spread over several files, which makes it difficult to understand. The Smala FSM also exhibits some scaling issues with a large amount of states and transitions, and with nested FSMs. Even if we believe that dedicated syntax of Smala is more usable for interaction programming, it is not enough to understand causality.

INTERACTION TECHNIQUES

We devised from the state of the art three requirements for the design of interaction techniques that would support a programmer in understanding interaction code. We devised the design principles to fulfill the requirements. Most design principles and techniques leverage on a textual code editor. Even if some graphical representations can be used to represent data-flow or FSMs, text-based editors are still heavily used as they provide features that are deemed usable by many programmers. Still, we hypothesize that the regular, mostly 1D, textual presentation of causal relationship constructs spread in multiple files does not help programmers to understand the causal chain. We demonstrate the interaction techniques in a concrete way through use cases.

Requirements

The understanding of interaction code poses specific challenges arising from the multiplicity of causal chains across files that split the description of behaviors. We wanted to design interaction techniques directly available in the edited source code file, saving navigation time across files. Although code lines integration within edited source code is not new, we have not seen such techniques applied to interaction code and causal relationships understanding. Hence, our interaction techniques should support programmers in:

Design principles

The first design principle that we followed to fulfill [ReqCausal] is to enable the programmer to make the y-ordering of lines of code consistent with the expected execution ordering [DgnYRearrange].

Reordering is especially important when the programmer wants to apprehend the multiplicity of execution paths due to uncontrolled sequences of external events. It is important to note that reordering only concerns the appearance of the program, not its actual source code, and it does not change its semantics. The representations of code change upon users' request, and can be set back to the original arrangement upon request.

The second design principle we followed to fulfill [ReqNoSplit] is to bring together the causal relationships that are far away from each other in the source code, including in the same file [Dgn-Together]. This is especially important when coping with causal relationships that reside in several code locations.

The third design principle is to take advantage of the text representation and of the properties of visual variables from Semiology of Graphics [START_REF] Bertin | Semiology of Graphics[END_REF] to understand the code and its execution. Notably, the first three interactions reorder the programming constructs to display them like an imperative, y-ordered control-flow. Note that the first design principle can be considered a special case of the third one, but its importance deserves a proper principle [DgnVisVar].

Finally, the fourth design principle consists in using animations to help the user apprehend the changes of the representations [DgnAnim] [START_REF] Chevalier | Animations 25 Years Later: New Roles and Opportunities[END_REF][START_REF] Schlienger | Improving Users' Comprehension of Changes with Animation and Sound: An Empirical Assessment[END_REF], especially for [ReqDynamicCaus]. We also took into consideration the guidelines related to animation of lists, as lines of codes can be considered as lists [START_REF] Schlienger | Improving Users' Comprehension of Changes with Animation and Sound: An Empirical Assessment[END_REF].

To the best of our knowledge, [DgnYRearrange] and [DgnTogether] have never been identified and used in past work. [Dg-nAnim] is not new, but has not been applied to code-to-code transformation. [DgnVisVar] is not new [START_REF] Conversy | Unifying textual and visual: A theoretical account of the visual perception of programming languages[END_REF], but has never been applied to interaction code. Though following the same design principles, the interaction techniques were not designed to be completely consistent: our goal was to explore a design space and how well the techniques would support program comprehension. Currently, the interactions are implemented in a GUI that enables a programmer to launch a Smala program and explore its source code with the interactions. Even though the first three interactions may be available statically (e.g. without running the explored source code), our implementation relies on the run-time initialization phase of the tree of processes and the reflexive capabilities of the Smala execution engine. Only the fourth interaction relies on the run-time execution. Relying on the execution engine enabled us to prototype the interactions without implementing a static analyzer.

Interaction 1: reordering a data-flow

The first interaction technique provides the programmer with means to navigate inside a data-flow and display it like an imperative control-flow. A use case is as follows. The programmer of a drone ground station application is faced with an unexpected behavior while testing interaction code: some text in the graphical interface is not updated as it should be, which is likely the symptom of a broken data-flow. The cause to be identified is a missing connector: the speed of the drone model displayed in the view is not connected to the corresponding data from the bus.

We designed an interaction technique to navigate the data-flow (Figure 2): clicking on a variable on the left-hand side of a dataflow construct summons an animated apparition of the upstream construct that is connected to the said variable. The upstream construct appears in a line of code just above the clicked construct. In a recursive manner, the programmer can click on the summoned lines to display further upstream constructs. If multiple sources are connected on a property, they are all shown using a line each. If there is nothing connected, a short animation quickly bounces the clicked line up and down. Note that the summoned lines may come from the current text file being edited but also from other files. In this case, the source filename is appended to the right of the line as a hyperlink that enables the programmer to jump to the code.

Step-by-step, the programmer is thus able to trace back the absence of a causal construct that should have led to the activation of the line of interest. In our example, we can see that there is nothing connected to the property named plane.vp. As such, this cannot be automatically identified as a mistake, since such behavior could have been perfectly legitimate in some applications (in a program, many properties are partially connected). The interaction also works with downstream constructs by clicking on the right side of the arrow, or on the declaration of a property. It is also available for transitions in FSMs: one can explore the chain that leads to or depart from a transition event.

Interaction 1 relies on three design principles to help understand the data-flow: [DgnTogether], [DgnYArrange] and [DgnVisVar]. Compared to a "Jump to Reference" command in a traditional code editor which completely changes the content of the window, or at best provides a transient pop-up on top of the currently edited window, the insertion above the lines being read keeps the context in which the programmer tries to understand the code, and displays the lines of code as if they were next to each other. The resulting sequence of lines of code, perceptually ordered in the ydimension and x-aligned [START_REF] Conversy | Unifying textual and visual: A theoretical account of the visual perception of programming languages[END_REF], is reminiscent of the sequence of lines of code in an imperative language. However, here the y-dimension of the source code is mapped to the causal relationships (reactive language) instead of the program counter (imperative language), while the x-alignment specifies that all lines belong to a same dataflow (reactive) instead of control-flow (imperative). This makes the causal chain directly visible. The same interaction technique makes it easier to spot a wrong link in the data-flow: the programmer can quickly identify a process wrongly connected to another one.

Interaction 2: reordering textual FSMs

In the example in Figure 1, the FSM has 7 states and 20 transitions. It is thus difficult to apprehend the whole FSM code and understand its behavior given a particular sequence of events. The use-case is as follows: there is a suspicious, transient activation of the check-LoopState state. The user wants to understand the causal events that lead to this state, what the state is activating in turn, and what causes its exiting. However, the current graphical state of the FSM representation makes it difficult to visualize such a sequence as it forces the user to look for the involved transitions and to hop from a line to another in arbitrary directions.

We designed an interaction technique based on the reordering of the elements of an FSM. The programmer can hover over a state, which highlights with a green background the transitions that go into or leave the state. S/he can then click on the state and see a smooth, animated change of the layout of the transitions around the clicked state, to make 'in' transitions lie above the state, and 'out' transitions lie below the state. She can continue exploring the follow-up causal chains by clicking on another state, and see the 'in' and 'out' transitions move around it.

Interaction 2 relies on the same design principles as Interaction 1, but applied to the causal chain related to FSMs (with states, transitions, events) in lieu of data-flows (with variables and operators such as connectors, bindings or assignments). Similarly, the resulting sequence of lines of code, ordered in the y-dimension and x-aligned, is reminiscent of the sequence of lines of code in an imperative language, and allows a developer to better understand the control-flow and its associated causal chain.

Navigation within FSMs and dataflows can be combined. One can rearrange transitions around a state (interaction 2), and click on the process to_check_loop that triggers a transition. . . (interaction 1): check_state -> checkLoopState(to_check_loop) . . . to summon the apparition of an upstream binding: checkSound.t.end -> to_check_loop check_state-> checkLoopState(to_check_loop)

Interaction 3: reordering graphical FSMs

The previous interaction techniques are a demonstration of how text-based representations of interaction code could be re-arranged to better follow the control-flow. The use-case from Interaction 2 was concerned with the understanding of the control-flow "around" one particular state. Here the use-case is extended to multiple states. A popular representation of FSMs relies on circles depicting states and on arrows depicting transitions, annotated with the event that fires a transition. Even if the two representations ("textual code" and "circle-arrow") seem different, we can smoothly transition from one to another to adapt the view according to the task at hand.

We designed an interaction technique that rearranges the circlearrow representation (Figure 3). Starting from the circle-and-arrow representation, the user draws a line that passes through states, transitions and events. The users should specify their gesture according to the particular sequence they want to analyze. After the gesture has been performed, the system animates a rearrangement of the circle-arrow representation. The final arrangement allows the programmer to read from the top to the bottom the causal chain involving a succession of states and events.

Again, such a representation provides the programmer with a sequential reading of the code, which makes causal ordering salient. Remarkably, the final circle-arrow representation is similar to the textual one. This supports the hypothesis that graphical and textual are not so different [START_REF] Conversy | Unifying textual and visual: A theoretical account of the visual perception of programming languages[END_REF]): the visual representation reuses the assets of the textual one, such as selectivity of the x-dimension (i.e. left alignment [START_REF] Conversy | Unifying textual and visual: A theoretical account of the visual perception of programming languages[END_REF]) and the ordered perception of the y-dimension to depict the order of the control-flow.

Interaction 4: showing the dynamics of FSMs

The dynamic behavior of FSMs can be hard to understand. The use case is a follows: on a GUI there is a displayed clock, coded with a FSM, which should switch from clock to timer mode upon request on a "play" button. But nothing happens. The programmer wants to check whether the issue is a faulty transition. We designed an animation that highlights the activation of states and transitions during execution (see Figure 4). Each time an FSM enters some state, the state is highlighted and the transition that activated it is both 6 highlighted and outlined. States might be declared remotely from the declaration of the FSM itself, especially in an embedded FSM. Therefore, the representation also connects the activated state (e.g., 𝑝𝑙𝑎𝑦_ℎ𝑜𝑣𝑒𝑟 ) to the parent FSM (e.g.,𝑐𝑡𝑟𝑙) in which it is declared. As time goes by during execution, the previous activated states and transitions are denoted by horizontal sidebars that progressively fade away and shrink towards the left (see Figure 4), much like a vertical VU-meter in music players. The progressive fading gives the user a sense of the history of activations. This representation also shows whether a state or a transition has been activated at least once. This is particularly useful when the transition between states is very fast.

EVALUATION

We conducted a study to assess how much more usable would Causette be compared to a traditional text editor. Due to the nature of our research (facilitating some program understanding tasks), we expected that it would be difficult to design a controlled experiment that would be both statistically and practically significant. We expected that measuring the time of completion of a program understanding task would be highly dependent on inter-individual differences. We thus followed the principles of Single-Subject Research [START_REF] Morgan | Single-Case Research Methods for the Behavioral and Health Sciences[END_REF]. Single-Subject Research involves testing a small number of participants and focusing intensively on the behavior of each individual and measuring strong and consistent effects that have biological or social importance [START_REF] Morgan | Single-Case Research Methods for the Behavioral and Health Sciences[END_REF]. In the following, we present the results per-subject, instead of aggregated measures of multiple subjects. To design the experiment and report on its results, we followed the principles of Fair Statistical Communication in HCI [START_REF] Dragicevic | Fair Statistical Communication in HCI[END_REF]. In particular, we asked quantitative research questions when suitable, and we stated the effect size.

Research questions

We focused on the following research questions: RQ1. How much would Causette facilitate the understanding of causal structures in interaction code? RQ2. How much would Causette make a difference when given a complex "interactive bug"? RQ3. How much would programmers benefit from insertion of related code lines into the source code being analyzed compared to common methods in text editors (e.g. '''find", "jump to definition")?

Participants

We recruited 10 participants. All of them were men (more on this in section 6) and were of age 20-25, 1 of age 25-30, 4 of age 30-40. They had at least an M.S in Computer Science or HCI, 3 hold a Ph.D degree. Half of them had more than three years of professional experience in interaction programming with Qt, Javascript or Swing. All of them were proficient in Smala and were using Sublime Text as an IDE. Sublime Text is a typical textual code editor, with features such as those mentioned in RQ3.

Experimental design

We are aware of the challenges arising in the design of code comprehension tasks and existing work has helped us analyze the limits of our own evaluation study [START_REF] Dror | Considerations and Pitfalls in Controlled Experiments on Code Comprehension[END_REF]. Our experimental design is inspired by two papers that evaluate new features for IDEs, Theseus [START_REF] Lieber | Addressing misconceptions about code with always-on programming visualizations[END_REF] and CodeBubbles [START_REF] Bragdon | Code bubbles: A working set-based interface for code understanding and maintenance[END_REF]. We thus conceived a set of tasks related to code comprehension and debugging. We used the code of a real-size application actually in use in Air Traffic Control (ATC). It consists of a GUI that supports air traffic controllers in detecting a conflict between two flights. The source code amounts to approximately 1,000 lines of Smala spread across 7 files.

Participants were given 6 tasks to complete in total (A to F), those 6 tasks falling into 3 categories (dataflow, value, debug). We designed the tasks within a category to be equivalent in terms of difficulty. F. Faulty alarm: The participant was asked to debug a FSM in charge of the sound management of the application. That FSM had an embedded FSM, with 20 transitions and 9 states. We introduced an error in the code, by deleting one transition of the FSM. As a consequence, the FSM ended up stuck in some state 𝑅𝑎𝑑𝑎𝑟𝐿𝑜𝑜𝑝𝑆𝑡𝑎𝑡𝑒 and an alarm kept ringing. Participants had to figure that out and fix it. There were 2 conditions: a control condition with the participants' usual editor (here Sublime), and a condition with Causette. Sublime is not a full-blown IDE, and we discuss the reasons of choosing it for control condition in section 6. To facilitate withinsubjects comparison, each participant was assigned three (from each category) tasks in the control condition and three tasks using Causette. To counterbalance an order effect, half of the participants completed all of their control tasks first, while the other half completed all of their Causette tasks first. The selection of the tasks across categories was randomized.

• Dataflow comprehension questions (

Before the evaluation, each participant was given a 10 minutes summary of the code: an overview of the architecture and the functions of the app, and the ATC vocabulary to understand identifiers in the code. The code itself did not include any comments. Once the participant had read the question and was ready to perform the task, a timer was launched. All the interaction techniques were available for each task. Up to seven minutes were allowed for each of the A-B and C-D tasks, while fifteen minutes were allowed for E-F tasks. When participants felt they completed the tasks, they told us, we stopped the task, recorded the duration regardless of the correctness of the answer, and asked for a confidence rate. Participants were also able to give up a task if they felt they could not perform it. If the timer reached the maximum allowed time, we interrupted the task. In total, up to one hour was devoted to the tasks. At the end of the experiment, we made the participants fill a System Usability Scale (SUS) [START_REF] Brooke | SUS: A 'Quick and Dirty' Usability Scale[END_REF] questionnaire on Causette, followed by a 30 minutes interview to get qualitative feedback.

Results

The complete results of the study2 include completion time, completion success, confidence rate and SUS score. Figures 6,7,8 shows the completion time and completion success per participant for each type of tasks and according to the two conditions.

Effectiveness -Degree of achievement.

The participants were all able to correctly complete the tasks in the Causette condition. This contrasts with the completion rate in the Control condition, where many participants could not provide a correct answer or just gave up. In particular, 9 participants out of 10 performed partially correctly the dataflow tasks, as their answers were not exhaustive (they did not mention all paths of the dataflow, and remarkably all but S8 felt confident). Except S1, each participant at least made an error or gave up in the Control condition. 4 participants could not complete the debugging tasks (2 gave incorrect answers, and 2 gave up). This suggests that users are not completely effective with a traditional code editor for these tasks, supporting our analysis of the problems encountered by programmers. This also suggests that our interaction techniques make users more effective than a traditional code editor for all types of task.

Participants were always confident in their answers in the Causette condition. 4 of them (S3, S5, S6, S8) were not confident in some of their answers in the Control condition. In the dataflow tasks, users were able to perform 93% faster with Causette on average. In these tasks, users were only able to answer partially, but we think that the time of completion is meaningful, since they felt they have completed the tasks. Had they resumed the tasks to find out all paths in the dataflow, they would have spent even more time.

In the value tasks, users were able to perform 77% faster with Causette on average.

The results of the debugging tasks are more contrasted. As a reminder, in the control condition, S1 performed better, S4 performed equally, but two participants gave up and two gave incorrect answers. S1 is slower with Causette in the debugging tasks. S1 told us he was familiar with dataflow issues, and less familiar with FSMs bugs, which could explain this outlier. S4 is as fast with Sublime as with Causette. S4 told us he had been focusing on FSMs in his code for two months before the experiment, which could explain his proficiency with Sublime at finding bugs. Except for S1 and S4, the 8 other participants performed faster with Causette. Ignoring incorrect answers, only five participants (S2, S3, S5 S7 and S9) performed significantly faster with Causette with respect to effect size. S6, S8 and S10 performed faster with Causette but with a smaller effect size. All in all, these results tend to suggest that Causette makes programmers faster at fulfilling the dataflow and value tasks. It may make them faster at debugging with a smaller time gain for half of the participants. 5.4.3 Satisfaction. We gathered the SUS scores for Causette only. 7 out of 10 are higher than 90, the remaining 3 (S1, S6, S7) range from 62,5 to 72,5. S1, S6 and S7 thought that they may need the support of a technical person to use Causette (score 3). S7 eventually stated that he would be able to learn to use it quickly. S1 and S6 did not feel very confident (score 3). S1 and S7 thought the system is not well integrated (score 3). S6 did not think he would use it frequently. We present Causette in this paper as a set of interactions, and not as a system. If we polished the interactions as much as we could, the system itself that embeds them is still not very usable. We hypothesize that the comments of S1, S6 and S7 reflect the usability of the system more than the interactions per se. 5.4.4 Internal validity assessment. We examined whether the design of our experiment exhibits any bias with respect to task equivalence or order (see Figures 10,11).

In the two conditions, the completion time means between A-B, C-D and E-F tasks tend to confirm that the two tasks within each three categories were of the same difficulty.

In the Causette condition, the order seems to have no effect. There could be an order effect on the completion time of the Sublime condition. It looks as if the use of Causette in a first place had a positive impact on the performances in the Control conditions for the data-flow and value tasks, while it is the opposite for the debugging tasks. However, the computed average times involve at most 3 values, even less when participants gave up or gave an incorrect answer. It is thus difficult to be conclusive or to comment. 5.4.5 Qualitative results. After each session with a participant, we conducted an interview to get qualitative feedback. Our three research questions RQ1, RQ2, RQ3 target all of the tasks.

RQ1. How much would Causette facilitate the understanding of causal structures in interaction code? Participants mentioned that they felt Causette saved them time to understand the dataflow (all the participants, except S6). The reordering of the in-and out-transitions was also described as time saving (S1, S4, S8, S10). S1 mentioned that he usually needs to draw FSMs when he got confused about the transitioning between states. Participants S1, S8, S10 pointed out that it was interesting to display the current state of an FSM (in the real-time animation of the FSM) instead of printing it in the console.

The issue about the declarative style of interaction code and how it prevents easy causal understanding was brought up: "Because what's difficult is the declarative aspect, without logical links. You can write it in any order you want. " (S8). S8 also developed an issue for FSMs: "with nested FSMs, after a moment I'm lost in the file, and having something that allows to put logical order between states and transitions, that helps. "

A few participants mentioned that the tool helped them construct or get quick access to a "mental picture" of the causal relationships: "I don't have to have a mind map all the time [...], there is no need to make drawings. " (S4). Another finding was that 6 out of 10 participants underlined what they felt would be the main use of the tool: to get into someone else's code or one's own former project.

The animated insertions were described as presenting the causal relationships effectively. For the dataflow, participants mentioned they felt reassured being provided with a guaranteed, exhaustive list of sources and destinations (S1, S10, S3, S8, S4). S1 and S10 commented on the fact that with a traditional editor, they usually feel unsure whether they figured out completely the dataflow, and they took time to check that the property under study is not dependent on another file or is renamed somewhere else. Such comments are consistent with the confidence rates we measured.

RQ2. How much would Causette make a difference when given a complex "interactive bug"?

The two complex comprehension and debugging tasks were commented by some participants as really reminiscent of the problems they usually face. Several comparisons and equivalent use cases were provided. S3 said "it reminds me of many cases [...] : I was creating my graphical objects, but they were aligned at the top left of my interface, and it took me time to understand that I had not initialized their length and height".

In the debugging task, S5 said he could have answered the last task he gave up in control condition, seeing clearly that the FSM was stuck in a state, but he got tangled up in staying focused on the wrong state. S4 and S7 elaborated on that aspect, saying the FSM animations are useful to locate which state it is blocked in. They found the real time animation and the history bar even more useful "to really see it". S1, S4, S5, S6 found that reordering FSMs make transition errors more salient.

RQ3. How much would programmers benefit from insertion of related code lines into the source code being analyzed?

First, participants brought up that Causette avoids navigating at length: "with the tool we avoid unnecessary navigation. When you use diverse "find" functions, you often end up having too many occurrences" (S4). This could be supported by the difference in response time we found. Comparisons with search functions in different IDEs were often conducted, to the point where Causette was described as a "super fast search tool" (S5). S2, S3, S4, S5 and S8 liked the simplicity of the triggering of the animated insertion, because it avoided the use of a menu. As one of our participants commented, the interactions involving line insertions might look unusual in the beginning, but it seems easy to get into the habit. Since code is rearranged, it is worth noting users may be disorientated. This was mentioned by one participant: "I clicked unintentionally, and I had trouble finding my way around, I didn't know what I had clicked on" (S9). This is especially true in interactions with FSMs as the layout may end up very different from the initial arrangement. We used animations to mitigate this aspect. We also provided an "original view" button to get the layout back to its original form. As for the FSM, the real-time animation was appreciated but the reordered FSM animation was also found useful. S1 who liked the graphical FSM underlined that the reordered FSM was very interesting.

THREATS TO VALIDITY

Participants. The number of participants in the experiment is low, and they are all men. We could not avoid this sample bias, as the users of the Smala language happen to be men. Still, we do not have any plausible hypothesis about the effect of genre on the results of the experiments. As noted by Feitelson [START_REF] Dror | Considerations and Pitfalls in Controlled Experiments on Code Comprehension[END_REF], the effect of genre is not clear and requires further investigation.

Size of code. The application used during the evaluation is 1,000 lines of code only. One can wonder if the interaction techniques would scale to larger code bases. 1,000 lines seem small, but they are written in a specialized, interaction-oriented programming language which is expressive and should not be compared to the size of code written in a general-purpose language such as Java. Still, the FSM of the example has a moderate complex behavior. Scaling up the number of states to a dozen would make it more difficult to perform interaction 3. Besides, our representations have limits: for example, Interaction 1 and 2 only display one causal chain at a time, and do not allow exploring multiple chains simultaneously. But the control condition does not facilitate exploring one causal chain only neither, and we think that it would scale even more badly, as one would have to navigate more files with longer causal chains.

Tasks. The tasks only partially represent the programming activity. We are aware that the evaluation has limits and should be complemented with other experiments. In particular, tasks A-B and C-D where the results were the most in favor of Causette, may seem idiosyncratic. However, the tasks represent a typical problem encountered by programmers of interactive programs. We designed the interactions to support solving those problems, hence it is not surprising that the evaluation suggests that Causette offers support. Nevertheless, it had to be demonstrated.

Control condition.The choice of a limited set of Sublime Text interactions as the control condition is disputable. Causette is a set of interaction techniques that may have been compared to those of a full-featured IDE. Still, we left the participants choose the Sublime Text interactions they use in their real-world activities. In particular, one can debug program with Sublime Text. However, such a debugger is of little help for the interaction code problems.

Understanding. A general pitfall of comprehension evaluation [START_REF] Dror | Considerations and Pitfalls in Controlled Experiments on Code Comprehension[END_REF] applies to our work: does the study actually tell something about comprehension? It could turn out that some participants, especially for task A-B and C-D, found the correct answers about the causal chains in code, without properly understanding them. Addressing that issue would require further investigation.

Reading/Writing. Finally, the study suggests that Causette support code reading, but not code writing. Since developers read 10 times more code than they write [START_REF] Dror | Considerations and Pitfalls in Controlled Experiments on Code Comprehension[END_REF][START_REF] Martin | Clean Code -A Handbook of Agile Software Craftmanship[END_REF], our results suggest that at least Causette could be useful. Further work is needed to assess whether Causette could support code writing.

Generalizability. The interactions may be too specialized to the particular language we used. Some languages or toolkits provide some of Smala's features e.g. Qt's signal/slot, JavaFX binding, SwingState's FSMs. We think that most of the interactions could be applied to these features e.g. navigating the chain of signal/slots in Qt or SwingState's FSMs. However, this necessitates appropriate analysis and introspection tools. For example, one could use the Qt's MetaObject system to gather dependency information, and use the API provided by some text editors to insert the upstream and downstream signal/slots where a particular connection is created in the code. Similarly, the QML or SwingStates run-times could record the parameters of the transitions and inform Causette. With this, it would be possible to adapt Causette interactions to an editor of Qt code: clicking on 𝑜𝑏 𝑗𝑒𝑐𝑡1.𝑠𝑖𝑔𝑛𝑎𝑙 in this line of code. . . : object1.signal.connect(object2.slot) . . . could summon the apparition of an upstream construct above: object0.signal.connect(object1.slot) object1.signal.connect(object2.slot) Similarly, since QML and Swingstates provide explicit FSMs syntaxes, an editor of such languages could rearrange the order of transitions as in interaction 2.

CONCLUSION AND FUTURE WORK

We presented Causette, a set of four interaction techniques for a textual and graphical code editor. The interactions rearrange and animate textual code in a way that makes the causal relationships more understandable. An evaluation with professional programmers suggests that Causette may be more usable than a regular text editor for some interaction programming tasks. This work indicates that rearranging interaction code may help developers better understand and fix it. This work can be continued by exploring unanswered questions on scalability, generalization, disorientation, and ecological validity. Instead of running another controlled experiment, we plan to provide our participants with a better, more robust, and more integrated version of our tool and observe its use in practice during a longitudinal study. This should also provide us with new insights on how to best support interaction programmers.

ICPC ' 22 ,

 22 May 16-17, 2022, Virtual Event, USA Martin, Magnaudet and Conversy

  hover (r. enter ) hover -> idle (r. leave ) hover -> pressed (r. press ) pressed -> hover (r. release ) // ^^transition }

Figure 2 :

 2 Figure 2: Interaction 1. Reordering a data-flow: (a) the user clicks on the left of a connector, an animation inserts the upstream data-flow construct (b) upon click on the new line, an animation inserts the next upstream construct (c) the user clicks on the new line, the system animates the line up-and-down to specify that the beginning of the data-flow has been reached.

Figure 3 :

 3 Figure 3: Interaction 3. Reordering an FSM given a path selection: (a) starting from a canonical graphical circle-arrow representation of an FSM, the user draws a path through states and transitions according to the causal chain she wants to explore; (b) the system reorders and animates the circles and arrows; (c) the final layout is similar to the corresponding text representation.

Figure 4 :

 4 Figure 4: Interaction 4. Showing in the text editor the activation of states and transitions during execution. (a) The FSM enters state play idle, due to activation of the highlighted transition (b) The selected state moves to play hover (c) State play hover is highlighted and changes in the history sidebars are updated.

Figure 5 :

 5 Figure 5: Air Traffic Control app used for the evaluation

  A-B): 2 tasks targeted the understanding of dataflow and required the participants to identify what could trigger the activation of a variable or what the variable could activate down the causal chain. • Value questions (C-D): 2 tasks asked what values a variable could take. • Complex comprehension and debugging tasks (E-F): Finally, 2 tasks involved a complex bug to fix. The tasks require a deeper understanding of the overall behavior of the program. E. Missing textual object: The task involved solving a dataflow problem, where the value of the flight callsign was not correctly connected to the textual property of the GUI. The error was a property naming problem due to a former incorrect copy/paste.

Figure 6 :

 6 Figure 6: Completion time for the first category of tasks (dataflow questions), comparing control condition (Sublime) and Causette condition. By default, the absence of a red symbol means the answer is correct.

Figure 7 :

 7 Figure 7: Completion time for the second category of tasks (value questions), comparing control condition (Sublime) and Causette condition.

Figure 8 :

 8 Figure 8: Completion time for the third category of tasks (debugging problems), comparing control condition (Sublime) and Causette condition.

5. 4 . 2

 42 Efficiency -Time of completion.

  Figure 9 represents the time percentage gain per participant and task groups. Except S1 and S4 in debugging tasks, all participants perform their tasks faster in Causette conditions.

Figure 9 :

 9 Figure 9: Time percentage gain per participant and per task groups when using Causette compared to Control (Sublime).

  Rearrangement of Causal Constructs ICPC '22, May 16-17, 2022, Virtual Event, USA

Figure 10 :

 10 Figure 10: Condition ordering effect: completion time means (upper figure) and answer incorrectness (lower figure) per task in Sublime condition.

Figure 11 :

 11 Figure 11: Condition ordering effect and completion time means per task in Causette condition.

All data anonymously available here: https://doi.org/10.5281/zenodo.6396517

ACKNOWLEDGMENTS

We thank our participants and colleagues for their advices and comments. This work was partly supported by the French « Programme d'Investissements d'avenir » ANR-17-EURE-0005 conducted by ANR and by Agence de l'Innovation de Défense.


Mamadou Lamine

Gueye Liuppa

Modeling a knowledge-based system for cyber-physical systems: Applications in the context of Learning Analytics

Keywords: Knowledge Base, Ontology, Autonomic Computing, Learning Analytics

Knowledge-based systems are major concerns in the field of artificial intelligence for the development of cyber-physical systems capable of self-management and adaptation to their context. The representation and knowledge management of these cyber-physical systems integrating heterogeneous actors must ensure the empowerment and optimization of these systems, as well as their ability to adapt to dynamic and unpredictable changes in their environment. In this document we show how a knowledge-based system based on semantic web technologies and IBM's reference model of Autonomic Computing (AC) can offer intelligent collaboration and coordination between people, data, services, robots and connected objects in the implementation of self-management processes in cyber-physical systems. Our solution consists to design a knowledge base in the field of Learning Analytics (LAs) involving a complex range of knowledge and heterogeneous components. This ontological knowledge base is guided by a functional decomposition approach based on the operating principle of the MAPE-K (Monitor-Analyze-Plan-Execute and Knowledge) autonomous control loop to provide the system with selfmanagement capabilities.

Introduction

With the fourth industrial revolution, universities underwent pedagogical transformations (University 4.0) induced by the integration of cyber-physical systems (connected objects, robots etc.) into teaching to improve and optimize the learning environment [START_REF] Sanin | Experience Based Knowledge Representation for Internet of Things and Cyber Physical Systems with Case Studies[END_REF]. Thus, educational institutions are seeking to develop selfmanaging systems to automate mechanisms for understanding, improving and optimizing learning based on knowledge about learning tracking, traces collected through the use of online tools and services [START_REF] Soualah-Alila | Archive ouverte HAL -Context-Aware Adaptive System For M-Learning Personalization[END_REF]26]. The representation and knowledge management of these systems integrating both connected objects, data, services, robots, people, etc. must ensure the empowerment and optimization of these systems, as well as their ability to adapt to dynamic and unpredictable changes in their environment. However, syntax-based methods of representing traditional knowledge offer few opportunities to address the semantic management obstacles that allow the orchestration of multiple actors in autonomous systems within the framework of University 4.0. There are also knowledge representation systems that provide empowerment, verification, optimization and adaptation services but are poorly adapted to a functional decomposition approach that allows the levels of maturation of cyber-physical systems to be taken into account (manual, observable, adaptive, self-adaptive, autonomous).

In this article paper, we propose a modeling of a common, scalable, dynamic and adaptive semantic space allowing the generic representation of physical or virtual objects, events, relationships, symptoms, diagnoses and change or action plans for the definition and execution of self-management processes, based on the IBM reference model of the MAPE-K (Monitoring, Analysis, Planning, Execution and Knowledge) control loop for autonomic computing [START_REF]An architectural blueprint for autonomic computing[END_REF]. This document is structured as follows: Section 2 provides a state of the art overview of knowledgebased systems and Learning Analytics, which is our case study. The two approaches we have explored for modeling our proposed solution are presented in Section 3. Before concluding, in section 4 we will present our case study and the proposed overall solution architecture to show a better appreciation of the contributions of ontologies and Autonomic Computing in industry 4.0, more specifically in the context of University 4.0.

State of the Art

In this section, we present a review of the literature on the Knowledge-based systems and Learning Analytics.

Knowledge-based systems

According to GRIMM et al. [START_REF] Grimm | Knowledge Representation and Ontologies Logic, Ontologies and Semantic Web Languages[END_REF], the representation of knowledge and reasoning is a symbolic branch of artificial intelligence that aims to design computer systems that reason around a representation of the world that can be interpreted by the machine, similar to human reasoning. Knowledge-Based Systems (KBS) have a computer model of the real-world domain of interest in which physical or virtual objects, events, relationships, etc. are represented by symbols. KBS reason on this knowledge and use different inputs to help agents (physical or virtual) solve complex problems or make good decisions [START_REF] Zaraté | A new trend for knowledge-based decision support systems design[END_REF].

In the field of KBS, several works [START_REF] Kitchen | Knowledge based systems in artificial intelligence[END_REF][START_REF] Soualah-Alila | Archive ouverte HAL -Context-Aware Adaptive System For M-Learning Personalization[END_REF][START_REF] Sanin | Experience Based Knowledge Representation for Internet of Things and Cyber Physical Systems with Case Studies[END_REF][START_REF] Salayandia | MetaShare: From Data Management Plans to Knowledge-Based Systems[END_REF] have been done in the conceptualization of data, information, knowledge, and intelligence in different forms using different approaches. According to [START_REF] Grimm | Knowledge Representation and Ontologies Logic, Ontologies and Semantic Web Languages[END_REF] the most widespread knowledge capture and representation formalities are based on :  semantic networks that can be found in RDF graphs;  rules in the form of "if-then", for example in business rules or logical programming formalities;  logic to achieve a precise semantic interpretation of semantic networks and rules.

Several researches have been conducted and many applications developed in the field of KBS [START_REF] Akerkar | Knowledge-based systems[END_REF], as in other areas of IT. In these systems, real-world facts are represented by simple assertions stored in a knowledge base and then manipulated using certain rules defined according to the objective of the system. We will present some research work carried out as part of the design of a knowledge base and reasoning on this knowledge: Kitchen [START_REF] Kitchen | Knowledge based systems in artificial intelligence[END_REF] presents the AM (Lenat) and Teiresias (Davis) projects in the field of expert systems of artificial intelligence. In these projects, the authors have developed knowledge-based systems capable of imitating the process of human intelligence functioning. The first, AM, applied to elementary mathematics, models an aspect of scientific research concerning the creation of new concepts and conjectures about their behaviour. It is based on the definitions of certain theoretical concepts and a large number of general heuristics to decide on useful research axes and generate examples that form the basis for conjectures. The second Teiresias project is a tool that allows an expert to build and maintain a knowledge base in his field of activity.

Based on the rules provided by an expert in the field, the system generates models that it uses to organize and control the use of the rules by giving the ability to provide a high-level report on the motivations for its actions. For example, for a programmer when a bug is discovered in the knowledge base, Teiresias is able to explain how it came to the knowledge base and even suggests plausible corrections.

According to Soualah Alila et al [START_REF] Soualah-Alila | Archive ouverte HAL -Context-Aware Adaptive System For M-Learning Personalization[END_REF], there are constraints of semantic heterogeneity of resources and heterogeneity of use of learning platforms that do not allow learning content to be adapted to the learner's contextual situation. To help solve this problem, the authors developed an m-learning system based on the learner's contextual constraints to recommend training paths without risk of disruption. The system architecture is based on a formal representation of data and business processes in an ontological knowledge base, as well as the use of metaheuristic algorithms to infer knowledge. According to the authors, them mlearning system offers trainers the possibility to model their know-how taking into account environmental and user constraints.

According to Sanin et al. [START_REF] Sanin | Experience Based Knowledge Representation for Internet of Things and Cyber Physical Systems with Case Studies[END_REF], cyber-physical systems and the Internet of Things can lead to the development of increasingly competent and intelligent systems in industry and academia, based on an interesting and attractive scenario. The authors propose Decision DNA, a knowledge-based system that integrates a complete representation of knowledge for the Internet of Things and cyber-physical systems. Decisional DNA collects explicit knowledge based on the experience of formal decision-making events and uses it to assist in the decision-making process. According to the authors, one of the main advantages of its use is to provide predictive capabilities based on knowledge and experience. Salayandia et al. [START_REF] Salayandia | MetaShare: From Data Management Plans to Knowledge-Based Systems[END_REF] propose a system of recommendations and advice for researchers, based on Semantic Web technologies, called MetaShare. It represents the researchers' experience, data collection, and management activities in a form that can be exploited by a machine by connecting the associated data. MetaShare is a decision-making support system for researchers on project planning and implementation based on similar project practices and decisions. Its formal representation of knowledge in the form of ontologies and rules allows for the collection, dissemination, and management of data to facilitate tasks related to the use and exchange of scientific data.

According to Marvis [START_REF] Shade | Overview of knowledge-based system[END_REF], current Semantic Web technologies offer the possibility of representing knowledge explicitly, through tools such as ontologies and rules applied to facts rather than implicitly through procedural programming methods. There is a common, evolving, dynamic and adaptive semantic representation of a problem that allows generic modeling of physical or virtual objects, events, relationships, symptoms, diagnoses and change or action plans for the definition and execution of self-management processes. Based on the above work, [START_REF] Soualah-Alila | Archive ouverte HAL -Context-Aware Adaptive System For M-Learning Personalization[END_REF] and [START_REF] Sanin | Experience Based Knowledge Representation for Internet of Things and Cyber Physical Systems with Case Studies[END_REF] can be used as a support for our approach to design the knowledge base of our system.

Learning Analytics

Through our case study, we will model a knowledge base in the field of Learning Analytics (LAs). LAs are defined at the first international conference on Learning Analytics and Knowledge (LAK) in 2011 as "measurement, collection, analysis, and communication of data on learners and their contexts, with the aim of understanding and optimizing learning and the environments in which it occurs".

Chatti et al. [START_REF] Chatti | A reference model for learning analytics[END_REF] presented a systematic overview of LAs and its key concepts using a reference model based on four dimensions, namely: 1) data, environments and context (what?), 2) stakeholders (who?), 3) objectives (why?) and 4) methods (how?). We will use this reference model as a basis for presenting different research studies in the field of LAs in relation to each dimension.

Arnold et al. [START_REF] Arnold | Course Signals at Purdue: Using learning analytics to increase student success[END_REF] have developed an early intervention solution for college faculty called Course Signals at Purdue University in Indiana. In short, Course Signals uses data from the information system, the course management system and the notebook. This data is then manipulated, transformed into compatible forms and entered into an algorithm generating a level of risk with additional information for each student, represented by a green, yellow or red indicator.

The Signals system is intended to help students understand their progress early enough to allow them to seek help and probably get good grades or change their behaviour. The authors propose to use business intelligence to improve student success at the course level, thereby increasing retention and graduation rates. The Signals prediction algorithm is based on the student's performance, effort, academic background, and characteristics.

Agnihotri et al. [START_REF] Agnihotri | Building a student at-risk model: an end-to-end perspective[END_REF] propose a model for early intervention with students most at risk of attrition, called the Student At-Risk Model (STAR), applied at the New York Institute of Technology (NYIT). The main risk factors include the student's grades, main subject, and certainty of choice of the main subject, as well as financial data such as the cost of tuition fees in relation to the student's means. STAR allows student support staff to screen and intervene early to improve student retention at university using a dashboard. It provides a binary indicator (risk of attrition or not) for each student and identifies the key factors that make a student unlikely to return the following year. STAR in version 2.0 is built from a dataset contained in a data warehouse where they can be created automatically as soon as a new student registers, then the data mining tools are used to form machine learning models to perform the classification task. These models use variables to predict whether or not a student will return the following year, which is then used to signal the risk of new students.

Niall Sclater et al. [START_REF] Sclater | Learning Analytics in Higher Education. A review of UK and international practice Full report[END_REF] have developed a sustainable and flexible LAs service for British universities and colleges, called Jisc's learning analytics. The system collects all kinds of data on student activity in various systems such as LMS such as Moodle, library systems, student record systems or other self-reported data through our student application. The objective of the tool is to provide an alert and intervention system to predict student success. This solution consists of a mix of commercial and open source solutions consisting of collecting and storing data in Learning Records Warehouses (LRW), analyzing these learning traces with the open platform "Apereo Learning Analytics Initiative" in order to present a dashboard for staff and to alert staff and students and allow them to manage the intervention activity through an alert and intervention system.

Admittedly, the list of LAs applications is not exhaustive, but it can be seen that most solutions consist of collecting, manipulating, transforming data in order to make them compatible before analyzing them using predictive algorithms. We note that the architecture of the proposed solutions for LAs is based on a combination of several technical solutions for data encoding, data mining and storage, and data analysis and processing. This presents many obstacles regarding the syntax and semantics required when integrating multiple data sources and also makes the deployment of LAs complex.

Proposal of Our Model

We propose a representation of a knowledge base based on an initial ontology-based approach to provide a common, scalable, dynamic, maintainable and adaptive semantic space that provides decision making adapted to the objectives of the system. The second approach to our modeling is based on the Autonomic Computing operating principle (MAPE-K) which consists of breaking down our knowledge base into autonomous components to provide a self-management process adapted to cyber-physical systems. These two approaches to our knowledge base will be detailed in the following sections.

Ontology-based modeling approach

Our ontology oriented approach [8] has as its main objective to define conceptual equivalences, which are then used to automatically calculate (reason) relationships between classes, properties, and instances.

Ontologies also allow any concept to be represented in a unique way, and adhere to the open world assumption: everything is permitted until it is prohibited. They provide a model of a body of knowledge in a given field, which can be real or imaginary in order to ensure knowledge management and reasoning on this knowledge, with a view to semantic interoperability between human and/or artificial agents [START_REF] Fürst | Raisonner sur des ontologies lourdes à l'aide de Graphes Conceptuels[END_REF]. Ontologies can provide cyber-physical systems with the ability to process and understand data, access a set of structured information and inference rules that they can use to achieve autonomous behaviour.

MAPE-K oriented design approach

For modeling of our KB to ensure self-management capabilities with a functional decomposition approach, we use the IBM reference model [START_REF] Kephart | The vision of autonomic computing[END_REF] to define autonomous managers, modules that provide autonomous behaviour to system components. It also allows us to better structure knowledge about the measures, symptoms, strategies, objectives, plans or requests for change, etc. in our knowledge base. This model is based, as suggested by Horn [START_REF] Horn | Autonomic Computing : IBM's Perspective on the State of Information Technology[END_REF], on a control loop called the autonomous control loop or MAPE-K loop, presented in the figure below:

Case study

To illustrate the representation of knowledge guided by an ontologically oriented approach in cyber-physical systems, based on the principle of CA [START_REF]An architectural blueprint for autonomic computing[END_REF], we work on scenarios drawn from Learning Analytics [START_REF]Learning Analytics, une tendance émergente dans l'éducation -sup-numerique[END_REF].

According to the 2012 report of the US Department of Education [START_REF]Enhancing learning and training through educational data mining and Learning Analytics[END_REF], with the emergence of LAs, "elearning systems have the capacity to capture learners' behaviour to provide feedback to a variety of actors to improve teaching, learning and educational decision-making". In these scenarios, we will implement knowledge modeling of learning tracking information, traces collected when using online tools and services. This formalization of knowledge in a form that can be interpreted by humans and machines will be used to automate and empower the understanding, improvement, and optimization of learning. Such a use case is relevant for illustrating the modeling of a KB for cyber-physical systems, as learning systems consist of a variety of interacting physical and/or virtual components (LMS, student, robots, teacher, etc.) and overflowing with a mass of information from different sources.

Fig. 2. Global architecture of the solution

The main components of our architecture are as follows:

Knowledge base (KB)

The knowledge base is the central core element of the MAPE-K loop, it contains all the knowledge relevant to the management of the system. The knowledge represented in our knowledge base concerns the learning management system (LMS), students, teachers, information system, pedagogical resources (books, films, computers, etc.) and chatbot, as well as the concepts, ensuring the functionalities of the MAPE-K autonomous control loop modules providing the system with autonomous behaviour.

We propose a knowledge base with an ontology oriented approach to ensure the heterogeneity constraints of data from different physical and/or virtual components (LMS, student, robots, teacher, etc.) of a learning environment. This formal representation of knowledge offers us the opportunity to better manage the automation and empowerment of educational decision-making processes for the understanding, improvement, and optimization of learning. We used Protege [START_REF] Musen | The Protégé project: A look back and a look forward[END_REF] as an ontology editor to create the ontology of our case study and reason on knowledge using integrated inference engines.

.

Reasoner

The reasoner is the trigger for the automatic and autonomous execution of our MAPE-K loop. This inference engine is an important component of the KB, without this software, it would be impossible to reason about knowledge. It applies logical rules of correspondence, selection, and execution [START_REF] Gong | An interoperable architecture and principles for implementing strategy and policy in operational processes[END_REF][START_REF] Umar | A Survey on State-of-the-Art Knowledge-based System Development and Issues[END_REF] to data captured by agents of the learning system and knowledge stored in the knowledge base in order to generate symptoms leading to diagnoses in order to make recommendations to the learner and/or teacher.

Fig. 4. Classification of the student by the reasoner as being at risk

To ensure the different functions of the system, we defined each function by a set of rules [START_REF] Gong | An interoperable architecture and principles for implementing strategy and policy in operational processes[END_REF][START_REF] Umar | A Survey on State-of-the-Art Knowledge-based System Development and Issues[END_REF] applied to the data captured by the agents of the learning system and the knowledge stored in the knowledge base in order to make recommendations to the learner and/or the teacher.

Monitoring

The basic function of our system is "Monitoring" which recovers the data captured by the different components of the learning system, presented in the form of facts, figures, etc.; for example:

Symptoms

The second function is the "Symptoms" which consists in determining the symptoms, i.e. giving meaning to the data, so that they become relevant information for our educational decision-making process. For example, it may generate a "student at risk" symptom if it finds that the student has a score below 7/10. Fig. 6. Symptom of an at-risk student

Analysis

Analysis, the third function is the subjective interpretation of information in order to determine the causes and the way to act in the process of achieving the objectives of Learning Analytics.

Diagnostics

The fourth function is the "Diagnostics", it is based on the symptoms, the results of the "Analysis" function, as well as the knowledge and rules defined in the system leading to the establishment of the diagnosis in a particular way to associate an objective with its diagnosis. This is what generates recommendations (educational decisions) for "Planning" to improve learning. For example, the diagnosis shows that the student has not completed all levels of knowledge acquisition.

Planning

The fifth function is "Planification", based on each diagnosis and the reasoning behind each diagnosis, it provides the "Execution" function with a sequential list of possible action plans leading to the implementation of recommendations.

Execution

Finally, execution generates actions in the form of recommendations to the learner or teacher to improve learning. The latter will be responsible for carrying out these actions in order to implement the necessary changes.

Conclusion

In this work, we proposed modeling of an ontology-based knowledge base with a functional decomposition approach, as well as self-management capabilities provided by the CA. In this article, let us implement the continuous improvement of automated decision making and the resolution of problems related to the selfmanagement constraints of cyber-physical systems. This scalable, dynamic and adaptive system allows the generic representation of physical objects, events, relationships, symptoms, diagnoses and action plans for the definition and execution of self-management processes. It can be further improved to provide better diagnostics for a variety of purposes and results to make its applications more intelligent and efficient. So, we note that in the LAs, two methods are preferred (xAPI and Caliper) [START_REF] Wikipedia | Analyse de l'apprentissage[END_REF] for encoding information on learning follow-up, traces collected when using online tools and services in the form of RDF triplets with the form "subject-predicate-object" + context. The statements are then stored in a Learning Record Store (LRS). We find that ontologies are native with an encoding of information in the form of RDF triplets with the form "subject-predict-object" + context, they also offer a controlled syntax and semantics to ensure interoperability. The knowledge base can be used in data mining and data warehousing.

In terms of perspectives, we intend to improve the work by working on in-depth documentation of the systematic diversification of scenarios and hypotheses in the knowledge base to arrive at a solution that makes it possible to assess the real contributions of a combination of ontologies and knowledge-based systems in LAs.

Fig. 1 .

 1 Fig. 1. MAPE-K autonomous control loop

Fig. 3 .

 3 Fig. 3. Representation of a student and his traces on the learning environment

oFig. 5 .

 5 Fig. 5. Monitored components of the system

Fig. 7 .

 7 Fig. 7. System analysis results

Fig. 8 .

 8 Fig. 8. System diagnostic results

Fig. 9 .

 9 Fig. 9. System planification results

Fig. 10 .

 10 Fig. 10. System execution results